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 » General IBM MQ Support » JBOSS application parameters for connection to MQ

Post new topic  Reply to topic Goto page 1, 2  Next
 JBOSS application parameters for connection to MQ « View previous topic :: View next topic » 
Author Message
vicks_mq
PostPosted: Wed Apr 24, 2019 9:06 am    Post subject: JBOSS application parameters for connection to MQ Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

I am seeing a 2009 connection broken error from our JBOSS to MQ in the JBOSS logs and also following MQ connection parameters are being printed.
Do you see anything wrong with these parameters?

com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow@66c7b0f6
2019-04-23 13:07:09,223 ERROR [stderr] (JMSCCThreadPoolWorker-61) | inSyncpoint :- false
2019-04-23 13:07:09,223 ERROR [stderr] (JMSCCThreadPoolWorker-61) | queueManagerName :- ABCSIT
2019-04-23 13:07:09,223 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_ACKNOWLEDGE_MODE :- 1
2019-04-23 13:07:09,223 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_ADMIN_OBJECT_TYPE :- 20
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_ASYNC_EXCEPTIONS :- -1
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_CLIENT_ID :- <null>
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_CONNECTION_TYPE :- 1
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_CONNECTION_TYPE_NAME :- com.ibm.msg.client.wmq
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_OBJECT_IDENTITY :- 137902373
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_PASSWORD :- ********
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_RTT_DIRECT_AUTH :- 0
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_RTT_PROXY_HOSTNAME :- <null>
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_RTT_PROXY_PORT :- 443
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_TRANSACTED :- false
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_USERID :- mqford
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_BROKER_CC_SUBQ :- SYSTEM.JMS.ND.CC.SUBSCRIBER.QUEUE
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_BROKER_CONTROLQ :- SYSTEM.BROKER.CONTROL.QUEUE
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_BROKER_PUBQ :- SYSTEM.BROKER.DEFAULT.STREAM
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_BROKER_QMGR :-
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_BROKER_SUBQ :- SYSTEM.JMS.ND.SUBSCRIBER.QUEUE
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_CCDTURL :- <null>
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_CF_DESCRIPTION :- <null>
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_CHANNEL :- FORD.NUM.TO.ABCSIT
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_CLEANUP_INTERVAL :- 3600000
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_CLEANUP_LEVEL :- 1
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_CLIENT_RECONNECT_OPTIONS :- 33554432
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_CLIENT_RECONNECT_TIMEOUT :- 1800
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_CLONE_SUPPORT :- 0
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_CONNECTION_MODE :- 1
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_CONNECTION_NAME_LIST_INT :- ABCSIT.XYZ.US(1416)
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_CONNECTION_TAG :- [B@1406ee6d
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_CONNECT_OPTIONS :- 0
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_HEADER_COMP :- NONE
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_LOCAL_ADDRESS :- <null>
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_MAP_NAME_STYLE :- true
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_MAX_BUFFER_SIZE :- 1000
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_MESSAGE_RETENTION :- 1
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_MESSAGE_SELECTION :- 0
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_MSG_BATCH_SIZE :- 10
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_MSG_COMP :- NONE
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_OPT_PUB :- false
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_OUTCOME_NOTIFICATION :- true
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_POLLING_INTERVAL :- 5000
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_PROCESS_DURATION :- 0
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_PROVIDER_VERSION :- 7
2019-04-23 13:07:09,225 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_PUB_ACK_INTERVAL :- 25
2019-04-23 13:07:09,225 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_QMGR_CCSID :- 819
2019-04-23 13:07:09,225 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_QUEUE_MANAGER :- ABCSIT
2019-04-23 13:07:09,225 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_RECEIVE_EXIT :- <null>
2019-04-23 13:07:09,225 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_RECEIVE_EXIT_INIT :- <null>
2019-04-23 13:07:09,225 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_RECEIVE_ISOLATION :- 0
2019-04-23 13:07:09,225 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_REMOTE_QMGR_QSGNAME :- <null>
2019-04-23 13:07:09,225 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_RESCAN_INTERVAL :- 5000
2019-04-23 13:07:09,225 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_RESOLVED_QUEUE_MANAGER :- ABCSIT
2019-04-23 13:07:09,225 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_RESOLVED_QUEUE_MANAGER_ID :-
Back to top
View user's profile Send private message
vicks_mq
PostPosted: Wed Apr 24, 2019 9:08 am    Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

Corresponding error in QMGR logs

----- amqrccca.c : 1131 -------------------------------------------------------
04/23/19 13:07:19 - Process(1339035.32167) User(mqsystem) Program(amqrmppa)
Host(MQXYZ00AA) Installation(MQAppliance)
VRMF(9.1.0.0) QMgr(ABCSIT)
Time(2019-04-23T17:07:19.190Z)
RemoteHost(11.12.133.144)
CommentInsert1(FORD.NUM.TO.ABCSIT)
CommentInsert2(11.12.133.144)
CommentInsert3(select() [TIMEOUT] 65 seconds)

AMQ9271E: Channel 'FORD.NUM.TO.ABCSIT' timed out.

EXPLANATION:
A timeout occurred while waiting to receive from the other end of channel
'FORD.NUM.TO.ABCSIT'. The address of the remote end of the connection was
'11.12.133.144'.
ACTION:
The return code from the select() [TIMEOUT] 65 seconds call was 0 (X'0').
Record these values and tell the systems administrator.
----- amqccita.c : 4779 -------------------------------------------------------
04/23/19 13:07:19 - Process(1339035.32167) User(mqsystem) Program(amqrmppa)
Host(MQXYZ00AA) Installation(MQAppliance)
VRMF(9.1.0.0) QMgr(ABCSIT)
Time(2019-04-23T17:07:19.190Z)
RemoteHost(11.12.133.144)
CommentInsert1(FORD.NUM.TO.ABCSIT)
CommentInsert2(1339035)
CommentInsert3(11.12.133.144)

AMQ9999E: Channel 'FORD.NUM.TO.ABCSIT' to host '11.12.133.144' ended
abnormally.

EXPLANATION:
The channel program running under process ID 1339035 for channel
'FORD.NUM.TO.ABCSIT' ended abnormally. The host name is '11.12.133.144'; in
some cases the host name cannot be determined and so is shown as '????'.
ACTION:
Look at previous error messages for the channel program in the error logs to
determine the cause of the failure. Note that this message can be excluded
completely or suppressed by tuning the "ExcludeMessage" or "SuppressMessage"
attributes under the "QMErrorLog" stanza in qm.ini. Further information can be
found in the System Administration Guide.
Back to top
View user's profile Send private message
Vitor
PostPosted: Wed Apr 24, 2019 9:17 am    Post subject: Re: JBOSS application parameters for connection to MQ Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

vicks_mq wrote:
I am seeing a 2009 connection broken error from our JBOSS to MQ in the JBOSS logs and also following MQ connection


Why do you assume the parameters are incorrect, if the connection is being made correctly? The connection described by these parameters is being broken after these parameters have been used to connect.

It's possible that the connection has been broken by a firewall that decides your connection has been idle for too long (where "idle" and "too long"
are site configurable)

