The simplest path forward is to increase your JVM's heap, say to 3GB or 4GB. As long as the broker's steady-state utilization (after triggering a full GC) remains relatively constant over time (more precisely, the steady state utilization doesn't rise consistently over time), then increasing the heap isn't a problem.
The only concern would be if the steady-state utilization rises over time (indicating a possible memory leak), in which case increasing the heap is simply prolonging the inevitable and not solving the problem. But as long as you're not seeing that afterwards, increasing the heap is a reasonable solution. Tim On Mon, Apr 13, 2020, 4:29 PM hfridhi <haythem.fri...@gmail.com> wrote: > Hello guys, > I know it could be shocking problem but it happened to me and I'm confused > too. > I started a broker to which I'm intensively sending messages through WS and > consuming them by a camel embedded route. > At a certain time, I'm facing "gc overhead limit exceeded java". > I tried to restart the broker and follow its memory using visualVM and I > got > this > < > http://activemq.2283324.n4.nabble.com/file/t379890/Screenshot_2020-04-14_at_00.png> > > This means that even without any call, memory is already at a high level > and > calling GC manually have no considerable effect. > > PS: Below is my Java configuration of AMQ > > > > Thank you for you help. > > > > -- > Sent from: > http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html >
