[jira] [Assigned] (SSHD-838) Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
[
https://issues.apache.org/jira/browse/SSHD-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor reassigned SSHD-838:
---
Assignee: Goldstein Lyor
> Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
>
>
> Key: SSHD-838
> URL: https://issues.apache.org/jira/browse/SSHD-838
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: jpalacios
>Assignee: Goldstein Lyor
>Priority: Major
> Labels: important, listener, logging
> Attachments: sshd-nio-acceptor-logging.patch
>
>
> As discussed in [SSHD-833|https://issues.apache.org/jira/browse/SSHD-833], it
> appears that when a client disconnects before the handshake completes there's
> some pretty loud logging coming from the
> {{Nio2Acceptor.AcceptCompletionHandler#okToReaccept}}.
> The entire message is logged at {{WARN}} level. Also, several lines from the
> stack trace are logged individually at the same level.
> We feel this much logging at {{WARN}} level will be too much noise for system
> administrators who might think there's something wrong with the system. We
> propose:
> # Changing the log level to {{DEBUG}} / {{FINE}}
> # Logging the stacktrace in a single message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SSHD-838) Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
[
https://issues.apache.org/jira/browse/SSHD-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor updated SSHD-838:
Labels: important listener logging (was: )
> Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
>
>
> Key: SSHD-838
> URL: https://issues.apache.org/jira/browse/SSHD-838
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: jpalacios
>Priority: Major
> Labels: important, listener, logging
> Attachments: sshd-nio-acceptor-logging.patch
>
>
> As discussed in [SSHD-833|https://issues.apache.org/jira/browse/SSHD-833], it
> appears that when a client disconnects before the handshake completes there's
> some pretty loud logging coming from the
> {{Nio2Acceptor.AcceptCompletionHandler#okToReaccept}}.
> The entire message is logged at {{WARN}} level. Also, several lines from the
> stack trace are logged individually at the same level.
> We feel this much logging at {{WARN}} level will be too much noise for system
> administrators who might think there's something wrong with the system. We
> propose:
> # Changing the log level to {{DEBUG}} / {{FINE}}
> # Logging the stacktrace in a single message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SSHD-838) Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
[
https://issues.apache.org/jira/browse/SSHD-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor updated SSHD-838:
Priority: Major (was: Minor)
> Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
>
>
> Key: SSHD-838
> URL: https://issues.apache.org/jira/browse/SSHD-838
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: jpalacios
>Priority: Major
> Attachments: sshd-nio-acceptor-logging.patch
>
>
> As discussed in [SSHD-833|https://issues.apache.org/jira/browse/SSHD-833], it
> appears that when a client disconnects before the handshake completes there's
> some pretty loud logging coming from the
> {{Nio2Acceptor.AcceptCompletionHandler#okToReaccept}}.
> The entire message is logged at {{WARN}} level. Also, several lines from the
> stack trace are logged individually at the same level.
> We feel this much logging at {{WARN}} level will be too much noise for system
> administrators who might think there's something wrong with the system. We
> propose:
> # Changing the log level to {{DEBUG}} / {{FINE}}
> # Logging the stacktrace in a single message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-838) Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
[
https://issues.apache.org/jira/browse/SSHD-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565817#comment-16565817
]
Goldstein Lyor commented on SSHD-838:
-
{quote}
That said, though, I want to be respectful of your time, because I'm not sure I
personally have the time to devote to building that change, and jpalacios is
about to leave on vacation
{quote}
I was not implying that you should come up with the code change - I feel I
understand the requirements and agree with the valid arguments you have made.
All I ask is that since your project seems to make use of this library, we
could leverage your experience with it and if possible to map the locations
where in your experience there is "loud" logging (as you have put it) so I can
have a better idea as to how to craft the suggested solution and where to
employ it.
{quote}
and I don't want to assume you have the time to build it either.
{quote}
I am rather busy in the near future, but since I believe this is an important
issue I will try to find some time for it (don't know when though). Please
track this issue and if you don't see any progress within the next few weeks,
please don't hesitate to inquire - just so we can be sure it does not fall
between the cracks...
> Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
>
>
> Key: SSHD-838
> URL: https://issues.apache.org/jira/browse/SSHD-838
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: jpalacios
>Priority: Minor
> Attachments: sshd-nio-acceptor-logging.patch
>
>
> As discussed in [SSHD-833|https://issues.apache.org/jira/browse/SSHD-833], it
> appears that when a client disconnects before the handshake completes there's
> some pretty loud logging coming from the
> {{Nio2Acceptor.AcceptCompletionHandler#okToReaccept}}.
> The entire message is logged at {{WARN}} level. Also, several lines from the
> stack trace are logged individually at the same level.
> We feel this much logging at {{WARN}} level will be too much noise for system
> administrators who might think there's something wrong with the system. We
> propose:
> # Changing the log level to {{DEBUG}} / {{FINE}}
> # Logging the stacktrace in a single message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-838) Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
[
https://issues.apache.org/jira/browse/SSHD-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565804#comment-16565804
]
Bryan Turner commented on SSHD-838:
---
My thanks and sincere appreciation, [~lgoldstein].
{quote}
Perhaps a possible solution is to define some "events" that can be signalled
via a ConnectionEventListener before the session is established and let the
user decide how to log them - e.g., connection requested, connection
established, connection accepted, connection terminated + reason (OK or
exception), etc For backward compatibility, if no event listener is
registered then the code will just log the event as it currently does (i.e.,
WARNING + stack trace)...
Once the session is established, all events associated with it should be
signalled via the SessionListener. In this context, please see if there are
other such exceptions/warnings that are signalled via logging and could
potentially be signalled via either the ConnectionEventListener or the
SessionListener.
{quote}
The approach itself sounds good to me. Bitbucket Server is already implementing
its own {{SessionListener}}, so implementing a {{ConnectionListener}} (or
whatever name is used) would be a logical enhancement, and allow us to
customize the behavior to fit our needs. That said, though, I want to be
respectful of your time, because I'm not sure I personally have the time to
devote to _building_ that change, and [~jpalacios] is about to leave on
vacation, and I don't want to assume you have the time to build it either.
Best regards,
Bryan Turner
> Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
>
>
> Key: SSHD-838
> URL: https://issues.apache.org/jira/browse/SSHD-838
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: jpalacios
>Priority: Minor
> Attachments: sshd-nio-acceptor-logging.patch
>
>
> As discussed in [SSHD-833|https://issues.apache.org/jira/browse/SSHD-833], it
> appears that when a client disconnects before the handshake completes there's
> some pretty loud logging coming from the
> {{Nio2Acceptor.AcceptCompletionHandler#okToReaccept}}.
> The entire message is logged at {{WARN}} level. Also, several lines from the
> stack trace are logged individually at the same level.
> We feel this much logging at {{WARN}} level will be too much noise for system
> administrators who might think there's something wrong with the system. We
> propose:
> # Changing the log level to {{DEBUG}} / {{FINE}}
> # Logging the stacktrace in a single message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-838) Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
[
https://issues.apache.org/jira/browse/SSHD-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565783#comment-16565783
]
ASF GitHub Bot commented on SSHD-838:
-
Github user bturner closed the pull request at:
https://github.com/apache/mina-sshd/pull/65
> Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
>
>
> Key: SSHD-838
> URL: https://issues.apache.org/jira/browse/SSHD-838
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: jpalacios
>Priority: Minor
> Attachments: sshd-nio-acceptor-logging.patch
>
>
> As discussed in [SSHD-833|https://issues.apache.org/jira/browse/SSHD-833], it
> appears that when a client disconnects before the handshake completes there's
> some pretty loud logging coming from the
> {{Nio2Acceptor.AcceptCompletionHandler#okToReaccept}}.
> The entire message is logged at {{WARN}} level. Also, several lines from the
> stack trace are logged individually at the same level.
> We feel this much logging at {{WARN}} level will be too much noise for system
> administrators who might think there's something wrong with the system. We
> propose:
> # Changing the log level to {{DEBUG}} / {{FINE}}
> # Logging the stacktrace in a single message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] mina-sshd pull request #65: SSHD-838 Remove LoggingUtils.logExceptionStackTr...
Github user bturner closed the pull request at: https://github.com/apache/mina-sshd/pull/65 ---
[jira] [Commented] (SSHD-838) Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
[
https://issues.apache.org/jira/browse/SSHD-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565735#comment-16565735
]
Goldstein Lyor commented on SSHD-838:
-
After reviewing your arguments I was persuaded and have adopted your suggested
patch (with a minor change) - see [this
commit|https://github.com/apache/mina-sshd/commit/f17bf3852e27b67f86fbd0d4091e788deb4202ba].
What remains now is the connection event listen...
> Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
>
>
> Key: SSHD-838
> URL: https://issues.apache.org/jira/browse/SSHD-838
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: jpalacios
>Priority: Minor
> Attachments: sshd-nio-acceptor-logging.patch
>
>
> As discussed in [SSHD-833|https://issues.apache.org/jira/browse/SSHD-833], it
> appears that when a client disconnects before the handshake completes there's
> some pretty loud logging coming from the
> {{Nio2Acceptor.AcceptCompletionHandler#okToReaccept}}.
> The entire message is logged at {{WARN}} level. Also, several lines from the
> stack trace are logged individually at the same level.
> We feel this much logging at {{WARN}} level will be too much noise for system
> administrators who might think there's something wrong with the system. We
> propose:
> # Changing the log level to {{DEBUG}} / {{FINE}}
> # Logging the stacktrace in a single message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-838) Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
[
https://issues.apache.org/jira/browse/SSHD-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565706#comment-16565706
]
Goldstein Lyor commented on SSHD-838:
-
{quote}I humbly ask...please don't move your logging in this direction{quote}
Will take this under advisement...
What about the {{ConnectionEventListener}} solution I suggested ?
> Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
>
>
> Key: SSHD-838
> URL: https://issues.apache.org/jira/browse/SSHD-838
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: jpalacios
>Priority: Minor
> Attachments: sshd-nio-acceptor-logging.patch
>
>
> As discussed in [SSHD-833|https://issues.apache.org/jira/browse/SSHD-833], it
> appears that when a client disconnects before the handshake completes there's
> some pretty loud logging coming from the
> {{Nio2Acceptor.AcceptCompletionHandler#okToReaccept}}.
> The entire message is logged at {{WARN}} level. Also, several lines from the
> stack trace are logged individually at the same level.
> We feel this much logging at {{WARN}} level will be too much noise for system
> administrators who might think there's something wrong with the system. We
> propose:
> # Changing the log level to {{DEBUG}} / {{FINE}}
> # Logging the stacktrace in a single message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SSHD-838) Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
[
https://issues.apache.org/jira/browse/SSHD-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565685#comment-16565685
]
Bryan Turner edited comment on SSHD-838 at 8/1/18 5:35 PM:
---
{quote}
If anything, I am considering replacing all code that passes the exception
directly to the logging framework with this call.
{quote}
That's _extremely_ concerning to me.
{quote}
The reason for it is that when passing the exception directly to the logging
framework it logs the entire stack trace - which is often very long and
tedious. Usually, logging the top (or bottom - depending how you look at it)
6-8 frames provides enough "hints" as to the call flow to let the user know
what went wrong.
{quote}
That doesn't feel like a decision a _library_ should make. The few frames being
logged may be "enough hints" for an SSHD developer, but they completely
eliminate most, if not all, frames related to the _application_. That means I
have to reproduce the failure myself (which isn't always possible), or
otherwise guess my way through to how the SSHD code relates to _my_ code. What
call in _my_ application led to the calls in SSHD that failed?
By using SLF4J "normally", the decisions are left to the application developer.
If the _application_ doesn't want the full trace, they can eliminate some or
all of it by configuring Logback/Log4J accordingly\-\-something Bitbucket
Server, for example, _does_. We trim our own stack frames\-\-we don't need (or
want) the libraries we use to do it for us, because our goals aren't always the
same. For the _library_, the goal is to facilitate its maintainers' ability to
get useful (_to them_) details when failures are reported, while avoiding "long
and tedious" extra information that makes resolution slower. For the
_application_, the goal is to facilitate troubleshooting _customer-raised
issues_, which requires more complete context. Is the problem in the library?
Or is the problem in how we _set up or use_ the library? When SSH-related
issues come through our support, _very, very few_ of them get forwarded to the
wider SSHD community. Instead, we debug them ourselves and we
[often|https://github.com/apache/mina-sshd/pull/1]
[provide|https://github.com/apache/mina-sshd/pull/2]
[fixes|https://github.com/apache/mina-sshd/pull/3] ([and more
examples|https://issues.apache.org/jira/browse/SSHD-163?jql=project%20%3D%20SSHD%20AND%20reporter%20%3D%20pepoirot%20]).
Further, there are shortcomings with the _structure_ of
{{logExceptionStackTrace}}'s output:
* You're dropping the cause(s), which are often more useful for debugging a
failure than the various exceptions that wrap them
* All of the frames are separate log messages, which means:
** They each are prefixed with logger details, making the frames themselves
significantly harder to scan
** Systems that are connected to a LaaS (logging-as-a-service) framework end up
with all of the frames in separate events. Searching for a message and then
seeing the trace becomes more complicated
I humbly ask...please don't move your logging in this direction. As a system
which uses Mina SSHD heavily, it's a very undesirable change for Bitbucket
Server. If you do make this change, though, please, please add a way to turn it
off and log exceptions normally again.
Best regards,
Bryan Turner
was (Author: bturner):
{quote}
If anything, I am considering replacing all code that passes the exception
directly to the logging framework with this call.
{quote}
That's _extremely_ concerning to me.
{quote}
The reason for it is that when passing the exception directly to the logging
framework it logs the entire stack trace - which is often very long and
tedious. Usually, logging the top (or bottom - depending how you look at it)
6-8 frames provides enough "hints" as to the call flow to let the user know
what went wrong.
{quote}
That doesn't feel like a decision a _library_ should make. The few frames being
logged may be "enough hints" for an SSHD developer, but they completely
eliminate most, if not all, frames related to the _application_. That means I
have to reproduce the failure myself (which isn't always possible), or
otherwise guess my way through to how the SSHD code relates to _my_ code. What
call in _my_ application led to the calls in SSHD that failed?
By using SLF4J "normally", the decisions are left to the application developer.
If the _application_ doesn't want the full trace, they can eliminate some or
all of it by configuring Logback/Log4J accordingly--something Bitbucket Server,
for example, _does_. We trim our own stack frames--we don't need (or want) the
libraries we use to do it for us, because our goals aren't always the same. For
the _library_, the goal is to facilitate its maintainers' ability to get useful
(_to them_) details when failures are reported, while avoiding "long and
tedious" extra
[jira] [Commented] (SSHD-838) Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
[
https://issues.apache.org/jira/browse/SSHD-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565685#comment-16565685
]
Bryan Turner commented on SSHD-838:
---
{quote}
If anything, I am considering replacing all code that passes the exception
directly to the logging framework with this call.
{quote}
That's _extremely_ concerning to me.
{quote}
The reason for it is that when passing the exception directly to the logging
framework it logs the entire stack trace - which is often very long and
tedious. Usually, logging the top (or bottom - depending how you look at it)
6-8 frames provides enough "hints" as to the call flow to let the user know
what went wrong.
{quote}
That doesn't feel like a decision a _library_ should make. The few frames being
logged may be "enough hints" for an SSHD developer, but they completely
eliminate most, if not all, frames related to the _application_. That means I
have to reproduce the failure myself (which isn't always possible), or
otherwise guess my way through to how the SSHD code relates to _my_ code. What
call in _my_ application led to the calls in SSHD that failed?
By using SLF4J "normally", the decisions are left to the application developer.
If the _application_ doesn't want the full trace, they can eliminate some or
all of it by configuring Logback/Log4J accordingly--something Bitbucket Server,
for example, _does_. We trim our own stack frames--we don't need (or want) the
libraries we use to do it for us, because our goals aren't always the same. For
the _library_, the goal is to facilitate its maintainers' ability to get useful
(_to them_) details when failures are reported, while avoiding "long and
tedious" extra information that makes resolution slower. For the _application_,
the goal is to facilitate troubleshooting _customer-raised issues_, which
requires more complete context. Is the problem in the library? Or is the
problem in how we _set up or use_ the library? When SSH-related issues come
through our support, _very, very few_ of them get forwarded to the wider SSHD
community. Instead, we debug them ourselves and we
[often|https://github.com/apache/mina-sshd/pull/1]
[provide|https://github.com/apache/mina-sshd/pull/2]
[fixes|https://github.com/apache/mina-sshd/pull/3] ([and more
examples|https://issues.apache.org/jira/browse/SSHD-163?jql=project%20%3D%20SSHD%20AND%20reporter%20%3D%20pepoirot%20]).
Further, there are shortcomings with the _structure_ of
{{logExceptionStackTrace}}'s output:
* You're dropping the cause(s), which are often more useful for debugging a
failure than the various exceptions that wrap them
* All of the frames are separate log messages, which means:
** They each are prefixed with logger details, making the frames themselves
significantly harder to scan
** Systems that are connected to a LaaS (logging-as-a-service) framework end up
with all of the frames in separate events. Searching for a message and then
seeing the trace becomes more complicated
I humbly ask...please don't move your logging in this direction. As a system
which uses Mina SSHD heavily, it's a very undesirable change for Bitbucket
Server. If you do make this change, though, please, please add a way to turn it
off and log exceptions normally again.
Best regards,
Bryan Turner
> Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
>
>
> Key: SSHD-838
> URL: https://issues.apache.org/jira/browse/SSHD-838
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: jpalacios
>Priority: Minor
> Attachments: sshd-nio-acceptor-logging.patch
>
>
> As discussed in [SSHD-833|https://issues.apache.org/jira/browse/SSHD-833], it
> appears that when a client disconnects before the handshake completes there's
> some pretty loud logging coming from the
> {{Nio2Acceptor.AcceptCompletionHandler#okToReaccept}}.
> The entire message is logged at {{WARN}} level. Also, several lines from the
> stack trace are logged individually at the same level.
> We feel this much logging at {{WARN}} level will be too much noise for system
> administrators who might think there's something wrong with the system. We
> propose:
> # Changing the log level to {{DEBUG}} / {{FINE}}
> # Logging the stacktrace in a single message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-792) Remote Port-Forwarding uses invalid "original host" values
[ https://issues.apache.org/jira/browse/SSHD-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565522#comment-16565522 ] Goldstein Lyor commented on SSHD-792: - I don't quite understand what is the problem - or rather how it occurs (I have not been able to reproduce it) and what your suggested solution is. Perhaps you could post a PR with suggested code changes so it might be clearer. > Remote Port-Forwarding uses invalid "original host" values > -- > > Key: SSHD-792 > URL: https://issues.apache.org/jira/browse/SSHD-792 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 1.6.0 > Environment: Java 8 > OSX >Reporter: Andreas Haufler >Assignee: Goldstein Lyor >Priority: Major > Labels: needs-test > Attachments: Forwarder.java > > > When starting a server which accepts all kinds of port forwarding: > sshd.setTcpipForwardingFilter(new StaticDecisionForwardingFilter(true)); > remote port-forwarding doesn't work (at least when connecting from OSX) > unless a specific address is given: > ssh localhost -p -R10001:localhost:80 <- doesn't work > ssh localhost -p -R127.0.0.1:10001:localhost:80 <- does work > As far as I can tell, TcpipClientChannel.java:98 uses the underlying > socket-address > of the effective connection and transmit the host (which is either 127.0.0.1 > or ::1) on OSX. > However, the client (ssh) would want to see "localhost" as original host in > order to permit tunneling. > Is there anything I am missing? Otherwise I could provide a PR which fixes > this (by remembering the originally requested host and reporting that back). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-792) Remote Port-Forwarding uses invalid "original host" values
[ https://issues.apache.org/jira/browse/SSHD-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565523#comment-16565523 ] Goldstein Lyor commented on SSHD-792: - I don't quite understand what is the problem - or rather how it occurs (I have not been able to reproduce it) and what your suggested solution is. Perhaps you could post a PR with suggested code changes so it might be clearer. > Remote Port-Forwarding uses invalid "original host" values > -- > > Key: SSHD-792 > URL: https://issues.apache.org/jira/browse/SSHD-792 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 1.6.0 > Environment: Java 8 > OSX >Reporter: Andreas Haufler >Assignee: Goldstein Lyor >Priority: Major > Labels: needs-test > Attachments: Forwarder.java > > > When starting a server which accepts all kinds of port forwarding: > sshd.setTcpipForwardingFilter(new StaticDecisionForwardingFilter(true)); > remote port-forwarding doesn't work (at least when connecting from OSX) > unless a specific address is given: > ssh localhost -p -R10001:localhost:80 <- doesn't work > ssh localhost -p -R127.0.0.1:10001:localhost:80 <- does work > As far as I can tell, TcpipClientChannel.java:98 uses the underlying > socket-address > of the effective connection and transmit the host (which is either 127.0.0.1 > or ::1) on OSX. > However, the client (ssh) would want to see "localhost" as original host in > order to permit tunneling. > Is there anything I am missing? Otherwise I could provide a PR which fixes > this (by remembering the originally requested host and reporting that back). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (SSHD-838) Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
[
https://issues.apache.org/jira/browse/SSHD-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565509#comment-16565509
]
Goldstein Lyor edited comment on SSHD-838 at 8/1/18 3:45 PM:
-
{quote}
This message happens when a remote user Ctrl+C's a process (typically a git
clone or git fetch, in our case) "early" enough to terminate the connection
before the handshake completes.
{quote}
But that is a *client* side event - how can the *server* distinguish between
such (let's say) "acceptable" incomplete handshakes from "unacceptable" ones.
If there indeed is a problem and we always log it as DEBUG level, we might
never know about "unacceptable" handshakes...
{quote}
Is there any way we can work together to adjust this logging so that it's not
so "strong", for lack of a better term, when it's most likely nothing but a
client disconnecting early?
{quote}
Perhaps a possible solution is to define some "events" that can be signalled
via a {{ConnectionEventListener}} before the session is established and let the
user decide how to log them - e.g., connection requested, connection
established, connection accepted, connection terminated + reason (OK or
exception), etc For backward compatibility, if no event listener is
registered then the code will just log the event as it currently does (i.e.,
WARNING + stack trace)...
Once the session is established, all events associated with it should be
signalled via the {{SessionListener}}. In this context, please see if there are
other such exceptions/warnings that are signalled via logging and could
potentially be signalled via either the {{ConnectionEventListener}} or the
{{SessionListener}}.
What do you think ... ?
was (Author: lgoldstein):
{quote}
This message happens when a remote user Ctrl+C's a process (typically a git
clone or git fetch, in our case) "early" enough to terminate the connection
before the handshake completes.
{quote}
But that is a *client* side event - how can the *server* distinguish between
such (let's say) "acceptable" incomplete handshakes from "unacceptable" ones.
If there indeed is a problem and we always log it as DEBUG level, we might
never know about "unacceptable" handshakes...
{quote}
Is there any way we can work together to adjust this logging so that it's not
so "strong", for lack of a better term, when it's most likely nothing but a
client disconnecting early?
{quote}
Perhaps a possible solution is do define some "events" that can be signalled
via a {{ConnectionEventListener}} before the session is established and let the
user decide how to log them - e.g., connection requested, connection
established, connection accepted, connection terminated + reason (OK or
exception), etc For backward compatibility, if no event listener is
registered then the code will just log the event as it currently does (i.e.,
WARNING + stack trace)...
Once the session is established, all events associated with it should be
signalled via the {{SessionListener}}. In this context, please see if there are
other such exceptions/warnings that are signalled via logging and could
potentially be signalled via either the {{ConnectionEventListener}} or the
{{SessionListener}}.
What do you think ... ?
> Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
>
>
> Key: SSHD-838
> URL: https://issues.apache.org/jira/browse/SSHD-838
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: jpalacios
>Priority: Minor
> Attachments: sshd-nio-acceptor-logging.patch
>
>
> As discussed in [SSHD-833|https://issues.apache.org/jira/browse/SSHD-833], it
> appears that when a client disconnects before the handshake completes there's
> some pretty loud logging coming from the
> {{Nio2Acceptor.AcceptCompletionHandler#okToReaccept}}.
> The entire message is logged at {{WARN}} level. Also, several lines from the
> stack trace are logged individually at the same level.
> We feel this much logging at {{WARN}} level will be too much noise for system
> administrators who might think there's something wrong with the system. We
> propose:
> # Changing the log level to {{DEBUG}} / {{FINE}}
> # Logging the stacktrace in a single message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-838) Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
[
https://issues.apache.org/jira/browse/SSHD-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565509#comment-16565509
]
Goldstein Lyor commented on SSHD-838:
-
{quote}
This message happens when a remote user Ctrl+C's a process (typically a git
clone or git fetch, in our case) "early" enough to terminate the connection
before the handshake completes.
{quote}
But that is a *client* side event - how can the *server* distinguish between
such (let's say) "acceptable" incomplete handshakes from "unacceptable" ones.
If there indeed is a problem and we always log it as DEBUG level, we might
never know about "unacceptable" handshakes...
{quote}
Is there any way we can work together to adjust this logging so that it's not
so "strong", for lack of a better term, when it's most likely nothing but a
client disconnecting early?
{quote}
Perhaps a possible solution is do define some "events" that can be signalled
via a {{ConnectionEventListener}} before the session is established and let the
user decide how to log them - e.g., connection requested, connection
established, connection accepted, connection terminated + reason (OK or
exception), etc For backward compatibility, if no event listener is
registered then the code will just log the event as it currently does (i.e.,
WARNING + stack trace)...
Once the session is established, all events associated with it should be
signalled via the {{SessionListener}}. In this context, please see if there are
other such exceptions/warnings that are signalled via logging and could
potentially be signalled via either the {{ConnectionEventListener}} or the
{{SessionListener}}.
What do you think ... ?
> Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
>
>
> Key: SSHD-838
> URL: https://issues.apache.org/jira/browse/SSHD-838
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: jpalacios
>Priority: Minor
> Attachments: sshd-nio-acceptor-logging.patch
>
>
> As discussed in [SSHD-833|https://issues.apache.org/jira/browse/SSHD-833], it
> appears that when a client disconnects before the handshake completes there's
> some pretty loud logging coming from the
> {{Nio2Acceptor.AcceptCompletionHandler#okToReaccept}}.
> The entire message is logged at {{WARN}} level. Also, several lines from the
> stack trace are logged individually at the same level.
> We feel this much logging at {{WARN}} level will be too much noise for system
> administrators who might think there's something wrong with the system. We
> propose:
> # Changing the log level to {{DEBUG}} / {{FINE}}
> # Logging the stacktrace in a single message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-838) Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
[
https://issues.apache.org/jira/browse/SSHD-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565499#comment-16565499
]
Goldstein Lyor commented on SSHD-838:
-
{quote}
That utility feels a lot like fighting the logging framework, to me. Is there
a reason not to just pass the exception object through to SLF4J like "normal"?
{quote}
The reason for it is that when passing the exception directly to the logging
framework it logs the entire stack trace - which is often very long and
tedious. Usually, logging the top (or bottom - depending how you look at it)
6-8 frames provides enough "hints" as to the call flow to let the user know
what went wrong.
{quote}
LoggingUtils.logExceptionStackTrace appears to only be used in 2 places in the
entire codebase
{quote}
This utility is relatively new and we did not retro fit older code.
{quote}
how about removing logExceptionStackTrace
{quote}
If anything, I am considering replacing all code that passes the exception
directly to the logging framework with this call.
> Lower the log level in Nio2Acceptor.AcceptCompletionHandler#okToReaccept
>
>
> Key: SSHD-838
> URL: https://issues.apache.org/jira/browse/SSHD-838
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: jpalacios
>Priority: Minor
> Attachments: sshd-nio-acceptor-logging.patch
>
>
> As discussed in [SSHD-833|https://issues.apache.org/jira/browse/SSHD-833], it
> appears that when a client disconnects before the handshake completes there's
> some pretty loud logging coming from the
> {{Nio2Acceptor.AcceptCompletionHandler#okToReaccept}}.
> The entire message is logged at {{WARN}} level. Also, several lines from the
> stack trace are logged individually at the same level.
> We feel this much logging at {{WARN}} level will be too much noise for system
> administrators who might think there's something wrong with the system. We
> propose:
> # Changing the log level to {{DEBUG}} / {{FINE}}
> # Logging the stacktrace in a single message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