It's possible that the queue manager reached the maximum number of connections and started forcibly disconnecting earlier connectors to make room.

It's possible that something was doing a port scan on your network and threw you out while it was scanning the MQ.

Other reasons are possible. My vote goes to firewall, based on the timeout message. I don't consider that conclusive evidence, and would not be surprised if it turned out to be something else.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
vicks_mq
PostPosted: Wed Apr 24, 2019 9:24 am    Post subject: Re: JBOSS application parameters for connection to MQ Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

Vitor wrote:
vicks_mq wrote:
I am seeing a 2009 connection broken error from our JBOSS to MQ in the JBOSS logs and also following MQ connection


Why do you assume the parameters are incorrect, if the connection is being made correctly? The connection described by these parameters is being broken after these parameters have been used to connect.

It's possible that the connection has been broken by a firewall that decides your connection has been idle for too long (where "idle" and "too long"
are site configurable)

It's possible that the queue manager reached the maximum number of connections and started forcibly disconnecting earlier connectors to make room.

It's possible that something was doing a port scan on your network and threw you out while it was scanning the MQ.

Other reasons are possible. My vote goes to firewall, based on the timeout message. I don't consider that conclusive evidence, and would not be surprised if it turned out to be something else.


Hi Vitor, thanks for the reply. Firewall is not the issue, we checked with network team and their logs.
Queue manager reaching maximum connections is also seems not possible as this error came when the application just had one transaction the whole day. (It is a test environment and only 1 transaction was submitted by the application).

