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 » IBM MQ API Support » MQRC_HANDLE_NOT_AVAILABLE error

Post new topic  Reply to topic Goto page 1, 2  Next
 MQRC_HANDLE_NOT_AVAILABLE error « View previous topic :: View next topic » 
Author Message
vlucian
PostPosted: Thu Apr 30, 2015 4:18 am    Post subject: MQRC_HANDLE_NOT_AVAILABLE error Reply with quote

Novice

Joined: 28 Jan 2011
Posts: 17

Hi,
We have a mutlithreading C++ client application running on Linux( RHxx). Two of its threads connects to an mq server ver 7.1.0.0. using a WMQ client.
One thread connects to a local queue (lets name it LOCALQ) for GET-ing some messages and also connects to a remote q (REMOTEQ) to PUT some kind of specific responses . A second thread connects to another local q for logging events (EVENTSQ). Everytime application GETs messages from LOCALQ is also putting events on EVENTSQ.

The strange thing is that the number of handles for the EVENTSQ (local) is increasing constantly (Open output count) and eventually the result will be consumation of the MAX_HANDLES handles and MQRC2017.
However, this will not happen if instead of REMOTEQ we are using a local queue and also is not happening with application running on Windows or AIX.
We tried different combinations of server and client's versions: 7.1.0.0, 7.1.0.6, 7.0.1.12 for the server (Windows) and 7.1 and 7.5 for the WMQ client (Linux).
Is there a problem with MQ, do we need to install a fix maybe?
Thanks a lot.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Apr 30, 2015 4:42 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

How exactly is your app MQPUTting to the EVENTSQ? MQPUT? MQPUT1?

Does your app MQCLOSE the queue after each MQPUT?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.


Last edited by bruce2359 on Thu Apr 30, 2015 4:42 am; edited 1 time in total
Back to top
View user's profile Send private message
mqjeff
PostPosted: Thu Apr 30, 2015 4:42 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

You should only open each queue during thread startup, not as part of ongoing thread processing.
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Thu Apr 30, 2015 6:32 am    Post subject: Reply with quote

Grand Master

Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand

Rather than look for bugs in MQ by far the most likely cause is a bug in your application. That is the case in 99% of the cases I've come across. Are you sure your application is not just opening the same queue over and over again? You can check the handles using a command like DIS CONN(*) TYPE(HANDLE). You can, of course, set a breakpoint in your application where you open the queue or perhaps use activity trace. You could even just take an MQ trace and look at the calls you are making to MQ.

Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
bruce2359
PostPosted: Thu Apr 30, 2015 6:43 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

Please display the MAXHANDS queue-manager attribute value. Post it here.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
vlucian
PostPosted: Thu Apr 30, 2015 1:50 pm    Post subject: Reply with quote

Novice

Joined: 28 Jan 2011
Posts: 17

MAXHANDS is 256

Developers team tried hardly to repair this problem. No luck yet. I'm still puzzled about this: the problem appear only for a remote queue. How could be the code responsible for that strange behavior?

I'll try to post the relevant piece of code.

Thanks!
Back to top
View user's profile Send private message
tczielke
PostPosted: Thu Apr 30, 2015 2:01 pm    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

Comparing an MQ trace or Application Activity Trace between the local queue and remote queue runs would probably be very helpful here. The MH06 supportpac (for strmqtrc traces) and the amqsactz program (for Application Activity Traces and can be found on the Capitalware website) make it more easy to read/compare the trace output.

If you are interested, this is a session from MQTC v2.0.1.4 that goes over these tools in detail -> http://www.mqtechconference.com/sessions_v2014/MQTC_v2014_Tracing_On_Linux.pdf
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
vlucian
PostPosted: Thu Apr 30, 2015 2:37 pm    Post subject: Reply with quote

Novice

Joined: 28 Jan 2011
Posts: 17

The method we use for EVENTSQ is put. And also debugged to pair any open queue with a subsequent close.

The EVENTSQ queue is open on the main thread and remains open (it's a Logger unique instance that is also used by all the other threads to log events). The other threads use their own connection as they need not necessary on the thread start up. (this didn't seems a problem till now). Please explain a bit more on this.

The handles start to increase after the thread who puts messages to the remote queue try to use the Logger. It looks like Logger loose its connection
Back to top
View user's profile Send private message
RogerLacroix
PostPosted: Mon May 04, 2015 2:52 pm    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3252
Location: London, ON Canada

vlucian wrote:
The handles start to increase after the thread who puts messages to the remote queue try to use the Logger. It looks like Logger loose its connection

OMG. Really, your developers don't know what the issue is!?! Its instantiating a new thread for each logging request rather than use the current logging thread. Just find a developer who understands multi-threading programming and they will be able to fix it.

Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter
Back to top
View user's profile Send private message Visit poster's website
vlucian
PostPosted: Tue May 05, 2015 2:15 am    Post subject: Reply with quote

Novice

Joined: 28 Jan 2011
Posts: 17

Roger, I'm sorry, you didn't understand, please read more carefully: there's a single log thread. So, this is not the issue. And, as I said before, the same code works on windows or AIX no matter what types of queues are used (local or remote). The problem is only on Linux connector working with remote queue.
Thanks anyway.
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue May 05, 2015 4:55 am    Post subject: Reply with quote

Grand High Poobah

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

vlucian wrote:
there's a single log thread.


And you've proved this how?

vlucian wrote:
It looks like Logger loose its connection


Which would do what to the threading model? Does it restablish the lost connection, or spawn a new connection? Or a new thread?
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue May 05, 2015 5:41 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

vlucian wrote:
... And also debugged to pair any open queue with a subsequent close.

Exactly how did you debug opens/closes? Did you capture trace data? Did you merely count the number of opens/closes in your C++ source code?

Did you also debug connects/disconnects?

Does the executable (not source code) that is failing have the exact same date/time stamp as the executable that is working?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
vlucian
PostPosted: Tue May 05, 2015 11:34 am    Post subject: Reply with quote

Novice

Joined: 28 Jan 2011
Posts: 17

@vitor: prove? what do you mean?

@bruce: We did capture trace. I'll ask my colleagues for details if you really have a point here.
The same Linux executable is working with local q and it has "the problem" with remote q. On windows/aix it's the same source code but, of course, different executables.

This code is not new, it's working for some years without a problem on AIX / Windows. The problem appeared on Linux version.

thanks.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue May 05, 2015 12:16 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

Are all of the compiler options identical on all platforms? Compiler optimization, for example.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue May 05, 2015 12:32 pm    Post subject: Reply with quote

Grand High Poobah

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

vlucian wrote:
@vitor: prove? what do you mean?


You say there's a single log thread - how do you know? When things go wrong, is there still a single log thread? There's a difference between there is only a single log thread and there should be only a single log thread.
_________________
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 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » IBM MQ API Support » MQRC_HANDLE_NOT_AVAILABLE error
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.