MQSeries.net :: View topic - Problem with Base Java API and -server JVM option

mqhack · Posted: Mon Jan 27, 2003 1:09 am Post subject:

I have Java program(s) that use bindings mode and the base Java MQ API. When these apps are launched with the JVM option -client, they work fine. When they are launched with the JVM option -server, they unexpectedly end with no exceptional messages that I see printed anywhere. These are apps that are integrated into another vendors applications via that vendors API, so I cannot tell exactly what the application is doing that causes my programs to exit, however my guess is that some sort of signal is being generated, possibly to the thread that is running the MQSession. I can replicate the problem at will, by pressing a button in one of the vendor app windows. Just some facts:

Java 1.3.1_06
Solaris
Solaris 8 2/02 s28s_u7wos_08a SPARC
Copyright 2002 Sun Microsystems, Inc. All Rights Reserved.
Assembled 18 December 2001
MQ
Name: WebSphere MQ
Version: 530
CMVC level: p000-L020617
BuildType: IKAP - (Production)

I do not get any FDC's and the error logs are clean. When I do a trace, I get the following at the precise moment that I press the button that causes the problem:
*17:11:55.874843 10893.1 cond_[timed]wait signalled for process death
17:11:55.874876 10893.1 -----}! xcsWaitEventSem rc=STOP
17:11:55.874888 10893.1 ----}! zcpReceiveOnPipe rc=STOP
17:11:55.874899 10893.1 ---}! ziiSendReceiveAgent rc=MQRC_CONNECTION_BROKEN
17:11:55.874910 10893.1 --}! ziiMQGET rc=STOP
17:11:55.874925 10893.1 --{ ziiBreakConnection
17:11:55.874938 10893.1 ---{ zcpDetachPipe
17:11:55.874955 10893.1 ----{ xcsUnregisterDestructor
17:11:55.874976 10893.1 routine(e4334580) rmID(0) arg(e34943cc) runItFlag(0)
17:11:55.874990 10893.1 Found p(50c610)
17:11:55.875002 10893.1 Freeing p(50c610)
17:11:55.875014 10893.1 ----} xcsUnregisterDestructor rc=OK
17:11:55.875109 10893.1 ----{ xcsDisconnectSharedMemSet
17:11:55.875131 10893.1 About to disconnect set 1::2::2-1236
17:11:55.875142 10893.1 -----{ xcsRequestThreadMutexSem
17:11:55.875155 10893.1 hmtx is 50b8f8
17:11:55.875165 10893.1 -----} xcsRequestThreadMutexSem rc=OK
17:11:55.875178 10893.1 -----{ xcsFreeMem
17:11:55.875193 10893.1 component:24 pointer:5103a8
17:11:55.875206 10893.1 -----} xcsFreeMem rc=OK
17:11:55.875220 10893.1 This set has 1 connections left (including us)
17:11:55.875303 10893.1 -----{ xcsFreeMem
17:11:55.875319 10893.1 component:24 pointer:555738
17:11:55.875330 10893.1 -----} xcsFreeMem rc=OK
17:11:55.875341 10893.1 -----{ xcsGetSetConnectCount
17:11:55.875353 10893.1 ------{ xstGetExtentConnectCount
17:11:55.875364 10893.1 -------{ xcsRequestThreadMutexSem
17:11:55.875377 10893.1 hmtx is 50b928
17:11:55.875386 10893.1 -------} xcsRequestThreadMutexSem rc=OK
17:11:55.875395 10893.1 -------{ xcsReleaseThreadMutexSem
17:11:55.875406 10893.1 hmtx is 50b928
17:11:55.875416 10893.1 -------} xcsReleaseThreadMutexSem rc=OK
17:11:55.875454 10893.1 Num of connections for extent 1:: ::2 is 8
17:11:55.875465 10893.1 ------} xstGetExtentConnectCount rc=OK
17:11:55.875477 10893.1 Set has 8 connections
17:11:55.875486 10893.1 -----} xcsGetSetConnectCount rc=OK
17:11:55.875518 10893.1 -----{ xstDisconnectExtent
17:11:55.875528 10893.1 ------{ xcsRequestThreadMutexSem
17:11:55.875541 10893.1 hmtx is 50b928
17:11:55.875550 10893.1 ------} xcsRequestThreadMutexSem rc=OK

I cannot really trace the java code because when the program is run with -Xdebug the problem does not occur. You might probably think that I should just run this in -client mode, but one of my applications
happens to be the type of large, long running server app that the -server option was made for. I will be using -client in the meantime until I can find a fix. Any suggestions or help appreciated