Our QM.ini Stanza is below -
Channels:
MaxChannels=999999999 # Unlimited, use MAXINST on channel
MaxActiveChannels=999999999 # Unlimited, use MAXINST on channel
MQIBindType=FASTPATH # FASTPATH connections for channels
ChlauthEarlyAdopt=YES # Evaluate CONNAUTH before CHLAUTH

the channel in question - FORD.NUM.TO.ABCSIT has following parameters

Maximum Instances - 100, Max Instances per client - 100,
SHARECNV - 1, DISCINT - 3600 , KAINT - AUTO
Back to top
View user's profile Send private message
Vitor
PostPosted: Wed Apr 24, 2019 9:30 am    Post subject: Re: JBOSS application parameters for connection to MQ Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

vicks_mq wrote:
Firewall is not the issue, we checked with network team and their logs.
Queue manager reaching maximum connections is also seems not possible as this error came when the application just had one transaction the whole day. (It is a test environment and only 1 transaction was submitted by the application).


Most of this information would have been helpful in your original post.

So let's see if I have this right. This connection had been idle for an extended period of time (unless you got this error right after your one transaction?). The JBoss & MQ platforms were sitting there, minding their own business, when this error turned up out of the blue.

But it's not a network error because nothing logged closing what most network components would consider to be an idle connection. Does the log the network team looked at even contain that kind of message? It's not an error by a lot of definitions, it's housekeeping.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
vicks_mq
PostPosted: Wed Apr 24, 2019 10:03 am    Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

Hi Vitor, thank you for reply. The last transaction which was also successful happened around 12:37PM and then after that all of a sudden at 01:07PM , we got this error, and the error in QMGR log file also corresponds it.


Quote:
2019-04-23 13:07:09,151 WARN [org.jboss.jca.core.connectionmanager.listener.NoTxConnectionListener] (JMSCCThreadPoolWorker-61) IJ000305: Connection error occured: org.jboss.jca.core.connectionmanager.listener.NoTxConnectionListener@635642cd[state=NORMAL managed connection=com.ibm.mq.connector.outbound.ManagedConnectionImpl@343bd3ae connection handles=0 lastUse=1556037483474 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri@760de767 pool internal context=SemaphoreArrayListManagedConnectionPool@3925807f[pool=jms/FORDMQEXTRACT_ABC1_PRY]]: com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ1107: A problem with this connection has occurred.
An error has occurred with the WebSphere MQ JMS connection.
Use the linked exception to determine the cause of this error.
at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:585) [com.ibm.msg.client.wmq.common.jar:]
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:221) [com.ibm.msg.client.wmq.common.jar:]
at com.ibm.msg.client.wmq.internal.WMQConnection.consumer(WMQConnection.java:785) [com.ibm.msg.client.wmq.jar:]
at com.ibm.mq.jmqi.remote.api.RemoteHconn.callEventHandler(RemoteHconn.java:2621) [com.ibm.mq.jmqi.remote.jar:7.5.0.7 - p750-007-160812]
at com.ibm.mq.jmqi.remote.api.RemoteHconn.driveEventsEH(RemoteHconn.java:601) [com.ibm.mq.jmqi.remote.jar:7.5.0.7 - p750-007-160812]
at com.ibm.mq.jmqi.remote.impl.RemoteDispatchThread.processHconn(RemoteDispatchThread.java:668) [com.ibm.mq.jmqi.remote.jar:7.5.0.7 - p750-007-160812]
at com.ibm.mq.jmqi.remote.impl.RemoteDispatchThread.run(RemoteDispatchThread.java:244) [com.ibm.mq.jmqi.remote.jar:7.5.0.7 - p750-007-160812]
at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:214) [com.ibm.msg.client.commonservices.jar:]
at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:105) [com.ibm.msg.client.commonservices.jar:]
at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:229) [com.ibm.msg.client.commonservices.jar:]
at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:303) [com.ibm.msg.client.commonservices.jar:]
at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1241) [com.ibm.msg.client.commonservices.j2se.jar:]
Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2009' ('MQRC_CONNECTION_BROKEN').
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:209) [com.ibm.msg.client.wmq.common.jar:]
... 10 more

