[
https://issues.apache.org/jira/browse/SSHD-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
perfah updated SSHD-1352:
-------------------------
Description:
We are seeing this stacktrace in our logs:
{code:java}
java.io.UncheckedIOException: java.io.IOException:
readDir(/TLWPT/OrderRouting/To: 31) client is closed
at
org.apache.sshd.sftp.client.impl.SftpDirEntryIterator.load(SftpDirEntryIterator.java:181)
at
org.apache.sshd.sftp.client.impl.SftpDirEntryIterator.next(SftpDirEntryIterator.java:120)
at
org.apache.sshd.sftp.client.impl.SftpDirEntryIterator.next(SftpDirEntryIterator.java:45)
at
org.apache.sshd.sftp.client.fs.SftpPathIterator.nextEntry(SftpPathIterator.java:110)
at
org.apache.sshd.sftp.client.fs.SftpPathIterator.next(SftpPathIterator.java:104)
at
org.apache.sshd.sftp.client.fs.SftpPathIterator.next(SftpPathIterator.java:39)
at java.base/java.nio.file.Files$2.next(Files.java:3802)
at java.base/java.nio.file.Files$2.next(Files.java:3790)
at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133){code}
Yet our code for detecting that the client has been closed appears to not work
(we see no recycled clients in our logs):
{code:java}
if (!clients.get(clientIdentity).isOpen()) {
...
LOGGER.debug("Recycled SFTP Client: {}", clientIdentity);
}{code}
I made a brief investigation by asking an LLM about the MINA repository, and
according to it, the apparent contradiction can be resolved when you consider
that _isOpen_ only reflects the status when you close it from the outside
(implicitly via _try-with-resources_ or explicitly by doing {_}close(){_}),
However, if the client is closed due to an internal reason (e.g. TCP connection
is closed), the closed-status appears to not propagate up.
Questions:
1. Can you confirm that this is the case? Or am I missing something?
2. Do you agree that _SshClient::isOpen_ should reflect the correct status even
if the client is closed for an internal reason?
was:
We are seeing this stacktrace in our logs:
{code:java}
java.io.UncheckedIOException: java.io.IOException:
readDir(/TLWPT/OrderRouting/To: 31) client is closed
at
org.apache.sshd.sftp.client.impl.SftpDirEntryIterator.load(SftpDirEntryIterator.java:181)
at
org.apache.sshd.sftp.client.impl.SftpDirEntryIterator.next(SftpDirEntryIterator.java:120)
at
org.apache.sshd.sftp.client.impl.SftpDirEntryIterator.next(SftpDirEntryIterator.java:45)
at
org.apache.sshd.sftp.client.fs.SftpPathIterator.nextEntry(SftpPathIterator.java:110)
at
org.apache.sshd.sftp.client.fs.SftpPathIterator.next(SftpPathIterator.java:104)
at
org.apache.sshd.sftp.client.fs.SftpPathIterator.next(SftpPathIterator.java:39)
at java.base/java.nio.file.Files$2.next(Files.java:3802)
at java.base/java.nio.file.Files$2.next(Files.java:3790)
at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133){code}
Yet our code for detecting that the client has been closed appears to not work
(we see no recycled clients in our logs):
{code:java}
if (!clients.get(clientIdentity).isOpen()) {
...
LOGGER.debug("Recycled SFTP Client: {}", clientIdentity);
}{code}
I made a brief investigation by asking an LLM about the MINA repository, and
according to it, the apparent contradiction can be resolved when you consider
that _isOpen_ only reflects the status when you close it from the outside
(implicitly via _try-with-resources_ or explicitly by doing {_}close(){_}),
However, if the client is closed due to an internal reason (e.g. TCP connection
is closed), the closed-status appears to not propagate up.
1. Can you confirm that this is the case? Or am I missing something?
2. Do you agree that _SshClient::isOpen_ should reflect the correct status even
if the client is closed for an internal reason?
> Paradoxical 'Client is closed' while SshClient::isOpen returns true
> -------------------------------------------------------------------
>
> Key: SSHD-1352
> URL: https://issues.apache.org/jira/browse/SSHD-1352
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 2.15.0
> Reporter: perfah
> Priority: Major
>
> We are seeing this stacktrace in our logs:
> {code:java}
> java.io.UncheckedIOException: java.io.IOException:
> readDir(/TLWPT/OrderRouting/To: 31) client is closed
> at
> org.apache.sshd.sftp.client.impl.SftpDirEntryIterator.load(SftpDirEntryIterator.java:181)
> at
> org.apache.sshd.sftp.client.impl.SftpDirEntryIterator.next(SftpDirEntryIterator.java:120)
> at
> org.apache.sshd.sftp.client.impl.SftpDirEntryIterator.next(SftpDirEntryIterator.java:45)
> at
> org.apache.sshd.sftp.client.fs.SftpPathIterator.nextEntry(SftpPathIterator.java:110)
> at
> org.apache.sshd.sftp.client.fs.SftpPathIterator.next(SftpPathIterator.java:104)
> at
> org.apache.sshd.sftp.client.fs.SftpPathIterator.next(SftpPathIterator.java:39)
> at java.base/java.nio.file.Files$2.next(Files.java:3802)
> at java.base/java.nio.file.Files$2.next(Files.java:3790)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133){code}
>
> Yet our code for detecting that the client has been closed appears to not
> work (we see no recycled clients in our logs):
> {code:java}
> if (!clients.get(clientIdentity).isOpen()) {
> ...
> LOGGER.debug("Recycled SFTP Client: {}", clientIdentity);
> }{code}
> I made a brief investigation by asking an LLM about the MINA repository, and
> according to it, the apparent contradiction can be resolved when you consider
> that _isOpen_ only reflects the status when you close it from the outside
> (implicitly via _try-with-resources_ or explicitly by doing {_}close(){_}),
> However, if the client is closed due to an internal reason (e.g. TCP
> connection is closed), the closed-status appears to not propagate up.
> Questions:
> 1. Can you confirm that this is the case? Or am I missing something?
> 2. Do you agree that _SshClient::isOpen_ should reflect the correct status
> even if the client is closed for an internal reason?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
