Well.
Our admin was unable configure server for connecting from jconsole. But i
read that 5.13.2 since 5.10.1 have many memory and cpu consuming fixes, we
update ActiveMQ and problem no longer appeared.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/ActiveMQ-hangs-and-i-
For the JMX: there is a newer setting in the activemq configuration file
that may override the command-line settings; here's a fairly stock example:
Check for these and any output during broker starting indicating the
management context failed to start -- if both
We use standalone broker, because we write our applications in PHP. And we
don't use custom plugins.
I try configure jmx for jconsole, on localhost all works well, but i can't
connect to server over vpn.
I use this manual: http://activemq.apache.org/jmx.html
And here ACTIVEMQ_SUNJMX_START variabl
Messages consumed fast, never seen more than 30 messages in queue. 90% of
time i see 0 messages in all queues and only consumed counter inreases.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/ActiveMQ-hangs-and-i-don-t-understand-why-tp4709963p4709978.html
Sent from the
Catch this situation again. Even web-console hangs. But this time no info
even in log, only startup log info.
Maybe openjdk is not the best choice?
java -version
openjdk version "1.7.0_80"
OpenJDK Runtime Environment (build 1.7.0_80-b15)
OpenJDK 64-Bit Server VM (build 24.80-b11, mixed mode)
Or A
Keep in mind that large numbers unconsumed messages stuck in the DLQ count
as a slow consumer and will use broker memory.
Is Producer Flow Control enabled? If so, what limits are you using?
What's your heap size? And how much of it is being used right after the
broker restarts?
On Mar 27, 2016
Is the AMQ broker embedded? If so, perhaps another application is leaking
memory.
Or, are there any custom plugins?
Bottom line here - there is something taking up all of the memory, causing
the OOM condition. Taking heap dumps and/or histograms may be the only
quick way to find out just what's
BTW, once the JVM reaches the out-of-memory condition, it can become
impossible to perform any operations on it - such as obtaining stack dumps
and heap dumps. With that said, a heap dump, or at least histogram, can
help determine the precise cause of the out-of-memory condition.
The jmap program
OutOfMemory most commonly occurs with slow consumption.
The broker can run out of memory if messages are produced to it too quickly
and consumers don't keep up. It will also run out of memory if massive
transactions are used and not committed nor rolled back before the broker's
memory is exhauste
