Port is constantly retrying after code change/service resuming

Hello everybody!

I have a custom pipeline component, a disassembler. It references a GAC'ed .Net library. I feed a file into pipeline containing my custom disassembler. Suppose, the GAC'ed library contains an error which is causing an exception. When that exception is thrown, we get a suspended instance of the port with message and an event log entry. Next, I fix the error in the GAC'ed library. When I build corrected code, version of the library is not altered. I then remove the old version of the library from GAC, and put good one in place of it in GAC. Next, I resume the suspended service instance. What I expect here is that good version of the library will handle suspended message without generating exception, and then message will be sent to orchestration connected to the port for further processing.

However. What I see puzzles me. The new code does process the resumed message, but as a side effect the port is starting to retry! That is the service instance is listed in BizTalk Admin Console under the "Retrying and Idle ports". And it never leaves that category. Result is that whatever the disassembler does, it does it over and over again until port is manually terminated. Particularly, my custom disassembler is supposed to send an e-mail notification. Well, I get hunders of e-mails in a matter of minutes. When I manually terminate the service and the re-feed original message into the port again, everything works just fine. So, it has something to do with resuming.

What is causing this looping-like behaviour of BizTalk? Does it have something to do with the way I replace the old assembly with new one in GAC? May be it's not a valid practice to update code in such a manner? If so, what would be the valid practice? To my mind, this should be very common scenario — an error exists in a library which suspends a message, that error is fixed, code is updated and message is resumed. I wouldn't expect anything as strange as the behaviour I witness within this quite streight forward scenario.

The issue may be easily reproduced by anyone through writing a dummy disassembler component that does nothing but calls a function in a GAC'ed assembly and then returns null in the GetNext() call. Bad version of the assembly would deliberately throw an exception, whereas good one would not.

Thank you for any hints!