You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Robbie Gemmell <ro...@gmail.com> on 2012/01/17 13:54:54 UTC
[Java Client] MessageListeners and Dispatcher thread daemon status
Hi all,
I would like to propose a change to make the Java clients session
Dispatcher thread be set non-daemon if a MessageListener is present on
the session, with a new configuration option to allow manipulating
this behaviour.
Historically, for the 0-8/0-9/0-9-1 client the use of Mina kept the
JVM alive when a MessageListener was set, allowing asynchronous
delivery to continue without the user having taken any explicit action
to keep the JVM alive. Since we removed Mina this is no longer the
case, and if there are no non-daemon threads then the JVM will now
exit even though the user has set a MessageListener set. Investigating
other providers suggests the typical behaviour is to make use of
non-daemon threads by default, preventing this happening, but allowing
users who desire that behaviour to configure it as such.
For example, tibco seem to do exactly what I am proposing with their
Dispatcher threads:
https://docs.tibco.com/pub/enterprise_message_service/6.1.0-august-2011/doc/html/tib_ems_api_reference/api/javadoc/com/tibco/tibjms/Tibjms.html#PROP_DAEMON_DISPATCHER
ActiveMQ seems to control this through transport options, defaulting
to non-daemon threads with an option to reconfigure it:
http://activemq.apache.org/tcp-transport-reference.html
Given this seems to be the adopted practice for other JMS providers it
would seem like a good thing to standardise on, making it easier for
people to pick up Qpid and try it with existing code they might have.
Making this change is basically noticable to anyone already working
round the all-daemon-thread behaviour of the client, but not making it
could be fairly dissruptive for anyone looking to upgrade and running
into it for the first time.
Thoughts?
Robbie.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [Java Client] MessageListeners and Dispatcher thread daemon status
Posted by "Weston M. Price" <wp...@redhat.com>.
On Jan 17, 2012, at 7:54 AM, Robbie Gemmell wrote:
> Hi all,
>
> I would like to propose a change to make the Java clients session
> Dispatcher thread be set non-daemon if a MessageListener is present on
> the session, with a new configuration option to allow manipulating
> this behaviour.
>
> Historically, for the 0-8/0-9/0-9-1 client the use of Mina kept the
> JVM alive when a MessageListener was set, allowing asynchronous
> delivery to continue without the user having taken any explicit action
> to keep the JVM alive. Since we removed Mina this is no longer the
> case, and if there are no non-daemon threads then the JVM will now
> exit even though the user has set a MessageListener set. Investigating
> other providers suggests the typical behaviour is to make use of
> non-daemon threads by default, preventing this happening, but allowing
> users who desire that behaviour to configure it as such.
>
Seems reasonable to me especially given the option to turn this on or off.
> For example, tibco seem to do exactly what I am proposing with their
> Dispatcher threads:
> https://docs.tibco.com/pub/enterprise_message_service/6.1.0-august-2011/doc/html/tib_ems_api_reference/api/javadoc/com/tibco/tibjms/Tibjms.html#PROP_DAEMON_DISPATCHER
>
> ActiveMQ seems to control this through transport options, defaulting
> to non-daemon threads with an option to reconfigure it:
> http://activemq.apache.org/tcp-transport-reference.html
>
> Given this seems to be the adopted practice for other JMS providers it
> would seem like a good thing to standardise on, making it easier for
> people to pick up Qpid and try it with existing code they might have.
> Making this change is basically noticable to anyone already working
> round the all-daemon-thread behaviour of the client, but not making it
> could be fairly dissruptive for anyone looking to upgrade and running
> into it for the first time.
>
Agreed. Good research BTW for other JMS providers. Given what you have found out I think the change makes sense.
> Thoughts?
>
> Robbie.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org