Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1918
@clebertsuconic
> SoftReference sucks. It usually let you OME before itâs released.
I know and i was too hurried to say that it could be used :P you're right
:+1:
> What about having a pool somewhere else? Or a smaller pool from Netty?
It could be a solution: TBH if we found together a solution that doesn't
require much (Netty) config from the user pov, would be even better!
> Iâm out today and Monday. Can we talk about this when I get back on
Tuesday?
Sure buddy, this is not a fix so we can arrive on it taking the right time
@tabish121
> It doesn't look like the buffer could be contended
On Tuesday with @clebertsuconic will be confirmed, but thanks...the code
was really too complex for just a simple behaviour ie reuse a buffer.
> It isn't entirely uncommon for consumers to be subscribed to low volume
queues or topics where they might sit idle for a longer period of time so
having each consumer hold onto memory like that indefinitely could lead to
quick resource exhaustion on the broker in the case of 1000s of connections
(think IoT)
That's important to know, yes, it makes sense!
So a solution could be to use a scheduled sweeper that check the alive
consumers, but idle for "too long" and deallocate their buffers or maybe making
use of something that the AMQP protocol itself probably provide (a keepalive,
tick or similar, don't know) to do the same.
Just thinking loud; anyway, I will let this PR rest a bit and we could have
a chat together next week if something here could be done :+1:
---
