[
https://issues.apache.org/jira/browse/DIRMINA-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129662#comment-14129662
]
Emmanuel Lecharny commented on DIRMINA-509:
-------------------------------------------
Postponed to 3.0.
> DatagramConnector.connect() is slow compared to connect() with
> java.net.DatagramSocket
> --------------------------------------------------------------------------------------
>
> Key: DIRMINA-509
> URL: https://issues.apache.org/jira/browse/DIRMINA-509
> Project: MINA
> Issue Type: Improvement
> Components: Transport
> Affects Versions: 1.1.6, 2.0.0-M1
> Reporter: Wilson Yeung
> Fix For: 3.0.0-M3
>
>
> I benchmarked Mina 2.0's NioDatagramConnector vs java.net.DatagramSocket on a
> Linux 2.6 kernel.
> Mina 2.0 NioDatagramConnector, connect(), future.addListener(),
> session.close()
> 100,000 iterations
> ~20 seconds
> ~5,000 per second
> java.net.DatagramSocket, connect(), disconnect(), close()
> 100,000 iterations
> ~2-3 seconds
> ~30,000 to 50,000 per second
> I believe the basic problem is that
> AbstractPollingIoConnector/AbstractPollingIoProcessor assumes that connecting
> a UDP datagram socket should be a scheduled operation. For TCP, this makes a
> lot of sense as connect() should be an asynchronous operation.
> But for UDP, where connect() only performs kernel resource reservation, it
> makes more sense I think to connect immediately and return an IoFuture with
> the IoSession already connected and ready. Looking at the code, I see that
> the connect() call is indeed made on the same call stack, but
> ConnectFuture.setSession() is executed by the AbstractPollingIoProcessor
> worker thread after the IoSession has been properly registered.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
