locked
WCF Adapter Timeout.... RRS feed

  • Question

  • Hi All,

    I have a Schema Exposed as a WCF Service ( both basic and Custom Isolated) and with Time outs in the receive location set to 02:00:1.  I am getting a Time out after 20 min .. the receive location is closing out.. below is the Error. Following are the things I did with out any success.. I need to increase the time out to 2hrs the process will be processing 50K + records by calling multiple External Service… I can break the process but want to check if there are other options to increase the Time-Outs..

    ERROR : A request-response for the "CustomRLConfig" adapter at receive location "***************" has timed out before a response could be delivered.

    BizTalk 3013 R2

    Steps Taken

    1. Increase the Time-out in Receive port to 2:00:00hrs
    2. Increase the Response Time out in the Isolated Host to “60” which is the max
    3. Used BasicHttp Adapter and CustomIsolated also
    4. Add new DWord @ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc.3.0\MessagingReqRespTTL and set it to 300.

    Nothing solved the issue.. Can any  help me with this

    Wednesday, December 21, 2016 11:47 PM

Answers

  • I would first suggest to look at ur design.. Making the service caller wait for response for such a long time is bad.

    If ur process takes so long, break it into async calls. Return an ack as soon as ur biztalk process receives the request via the exposed service.

    After u r done with 50k+ processing, call something (best a service) on the caller end to notify that the processing is done.

    Have a unique identifier correlate these two for the source application. (Have a header with some requestID which the caller will send when sending the request. Use the same ID to notify the caller that this requestID processing is done)

    PS: Even if u increase it make it work under 60 mins, its highly likely that some time the process would be takign longer because of load reasons , network latency etc. 

    I would suggest to look for a better solution design.


    Pi_xel_xar

    Blog: My Blog

    BizTalkApplicationDeploymentTool: BizTalk Application Deployment Tool/

    Thursday, December 22, 2016 8:44 AM
    Answerer
  • I am afraid that is not possible as far as I know with BizTalk Application Hosts.

    Really 60mins is a long time for HTTP, I would suggest that you refactor your app, so that the HTTP call is not blocked for more than 60mins.


    Thanks Arindam


    Thursday, December 22, 2016 12:19 PM
    Moderator
  • Sorry forgot to mention after changing the time out to 60 on host I did restarted th apppool and it's now timing out at 60 min ... but I am looking for longer time-outs. More like 2 or 4 hrs...
    Unfortunately, that this the max threshold which you can set at the Biztalk Application Host and Registry key- MessagingReqRespTTL is no longer available post BizTalk Server 2010 release.

    You should consider optimizing the design here after.



    Rachit Sikroria (Microsoft Azure MVP)


    Thursday, December 22, 2016 2:28 PM
    Moderator

All replies


    1. Increase the Response Time out in the Isolated Host to “60” which is the max
    2. Add new DWord @ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc.3.0\MessagingReqRespTTL and set it to 300.

    Hi,

    After changing these settings you have to restart the Application Pool the Receive Location is running under for the changes to take effect.


    Rachit Sikroria (Microsoft Azure MVP)

    Thursday, December 22, 2016 2:43 AM
    Moderator
  • Hi

    The limit of "Response timeout in minutes" (which can be a max of 60 mins) will apply here. If you have made this value to 60, and are still seeing a timeout in 20mins, it means that the default is coming into play here.

    Make sure that you changed this setting in the correct Isolated Host, and restart the App Pool afterwards.


    Thanks Arindam

    Thursday, December 22, 2016 4:12 AM
    Moderator
  • I would first suggest to look at ur design.. Making the service caller wait for response for such a long time is bad.

    If ur process takes so long, break it into async calls. Return an ack as soon as ur biztalk process receives the request via the exposed service.

    After u r done with 50k+ processing, call something (best a service) on the caller end to notify that the processing is done.

    Have a unique identifier correlate these two for the source application. (Have a header with some requestID which the caller will send when sending the request. Use the same ID to notify the caller that this requestID processing is done)

    PS: Even if u increase it make it work under 60 mins, its highly likely that some time the process would be takign longer because of load reasons , network latency etc. 

    I would suggest to look for a better solution design.


    Pi_xel_xar

    Blog: My Blog

    BizTalkApplicationDeploymentTool: BizTalk Application Deployment Tool/

    Thursday, December 22, 2016 8:44 AM
    Answerer
  • Sorry forgot to mention after changing the time out to 60 on host I did restarted th apppool and it's now timing out at 60 min ... but I am looking for longer time-outs. More like 2 or 4 hrs...
    Thursday, December 22, 2016 11:52 AM
  • I am afraid that is not possible as far as I know with BizTalk Application Hosts.

    Really 60mins is a long time for HTTP, I would suggest that you refactor your app, so that the HTTP call is not blocked for more than 60mins.


    Thanks Arindam


    Thursday, December 22, 2016 12:19 PM
    Moderator
  • Sorry forgot to mention after changing the time out to 60 on host I did restarted th apppool and it's now timing out at 60 min ... but I am looking for longer time-outs. More like 2 or 4 hrs...
    Unfortunately, that this the max threshold which you can set at the Biztalk Application Host and Registry key- MessagingReqRespTTL is no longer available post BizTalk Server 2010 release.

    You should consider optimizing the design here after.



    Rachit Sikroria (Microsoft Azure MVP)


    Thursday, December 22, 2016 2:28 PM
    Moderator