Hello Emmanuel, actually it seems as if the Queue data structure continues to increase..message after message. We cannot check if the our device receive the message, the implemented protocol doesn't allow this, do you mean checking if the session goes in an IDLE state? I can add override of method "sessionIdle(IoSession, IdleStatus) to our HandlerAdapter..
*Leonardo D'Alimonte* *LOGINET s.r.l.* Diretto : +39 0227071955 Fax : +39 0227071931 Mobile : +39 3930746502 Viale Monza 270 20128 Milano Italy [email protected] www.loginet.it / [image: Not loaded] <https://www.facebook.com/pages/Loginet-SRL/897096740301055> *This message (including any attachments) may contain confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.* On Tue, Sep 1, 2015 at 3:45 PM, Emmanuel Lécharny <[email protected]> wrote: > Le 01/09/15 15:23, Leonardo D'Alimonte a écrit : > > Hi everybody, > > > > we have a web application based on Apache MINA 2.0.9 for transports of > TCP > > messages, recently it suffered for a memory leak, JDK version is 1.6.0_45 > > Analyzing the heap dump, I found a ConcurrentLinkedQueue inside a > > NioSocketSession sized 844MB and more... > > You can find attached here a screenshot taken with MAT. > > > > We have our IoHandlerAdapter that doesn't handle session IDLE events, but > > counters inside NioSocketSession for read/write events are set to 0. > > Sessions to our device managed by this HandlerAdapter are created only to > > send messages, we don't receive any message back.. > > Blind guess : the messages you write are never actually sent, they are > just enqueued. Check that the remote peer receive them, and if notn then > you should check if the session is still active before sending more > messages. > >
