| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Invalid handlers MQRC 2018 |
« View previous topic :: View next topic » |
| Author |
Message
|
| HenriqueS |
 Posted: Thu Feb 21, 2008 12:02 pm Post subject: Invalid handlers MQRC 2018 |
 |
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Folks,
The exit I´ve been working for the last weeks is almost done. BUT...
1) It is supposed to work for many channels, and it is already configured to do so (setup as a msg exit).
2) The exit executes fine when is working with only one channel.
3) When another channel receives/sends some message that my exit should take care of, it raises a 2018 when performs a MQOPEN or MQPUT.
4) I´ve read some tech docs and I suspect there is some problem that the 1st channel exit run gets some sort of exclusive access to the connection handle and that handle is considered invalid for later MQOPENs and MQPUTs that run on other user exit instances (threads?).
| Code: |
case MQXR_INIT:
Hconn = MQHO_UNUSABLE_HOBJ; /* Clear connection handle */
MQCONN(pChannelDef->QMgrName, &Hconn, &CompCode, &Reason);
...
break;
case MQXR_MSG:
O_options = MQOO_OUTPUT + MQOO_FAIL_IF_QUIESCING + MQOO_SET_IDENTITY_CONTEXT;
MQOPEN(Hconn, &od, O_options, &Hobj, &CompCode, &Reason);
...
P_options.Options = MQPMO_SET_IDENTITY_CONTEXT + MQPMO_FAIL_IF_QUIESCING;
MQPUT(Hconn, Hobj, &md, &P_options, *pDataLength, pMQXQH, &CompCode, &Reason);
|
The log file I write from the exit shows that every channel runs the MQXR_INIT block when the exit is compiled and put into the /var/mqm/exits dir even if it is 'in execution' state. It is some sort of MQ refresh procedure. So I am pretty sure that all MQCONNs are performed OK (O get a MQXCC_OK for every MQCONN on every channel).
Should I use the MQCNO_HANDLE_SHARE_BLOCK connect option?
Sample log file:
| Code: |
case init:
mqconn(channel1) = ok
mqconn(channel2) = ok
mqconn(channel3) = ok
case msg:
mqopen("queue1") = ok
mqput("queue1", "payload") = ok
mqopen("queue2") = error 2018
mqopen("queue2", "payload") = error 2018
|
_________________
HenriqueS
Certified Websphere MQ 6.0 System Administrator |
|
| Back to top |
|
 |
| zpat |
| Posted: Thu Feb 21, 2008 11:23 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| We've had similar issue with mainframe MQ exits, so you need to find some way of serialising the use of any resources which can't be shared by multiple concurrent instances of the exit. |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Fri Feb 22, 2008 12:49 pm Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Thanks. But here we are dealing within a Unix environment.
I tried the MQCNO option I said before.
Now it does work fine. But I got to test with a higher message load.
_________________
HenriqueS
Certified Websphere MQ 6.0 System Administrator |
|
| Back to top |
|
|
| TheAndroid |
| Posted: Fri Feb 22, 2008 4:18 pm Post subject: |
|
|
Novice
Joined: 04 Dec 2007
Posts: 23
|
| Is there a particular reason why you aren't using MQPUT1? It atomically does the conn, open, put, close for you. Since it's within the QMGR, it should be faster as you aren't crossing your exit boundary multiple times. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Fri Feb 22, 2008 8:10 pm Post subject: Re: Invalid handlers MQRC 2018 |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| HenriqueS wrote: |
| 3) When another channel receives/sends some message that my exit should take care of, it raises a 2018 when performs a MQOPEN or MQPUT. |
This smells like a problem of not understanding how DLLs or shared libraries work.
Are you using global variables or allocated memory or shared memory? How are you passing/storing variables between exit invocations?
Also, you should be connecting to the QMgr and opening those queues once and then reusing those handles accordingly. Do not use MQPUT1 as it will be a big resource waste doing open, put, close to the same queue hundreds or thousands of times per hour.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| TheAndroid |
| Posted: Mon Feb 25, 2008 5:30 am Post subject: |
|
|
Novice
Joined: 04 Dec 2007
Posts: 23
|
| TheAndroid wrote: |
| Is there a particular reason why you aren't using MQPUT1? It atomically does the conn, open, put, close for you. Since it's within the QMGR, it should be faster as you aren't crossing your exit boundary multiple times. |
I was riding the train Friday night when I realized how dumb my question was. What I should have asked was:
Since the Message Exit runs for EVERY message, is it possible to make the connection global and then use MQPUT1 for each message? |
|
| Back to top |
|
|
| Nigelg |
| Posted: Mon Feb 25, 2008 5:52 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Do the MQCONN when the exit is called for MQXR_MSG. You will be returned MQRC_ALREADY_CONNECTED, but will get a valid Hconn. You can then use that Hconn in subsequent MQI calls, MQPUT, MQGET etc.
_________________
MQSeries.net helps those who help themselves.. |
|
| 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
|
|
|
|
