| Author |
Message
|
| prasanta |
 Posted: Thu Jul 26, 2012 3:52 am Post subject: Is there any IBM MQ APIs to check the MQ connection status |
 |
|
Newbie
Joined: 26 Jul 2012
Posts: 4
|
gdb) where
#0 0xc000000000211ab0:0 in _lwp_kill+0x30 ()
from /usr/lib/hpux64/libpthread.so.1
#1 0xc000000000178810:0 in pthread_kill+0x9d0 ()
from /usr/lib/hpux64/libpthread.so.1
at /build/p701_P/src/lib/imqi/unix/hp700_ux90/bh/../../../imqque.cpp:2738
#10 0xc00000000d3da770:0 in ImqQue::put ()
at /build/p701_P/src/lib/imqi/unix/hp700_ux90/bh/../../../imqque.cpp:2687
From the above stack trace we found that, it required to check the MQ connection status before doing any put or get.
Because we are assume that If there is a stale connection from the pool exists and reused as a result of recycling the MQ queue Manager Object and the restart could occurs.
So kindly let us know is there any IBM MQ library APIs to check the MQ connection status ( alive or not)? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Jul 26, 2012 4:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
This is entirely entirely wrong.
You never check the connection before putting or getting.
You Put or Get and deal with failures, that might include bad connection.
YOU NEVER CHECK THE CONNECTION. |
|
| Back to top |
|
|
| prasanta |
| Posted: Fri Jul 27, 2012 1:38 am Post subject: |
|
|
Newbie
Joined: 26 Jul 2012
Posts: 4
|
| can you tell is there any IBM MQ library APIs to check the MQ connection status ( alive or not) in any particular time. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 27, 2012 3:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| prasanta wrote: |
| can you tell is there any IBM MQ library APIs to check the MQ connection status ( alive or not) in any particular time. |
There is not.
Because you never do this.
Because you never NEED to do this.
Your assertion:
| prasanta wrote: |
| we found that, it required to check the MQ connection status before doing any put or get. |
is entirely wrong (and I don't even see how you got that from the fragment you posted).
So in summary and to directly answer your question there is no such API because no such API is ever needed.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jul 27, 2012 4:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Each and every MQI call returns a Completion and Reason. It the responsibility of the app to check to ensure that calls completed successfully, and to take appropriate action if they did not.
It is possible that a connection that is valid at one instant in time might fail at the next get/put. This failure will be presented to the app in the ReasonCode returned from the failed call. If it is the connection that has failed, the Reason will be something like CONNECTION_BROKEN.
Please read the appropriate sections of the APR and APG manuals for ReasonCodes from each MQI call.
_________________
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 |
|
|
| mqjeff |
| Posted: Fri Jul 27, 2012 5:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
To beat this poor demised equine a bit more, and to clarify the point of my esteemable colleagues...
Suppose you check the connection, and it says "Everything is okay", and then it immediately dies. And then you try to GET. You checked the connection, everything was fine! But you got an error trying to do the GET anyway, because the connection had died between when you checked it and when you tried to use it.
There is no way to say "This connection is good for the next N period of time". No matter how small you slice it... |
|
| Back to top |
|
|
| prasanta |
| Posted: Sat Jul 28, 2012 1:34 am Post subject: |
|
|
Newbie
Joined: 26 Jul 2012
Posts: 4
|
| Why we are getting the core dump when we call the Put or Get in the MQ client library instead of reporting a failure message? |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Jul 28, 2012 2:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| prasanta wrote: |
| Why we are getting the core dump when we call the Put or Get in the MQ client library instead of reporting a failure message? |
Your application's hosed.
My guess would be badly built rather than badly coded but from the tiny amount of information you've posted it's impossible to be sure.
I repeat my earlier question: how did you get to "we need to check the connection"?. I don't see your logic and wonder if there is any (or if you just thought that sounded like a likely problem and plumped for it).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| prasanta |
| Posted: Mon Jul 30, 2012 12:23 am Post subject: |
|
|
Newbie
Joined: 26 Jul 2012
Posts: 4
|
Thanks to all your response.
But why we are getting the core dump when we call the Put or Get in the MQ client library instead of reporting a failure message?
Below is the full stack strace of the latest core dump file.
| Code: |
(gdb) bt
#0 0xc000000000211ab0:0 in _lwp_kill+0x30 ()
from /usr/lib/hpux64/libpthread.so.1
#1 0xc000000000178810:0 in pthread_kill+0x9d0 ()
from /usr/lib/hpux64/libpthread.so.1
#2 0xc0000000003f8140:0 in raise+0xe0 () from /usr/lib/hpux64/libc.so.1
#3 0xc000000000508c50:0 in abort+0x170 () from /usr/lib/hpux64/libc.so.1
#4 0xc00000000ee03610:0 in xehInterpretSavedSigaction ()
at /build/p701_P/src/lib/cs/unix/amqxerrx.c:915
#5 0xc00000000edfdbe0:0 in xehExceptionHandler ()
at /build/p701_P/src/lib/cs/unix/amqxerrx.c:1224
#6 <signal handler called>
#7 ImqMgr::connect ()
at /build/p701_P/src/lib/imqi/unix/hp700_ux90/bh/../../../imqmgr.cpp:1509
#8 0xc00000000d3c27a0:0 in ImqObj::openFor ()
at /build/p701_P/obj/ia64_hpux_11/include/imqobj.hpp:152
#9 0xc00000000d3daf90:0 in ImqQue::put ()
at /build/p701_P/src/lib/imqi/unix/hp700_ux90/bh/../../../imqque.cpp:2738
#10 0xc00000000d3da770:0 in ImqQue::put ()
at /build/p701_P/src/lib/imqi/unix/hp700_ux90/bh/../../../imqque.cpp:2687
#11 0x40000000004ce010:0 in MQAccessNameSpace::MQAccess::PutMessage(MQMessageNameSpace::MQMessage&)+0x12d0 ()
#12 0x40000000004f4b10:0 in OrderHandlerNameSpace::OrderHandler::OrderProcessLoop()+0x5d50 ()
---Type <return> to continue, or q <return> to quit---
#13 0x40000000004ed800:0 in StartOrderHandler(OrderHandlerNameSpace::OrderHandler*)+0x30 ()
#14 0xc00000000bb82f00:0 in thread_shell (p_tsv=0x6000000000626280)
at ../mcc_fw_threads.c:488
#15 0xc00000000013fb20:0 in __pthread_bound_body+0x190 ()
from /usr/lib/hpux64/libpthread.so.1 |
Could you please let us know the contact details of IBM MQ support team so will get some help from them regarding this issue?? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jul 30, 2012 2:26 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Do you get the same core dump when trying to run from the samples amqsputc and amqsgetc ?
Are you sure you have installed the adequate binaries for your platform / OS?
Do you get any FDC's in association with the core dump?
To report the problem in a PMR go to the IBM web site and look for "ESR"
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Toronto_MQ |
| Posted: Thu Aug 02, 2012 10:14 am Post subject: |
|
|
Master
Joined: 10 Jul 2002
Posts: 263
Location: read my name
|
|
| Back to top |
|
|
| mattfarney |
| Posted: Sat Aug 04, 2012 2:08 pm Post subject: |
|
|
Disciple
Joined: 17 Jan 2006
Posts: 167
Location: Ohio
|
As a possible guess based on the stack trace,
you are probably using an MQ object without it being fully initialized (or allocated if need-be).
On the connect call, you are getting a signal (probably sigsegv) though you could gdb the core and find out for sure.
Just a guess.
-mf |
|
| Back to top |
|
|
| steve_shad |
| Posted: Mon Aug 06, 2012 7:43 am Post subject: |
|
|
Newbie
Joined: 06 Aug 2012
Posts: 4
|
I am a colleague of Prasanta's. We work in an application support team and are not MQ experts. We are just trying to understand why an application process on a customers production system is occasionally crashing.
The stack trace that Prasanta posted shows that an attempt to put a message on a queue caused a serious exception in the ImqMgr::connect function, and that this was trapped and converted to a SIGABRT, thus causing process exit with a core dump. In this instance we had no opportunity to examine any response code from the call to ImqQue::put.
Our customer wants the process to handle whatever error is at the root of this, instead of crashing and generating a core dump, as this causes alarms to go off in their system monitoring.
fjb_saper : we have not run the examples that you indicate. The right binaries for the platform / OS are installed - most of the time the code is working fine with many messages read from and written to queues every hour. I don't think there are any FDCs generated corresponding to this issue - I have looked in /var/mqm/errors for these.
mqjeff, vitor, bruce2359 : we take your point about not checking the connection state before the put, but somehow we need to avoid this abort.
mattfarney : The core file indicates that the process died with SIGABRT, but this is after the exception from ImqMgr::connect has been handled. How can I find out what happened in the call toImqMgr::connect that caused it to subsequently trigger an abort ?
Thanks for the input so far - it is much appreciated. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 06, 2012 7:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Okay, so we've suggested that it's bad code.
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...
If you can post the section of the code that calls ImqMgr:connect, and handles any of it's exceptions, we can review it for accuracy.
From the symptoms - that everything works fine a lot of time and then sometimes you get these aborts - it suggests that something outside of the program is failing, and it's not a coding issue.
The question now is: can you replicate the issue? That is, if you get an instance of the abort, can you then immediately regenerate the abort if you relaunch the program? Or does everything appear to work fine after you restart?
If you can't replicate the issue, then you need to start looking at everything that happened on the system at the time of abort - any errors in the system log at all about anything? Any errors at all or mention of anything at all on the queue manager side of the connection rather than the application side?
I'd also see if you can enable mq tracing (on the client side if it's an client application, or on the qmgr if not) and enable some kind of os-level monitoring of the application. You say it's prod, so that's tough, but... You might simply be experiencing a slow memory leak that is from app code and the error only happens to occur during the MQ calls.
Last edited by mqjeff on Mon Aug 06, 2012 8:10 am; edited 1 time in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Aug 06, 2012 8:06 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqjeff wrote: |
From the symptoms - that everything works fine a lot of time and then sometimes you get these aborts - it suggests that something outside of the program is failing, and it's not a coding issue. |
Or it's data dependent (like an application buffer overrun), or load dependent, or resource dependent.
With so little information, and no FDCs, I'm wondering if WMQ is the victim of this, and not the cause.
_________________
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 |
|
|
|
|
