locked
Cannot access a disposed object. Object Name : DataReader. RRS feed

  • Question

  • "Cannot access a disposed object. Object Name : DataReader."

    This issue occurs when i use two custom pipeline component in the validate stage of recv pipeline.

    1)frst custom component is to validate the FF file (if i use this component alone everything works fine)

    2)2nd custom component is to execute map in the pipeline after the frst component

    Is there a soultion for this ?

    Other than setting RecoverableInterchangingProcessing to "True" and adding pContext.ResourceTracker.AddResource(Stream) ??

    Thanks

    Ismail

    Monday, October 20, 2014 3:03 AM

Answers

  • Ok, either way, your first step should be to attach the debugger and see exactly where it's breaking and why.  Then back track to whatever is causing that reader to be null.

    • Marked as answer by Angie Xu Monday, October 27, 2014 1:30 AM
    Tuesday, October 21, 2014 2:47 AM
    Moderator
  • A very likely cause is that in your SECOND pipeline component you associated a Text/XmlReader with the message stream and CLOSED the reader. This causes it t close the underlying data stream and when BizTalk tried to access the contents for the purpose of publishing into the MessageBox, it failed with the error you see.

    Regards.

    • Marked as answer by Angie Xu Monday, October 27, 2014 1:30 AM
    Tuesday, October 21, 2014 5:00 AM

All replies

  • It would be easy if you had your code copied here..

    One thing I suspect and we normally forgot to do is to reset the position of the stream to the beginning when we go from one component to another, something like below:

    yourStream.Position=0 
    or 
    yourStream.Seek(0, SeekOrigin.Begin);

    (may be DataReader is yourStream in your case?) 

    This statement can be added at the last of your Execute method just before your return statement. "yourStream" is the stream variable associated with your message.

    We need to re-position the stream before we read it again (when you get control to execute method, default position is 0). When you have more than one components, the message (IBaseMessage) then needs to be passed from one component to another and the current position needs to be 0.

    FYI: RecoverableInterchangingProcessing is to allows an interchange to be processed completely even if one or more messages in the interchange fail at the following stages/phases and ResourceTracker is used to manage the lifetime of the objects (e.g. you will track those objects which you want to be disposed after execution of your component).


    Please mark it as Answer if this answers your question
    Thanks.
    Mo
    The contents I write here is my personal views, not the view of my employer and anyone else.

    Monday, October 20, 2014 3:31 AM
  • The solution will be in your code as it is extremely unlikely that adding anything to the Resource Tracker will solve the problem.

    Either way, this process seems a bit unusual, why are you processing the flat file and mapping in the Validate Stage?  Why can't you use the Flat File Disassembler and a Port Map?

    Monday, October 20, 2014 11:29 AM
    Moderator
  • It sounds like you are closing or disposing a object in the frist component and then tries to use it in the second. 

    Mohan Raj Aryal point is also good to look into. If the datastream has been read in the first component and you don't set the position = 0 you could get this error.

    Monday, October 20, 2014 6:35 PM
  • Hi John

    Reason being, initially process had 2 maps in the inbound and outbound port . I have merged both into a single xslt.

    Since the message size is huge it was taking hours to process the file. I have default FFDisasmblr and after that i have created custom validator component to extract the line numb of FF where exactly issue occured. Only after validate component i need to execute the xslt which m doing in the 2nd component of validate stage.

    Thanks

    Ismail

    Tuesday, October 21, 2014 2:14 AM
  • Ok, either way, your first step should be to attach the debugger and see exactly where it's breaking and why.  Then back track to whatever is causing that reader to be null.

    • Marked as answer by Angie Xu Monday, October 27, 2014 1:30 AM
    Tuesday, October 21, 2014 2:47 AM
    Moderator
  • A very likely cause is that in your SECOND pipeline component you associated a Text/XmlReader with the message stream and CLOSED the reader. This causes it t close the underlying data stream and when BizTalk tried to access the contents for the purpose of publishing into the MessageBox, it failed with the error you see.

    Regards.

    • Marked as answer by Angie Xu Monday, October 27, 2014 1:30 AM
    Tuesday, October 21, 2014 5:00 AM
  • This problem is caused by a very convoluted bug in the FF Disassembler in which, if a downstream component discards or replaces a disassembled message from the FF Disassembler (which is a perfectly reasonable thing to do), and if .NET decides to preform a garbage collection at just the wrong time (which it is perfectly entitled to do), and if Recoverable Interchange Processing is switched off, the FF Disassembler detects, during an internal status change, that an internal reader object, used to read the XSD document specification, has been invalidated.  The full explanation is more complex, but essentially, by setting Recoverable Interchange Processing to True, you are avoiding the line of code that detects the invalidity - a sort-of workaround, but not a true fix.

    Here is one approach that will work, but it takes some custom coding.  Create a custom pipeline disassembly component that wraps an instance of Microsoft's FF Disassembler.  In the Disassemble method, code a loop that fully disassembles the flat file and stores each resultant message in an in-memory collection.  Then code the GetNext function to return each of these cached messages in turn.  This will nicely avoid the issue and provide you with a FF Disassembler that is safe to use with other downstream components.


    Charles Young

    Monday, July 6, 2015 12:14 PM