I highly recommend you using check-leak.. you would have found what's
leaking already.
https://github.com/check-leak/check-leak
java -jar check-leak-0.10.jar remote --pid --report
--sleep 5000
( I suggest using 5 seconds for your test)
I would even write a unit-test for memory-leaks.
On Fr
So I’m getting a bit closer. The leak is in PostOfficeImpl and QueueInfo.
QueueInfo contains the filterStrings List which appears to contain a list of
filters used by consumers subscribed to that queue. However, for some reason
this list is updated in a very strange way. For one or two consumers
Hello all.
I know it’s not ideal but the broker is doing just fine (except for the leak
issue of course).
I’ve tried upgrading to 2.30.0 and the broker still ends up on its knees given
enough load and only a little heap. In my testing case I’ve limited the heap
size to 64 MiB so that I wouldn'