glassfish
  1. glassfish
  2. GLASSFISH-20367

[Regression] MES object and MSES object continuosly keep on throwing RejectedExecutionException for succesive submission if once same exception is encountered.

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0_b85
    • Fix Version/s: 4.0_b86_RC2
    • Component/s: concurrency
    • Labels:
      None
    • Environment:

      ubuntu

      Description

      If during submission of a task from servlet1, concurrency utils object eg: concurrent/mes1 throws RejectedExecutionException then if we try to execute another servlet submitting task to same object i.e. concurrent/mes1 it will still keep on throwing RejectedExecutionException.

      Applicable to both MES and MSES.

        Activity

        Hide
        Gail Risdal added a comment -

        Added the following to the release notes:

        [Regression] MES object and MSES object continuously keep on throwing RejectedExecutionException for successive submission if once same exception is encountered. (20367)

        Description
        If multiple servlets share the same concurrent resource (managed executor service, managed scheduled executor service, or managed thread factory), and the resource rejects submission of a task from one servlet, it will reject submission of a task from all other servlets using that resource. This is expected behavior and occurs when a concurrent resource is disabled and then reenabled, at which time a different instance of the resource is created.

        Workaround
        Restart the application.

        Show
        Gail Risdal added a comment - Added the following to the release notes: [Regression] MES object and MSES object continuously keep on throwing RejectedExecutionException for successive submission if once same exception is encountered. (20367) Description If multiple servlets share the same concurrent resource (managed executor service, managed scheduled executor service, or managed thread factory), and the resource rejects submission of a task from one servlet, it will reject submission of a task from all other servlets using that resource. This is expected behavior and occurs when a concurrent resource is disabled and then reenabled, at which time a different instance of the resource is created. Workaround Restart the application.
        Hide
        Alex Pineda added a comment -

        Added Release Notes tag so the issue can be documented and communicated to the Glassfish users.

        Show
        Alex Pineda added a comment - Added Release Notes tag so the issue can be documented and communicated to the Glassfish users.
        Hide
        anthony.lai added a comment -

        Project: glassfish
        Repository: svn
        Revision: 61602
        Author: anthony.lai
        Date: 2013-04-23 22:51:14 UTC
        Link:

        Log Message:
        ------------
        GLASSFISH-20367 - remove cached default concurrency resource objects from
        deployer classes.
        Approved by Michael.
        Passed QL and Concurrency CTS.

        Revisions:
        ----------
        61602

        Modified Paths:
        ---------------
        trunk/main/appserver/concurrent/concurrent-impl/src/main/java/org/glassfish/concurrent/runtime/deployer/DefaultManagedScheduledExecutorService.java
        trunk/main/appserver/concurrent/concurrent-impl/src/main/java/org/glassfish/concurrent/runtime/deployer/DefaultManagedExecutorService.java
        trunk/main/appserver/concurrent/concurrent-impl/src/main/java/org/glassfish/concurrent/runtime/deployer/DefaultManagedThreadFactory.java

        Show
        anthony.lai added a comment - Project: glassfish Repository: svn Revision: 61602 Author: anthony.lai Date: 2013-04-23 22:51:14 UTC Link: Log Message: ------------ GLASSFISH-20367 - remove cached default concurrency resource objects from deployer classes. Approved by Michael. Passed QL and Concurrency CTS. Revisions: ---------- 61602 Modified Paths: --------------- trunk/main/appserver/concurrent/concurrent-impl/src/main/java/org/glassfish/concurrent/runtime/deployer/DefaultManagedScheduledExecutorService.java trunk/main/appserver/concurrent/concurrent-impl/src/main/java/org/glassfish/concurrent/runtime/deployer/DefaultManagedExecutorService.java trunk/main/appserver/concurrent/concurrent-impl/src/main/java/org/glassfish/concurrent/runtime/deployer/DefaultManagedThreadFactory.java
        Hide
        anthony.lai added a comment -
        • What is the impact on the customer of the bug?

        Once the default MES, MSES, or MTF is shutdown, a server restart is required for applications to refer to a working copy of the resource even after the resource is re-enabled. With this fix, only a restart of the application is needed.

        • What is the cost/risk of fixing the bug?

        Low risk. Minor change in DefaultMES, DefaultMSES, and DefaultMTF classes to no longer maintain a cached copy of the MES, MSES, or MTF.

        • Is there an impact on documentation or message strings?
          No
        • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
          QL. Concurrency CTS.
        • Which is the targeted build of 4.0 for this fix?
          4.0_b86
        • If this an integration of a new version of a component from another project,
          what are the changes that are being brought in? This might be list of
          Jira issues from that project or a list of revision messages.

        N/A

        Show
        anthony.lai added a comment - What is the impact on the customer of the bug? Once the default MES, MSES, or MTF is shutdown, a server restart is required for applications to refer to a working copy of the resource even after the resource is re-enabled. With this fix, only a restart of the application is needed. What is the cost/risk of fixing the bug? Low risk. Minor change in DefaultMES, DefaultMSES, and DefaultMTF classes to no longer maintain a cached copy of the MES, MSES, or MTF. Is there an impact on documentation or message strings? No Which tests should QA (re)run to verify the fix did not destabilize GlassFish? QL. Concurrency CTS. Which is the targeted build of 4.0 for this fix? 4.0_b86 If this an integration of a new version of a component from another project, what are the changes that are being brought in? This might be list of Jira issues from that project or a list of revision messages. N/A
        Hide
        anthony.lai added a comment -

        Got more info from Shobhit.

        Some of his testcases test for behavior when an MES resource is disabled. So within those tests they would first disable an MES resource, and then re-enable it. When the next testcase runs, the MES resource is still shut down and thus the next test fails.

        This is expected behavior. When an MES resource is disabled and then re-enabled, a different instance of MES is created. The application has retained the reference to the disabled (ie shut down) MES resource and needed to be restarted (such as disabled and then enabled) to reference the active and enabled MES.

        Within the test case I notice a problem with the default MES. Even after an application is restarted it is still referencing the default MES that was shut down. Thus I am reopening this issue for this problem.

        Show
        anthony.lai added a comment - Got more info from Shobhit. Some of his testcases test for behavior when an MES resource is disabled. So within those tests they would first disable an MES resource, and then re-enable it. When the next testcase runs, the MES resource is still shut down and thus the next test fails. This is expected behavior. When an MES resource is disabled and then re-enabled, a different instance of MES is created. The application has retained the reference to the disabled (ie shut down) MES resource and needed to be restarted (such as disabled and then enabled) to reference the active and enabled MES. Within the test case I notice a problem with the default MES. Even after an application is restarted it is still referencing the default MES that was shut down. Thus I am reopening this issue for this problem.
        Hide
        anthony.lai added a comment -

        Both servlets would be sharing the same MES object. So if the MES is not able to accept task submission, it would reject task submissions from both servlets.

        Show
        anthony.lai added a comment - Both servlets would be sharing the same MES object. So if the MES is not able to accept task submission, it would reject task submissions from both servlets.
        Hide
        Alex Pineda added a comment -

        Assigning to Concurrency Dev lead.

        Show
        Alex Pineda added a comment - Assigning to Concurrency Dev lead.

          People

          • Assignee:
            anthony.lai
            Reporter:
            shobhit.singh
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: