[
https://issues.apache.org/jira/browse/DIRMINA-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Valliere resolved DIRMINA-993.
---------------------------------------
Resolution: Not A Problem
Not a MINA problem because it occurs in the JDK directly.
> Connecting to server occasionally fails when using TCP_NODELAY
> --------------------------------------------------------------
>
> Key: DIRMINA-993
> URL: https://issues.apache.org/jira/browse/DIRMINA-993
> Project: MINA
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.9
> Environment: Windows (tested on Vista and 7)
> Reporter: Attila Kelemen
> Priority: Major
>
> Mina sometimes fails to connect to a remote TCP server when TCP_NODELAY is
> set for a `NioSocketConnector`.
> {code:java}
> NioSocketConnector connector = new NioSocketConnector();
> try {
> connector.getSessionConfig().setTcpNoDelay(true);
> connector.setHandler(new IoHandlerAdapter());
> ConnectFuture future = connector.connect(new
> InetSocketAddress("localhost", myport));
> future.await();
> future.getSession();
> } finally {
> connector.dispose(true);
> }
> {code}
> The above code sometimes (rarely) fails with an exception (thrown by
> getSession()) with a (wrapped) "java.net.SocketException: Invalid argument:
> no further information" exception. The best way to reproduce the problem is
> to run the above code concurrently multiple times (e.g. as done by this
> method:
> https://github.com/kelemen/JTrim/blob/v1.7.3/jtrim-core/src/main/java/org/jtrim/concurrent/Tasks.java#L173).
> I have also found a simplified JDK only code which reproduces the issue (more
> reliably) where the order of JDK calls are in the same order as Mina does:
> {code:java}
> SocketChannel channel = SocketChannel.open();
> try {
> channel.configureBlocking(false);
> channel.connect(new InetSocketAddress("localhost", myport));
> channel.socket().setTcpNoDelay(true);
> } finally {
> channel.close();
> }
> {code}
> In the above code if `setTcpNoDelay` had been called before `connect` there
> is no exception thrown. Also worth noting, that it seems, that if
> `setTcpNoDelay(true)` is called again after a failure, the call seems to
> eventually succeed (possibly after many retries).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)