Issue Details (XML | Word | Printable)

Key: GLASSFISH-1429
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Minor Minor
Assignee: David Zhao
Reporter: oleksiys
Votes: 0
Watchers: 4
Operations

If you were logged in you would be able to see more operations.
glassfish

JMS standalone client hangs on exit

Created: 06/Nov/06 07:09 AM   Updated: 24/Oct/12 02:54 AM   Resolved: 24/Oct/12 02:54 AM
Component/s: jms
Affects Version/s: 9.1pe
Fix Version/s: 4.0_b61

Time Tracking:
Not Specified

Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,429
Status Whiteboard:

v2.1.1_exclude

Tags:
Participants: claus_list, David Zhao, Ed Bratt, gfbugbridge, jicai.liu, jthoennes, Kim Haase, oleksiys, rampsarathy, Satish Kumar, Sivakumar Thyagarajan and Tom Mueller


 Description  « Hide

This appears to be a bug. Even when the connection is closed, there appears to
be an active MQ client daemon thread which prevents the VM from exiting. Could
you file a GlassFish issue? We shall investigate this further.

> "Timer-0" daemon prio=1 tid=0x09b4b328 nid=0x622f in Object.wait()
[0xa72f8000..0xa72f8f30]
> at java.lang.Object.wait(Native Method)
> - waiting on <0xaa780068> (a java.util.TaskQueue)
> at java.util.TimerThread.mainLoop(Timer.java:509)
> - locked <0xaa780068> (a java.util.TaskQueue)
> at java.util.TimerThread.run(Timer.java:462)
>
> "iMQReadChannel-1" prio=1 tid=0x09b450d0 nid=0x622e runnable
[0xa7379000..0xa7379eb0]
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:129)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
> - locked <0xaae3dfe8> (a java.io.BufferedInputStream)
> at
com.sun.messaging.jmq.io.ReadOnlyPacket.readFully(ReadOnlyPacket.java:263)
> at
com.sun.messaging.jmq.io.ReadOnlyPacket.readFixedHeader(ReadOnlyPacket.java:183)
> at
com.sun.messaging.jmq.io.ReadOnlyPacket.readPacket(ReadOnlyPacket.java:143)
> at
com.sun.messaging.jmq.io.ReadWritePacket.readPacket(ReadWritePacket.java:73)
> - locked <0xaa73e1f8> (a com.sun.messaging.jmq.io.ReadWritePacket)
> at
com.sun.messaging.jmq.jmsclient.ProtocolHandler.readPacket(ProtocolHandler.java:1719)
> at com.sun.messaging.jmq.jmsclient.ReadChannel.run(ReadChannel.java:1139)
> at java.lang.Thread.run(Thread.java:595)
>
> "imqConnectionFlowControl-1" prio=1 tid=0x09b44c40 nid=0x622d in Object.wait()
[0xa73fa000..0xa73fae30]
> at java.lang.Object.wait(Native Method)
> - waiting on <0xaae3e110> (a com.sun.messaging.jmq.jmsclient.FlowControl)
> at com.sun.messaging.jmq.jmsclient.FlowControl.run(FlowControl.java:290)
> - locked <0xaae3e110> (a com.sun.messaging.jmq.jmsclient.FlowControl)
> at java.lang.Thread.run(Thread.java:595)

Thanks
--Siva.



gfbugbridge added a comment - 17/Jan/07 06:29 PM

<BT6514413>


Sivakumar Thyagarajan added a comment - 16/Apr/07 02:44 AM

Requesting Ramesh to look at this.


rampsarathy added a comment - 17/Apr/07 11:44 PM

There are certain daemon threads associated with a jms connection, since the
connection factory that is looked up is a managed connection factory (belongs to
jms resource adaptor), and the connections are obtained and returned from/to a
connection pool, a connection.close will not actually close the underlying
ohysical connection but only return it to the pool. So the threads that were
created for this connections are also alive as long as the connecion is kept
alive in the pool. And there are specific reasons why these threads have to be
daemon threads and not user threads.
Because of the above reasons the client program hangs, waiting indefinitely (or
until the idle time out in the pool is exhausted) for the threads to exit.

As a workaround we need to configure the connection pool (used by the connector
resource) in such a way that it does not pool connections (closes them
immediately instead of pooling it).
This can be achieved by setting the following pool properties in GlassFish V2

steady-pool-size=0
max-connection-usage-count=1
pool-resize-quantity=1
idle-timeout-in-seconds=5 ( the lesser the better because the connnections will
be closed after this time)

Please use asadmin set --user <user> --passwordfile <file>
domain.resources.connector-connection-pool.<poolname>.<property>=<value>

Using the above values (in b42) the client program exits immediately,


jthoennes added a comment - 20/Aug/09 05:01 AM

See discussion in forums thread:
http://forums.java.net/jive/thread.jspa?threadID=37143

I also remember a related issue with regard to the ACC container.
There was a specific mechanism used to tear down the OpenMQ runtime.

This workaround suggested by rampsarathy is not a solution to this issue.


rampsarathy added a comment - 20/Aug/09 05:15 AM

Assigning to Satish


Satish Kumar added a comment - 13/Oct/09 11:38 PM

This is a GF V2.1 issue. Marking this as v3_exlude


Satish Kumar added a comment - 13/Oct/09 11:41 PM

Adding status white board v3_exclude


Kim Haase added a comment - 14/Oct/09 08:05 AM

This is also an issue at v3 (I'm using glassfish-v3-b68-10_13_2009.zip).

A standalone client jar hangs on exit (with a plain vanilla connection factory).
The only way to prevent the hang is to deploy the jar with the --retrieve option
or to deploy it and then use the get-client-stubs command. The client jar that
is returned contains a Facade class that enables the client to exit.

The standalone client jar that hangs consists of a simple Java class:

jdench 183 =>jar tvf dist/producer.jar
0 Wed Oct 14 10:06:14 EDT 2009 META-INF/
124 Wed Oct 14 10:06:12 EDT 2009 META-INF/MANIFEST.MF
3413 Wed Oct 14 10:06:12 EDT 2009 Producer.class

When I run the jar, the output looks like this. I have to Control-C to exit the app.

jdench 193 =>appclient -client dist/producer.jar queue 3
Oct 14, 2009 10:21:58 AM
com.sun.enterprise.transaction.JavaEETransactionManagerSimplified initDelegates
INFO: Using
com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate as the
delegate
Oct 14, 2009 10:22:14 AM com.sun.messaging.jms.ra.ResourceAdapter start
INFO: MQJMSRA_RA1101: SJSMQ JMS Resource Adapter starting: REMOTE
Oct 14, 2009 10:22:14 AM com.sun.messaging.jms.ra.ResourceAdapter start
INFO: MQJMSRA_RA1101: SJSMQ JMSRA Started:REMOTE
Oct 14, 2009 10:22:15 AM com.sun.messaging.jms.ra.ManagedConnectionFactory
setAddressList
INFO: MQJMSRA_MF1101: setAddressList:NOT setting default value=localhost
Oct 14, 2009 10:22:15 AM com.sun.messaging.jms.ra.ManagedConnectionFactory
setPassword
INFO: MQJMSRA_MF1101: setPassword:NOT setting default value
Oct 14, 2009 10:22:15 AM com.sun.messaging.jms.ra.ManagedConnectionFactory
setUserName
INFO: MQJMSRA_MF1101: setUserName:NOT setting default value=guest
Destination type is queue
Sending message: This is message 1
Sending message: This is message 2
Sending message: This is message 3
^C jdench 194 =>

The jar returned after deployment looks like this:

jdench 188 =>jar tvf client-jar/appClient.jar
248 Wed Oct 14 10:13:40 EDT 2009 META-INF/MANIFEST.MF
1696 Wed Oct 14 10:13:40 EDT 2009 META-INF/application-client.xml
893 Wed Oct 14 10:13:40 EDT 2009 META-INF/sun-application-client.xml
18414 Wed Oct 14 10:13:40 EDT 2009
org/glassfish/appclient/client/AppClientFacade.class

When it runs, the output looks like this:

jdench 191 =>appclient -client client-jar/appClient.jar queue 3
Oct 14, 2009 10:18:52 AM
com.sun.enterprise.transaction.JavaEETransactionManagerSimplified initDelegates
INFO: Using
com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate as the
delegate
Oct 14, 2009 10:19:20 AM com.sun.messaging.jms.ra.ResourceAdapter start
INFO: MQJMSRA_RA1101: SJSMQ JMS Resource Adapter starting: REMOTE
Oct 14, 2009 10:19:21 AM com.sun.messaging.jms.ra.ResourceAdapter start
INFO: MQJMSRA_RA1101: SJSMQ JMSRA Started:REMOTE
Oct 14, 2009 10:19:23 AM com.sun.messaging.jms.ra.ManagedConnectionFactory
setAddressList
INFO: MQJMSRA_MF1101: setAddressList:NOT setting default value=localhost
Oct 14, 2009 10:19:23 AM com.sun.messaging.jms.ra.ManagedConnectionFactory
setPassword
INFO: MQJMSRA_MF1101: setPassword:NOT setting default value
Oct 14, 2009 10:19:23 AM com.sun.messaging.jms.ra.ManagedConnectionFactory
setUserName
INFO: MQJMSRA_MF1101: setUserName:NOT setting default value=guest
Destination type is queue
Sending message: This is message 1
Sending message: This is message 2
Sending message: This is message 3
Oct 14, 2009 10:19:24 AM com.sun.messaging.jms.ra.ResourceAdapter stop
INFO: MQJMSRA_RA1101: SJSMQ JMSRA stopping...
Oct 14, 2009 10:19:24 AM com.sun.messaging.jms.ra.ResourceAdapter stop
INFO: MQJMSRA_RA1101: SJSMQ JMSRA stopped.
Oct 14, 2009 10:19:24 AM
com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl
sendStopToResourceAdapter
INFO: ra.stop-successful


Ed Bratt added a comment - 15/Oct/09 04:26 PM

Will not fix in v2.1.1


Satish Kumar added a comment - 26/Oct/09 04:29 AM

Removing v3_exclude from the status whiteboard since this appears to be a
problem in V3 as well.


jicai.liu added a comment - 05/May/11 03:19 AM - edited

When i set the property "jms.jmsra.inAcc" with the value "false",it works well~
note: in version 2


jthoennes added a comment - 12/May/11 04:07 AM

In reply to comment #11:
> When i set the property "jms.jmsra.inAcc" with the value "false",it works well~

I guess you mean "imq.jmsra.inAcc"? Shall I set this as a system property as in:

java -Dimq.jmsra.inAcc=false

Were are these system properties documented?


claus_list added a comment - 12/Jun/11 09:16 AM - edited

java -Dimq.jmsra.inAcc=false

Works on my consumer but not on the producer. (same setup standalone clients according to the tutorial)

Does not work for me. Is there another system property ?


Tom Mueller added a comment - 06/Mar/12 10:00 PM

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.


David Zhao added a comment - 24/Oct/12 02:54 AM

Fixed.