[jira] [Closed] (SSHD-1280) Clarification of ConnectFuture#cancel(), AuthFuture#cancel(), OpenFuture#cancel behaviours if connection,auhentication,channel open are already done respectively
[
https://issues.apache.org/jira/browse/SSHD-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein closed SSHD-1280.
Resolution: Information Provided
> Clarification of ConnectFuture#cancel(), AuthFuture#cancel(),
> OpenFuture#cancel behaviours if connection,auhentication,channel open are
> already done respectively
> -
>
> Key: SSHD-1280
> URL: https://issues.apache.org/jira/browse/SSHD-1280
> Project: MINA SSHD
> Issue Type: Documentation
>Affects Versions: 2.8.0
> Environment: Java SE 8, NetBeans IDE 8.2
>Reporter: dgü
>Priority: Major
>
> Hello!
>
> {code:java}
> /**
> * Cancels the connection attempt and notifies all threads waiting for
> this future.
> */
> void cancel();
> {code}
> Ref:
> [https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/future/ConnectFuture.java]
> {code:java}
> /**
> * Cancels the authentication attempt and notifies all threads waiting
> for this future.
> */
> void cancel();
> {code}
> Ref:
> [https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/future/AuthFuture.java]
> According to my tests;
> * ConnectFuture#cancel() cancels client session connection attempt only if
> connection is not established yet. If connection is established, it doesn't
> cancel.
> * AuthFuture#cancel() cancels client authentication attempt only if
> authentication is not completed yet. If authentication is completed, it
> doesn't cancel.
> are these behaviours are expected ? If so, it is possible to update the
> documentation to rely on these behaviours ?
> Thanks in advance!
--
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
[jira] [Commented] (SSHD-1280) Clarification of ConnectFuture#cancel(), AuthFuture#cancel(), OpenFuture#cancel behaviours if connection,auhentication,channel open are already done respectively
[
https://issues.apache.org/jira/browse/SSHD-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569606#comment-17569606
]
Lyor Goldstein commented on SSHD-1280:
--
I disagree with the need to re-phrase the documentation - I believe it defines
+exactly+ the method's behavior. Obviously, if a channel is already open then
cancelling an {{OpenFuture}} should have no effect on it. This is a slippery
slope - why not also request to document the fact that if the session has been
closed, or the channel has been closed 1 hour ago then {{OpenFuture#cancel}}
has no effect. No offenses, but one does not document that 2+2 = 4...
> Clarification of ConnectFuture#cancel(), AuthFuture#cancel(),
> OpenFuture#cancel behaviours if connection,auhentication,channel open are
> already done respectively
> -
>
> Key: SSHD-1280
> URL: https://issues.apache.org/jira/browse/SSHD-1280
> Project: MINA SSHD
> Issue Type: Documentation
>Affects Versions: 2.8.0
> Environment: Java SE 8, NetBeans IDE 8.2
>Reporter: dgü
>Priority: Major
>
> Hello!
>
> {code:java}
> /**
> * Cancels the connection attempt and notifies all threads waiting for
> this future.
> */
> void cancel();
> {code}
> Ref:
> [https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/future/ConnectFuture.java]
> {code:java}
> /**
> * Cancels the authentication attempt and notifies all threads waiting
> for this future.
> */
> void cancel();
> {code}
> Ref:
> [https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/future/AuthFuture.java]
> According to my tests;
> * ConnectFuture#cancel() cancels client session connection attempt only if
> connection is not established yet. If connection is established, it doesn't
> cancel.
> * AuthFuture#cancel() cancels client authentication attempt only if
> authentication is not completed yet. If authentication is completed, it
> doesn't cancel.
> are these behaviours are expected ? If so, it is possible to update the
> documentation to rely on these behaviours ?
> Thanks in advance!
--
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
[jira] [Assigned] (SSHD-1279) Is it possible to detect Input protocol is scp and sftp at provider level?
[ https://issues.apache.org/jira/browse/SSHD-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-1279: Assignee: Lyor Goldstein > Is it possible to detect Input protocol is scp and sftp at provider level? > -- > > Key: SSHD-1279 > URL: https://issues.apache.org/jira/browse/SSHD-1279 > Project: MINA SSHD > Issue Type: Question >Reporter: Sandeep >Assignee: Lyor Goldstein >Priority: Major > > Hi Team, > For sftp server side I need to check whether the input protocol is SCP and > SFTP. Can any one help me how to do at the FileSystemProvider level or any > other option? > ~Sandeep -- 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
[jira] [Resolved] (SSHD-1279) Is it possible to detect Input protocol is scp and sftp at provider level?
[ https://issues.apache.org/jira/browse/SSHD-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-1279. -- Resolution: Information Provided > Is it possible to detect Input protocol is scp and sftp at provider level? > -- > > Key: SSHD-1279 > URL: https://issues.apache.org/jira/browse/SSHD-1279 > Project: MINA SSHD > Issue Type: Question >Reporter: Sandeep >Assignee: Lyor Goldstein >Priority: Major > > Hi Team, > For sftp server side I need to check whether the input protocol is SCP and > SFTP. Can any one help me how to do at the FileSystemProvider level or any > other option? > ~Sandeep -- 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
[jira] [Commented] (SSHD-1279) Is it possible to detect Input protocol is scp and sftp at provider level?
[
https://issues.apache.org/jira/browse/SSHD-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569603#comment-17569603
]
Lyor Goldstein commented on SSHD-1279:
--
Easy - {{FileSystemProvider}} cannot be implemented over standard SCP as the
protocol lacks most of the required primitives for its implementation. One
could implement it using SCP + SHELL, but not over pure SCP. Therefore, if it
is a functional {{FileSystemProvider}} then it +must+ be SFTP.
> Is it possible to detect Input protocol is scp and sftp at provider level?
> --
>
> Key: SSHD-1279
> URL: https://issues.apache.org/jira/browse/SSHD-1279
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Sandeep
>Priority: Major
>
> Hi Team,
> For sftp server side I need to check whether the input protocol is SCP and
> SFTP. Can any one help me how to do at the FileSystemProvider level or any
> other option?
> ~Sandeep
--
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
Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)
On 21/07/2022 15:38, Christoph John wrote:
Hi Emmanuel,
I took a look at this and it seems the two latches were a red herring.
One is for the initiator (connector) and the other one for the acceptor
that are used in the unit test.
I must admit I haven't spent enough time to unerstand what was going on ;-)
However, I think I found the root cause for the failing unit tests. We
have an AbstractIoHandler which extends IoHandlerAdapter. In its
exceptionCaught() method we do some magic and in the end disconnect the
session. You can see that here:
https://github.com/quickfix-j/quickfixj/pull/441/files#diff-ecbb4c6b07934a11f46ceae43478dc258e7dfcaedad8c67881c7441848f8909d
Now when I exchange the closeNow() with closeOnFlush() the unit tests
succeed, meaning that the registered filter is notified of the Exception.
Is this expected?
The closeNow is pretty brutal. In case of a TLS failure, the SSLEngine
generates a message that *must* be sent to the remote peer. This message
is a TLS alert, and it cntains the rooot cause of the failure.
Closing the connection brutally will not allow this message to be sent,
so doing a close n flush will guarantee that *every* message stored in
the queue qill be sent.
So, yes, this is the way to go.
Did this behaviour change intentionally?
No.
Is it safe to
always use closeOnFlush()?
It should be.
(probably I should wait for the returned
CloseFuture to complete for a sensible amount of time)
Thanks in advance and best regards
Chris.
On 16.07.22 05:30, Emmanuel Lécharny wrote:
Hi Christoph,
after further analysis, it appears that we have 2 countdown latch
instances (exceptionThrownLatch) at play:
* one that is decremented in the exceptionCaught event,
[Count1]>:1]--->PKIX path validation failed:
java.security.cert.CertPathValidatorException: signature check failed
[Count0]>:0<]---
* and the other one that is checked for the exfeption being received:
[Count:1 in
assert
As you can see, the instances ID are different: b9ed2fa and 8458f04.
Seems like the handler you have added in teh chain is not owning the
same latch that the one being checked in the assert, now to see why...
On 13/07/2022 17:43, Emmanuel Lécharny wrote:
Hi Christoph,
actually, there is a kind of race condition in your test.
I have added some logs:
@Override
public void exceptionCaught(NextFilter nextFilter,
IoSession session, Throwable cause)
throws Exception {
System.out.println("[Count:"+exceptionThrownLatch.getCount()+"]--->"
+ cause.getMessage());
//LOGGER.info("exceptionCaught", cause);
exceptionThrownLatch.countDown();
System.out.println("[Count:"+exceptionThrownLatch.getCount()+"<]---");
nextFilter.exceptionCaught(session, cause);
}
which generates:
[Count:1]--->PKIX path validation failed:
java.security.cert.CertPathValidatorException: signature check failed
[Count:0<]---
after the initiator.start() call. So the latch is properly
decremented and the initiator.assertSslExceptionThrown() should be
valid:
public void assertSslExceptionThrown() throws Exception {
System.out.println("[Count:"+exceptionThrownLatch.getCount()+" in
assert");
boolean reachedZero =
exceptionThrownLatch.await(TIMEOUT_SECONDS, TimeUnit.SECONDS);
if (!reachedZero) {
throw new AssertionError("No SSL exception thrown");
}
and weird enough, the latch counter is 1 ! (ie, the counter is
*not* decremented)
Here are the complete logs (check the 'Count' string):
juil. 13, 2022 5:33:12 PM
quickfix.mina.ssl.SSLCertificateTest$TestAcceptor createConnector
INFOS: Creating acceptor: [DEFAULT]
SocketUseSSL=Y
EndTime=00:00:00
ReconnectInterval=2
SocketAcceptPort=50957
SocketTrustStore=single-session/server.truststore
NeedClientAuth=Y
EnabledProtocols=TLSv1.2
SocketAcceptHost=localhost
CipherSuites=TLS_RSA_WITH_AES_128_CBC_SHA
ConnectionType=acceptor
StartTime=00:00:00
SocketKeyStorePassword=password
SocketConnectProtocol=SOCKET
KeyStoreType=JKS
SocketKeyStore=single-session/server.keystore
SocketTrustStorePassword=password
TrustStoreType=JKS
HeartBtInt=30
[SESSION]
BeginString=FIX.4.4
SenderCompID=ALFA
TargetCompID=ZULU
DataDictionary=FIX44.xml
juil. 13, 2022 5:33:14 PM quickfix.DefaultSessionSchedule
INFOS: [FIX.4.4:ALFA->ZULU] daily, 00:00:00-UTC - 00:00:00-UTC
<20220713-15:33:14, FIX.4.4:ALFA->ZULU, event> (Session
FIX.4.4:ALFA->ZULU schedule is daily, 00:00:00-UTC - 00:00:00-UTC)
<20220713-15:33:14, FIX.4.4:ALFA->ZULU, event> (Created session:
FIX.4.4:ALFA->ZULU)
juil. 13, 2022 5:33:14 PM quickfix.mina.SessionConnector
startSessionTimer
INFOS: SessionTimer started
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option:
Re: [VOTE] Release Apache Mina SSHD 2.9.0 (2nd try)
+1 Le lun. 18 juil. 2022 à 09:51, Guillaume Nodet a écrit : > > I've staged another candidate release at: > https://repository.apache.org/content/repositories/orgapachemina-1076 > Git tag: > https://github.com/apache/mina-sshd/tree/sshd-2.9.0 > Issues solved: > https://github.com/apache/mina-sshd/blob/sshd > -2.9.0/docs/changes/2.9.0.md > > Please review and vote ! > > -- > > Guillaume Nodet > > -- Guillaume Nodet
Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)
Hi Emmanuel,
I took a look at this and it seems the two latches were a red herring. One is for the initiator
(connector) and the other one for the acceptor that are used in the unit test.
However, I think I found the root cause for the failing unit tests. We have an AbstractIoHandler
which extends IoHandlerAdapter. In its exceptionCaught() method we do some magic and in the end
disconnect the session. You can see that here:
https://github.com/quickfix-j/quickfixj/pull/441/files#diff-ecbb4c6b07934a11f46ceae43478dc258e7dfcaedad8c67881c7441848f8909d
Now when I exchange the closeNow() with closeOnFlush() the unit tests succeed, meaning that the
registered filter is notified of the Exception.
Is this expected? Did this behaviour change intentionally? Is it safe to always use closeOnFlush()?
(probably I should wait for the returned CloseFuture to complete for a sensible amount of time)
Thanks in advance and best regards
Chris.
On 16.07.22 05:30, Emmanuel Lécharny wrote:
Hi Christoph,
after further analysis, it appears that we have 2 countdown latch instances (exceptionThrownLatch)
at play:
* one that is decremented in the exceptionCaught event,
[Count:1]--->PKIX path
validation failed: java.security.cert.CertPathValidatorException: signature check failed
[Count:0<]---
* and the other one that is checked for the exfeption being received:
[Count:1 in assert
As you can see, the instances ID are different: b9ed2fa and 8458f04.
Seems like the handler you have added in teh chain is not owning the same latch that the one being
checked in the assert, now to see why...
On 13/07/2022 17:43, Emmanuel Lécharny wrote:
Hi Christoph,
actually, there is a kind of race condition in your test.
I have added some logs:
@Override
public void exceptionCaught(NextFilter nextFilter, IoSession session, Throwable
cause)
throws Exception {
System.out.println("[Count:"+exceptionThrownLatch.getCount()+"]--->" +
cause.getMessage());
//LOGGER.info("exceptionCaught", cause);
exceptionThrownLatch.countDown();
System.out.println("[Count:"+exceptionThrownLatch.getCount()+"<]---");
nextFilter.exceptionCaught(session, cause);
}
which generates:
[Count:1]--->PKIX path validation failed:
java.security.cert.CertPathValidatorException: signature check failed
[Count:0<]---
after the initiator.start() call. So the latch is properly decremented and the
initiator.assertSslExceptionThrown() should be valid:
public void assertSslExceptionThrown() throws Exception {
System.out.println("[Count:"+exceptionThrownLatch.getCount()+" in assert");
boolean reachedZero = exceptionThrownLatch.await(TIMEOUT_SECONDS,
TimeUnit.SECONDS);
if (!reachedZero) {
throw new AssertionError("No SSL exception thrown");
}
and weird enough, the latch counter is 1 ! (ie, the counter is *not*
decremented)
Here are the complete logs (check the 'Count' string):
juil. 13, 2022 5:33:12 PM quickfix.mina.ssl.SSLCertificateTest$TestAcceptor
createConnector
INFOS: Creating acceptor: [DEFAULT]
SocketUseSSL=Y
EndTime=00:00:00
ReconnectInterval=2
SocketAcceptPort=50957
SocketTrustStore=single-session/server.truststore
NeedClientAuth=Y
EnabledProtocols=TLSv1.2
SocketAcceptHost=localhost
CipherSuites=TLS_RSA_WITH_AES_128_CBC_SHA
ConnectionType=acceptor
StartTime=00:00:00
SocketKeyStorePassword=password
SocketConnectProtocol=SOCKET
KeyStoreType=JKS
SocketKeyStore=single-session/server.keystore
SocketTrustStorePassword=password
TrustStoreType=JKS
HeartBtInt=30
[SESSION]
BeginString=FIX.4.4
SenderCompID=ALFA
TargetCompID=ZULU
DataDictionary=FIX44.xml
juil. 13, 2022 5:33:14 PM quickfix.DefaultSessionSchedule
INFOS: [FIX.4.4:ALFA->ZULU] daily, 00:00:00-UTC - 00:00:00-UTC
<20220713-15:33:14, FIX.4.4:ALFA->ZULU, event> (Session FIX.4.4:ALFA->ZULU schedule is daily,
00:00:00-UTC - 00:00:00-UTC)
<20220713-15:33:14, FIX.4.4:ALFA->ZULU, event> (Created session:
FIX.4.4:ALFA->ZULU)
juil. 13, 2022 5:33:14 PM quickfix.mina.SessionConnector startSessionTimer
INFOS: SessionTimer started
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketTcpNoDelay=true
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketSynchronousWrites=false
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketSynchronousWriteTimeout=3
juil. 13, 2022 5:33:14 PM quickfix.mina.acceptor.AbstractSocketAcceptor
installSSL
INFOS: Installing SSL filter for 0.0.0.0/0.0.0.0:50957
juil. 13, 2022 5:33:14 PM quickfix.mina.acceptor.AbstractSocketAcceptor
startAcceptingConnections
INFOS: Listening for connections at 0.0.0.0/0.0.0.0:50957 for session(s)
