[ https://issues.apache.org/jira/browse/SSHD-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Wolf resolved SSHD-1295. ------------------------------- Fix Version/s: 2.9.3 Assignee: Thomas Wolf Resolution: Fixed [Github PR 315|https://github.com/apache/mina-sshd/pull/315] has been merged. > Connection attempt not canceled when a connection timeout occurs > ---------------------------------------------------------------- > > Key: SSHD-1295 > URL: https://issues.apache.org/jira/browse/SSHD-1295 > Project: MINA SSHD > Issue Type: Bug > Affects Versions: 2.9.2 > Reporter: Thomas Wolf > Assignee: Thomas Wolf > Priority: Major > Fix For: 2.9.3 > > > This is not a new bug; it's also present in earlier versions. > When {{client.connect().verify(timeout)}} times out, the underlying > asynchronous connection attempt still continues _and may still succeed_. If > that happens, there is a connection and session that the user cannot use or > close. (Short of calling verify().getSession() again, but that is a pattern I > have never seen, and it also makes using a timeout rather useless.) > This means that timeouts are inherently unreliable. > Here's a simple test case illustrating this problem (for > {{org.apache.sshd.client.ClientTest}}): > {code:java} > @Test > public void testConnectTimeout() throws Exception { > client.start(); > try { > ConnectFuture future = client.connect(getCurrentTestName(), > TEST_LOCALHOST, port); > try { > future.verify(1); > fail("Timeout expected"); > } catch (InterruptedIOException | SshException e) { > ClientSession session = null; > try { > session = future.verify(CONNECT_TIMEOUT).getSession(); > } catch (SshException e2) { > assertTrue("Expected a timeout, got " + e2, > e2.getMessage().contains("timeout")); > } > if (session != null) { > assertTrue("Session should be closed", session.isClosed() || > session.isClosing()); > } > } > } finally { > client.stop(); > } > } > {code} > This test fails. > When the {{ConnectFuture}} times out (or is canceled, or waiting is > interrupted), the underlying {{IoConnectFuture}} must be canceled. If we do > get an {{IoSession}} all the same, but the {{ConnectFuture}} is already > canceled or timed out, the {{IoSession}} must be closed immediately. > Preferrably before a {{Session}} is created at all; otherwise, that SSH > session must be closed, too. Creating a {{ClientSession}} already starts the > application-level protocol (sending the SSH ident, or if a proxy is used, the > proxy connect request). > The test also highlights another problem: there is no clear indication that > the failure of {{verify()}} indicates a timeout. Probably there should be a > dedicated exception for this, or at least the {{SshException}} should have a > {{TimeoutException}} as cause. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org