Message stuck on active when HTTP 500 RRS feed

  • Question

  • I'm currently struggling with the following:

    I have a simple orchestration that is sending a message to a webservice (request-response) using WCF-basichttp.
    When the webservice throws an exception I receive a soap fault and the orchestration handles it perfectly fine. 

    In cases where I don't receive a soap fault but just an ordinary HTTP 500 the message sent to the webservice gets stuck on active forever. (orchestration dehydrated) The http 500 is not caught in that case. To simulate this you can make a typo in the web.config of the webservice. When calling the webservice a http 500.19 occurs and the message gets stuck on Active. Using a WCF-Custom binding makes no difference.

    I also tried this using the 'old' HTTP adapter and the HTTP adapter handles it perfectly fine.

    To me this feels like a bug in the WCF adapter. Any thoughts?

    (WIN2012, BTS2013)

    • Edited by _FJ_ Friday, June 19, 2015 11:27 AM
    Friday, June 19, 2015 11:01 AM


All replies

  • Hi ,

    You are getting expectation at IIS level were service is hosted . 500 internal server error or its subsequent numbers like 500.19 are related to IIS response mismatch were server is unable to respond to the request send by the end Application (Orchestration in this case ).

    As your service has fault contract defined so when you are getting service expectation then your Orchestration can gracefully capture the exception. but for IIS level expectation it wont be fissbile as it been raised as server exception.



    Friday, June 19, 2015 12:01 PM
  • The error occurs on IIS level so I indeed don't get a soap fault but a HTTP 500.19. However the WCF adapter is unable to handle this gracefully while the HTTP adapter can.

    What can I do to prevent that my messages and orchestration remain active/dehydrated forever? This behavior is of course not acceptable.

    By the way, the typo in the web.config is just an example to easily reproduce the behavior. We also have some other situations where a server exception is raised that produces the same 'active message behavior' in BizTalk.

    • Edited by _FJ_ Friday, June 19, 2015 1:23 PM
    Friday, June 19, 2015 12:18 PM
  • Hi ,

    Have you tried setting retry count on send port to 0 . After setting the retry count Orchestration wont get dehydrated and it can generate you error in first run only.



    Friday, June 19, 2015 4:38 PM
  • Retry Count was already set to 0. The orchestration dehydrates and the message remains active for an infinite time.
    Friday, June 19, 2015 5:55 PM
  • Hi ,

    Then can you try to set recycle setting for IIS . It is the issue which need to be taken care of from both IIS level and BizTalk level . 

    You need to modify recycle workers process as per MSDN documentation .

    You can also try setting SOAP.Connection timeout property inside Orchestration along with WCF connection property at the web.config file of the service.



    Sunday, June 21, 2015 5:32 AM
  • Adjusting the host recycle options is not an option because in our production environment the webserver lives on a different machine. I have no influence on the webserver.

    Lets do a step back. Why is the WCF(-BasicHttp) adapter not correctly responding when it receives an HTTP 500 from the webserver (not the application)? As I said, the normal HTTP adapter works perfectly fine in this scenario. Shouldn't it just handle the HTTP error correctly??

    The connection timeout settings are all default and set in the send port. I can of course set transaction timeouts in the orchestration but that is silly in this situation since (at least in my opinion) the adapter should just do its work. The web.config is on the server side and not my domain so little influence on that.

    In my test scenario it is also not an option because there I intentionally corrupted the web.config of the webservice to reproduce the behavior.

    Thanks for your suggestions but at this point I refuse to believe that the WCF adapter cannot handle HTTP 500 errors in this situation. Maybe you or someone from Microsoft can reproduce this?

    Monday, June 22, 2015 6:07 AM
  • I just added some WCF tracing and it seems the BizTalk process is actually throwing a ProtocolException. So it does respond to an HTTP 500 from the webserver. However the exception is somehow not reaching my orchestration.

    Also adding an explicit ProtocolException (next to System.Exception) as an errorhandler is not helping.

    Monday, June 22, 2015 6:42 AM
  • Hi ,

    As per your error screen shot your web server is not responding to the request send from your BizTalk Server . 

    I would suggest to test the service through WCF Test client or SOAP UI first and then validate your BizTalk request against what you are sending with SOAP UI.



    Friday, July 3, 2015 5:45 AM
  • Today I came across the CU list of 2013R2. Exactly this bug has been fixed in CU1 of BTS2013R2.

    Unfortunately there is no fix released for BizTalk 2013 (R1).

    @Microsoft, when is CU3 for BizTalk 2013 (R1) coming? Several of my clients are already waiting a long time for this...

    • Marked as answer by _FJ_ Monday, August 3, 2015 7:01 AM
    Monday, August 3, 2015 7:01 AM