Hi Rob,
That looks exactly like it. Blimey how did you find the Jira so fast??
It's a serious question, I'm not too familiar with Jira in general (I've
raised a few but that's about it). Is there a tutorial/FAQ/idiot's guide
for finding things in Qpid Jira.
The Jira comment "Investigating other providers suggests the typical
behaviour is to make use of non-daemon threads by default" would fit
with my observation of JBoss, and it looks like Alex observed the same
with Tibco.
Looking at the latest version of Programming in Apache Qpid I noticed:
qpid.jms.daemon.dispatcher boolean false
Controls whether the Session dispatcher thread is a daemon thread or
not. If this system property is set to true then the Session dispatcher
threads will be created as daemon threads. This setting is introduced in
version 0.16.
Which suggests this behaviour was introduced in 0.16
FWIW I think that this is a good thing, and it's even better that it's
configurable. I guess it's one of those changes that one doesn't notice
until it's noticed :-)
I'm liking the latest version of Programming in Apache Qpid, it looks
like it has a lot more comprehensive documentation of the options in
general.
Thanks again for responding so fast Rob,
Frase
On 26/01/13 12:10, Rob Godfrey wrote:
On 26 January 2013 13:00, Fraser Adams <[email protected]> wrote:
Another thing I've just noticed about 0.20 Java.
The behaviour of the Thread that gets started when a MessageListener is
registered has changed some time between 0.12 and 0.20 (I'm afraid I was
stuck on 0.12 for a while so I can't say exactly which version it got
changed in).
Are you referring to this change:
https://issues.apache.org/jira/browse/QPID-3784
-- Rob
In 0.12 it was a Daemon Thread, so things bombed straight out when main
exited, in 0.20 it now appears to be a user Thread and it appears to block
at the end of main and I have to ctrl C. (I think I've got Daemon and user
the right way round...)
I only really noticed this 'cause in some of the more noddy bits of code
I've put together for tinkering I put
// Blocks here until return is pressed
try {
System.out.println("Hit Return to exit");
String s = commandLine.readLine();
} catch (Exception e) {
System.out.println ("ItemConsumer: exception: " +
e.getMessage());
e.printStackTrace ();
}
To stop things exiting immediately back in the 0.12 days, but now when I hit
return the application stays running.
I doubt it's a big deal and probably actually a useful change (TBH I'm not
sure if the JMS spec says anything about this particular Thread). I know
that JBoss Messaging behaved in this way so perhaps it's a common convention
at least.
As I say I don't think that this is an "issue" with 0.20, but it is a subtle
change that affects how JMS MessageListener clients may need to behave.
Frase
The Apache Qpid community is pleased to announce the immediate
availability of Apache Qpid 0.20.
Apache Qpid (http://qpid.apache.org) is a cross-platform enterprise
messaging solution which implements the Advanced Message Queuing
Protocol (AMQP, http://www.amqp.org). It provides brokers written in
C++ and Java, along with clients for C++, Java JMS, .Net, Python,
Ruby, and Perl.
Qpid 0.20 is available from our website:
http://qpid.apache.org/download.html
The 0.20 release includes many bug fixes and improvements. We
recommend that all users upgrade. A comprehensive list of changes in
the 0.20 release is available here:
http://qpid.apache.org/release_notes_0.20.html
Thanks to all the users and contributors who have helped to improve
Apache Qpid.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
