[ https://issues.apache.org/jira/browse/DIRMINA-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Serge Baranov updated DIRMINA-665: ---------------------------------- Attachment: uniqueid.patch Patch with a temporary fix to this problem is attached. > AbstractIoSession#getId() can cause collisions which lead to sessionClosed > calls without sessionCreated > ------------------------------------------------------------------------------------------------------- > > Key: DIRMINA-665 > URL: https://issues.apache.org/jira/browse/DIRMINA-665 > Project: MINA > Issue Type: Bug > Components: Core > Affects Versions: 2.0.0-M4 > Reporter: Serge Baranov > Fix For: 2.0.0-RC1 > > Attachments: DuplicateSessionTest.java, uniqueid.patch > > > While investigating the root case of the problem described at > http://www.nabble.com/Counting-connections-in-MINA-tt22200162.html I found > that it's most likely caused by the collisions of the session ids. > See org.apache.mina.core.service.IoServiceListenerSupport#fireSessionCreated: > // If already registered, ignore. > if (managedSessions.putIfAbsent(Long.valueOf(session.getId()), session) != > null) { > return; > } > If the new created session has the same id as the one already managed by the > service, this method returns and sessionCreated/sessionOpened are not invoked > in the IoHandler. It's not surprising as the JavaDoc for getId() says: > TODO this method implementation is totally wrong. It has to be rewritten. > This problem is pretty serious as under heavy load you will get several > collisions per hour. Basically, you will get sessionClosed with empty > attributes map which will not correspond to any sessionOpened/sessionCreated. > Which leads to inability to track anything via session attributes (consider a > simple counter for connected IP addresses which gives you a number of users > connected per IP). > There is probably also some race condition as in some cases duplicate id > doesn't cause such problem. It must be investigated further. > I've rewritten the getId() method to use AtomicLong incremented in the > constructor of the class and it has fixed the problem for me. > I'm attaching the test case which reproduces the problem on my machine. You > may need to run it several times to get the expected result or adjust the > number of created sessions and the packet size. > Sample output with current getId() implementation: > [2009-03-01 01:06:43,070] START > [2009-03-01 01:06:44,503] DUPLICATE SESSION CLOSED WITHOUT CREATED/OPEN: > (0x01028859: nio socket, server, null => null) / DUPLICATE ID: true > [2009-03-01 01:06:47,172] DUPLICATE SESSION CLOSED WITHOUT CREATED/OPEN: > (0x012BDC2C: nio socket, server, null => null) / DUPLICATE ID: true > [2009-03-01 01:06:51,187] DUPLICATE SESSION CLOSED WITHOUT CREATED/OPEN: > (0x012C0881: nio socket, server, null => null) / DUPLICATE ID: true > [2009-03-01 01:06:55,398] FINISH > Sample output with getId() implementation using AtomicLong(): > [2009-03-01 01:08:00,728] START > [2009-03-01 01:08:12,653] FINISH > I have no time for additional investigations for now, hope it helps. > The proposed solution is to either rewrite id generation or make the behavior > consistent in case duplicate id is generated. Duplicate ids should not stop > the application from normal operation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.