[
https://issues.apache.org/jira/browse/DIRMINA-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serge Baranov updated DIRMINA-665:
----------------------------------
Attachment: DuplicateSessionTest.java
A test case illustrating the collisions problem and sessionClosed call without
sessionCreated call.
> 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
>
>
> 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.
