| Author |
Message
|
| souciance |
 Posted: Mon Mar 05, 2012 2:38 am Post subject: JMS auto reconnect using ccdt |
 |
|
Disciple
Joined: 29 Jun 2010
Posts: 169
|
Hello,
I have a MQ JMS setup with MQ 7.1 and two queue managers qm1 and qm2. I have created a connection factory with client connection that uses the ccdt tabel to route connection between two the queue managers in case one goes down.
I am using JMETER to send 10 000 messages to see the performance and stability. In the middle of the transmission I do an immediate shutdown on qm1 and I can see the connection is routed to qm2.
However, a lot of messages are lost due to the interrruption in the connection.
Is there a best practise for this kind of setup? Does the client need to implement retransmit code based on MQ reponse errors or are there MQ parmeters you can tweak so that the messsages don't get lost?
Thanks.
Moeed. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Mar 05, 2012 2:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Messages are never shared between separate queue managers.
They are only ever shared between instances of a single multi-instance queue manager.
Or between queue managers participating in a shared queue group - but this is only possible with queue managers that are all running on zOS.
So what you are observing is absolutely correct behavior. If QM 1 is down, all unprocessed messages on that qm are unavailable.
They are only LOST if you have made them NONPERSISTENT. |
|
| Back to top |
|
|
| souciance |
| Posted: Mon Mar 05, 2012 3:29 am Post subject: |
|
|
Disciple
Joined: 29 Jun 2010
Posts: 169
|
| Thanks mqjeff for the reply. I think I understand the process better now. But for the persistence part, is it sufficient for the MQ queues to be persistent, or does the client need to set mqmd parameters as well when sending the message? Thanks for the help. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Mar 05, 2012 3:31 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| souciance wrote: |
| the client need to set mqmd parameters as well when sending the message |
And, to be clear, nonpersistent messages are not 'lost'.
They are merely not retained, as you have specifically stated that they are allowed to be not retained. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 05, 2012 5:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| souciance wrote: |
| But for the persistence part, is it sufficient for the MQ queues to be persistent, or does the client need to set mqmd parameters as well when sending the message? |
As has been said many times on this forum, queues are not persistent. Messages are persistent; the value on the queue is a default.
There are many, many debates on here on the merits of setting message persistence inside the application v having all applications use the queue default. My summary of this debate is "it depends".
But if the message is set to be non-persistent then it's not a persistent message. If the message is persistent it's persistent. Nothing will enforce that the messages on a queue match the default persistence settting of a queue except in the special case of a persistent message on a temporary dynamic queue.
<plug>3rd party vendors, including the sponsor of this forum, manufacture products which can enforce this setting </plug>
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| souciance |
| Posted: Mon Mar 05, 2012 6:10 am Post subject: |
|
|
Disciple
Joined: 29 Jun 2010
Posts: 169
|
Yeah, it seems I will have to enforce message persistence but also put the jms destination to be persistent. Also when I added a connection name list to include both qm together with the cddt it managed to switch connection and maintain correct number of message...So I am happy  |
|
| Back to top |
|
|
| souciance |
| Posted: Wed Mar 07, 2012 5:33 am Post subject: |
|
|
Disciple
Joined: 29 Jun 2010
Posts: 169
|
Hi again..
I have noticed that as the ccdt table switches, the last message that was sent to QM1 is also sent to QM2, probably because it did not get an acknowledge. For instance instead of receiving 10000 messages between two queue managers I get 10001 messages.
Is there anyway from design and implementation perspective to assure that only one copy is sent? Thanks..
Souciance |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Mar 07, 2012 9:57 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If your 10,000th MQPUT got a successful return code, and the message was put OUTside of syncpoint, the message will be on the queue on QM1. Don't put it again once connected to QM2.
If your 10,000th MQPUT got a successful return code, and the message was put INside of syncpoint, and your MQCMIT got a successful return code, the message will be on the queue on QM1. Don't put it again once connected to QM2.
If your 10,000th MQPUT did NOT got a successful return code, and the message was put OUTside of syncpoint, the message will NOT be on the queue on QM1. DO put it again once connected to QM2.
If your 10,000th MQPUT DID get a successful return code, and the message was put INside of syncpoint, but your MQCMIT did NOT get a successful return code, the message will may or may NOT be on the queue on QM1. Up to your application and business to decide what to do once connected to QM2. The consumer app should be able to deal with duplicates in a perfect world and in this ambigious state the sender opts to send the 10,000th message again to QM2.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
