ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere MQ Java / JMS » JMS auto reconnect using ccdt

Post new topic  Reply to topic
 JMS auto reconnect using ccdt « View previous topic :: View next topic » 
Author Message
souciance
PostPosted: Mon Mar 05, 2012 2:38 am    Post subject: JMS auto reconnect using ccdt Reply with quote

Apprentice

Joined: 29 Jun 2010
Posts: 26

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
View user's profile Send private message
mqjeff
PostPosted: Mon Mar 05, 2012 2:51 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 13220

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
View user's profile Send private message
souciance
PostPosted: Mon Mar 05, 2012 3:29 am    Post subject: Reply with quote

Apprentice

Joined: 29 Jun 2010
Posts: 26

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
View user's profile Send private message
mqjeff
PostPosted: Mon Mar 05, 2012 3:31 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 13220

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
View user's profile Send private message
Vitor
PostPosted: Mon Mar 05, 2012 5:57 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 21193
Location: Ohio, 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
View user's profile Send private message
souciance
PostPosted: Mon Mar 05, 2012 6:10 am    Post subject: Reply with quote

Apprentice

Joined: 29 Jun 2010
Posts: 26

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
View user's profile Send private message
souciance
PostPosted: Wed Mar 07, 2012 5:33 am    Post subject: Reply with quote

Apprentice

Joined: 29 Jun 2010
Posts: 26

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
View user's profile Send private message
PeterPotkay
PostPosted: Wed Mar 07, 2012 9:57 am    Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 6869
Location: Hartford CT

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere MQ Java / JMS » JMS auto reconnect using ccdt
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.