[GLASSFISH-20367] [Regression] MES object and MSES object continuosly keep on throwing RejectedExecutionException for succesive submission if once same exception is encountered. Created: 22/Apr/13  Updated: 20/Dec/16  Resolved: 23/Apr/13

Status: Resolved
Project: glassfish
Component/s: concurrency
Affects Version/s: 4.0_dev
Fix Version/s: 4.0_dev

Type: Bug Priority: Major
Reporter: shobhit.singh Assignee: anthony.lai
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


Tags: 4_0-approved, 4_0-release-notes, 4_0-release-notes-completed, 4_0-release-notes-drafted


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.

Comment by Alex Pineda [ 22/Apr/13 ]

Assigning to Concurrency Dev lead.

Comment by anthony.lai [ 22/Apr/13 ]

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.

Comment by anthony.lai [ 23/Apr/13 ]

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.

Comment by anthony.lai [ 23/Apr/13 ]
  • 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?
  • 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?
  • 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.


Comment by anthony.lai [ 23/Apr/13 ]

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

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


Modified Paths:

Comment by Alex Pineda [ 14/May/13 ]

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

Comment by Gail Risdal [ 31/May/13 ]

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)

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.

Restart the application.

Generated at Tue Mar 28 06:40:44 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.