| Author |
Message
|
| PeterPotkay |
 Posted: Mon Apr 22, 2019 4:50 pm Post subject: |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| 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 |
|
 |
| fjb_saper |
| Posted: Tue Apr 23, 2019 12:22 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
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 |
|
|
| hughson |
| Posted: Tue Apr 23, 2019 3:29 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
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 |
|
|
| fjb_saper |
| Posted: Tue Apr 23, 2019 10:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
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 |
|
|
| hughson |
| Posted: Wed Apr 24, 2019 2:00 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
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 |
|
|
| fjb_saper |
| Posted: Wed Apr 24, 2019 5:51 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
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 |
|
|
| hughson |
| Posted: Wed Apr 24, 2019 4:50 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
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 |
|
|
| vicks_mq |
| Posted: Thu Apr 25, 2019 5:50 am Post subject: |
|
|
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 |
|
|
| dextermbmq |
| Posted: Sat May 18, 2019 4:18 am Post subject: |
|
|
Voyager
Joined: 26 Jul 2014
Posts: 77
|
| 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 |
|
|
| hughson |
| Posted: Sat May 18, 2019 11:16 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
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 |
|
|
| dextermbmq |
| Posted: Sun May 19, 2019 5:04 am Post subject: |
|
|
Voyager
Joined: 26 Jul 2014
Posts: 77
|
[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 |
|
|
| hughson |
| Posted: Sun May 19, 2019 6:29 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
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 |
|
|
|
|
