Sounds like the master SelectorKey HashMap owned by the Selector. This is part of the Java NIO API, not MINA.
https://docs.oracle.com/javase/7/docs/api/java/nio/channels/Selector.html You can call selector.keys() which is actually that HashMap you are referring to. I think there is a total of 3 HashMaps used by the Selector which contain SelectionKeyImpl objects. On Tue, Oct 23, 2018 at 11:05 PM jpalacios (JIRA) <[email protected]> wrote: > jpalacios created DIRMINA-1096: > ---------------------------------- > > Summary: 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 > > > 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) >