Back to top
View user's profile Send private message
Vitor
PostPosted: Wed Apr 24, 2019 10:20 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

vicks_mq wrote:
Hi Vitor, thank you for reply. The last transaction which was also successful happened around 12:37PM and then after that all of a sudden at 01:07PM , we got this error, and the error in QMGR log file also corresponds it.


So; you send a transaction that involves this channel. 30 minutes later (not 29, not 31 but 30) the connection goes boom. After exactly 30 minutes of inactivity. But that's just a wild coincidence and not something timing out the idle connection.

When you researched this problem what did you find? Mr. Google pointed me to this, this and most interestingly of all this gem from 2 years ago


_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
vicks_mq
PostPosted: Wed Apr 24, 2019 12:28 pm    Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

Vitor wrote:
vicks_mq wrote:
Hi Vitor, thank you for reply. The last transaction which was also successful happened around 12:37PM and then after that all of a sudden at 01:07PM , we got this error, and the error in QMGR log file also corresponds it.


So; you send a transaction that involves this channel. 30 minutes later (not 29, not 31 but 30) the connection goes boom. After exactly 30 minutes of inactivity. But that's just a wild coincidence and not something timing out the idle connection.

When you researched this problem what did you find? Mr. Google pointed me to this, this and most interestingly of all this gem from 2 years ago



Hi Vitor, this issue is different from any of the links mentioned here -
1st we are not getting Maximum number of svrconn channel instances reached
2nd earlier we had problem wiht firewall because the application was connecting from a vendor site
3nd this current issue is different and it gets resolved if I change the value of SHARECNV to 10 from its existing value of 1. But I still have not figured out the reason why changing the value of SHARECNV resolved it, yes I understand this allows an application to share conversation over a single channel instance but when we have MaxInstance of that channel set to 100 and I never see that number of instances reaches so why this issue is happening with the value of SHARECNV as 1.
Back to top
View user's profile Send private message
vicks_mq
PostPosted: Wed Apr 24, 2019 1:13 pm    Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

I found something - We have one QMGR whose parameters are given below and using the same SVRCONN channel , 4 different instances of application each running on a different server are connected and I noticed the following

Svrconn channel parameters - MAXINST(99999999) MAXINSTC(9999999) SHARECNV(10) DISCINT(0)

