| Author |
Message
|
| kishvardhan |
 Posted: Wed Sep 17, 2014 9:10 am Post subject: QMgr connection count |
 |
|
Newbie
Joined: 17 Sep 2014
Posts: 8
|
could you please help me to identify connection count for particular queue manager.
We are facing MQRC_HCNDLE_NOT_AVAILABLE with reason code 2017
looks like number of connection handles in PID. Need to identify which PID consumes handles.
We have increased MAXHANS values aswell. 
Some one help me to find root cause of this issue.
 |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Sep 17, 2014 9:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
What platform? What version of WMQ?
| kishvardhan wrote: |
| looks like number of connection handles in PID |
No, it's the number of queue handles a given instance is using, not the number of connections, that's running out.
| kishvardhan wrote: |
| Some one help me to find root cause of this issue |
The root cause is you have an application that's using MQOPEN (or equivalent) and not using MQCLOSE (or equivalent). This is commonly known as a "code bug" and the developer in question should be asked to fix his code. Assertively.
| kishvardhan wrote: |
| Need to identify which PID consumes handles |
It's whoever's telling you they're getting 2017 reason codes from the queue manager. The handles limit is per application not per queue manager; each application is allowed MaxHandles number of handles. Only the application that runs out of handles will receive the error; other applications will work normally.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kishvardhan |
| Posted: Thu Sep 18, 2014 8:39 am Post subject: |
|
|
Newbie
Joined: 17 Sep 2014
Posts: 8
|
@Vitor
We using MQ in UNIX platform
But application code developed in 2008 and there was no issue.
after some new component or Some MQ upgrade, application facing this kind of issue...
Last edited by kishvardhan on Thu Sep 18, 2014 8:40 am; edited 1 time in total |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Sep 18, 2014 8:40 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
If you don't know which application is getting the 2017 error code, in order to find out why they are not closing their handles you could use the following command:-
| Code: |
| DISPLAY CONN(*) TYPE(ALL) ALL WHERE(APPLTYPE EQ USER) |
and look for the one with lots of TYPE(HANDLE) records against it.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| kishvardhan |
| Posted: Thu Sep 18, 2014 8:50 am Post subject: |
|
|
Newbie
Joined: 17 Sep 2014
Posts: 8
|
there was no type called handle in the records.
Mostly all are CONN type and some of objects are with HSSTATE(Inactive)
|
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 18, 2014 8:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kishvardhan wrote: |
| after some new component or Some MQ upgrade, application facing this kind of issue... |
So back in 2008 the applications didn't close handles correctly and some bug / feature of the WMQ of the day let this slide; the more modern version has corrected this and now you're getting the reason code.
This also takes at face value your assertion that the code was developed in 2008 and hasn't been changed in 6 years so it must be a problem with the software and no recent change to the application that's introduced this bug. 
Unless:
| kishvardhan wrote: |
| after some new component or Some MQ upgrade, application facing this kind of issue |
The "some new component" is a new release of the application!
But that phrase is itself terrifying - don't you know what's changed in your environment? If there's been an MQ upgrade, what upgrade? IBM don't make "some upgrade", they make specific versions? Where's the control?
When, as a minimum, did this start happening? What changed immediately before then? What have you done to track down this problem except post here and go
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kishvardhan |
| Posted: Thu Sep 18, 2014 9:02 am Post subject: |
|
|
Newbie
Joined: 17 Sep 2014
Posts: 8
|
@vitol
let me clear you the point..
there was MQ upgrade from MQv6 to MQv7.0.1.3 in the application.
Post that we got issue. Before that it was not there.
and due to adding monitoring components to monitor channel status would cause this issue? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 18, 2014 9:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kishvardhan wrote: |
there was MQ upgrade from MQv6 to MQv7.0.1.3 in the application.
Post that we got issue. Before that it was not there. |
Information. It's like a cool blast of oxygen....
So you upgraded from a massively out of date (and slightly shaky) version to a more modern version that's still not the latest. Interesting strategy.
If this problem is being seen as part of your upgrade testing, it's a simple matter to switch on and off various applications until you observe that the problem only occurs when a given application is running. If this problem is being seen in production, then you can refer back to the upgrade testing and see which applications have changed since you ran the upgrade test, which clearly didn't display this problem or you would not have upgraded.
Or you can look for the application reporting the 2017 error (as I suggested earlier) and know that's the application with the problem.
| kishvardhan wrote: |
| and due to adding monitoring components to monitor channel status would cause this issue? |
Any specific monitoring components or just monitoring components generally? Were they installed by the same team that put "some MQ update" in place.....?
I don't see how something monitoring a channel would affect the number of queue handles an application was using. What happened when you tested this unspecified monitoring before putting it live?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Sep 18, 2014 9:19 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| kishvardhan wrote: |
there was no type called handle in the records.
Mostly all are CONN type and some of objects are with HSSTATE(Inactive)
|
When you see the output from DISPLAY CONN, you'll see something like this:-
| Code: |
AMQ8276: Display Connection details.
CONN(6E121B5420001C03)
EXTCONN(414D51434D51373031514D2020202020)
TYPE(CONN)
PID(13100) TID(1)
APPLDESC( ) APPLTAG(D:\nttools\q.exe)
APPLTYPE(USER) ASTATE(NONE)
CHANNEL( ) CONNAME( )
CONNOPTS(MQCNO_SHARED_BINDING) USERID(hughson)
UOWLOG( ) UOWSTDA( )
UOWSTTI( ) UOWLOGDA( )
UOWLOGTI( ) URTYPE(QMGR)
EXTURID(XA_FORMATID[00000000] XA_GTRID[] XA_BQUAL[])
QMURID(0.0) UOWSTATE(NONE)
OBJNAME(Q1) OBJTYPE(QUEUE)
ASTATE(NONE) HSTATE(INACTIVE)
OPENOPTS(MQOO_OUTPUT,MQOO_FAIL_IF_QUIESCING)
READA(NO)
OBJNAME(Q2) OBJTYPE(QUEUE)
ASTATE(NONE) HSTATE(INACTIVE)
OPENOPTS(MQOO_OUTPUT,MQOO_FAIL_IF_QUIESCING)
READA(NO) |
The first chunk is the TYPE(CONN) record, then there is a space, then there are a smaller set of lines together showing an object, in the example a queue, this is a TYPE(HANDLE) record, then a space, and then another TYPE(HANDLE) record, until you get to the next TYPE(CONN).
Unfortunately runmqsc has a funny way of reporting this and doesn't show the TYPE(HANDLE).
So do you see any CONNs that have lots of these object related records?
HSTATE(INACTIVE) means that the object handle isn't currently in a MQ API call. You will see HSTATE(ACTIVE) when the application is in an MQGET-wait for example. If your problem, as surmised, is that the application is opening queues but not closing them after it is finished with them, then HSTATE(INACTIVE) is what we'd expect to see.
Cheers
Morag
P.S. V6 is out of service and V7.0.1 is going out of service Sept 2015, you should look to move to V7.5 soon at minimum.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Sep 18, 2014 9:33 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| hughson wrote: |
| P.S. V6 is out of service and V7.0.1 is going out of service Sept 2015, you should look to move to V7.5 soon at minimum. |
Only V7.5? Where's your sense of adventure? 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Sep 18, 2014 9:41 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| exerk wrote: |
| hughson wrote: |
| P.S. V6 is out of service and V7.0.1 is going out of service Sept 2015, you should look to move to V7.5 soon at minimum. |
Only V7.5? Where's your sense of adventure? |
You can't migrate straight from V6 to V8. Code won't let you. But now that they've got as far as V7.0.1 they could jump straight to V8 from there. 
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 18, 2014 9:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hughson wrote: |
| exerk wrote: |
| hughson wrote: |
| P.S. V6 is out of service and V7.0.1 is going out of service Sept 2015, you should look to move to V7.5 soon at minimum. |
Only V7.5? Where's your sense of adventure? |
You can't migrate straight from V6 to V8. Code won't let you. But now that they've got as far as V7.0.1 they could jump straight to V8 from there. |
Assuming the remaining wheels don't fall off their code......
(Bad Vitor! Bad Vitor! *hits himself on nose with rolled up newspaper*)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 18, 2014 10:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
@kishvardhan, a thought has occured to me (being beaten with a rolled up newspaper is inspirational):
If you were on WMQv6.0, are these applications trying to use the long depreciated ActiveX control to talk to MQ? That could well be going crackers trying to talk to a v7 installation and would cause this problem (or a problem) without the application code itself being changed.
Of course, this would (as I indicated above) have shown up in your pre-upgrade testing.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Sep 18, 2014 1:55 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| Vitor wrote: |
| being beaten with a rolled up newspaper is inspirational |
Everyone take note 
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Sep 19, 2014 4:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| hughson wrote: |
| Vitor wrote: |
| being beaten with a rolled up newspaper is inspirational |
Everyone take note |
Look, what a man and his wife do in the privacy...
Wait, no, sorry, too inappropriate.
Our chief weapon is surpise! And a rolled up newspaper. |
|
| Back to top |
|
|
|
|
