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 IndexGeneral IBM MQ SupportApplication connecting Listeners are dropping itself

Post new topicReply to topic Goto page Previous  1, 2
Application connecting Listeners are dropping itself View previous topic :: View next topic
Author Message
PeterPotkay
PostPosted: Mon Apr 22, 2019 4:50 pm Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7546

vicks_mq wrote:
fjb_saper wrote:
Well in that case were you channel restrictions set high enough (maxinst, maxinstc ) ?


Hi fjb_saper, I think you are right, we need to increase the value of this - because they are set to 100, which is probably not enough.




100 is much bigger than 16. Why would that be a problem?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Apr 23, 2019 12:22 pm Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20071
Location: LI,NY

PeterPotkay wrote:
vicks_mq wrote:
fjb_saper wrote:
Well in that case were you channel restrictions set high enough (maxinst, maxinstc ) ?


Hi fjb_saper, I think you are right, we need to increase the value of this - because they are set to 100, which is probably not enough.




100 is much bigger than 16. Why would that be a problem?

The op didn't say how many times 16 connections would be opened...
The biggest difference between the 2 definitions is sharecnv and the number of maxinst and maxinstc...
So either the total of 500 channels is not enough for the qmgr or it is the maxinst / maxinstc that gets busted... Note that before those values were at max...
If setting sharecnv gets him through, then there must be something in the max number of channels that may be too low... but let's not forget that that also impacts maxinst and maxinstc...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
hughson
PostPosted: Tue Apr 23, 2019 3:29 pm Post subject: Reply with quote

Grand Master

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

This is all well and good, but the error message is not what would be seen if max channels (qmgr wide or per channel) is reached.

That said, I cannot explain why SHARECNV change would fix it either. Very odd.

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
fjb_saper
PostPosted: Tue Apr 23, 2019 10:47 pm Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20071
Location: LI,NY

hughson wrote:
This is all well and good, but the error message is not what would be seen if max channels (qmgr wide or per channel) is reached.

That said, I cannot explain why SHARECNV change would fix it either. Very odd.

Cheers,
Morag


MaxInst, MaxInstc reached on the channel? Would not sharecnv(10) divide the number by about 10 and potenrially bring it back into an acceptable range...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
hughson
PostPosted: Wed Apr 24, 2019 2:00 am Post subject: Reply with quote

Grand Master

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

MaxInst and MaxInstC reached on a channel give the same return code to the client as MaxChannels, and give a similar error message (indicating that you have run out of MaxInst/MaxInstC or MaxChls). This is not the error message seen on vicks system.

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
fjb_saper
PostPosted: Wed Apr 24, 2019 5:51 am Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20071
Location: LI,NY

@morag, Could sharecnv(10) vs sharecnv(1) have an effect on the heartbeat of the connection and make it happen more frequently, due to multiplexing the connections through the same socket?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
hughson
PostPosted: Wed Apr 24, 2019 4:50 pm Post subject: Reply with quote

Grand Master

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

fjb_saper wrote:
Could sharecnv(10) vs sharecnv(1) have an effect on the heartbeat of the connection and make it happen more frequently, due to multiplexing the connections through the same socket?

Having more conversations over one channel is likely to make heartbeating less frequent, since there will be more data flowing and thus less idle times.

Heartbeating is managed by a single thread for the running instance of the channel, regardless of how many conversations are running over it. Each conversation DOES NOT heartbeat itself.

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 5:50 am Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

hughson wrote:
This is all well and good, but the error message is not what would be seen if max channels (qmgr wide or per channel) is reached.

That said, I cannot explain why SHARECNV change would fix it either. Very odd.

Cheers,
Morag


Hi Morag, yes it is odd. but changing SHARECNV has fixed it and we are not seeing any more error.
Back to top
View user's profile Send private message
dextermbmq
PostPosted: Sat May 18, 2019 4:18 am Post subject: Reply with quote

Acolyte

Joined: 26 Jul 2014
Posts: 57

hughson wrote:
vicks_mq wrote:
hughson wrote:
With your "solution" in place, do you still see 16 instances of the SVRCONN, or are they now sharing?
Cheers,
Morag

No, I see less than 16.

I assume you see 16 queue listeners though, and if you run DISPLAY CHSTATUS and add up the number of CURSHCNV on each, you get a total of 16?


Hi Morag,

I have a similar situation where total IPPROCS(on multiple queues being polled by same channel) is different than the total count of CURSHCNV across all the instances of that channel.Count of CURSHCNV is more than IPPROCS.

