[
https://issues.apache.org/jira/browse/DIRMINA-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663417#comment-16663417
]
Emmanuel Lecharny commented on DIRMINA-1096:
--------------------------------------------
{{NioSocketSession}} are retained as long as the client doesn't disconnect.
This data structure holds a lot of references to other data structures, plus a
lot of internal data associated with the session :
+References+ :
* TransportMetadata
* IoProcessor
* Channel
* SelectionKey
* IoFilterChain
* IoHandler
* IoSessionConfig
* IoService
+Internal data :+
* attributes : IoSessionAttributeMap
* closeFuture : CloseFuture
* closing : boolean
* creationTime : long
* currentWriteRequest : WriteRequest
* deferDecreaseReadBuffer : boolean
* idleCountForBoth : AtomicInteger
* idleCountForRead : AtomicInteger
* idleCountForWrite : AtomicInteger
* lastIdleTimeForBoth : long
* lastIdleTimeForRead : long
* lastIdleTimeForWrite : long
* lastReadBytes : long
* lastReadMessages : long
* lastReadTime : long
* lastThroughputCalculationTime : long
* lastWriteTime : long
* lastWrittenBytes : long
* lastWrittenMessages : long
* lock : Object
* readBytes : long
* readBytesThroughput : double
* readMessages : long
* readMessagesThroughput : double
* readSuspended : boolean
* scheduledForFlush : AtomicBoolean
* scheduledWriteBytes : AtomicInteger
* scheduledWriteMessages : AtomicInteger
* sessionId : long
* writeRequestQueue : WriteRequestQueue
* writeSuspended : boolean
* writtenBytes : long
* writtenBytesThroughput : double
* writtenMessages : long
* writtenMessagesThroughput : double
If a lot of messages are waiting to be flushed, the {{writeRequestQueue}} will
itself use a lot of memory. This is typically what happens when dealing with a
slow client, or with a 'rogue' client that disconnects brutally (in this case,
the server will never be informed that the client has quit).
Bottom line, the question is rather : why are there so many sessions pending ?
If we are talking about hundred of thousands pending sessions, then the server
has to deal with such a problem. Either by 'fixing' the clients (having them
quit properly, or read the messages quick enough), or by adding some protection
on the server (and it will depend on what is the real problem with the clients).
So:
* is it a load test ?
* if so, what is this load test doing precisely ?
* otherwise, are the clients disconnecting properly ?
* are they reading the messages fast enough ?
> Massive object graph in NioSocketSession
> ----------------------------------------
>
> Key: DIRMINA-1096
> URL: https://issues.apache.org/jira/browse/DIRMINA-1096
> Project: MINA
> Issue Type: Bug
> Affects Versions: 2.0.16
> Reporter: jpalacios
> Priority: Major
>
> I'm looking at a heap dump from one of our customers where the retained heap
> size for some {{NioSocketSession}} instances is almost 1GB.
> From the looks of the dump MINA has created a massive object graph where:
> {code}
> NioSocketSession -> SelectionKeyImpl -> EpollSelectorImpl -> HashMap ->
> SelectionKeyImpl -> NioSocketSession -> ...
> {code}
> From the looks of the obeject IDs these are not loops
> Each individual object is not large by itself but at the top of the graph the
> accumulated retained size is enough to produce an OOME
> Could you help me understand how MINA can produce such a massive object
> graph? Should MINA apply any defense mechanism to prevent this??
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
