| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Is there any IBM MQ APIs to check the MQ connection status |
« View previous topic :: View next topic » |
| Author |
Message
|
| Vitor |
 Posted: Mon Aug 06, 2012 8:55 am Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
It could also be a bad compile.
It could also be that you're trying to use the C++ so/dlls on a version of the OS that they're not qualified for. The C++ APIs have been stabilized and no new function has been added to them in a couple of years. They have been recompiled at newer levels, but that doesn't necessarily mean you should still be using them.
EDIT: what I really mean here is - make sure you're using a known fixpack level of the C++ MQ libraries and that that fixpack level is certified for the platform you're on. And then look at refactoring to not use the C++ MQ libraries... |
As I indicated above, I'd say bad build over bad code.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| steve_shad |
| Posted: Tue Aug 07, 2012 6:39 am Post subject: |
|
|
Newbie
Joined: 06 Aug 2012
Posts: 4
|
Thanks again for your inputs.
I found out from my customer that when this problem happened, the Queue manager at the remote end of one of our queues was not running. Once this was resolved, the problems ceased. However, from the application traces it does not look like we were trying to access that queue at the time of the crash, so this information is a little confusing.
mqjeff, to answer some of your points....
This application runs on HP-UX 11.31 with MQ version 7. I have found a discrepancy which may or may not be significant. On our development machines where the application is compiled and linked, we have these products installed using official IBM kits :
MQSERIES 7.0.1.3 WebSphere MQ for HP-UX
MQSERIES 7.0.1.5 WebSphere MQ update for HP-UX (U839626)
However, on the production system (runtime) the 7.0.1.5 upgrade is not there.
Looking at the build process, the application binary is linked against these libraries :
/usr/lib/libimqi23ah_r.so -> //opt/mqm/lib/libimqi23bh_r.so
/usr/lib/libmqic_r.so -> /opt/mqm/lib/libmqic_r.so
These are identical between dev and prod boxes.
Regarding the possibility of a memory leak, we had already checked for that with a monitor on the process vsz. We do not see any significant growth.
So far we have not been able to replicate this issue in a test environment, but are still trying to do that.
Regarding the section of code that calls ImqMgr:connect, please take another look at the stack trace in an earlier posting. You will see that it is not the application that is making this call - it is MQ further up the stack in response to the application call of the ImqQue::put entry point.
Regarding MQ trace I will investigate whether it will be possible to enable anything like this.
Regards,
Steve |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 07, 2012 9:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Could be due to the difference in fix pack levels...
7.0.1.3 although GA is still a little "rough" compared to 7.0.1.5
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mattfarney |
| Posted: Wed Aug 08, 2012 3:11 pm Post subject: |
|
|
Disciple
Joined: 17 Jan 2006
Posts: 167
Location: Ohio
|
There was a environmental flag named:
AMQ_ABORT_ON_EXCEPTION
that used to affect this behavior. It's probably still there but I don't know for sure.
Exporting that before starting should change the behavior, but I can't say I recommend it. I had to set mine to 'Y' to enable this behavior years ago. Otherwise, an MQ error could cause a deadlock between Oracle and MQ rollbacks. The signal behavior I believe is to trump any other waiting error handlers.
I believe. Your mileage may vary.
-mf |
|
| Back to top |
|
|
| steve_shad |
| Posted: Mon Aug 20, 2012 4:31 am Post subject: |
|
|
Newbie
Joined: 06 Aug 2012
Posts: 4
|
There have been a couple of references in this thread to the root cause of this issue being "bad code" or "code is hosed". I would be interested in members thoughts on the design philosophy of this MQ client app.
The module uses two input queues to read messages from, and a configurable number of queues on which to send replies. The reply queues are modelled in the application, and the incoming messages tell us which one to use.
On startup, a connection is made to the appropraite queue managers, and all queues are opened. They are maintained in an Open state throughtout the lifetime of the module.
If any Put or Get operation on a queue fails, the queue is closed, queue manager disconnected and the queue marked as unavailable. A "monitor" thread polls the state of all queues every 30 seconds and attempts to reconnect/open any queues marked as unavailable.
The MQ experts in our customer are suggesting we should recode our queue interface to connect/open the queue every time we use it. However, we are concerned about the overhead of doing this, the amount of work (design/implement/test) that our dev team would have to go through to achieve it, and also whether it is likely to solve the problem.
Our application has been working this way for over 10 years, and problems of this type have not been seen until recently.
Are there any opinions out there ? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 20, 2012 4:47 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It's a bad idea to close/open every time. It's hard on MQ, and it's hard on your app.
The monitor thread is a bit unnecessary. I would typically just code the app to attempt the reopen if I get a bad return code from the PUT, and likewise attempt the reconnect if I get a bad return code from the OPEN.
We keep saying bad code because core dumps are not something that MQ typically does. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Aug 20, 2012 5:00 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| steve_shad wrote: |
The module uses two input queues to read messages from, and a configurable number of queues on which to send replies. |
How many configurable reply-to-queues? 5, 10, 100, 5000?
Configurable how?
| steve_shad wrote: |
| On startup, a connection is made to the appropraite queue managers, |
The app MQCONNects to multiple queue managers concurrently? How many?
| steve_shad wrote: |
| If any Put or Get operation on a queue fails, the queue is closed, queue manager disconnected and the queue marked as unavailable. |
How is the queue marked as unavailable?
| steve_shad wrote: |
The MQ experts in our customer are suggesting we should recode our queue interface to connect/open the queue every time we use it. |
Why are they suggesting this?
| steve_shad wrote: |
Our application has been working this way for over 10 years, and problems of this type have not been seen until recently.
Are there any opinions out there ? |
Obviously, something has changed. Get an MQ trace.
_________________
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 Mon Aug 20, 2012 5:11 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 20, 2012 5:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| I would typically just code the app to attempt the reopen if I get a bad return code from the PUT, and likewise attempt the reconnect if I get a bad return code from the OPEN. |
There's no need to connect / disconnect / open / close more than once in the life of an application. These are resource expensive operations and it's much cheaper to react to a problem.
| mqjeff wrote: |
| We keep saying bad code because core dumps are not something that MQ typically does. |
again
Well built (in the technical sense) applications don't produce core dumps. Certainly WMQ itself doesn't ever (or shouldn't ever!) produce one. Such dumps in my experience are bad compile scripts at work.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| steve_shad |
| Posted: Mon Aug 20, 2012 8:36 am Post subject: |
|
|
Newbie
Joined: 06 Aug 2012
Posts: 4
|
Thanks bruce2359, and other respondents. As I suspected, recoding is not necessarily the right way to go. To answer your questions :
| bruce2359 wrote: |
| steve_shad wrote: |
The module uses two input queues to read messages from, and a configurable number of queues on which to send replies. |
How many configurable reply-to-queues? 5, 10, 100, 5000?
Configurable how?
|
There are 11 reply queues described in a database in our application.
| bruce2359 wrote: |
| steve_shad wrote: |
| On startup, a connection is made to the appropraite queue managers, |
The app MQCONNects to multiple queue managers concurrently? How many?
|
It looks like there is only 1.
| bruce2359 wrote: |
| steve_shad wrote: |
| If any Put or Get operation on a queue fails, the queue is closed, queue manager disconnected and the queue marked as unavailable. |
How is the queue marked as unavailable?
|
A class member variable in the app code.
| bruce2359 wrote: |
| steve_shad wrote: |
The MQ experts in our customer are suggesting we should recode our queue interface to connect/open the queue every time we use it. |
Why are they suggesting this?
|
They say it is the "proper" way to do things. I wasn't convinced, hence the reason for contacting you Guys here again.
| bruce2359 wrote: |
| steve_shad wrote: |
Our application has been working this way for over 10 years, and problems of this type have not been seen until recently.
Are there any opinions out there ? |
Obviously, something has changed. Get an MQ trace. |
I will look into this. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
