locked
Request-response receive port throws message routing error RRS feed

  • Question

  • I am getting the below error frequently in my production environment:

    A response message for two-way receive port "xxx_SendPort" is being suspended as the messaging engine could not correlate the response to an existing request message. This usually happens when the host process has been recycled. MessageId: {76F39141-CCC2-448D-A7A3-16577F98B361} InstanceID: {859DE9C2-6AFF-4814-BF94-DA3700073A01} - maybe a known issue, see KB 979095

    I have looked into the KB article mentioned but the hot fix is just for BizTalk Server 2006. Is there any workaround for this?
    Or Microsoft has released some hot fix for this error for BizTalk Server 2013?

    Thursday, June 30, 2016 5:43 AM

Answers

  • Hi Pratibha

    So, the flow is 2 way ReceivePort -> 2-way SendPort -> SendPort response sent back to first 2 way ReceivePort. Is that correct?

    You need to check first if the Receive Location's Host Instance is getting recycled/crashing while the SendPort is executing. You can check the System eventlogs on your BizTalk servers to confirm this. Also, how often is the error happening? Are the majority of the calls succeeding? Can you confirm this from Admin Console?

    Now, CU3 may/may not be relevant in your case as the reported bug is from 2006 R2 - chances are minimal that it still exists in 2013. But you should apply the CU as a best practice - you can check in the install log that the CU installer creates for possible errors.


    Thanks Arindam

    • Proposed as answer by Angie Xu Sunday, July 10, 2016 7:33 AM
    • Marked as answer by Angie Xu Monday, July 11, 2016 2:19 AM
    Thursday, June 30, 2016 10:12 AM
    Moderator

All replies

  • Hi Pratibha

    This means that by the time when the response message is being delivered to the 2-way ReceivePort instance, the ReceivePort instance is no longer in memory/active. This may happen if the Receive Location Host Instance got restarted/crashed after the request message was received over this 2-way ReceivePort instance.

    Can you check in System EvenLogs for any such entry?

    Make sure you have the latest CU for BizTalk 2013.

    Also, can you briefly explain the whole flow - what happens to the message after it is received by the 2-way ReceivePort? Also, how does the response go back to the same 2-way ReceivePort? Are you manipulating any context proeprties like BTS.EpmRRCorrelationToken in your code?


    Thanks Arindam


    Thursday, June 30, 2016 5:59 AM
    Moderator
  • Hi Pratibha,

    Well after going through the KB I also did not find out if it is applicable to 2013 or not. But,

    I agree with Arindam has said,

    First of all collect the following information from your production environment.

    1) What is the latest Cumulative Update you have installed on the environment.

    2) Run the MBV tool it should tell you which CU you need to install(iut points to the latest one)

    3) Collect the event log for the whole duration for which this issue occurred.

    MBV is very powerful tool which will let us know the issues with the PROD environment.

    Also I would suggest collecting the Performance Counters for the host and orchestration to analyse what really is going on.

    The way forward to resolution is the through the analysis of the collected information.

    Regards,


    Mandar Dharmadhikari

    Thursday, June 30, 2016 6:42 AM
    Moderator
  • One of the reasons for routing failures in request-response ports is when you've published orchestrations as web services and the orchestration execution time is NOT explicitly set in the web.config. The default for this happens to be 110 seconds and if the orchestration takes longer than that then IIS breaks connection. In this scenario the subscription that was created to auto-correlate the response gets deleted and thus the error. In the web.config of this service add the <httpRuntime executionTimeout="600" /> - implying 600 seconds ~ 10 minutes and see if this error stops...

    Regards.

    Thursday, June 30, 2016 6:58 AM
  • Hi,

    We are not using orchestration, the service is published as schema as service.
    Timeout is set to 15 mins.
    Not manipulating any context property. Only Bts.ReceivePortName is used in filter.

    We have installed CU3 but it didnt got installed successfully on all servers. It showed some upgrade patch is not found or already modified error. We have planned to install CU3 and CU4 soon. Will monitor and then update.

    Can anyone suggest why CU3 didn't got installed successfully on soem servers?

    Any help is appreciated. 

    Thursday, June 30, 2016 9:25 AM
  • Hi Pratibha,

    It will be a shot in the dark to guess why the CU3 was not installed on some servers without looking at the log file of the installation. If you analyze the logs you will find your answer in there. The log will definetly contain the answer. I know it is not possible to share the prod log file so just find out the error and post it here in a generic way so that we can help you out

    Regards,


    Mandar Dharmadhikari

    Thursday, June 30, 2016 9:31 AM
    Moderator
  • Hi Pratibha

    So, the flow is 2 way ReceivePort -> 2-way SendPort -> SendPort response sent back to first 2 way ReceivePort. Is that correct?

    You need to check first if the Receive Location's Host Instance is getting recycled/crashing while the SendPort is executing. You can check the System eventlogs on your BizTalk servers to confirm this. Also, how often is the error happening? Are the majority of the calls succeeding? Can you confirm this from Admin Console?

    Now, CU3 may/may not be relevant in your case as the reported bug is from 2006 R2 - chances are minimal that it still exists in 2013. But you should apply the CU as a best practice - you can check in the install log that the CU installer creates for possible errors.


    Thanks Arindam

    • Proposed as answer by Angie Xu Sunday, July 10, 2016 7:33 AM
    • Marked as answer by Angie Xu Monday, July 11, 2016 2:19 AM
    Thursday, June 30, 2016 10:12 AM
    Moderator