Issue Details (XML | Word | Printable)

Key: MULE-3390
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Blocker Blocker
Assignee: Daniel Feist
Reporter: Dimitar Dimitrov
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Mule

Disposing the context does not dispose the NotificationsManager, which in turn holds the work manager

Created: 22/May/08 05:38 AM   Updated: 23/May/08 07:52 AM
Component/s: Core: Concurrency / Threading
Affects Version/s: 2.0.1
Fix Version/s: 2.0.2

Time Tracking:
Issue & Sub-Tasks
Issue Only
Not Specified

File Attachments: 1. Java Source File StartStopper.java (2 kB)


Labels:
User impact: Medium

Sub-Tasks  All   Open   

 Description  « Hide
When creating and disposing any mule context, the ServerNotificationManager blocks a thread from the work manager, waiting on the event queue. The exit condition is that the disposed flag becomes true, but it's checked only after we dispatch an async event. The fireNotification() method discards any events fired after we set dispose to true, effectively making sure that the thread is never released.

A solution could be to interrupt the thread on shutdown or to put a poison pill in the event queue on disposal.

A class demonstrating a workaround (and the issue itself) is attached. The last 2 lines in the main method should not be needed.

The issue impacts any applications that embed MuleContext and do not call System.exit() in order to terminate.



 All   Comments   Work Log   Change History   Transitions   FishEye      Sort Order: Ascending order - Click to sort in descending order
Dimitar Dimitrov added a comment - 22/May/08 05:39 AM
Also would be nice if the notification manager logged the dropped notifications with level DEBUG ot TRACE.

Daniel Feist added a comment - 22/May/08 07:56 AM
Hi,
You don't happen to have a failing test case do you? That why I can compare a fix to what you expect and get this in quicker.

Dimitar Dimitrov added a comment - 22/May/08 10:40 AM
As I mentioned, if you remove the last 2 lines from the main() method, it doesn't terminate.
class StartNoStop {
    public static void main(String[] args) throws MuleException, InterruptedException {
        MuleContext ctx = new DefaultMuleContextFactory().createMuleContext();
        ctx.start();
        ctx.stop();
        ctx.dispose();
    }
}

Dimitar Dimitrov added a comment - 22/May/08 10:53 AM
And another one:
class StartNoStop {
    public static void main(String[] args) throws MuleException  {
        MuleClient mc = new MuleClient(); // should create an empty context
        mc.dispose();
    }
}

Does not terminate


Daniel Feist added a comment - 22/May/08 03:11 PM
This is serious, I'm surprised it hasn't appeared in any of out unit tests, these don't use System.exit() and start and stop mule via MuleContext. I'll take a look. Can you clarify what you mean by the "dropped notifications"?
thanks.


Dimitar Dimitrov added a comment - 22/May/08 06:31 PM
Right not the fireNotification() method silently returns if the notification manager has been disposed. Instead of this, it would help debugging in any such calls were logged either as TRACE (if we assume it's normal condition) or as WARN (which would help us fix the code that fired the notification in the first place)

Also, somewhere in the dispatching code in the notif manager, there was another check which would cause it to ignore notifications after disposal, even if they made it in the queue. That's bad, since it's not deterministic. Ideally the NM should dispatch all pending notifications before disposal (we still need to think about timeouts).


Daniel Feist added a comment - 22/May/08 07:02 PM
OK, I'll try to take a look at this sometime ... alternatively feel free to submit a patch by attaching it to this issue.

Daniel Feist added a comment - 23/May/08 07:52 AM
Applied your patch to log missing notifications. Not done anything to "dispatch all pending notifications before disposal" though...