none
MQSC (MQ Base-Client) Receive Adapter Behaviour when stopping Host Instance - Duplication Issue RRS feed

  • Question

  • I have set up a Receive Location on a MQ Series Queue using the MQSC Adapter (non-transactional MQ Base-Client). The Messages get collected and are not visible on the Queue anymore. A simple Sendport with subscription to any message coming through mentioned Receiveport writes collected Messages to the Filesystem.

    Everything looks fine:
     - No more Messages in Queue or MsgBox, Messages have been written to final Destination, no Error Messages or Warnings in the event logs.

    But:
     - If the Hostinstance which MQSC Adapter is associated with is stopped all Messages ever (as long as Hostinstace was running) collected from Queue "reappear". They have the original Putdate. So I'd get duplication of the Messages.

    It seems as if the Adapter never "commits" the deletion of the Messages on the Queue but as I only know too little about MQ this is a guess.

    The Documentation to the Adapter states:
    " You can also configure the MQSC Adapter to support non-transactional messaging when integrating with MQSeries Queues. For this, the MQSC Adapter uses the WebSphere MQ Base-Client. In this case, the adapter only guarantees that no messages are lost. Duplication of messages can occur under failure conditions. Therefore, you should use this configuration option only if the application that is consuming the message from BizTalk Server or MQSeries Queues can handle duplication of messages. To prevent loss of messages, the MQSC adapter first does an MQGET with a browse lock by setting the MQGMO_BROWSE_FIRST and MQGMO_LOCK options. The adapter then submits the message to BizTalk Server. If the submitted message to BizTalk Server is successful, the adapter does a destructive MQGet with MQGMO_MSG_UNDER_CURSOR option. If a failure occurs while submitting the message to BizTalk Server, the adapter does an MQGet with MQGMO_UNLOCK so that additional operations can be performed on the message"

    As no Errors come up I  presume that all  above should have worked? But it seems as if the Adapter either doesn't "understand" that the submission of the messages to BTS was successful or it doesn't send the destructive MQGet with MQGMO_MSG_UNDER_CURSOR option  or if it does not successfully.

    Is this a Problem of the Adapter or have I used wrong setttings? Or should some Queue Settings be revised (I have no control over the MQ Manager)? I cannot believe that this behaviour should be normal as the restart of an Hostinstance does not necessarily constitute a failure condition, especially if no Messages are in msgbox at that time

    Help or Tips very much apreciated!

    Wednesday, May 7, 2008 4:20 PM

Answers

  • I recently assisted a customer with this problem and there is a hotfix for this which should help you in your case as well.

     

    http://support.microsoft.com/kb/932523

     

    The problem is that when messages are put to a distributed queue manager, the default behavior is for messages to be put outside of Synchpoint. However with a z/OS queue manager the default behavior is for messages to be put within Synchpoint (inside of a unit of work). The Get() should use MQGMO_NO_SYNCPOINT option since messages outside of Synchpoint do not need to be committed.  This behavior was changed with 932523 so it should apply to your problem as well.

     

    Good luck
    Friday, August 29, 2008 4:00 PM

All replies

  • I recently assisted a customer with this problem and there is a hotfix for this which should help you in your case as well.

     

    http://support.microsoft.com/kb/932523

     

    The problem is that when messages are put to a distributed queue manager, the default behavior is for messages to be put outside of Synchpoint. However with a z/OS queue manager the default behavior is for messages to be put within Synchpoint (inside of a unit of work). The Get() should use MQGMO_NO_SYNCPOINT option since messages outside of Synchpoint do not need to be committed.  This behavior was changed with 932523 so it should apply to your problem as well.

     

    Good luck
    Friday, August 29, 2008 4:00 PM
  • Thank you for your help, showing me the kb Article and your explanation!

    I can't believe I wasn't able to find the kb Article - it surely does seem to apply to my problem.

     

    I shall try the hotfix and shall post here the outcome!

    Monday, September 1, 2008 9:20 AM
  • Thanks again for pointing to the hotfix. It has been the solution to my problem.

     

    Friday, September 12, 2008 1:52 PM