java.lang.IllegalStateException: Phase 'dispose' has already been executed

Details

  • User impact:
    High
  • Similar Issues:
    None

Description

I am using Mule ESB EE 2.2.2 and testing it using Junit tests with the FunctionalTestCase mechanism (that is my Junit tests all subclass from this). I get this except intermittently when running the tests.

This is a similar problem to that of MULE-4589, but in dispose instead of start.

**********************************************************************

  • Mule shut down normally on: 10/31/09 11:35 PM *
  • Server was up for: 0 days, 0 hours, 0 mins, 4.55 sec *
    **********************************************************************
    INFO 2009-10-31 23:35:16,511 [Wrapper-Shutdown-Hook] org.mule.MuleServer: Mule server shutting down due to normal shutdown request
    Error in WrapperListener.stop callback. java.lang.IllegalStateException: Phase 'dispose' has already been executed
    java.lang.IllegalStateException: Phase 'dispose' has already been executed
    at org.mule.lifecycle.GenericLifecycleManager.checkPhase(GenericLifecycleManager.java:177)
    at org.mule.DefaultMuleContext.dispose(DefaultMuleContext.java:201)
    at org.mule.MuleServer.shutdown(MuleServer.java:411)
    at org.mule.module.boot.MuleServerWrapper.stop(MuleServerWrapper.java:74)
    at org.tanukisoftware.wrapper.WrapperManager.privilegedStopInner(WrapperManager.java:3180)
    at org.tanukisoftware.wrapper.WrapperManager.access$2600(WrapperManager.java:103)
    at org.tanukisoftware.wrapper.WrapperManager$8.run(WrapperManager.java:1995)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.tanukisoftware.wrapper.WrapperManager.stop(WrapperManager.java:1992)
    at org.tanukisoftware.wrapper.WrapperManager$2.run(WrapperManager.java:467)
    <-- Wrapper Stopped

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Francis Upton added a comment -

And a similar situation, cause by the same synchronization problem:

java.lang.IllegalStateException: Currently executing lifecycle phase: start
at org.mule.lifecycle.GenericLifecycleManager.checkPhase(GenericLifecycleManager.java:187)
at org.mule.DefaultMuleContext.dispose(DefaultMuleContext.java:201)
at org.mule.tck.AbstractMuleTestCase.disposeManager(AbstractMuleTestCase.java:500)
at org.mule.tck.AbstractMuleTestCase.tearDown(AbstractMuleTestCase.java:465)
at org.mule.tck.AbstractMuleTestCase.runBare(AbstractMuleTestCase.java:253)
at org.mule.tck.AbstractMuleTestCase.run(AbstractMuleTestCase.java:233)

Show
Francis Upton added a comment - And a similar situation, cause by the same synchronization problem: java.lang.IllegalStateException: Currently executing lifecycle phase: start at org.mule.lifecycle.GenericLifecycleManager.checkPhase(GenericLifecycleManager.java:187) at org.mule.DefaultMuleContext.dispose(DefaultMuleContext.java:201) at org.mule.tck.AbstractMuleTestCase.disposeManager(AbstractMuleTestCase.java:500) at org.mule.tck.AbstractMuleTestCase.tearDown(AbstractMuleTestCase.java:465) at org.mule.tck.AbstractMuleTestCase.runBare(AbstractMuleTestCase.java:253) at org.mule.tck.AbstractMuleTestCase.run(AbstractMuleTestCase.java:233)
Hide
Permalink
Francis Upton added a comment -

Adding these changes to DefaultMuleContext seems to fix this problem, but I did not run all of the Mule regression tests:

1) Add "synchronized"

2) Add isDisposed() as well.

// Changed to synchronized to fix MULE-4590
public synchronized void dispose()
{
// Added isDisposed() to fix MULE-4590 -
if (isDisposing() || isDisposed())

{ return; }
Show
Francis Upton added a comment - Adding these changes to DefaultMuleContext seems to fix this problem, but I did not run all of the Mule regression tests: 1) Add "synchronized" 2) Add isDisposed() as well. // Changed to synchronized to fix MULE-4590 public synchronized void dispose() { // Added isDisposed() to fix MULE-4590 - if (isDisposing() || isDisposed()) { return; }
Hide
Permalink
Andrew Perepelytsya added a comment -

