| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| client side api exits? |
« View previous topic :: View next topic » |
| Author |
Message
|
| mdhart |
 Posted: Fri May 19, 2006 8:14 am Post subject: client side api exits? |
 |
|
Newbie
Joined: 30 Aug 2005
Posts: 2
Location: Hamilton
|
We have a client on OpenVMS that is misbehaving at times. Occasionally but not always, when it tries to MQGET a large message (4 million bytes or less, channel and queue are set at default size, 4194304 bytes), it fails on a 2010 MQRC_DATA_LENGTH_ERROR. This client will run for days without failure, handling hundreds of messages between failures. We've been working on this for a while, and are running into dead ends. My personal suspicion, based on history (don't ask), is that something in the VMS C++ compiler or runtime is overlaying memory, but i've no way to prove it.
MQRC_DATA_LENGTH_ERROR is as follows "The DataLength parameter is not valid. Either the parameter pointer is not valid, or it points to read-only storage."
What I'd really like to know is what parameters are being passed into the MQGET call. I've looked at tracing, but it only logs readable info if the MQGET call is passed down the wire to the queue manager, which in this case it is not.
Of course one option is to log the parameters before calling MQGET, but that, for various internal reasons, is not a trivial change, and if my theory is correct, changing the code will only move the problem elsewhere.
I've also looked at client-side API exits, but I can't figure out whether or not they work, or even how to configure them. Do they work on the client-side? How?
Any other ideas?
cheers,
mike |
|
| Back to top |
|
 |
| wschutz |
| Posted: Fri May 19, 2006 8:41 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
There are two types of exits at play:
Channel exits that you supply on the client's machine and get envoked before / after data is sent / received (SENDEXIT/RCVEXIT) on the client channel.
The other exit type is the API Exit, which gets called at the server whenever a MQ api call is made into the qmgr.
I'm taking a guess here, but I'd think that 2010 is detected within the MQ client code itself and therefore you'd never see any associated traffic on the client channel, so none of the exits would get envoked.
Really, I think a client trace is the way to go. If you ONLY have hundreds of messages every few days, the volume whouldn't be too bad...
_________________
-wayne |
|
| Back to top |
|
|
| tleichen |
| Posted: Fri May 19, 2006 10:51 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
Sure sounds like a memory leak of some sort. You might try making some of the parameters that go into the MQGET to be static. I know that's not the normal way of doing things, but it would not surprise me if it has an effect. If it does, you still need to find what's stomping all over memory. 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| mdhart |
| Posted: Fri May 19, 2006 12:03 pm Post subject: |
|
|
Newbie
Joined: 30 Aug 2005
Posts: 2
Location: Hamilton
|
Thanks for the advice. Based on the traces I've tested with, this error is thrown well before anything gets sent on the channel, thus rendering channel exits useless in this scenario. Unfortunately the traces themselves don't show the parameters either, at least not as far as I can tell. There is very little logged between the MQGET() and the error. I replicated the error by specifying a data length > 4Mb, and have attached the relevant part of the trace below.
I guess the only route is to modify the code and log what the parameters are before the call. We were hoping to find a non-obtrusive way of doing this (changing anything on this box is a political nightmare), but I guess not.
Thanks!
mike
<snip trace>
| Code: |
11:57:03.569337 6022.1 { MQGET
11:57:03.569356 6022.1 -{ MQGET
11:57:03.569365 6022.1 ITimer Saved
11:57:03.569375 6022.1 FPE Handler installed, New=77feab7e, Old=0
11:57:03.569384 6022.1 SEGV Handler installed, New=77feab7e, Old=0
11:57:03.569394 6022.1 BUS Handler installed, New=77feab7e, Old=0
11:57:03.569403 6022.1 ILL Handler installed, New=77feab7e, Old=0
11:57:03.569410 6022.1 Synchronous Signal Handling Activated
11:57:03.569419 6022.1 Signals Saved
11:57:03.569426 6022.1 --{ MakeCall
11:57:03.569432 6022.1 --} MakeCall rc=OK
11:57:03.569442 6022.1 FPE Handler deinstalled, New=0, Old=77feab7e
11:57:03.569451 6022.1 SEGV Handler deinstalled, New=0, Old=77feab7e
11:57:03.569461 6022.1 BUS Handler deinstalled, New=0, Old=77feab7e
11:57:03.569471 6022.1 ILL Handler deinstalled, New=0, Old=77feab7e
11:57:03.569477 6022.1 Synchronous signal handling deactivated - previous handlers restored
11:57:03.569486 6022.1 Signals Restored (1)
11:57:03.569493 6022.1 ITimer Restored
11:57:03.569501 6022.1 -}! MQGET rc=MQRC_DATA_LENGTH_ERROR
11:57:03.569508 6022.1 }! MQGET rc=MQRC_DATA_LENGTH_ERROR |
|
|
| 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
|
|
|
|
