Author |
Message
|
Biju |
Posted: Fri Apr 03, 2015 11:51 am Post subject: Oracle Middleware GateWay and WMQ - Message Duplication!!!!! |
|
|
 Acolyte
Joined: 03 Oct 2005 Posts: 71
|
Hello All,
We have a peculiar situation in one of our environments. An Oracle Middleware Gateway connects to WebSphere MQ to read messages. The read is successful and the message is reaching AQ. The problem here is the messages from WMQ are not read destructively but still the AQ gets the messages, then the transaction rolls back (tested by puttin about 100 messages at once and looked at the Queueu status - the count of current depth and uncommitted messages keeps changing) and MGW reads the message again and updates the AQ. In this process the partner applications gets the same messages multiple times and are calling out a duplication.
Have anyone of you encountered such a problem? Were you able to resolve it? If yes what should we look for to correct the issue?
Thanks & Regards |
|
Back to top |
|
 |
Gaya3 |
Posted: Fri Apr 03, 2015 1:16 pm Post subject: |
|
|
 Jedi
Joined: 12 Sep 2006 Posts: 2493 Location: Boston, US
|
why destructive reading is not happening _________________ Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Apr 03, 2015 6:08 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Every MQ app that does an MQGET should check the MQMD Backout Count on every message it gets. If it sees a value higher than expected, it needs to decide if its appropriate to continue processing that message.
Looks like your app is picking up messages, processes them to some degree but not 100%, rolls them back to the queue when the transaction is backed out (MQMD Backout count will increase) and then picking them up again. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
Biju |
Posted: Fri Apr 03, 2015 9:03 pm Post subject: |
|
|
 Acolyte
Joined: 03 Oct 2005 Posts: 71
|
Thank you for the responses.
@Gaya3 - if I knew why I wouldn't have posted this question .
Peter, The reading application is an Oracle product Middleware GateWay or Messaging GateWay. I am not much aware of the products internal functionality. We have a case opened with both Oracle and IBM.
We took a trace at MQ and see that the app connects gets, backsout and then commits. Oracle accepted it as a bug.
But the concerning behavious is: The same gateway when connected to a different Queue Manager everything works as expected. MGW connects to the WMQ and gets the messages off the Queue and there is no duplication. With the problematic Queue manager also, if we use the sample amqsget or amqsgetc the messages goes off the Queue. Its only when the MGW tries to read the problem happens.
Regards. |
|
Back to top |
|
 |
fjb_saper |
Posted: Sat Apr 04, 2015 9:18 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Biju wrote: |
Thank you for the responses.
@Gaya3 - if I knew why I wouldn't have posted this question .
Peter, The reading application is an Oracle product Middleware GateWay or Messaging GateWay. I am not much aware of the products internal functionality. We have a case opened with both Oracle and IBM.
We took a trace at MQ and see that the app connects gets, backsout and then commits. Oracle accepted it as a bug.
But the concerning behavious is: The same gateway when connected to a different Queue Manager everything works as expected. MGW connects to the WMQ and gets the messages off the Queue and there is no duplication. With the problematic Queue manager also, if we use the sample amqsget or amqsgetc the messages goes off the Queue. Its only when the MGW tries to read the problem happens.
Regards. |
May be your Oracle Gateway is misconfigured on this qmgr. Do you have all the additional queues the gateway requires to function properly defined?  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Biju |
Posted: Sat Apr 04, 2015 10:41 am Post subject: |
|
|
 Acolyte
Joined: 03 Oct 2005 Posts: 71
|
Hello fjb_saper,
Yes, all the Queue Managers in the other environment have similar setup including the Queue Names and channel names (except for the Queue manager name, host name and the port number) similar to that of the SIT environment where we have a problem.
Regards |
|
Back to top |
|
 |
bruce2359 |
Posted: Sat Apr 04, 2015 11:36 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Similar is not good enough.
If you have one misbehaving environment, look more closely there. Your gateway configuration must be identical for it to behave identically. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
fjb_saper |
Posted: Sat Apr 04, 2015 10:09 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
If memory serves you need 3 extra queues for use by the gateway only...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Biju |
Posted: Sun Apr 05, 2015 6:49 am Post subject: |
|
|
 Acolyte
Joined: 03 Oct 2005 Posts: 71
|
@bruce - The SAME gateway was used to test the behavior with all other environment Queue managers. And the script that was run by the DBA at the GateWay to connect to the Queue Managers were same except for the connection parameters.
@fjb_saper - I believe there are only two Queues needed by the gateway for inbound and outbound logs.
Regards |
|
Back to top |
|
 |
fjb_saper |
Posted: Sun Apr 05, 2015 8:21 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Biju wrote: |
@bruce - The SAME gateway was used to test the behavior with all other environment Queue managers. And the script that was run by the DBA at the GateWay to connect to the Queue Managers were same except for the connection parameters.
@fjb_saper - I believe there are only two Queues needed by the gateway for inbound and outbound logs.
Regards |
I thought that additional to the log queues you also needed to define an error queue for the gateway?  _________________ MQ & Broker admin |
|
Back to top |
|
 |
tczielke |
Posted: Sun Apr 05, 2015 8:32 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010 Posts: 941 Location: Illinois, USA
|
Biju wrote: |
@bruce - The SAME gateway was used to test the behavior with all other environment Queue managers. And the script that was run by the DBA at the GateWay to connect to the Queue Managers were same except for the connection parameters.
@fjb_saper - I believe there are only two Queues needed by the gateway for inbound and outbound logs.
Regards |
If your queue managers are 7.1 or higher, running that same Gateway test against the good and problematic queue manager with an Application Activity Trace running on each queue manager could be enlightening to what is going on to explain the differences. I prefer using the amqsactz program (source located on the Capitalware web site) to work with the AAT, as you can get a one line API trace to view. Also, the summary reports from amqsactz would be helpful here, as you could see very quickly any different reason codes, options, queues, etc. that are being found for the two different runs of this same gateway app against the two queue managers. _________________ Working with MQ since 2010. |
|
Back to top |
|
 |
Gaya3 |
Posted: Mon Apr 06, 2015 6:21 am Post subject: |
|
|
 Jedi
Joined: 12 Sep 2006 Posts: 2493 Location: Boston, US
|
this is not MQ problem we do have the similar set up its the target apps which is picking the messages has to be configured _________________ Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
Back to top |
|
 |
Biju |
Posted: Tue May 12, 2015 2:15 am Post subject: Issue of Duplication Resolved |
|
|
 Acolyte
Joined: 03 Oct 2005 Posts: 71
|
Hello All,
The duplication issue has been rectified. Action take were:
1. A clean up of the MGW with a script provided by Oracle (done by DBA).
2. Recreate the inbound and Outbound Log Queues which is used by the MGW with a different name.
3. Restart MGW services.
The suspected issue is more than one instance of MGW reading from the inbound and outbound log queues creating inconsistency in the MGW behavior.
Thank you all for your suggestions and assistance .
Regards,
Biju. |
|
Back to top |
|
 |
|