dis chs(LONDON.SVRCONN) CURSHCNV
8 : dis chs(LONDON.SVRCONN) CURSHCNV
AMQ8417: Display Channel Status details.
CHANNEL(LONDON.SVRCONN) CHLTYPE(SVRCONN)
CONNAME(Hostname1) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
CURSHCNV(10)
AMQ8417: Display Channel Status details.
CHANNEL(LONDON.SVRCONN) CHLTYPE(SVRCONN)
CONNAME(Hostname2) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
CURSHCNV(2)
AMQ8417: Display Channel Status details.
CHANNEL(LONDON.SVRCONN) CHLTYPE(SVRCONN)
CONNAME(Hostname2) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
CURSHCNV(10)
AMQ8417: Display Channel Status details.
CHANNEL(LONDON.SVRCONN) CHLTYPE(SVRCONN)
CONNAME(Hostname3) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
CURSHCNV(10)
AMQ8417: Display Channel Status details.
CHANNEL(LONDON.SVRCONN) CHLTYPE(SVRCONN)
CONNAME(Hostname2) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
CURSHCNV(10)
AMQ8417: Display Channel Status details.
CHANNEL(LONDON.SVRCONN) CHLTYPE(SVRCONN)
CONNAME(Hostname3) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
CURSHCNV(
AMQ8417: Display Channel Status details.
CHANNEL(LONDON.SVRCONN) CHLTYPE(SVRCONN)
CONNAME(Hostname1) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
CURSHCNV(10)
AMQ8417: Display Channel Status details.
CHANNEL(LONDON.SVRCONN) CHLTYPE(SVRCONN)
CONNAME(Hostname4) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
CURSHCNV(10)
AMQ8417: Display Channel Status details.
CHANNEL(LONDON.SVRCONN) CHLTYPE(SVRCONN)
CONNAME(Hostname3) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
CURSHCNV(4)
AMQ8417: Display Channel Status details.
CHANNEL(LONDON.SVRCONN) CHLTYPE(SVRCONN)
CONNAME(Hostname4) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
CURSHCNV(10)
AMQ8417: Display Channel Status details.
CHANNEL(LONDON.SVRCONN) CHLTYPE(SVRCONN)
CONNAME(Hostname4) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
CURSHCNV(2)

for a connection to a particular server let's say Hostname4, whenever the application connects it starts with CURSHCNV as 1, and as the more users logged in the CURSHCNV value keeps increases until it hits a value of 10 and then application create another instance of the channel for this hostname4 and again it goes from CURSHCNV 1 to 10, and once it reaches again 10, then the application open another instance ..

I have one question here - suppose an instance has CURSHCNV as 9, how does the value of it gets decreased back to 1, is it when the application issue a MQ DISCONNECT COMMAND?
Back to top
View user's profile Send private message
hughson
PostPosted: Wed Apr 24, 2019 4:58 pm    Post subject: Reply with quote

Padawan

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

vicks_mq wrote:
I am seeing a 2009 connection broken error from our JBOSS to MQ in the JBOSS logs and also following MQ connection parameters are being printed.
Do you see anything wrong with these parameters?

2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_CLIENT_RECONNECT_OPTIONS :- 33554432
2019-04-23 13:07:09,224 ERROR [stderr] (JMSCCThreadPoolWorker-61) | XMSC_WMQ_CLIENT_RECONNECT_TIMEOUT :- 1800

The value 33554432 set in XMSC_WMQ_CLIENT_RECONNECT_OPTIONS equates to MQCNO_RECONNECT_DISABLED

I agree with Vitor's analysis that the firewall is the most likely suspect. I said so in your other thread too.

vicks_mq wrote:
for a connection to a particular server let's say Hostname4, whenever the application connects it starts with CURSHCNV as 1, and as the more users logged in the CURSHCNV value keeps increases until it hits a value of 10 and then application create another instance of the channel for this hostname4 and again it goes from CURSHCNV 1 to 10, and once it reaches again 10, then the application open another instance ..

Yup, this is exactly how Shared Conversations works.

vicks_mq wrote:
I have one question here - suppose an instance has CURSHCNV as 9, how does the value of it gets decreased back to 1, is it when the application issue a MQ DISCONNECT COMMAND?

Yes, when the application who connected and increased the count by one, disconnects, it decreases the count by one.

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
vicks_mq
PostPosted: Thu Apr 25, 2019 3:46 am    Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

Quote:
The value 33554432 set in XMSC_WMQ_CLIENT_RECONNECT_OPTIONS equates to MQCNO_RECONNECT_DISABLED

Morag, thank you for the reply , what is the pro & cons of if the application change MQCNO_RECONNECT to "ENABLED" ?
Does that cause any harm? I am wondering if this 2009 error is because of a issue in firewall, which is only happening intermittently, then this reconnect should solve it?
Back to top
View user's profile Send private message
vicks_mq
PostPosted: Thu Apr 25, 2019 5:02 am    Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

Quote:



vicks_mq wrote:
for a connection to a particular server let's say Hostname4, whenever the application connects it starts with CURSHCNV as 1, and as the more users logged in the CURSHCNV value keeps increases until it hits a value of 10 and then application create another instance of the channel for this hostname4 and again it goes from CURSHCNV 1 to 10, and once it reaches again 10, then the application open another instance ..

Yup, this is exactly how Shared Conversations works.

Hi Morag, I need your expertise to figure out what could have happened in below case. Below I see 3 instances of the SVRCONN and whereas 1st one has CURSHCNV reached to Max of 10, but the 2nd instance doesn't have its CURSHCNV reached to 10 but we got a 3rd instance created.
Another thing to note, both the 2nd and 3rd instance started at same time.
I can think of 2 possible scenarios, when the 1st instance CURSHCNV reached to 10, application has multiple users logged in and it created 2 more instances parallel (hence the same start time)
2nd scenario I can think that application only create the 2nd instance but very soon within few seconds this instance CURSHCNV also reached to 10 and application created another instance and later dropped the CURSHCNV of 2nd from 10 to 4.

AMQ8417: Display Channel Status details.
CHANNEL(UNICEF.APP.SVRCONN) CHLTYPE(SVRCONN)
CHSTADA(2019-04-22) CHSTATI(01.09.00)
CONNAME(55.111.222.333) CURRENT
LSTMSGDA(2019-04-25) LSTMSGTI(08.48.54)
MSGS(2843416) STATUS(RUNNING)
SUBSTATE(RECEIVE) CURSHCNV(10)

AMQ8417: Display Channel Status details.
CHANNEL(UNICEF.APP.SVRCONN) CHLTYPE(SVRCONN)
CHSTADA(2019-04-22) CHSTATI(01.09.05)
CONNAME(55.111.222.333) CURRENT
LSTMSGDA(2019-04-25) LSTMSGTI(08.48.53)
MSGS(573026) STATUS(RUNNING)
SUBSTATE(RECEIVE) CURSHCNV(4)

AMQ8417: Display Channel Status details.
CHANNEL(UNICEF.APP.SVRCONN) CHLTYPE(SVRCONN)
CHSTADA(2019-04-22) CHSTATI(01.09.05)
CONNAME(55.111.222.333) CURRENT
LSTMSGDA(2019-04-25) LSTMSGTI(06.42.39)
MSGS(439041) STATUS(RUNNING)
SUBSTATE(RECEIVE) CURSHCNV(1)
Back to top
View user's profile Send private message
vicks_mq
PostPosted: Thu Apr 25, 2019 7:18 am    Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

[quote="Vitor"]
vicks_mq wrote:
Hi Vitor, thank you for reply. The last transaction which was also successful happened around 12:37PM and then after that all of a sudden at 01:07PM , we got this error, and the error in QMGR log file also corresponds it.


Quote:
So; you send a transaction that involves this channel. 30 minutes later (not 29, not 31 but 30) the connection goes boom. After exactly 30 minutes of inactivity. But that's just a wild coincidence and not something timing out the idle connection.


Hi Vitor, it just happened again , the last message sent from application to SVRCONN channel was 10:11 and exactly at 10:41 , my SVRCONN went from RUNNING to INACTIVE and QMGR printed the error logs of channel timing out. It could not be a coincidence.
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Apr 25, 2019 7:22 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

[quote="vicks_mq"]
Vitor wrote:
vicks_mq wrote:
Hi Vitor, thank you for reply. The last transaction which was also successful happened around 12:37PM and then after that all of a sudden at 01:07PM , we got this error, and the error in QMGR log file also corresponds it.


Quote:
So; you send a transaction that involves this channel. 30 minutes later (not 29, not 31 but 30) the connection goes boom. After exactly 30 minutes of inactivity. But that's just a wild coincidence and not something timing out the idle connection.


Hi Vitor, it just happened again , the last message sent from application to SVRCONN channel was 10:11 and exactly at 10:41 , my SVRCONN went from RUNNING to INACTIVE and QMGR printed the error logs of channel timing out. It could not be a coincidence.


Yes, in retrospect you probably couldn't hear the sarcasm dripping from my voice when I claim the exact 30 minute interval was a coincidence. Despite your assertion that there's nothing in the network (like a firewall) timing out the connection after 30 minutes of inactivity.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
vicks_mq
PostPosted: Thu Apr 25, 2019 10:58 am    Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

Vitor wrote:


Yes, in retrospect you probably couldn't hear the sarcasm dripping from my voice when I claim the exact 30 minute interval was a coincidence. Despite your assertion that there's nothing in the network (like a firewall) timing out the connection after 30 minutes of inactivity.

Vitor, if there is one, the network team is denying its knowledge.
So I am lost here.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » General IBM MQ Support » JBOSS application parameters for connection to MQ
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.