| Author |
Message
|
| shivaramakrishna |
 Posted: Sun Feb 25, 2007 10:19 pm Post subject: Surprising API Exit runs as part of application it self |
 |
|
Newbie
Joined: 25 Feb 2007
Posts: 3
|
Hi All,
I am implementing an API exit on Solaris. I am facing a peculiar problem.
For applications linked to mqm.lib the API exit runs as part of application itself.
For applications linked to mqic.lib the API exit runs as part of pool process (amqrmppa).
Is it documented in any of the MQ manuals? I searched a hell lot but I could not find this info anywhere.
Is this behavior only on Solaris or on other plat forms also?
_________________
Regards,
Shiva |
|
| Back to top |
|
 |
| vennela |
| Posted: Mon Feb 26, 2007 12:43 am Post subject: Re: Surprising API Exit runs as part of application it self |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| shivaramakrishna wrote: |
| For applications linked to mqm.lib the API exit runs as part of application itself. |
I think I don't understand "part" of the application. Can you please explain in detail what you mean by that
Is the exit working OK for you. Are you getting the desired results |
|
| Back to top |
|
|
| Nigelg |
| Posted: Mon Feb 26, 2007 4:10 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
The API exit runs at the interface between the app and the qmgr, i.e. when there is a context switch between the app process and the qmgr agent (amqzlaa0). For a server app, this interface is inside your app; for a client app, the interface is inside the SVRCONN MCA, i.e. the app receiving the API requests over the client channel and passing them to the qmgr.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| shivaramakrishna |
| Posted: Mon Feb 26, 2007 4:20 am Post subject: |
|
|
Newbie
Joined: 25 Feb 2007
Posts: 3
|
Hi Thanks for the information.
To add some more info on to this.
I am facing some problems on Solaris.
If Any application has the symbols( functions or global variables) with the same name as those present inside the API Exit.
Then during runtime, the linker is resolving the symbols to those present in the application. This was a mojor problem for me.
I could resolve this Issue by writting a simple map file for the API Exit.
Hence the symbols were resolved at compile time only.
_________________
Regards,
Shiva |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Feb 26, 2007 1:39 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| shivaramakrishna wrote: |
If Any application has the symbols( functions or global variables) with the same name as those present inside the API Exit.
Then during runtime, the linker is resolving the symbols to those present in the application. This was a mojor problem for me.
I could resolve this Issue by writting a simple map file for the API Exit.
|
You need to re-read the information on the API Exit.
Here is a quick overview:
- The API Exit is compiled and linked seperately from your application.
- You put the resulting DLL or shared-module into the Exits directory
- You configure the queue manager to use said API Exit.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| shivaramakrishna |
| Posted: Tue Feb 27, 2007 6:07 am Post subject: |
|
|
Newbie
Joined: 25 Feb 2007
Posts: 3
|
Hi,
I know all of that.
My application was not linked to exit library.
But I had a function with the same name in Application also.
Say for ex:
if there is a function logmessage() in exit which will log some info on to a logfile.
If there is another function in Application logmessage() which will print some message on to screen.
They are totally diffrent but had same name.
For MQServer Applications APIExit runs under the context of application itself. Hence the runtime linker on solaris was resolving the refrences for function logmessage() in the exit to the definition present in the application.
This will not happen on windows, coz, on windows the DLLs will have a saparate heap. Hence context of application and exit can not colide.
_________________
Regards,
Shiva |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Feb 28, 2007 8:56 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| shivaramakrishna wrote: |
They are totally diffrent but had same name.
For MQServer Applications APIExit runs under the context of application itself. Hence the runtime linker on solaris was resolving the refrences for function logmessage() in the exit to the definition present in the application. |
Hummm... I'm not a Solaris expert but the label / function references are normally created/determined at link time. Hence, during runtime the module will call/reference the function that was setup at link time.
Basically, you are saying that all determined references created during the link are thrown-out during runtime and re-built during runtime. I find that hard to believe usless these are dynamic references.
Are the references you are having problems with dynamic references?
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Mar 01, 2007 12:42 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| shivaramakrishna wrote: |
APIExit runs under the context of application itself. Hence the runtime linker on solaris was resolving the refrences for function logmessage() in the exit to the definition present in the application.
This will not happen on windows, coz, on windows the DLLs will have a saparate heap. |
Heap - you mean memory heap used by malloc? I don't see the connection between this and name lookups by the runtime linker.
As a general principle, if your library is going to be dynamically loaded, then either (1) specify your link library dependencies at link time, or else (2) explicitly use dlopen and dlsym to find your function in the location where you know it is.
If (1) definitely doesn't work for you I guess it has to be (2). |
|
| Back to top |
|
|
| tleichen |
| Posted: Thu Mar 01, 2007 7:52 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| mvic wrote: |
As a general principle, if your library is going to be dynamically loaded, then either (1) specify your link library dependencies at link time, or else (2) explicitly use dlopen and dlsym to find your function in the location where you know it is.
If (1) definitely doesn't work for you I guess it has to be (2). |
I agree. This sounds more like a build problem than anything... 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
|
|
