[GLASSFISH-20390] Possible concurrency issue in AsyncClientShutdownTask.run() in the MDB container Created: 23/Apr/13  Updated: 20/Dec/16  Resolved: 26/Apr/13

Status: Closed
Project: glassfish
Component/s: jca
Affects Version/s: 4.0_dev
Fix Version/s: 4.0_dev

Type: Bug Priority: Major
Reporter: Sivakumar Thyagarajan Assignee: marina vatkina
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved


While trying to verify GLASSFISH-20296, we found that endpointDeactivation may not be called during application undeployment intermittently.

We (Jagadish and I) think this could be due to a concurrency issue in AsynClientShutdownTask in

To reproduce:

  • In a multi-core laptop (Dell XPS) run the following
    Uncomment the lookup logic in endpointDeactivation in ra/src/connector/SimpleResourceAdapterImpl.java of https://svn.java.net/svn/glassfish~svn/trunk/v2/appserv-tests/devtests/connector/v3/connector1.6, and run the test "ant all".
  • observe that the endpointDeactivation is not called.
    [actually you should be able to use any MDB test that uses a resource adapter to deliver messages. Undeploy the application that uses the RA, and check if endpointDeactivation is called.]

If you set a breakpoint in AsyncClientShutdownTask.run() you can observe that the MessageBeanCllient.close() – which would actually call the RA's endpointDeactivation in the connector's code – is not called intermittently.

Making the "done" local variable in AsyncClientShutdownTask "volatile" appears to fix the issue.

If you can't seem to reproduce the issue, and would like to have us (Jagadish/I) verify your fixes, please let us know. We can reproduce this issue fairly reguarly.

Comment by marina vatkina [ 23/Apr/13 ]

It's not called on undeploy on my mac as well

Comment by marina vatkina [ 23/Apr/13 ]

The endpoint is not called because activeRar in ConnectorMessageBeanClient.close is null. Is it the same as GLASSFISH-20389?

Comment by marina vatkina [ 24/Apr/13 ]

activeRar is also null when undeploying ejb/ejb32/mdb test

Comment by Sivakumar Thyagarajan [ 24/Apr/13 ]

Marina: This issue is not related to GLASSFISH-20389. Infact that issue is now fixed with rev 61615, but you should still be able to reproduce this issue. If you can't reproduce and want us to run a diagnostic patch, please provide us a patch.

Transferring this to you.

Comment by marina vatkina [ 25/Apr/13 ]
  • What is the impact on the customer of the bug?
    It is reported to be seen on a multi-core device
  • How likely is it that a customer will see the bug and how serious is the bug?
    Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
    What CTS failures are caused by this bug?
    Not a regression, but the endpoint remains active until the server shutdown. May cause problems with redeployment.
  • What is the cost/risk of fixing the bug?
    Very low

How risky is the fix? How much work is the fix? Is the fix complicated?
Very low

  • Is there an impact on documentation or message strings?
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Connector, EJB
  • 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 Sivakumar Thyagarajan [ 26/Apr/13 ]

Marking this issue as closed, as we couldn't reproduce it anymore on trunk.

Generated at Mon Mar 27 03:35:56 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.