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 IndexIBM MQ Java / JMSJMS Auto reconnect with CCDT that's has Multiple QManagers

Post new topicReply to topic Goto page Previous  1, 2
JMS Auto reconnect with CCDT that's has Multiple QManagers View previous topic :: View next topic
Author Message
paulau
PostPosted: Thu Sep 26, 2019 7:20 pm Post subject: Reply with quote

Novice

Joined: 06 Feb 2017
Posts: 19

When your Java application code is making a call to MQ, I would expect that the JMS layer knows instantly that the connection is down and starts the reconnect process immediately.

Your comment about default delays should only be applicable if there are no calls during that delay.
Back to top
View user's profile Send private message
HubertKleinmanns
PostPosted: Thu Sep 26, 2019 11:10 pm Post subject: Reply with quote

Yatiri

Joined: 24 Feb 2004
Posts: 696
Location: Germany

divyadam wrote:
HI Yatiri

Are you talking with me? My Name is HubertKleinmanns, Yatiri is only a rank in this Forum.

divyadam wrote:
with "MQConnectionFactory.setClientReconnectOptions()" if I have to use CCDT should I use "WMQConstants.WMQ_CLIENT_RECONNECT_AS_DEF" (reconnect behaviour set by channel attribute)"?

I always recomment developers, not to trust administrators, that they are setting the correct attributes. So if possible I would always set such attributes in the application (same for persistency, priority etc.).

divyadam wrote:
also what does 'int' value with 'options'

I don't want to set "SHARECNV" on ServerConn cahannel cause it would piggy back on the previous connection I believe.
I was JMC connections to be non-persistent.

A value of 1 or higher for SHARECNV is a prerequisite for reconnections.
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
hughson
PostPosted: Fri Sep 27, 2019 1:33 am Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1253
Location: Bay of Plenty, New Zealand

divyadam wrote:
we don't have the reconnect option. was told the QueueConnectionFactory method has default reconnect feature.

By this I assume you mean RECONNECT_AS_DEF as you show below.

divyadam wrote:
HI Yatiri
with "MQConnectionFactory.setClientReconnectOptions()" if I have to use CCDT should I use "WMQConstants.WMQ_CLIENT_RECONNECT_AS_DEF" (reconnect behaviour set by channel attribute)"?

also what does 'int' value with 'options'

Sorry I don't understand what you mean about int value with options? Can you be more specific - show where you are seeing this?

divyadam wrote:
I don't want to set "SHARECNV" on ServerConn cahannel cause it would piggy back on the previous connection I believe.
I was JMC connections to be non-persistent.

A SHARECNV value of 1 will not do any piggy-backing. Ensure you have SHARECNV(1) and not SHARECNV(0).
divyadam wrote:
Also
Application is taking almost 300 seconds to realize the QMGRs in DataCenter1 are down. that's the default OS timeout. we are planning to Implement JMS TCP timeout as one of the java option that would speed up the QMGR down acknowledgement.

Is there an option at MQConnectionFactory that I can make use of to terminate connection initiation earlier and force the JMS connection to do CCDT lookup?

This is probably because you are using default values for HBINT of 300 seconds. Suggest you set it lower. This has a very strong impact on the length of time it takes for the channel to notice the socket is 'gone'. Remember you must set it at both sides in order to reduce it. In the CCDT and also on the SVRCONN definition on the queue managers.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
divyadam
PostPosted: Fri Sep 27, 2019 3:25 am Post subject: Reply with quote

Novice

Joined: 03 Oct 2018
Posts: 22

Code:

divyadam wrote:
we don't have the reconnect option. was told the QueueConnectionFactory method has default reconnect feature.

By this I assume you mean RECONNECT_AS_DEF as you show below.


sorry for the confusion; we don't have reconnect defined in our code, our developer just assumed the reconnects will be handled by default.

Code:

divyadam wrote:
HI Yatiri
with "MQConnectionFactory.setClientReconnectOptions()" if I have to use CCDT should I use "WMQConstants.WMQ_CLIENT_RECONNECT_AS_DEF" (reconnect behaviour set by channel attribute)"?

also what does 'int' value with 'options'

Sorry I don't understand what you mean about int value with options? Can you be more specific - show where you are seeing this?


I looked up IBM documentation on WMQ_CLIENT_RECONNECT_AS_DEF and it has "int and timeout" was referring to that
Code:

setClientReconnectTimeout( int timeout)
throws javax.jms.JMSException

https://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.javadoc.doc/WMQJMSClasses/com/ibm/mq/jms/MQConnectionFactory.html#setClientReconnectTimeout_int_

Code:

divyadam wrote:
Also
Application is taking almost 300 seconds to realize the QMGRs in DataCenter1 are down. that's the default OS timeout. we are planning to Implement JMS TCP timeout as one of the java option that would speed up the QMGR down acknowledgement.

Is there an option at MQConnectionFactory that I can make use of to terminate connection initiation earlier and force the JMS connection to do CCDT lookup?

This is probably because you are using default values for HBINT of 300 seconds. Suggest you set it lower. This has a very strong impact on the length of time it takes for the channel to notice the socket is 'gone'. Remember you must set it at both sides in order to reduce it. In the CCDT and also on the SVRCONN definition on the queue managers.


what is the option in CCDT definition and SVRCONN to over write the default heart beat interval

Code:

divyadam wrote:
I don't want to set "SHARECNV" on ServerConn cahannel cause it would piggy back on the previous connection I believe.
I was JMC connections to be non-persistent.

A SHARECNV value of 1 will not do any piggy-backing. Ensure you have SHARECNV(1) and not SHARECNV(0).

thanks for clarifying that, make sure we have it set it right.
Back to top
View user's profile Send private message
hughson
PostPosted: Fri Sep 27, 2019 1:38 pm Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1253
Location: Bay of Plenty, New Zealand

divyadam wrote:
I looked up IBM documentation on WMQ_CLIENT_RECONNECT_AS_DEF and it has "int and timeout" was referring to that
Code:

setClientReconnectTimeout( int timeout)
throws javax.jms.JMSException

https://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.javadoc.doc/WMQJMSClasses/com/ibm/mq/jms/MQConnectionFactory.html#setClientReconnectTimeout_int_


This just tells you that the value you must write inside the brackets is an integer ('int') and that it represents a timeout which is described in the explanatory text as being in seconds.

divyadam wrote:
Code:

divyadam wrote:
Also
Application is taking almost 300 seconds to realize the QMGRs in DataCenter1 are down. that's the default OS timeout. we are planning to Implement JMS TCP timeout as one of the java option that would speed up the QMGR down acknowledgement.

Is there an option at MQConnectionFactory that I can make use of to terminate connection initiation earlier and force the JMS connection to do CCDT lookup?

This is probably because you are using default values for HBINT of 300 seconds. Suggest you set it lower. This has a very strong impact on the length of time it takes for the channel to notice the socket is 'gone'. Remember you must set it at both sides in order to reduce it. In the CCDT and also on the SVRCONN definition on the queue managers.


what is the option in CCDT definition and SVRCONN to over write the default heart beat interval


When editing the CCDT:-
Code:
ALTER CHANNEL(channel-name) CHLTYPE(CLNTCONN) HBINT(60)


When changing config on the queue manager:-
Code:
ALTER CHANNEL(channel-name) CHLTYPE(SVRCONN) HBINT(60)


Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
divyadam
PostPosted: Fri Sep 27, 2019 9:05 pm Post subject: Reply with quote

Novice

Joined: 03 Oct 2018
Posts: 22

Code:
 
setClientReconnectOptions

public void setClientReconnectOptions( int options)
throws javax.jms.JMSException
Specifies the client reconnect options for new connections created by this factory. These can be found in WMQConstants, and will be one of:
WMQ_CLIENT_RECONNECT_AS_DEF (default) - Use the value specified in the mqclient.ini file. This is set using the 'DefRecon' property within the 'Channels' stanza. It can be set to one of:
YES - behaves as the WMQ_CLIENT_RECONNECT option
NO - default. Does not specify any reconnection options
QMGR - behaves as the WMQ_CLIENT_RECONNECT_Q_MGR option
DISABLED - behaves as the WMQ_CLIENT_RECONNECT_DISABLED option
WMQ_CLIENT_RECONNECT - Reconnect to the any of the queue managers specified in the connection name list
WMQ_CLIENT_RECONNECT_Q_MGR - Reconnect to the same queue manager we were originally connected to. This will throw MQRC_RECONNECT_QMID_MISMATCH if the queue manager it tries to connect to (specified in the connection name list) has a different QMID to the queue manager originally connected to.
WMQ_CLIENT_RECONNECT_DISABLED - Reconnection is disabled

which option should I use with CCDT implementation?
the "connection name list" is the CCDT; that's been given here?
Back to top
View user's profile Send private message
hughson
PostPosted: Fri Sep 27, 2019 10:24 pm Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1253
Location: Bay of Plenty, New Zealand

divyadam wrote:
which option should I use with CCDT implementation?

Use WMQ_CLIENT_RECONNECT, since you are demonstrably not going to work with WMQ_CLIENT_RECONNECT_Q_MGR

divyadam wrote:
the "connection name list" is the CCDT; that's been given here?

In your setup, the CCDT is the equivalent of the connection name list in the description.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
divyadam
PostPosted: Mon Sep 30, 2019 2:54 pm Post subject: Reply with quote

Novice

Joined: 03 Oct 2018
Posts: 22

One more question on setting up HBINT; when we reached out to IBM they asked us to implement JAVA_JMS_TCP timeout at application level.
Code:

com.ibm.mq.cfg.TCP.Connect_Timeout=10


which one is better the HBINT or the java parameter.
Back to top
View user's profile Send private message
hughson
PostPosted: Mon Sep 30, 2019 7:56 pm Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1253
Location: Bay of Plenty, New Zealand

divyadam wrote:
One more question on setting up HBINT; when we reached out to IBM they asked us to implement JAVA_JMS_TCP timeout at application level.
Code:

com.ibm.mq.cfg.TCP.Connect_Timeout=10


which one is better the HBINT or the java parameter.


Neither one is better than the other.

Heartbeat interval kicks in once the connection is already running, and helps to speed up detection of a broken socket that was previously good. The heartbeat interval is used to determine how long to wait for the other side to send something before assuming the connection has gone bad. This will help when switching away from a queue manager you were previously connected to.

TCP.Connect_Timeout is for when an initial connect is taking a long time which can be the case if an IP address is no longer in existence, or perhaps even if a machine is currently unavailable. This will help when trying to connect to each entry in the CCDT in turn, to find one that is available.

So set both.

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
divyadam
PostPosted: Sun Oct 06, 2019 3:52 pm Post subject: Reply with quote

Novice

Joined: 03 Oct 2018
Posts: 22

one more help
How do I test this. in production I can't Bring down Manager or the listener. I have the updated code ready validated in QA/PTE but the setup is not same as in Production. need to test this in Production where it has 2 datacenter. the whole purpose of this effort is to make it right and be able to test this flow.

Need help to test this config with out actually shutting down Q-Manager/ Listener.
Back to top
View user's profile Send private message
hughson
PostPosted: Mon Oct 07, 2019 1:28 am Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1253
Location: Bay of Plenty, New Zealand

divyadam wrote:
Need help to test this config with out actually shutting down Q-Manager/ Listener.

Why not start a second listener that only you are using and then you can bring that listener down without affecting others?
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
PeterPotkay
PostPosted: Mon Oct 07, 2019 3:31 am Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7557

Stop your app's dedicated SVRCONN channel to test. Leave the queue manager, its listener and all other channels for other applications running.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
divyadam
PostPosted: Mon Oct 07, 2019 2:08 pm Post subject: Reply with quote

Novice

Joined: 03 Oct 2018
Posts: 22

thanks For the Inputs and Ideas on testing this out.

I can't have additional listener cause it requires a new CCDT and new Listener for each application/Q-manager that we run in Production and intend to test.

Also
if I opt for shutting down the SVRCONN channel, would the JMS/MQ exception return codes be same with Stopping a SVRCONN channel VS shutting down listener?

Sorry 😐; I know I am confused. the real issue is; our non-production is no match for production and we have seen the failover worked in non-production where we have all Q-Managers in one datacenter. where as in Production we have Q-managers across multiple DataCenters and that where we ran in to issues and have opened up this thread for help.

Will try to shutdown the SVRCONN and see if that prompts the reconnection. in the mean time I appreciate all the thoughts.
Back to top
View user's profile Send private message
HubertKleinmanns
PostPosted: Tue Oct 08, 2019 12:40 am Post subject: Reply with quote

Yatiri

Joined: 24 Feb 2004
Posts: 696
Location: Germany

divyadam wrote:
new Listener for each application/Q-manager that we run in Production and intend to test.

A second listener is only an additional fdefinition on the QMgr, The CCDT can be directly edited with "runmqsc -n". So it is not a big deal, to start a second listener and replace the CCDT for e specific application you want to test with.

divyadam wrote:
Also
if I opt for shutting down the SVRCONN channel, would the JMS/MQ exception return codes be same with Stopping a SVRCONN channel VS shutting down listener?

Shutting down (stopping) the listener doesn't stop any active channel instance. It just prevents the opening of new channel instances.

divyadam wrote:
Sorry 😐; I know I am confused. the real issue is; our non-production is no match for production

I agree, that's the real issue .

divyadam wrote:
and we have seen the failover worked in non-production where we have all Q-Managers in one datacenter. where as in Production we have Q-managers across multiple DataCenters and that where we ran in to issues and have opened up this thread for help.

MQ doesn't care about locating QMgrs in one DC or spreading these over more DCs. The only thing you have to care about are networking and firewall issues. This could be tested without MQ (e. g. "nc" or "netcat").

divyadam wrote:
Will try to shutdown the SVRCONN and see if that prompts the reconnection. in the mean time I appreciate all the thoughts.

I think, you even don't need to set up a second listener for testing the reconnect feature. But you need a separate channel definition. Then you could stop the SVRCONN channel on the QMgr - without affecting other applications.
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:
Post new topicReply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum IndexIBM MQ Java / JMSJMS Auto reconnect with CCDT that's has Multiple QManagers
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.