Configuration Info :
An application starts and creates 20 Listeners for a queue(20 IPPROCS) and there are multiple such queues. So at any point of time we have close to 14-15 queues with IPPROCS as 20 on each. There is a single channel that application uses to consume the messages from all these queues. The total no. of channels running are close to 32. Most of them have CURSHCNV as 10 (which is expected as SHARECNV is set to 10 at the channel level. Some of the channels have CURSHCNV less than 10. But the sum total of CURSHCNV across all running instances is not matching IPPROCS.

What can cause this kind of situation ?
Back to top
View user's profile Send private message
hughson
PostPosted: Sat May 18, 2019 11:16 pm Post subject: Reply with quote

Grand Master

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

dextermbmq wrote:
Hi Morag,

I have a similar situation where total IPPROCS(on multiple queues being polled by same channel) is different than the total count of CURSHCNV across all the instances of that channel.Count of CURSHCNV is more than IPPROCS.

Configuration Info :
An application starts and creates 20 Listeners for a queue(20 IPPROCS) and there are multiple such queues. So at any point of time we have close to 14-15 queues with IPPROCS as 20 on each. There is a single channel that application uses to consume the messages from all these queues. The total no. of channels running are close to 32. Most of them have CURSHCNV as 10 (which is expected as SHARECNV is set to 10 at the channel level. Some of the channels have CURSHCNV less than 10. But the sum total of CURSHCNV across all running instances is not matching IPPROCS.

What can cause this kind of situation ?

If the number of connections (total of CURSHCNV) does not match the number of open handles (IPPROCS) this means that some of your connections have not managed to open the queue. You don't say anything about your application, but if it was written in JMS for example, the JMSConnection would only make an MQ connection and would not open the queue, whereas the JMSSessions would be the ones opening the queues.

Issue the following command to see all the connections and scroll through to see which one(s) don't have the queue open.

Code:
DISPLAY CONN(*) TYPE(ALL) ALL


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
dextermbmq
PostPosted: Sun May 19, 2019 5:04 am Post subject: Reply with quote

Acolyte

Joined: 26 Jul 2014
Posts: 57

[quote="hughson"]
dextermbmq wrote:
You don't say anything about your application, but if it was written in JMS for example, the JMSConnection would only make an MQ connection and would not open the queue, whereas the JMSSessions would be the ones opening the queues.

Issue the following command to see all the connections and scroll through to see which one(s) don't have the queue open.

Code:
DISPLAY CONN(*) TYPE(ALL) ALL


Cheers,
Morag


Thanks Morag.

I got some of the connections for which the OBJNAME was blank while for the remaining connections I got the Queue Names in the OBJNAME attribute.

AMQ8276: Display Connection details.
CONN(8C6ED95C01C12120)
EXTCONN(414D5143464D51534F50514D30352020)
TYPE(*)
PID(15078) TID(9)
APPLDESC(WebSphere MQ Channel) APPLTAG(XXXXXXXXX)
APPLTYPE(SYSTEM) ASTATE(NONE)
CHANNEL(OFCOM_SVRCONN) CONNAME(XX.YY.XXX.YY)
CONNOPTS(MQCNO_HANDLE_SHARE_BLOCK,MQCNO_SHARED_BINDING)
USERID(xyz) UOWLOG( )
UOWSTDA( ) UOWSTTI( )
UOWLOGDA( ) UOWLOGTI( )
URTYPE(QMGR)
EXTURID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
QMURID(0.0) UOWSTATE(NONE)

This is a Java application using MQ jars for connecting to our Queue Manager. Is it a worrying thing that I should check with my developers ?

Regards
Back to top
View user's profile Send private message
hughson
PostPosted: Sun May 19, 2019 6:29 am Post subject: Reply with quote

Grand Master

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

dextermbmq wrote:
I got some of the connections for which the OBJNAME was blank while for the remaining connections I got the Queue Names in the OBJNAME attribute.

So what were the relative numbers? How many did not have an OBJNAME?

dextermbmq wrote:
This is a Java application using MQ jars for connecting to our Queue Manager.

Is it using the JMS interface or the Java classes? If JMS, see my earlier remarks.

dextermbmq wrote:
Is it a worrying thing that I should check with my developers ?

I think you should indeed check with your developers, not because I believe it is a worrying thing, but simply because you are unable to answer whether it is a worrying thing. Knowledge of how the application works will help you do your job.

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
Display posts from previous:
Post new topicReply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum IndexGeneral IBM MQ SupportApplication connecting Listeners are dropping itself
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.