activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: ActiveMQ broker becomes unresponsive after sometime
Date Tue, 23 May 2017 02:37:51 GMT
Shenandoah is aimed at large JVMs (the page that link points to says 20GB
or bigger), so I wouldn't just go trying it without understanding what its
strengths and weaknesses are.

GCEasy looks interesting, but I'm curious how they make it free and whether
there are catches. Are you associated with the company?

Can you share more about your experience with G1? In particular, was the
slow behavior during incremental Old Gen collections, or during an actual
full GC? Theoretically, G1 is supposed to avoid full GCs by doing
incremental Old Gen GCs; are you saying that you weren't able to get it to
do that?


On May 19, 2017 8:41 AM, "nigro_franz" <> wrote:


In the last period I'm enjoying using this:

You need to pass the following JVM arguments: -XX:+PrintGCDetails
-XX:+PrintGCDateStamps -Xloggc:[file-path]

With [file-path] as the location where garbage collection log should be
Then run your tests and upload the log to you'll have
tons of graphs useful to get insights on the problem.

About G1: on Artemis we found that with a too big old generations G1 wasn't
fast enough on Full GCs (are single threaded on it!) while using
-XX:+UseParallelOldGC yes, so it worth to try it.

While If you have a Fedora machine wiht OpenJDK 8 or something similar, you
have the option to use -XX:+UseShenandoahGC and find out if the problem is
really a GC related one (do not use it in production yet!).
If ShenandoahGC will solve the issue then it is very likely to be GC problem

View this message in context: http://activemq.2283324.n4.
Sent from the ActiveMQ - User mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message