| Author |
Message
|
| paulau |
 Posted: Thu Sep 26, 2019 7:20 pm Post subject: |
 |
|
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 |
|
 |
| HubertKleinmanns |
| Posted: Thu Sep 26, 2019 11:10 pm Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
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 |
|
|
| hughson |
| Posted: Fri Sep 27, 2019 1:33 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| divyadam |
| Posted: Fri Sep 27, 2019 3:25 am Post subject: |
|
|
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 |
|
|
| hughson |
| Posted: Fri Sep 27, 2019 1:38 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
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 |
|
|
| divyadam |
| Posted: Fri Sep 27, 2019 9:05 pm Post subject: |
|
|
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 |
|
|
| hughson |
| Posted: Fri Sep 27, 2019 10:24 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| divyadam |
| Posted: Mon Sep 30, 2019 2:54 pm Post subject: |
|
|
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 |
|
|
| hughson |
| Posted: Mon Sep 30, 2019 7:56 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| divyadam |
| Posted: Sun Oct 06, 2019 3:52 pm Post subject: |
|
|
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 |
|
|
| hughson |
| Posted: Mon Oct 07, 2019 1:28 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| PeterPotkay |
| Posted: Mon Oct 07, 2019 3:31 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
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 |
|
|
| divyadam |
| Posted: Mon Oct 07, 2019 2:08 pm Post subject: |
|
|
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 |
|
|
| HubertKleinmanns |
| Posted: Tue Oct 08, 2019 12:40 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
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 |
|
|
| Joseph88 |
| Posted: Mon Dec 09, 2019 1:23 am Post subject: |
|
|
Guest
|
| divyadam wrote: |
HERE IS THE CCDT definitions
CHANNEL(QMGR1 CHL )
CHLTYPE(CLNTCONN)
AFFINITY(NONE)
CLNTWGHT(49)
COMPHDR(NONE)
CONNAME(<QMGR1 VIP> <PORT>)
DESCR( )
LOCALADDR( )
MAXMSGL(10485760)
QMNAME(ABCD)
SSLCIPH(TLS_RSA_WITHAES_256_CBC_SHA256)
SSLPEER(CN=QMGR1)
TRPTYPE(TCP)
CHANNEL(QMGR2 CHL )
CHLTYPE(CLNTCONN)
AFFINITY(NONE)
CLNTWGHT(49)
Rachat de crédit meilleur taux crédit
COMPHDR(NONE)
CONNAME(<QMGR2 VIP> <PORT>)
DESCR( )
LOCALADDR( )
MAXMSGL(10485760)
QMNAME(ABCD)
SSLCIPH(TLS_RSA_WITHAES_256_CBC_SHA256)
SSLPEER(CN=QMGR2)
TRPTYPE(TCP)
CHANNEL(QMGR3 CHL )
CHLTYPE(CLNTCONN)
AFFINITY(NONE)
CLNTWGHT(1)
COMPHDR(NONE)
CONNAME(<QMGR3 VIP> <PORT>)
DESCR( )
LOCALADDR( )
MAXMSGL(10485760)
QMNAME(ABCD)
SSLCIPH(TLS_RSA_WITHAES_256_CBC_SHA256)
SSLPEER(CN=QMGR3)
TRPTYPE(TCP)
CHANNEL(QMGR4 CHL )
CHLTYPE(CLNTCONN)
AFFINITY(NONE)
CLNTWGHT(1)
COMPHDR(NONE)
CONNAME(<QMGR4 VIP> <PORT>)
DESCR( )
LOCALADDR( )
MAXMSGL(10485760)
QMNAME(ABCD)
SSLCIPH(TLS_RSA_WITHAES_256_CBC_SHA256)
SSLPEER(CN=QMGR4)
TRPTYPE(TCP)
*** the Idea is to have QMGR1 and QMGR2 in datacenter1 are primary andQMGR3 and QMGR4 in DataCenter2 are backup but actively running on DataCenter2. When in issue JMS connections should failover to QMGRs running in DataCenter2.
|
Hi, I did not know that these are all definitions of CDDT
thank you |
|
| Back to top |
|
|
|
|
