Author |
Message
|
ktg |
Posted: Tue Feb 12, 2008 9:29 pm Post subject: RUNMQSC problem with API exit |
|
|
Centurion
Joined: 09 Jan 2006 Posts: 138 Location: India
|
Hi All,
We have an API exit which calls pthread_mutex_trylock(). All the client and server applications works without any problem with the exit configured queue manager. But not able to run "runmqsc" on that queue manager. The AMQ error log files says:
Code: |
02/12/08 19:25:42 - Process(3346.1) User(mqm) Program(runmqsc)
AMQ6175: The system could not dynamically load the shared library
'/var/mqm/exits//API_exit'. The system returned error message
'/var/mqm/exits//API_exit: undefined symbol: pthread_mutex_trylock'.
The queue
manager will continue without this module.
EXPLANATION:
This message applies to UNIX systems. The shared library
'/var/mqm/exits//API_exit' failed to load correctly due to a problem
with the
library.
ACTION:
Check the file access permissions and that the file has not been
corrupted.
----- amqxufnx.c : 1159
-------------------------------------------------------
02/12/08 19:25:42 - Process(3346.1) User(mqm) Program(runmqsc)
AMQ7214: The module for API Exit 'API_exit' could not be loaded.
EXPLANATION:
The module 'API_exit' for API Exit 'API_exit' could not be loaded for
reason
xecU_S_LOAD_FAILED.
ACTION:
Correct the problem with the API Exit module 'API_exit'.
----- amqzuax0.c : 620 |
We started facing this problem while testing on Linux - RHEL3. We didn't had this problem on Solaris.
Please help.
TIA,
Kalpana |
|
Back to top |
|
 |
markt |
Posted: Tue Feb 12, 2008 11:17 pm Post subject: |
|
|
 Knight
Joined: 14 May 2002 Posts: 508
|
Not all programs are compiled threaded, therefore pthread functions may not be accessible. That's why on most Unix platforms you have to provide both a threaded and non-threaded version of API exits. This is fully described in the books. |
|
Back to top |
|
 |
ktg |
Posted: Tue Feb 12, 2008 11:21 pm Post subject: |
|
|
Centurion
Joined: 09 Jan 2006 Posts: 138 Location: India
|
markt wrote: |
Not all programs are compiled threaded, therefore pthread functions may not be accessible. That's why on most Unix platforms you have to provide both a threaded and non-threaded version of API exits. This is fully described in the books. |
I have threaded as well as non-threaded versions of exits. |
|
Back to top |
|
 |
markt |
Posted: Wed Feb 13, 2008 4:13 am Post subject: |
|
|
 Knight
Joined: 14 May 2002 Posts: 508
|
And you are attempting to call pthread functions from the non-threaded version? Don't do that.
Hint: runmqsc may not be a threaded program on all platforms. |
|
Back to top |
|
 |
ktg |
Posted: Fri Feb 15, 2008 10:57 am Post subject: |
|
|
Centurion
Joined: 09 Jan 2006 Posts: 138 Location: India
|
Quote: |
And you are attempting to call pthread functions from the non-threaded version? Don't do that. |
Yes :-|........This code is being used from many years......I cant change the code as my job is to do only Porting.
Quote: |
Hint: runmqsc may not be a threaded program on all platforms. |
I could not find any document/info telling runmqsc as a not threaded application on Linux?
Thanks,
Kalpana |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Feb 15, 2008 11:12 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
It should be clear that a) it's a bug to called thread routines in a piece of code that has to explicitly be non-threaded, b) even if that code has been running fine for years, this is still a bug c) "Porting" naturally requires changing the code, in order to ensure it functions on the new platform/environment/etc.
There's no documentation on the threaded or non-threaded "nature" of any of the MQ programs, other than where it's necessary to explain the functionality (like the fact that the channels run as threads in agent processes, rather than new processes). At least as far as I'm aware.
It doesn't matter though, as long as the documentation is specific that you need to provide both threaded and non-threaded versions of the exit. Which I'm pretty sure it is. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
|