| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Client Application bypass API Exit? |
« View previous topic :: View next topic » |
| Author |
Message
|
| radishcarrot |
 Posted: Mon Oct 22, 2007 8:48 pm Post subject: Client Application bypass API Exit? |
 |
|
Newbie
Joined: 22 Oct 2007
Posts: 4
|
I have set up some logging of messages within my MQ cluster. I have put my API Exit in the QMGR Level.
On QM1, I created PP.IN & PP.OUT The PP.OUT queue is shared in the cluster. I created a namelist to authenticate the queues and add the entries to the qm.ini and restarted the queue manager.
Using my simulation, I tested by locally putting a message to PP.OUT and the message can be seen at PP.IN queue. Everything works fine. Messages are logged (this implies that the API exit is called). Then I asked my client to send a message using their application to the PP.OUT queue. The message is NOT logged (this implies that the API exits is not called at all)
Can anyone suggest why?
I surmise that a different process ends up putting the message depending on whether the put is as a result of a cluster put of a local put - but surely is ends up being a MQPUT regardless? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Oct 23, 2007 2:57 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Are you using mirrorq?
It has a bug in it in this area, that it doesn't duplicate things being put by the MCA.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Tue Oct 23, 2007 4:01 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
It has been a long time, but I thought mirrorq used a flag to tell it what to log and not log. Look in the source for:
| Quote: |
/**********************************************************/
/* 04/15/2004 - change default behavior to only exclude */
/* internal functions when requested by setting */
/* MIRRORQ_NO_INTERNAL to any value */
/**********************************************************/
|
and see what the code around it does. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Oct 23, 2007 7:49 am Post subject: Re: Client Application bypass API Exit? |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| radishcarrot wrote: |
The message is NOT logged (this implies that the API exits is not called at all)
Can anyone suggest why? |
The MQPUT should be done by an amqrmppa process on behalf of a client application. Is the API exit written and configured in such a way that it will run from all processes, and do the same thing in all processes? |
|
| Back to top |
|
|
| radishcarrot |
| Posted: Tue Oct 23, 2007 5:42 pm Post subject: |
|
|
Newbie
Joined: 22 Oct 2007
Posts: 4
|
Sorry guys, I am not using the mirrorq code. I did not check for any internal processes and then ignoring them, in fact I even print debugging statement for each of the processes that I specified. In a strange way, just this particular system seems to bypass the API Exit. Just wondering how did it happen. Hopefully someone has an idea. =)
Just to confirm what mvic wrote about "configured in such a way that it will run from all processes, and do the same thing in all processes?" <- Do you mean registering all the processes in the EntryPoint. I did it, to name a few function that I registered. For e.g. OpenBefore, OpenAfter, PutBefore, PutAfter, Put1Before, Put1After, and etc.
By the way, any idea whether MQC.MQPMO_SYNCPOINT has an impact on the API exit for putting of messages?
Thanks for the help. |
|
| Back to top |
|
|
| JuulV |
| Posted: Thu Oct 25, 2007 1:09 am Post subject: |
|
|
Apprentice
Joined: 05 Sep 2007
Posts: 28
Location: Belgium
|
First a very important thing about the API Exit: although you register it with the queue manager (in the qm.ini file on Unix/linux, or the registry on Windows - usually via MQ Explorer), the exit is loaded by, and runs under the process that issues the WMQ API calls (which can be a user application or internal WMQ process).
Once you define the API Exit (and recycled the QMgr), there's NO WAY of preventing it from being INVOKED FOR EVERY process that issues an MQCONN(X) call, but typically in the MQ_INIT_EXIT, coding can be present to exclude some processes from further processing (by simply not registering any other entry points), and/or to register the calls in which the exit is registered (via calls to the MQXEP function). Note that I said typically before, as it is possible to register and deregister Exit entry points at any time (but only from within the API Exit code itself).
So, either your message is put to a QMgr where the API Exit is not registered (did you register the API Exit with all QMgrs in the cluster?), or code in the exit itself prevents it from intercepting the call, or the call is intercepted, but the result is not what you expected... You say that your API Exit "logs" the calls. To where? To another queue? On what queue manager? Do you check the MQCC/MQRC from this put? Or do you log to a file? How do you specify the file name (and particularly the directory/path) where the file has to be created? If you're using a relative value for this, remember that the Exit runs as part of the process, so the current working directory of that process (whatever that might be) is used. When writing to file, also remember that each instance of the Exit should have its own file (I know this is a pain), or that log data from one processes can (and will) be overwritten by data from another instance of the exit.
Re. the effect of SYNCPOINT settings for putting messages from within the API Exit: see the System Admin Guide, General Usage Notes in the API Exit Reference chapter.
I hope above will help you out...
_________________
Juul Vanparijs
Senior Developer
Cressida Technology Ltd |
|
| Back to top |
|
|
| radishcarrot |
| Posted: Thu Oct 25, 2007 11:24 pm Post subject: |
|
|
Newbie
Joined: 22 Oct 2007
Posts: 4
|
Thanks for the help.
Hmmm, ok. I registered it under the OpenBefore of the MQOPEN. Therefore from what I understand, everytime when I put a message because it is a new connection, I would literally be calling the OpenBefore function. Correct me if I am wrong here. Or should I just register my API under the MQPUT?
I uses the syslog method therefore should not be a problem in my logging of my messages.
From JuulV: "So, either your message is put to a QMgr where the API Exit is not registered (did you register the API Exit with all QMgrs in the cluster?), or code in the exit itself prevents it from intercepting the call, or the call is intercepted, but the result is not what you expected... "
Do you mean that I should apply my API exit to all the QMGRS in the cluster although my client app is just connected to one?? At this moment, I just register my api exit to the QMgr that my client application is connected to, no other QMGR. |
|
| Back to top |
|
|
| JuulV |
| Posted: Fri Oct 26, 2007 2:47 am Post subject: |
|
|
Apprentice
Joined: 05 Sep 2007
Posts: 28
Location: Belgium
|
Hmmm...,
I don't completely understand the first part of your reply, but let's try to explain how the API Exit works:
You register the Exit with the queue manager, giving the queue manager the name of the MQINIT function that you used in your exit.
Whenever an application issues a MQCONN(X) call, the MQINIT function of your exit is invoked, before any other processing.
Your MQINIT function registers the call types and reasons (E.g. MQOPEN BEFORE, or MQPUT AFTER) in which your exit is interested. It also should always register the termination Exit point.
Whenever the application issues an API call for which an exit function is registered, the corresponding exit function is called BEFORE or AFTER the call is processed, with the DATA AVAILABLE AT THAT TIME (E.g. an MQOPEN BEFORE does not have the object handle that will be returned, nor any message data; MQPUT exit points don't have the queue name, but do have the object handle and the message data).
This is where I don't understand your reply: the OpenBefore function has no data at all to log.
Also remember that an Exit function is only invoked for the exact API call for which it is registered, E.g. MQOPEN or MQPUT exit points are not invoked for an MQPUT1, nor vice-versa.
When the application issues the MQDISC, the termination function of your exit is called, AFTER all MQ work (possibly including MQDISC exit functions) is completed, and your application exit should clean up any permantly allocated resources.
Writing to syslog is a pretty good idea, but I wouldn't recommend it for really high volume, especially not if you open and close the log for every call (but it certainly solves the concurrency problems).
If you're 100% sure that your cleint app only connects to 1 queue manager in the cluster, there's no need to register the exit with the other queue managers.
Regards,
_________________
Juul Vanparijs
Senior Developer
Cressida Technology Ltd |
|
| Back to top |
|
|
| radishcarrot |
| Posted: Sun Oct 28, 2007 6:36 am Post subject: |
|
|
Newbie
Joined: 22 Oct 2007
Posts: 4
|
I am sorry, actually the information that I logged is the Queue Name (just want to know that I am trying to put messages into the correct queues) therefore I registered it under the MQOPEN OpenBefore function and not at the MQPUT PutBefore or PutAfter function.
Anyway will register the exit in my other queue manager to confirm although my client has only access to one queue manager.
thanks alot for your help. Will post my result soon.  |
|
| 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
|
|
|
|
