| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| QueueManger Connection Handle Timeouts? [2018 (HCONN_ERROR) |
« View previous topic :: View next topic » |
| Author |
Message
|
| pmgower |
 Posted: Mon Apr 22, 2002 12:57 pm Post subject: |
 |
|
Newbie
Joined: 21 Apr 2002
Posts: 4
|
I'm running on MQSeries 5.1 and using C APIs on the MQServer to connect to MQ. My understanding is that once you connect to a QueueManager, or Queue that the connection (i.e. Handle) will not qo away until I disconnect from them manually (i.e. the connection will not expire). If this is an invalid assumption then that might be my problem. Please read the problem description below and let me know what I need to do in order to resolve this issue.
We have a system setup that is supposed to reduce the number of times we have to connect to a QueueManager, ReplyToQueue, and RequestQueue. Now when I initially connect to the QueueManager, ReplyToQueue and RequestQueue everything works fine. The problem is when I run consecutive transactions through (i.e. put messages on the queue and get from the replytoqueue) eventually the MQPUT will fail with a return code of 2018 (HCONN_ERROR). After I receive that error I attempt to reconnect to the RequestQueue (assumeing the RequestQueue Handle timed out or something) but that MQOPEN fails with a return code of 2018 (HCONN_ERROR). The only way I can get transactions to run through again is to Reopen the QueueManager, ReplyToQueue and RequestQueue. I am wondering if there is a setting on the configuration of QueueMangers or Queues to allow handles to last longer. Or is it something else I can do? I'm trying to reduce the performance hit that it takes to open the QueueManager, ReplyToQueue, and RequestQueue.
Thanks for your help,
Paul Gower |
|
| Back to top |
|
 |
| StefanSievert |
| Posted: Mon Apr 22, 2002 3:11 pm Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
Paul,
can you please elaborate on your environment (platform, transaction managers involved etc.)?
It sounds like you are probably trying to use your connection handle outside of its scope. TTBOMK, connection handles do not timeout/expire on any platform I have come across, so it is likely to search for the cause in the area of scope.
From the MQ APR, MQCONN documentation:
| Quote: |
The scope of the handle is restricted to the smallest unit of parallel
processing within the environment concerned; the handle is not valid
outside the unit of parallel processing from which the MQCONN call was
issued.
- On Digital OpenVMS, the scope of the handle is the thread issuing the
call.
- On DOS client, the scope of the handle is the system.
- On OS/390, the scope of the handle is:
–- For CICS: the CICS task
–- For IMS: the Task Control Block, excluding any subtasks (usually
this is the application program running in the dependent region)
–- For OS/390 batch and TSO: the Task Control Block, excluding any
subtasks issuing the call. For IMS and OS/390 batch applications,
the scope of the handle excludes any subtasks of the task.
- On OS/2, the scope of the handle is the thread issuing the call.
- On OS/400, the scope of the handle is the job issuing the call.
- On Tandem NonStop Kernel, the scope of the handle is the process.
- On UNIX systems, the scope of the handle is the thread issuing the
call.
- On VSE/ESA, the scope of the handle is the CICS transaction.
- On Windows client and 16-bit Windows, the scope of the handle is the
process issuing the call.
- On 32-bit Windows and Windows NT, the scope of the handle is the
thread issuing the call.
|
Trying to use the handle outside of scope will give the symptoms you describe.
Cheers,
Stefan
_________________
Stefan Sievert
IBM Certified * WebSphere MQ |
|
| Back to top |
|
|
| pmgower |
| Posted: Tue Apr 23, 2002 11:33 am Post subject: |
|
|
Newbie
Joined: 21 Apr 2002
Posts: 4
|
Stefan,
My environment is Windows 2000 Server. On startup of my Application (actually it is a system service), the DLL is loaded into memory. That DLL is unloaded when my application is stopped. When a transaction comes through my application the first time, it connects to the QueueManager, ReplyToQueue, and RequestQueue. And following that, the next transactions just use the valid QueueManager connections. These transactions will come through the same thread that ran the MQCONN. I'm really at a loss as to what is going wrong.
Thanks for your help again,
Paul |
|
| Back to top |
|
|
| StefanSievert |
| Posted: Wed Apr 24, 2002 9:33 am Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
Paul,
it's hard to diagnose what the cause might be without knowing the details of your implementation. If you are 100% sure that it is always the same thread that tries to use the connection handle, then I would look at how you store the handle in the DLL. Or are you passing the handle back and forth between the caller and the DLL function?
If you store it in the DLL's memory context, is it defined as a static/global variable?
Are you getting the return code in reproducable situations or do you get it randomly?
When do you MQDISC and how is that initiated? Can you rule out the possibility that MQDISC was called and then somebody tried to re-use the (now invalid) handle?
Some questions to look into.
Stefan
_________________
Stefan Sievert
IBM Certified * WebSphere MQ |
|
| Back to top |
|
|
| pmgower |
| Posted: Wed Apr 24, 2002 10:15 am Post subject: |
|
|
Newbie
Joined: 21 Apr 2002
Posts: 4
|
Stefan,
I'm sure it is not being passed around between threads. The thread is loaded at the start of my application, which creates one instance of the class that will store the connection information. That class will hold a MQLONG QueueManagerConnectionHandle as a private member variable. Then the application will call a public function on the class and in that function it attempts to connect to the QueueManager, and respective queues. It only connects the first time that public function is called (latter calls to that function will merely try to put a message to the already open put queue. The only place MQDISC is called is in the destructor of that class. Now is there something that you see that might be wrong in the implementation for of this? I do need to check on the thread issue but I was told by my technical lead that without a shadow of a doubt it is using one thread for each connection and that connection will stay alive until the application is stopped. Let me know if I have given you enough information yet.
Thanks again for all your help,
Paul
[quote]
On 2002-04-24 10:33, StefanSievert wrote:
Paul,
it's hard to diagnose what the cause might be without knowing the details of your implementation. If you are 100% sure that it is always the same thread that tries to use the connection handle, then I would look at how you store the handle in the DLL. Or are you passing the handle back and forth between the caller and the DLL function?
| Quote: |
If you store it in the DLL's memory context, is it defined as a static/global variable?
Are you getting the return code in reproducable situations or do you get it randomly?
When do you MQDISC and how is that initiated? Can you rule out the possibility that MQDISC was called and then somebody tried to re-use the (now invalid) handle?
Some questions to look into.
Stefan
|
|
|
| Back to top |
|
|
| StefanSievert |
| Posted: Wed Apr 24, 2002 10:50 am Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
Hmmm, nothing is obviously fishy from what you describe. You said that you used that technique to reduce the number of MQCONN's and MQOPEN's. If your application spawns the thread during startup, what is the difference to calling MQCONN and MQOPEN once during application startup? The solution would make sense to me if you were re-using your class from multiple applications, but how do they communicate with the thread which created the class? Maybe I just don't get it. 
Can you please answer this one question: Are you getting the return code in reproducable situations or do you get it randomly?
If it ALWAYS only works on the first invocation and NEVER on a subsequent call, that would be a different picture as opposed to: ALWAYS works on the first and mostly on subsequent, but eventually fails. The latter would be very strange. Can you add code to your DLL method that does the MQPUT and print out (probably to a file) the connection handle, process and threadId and see what happens to those values over multiple invocations? I guess you'll need to do some digging to see what's going on. I am not a big C++ expert so the question about the lifetime of a private non-static variable (your connection handle) remains unanswered. Probably somebody else can jump in on that one.
Cheers,
Stefan
PS. BTW, if you want me to take look at your code, by any means, send it to me and I'd be happy to see if something catches my attention. NDA is implicit! I'll send you my email address in a private message if you want to take me up on that.
_________________
Stefan Sievert
IBM Certified * WebSphere MQ
[ This Message was edited by: StefanSievert on 2002-04-24 11:58 ] |
|
| Back to top |
|
|
| pmgower |
| Posted: Wed Apr 24, 2002 11:00 am Post subject: |
|
|
Newbie
Joined: 21 Apr 2002
Posts: 4
|
Ok, to answer your question it is a random problem. For instance, if I run one transaction and then say 2 hours (approx.) later or some time later I try to run it again then it will give me a return code of 2018. But if you send multiple transactions through then it works. For instance once I sent through 10 transactions, then 10 more, then 10 more, etc. and it finally failed in the middle of one set of 10 after 30 or 40 or so. So it really doesn't make sense to me. Again I'm going to research into how we are actually starting up the threads, etc. And to answer your question about why we don't load our connection up at startup is for flexability. We don't always us MQ for each transaction some transactions we use a different communication medium. Anyway, I hope this helps.
Thanks again,
Paul |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
