Solidsoft-Reply / ESB-Libraries

Libraries for dynamic service mediation. The libraries depend on the Microsoft BizTalk Server rules engine.
Apache License 2.0
0 stars 2 forks source link

FF Disassembler may fail with DataReader disposed error following a garbage collection #15

Closed SolidsoftReplyDevelopment closed 9 years ago

SolidsoftReplyDevelopment commented 9 years ago

An intermittent issue can arise when using the Service Mediation FF Disassembler component in a BizTalk pipeline. It may sometimes fail to process a message, failing with an error that states that the DataReader has been disposed.

SolidsoftReplyDevelopment commented 9 years ago

This is a problem with the Microsoft FF Disassembler. It has been well-recognised elsewhere, but the reasons for it are not well-documented. After some research, I discovered that it concerns the premature disposal of an XML Reader object used to read the XSD document spec for a disassembled XML file. This can happen when a downstream component replaces the current message with a new message. The Microsoft FF Disassembler is not safe to use in these situations - effectively a logical bug in the Microsoft code. In this case, each message disassembled by Microsoft's FF disassembler is handed off to an instance of the Service Mediation disassembler which returns a new message and content. If a garbage collection occurs at run-time, the internal XML document spec reader is disposed as part of some internal state transition handling. If this happens before the FF Disassembler has fully disassembled the original flat file, the error occurs.

The only documented workaround is to switch on recoverable interchange handling on the Microsoft FF disassembler. This works because the problem is only triggered when recoverable interchange handling is switched off. Switching it on avoids the line of code that triggers the state transition that results in the closure of the doc spec XML Reader. However, this workaround is unacceptable here.

To deal with the issue, I have re-written part of the FF Disassembler code. The code now fully disassembles the flat file internally in the Disassemble method and stores each resultant message in an in-memory collection. The GetNext method processes the contents of that collection, passing each stored message to the Service Mediation component. Storing each disassembled message in-memory is not ideal and not the most performant approach, but it avoids the issue and makes the service mediation FF Disassembler safe for use with downstream components.

cnayoung commented 9 years ago

This problem as further compounded by similar issues when headers schemas are defined for flat files. In this case, any attempt to read the Data (clone) property of messages returned from the FF Disassembler results in an intermittent problem, probably again related to garbage collection, in which state transitions specify that that the flat file is no longer readable. This happens in a different part of Microsoft's code, but is somewhat similar to the original issue. I eventually solved this issue by removing a call to the Data property and replacing it with a call to GetOriginalDataStream(). It is not known if this also helps prevent the original problem.