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 Previous  1, 2
 JBOSS application parameters for connection to MQ « View previous topic :: View next topic » 
Author Message
Vitor
PostPosted: Thu Apr 25, 2019 11:31 am    Post subject: Reply with quote

Grand High Poobah

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

vicks_mq wrote:
the network team is denying its knowledge.


This is standard procedure for every network team in every organization I've ever worked in. I suspect the response:

Quote:
It's not a network issue - what was the question again?


is on a network certification exam.

vicks_mq wrote:
So I am lost here.


I've been where you are. Most of the usual suspects on this forum have been where you are. Persist.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
hughson
PostPosted: Thu Apr 25, 2019 1:50 pm    Post subject: Reply with quote

Padawan

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

vicks_mq wrote:
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?

No harm in using MQCNO_RECONNECT, and althought it won't solve the 2009, it will stop the application from seeing it, and allow it to continue running, which is a close second.

vicks_mq wrote:
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)

It could be two things that I can think of.
  • Lots of disconnects happened after the third channel instance was started
  • There is more than one process (O/S process) on the client machine (A socket can only be shared when it is in the same O/S process).


vicks_mq wrote:
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.


If you want to keep your channel from appearing to be idle from the perspective of the firewall, why not enable heartbeats? You don't show in your DISPLAY CHSTATUS output what the negotiated value of HBINT is, but that would be interesting to see. The default value of heartbeats is usually 5 minutes (300 seconds), so that would certainly be good enough if your firewall is setup to break idle connections after 30 minutes.

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 4:42 pm    Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

hughson wrote:


If you want to keep your channel from appearing to be idle from the perspective of the firewall, why not enable heartbeats? You don't show in your DISPLAY CHSTATUS output what the negotiated value of HBINT is, but that would be interesting to see. The default value of heartbeats is usually 5 minutes (300 seconds), so that would certainly be good enough if your firewall is setup to break idle connections after 30 minutes.

Cheers,
Morag


Now coming back to issue of our MQ appliance where application is giving 2009 and MQ QMGR error log is giving me timeout, I checked the DIS CHS() AND HBINT(300) , I checked the value of KAINT(AUTO), does this parameter affect anything?


Last edited by vicks_mq on Fri Apr 26, 2019 4:46 am; edited 1 time in total
Back to top
View user's profile Send private message
vicks_mq
PostPosted: Thu Apr 25, 2019 6:17 pm    Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

I also found another strange thing for our MQ 8 LINUX SVRCONN channel-
one instance of this channel doesn't have any message sent recently so what he is doing "RUNNING" ? (current time is 22:15 PM and the last message on this channel was at 06.42 AM)

AMQ8417: Display Channel Status details.
CHANNEL(UNICEF.APP.SVRCONN) CHLTYPE(SVRCONN)
BUFSRCVD(725382) BUFSSENT(442154)
BYTSRCVD(178685216) BYTSSENT(153884848)
CHSTADA(2019-04-21) CHSTATI(01.09.05)
COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(55.111.222.333) CURRENT
EXITTIME(0,0) HBINT(300)
JOBNAME(000007E50000003B) LOCLADDR(::ffff:11.111.222.333(1415))
LSTMSGDA(2019-04-25) LSTMSGTI(06.42.39)
MCASTAT(RUNNING) MCAUSER(bmwuser)
MONCHL(OFF) MSGS(439041)
RAPPLTAG(jar) SECPROT(TLSV1)
SSLCERTI( ) SSLKEYDA( )
SSLKEYTI( ) SSLPEER( )
SSLRKEYS(0) STATUS(RUNNING)
STOPREQ(NO) SUBSTATE(RECEIVE)
CURSHCNV(1) MAXSHCNV(10)
RVERSION(07050004) RPRODUCT(MQJM)
Back to top
View user's profile Send private message
Vitor
PostPosted: Fri Apr 26, 2019 3:52 am    Post subject: Reply with quote

Grand High Poobah

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

vicks_mq wrote:
I also found another strange thing for our MQ 8 LINUX SVRCONN channel-
one instance of this channel doesn't have any message sent recently so what he is doing "RUNNING" ? (current time is 22:15 PM and the last message on this channel was at 06.42 AM)


Is there still an active connection (even in the absence of message traffic)?

Keep in mind that client channels do not behave the same way as queue manager to queue manager channels. A good example is the 2009 error; the sender channel would just attempt reconnection.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
hughson
PostPosted: Fri Apr 26, 2019 3:57 am    Post subject: Reply with quote

Padawan

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

Vitor wrote:
vicks_mq wrote:
I also found another strange thing for our MQ 8 LINUX SVRCONN channel-
one instance of this channel doesn't have any message sent recently so what he is doing "RUNNING" ? (current time is 22:15 PM and the last message on this channel was at 06.42 AM)


Is there still an active connection (even in the absence of message traffic)?


Aha, but this particular channel instance does and will have network traffic because it has a negotiated value of HBINT (the one shown on DISPLAY CHSTATUS) of 300.

Question is, what is the negotiated value of HBINT for the channels that are being dropped? Not just the DISPLAY CHANNEL value mind, we must see the DISPLAY CHSTATUS version of the value.

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
Vitor
PostPosted: Fri Apr 26, 2019 4:22 am    Post subject: Reply with quote

Grand High Poobah

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

hughson wrote:
Vitor wrote:
vicks_mq wrote:
I also found another strange thing for our MQ 8 LINUX SVRCONN channel-
one instance of this channel doesn't have any message sent recently so what he is doing "RUNNING" ? (current time is 22:15 PM and the last message on this channel was at 06.42 AM)


Is there still an active connection (even in the absence of message traffic)?


Aha, but this particular channel instance does and will have network traffic because it has a negotiated value of HBINT (the one shown on DISPLAY CHSTATUS) of 300.




I once again bow down before you in contrition.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
vicks_mq
PostPosted: Fri Apr 26, 2019 4:38 am    Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

hughson wrote:
Vitor wrote:
vicks_mq wrote:
I also found another strange thing for our MQ 8 LINUX SVRCONN channel-
one instance of this channel doesn't have any message sent recently so what he is doing "RUNNING" ? (current time is 22:15 PM and the last message on this channel was at 06.42 AM)


Is there still an active connection (even in the absence of message traffic)?


Aha, but this particular channel instance does and will have network traffic because it has a negotiated value of HBINT (the one shown on DISPLAY CHSTATUS) of 300.

Question is, what is the negotiated value of HBINT for the channels that are being dropped? Not just the DISPLAY CHANNEL value mind, we must see the DISPLAY CHSTATUS version of the value.

Cheers,
Morag


DISPLAY CHSTATUS shows HBINT(300)
Back to top
View user's profile Send private message
vicks_mq
PostPosted: Fri Apr 26, 2019 4:47 am    Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

Shall I start another thread for our MQ appliance TimeOut error , it looks like I have diverted the topic to our MQ8 LINUX which is not throwing any error.
Back to top
View user's profile Send private message
Vitor
PostPosted: Fri Apr 26, 2019 5:34 am    Post subject: Reply with quote

Grand High Poobah

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

vicks_mq wrote:
Shall I start another thread for our MQ appliance TimeOut error , it looks like I have diverted the topic to our MQ8 LINUX which is not throwing any error.


Probably best. Remember you can include a link to this one.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 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.