Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 9.1pe
    • Fix Version/s: 4.0_b61
    • Component/s: jms
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      1,429
    • Status Whiteboard:
      Hide

      v2.1.1_exclude

      Show
      v2.1.1_exclude

      Description

      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.

        Activity

        oleksiys created issue -
        Hide
        gfbugbridge added a comment -

        <BT6514413>

        Show
        gfbugbridge added a comment - <BT6514413>
        Hide
        Sivakumar Thyagarajan added a comment -

        Requesting Ramesh to look at this.

        Show
        Sivakumar Thyagarajan added a comment - Requesting Ramesh to look at this.
        Hide
        rampsarathy added a comment -

        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,

        Show
        rampsarathy added a comment - 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,
        Hide
        jthoennes added a comment -

        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.

        Show
        jthoennes added a comment - 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.
        Hide
        rampsarathy added a comment -

        Assigning to Satish

        Show
        rampsarathy added a comment - Assigning to Satish
        Hide
        Satish Kumar added a comment -

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

        Show
        Satish Kumar added a comment - This is a GF V2.1 issue. Marking this as v3_exlude
        Hide
        Satish Kumar added a comment -

        Adding status white board v3_exclude

        Show
        Satish Kumar added a comment - Adding status white board v3_exclude
        Hide
        Kim Haase added a comment -

        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

        Show
        Kim Haase added a comment - 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
        Hide
        Ed Bratt added a comment -

        Will not fix in v2.1.1

        Show
        Ed Bratt added a comment - Will not fix in v2.1.1
        Hide
        Satish Kumar added a comment -

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

        Show
        Satish Kumar added a comment - Removing v3_exclude from the status whiteboard since this appears to be a problem in V3 as well.
        kenaiadmin made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 1429 33033
        Hide
        jicai.liu added a comment - - edited

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

        Show
        jicai.liu added a comment - - edited When i set the property "jms.jmsra.inAcc" with the value "false",it works well~ note: in version 2
        Hide
        jthoennes added a comment -

        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?

        Show
        jthoennes added a comment - 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?
        Hide
        claus_list added a comment - - 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 ?

        Show
        claus_list added a comment - - 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 ?
        Ed Bratt made changes -
        Assignee Satish Kumar [ sats ] liang.x.zhao [ liang.x.zhao ]
        Hide
        Tom Mueller added a comment -

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

        Show
        Tom Mueller added a comment - Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.
        Tom Mueller made changes -
        Fix Version/s not determined [ 11149 ]
        Fix Version/s 9.1pe [ 10974 ]
        David Zhao made changes -
        Fix Version/s 4.0 [ 10970 ]
        Fix Version/s not determined [ 11149 ]
        Hide
        David Zhao added a comment -

        Fixed.

        Show
        David Zhao added a comment - Fixed.
        David Zhao made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 4.0_b61 [ 15650 ]
        Fix Version/s 4.0 [ 10970 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            David Zhao
            Reporter:
            oleksiys
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: