Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: V3
    • Fix Version/s: V3
    • Component/s: jms
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      8,527

      Description

      OS: solaris10
      build: promoted build 50
      I ported all the V2 jms test cases to V3. When I ran the tests and found 50%
      test cases hung. This issue blocked SQE test execution.
      Steps to reproduce the bug:
      1. Install V3. start domain
      2. Checkout SQE workspace cvs co appserver-sqe/bootstrap.xml
      (CVSROOT: :pserver:<user>@redcvs.red.iplanet.com:/m/jws)
      cd appserver-sqe
      ant -f bootstrap.xml co-jms
      3.set env variables
      S1AS_HOME <as install dir>
      SPS_HOME <appserver-sqe dir>
      ANT_HOME <ant 1.6.5 install dir>
      JAVA_HOME <java install dir, we use jdk1.6.0_13)
      4. cd appserver-sqe/pe/jms/jmspoolapp, run "ant build setup deploy", it worked fine.
      5. cd appserver-sqe/pe/jms/jmspoolapp, run "ant run", it hung for about 20
      minutes while calling "runclient-common" target and then test passed.

          • server.log and execution output are attached.
      1. run.log
        16 kB
        sonialiu
      2. server.log
        65 kB
        sonialiu

        Activity

        Hide
        jthoennes added a comment -

        How could I stop the JMS pool myself before exiting from the GUI client?
        Is there some programmatic way to do so?

        Show
        jthoennes added a comment - How could I stop the JMS pool myself before exiting from the GUI client? Is there some programmatic way to do so?
        Hide
        Tim Quinn added a comment -

        Jagadish had identified the ejb devtests in the ejb/mdb as failing (as a symptom
        of this problem) and of the failure of the app client to exit.

        I have verified that those test, which did fail for me earlier, now pass with
        the latest repository sources.

        Show
        Tim Quinn added a comment - Jagadish had identified the ejb devtests in the ejb/mdb as failing (as a symptom of this problem) and of the failure of the app client to exit. I have verified that those test, which did fail for me earlier, now pass with the latest repository sources.
        Hide
        Tim Quinn added a comment -

        A further note on this...

        One of the changes in the app client container in my recent check-ins is that,
        if the ACC detects that an AWT event dispatcher thread is running when the
        client's main method returns, then the ACC will join to that thread. This
        effectively stalls the ACC until the user closes the last remaining GUI
        components and the EDT finishes.

        At that point, the ACC will go ahead and perform its cleanup.

        To address the point jthoennes has raised, the client will not need to
        explicitly invoke any JMS or ACC-related shutdown API.

        Note, though, that if the app client itself has created non-daemon threads and
        those threads continue after the user closes the GUI, the ACC will perform its
        cleanup but will NOT force a VM exit. The VM will remain running because of
        those non-daemon threads.

        A client that creates such threads should make sure that they are stopped in a
        controlled fashion before the EDT terminates.

        Show
        Tim Quinn added a comment - A further note on this... One of the changes in the app client container in my recent check-ins is that, if the ACC detects that an AWT event dispatcher thread is running when the client's main method returns, then the ACC will join to that thread. This effectively stalls the ACC until the user closes the last remaining GUI components and the EDT finishes. At that point, the ACC will go ahead and perform its cleanup. To address the point jthoennes has raised, the client will not need to explicitly invoke any JMS or ACC-related shutdown API. Note, though, that if the app client itself has created non-daemon threads and those threads continue after the user closes the GUI, the ACC will perform its cleanup but will NOT force a VM exit. The VM will remain running because of those non-daemon threads. A client that creates such threads should make sure that they are stopped in a controlled fashion before the EDT terminates.
        Hide
        Jagadish added a comment -

        Connector runtime shuts down all the resource-adapters concurrently with threads
        from executor service. This may be a reason why there was 20-30 seconds delay. I
        have made these threads as daemon and do not see the 20-30 seconds delay any more.

        Show
        Jagadish added a comment - Connector runtime shuts down all the resource-adapters concurrently with threads from executor service. This may be a reason why there was 20-30 seconds delay. I have made these threads as daemon and do not see the 20-30 seconds delay any more.
        Hide
        sonialiu added a comment -

        Tested today's (07/14) nigthly build, the bug is fixed.

        Show
        sonialiu added a comment - Tested today's (07/14) nigthly build, the bug is fixed.

          People

          • Assignee:
            Tim Quinn
            Reporter:
            sonialiu
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: