Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DMLC async stop notification is not fired after calls to stop() [SPR-5198] #9871

Closed
spring-projects-issues opened this issue Oct 3, 2008 · 3 comments
Assignees
Labels
in: messaging Issues in messaging modules (jms, messaging) type: bug A general bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Oct 3, 2008

Ben Rowlands opened SPR-5198 and commented

The async stop listener provided in #9092 is not actually fired after a call to stop().

Once stop is called() the DMLC threads notice isRunning is false and park themselves inside waitWhileNotRunning(). This method blocks until the DMLC is de-actived (as a result of calling shutdown) or the DMLC is re-started.

The attached test case demonstrates the issue.

It looks like waitWhileNotRunning() should probably call the async-stop runnable once all processor threads get to that point or isActive() should return false after a call to stop()?


Affects: 2.5.5

Attachments:

Issue Links:

2 votes, 4 watchers

@spring-projects-issues
Copy link
Collaborator Author

Michael Robinson commented

I can verify that I am seeing the same behavior. If it is helpful I also have a related forum post here:

http://forum.springframework.org/showthread.php?t=59990

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

This problem actually only shows with the default TaskExecutor, where invoker threads keep running and waiting. If you specify a SchedulingTaskExecutor (any of the thread-pooling ones), then DefaultMessageListenerContainer will automatically use a shorter maxMessagesPerTask setting that allows invoker threads to return to the pool - and also to invoke the stop notification.

So for the time being, try specifying an thread-pooling TaskExecutor. I'll see what I can do to invoke the stop notification for the default TaskExecutor as well.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

I've added the stop notification capability for ongoing loops (i.e. unlimited maxMessagesPerTask which is the default when not using an external TaskExecutor) as well now.

This will be available in tonight's 2.5.6 snapshot. Please give it a try and let me know whether it works for you!

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: messaging Issues in messaging modules (jms, messaging) type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants