none
Messages are being lost when communicating to a WCF NetNamedPipe receive adapter - how do i not lose them? RRS feed

  • Question

  • Hi,

    We have a Windows Service which receives messages and passes these along to a NetNamedPipe receive adapter on Biztalk 2006 R2.  During this call we seemed to be losing messages that were being sent via IOutputChannel.Send() from our client.  We have the send wrapped in a try catch to catch any exceptions and retry the message send if it did error, but it seemed that whatever was going wrong Biztalk was not throwing an exception back to the client.

    We did some tracing on WCF to try and find out where the error was coming from and on the client side saw this happening:

    There was an error writing to the pipe: Unrecognized error 232 (0xe8).

    And on the Biztalk side we saw this happening:

    "The system hit the limit set for throttle 'MaxConcurrentCalls'. Limit for this throttle was set to 200....."

    Followed by a number of PipeConnection aborted and exceptions saying :The write to the pipe did not complete within the allotted timeout of 00:01:00. The time allotted to this operation may have been a portion of a longer timeout.

    It seems to be during this melee of exceptions that our message is being lost.  Does anyone know how we can ensure we dont lose this message, or at least ensure biztalk tells us if it cant process the message so we can retry it later?  We have tried increasing the MaxConcurrentCalls, but this we believe is just masking the problem that we need to know if biztalk received the message ok before we move on to the next message.

    Thursday, March 18, 2010 3:15 PM

Answers

  • Sounds like a good call - there could potentially be some internal problems if you are losing data. It is prudent/cautious to contact MS Support on this. I was just thinking it was not able to consume resources fast enough - sort of like an overflow situation.

    If you do go back to WCF you might try a different WCF binding that can be used with IIS and scaled more predictably. If you hear there is a hotfix or workaround, be sure to post back.

    Thanks!


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Wednesday, March 24, 2010 6:18 PM
    Moderator

All replies

  • Did you already try increasing the timeouts on the port?

    Thanks,
    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Thursday, March 18, 2010 5:47 PM
    Moderator
  • Hi Ben,

    Thanks for your response.  We did try changing the timeouts and number of concurrent calls (which did help), but our concern is that should load pick up this could happen again.   We want to make sure the client is aware the biztalk receive adapter had an issue and so not remove the message from its queue (retrying the send).

    Cheers

    Monday, March 22, 2010 8:50 AM
  • Right, that is definitely a concern -  you can only bump the timeouts so far before you have other issues. I would be concerned about the scalability of named pipes - based on server resources and number of threads. Here are some good articles on Named Pipes from a thread management standpoint: http://msdn.microsoft.com/en-us/library/aa365594(VS.85).aspx and http://msdn.microsoft.com/en-us/library/aa365588(VS.85).aspx.

    So I would probably resort to using one or more dedicated BizTalk hosts for the named pipe ports so you have a separate thread pool to work with. I am hoping the BizTalk named pipe adapter is multithreaded but I am not sure.

    Thanks,


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Monday, March 22, 2010 3:07 PM
    Moderator
  • True, i hadn't considered thread issues as well as everything else (p.s. the net named pipe is multithreaded i can see the various threads spin up in the trace).  We do seperate out receive ports into their own host but thats all our receive ports and not just the WCF ones.  I have raised a support call with Microsoft to see what advice they have to give, if we get anything good ill post it back on here :o)  For the time being we are doing away with using WCF and using a file drop location instead where we can be sure the file has been dropped off succesfully.

    Thanks,

    Rich

    Wednesday, March 24, 2010 12:03 PM
  • Sounds like a good call - there could potentially be some internal problems if you are losing data. It is prudent/cautious to contact MS Support on this. I was just thinking it was not able to consume resources fast enough - sort of like an overflow situation.

    If you do go back to WCF you might try a different WCF binding that can be used with IIS and scaled more predictably. If you hear there is a hotfix or workaround, be sure to post back.

    Thanks!


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Wednesday, March 24, 2010 6:18 PM
    Moderator