[jira] [Commented] (SSHD-1058) Improve exception logging strategy
[
https://issues.apache.org/jira/browse/SSHD-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245048#comment-17245048
]
Markus Spann commented on SSHD-1058:
Hello, when are you going to release the eagerly awaited version 2.6.0? It
contains a large number of fixes and features that many of the using
applications will benefit from. Thanks for your good work.
> Improve exception logging strategy
> --
>
> Key: SSHD-1058
> URL: https://issues.apache.org/jira/browse/SSHD-1058
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.5.0, 2.5.1
> Environment: Linux, Java 11
>Reporter: Markus Spann
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 2.6.0
>
>
> When calling flush on ChannelOutputStream, Window.waitForSpace may throw a
> WindowClosedException. This exception is always logged at error level, then
> rethrown. If Debug is enabled on the logger, the error log is issued twice
> (second time with stacktrace).
> During deinitialization it is common practice to call flush on output
> streams. Due to the asynchronous nature of the code in this library, the call
> may fail. The caller should decide how to deal with the exception and log at
> error level if needed.
> The implementation should not log at error level regardless.
> I would suggest INFO level instead (if logging at all).
>
> {code:java}
> // lines 202 ff.
> if (log.isDebugEnabled()) {
> log.info("flush({}) failed ({}) to wait for space of len={}: {}: ", this,
> e.getClass().getSimpleName(), total, e.getMessage(), e); // with stacktrace
> } else {
> log.info("flush({}) failed ({}) to wait for space of len={}: {}",
> this, e.getClass().getSimpleName(), total, e.getMessage());
> }
> throw e;
> {code}
> Thanks,
> Markus
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-981) Implement no-flow-control SFTP extension
[ https://issues.apache.org/jira/browse/SSHD-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17234457#comment-17234457 ] Markus Spann commented on SSHD-981: --- Guillaume and Lyor, thank you both! (y) > Implement no-flow-control SFTP extension > > > Key: SSHD-981 > URL: https://issues.apache.org/jira/browse/SSHD-981 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.7.0 > > > This extension has been specified by [https://tools.ietf.org/html/rfc8308] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1029) Support native PTY in SSH server
[ https://issues.apache.org/jira/browse/SSHD-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233473#comment-17233473 ] Markus Spann commented on SSHD-1029: Could we consider addressing this issue in a future release, as this is one of two issues that blocks release of version 2.6.0 (which contains 42 completed issues)? > Support native PTY in SSH server > > > Key: SSHD-1029 > URL: https://issues.apache.org/jira/browse/SSHD-1029 > Project: MINA SSHD > Issue Type: New Feature >Reporter: Guillaume Nodet >Priority: Major > Fix For: 2.6.0 > > > In order to correctly integrate with native shells, we need to open a PTY and > launch the command redirecting the streams from/to the pty. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-981) Implement no-flow-control SFTP extension
[ https://issues.apache.org/jira/browse/SSHD-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233474#comment-17233474 ] Markus Spann commented on SSHD-981: --- Could we consider addressing this issue in a future release, as this is one of two issues that blocks release of version 2.6.0 (which contains 42 completed issues)? > Implement no-flow-control SFTP extension > > > Key: SSHD-981 > URL: https://issues.apache.org/jira/browse/SSHD-981 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.6.0 > > > This extension has been specified by [https://tools.ietf.org/html/rfc8308] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1058) Improve exception logging strategy
[
https://issues.apache.org/jira/browse/SSHD-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180324#comment-17180324
]
Markus Spann commented on SSHD-1058:
[~lgoldstein] and [~gnodet] : Thank you both (y)
> Improve exception logging strategy
> --
>
> Key: SSHD-1058
> URL: https://issues.apache.org/jira/browse/SSHD-1058
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.5.0, 2.5.1
> Environment: Linux, Java 11
>Reporter: Markus Spann
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 2.6.0
>
>
> When calling flush on ChannelOutputStream, Window.waitForSpace may throw a
> WindowClosedException. This exception is always logged at error level, then
> rethrown. If Debug is enabled on the logger, the error log is issued twice
> (second time with stacktrace).
> During deinitialization it is common practice to call flush on output
> streams. Due to the asynchronous nature of the code in this library, the call
> may fail. The caller should decide how to deal with the exception and log at
> error level if needed.
> The implementation should not log at error level regardless.
> I would suggest INFO level instead (if logging at all).
>
> {code:java}
> // lines 202 ff.
> if (log.isDebugEnabled()) {
> log.info("flush({}) failed ({}) to wait for space of len={}: {}: ", this,
> e.getClass().getSimpleName(), total, e.getMessage(), e); // with stacktrace
> } else {
> log.info("flush({}) failed ({}) to wait for space of len={}: {}",
> this, e.getClass().getSimpleName(), total, e.getMessage());
> }
> throw e;
> {code}
> Thanks,
> Markus
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-1058) ChannelOutputStream#flush should not log at error level
[
https://issues.apache.org/jira/browse/SSHD-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179453#comment-17179453
]
Markus Spann edited comment on SSHD-1058 at 8/18/20, 8:09 AM:
--
Thanks for pointing out issue SSHD-977 which I was not aware of.
I utilize sshd to offer an administrative rmi console in an application. RMI
commands also get executed by scripts e.g. checking system health/status
periodically.
Every such invocation causes an error log now.
We are being called in destroy(ChannelSession) by
ChannelSession#closeImmediately0. We then go on by calling
AbstractTerminal#close which ultimately gets the WindowClosedException in
Window#waitForCondition.
I am wondering whether the solution is to NOT close the terminal after #destroy
was called?
(Our stackframes start with my.app.rmi)
{noformat}
2020-08-17 11:22:43,969 ERROR [sshd-pool-thread-10]
server.channel.ChannelSession - flush(ChannelOutputStream[ChannelSession[id=0,
recipient=0]-ServerSessionImpl[rmiadmin@/0:0:0:0:0:0:0:1:58844]]
SSH_MSG_CHANNEL_DATA) wait for space len=1 exception details
org.apache.sshd.common.channel.WindowClosedException: Already closed:
Window[server/remote](ChannelSession[id=0,
recipient=0]-ServerSessionImpl[rmiadmin@/0:0:0:0:0:0:0:1:58844])
at org.apache.sshd.common.channel.Window.waitForCondition(Window.java:304)
at org.apache.sshd.common.channel.Window.waitForSpace(Window.java:255)
at
org.apache.sshd.common.channel.ChannelOutputStream.flush(ChannelOutputStream.java:197)
at
org.apache.sshd.common.channel.ChannelOutputStream.close(ChannelOutputStream.java:271)
at
org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.close(LineDisciplineTerminal.java:306)
at java.base/sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:341)
at java.base/sun.nio.cs.StreamEncoder.close(StreamEncoder.java:161)
at java.base/java.io.OutputStreamWriter.close(OutputStreamWriter.java:258)
at java.base/java.io.PrintWriter.close(PrintWriter.java:415)
at
org.jline.terminal.impl.LineDisciplineTerminal.doClose(LineDisciplineTerminal.java:270)
at org.jline.terminal.impl.ExternalTerminal.doClose(ExternalTerminal.java:89)
at org.jline.terminal.impl.AbstractTerminal.close(AbstractTerminal.java:95)
at
my.app.rmi.server.ssh.AbstractEmbeddedShell.close(AbstractEmbeddedShell.java:569)
at my.app.rmi.server.ssh.EmbeddedShell.close(EmbeddedShell.java:270)
at
my.app.rmi.server.ssh.AbstractEmbeddedShell.destroy(AbstractEmbeddedShell.java:515)
at
org.apache.sshd.server.channel.ChannelSession.closeImmediately0(ChannelSession.java:213)
at
org.apache.sshd.common.util.closeable.Builder$1.doClose(Builder.java:47){noformat}
was (Author: spannjp):
Thanks for pointing out issue SSHD-977 which I was not aware of.
I utilize sshd to offer an administrative rmi console in an application. RMI
commands also get executed by scripts e.g. checking system health/status
periodically.
Every such invocation causes an error log now.
We are being called in destroy(ChannelSession) by
ChannelSession#closeImmediately0. We then go on by calling
AbstractTerminal#close which ultimately gets the WindowClosedException in
Window#waitForCondition.
I am wondering whether the solution is to NOT close the terminal after #destroy
was called?
(Our stackframes start with my.app.rmi)
{noformat}
2020-08-17 11:22:43,969 ERROR [sshd-pool-thread-10]
server.channel.ChannelSession - flush(ChannelOutputStream[ChannelSession[id=0,
recipient=0]-ServerSessionImpl[rmiadmin@/0:0:0:0:0:0:0:1:58844]]
SSH_MSG_CHANNEL_DATA) wait for space len=1 exception details
org.apache.sshd.common.channel.WindowClosedException: Already closed:
Window[server/remote](ChannelSession[id=0,
recipient=0]-ServerSessionImpl[rmiadmin@/0:0:0:0:0:0:0:1:58844])
at org.apache.sshd.common.channel.Window.waitForCondition(Window.java:304)
at org.apache.sshd.common.channel.Window.waitForSpace(Window.java:255)
at
org.apache.sshd.common.channel.ChannelOutputStream.flush(ChannelOutputStream.java:197)
at
org.apache.sshd.common.channel.ChannelOutputStream.close(ChannelOutputStream.java:271)
at
org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.close(LineDisciplineTerminal.java:306)
at java.base/sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:341)
at java.base/sun.nio.cs.StreamEncoder.close(StreamEncoder.java:161)
at java.base/java.io.OutputStreamWriter.close(OutputStreamWriter.java:258)
at java.base/java.io.PrintWriter.close(PrintWriter.java:415)
at
org.jline.terminal.impl.LineDisciplineTerminal.doClose(LineDisciplineTerminal.java:270)
at org.jline.terminal.impl.ExternalTerminal.doClose(ExternalTerminal.java:89)
at org.jline.terminal.impl.AbstractTerminal.close(AbstractTerminal.java:95)
at
my.app.rmi.server.ssh.AbstractEmbeddedShell.close(AbstractEmbeddedShell.java:569)
[jira] [Commented] (SSHD-1058) ChannelOutputStream#flush should not log at error level
[
https://issues.apache.org/jira/browse/SSHD-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179453#comment-17179453
]
Markus Spann commented on SSHD-1058:
Thanks for pointing out issue SSHD-977 which I was not aware of.
I utilize sshd to offer an administrative rmi console in an application. RMI
commands also get executed by scripts e.g. checking system health/status
periodically.
Every such invocation causes an error log now.
We are being called in destroy(ChannelSession) by
ChannelSession#closeImmediately0. We then go on by calling
AbstractTerminal#close which ultimately gets the WindowClosedException in
Window#waitForCondition.
I am wondering whether the solution is to NOT close the terminal after #destroy
was called?
(Our stackframes start with my.app.rmi)
{noformat}
2020-08-17 11:22:43,969 ERROR [sshd-pool-thread-10]
server.channel.ChannelSession - flush(ChannelOutputStream[ChannelSession[id=0,
recipient=0]-ServerSessionImpl[rmiadmin@/0:0:0:0:0:0:0:1:58844]]
SSH_MSG_CHANNEL_DATA) wait for space len=1 exception details
org.apache.sshd.common.channel.WindowClosedException: Already closed:
Window[server/remote](ChannelSession[id=0,
recipient=0]-ServerSessionImpl[rmiadmin@/0:0:0:0:0:0:0:1:58844])
at org.apache.sshd.common.channel.Window.waitForCondition(Window.java:304)
at org.apache.sshd.common.channel.Window.waitForSpace(Window.java:255)
at
org.apache.sshd.common.channel.ChannelOutputStream.flush(ChannelOutputStream.java:197)
at
org.apache.sshd.common.channel.ChannelOutputStream.close(ChannelOutputStream.java:271)
at
org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.close(LineDisciplineTerminal.java:306)
at java.base/sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:341)
at java.base/sun.nio.cs.StreamEncoder.close(StreamEncoder.java:161)
at java.base/java.io.OutputStreamWriter.close(OutputStreamWriter.java:258)
at java.base/java.io.PrintWriter.close(PrintWriter.java:415)
at
org.jline.terminal.impl.LineDisciplineTerminal.doClose(LineDisciplineTerminal.java:270)
at org.jline.terminal.impl.ExternalTerminal.doClose(ExternalTerminal.java:89)
at org.jline.terminal.impl.AbstractTerminal.close(AbstractTerminal.java:95)
at
my.app.rmi.server.ssh.AbstractEmbeddedShell.close(AbstractEmbeddedShell.java:569)
at my.app.rmi.server.ssh.EmbeddedShell.close(EmbeddedShell.java:270)
at
my.app.rmi.server.ssh.AbstractEmbeddedShell.destroy(AbstractEmbeddedShell.java:515)
at
org.apache.sshd.server.channel.ChannelSession.closeImmediately0(ChannelSession.java:213)
at
org.apache.sshd.common.util.closeable.Builder$1.doClose(Builder.java:47){noformat}
> ChannelOutputStream#flush should not log at error level
> ---
>
> Key: SSHD-1058
> URL: https://issues.apache.org/jira/browse/SSHD-1058
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.0, 2.5.1
> Environment: Linux, Java 11
>Reporter: Markus Spann
>Assignee: Lyor Goldstein
>Priority: Minor
>
> When calling flush on ChannelOutputStream, Window.waitForSpace may throw a
> WindowClosedException. This exception is always logged at error level, then
> rethrown. If Debug is enabled on the logger, the error log is issued twice
> (second time with stacktrace).
> During deinitialization it is common practice to call flush on output
> streams. Due to the asynchronous nature of the code in this library, the call
> may fail. The caller should decide how to deal with the exception and log at
> error level if needed.
> The implementation should not log at error level regardless.
> I would suggest INFO level instead (if logging at all).
>
> {code:java}
> // lines 202 ff.
> if (log.isDebugEnabled()) {
> log.info("flush({}) failed ({}) to wait for space of len={}: {}: ", this,
> e.getClass().getSimpleName(), total, e.getMessage(), e); // with stacktrace
> } else {
> log.info("flush({}) failed ({}) to wait for space of len={}: {}",
> this, e.getClass().getSimpleName(), total, e.getMessage());
> }
> throw e;
> {code}
> Thanks,
> Markus
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1058) ChannelOutputStream#flush should not log at error level
[
https://issues.apache.org/jira/browse/SSHD-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179421#comment-17179421
]
Markus Spann commented on SSHD-1058:
Here's how exceptions were dealt with up to and including version 2.4.0 in the
discussed scenario:
{code:java}
... // lines 200 ff.
} catch (IOException e) {
if (this.log.isDebugEnabled()) {
this.log.debug("flush({}) failed ({}) to wait for space of len={}: {}",
new Object[] { this, e.getClass().getSimpleName(), Long.valueOf(total),
e.getMessage() });
}
throw e;
}
{code}
{quote}We apply a consistent policy of logging exception [...]
{quote}
since when?
> ChannelOutputStream#flush should not log at error level
> ---
>
> Key: SSHD-1058
> URL: https://issues.apache.org/jira/browse/SSHD-1058
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.0, 2.5.1
> Environment: Linux, Java 11
>Reporter: Markus Spann
>Assignee: Lyor Goldstein
>Priority: Minor
>
> When calling flush on ChannelOutputStream, Window.waitForSpace may throw a
> WindowClosedException. This exception is always logged at error level, then
> rethrown. If Debug is enabled on the logger, the error log is issued twice
> (second time with stacktrace).
> During deinitialization it is common practice to call flush on output
> streams. Due to the asynchronous nature of the code in this library, the call
> may fail. The caller should decide how to deal with the exception and log at
> error level if needed.
> The implementation should not log at error level regardless.
> I would suggest INFO level instead (if logging at all).
>
> {code:java}
> // lines 202 ff.
> if (log.isDebugEnabled()) {
> log.info("flush({}) failed ({}) to wait for space of len={}: {}: ", this,
> e.getClass().getSimpleName(), total, e.getMessage(), e); // with stacktrace
> } else {
> log.info("flush({}) failed ({}) to wait for space of len={}: {}",
> this, e.getClass().getSimpleName(), total, e.getMessage());
> }
> throw e;
> {code}
> Thanks,
> Markus
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Created] (SSHD-1058) ChannelOutputStream#flush should not log at error level
Markus Spann created SSHD-1058:
--
Summary: ChannelOutputStream#flush should not log at error level
Key: SSHD-1058
URL: https://issues.apache.org/jira/browse/SSHD-1058
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 2.5.1, 2.5.0
Environment: Linux, Java 11
Reporter: Markus Spann
When calling flush on ChannelOutputStream, Window.waitForSpace may throw a
WindowClosedException. This exception is always logged at error level, then
rethrown. If Debug is enabled on the logger, the error log is issued twice
(second time with stacktrace).
During deinitialization it is common practice to call flush on output streams.
Due to the asynchronous nature of the code in this library, the call may fail.
The caller should decide how to deal with the exception and log at error level
if needed.
The implementation should not log at error level regardless.
I would suggest INFO level instead (if logging at all).
{code:java}
// lines 202 ff.
if (log.isDebugEnabled()) {
log.info("flush({}) failed ({}) to wait for space of len={}: {}: ", this,
e.getClass().getSimpleName(), total, e.getMessage(), e); // with stacktrace
} else {
log.info("flush({}) failed ({}) to wait for space of len={}: {}",
this, e.getClass().getSimpleName(), total, e.getMessage());
}
throw e;
{code}
Thanks,
Markus
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
