Github user franz1981 commented on the issue:
    > 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 
    > 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 
    Sure buddy, this is not a fix so we can arrive on it taking the right time
    > 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: 


Reply via email to