Francis, could you please submit patches as described here? http://www.mulesoft.org/display/MULE/Getting+Involved

Show
Andrew Perepelytsya added a comment - Francis, could you please submit patches as described here? http://www.mulesoft.org/display/MULE/Getting+Involved
Hide
Permalink
Daniel Feist added a comment - - edited

Francis: From what I see dispose() is already synchronized, also as far as I understand the isDisposing() check although harmless should not be needed if dispose is synchronous. Can you provide a test case to reproduce this if possible?

Show
Daniel Feist added a comment - - edited Francis: From what I see dispose() is already synchronized, also as far as I understand the isDisposing() check although harmless should not be needed if dispose is synchronous. Can you provide a test case to reproduce this if possible?
Hide
Permalink
Francis Upton added a comment -

The dispose was not synchronized in 2.1.2 which is the version I was testing with, I also looked at the 2.2 branch and thought I saw that it was not synchronized. There are two separate problems here:

1) the currently executing phase: start, this is fixed by synchronizing the dispose.

2) the exception 'dispose' has already executed, the synchronize alone will not fix this as another thread could call dispose() while it is being disposed or later. That's what the isDisposed() check is for.

And I'm sorry, I don't have the bandwidth right now to create a separate test case. I hit these problems regularly in my product's testing, but those test cases are intertwined with my product's tests.

Andrew - in the future I will submit patches that way.

Show
Francis Upton added a comment - The dispose was not synchronized in 2.1.2 which is the version I was testing with, I also looked at the 2.2 branch and thought I saw that it was not synchronized. There are two separate problems here: 1) the currently executing phase: start, this is fixed by synchronizing the dispose. 2) the exception 'dispose' has already executed, the synchronize alone will not fix this as another thread could call dispose() while it is being disposed or later. That's what the isDisposed() check is for. And I'm sorry, I don't have the bandwidth right now to create a separate test case. I hit these problems regularly in my product's testing, but those test cases are intertwined with my product's tests. Andrew - in the future I will submit patches that way.
Hide
Permalink
Daniel Feist added a comment -

I've checked and it's synchronized in latest version of all current code lines: 2.1.x, 2.2.x and 3.x.

> the synchronize alone will not fix this as another thread could call dispose() while it is being disposed or later
I don't understand this..any other threads will be waiting and by the time the first thread finishes and another thread enters isDisposed with return true.

Show
Daniel Feist added a comment - I've checked and it's synchronized in latest version of all current code lines: 2.1.x, 2.2.x and 3.x. > the synchronize alone will not fix this as another thread could call dispose() while it is being disposed or later I don't understand this..any other threads will be waiting and by the time the first thread finishes and another thread enters isDisposed with return true.
Hide
Permalink
Francis Upton added a comment -

Here is the code from the2.1.2 zip file, the revision on DefaultMuleContext is 12747, so it's possible someone already fixed the code lines. Note the original code does not have isDisposed() only isDisposing() which does not prevent the problem.

public void dispose()
{
if (isDisposing())

{ return; }

ServerNotificationManager notificationManager = getNotificationManager();

Show
Francis Upton added a comment - Here is the code from the2.1.2 zip file, the revision on DefaultMuleContext is 12747, so it's possible someone already fixed the code lines. Note the original code does not have isDisposed() only isDisposing() which does not prevent the problem. public void dispose() { if (isDisposing()) { return; } ServerNotificationManager notificationManager = getNotificationManager();
Hide
Permalink
Daniel Feist added a comment -

This was fixed in MULE-3727 for 2.1.4 (not yet released), and 2.2.2.

Show
Daniel Feist added a comment - This was fixed in MULE-3727 for 2.1.4 (not yet released), and 2.2.2.

People

  • Assignee:
    Daniel Feist
    Reporter:
    Francis Upton
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: