Forcing daemon threads when using discovery transport

I see that I can add a "daemon=true" parameter to tcp broker urls to force the ActiveMQ Transport threads to be created as daemon threads. I've tested this and it works fine, e.g. "failover:(tcp://172.202.23.11:61616?daemon=true,tcp://172.202.23.11:61617?daemon=true)?initialReconnectDelay=100" Ho

Re: Using ActiveMQ for personalized chat service

I looked at this one before: http://www.igniterealtime.org/projects/smack/ -- View this message in context: http://activemq.2283324.n4.nabble.com/Using-ActiveMQ-for-personalized-chat-service-tp4688033p4688358.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Using ActiveMQ for personalized chat service

Sure. Look for XMPP client libraries; I did that a while back, but don't recall where I found them. I'll take a quick look. Does openfire have a java client library? Keep in mind, XMPP is used by almost every chat-based application out there. I'm sure you can find the requisite libs. -- Vie

Re: Problems with ActiveMQ with LevelDB and shared filesystem over NFS4

OK, digging into the code, here's how the keep-alive works with the shared-filesystem-locker: public boolean keepAlive() { return lock != null && lock.isValid() && file.exists(); } I suspect this code is either (a) ignoring the lost access to the server, or (b) blockin