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 » QMgr connection count

Post new topic  Reply to topic Goto page 1, 2  Next
 QMgr connection count « View previous topic :: View next topic » 
Author Message
kishvardhan
PostPosted: Wed Sep 17, 2014 9:10 am    Post subject: QMgr connection count Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed Sep 17, 2014 9:31 am    Post subject: Reply with quote

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
View user's profile Send private message
kishvardhan
PostPosted: Thu Sep 18, 2014 8:39 am    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Thu Sep 18, 2014 8:40 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
kishvardhan
PostPosted: Thu Sep 18, 2014 8:50 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Thu Sep 18, 2014 8:55 am    Post subject: Reply with quote

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
View user's profile Send private message
kishvardhan
PostPosted: Thu Sep 18, 2014 9:02 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Thu Sep 18, 2014 9:17 am    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Thu Sep 18, 2014 9:19 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
exerk
PostPosted: Thu Sep 18, 2014 9:33 am    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Thu Sep 18, 2014 9:41 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Vitor
PostPosted: Thu Sep 18, 2014 9:57 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Thu Sep 18, 2014 10:00 am    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Thu Sep 18, 2014 1:55 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
mqjeff
PostPosted: Fri Sep 19, 2014 4:54 am    Post subject: Reply with quote

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
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 » QMgr connection count
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.