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

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.

Thanks

Abhishek   

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

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.

Thanks

Abhishek

Retry Count was already set to 0. The orchestration dehydrates and the message remains active for an infinite time.

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 .

http://www.iis.net/configreference/system.applicationhost/applicationpools/add/recycling

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

Thanks

Abhishek