Re: Broker queue attributes not displayed in jconsole with active mq 5.9.0

Aditya, I'm never going to recommend downgrading to a version that's almost six years old and for which lots of bug fixes have been made in later versions, so particularly not because you can't get JMX to work for you. And I'm especially not going to recommend that because you spent a small amoun

Re: Are all queues actively serviced or is there potential for unfair servicing?

Kevin, are you still seeing this behavior consistently? On Mon, Jun 8, 2015 at 7:37 PM, Kevin Burton wrote: > I think I’m seeing a situation where the broker isn’t sending messages on > queue A when there are a lot of messages on queue B.. > > I have consumers listening but just not receiving me

Re: If my ActiveMQ brokers are down, how do I tell my producer to stop blocking the thread?

Great! Thank you for letting me know. -- View this message in context: http://activemq.2283324.n4.nabble.com/If-my-ActiveMQ-brokers-are-down-how-do-I-tell-my-producer-to-stop-blocking-the-thread-tp4698835p4699303.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: ActiveMQ uses 100% CPU

Another thing here - what else is running in the same JVM as ActiveMQ? Also, are the messages being consumed, and are consumers keeping up with producers? -- View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-uses-100-CPU-tp4699129p4699302.html Sent from the ActiveMQ

Re: How do you destroy orphaned consumers on the server/broker?

Monitoring is very important for ActiveMQ, so it's good to hear. I've used JMX and Jolokia for that purpose. The advisories are useful for that as well. -- View this message in context: http://activemq.2283324.n4.nabble.com/How-do-you-destroy-orphaned-consumers-on-the-server-broker-tp4680431p

Re: unable to reconnect after exception "Channel was inactive for too long"

Jeff, does your keystore work fine up until the error happens and then begin failing (semi-)consistently, or does it fail with this SSL error right off the bat? On Tue, Jul 14, 2015 at 7:06 PM, Hadrian Zbarcea wrote: > Jeff, > > I would start with figuring out the reason for "PKIX path validatio

Re: unable to reconnect after exception "Channel was inactive for too long"

Jeff, I would start with figuring out the reason for "PKIX path validation failed/signature check failed". It looks like the keystore is not properly configured when attempting to reconnect. I'll try to spend some time on this tomorrow. Cheers, Hadrian On 06/16/2015 03:18 PM, jeffrey wrote

Re: How do you destroy orphaned consumers on the server/broker?

It can be done, but may be tricky. If the client is using the clientId setting, then unsubscribe should work - just pass the same clientId. Otherwise, it's a little harder - the consumer is connected to the HTTP session. As long as the session matches (I believe that's a cookie and possibly comb

Re: How do you destroy orphaned consumers on the server/broker?

Does anyone know how to do this purely through the request? I'm currently working on a Python client using the requests library, and my consumers are still getting orphaned in AMQ after session.close() -- View this message in context: http://activemq.2283324.n4.nabble.com/How-do-you-destroy-or

Re: how to disable InactivityMonitor with ActiveMQ 5.7.0.fuse-71-047 ?

Try replacing the & in your xml with & That should take care of the xml parsing. On Tue, Jul 14, 2015 at 10:37 AM, Jason Vas Dias wrote: > On 14/07/2015, Christopher Shannon > wrote: > > The useInactivityMonitor option appears to have been added in 5.3.0 and > > maxInactivityDuration

Re: how to disable InactivityMonitor with ActiveMQ 5.7.0.fuse-71-047 ?

On 14/07/2015, Christopher Shannon wrote: > The useInactivityMonitor option appears to have been added in 5.3.0 and > maxInactivityDuration even earlier than that. > Yes, but they do not work! > You can set the properties on your connection string in the client. > > For example: > > tcp://localh

Re: how to disable InactivityMonitor with ActiveMQ 5.7.0.fuse-71-047 ?

The useInactivityMonitor option appears to have been added in 5.3.0 and maxInactivityDuration even earlier than that. You can set the properties on your connection string in the client. For example: tcp://localhost:61616?transport.useInactivityMonitor=false&wireformat. maxInactivityDuration=0

Re: ActiveMQ(MQTT) crash when subscribe

So good news, it turns out if you enable debug logging there is already a check in place to log the full stack trace. Take a look at this page: http://activemq.apache.org/how-do-i-enable-debug-logging.html for instructions on how to enable debug and then you should get the full print out of the Arr

Re: how to disable InactivityMonitor with ActiveMQ 5.7.0.fuse-71-047 ?

Here's some debug output showing the timeout negotiation from the client: 2015-07-14 14:27:48,969 [main] DEBUG activemq.transport.WireFormatNegotiator - Sending: WireFormatInfo { version=9, properties={MaxFrameSize=9223372036854775807, CacheSize=1024, CacheEnabled=true, SizePrefixDisabled=false,

Re: ActiveMQ(MQTT) crash when subscribe

It's difficult to track down the cause based on what you have provided because unfortunately the full stack trace is missing for the ArrayIndexOutOfBoundsException. The broker needs to be updated to log the full stack trace which I can update. I can let you know when the latest snapshot has that

Re: ActiveMQ(MQTT) crash when subscribe

My project is very important and because of this problem it has been down. I asked many times from supporters, the answered once but it didn't help me. I really need to know how to solve the problem. I appreciate it if anybody can help. -- View this message in context: http://activemq.228332

how to disable InactivityMonitor with ActiveMQ 5.7.0.fuse-71-047 ?

Good day - I have an ActiveMQ 5.7.0.fuse-71-047 server setup with this in its at-broker-context.xml (main configuration file) : Yet still when clients connect to the broker, they end up using a non-zero timeout : 2015-07-14 13:48:27,563 [ActiveMQ InactivityMonitor Worker] WARN broker.