[jira] [Work logged] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=918949=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918949
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 11/May/24 23:53
Start Date: 11/May/24 23:53
Worklog Time Spent: 10m
Work Description: elecharny commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597523524
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
I missed the MSS part. Ok, so makes sense to keep the parameter as is, but I
do agree that *not* setting a default at all would be a better option. At
least, you let the developer makes a choice depending on what they actually
measure.
Thanks Jon!
Issue Time Tracking
---
Worklog Id: (was: 918949)
Time Spent: 1.5h (was: 1h 20m)
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.executorFilter);
> connector.getFilterChain().addLast("gpbMessageFilter",
> G10CaptureService.gpbMessageFilter);
>
[jira] [Work logged] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=918948=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918948
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 11/May/24 22:28
Start Date: 11/May/24 22:28
Worklog Time Spent: 10m
Work Description: jon-valliere commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597516034
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
See https://en.wikipedia.org/wiki/Nagle%27s_algorithm
Nagle only really applies for when the packets are smaller than the MSS
which is usually 1280 bytes. AFAIK only the HELLO message in TLS HS is smaller
than this; all other messages SHOULD be aggregated together by the SSL layer.
There IS a _well known_ interaction with Nagle and Delayed Ack which can cause
Nagle to be worse than it would be by itself. What is the order of delays you
are seeing?
Issue Time Tracking
---
Worklog Id: (was: 918948)
Time Spent: 1h 20m (was: 1h 10m)
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
>
[jira] [Work logged] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=918947=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918947
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 11/May/24 22:09
Start Date: 11/May/24 22:09
Worklog Time Spent: 10m
Work Description: jon-valliere commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597513918
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
In my other IO framework, all of the TCP/SOCK options all have `unset`
states where the framework code will not call the SOCK configuration at all and
allow the OS defaults to be applied.
Issue Time Tracking
---
Worklog Id: (was: 918947)
Time Spent: 1h 10m (was: 1h)
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.executorFilter);
> connector.getFilterChain().addLast("gpbMessageFilter",
> G10CaptureService.gpbMessageFilter);
> connector.getFilterChain().addLast("keepAliveFilter",
>
[jira] [Work logged] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=918946=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918946
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 11/May/24 22:02
Start Date: 11/May/24 22:02
Worklog Time Spent: 10m
Work Description: elecharny commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597513323
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
Not arguing here, I will revert but...
I do think that this flag should be opt-in, ie the Nagle algorithm should be
disabled by default. The use cases were it's useful are not really the most
frequent, and the drawbacks are numerous. If the default sendBuffer size is
set to 64Ko, then you have a delayed for every packet that has a lower number
of bytes to transfert. if you set the sendBuffer size to a lower value, then
you are sending way more packet than needed. In any case, if you are to send
some data that span on more than one packet, and the last packet is not
completed, then you'll pay a 200ms delay every time. Not very cool.
With Gigabits connections, sending a lot of packets is not really an issue
anymore, except on heavily loaded applications that aren't interactive (HTTP
may enter into this category, but with REST application, I would argue that an
immediate sending is a plus).
Regarding LDAP, requests are small there is no interest in differing the
packet sendings, so yes, I'm likely to deactivate the Nagle Algorithm.
Seems like on Linux they have added the TCP_CORK parameter to let the sender
decide when to send the data, bypassing the Nagle's algorithm completely, and
also solving the context switching pb at the same time (somehow it's a way to
say "you're responsability, not teh OS one", and I tend to agree). Sadly, this
is not portable, so currently it's not an option.
Last, not least, for TLS HS, Nagle's Algorithm is delaying the whole
negociation, which is a real PITA...
Issue Time Tracking
---
Worklog Id: (was: 918946)
Time Spent: 1h (was: 50m)
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
>
[jira] [Work logged] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=918930=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918930
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 11/May/24 16:40
Start Date: 11/May/24 16:40
Worklog Time Spent: 10m
Work Description: jon-valliere commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597475482
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
Disabling Nagle by default may create context switching performance hits in
certain applications. Any situation where you may invoke more than one write
in sequence, receives performance boosts from the way the IO scheduler works in
TCP because it can produce MORE packets in a single go and does not have to be
woken up as often. The OS itself does not disable Nagle by default and I do
not think we should make this decision for the end user. As long as they can
configure it, I think the default should be `unset` (to allow the OS default to
apply). If other applications, built on MINA, want to configure a new default
then it is up to them. For SSHD or Apache Directory, if you want to disable
Nagle there, that is fine.
Issue Time Tracking
---
Worklog Id: (was: 918930)
Time Spent: 50m (was: 40m)
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
>
[jira] [Work logged] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=918929=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918929
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 11/May/24 16:21
Start Date: 11/May/24 16:21
Worklog Time Spent: 10m
Work Description: elecharny commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597473106
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
Hi @jon-valliere, just read this blog post:
https://brooker.co.za/blog/2024/05/09/nagle.html
Somehow, Nagle's algorithm is a thing of the past (ie when we were dealing
with terminals over slow connections). In MINA's context, and if we except
SSHD, I do think that the default to disable Nagle's algorithm actually makes
sense. Most of MINA based application don't deal with char by char
communication, rather with quite big chunks of data, so there is little need to
wait for an ACK from the server.
Anyway, this is configurable, so I guess it should not be a big deal.
Issue Time Tracking
---
Worklog Id: (was: 918929)
Time Spent: 40m (was: 0.5h)
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
>
[jira] [Work logged] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=918927=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918927
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 11/May/24 13:44
Start Date: 11/May/24 13:44
Worklog Time Spent: 10m
Work Description: jon-valliere commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597451055
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
Hey @elecharny I'm not sure this is a good idea. If we want todo this also,
I think it should be as part of a separate PR.
Issue Time Tracking
---
Worklog Id: (was: 918927)
Time Spent: 0.5h (was: 20m)
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.executorFilter);
> connector.getFilterChain().addLast("gpbMessageFilter",
> G10CaptureService.gpbMessageFilter);
> connector.getFilterChain().addLast("keepAliveFilter",
> G10CaptureService.keepAliveFilter);
> connector.setHandler(ioHandler);
> }
>
[jira] [Work logged] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=918926=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918926
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 11/May/24 13:43
Start Date: 11/May/24 13:43
Worklog Time Spent: 10m
Work Description: jon-valliere commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597451055
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
Hey @elecharny I'm not sure this is a good idea
Issue Time Tracking
---
Worklog Id: (was: 918926)
Time Spent: 20m (was: 10m)
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.executorFilter);
> connector.getFilterChain().addLast("gpbMessageFilter",
> G10CaptureService.gpbMessageFilter);
> connector.getFilterChain().addLast("keepAliveFilter",
> G10CaptureService.keepAliveFilter);
> connector.setHandler(ioHandler);
> }
>
> public void StartRecordCapture()
> {
> connectionLock.lock();
> try
>
[jira] [Work logged] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=906344=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-906344
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 22/Feb/24 03:02
Start Date: 22/Feb/24 03:02
Worklog Time Spent: 10m
Work Description: jon-valliere opened a new pull request, #44:
URL: https://github.com/apache/mina/pull/44
(no comment)
Issue Time Tracking
---
Worklog Id: (was: 906344)
Remaining Estimate: 0h
Time Spent: 10m
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.executorFilter);
> connector.getFilterChain().addLast("gpbMessageFilter",
> G10CaptureService.gpbMessageFilter);
> connector.getFilterChain().addLast("keepAliveFilter",
> G10CaptureService.keepAliveFilter);
> connector.setHandler(ioHandler);
> }
>
> public void StartRecordCapture()
> {
> connectionLock.lock();
> try
> {
> ConnectFuture primaryConnectFuture = connector.connect(primaryAddress,
> initializer);
> //hungs forever if the no. of threads are more than 30
> primaryConnectFuture.awaitUninterruptibly();//no time out specified
> if (!primaryConnectFuture.isConnected())
> {
>
> if (handleIOException(searchExpression, captureHandler)) {
> return;
> }
> LOG.info("{} Apache mina
[jira] [Work logged] (DIRMINA-1169) BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
[
https://issues.apache.org/jira/browse/DIRMINA-1169?focusedWorklogId=861946=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861946
]
ASF GitHub Bot logged work on DIRMINA-1169:
---
Author: ASF GitHub Bot
Created on: 22/May/23 08:22
Start Date: 22/May/23 08:22
Worklog Time Spent: 10m
Work Description: elecharny commented on PR #35:
URL: https://github.com/apache/mina/pull/35#issuecomment-1556764578
Also merged in 2.1.X
Issue Time Tracking
---
Worklog Id: (was: 861946)
Time Spent: 2h (was: 1h 50m)
> BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
> --
>
> Key: DIRMINA-1169
> URL: https://issues.apache.org/jira/browse/DIRMINA-1169
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.23, 2.1.6, 2.2.1
>Reporter: Thomas Wolf
>Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> See also SSHD-1256.
> The main acceptor loop does basically (somewhat simplified):
> {code:java}
> while (selectable) {
> registerHandles(); // Process registration queue: add new sockets (from
> bind()) to the selector with OP_ACCEPT, fulfills their open futures
> int selected = select();
> if (/* nothing to do */) {
> break; // and end the thread; higher layers will create a new one if
> needed
> }
> if (selected > 0) {
> processHandles(selectedHandles()); // Handle and hand off new connections
> }
> unregisterHandles(); // Process cancel queue: cancel SelectionKey, close
> ServerSocketChannel, fulfill the cancel future
> }
> {code}
> With Java 11, unbinding a {{ServerSocketChannel}} changed:
> * [JDK-8214430|https://bugs.openjdk.org/browse/JDK-8214430]
> * [Java 11 Release
> Notes|https://www.oracle.com/java/technologies/javase/11-relnote-issues.html#JDK-8198562]
> Essentially the unbind gives up the socket only at the next {{select()}}
> call. This causes two problems in Apache MINA's acceptor:
> * The unbind future is set "done" before the socket is actually released.
> * If a new binding for one of the unbound sockets is registered before that
> {{select()}} has been done, {{registerHandles()}} gets a {{BindException}}
> ("address already in use").
> So for Java >= 11, the code must ensure that there is a {{select()}} between
> processing unbindings and processing new bindings, and the unbind futures
> must be set "done" only after that {{select()}}.
--
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] [Work logged] (DIRMINA-1169) BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
[
https://issues.apache.org/jira/browse/DIRMINA-1169?focusedWorklogId=861879=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861879
]
ASF GitHub Bot logged work on DIRMINA-1169:
---
Author: ASF GitHub Bot
Created on: 20/May/23 22:16
Start Date: 20/May/23 22:16
Worklog Time Spent: 10m
Work Description: tomaswolf commented on PR #39:
URL: https://github.com/apache/mina/pull/39#issuecomment-1556028337
Obsoleted by commit c7cb73cb4.
Issue Time Tracking
---
Worklog Id: (was: 861879)
Time Spent: 1h 40m (was: 1.5h)
> BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
> --
>
> Key: DIRMINA-1169
> URL: https://issues.apache.org/jira/browse/DIRMINA-1169
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.23, 2.1.6, 2.2.1
>Reporter: Thomas Wolf
>Priority: Major
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See also SSHD-1256.
> The main acceptor loop does basically (somewhat simplified):
> {code:java}
> while (selectable) {
> registerHandles(); // Process registration queue: add new sockets (from
> bind()) to the selector with OP_ACCEPT, fulfills their open futures
> int selected = select();
> if (/* nothing to do */) {
> break; // and end the thread; higher layers will create a new one if
> needed
> }
> if (selected > 0) {
> processHandles(selectedHandles()); // Handle and hand off new connections
> }
> unregisterHandles(); // Process cancel queue: cancel SelectionKey, close
> ServerSocketChannel, fulfill the cancel future
> }
> {code}
> With Java 11, unbinding a {{ServerSocketChannel}} changed:
> * [JDK-8214430|https://bugs.openjdk.org/browse/JDK-8214430]
> * [Java 11 Release
> Notes|https://www.oracle.com/java/technologies/javase/11-relnote-issues.html#JDK-8198562]
> Essentially the unbind gives up the socket only at the next {{select()}}
> call. This causes two problems in Apache MINA's acceptor:
> * The unbind future is set "done" before the socket is actually released.
> * If a new binding for one of the unbound sockets is registered before that
> {{select()}} has been done, {{registerHandles()}} gets a {{BindException}}
> ("address already in use").
> So for Java >= 11, the code must ensure that there is a {{select()}} between
> processing unbindings and processing new bindings, and the unbind futures
> must be set "done" only after that {{select()}}.
--
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] [Work logged] (DIRMINA-1169) BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
[
https://issues.apache.org/jira/browse/DIRMINA-1169?focusedWorklogId=861880=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861880
]
ASF GitHub Bot logged work on DIRMINA-1169:
---
Author: ASF GitHub Bot
Created on: 20/May/23 22:16
Start Date: 20/May/23 22:16
Worklog Time Spent: 10m
Work Description: tomaswolf closed pull request #39: Fix patch
application for DIRMINA-1169
URL: https://github.com/apache/mina/pull/39
Issue Time Tracking
---
Worklog Id: (was: 861880)
Time Spent: 1h 50m (was: 1h 40m)
> BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
> --
>
> Key: DIRMINA-1169
> URL: https://issues.apache.org/jira/browse/DIRMINA-1169
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.23, 2.1.6, 2.2.1
>Reporter: Thomas Wolf
>Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> See also SSHD-1256.
> The main acceptor loop does basically (somewhat simplified):
> {code:java}
> while (selectable) {
> registerHandles(); // Process registration queue: add new sockets (from
> bind()) to the selector with OP_ACCEPT, fulfills their open futures
> int selected = select();
> if (/* nothing to do */) {
> break; // and end the thread; higher layers will create a new one if
> needed
> }
> if (selected > 0) {
> processHandles(selectedHandles()); // Handle and hand off new connections
> }
> unregisterHandles(); // Process cancel queue: cancel SelectionKey, close
> ServerSocketChannel, fulfill the cancel future
> }
> {code}
> With Java 11, unbinding a {{ServerSocketChannel}} changed:
> * [JDK-8214430|https://bugs.openjdk.org/browse/JDK-8214430]
> * [Java 11 Release
> Notes|https://www.oracle.com/java/technologies/javase/11-relnote-issues.html#JDK-8198562]
> Essentially the unbind gives up the socket only at the next {{select()}}
> call. This causes two problems in Apache MINA's acceptor:
> * The unbind future is set "done" before the socket is actually released.
> * If a new binding for one of the unbound sockets is registered before that
> {{select()}} has been done, {{registerHandles()}} gets a {{BindException}}
> ("address already in use").
> So for Java >= 11, the code must ensure that there is a {{select()}} between
> processing unbindings and processing new bindings, and the unbind futures
> must be set "done" only after that {{select()}}.
--
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] [Work logged] (DIRMINA-1169) BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
[
https://issues.apache.org/jira/browse/DIRMINA-1169?focusedWorklogId=861867=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861867
]
ASF GitHub Bot logged work on DIRMINA-1169:
---
Author: ASF GitHub Bot
Created on: 20/May/23 14:40
Start Date: 20/May/23 14:40
Worklog Time Spent: 10m
Work Description: tomaswolf opened a new pull request, #39:
URL: https://github.com/apache/mina/pull/39
Add the most crucial bit: the actual fix. Since Java 11, unbinding may take
effect only on the next select(). Thus there must be a select() between
unbindings and performing new bindings.
Issue Time Tracking
---
Worklog Id: (was: 861867)
Time Spent: 1.5h (was: 1h 20m)
> BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
> --
>
> Key: DIRMINA-1169
> URL: https://issues.apache.org/jira/browse/DIRMINA-1169
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.23, 2.1.6, 2.2.1
>Reporter: Thomas Wolf
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> See also SSHD-1256.
> The main acceptor loop does basically (somewhat simplified):
> {code:java}
> while (selectable) {
> registerHandles(); // Process registration queue: add new sockets (from
> bind()) to the selector with OP_ACCEPT, fulfills their open futures
> int selected = select();
> if (/* nothing to do */) {
> break; // and end the thread; higher layers will create a new one if
> needed
> }
> if (selected > 0) {
> processHandles(selectedHandles()); // Handle and hand off new connections
> }
> unregisterHandles(); // Process cancel queue: cancel SelectionKey, close
> ServerSocketChannel, fulfill the cancel future
> }
> {code}
> With Java 11, unbinding a {{ServerSocketChannel}} changed:
> * [JDK-8214430|https://bugs.openjdk.org/browse/JDK-8214430]
> * [Java 11 Release
> Notes|https://www.oracle.com/java/technologies/javase/11-relnote-issues.html#JDK-8198562]
> Essentially the unbind gives up the socket only at the next {{select()}}
> call. This causes two problems in Apache MINA's acceptor:
> * The unbind future is set "done" before the socket is actually released.
> * If a new binding for one of the unbound sockets is registered before that
> {{select()}} has been done, {{registerHandles()}} gets a {{BindException}}
> ("address already in use").
> So for Java >= 11, the code must ensure that there is a {{select()}} between
> processing unbindings and processing new bindings, and the unbind futures
> must be set "done" only after that {{select()}}.
--
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] [Work logged] (DIRMINA-1169) BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
[
https://issues.apache.org/jira/browse/DIRMINA-1169?focusedWorklogId=861859=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861859
]
ASF GitHub Bot logged work on DIRMINA-1169:
---
Author: ASF GitHub Bot
Created on: 20/May/23 07:51
Start Date: 20/May/23 07:51
Worklog Time Spent: 10m
Work Description: tomaswolf commented on PR #35:
URL: https://github.com/apache/mina/pull/35#issuecomment-1555823619
> Merged in 2.2.X
But not correctly. See my
[comment](https://github.com/apache/mina/commit/36f4e9718d43509d0182b153277ff186148660f3#r114177942).
Issue Time Tracking
---
Worklog Id: (was: 861859)
Time Spent: 1h 20m (was: 1h 10m)
> BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
> --
>
> Key: DIRMINA-1169
> URL: https://issues.apache.org/jira/browse/DIRMINA-1169
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.23, 2.1.6, 2.2.1
>Reporter: Thomas Wolf
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> See also SSHD-1256.
> The main acceptor loop does basically (somewhat simplified):
> {code:java}
> while (selectable) {
> registerHandles(); // Process registration queue: add new sockets (from
> bind()) to the selector with OP_ACCEPT, fulfills their open futures
> int selected = select();
> if (/* nothing to do */) {
> break; // and end the thread; higher layers will create a new one if
> needed
> }
> if (selected > 0) {
> processHandles(selectedHandles()); // Handle and hand off new connections
> }
> unregisterHandles(); // Process cancel queue: cancel SelectionKey, close
> ServerSocketChannel, fulfill the cancel future
> }
> {code}
> With Java 11, unbinding a {{ServerSocketChannel}} changed:
> * [JDK-8214430|https://bugs.openjdk.org/browse/JDK-8214430]
> * [Java 11 Release
> Notes|https://www.oracle.com/java/technologies/javase/11-relnote-issues.html#JDK-8198562]
> Essentially the unbind gives up the socket only at the next {{select()}}
> call. This causes two problems in Apache MINA's acceptor:
> * The unbind future is set "done" before the socket is actually released.
> * If a new binding for one of the unbound sockets is registered before that
> {{select()}} has been done, {{registerHandles()}} gets a {{BindException}}
> ("address already in use").
> So for Java >= 11, the code must ensure that there is a {{select()}} between
> processing unbindings and processing new bindings, and the unbind futures
> must be set "done" only after that {{select()}}.
--
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] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861857=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861857 ] ASF GitHub Bot logged work on DIRMINA-1122: --- Author: ASF GitHub Bot Created on: 20/May/23 04:43 Start Date: 20/May/23 04:43 Worklog Time Spent: 10m Work Description: elecharny commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-123546 Pushed in 2.2.X Issue Time Tracking --- Worklog Id: (was: 861857) Time Spent: 3h 10m (was: 3h) > Add support for endpoint identification algorithm > - > > Key: DIRMINA-1122 > URL: https://issues.apache.org/jira/browse/DIRMINA-1122 > Project: MINA > Issue Type: Improvement > Components: Filter, SSL >Affects Versions: 2.0.22, 2.1.3 >Reporter: Marcin L >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.2.0 > > Attachments: > DIRMINA-1122_-_endpoint_identification_algorithm_support.patch > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Support for endpoint identification algorithm was added in Java 1.7. > Currently MINA supports providing single SNI name via > org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but > there is no way verifying it matches the certificate received. > It would be nice if we could provide endpoint identification algorithm to > SslFilter so certificate's common name or subject alternative names are > verified. -- 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] [Work logged] (DIRMINA-1169) BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
[
https://issues.apache.org/jira/browse/DIRMINA-1169?focusedWorklogId=861856=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861856
]
ASF GitHub Bot logged work on DIRMINA-1169:
---
Author: ASF GitHub Bot
Created on: 20/May/23 04:42
Start Date: 20/May/23 04:42
Worklog Time Spent: 10m
Work Description: elecharny commented on PR #35:
URL: https://github.com/apache/mina/pull/35#issuecomment-122769
Merged in 2.2.X
Issue Time Tracking
---
Worklog Id: (was: 861856)
Time Spent: 1h 10m (was: 1h)
> BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
> --
>
> Key: DIRMINA-1169
> URL: https://issues.apache.org/jira/browse/DIRMINA-1169
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.23, 2.1.6, 2.2.1
>Reporter: Thomas Wolf
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> See also SSHD-1256.
> The main acceptor loop does basically (somewhat simplified):
> {code:java}
> while (selectable) {
> registerHandles(); // Process registration queue: add new sockets (from
> bind()) to the selector with OP_ACCEPT, fulfills their open futures
> int selected = select();
> if (/* nothing to do */) {
> break; // and end the thread; higher layers will create a new one if
> needed
> }
> if (selected > 0) {
> processHandles(selectedHandles()); // Handle and hand off new connections
> }
> unregisterHandles(); // Process cancel queue: cancel SelectionKey, close
> ServerSocketChannel, fulfill the cancel future
> }
> {code}
> With Java 11, unbinding a {{ServerSocketChannel}} changed:
> * [JDK-8214430|https://bugs.openjdk.org/browse/JDK-8214430]
> * [Java 11 Release
> Notes|https://www.oracle.com/java/technologies/javase/11-relnote-issues.html#JDK-8198562]
> Essentially the unbind gives up the socket only at the next {{select()}}
> call. This causes two problems in Apache MINA's acceptor:
> * The unbind future is set "done" before the socket is actually released.
> * If a new binding for one of the unbound sockets is registered before that
> {{select()}} has been done, {{registerHandles()}} gets a {{BindException}}
> ("address already in use").
> So for Java >= 11, the code must ensure that there is a {{select()}} between
> processing unbindings and processing new bindings, and the unbind futures
> must be set "done" only after that {{select()}}.
--
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] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861317=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861317 ] ASF GitHub Bot logged work on DIRMINA-1122: --- Author: ASF GitHub Bot Created on: 10/May/23 09:34 Start Date: 10/May/23 09:34 Worklog Time Spent: 10m Work Description: elecharny commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1541786919 yes, I followed John's advice and used the new pattern (ie develop a custom SSLFilter inheriting the base SSLFilter to pass a new attribute). We may discuss this pattern though, because it's pretty heavy, IMHO... Issue Time Tracking --- Worklog Id: (was: 861317) Time Spent: 3h (was: 2h 50m) > Add support for endpoint identification algorithm > - > > Key: DIRMINA-1122 > URL: https://issues.apache.org/jira/browse/DIRMINA-1122 > Project: MINA > Issue Type: Improvement > Components: Filter, SSL >Affects Versions: 2.0.22, 2.1.3 >Reporter: Marcin L >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.2.0 > > Attachments: > DIRMINA-1122_-_endpoint_identification_algorithm_support.patch > > Time Spent: 3h > Remaining Estimate: 0h > > Support for endpoint identification algorithm was added in Java 1.7. > Currently MINA supports providing single SNI name via > org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but > there is no way verifying it matches the certificate received. > It would be nice if we could provide endpoint identification algorithm to > SslFilter so certificate's common name or subject alternative names are > verified. -- 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] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861287=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861287 ] ASF GitHub Bot logged work on DIRMINA-1122: --- Author: ASF GitHub Bot Created on: 10/May/23 05:53 Start Date: 10/May/23 05:53 Worklog Time Spent: 10m Work Description: the-thing commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1541392215 Good stuff. I had a peek and I can see that the solution requires custom ssl engine creation. Drop me a message if any trouble. Issue Time Tracking --- Worklog Id: (was: 861287) Time Spent: 2h 50m (was: 2h 40m) > Add support for endpoint identification algorithm > - > > Key: DIRMINA-1122 > URL: https://issues.apache.org/jira/browse/DIRMINA-1122 > Project: MINA > Issue Type: Improvement > Components: Filter, SSL >Affects Versions: 2.0.22, 2.1.3 >Reporter: Marcin L >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.2.0 > > Attachments: > DIRMINA-1122_-_endpoint_identification_algorithm_support.patch > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Support for endpoint identification algorithm was added in Java 1.7. > Currently MINA supports providing single SNI name via > org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but > there is no way verifying it matches the certificate received. > It would be nice if we could provide endpoint identification algorithm to > SslFilter so certificate's common name or subject alternative names are > verified. -- 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] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861277=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861277 ] ASF GitHub Bot logged work on DIRMINA-1122: --- Author: ASF GitHub Bot Created on: 10/May/23 03:44 Start Date: 10/May/23 03:44 Worklog Time Spent: 10m Work Description: elecharny commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1541304843 Ok, I pushed the modified code with the working tests! Issue Time Tracking --- Worklog Id: (was: 861277) Time Spent: 2h 40m (was: 2.5h) > Add support for endpoint identification algorithm > - > > Key: DIRMINA-1122 > URL: https://issues.apache.org/jira/browse/DIRMINA-1122 > Project: MINA > Issue Type: Improvement > Components: Filter, SSL >Affects Versions: 2.0.22, 2.1.3 >Reporter: Marcin L >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.2.0 > > Attachments: > DIRMINA-1122_-_endpoint_identification_algorithm_support.patch > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Support for endpoint identification algorithm was added in Java 1.7. > Currently MINA supports providing single SNI name via > org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but > there is no way verifying it matches the certificate received. > It would be nice if we could provide endpoint identification algorithm to > SslFilter so certificate's common name or subject alternative names are > verified. -- 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] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861194=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861194 ] ASF GitHub Bot logged work on DIRMINA-1122: --- Author: ASF GitHub Bot Created on: 09/May/23 13:12 Start Date: 09/May/23 13:12 Worklog Time Spent: 10m Work Description: elecharny commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1540100131 Hi, I confirm the first branch (_ssl_endpoint_algorithm_) works. It mimics MINA_2.1.X, using a PEER attribute. Issue Time Tracking --- Worklog Id: (was: 861194) Time Spent: 2.5h (was: 2h 20m) > Add support for endpoint identification algorithm > - > > Key: DIRMINA-1122 > URL: https://issues.apache.org/jira/browse/DIRMINA-1122 > Project: MINA > Issue Type: Improvement > Components: Filter, SSL >Affects Versions: 2.0.22, 2.1.3 >Reporter: Marcin L >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.2.0 > > Attachments: > DIRMINA-1122_-_endpoint_identification_algorithm_support.patch > > Time Spent: 2.5h > Remaining Estimate: 0h > > Support for endpoint identification algorithm was added in Java 1.7. > Currently MINA supports providing single SNI name via > org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but > there is no way verifying it matches the certificate received. > It would be nice if we could provide endpoint identification algorithm to > SslFilter so certificate's common name or subject alternative names are > verified. -- 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] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861155=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861155 ] ASF GitHub Bot logged work on DIRMINA-1122: --- Author: ASF GitHub Bot Created on: 09/May/23 09:20 Start Date: 09/May/23 09:20 Worklog Time Spent: 10m Work Description: the-thing commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1539764637 I was able to crate 2 branches based of 2.2.X and they both work (still waiting for the CI to run). 1) The old method - by providing the peer address. https://github.com/the-thing/mina/tree/ssl_endpoint_algorithm Probably not desired. 2) Without providing the peer address - requires additional serverNames parameter https://github.com/the-thing/mina/tree/ssl_endpoint_2 The problem with this method is that the actual server peer address will not be automatically verified and will have to be passed as a "serverName". 3) There is also another fix that doesn't require any of the above. The unit tests uses "localhost" as a host name so I would have to recreate the keystores with appropriate hostname patterns. Issue Time Tracking --- Worklog Id: (was: 861155) Time Spent: 2h 20m (was: 2h 10m) > Add support for endpoint identification algorithm > - > > Key: DIRMINA-1122 > URL: https://issues.apache.org/jira/browse/DIRMINA-1122 > Project: MINA > Issue Type: Improvement > Components: Filter, SSL >Affects Versions: 2.0.22, 2.1.3 >Reporter: Marcin L >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.2.0 > > Attachments: > DIRMINA-1122_-_endpoint_identification_algorithm_support.patch > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Support for endpoint identification algorithm was added in Java 1.7. > Currently MINA supports providing single SNI name via > org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but > there is no way verifying it matches the certificate received. > It would be nice if we could provide endpoint identification algorithm to > SslFilter so certificate's common name or subject alternative names are > verified. -- 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] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861120=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861120 ] ASF GitHub Bot logged work on DIRMINA-1122: --- Author: ASF GitHub Bot Created on: 09/May/23 05:59 Start Date: 09/May/23 05:59 Worklog Time Spent: 10m Work Description: elecharny commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1539456424 Also tested something: using the **sniHostNames** instead of doing a _peer.getHostString()_, changes nothing... Issue Time Tracking --- Worklog Id: (was: 861120) Time Spent: 2h 10m (was: 2h) > Add support for endpoint identification algorithm > - > > Key: DIRMINA-1122 > URL: https://issues.apache.org/jira/browse/DIRMINA-1122 > Project: MINA > Issue Type: Improvement > Components: Filter, SSL >Affects Versions: 2.0.22, 2.1.3 >Reporter: Marcin L >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.2.0 > > Attachments: > DIRMINA-1122_-_endpoint_identification_algorithm_support.patch > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Support for endpoint identification algorithm was added in Java 1.7. > Currently MINA supports providing single SNI name via > org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but > there is no way verifying it matches the certificate received. > It would be nice if we could provide endpoint identification algorithm to > SslFilter so certificate's common name or subject alternative names are > verified. -- 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] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861081=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861081 ] ASF GitHub Bot logged work on DIRMINA-1122: --- Author: ASF GitHub Bot Created on: 08/May/23 21:00 Start Date: 08/May/23 21:00 Worklog Time Spent: 10m Work Description: elecharny commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1539042180 Note that MINA 2.2.X don't have anymore a **PEER_ADDRESS** attribute, so we have to go through the creation of a dedicated **SslFilter** class, which extends the default **SslFilter** class. Not necessary easier, but should do the trick. Issue Time Tracking --- Worklog Id: (was: 861081) Time Spent: 2h (was: 1h 50m) > Add support for endpoint identification algorithm > - > > Key: DIRMINA-1122 > URL: https://issues.apache.org/jira/browse/DIRMINA-1122 > Project: MINA > Issue Type: Improvement > Components: Filter, SSL >Affects Versions: 2.0.22, 2.1.3 >Reporter: Marcin L >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.2.0 > > Attachments: > DIRMINA-1122_-_endpoint_identification_algorithm_support.patch > > Time Spent: 2h > Remaining Estimate: 0h > > Support for endpoint identification algorithm was added in Java 1.7. > Currently MINA supports providing single SNI name via > org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but > there is no way verifying it matches the certificate received. > It would be nice if we could provide endpoint identification algorithm to > SslFilter so certificate's common name or subject alternative names are > verified. -- 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] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[
https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861080=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861080
]
ASF GitHub Bot logged work on DIRMINA-1122:
---
Author: ASF GitHub Bot
Created on: 08/May/23 20:58
Start Date: 08/May/23 20:58
Worklog Time Spent: 10m
Work Description: elecharny commented on PR #26:
URL: https://github.com/apache/mina/pull/26#issuecomment-1539039335
On the test, we use a custom SSLFilter which sets the peer:
```
protected SSLEngine createEngine(IoSession session,
InetSocketAddress addr) {
//Add your SNI host name and port in the IOSession
String sniHostNames = (String)session.getAttribute(
"SNIHostNames" );
int portNumber = (int)session.getAttribute( "PortNumber");
InetSocketAddress peer = InetSocketAddress.createUnresolved(
sniHostNames, portNumber);
SSLEngine sslEngine = (addr != null) ?
sslContext.createSSLEngine(peer.getHostString(),
peer.getPort()) : sslContext.createSSLEngine();
...
```
The default ```SslFilter.createEngine()``` never get called when
initializing the **Connector**.
It's called only for the **Acceptor**.
Issue Time Tracking
---
Worklog Id: (was: 861080)
Time Spent: 1h 50m (was: 1h 40m)
> Add support for endpoint identification algorithm
> -
>
> Key: DIRMINA-1122
> URL: https://issues.apache.org/jira/browse/DIRMINA-1122
> Project: MINA
> Issue Type: Improvement
> Components: Filter, SSL
>Affects Versions: 2.0.22, 2.1.3
>Reporter: Marcin L
>Assignee: Jonathan Valliere
>Priority: Minor
> Fix For: 2.2.0
>
> Attachments:
> DIRMINA-1122_-_endpoint_identification_algorithm_support.patch
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Support for endpoint identification algorithm was added in Java 1.7.
> Currently MINA supports providing single SNI name via
> org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but
> there is no way verifying it matches the certificate received.
> It would be nice if we could provide endpoint identification algorithm to
> SslFilter so certificate's common name or subject alternative names are
> verified.
--
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] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[
https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861078=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861078
]
ASF GitHub Bot logged work on DIRMINA-1122:
---
Author: ASF GitHub Bot
Created on: 08/May/23 20:39
Start Date: 08/May/23 20:39
Worklog Time Spent: 10m
Work Description: the-thing commented on PR #26:
URL: https://github.com/apache/mina/pull/26#issuecomment-1539019441
I applied the changes manually to 2.2.X. The peerAddress session attribute
has been removed, which was used to get the hostname for the SSL engine.
2.1.X - org.apache.mina.filter.ssl.SslHandler#init
```
InetSocketAddress peer = (InetSocketAddress)
session.getAttribute(SslFilter.PEER_ADDRESS);
// Create the SSL engine here
if (peer == null) {
sslEngine = sslFilter.sslContext.createSSLEngine();
} else {
sslEngine = sslFilter.sslContext.createSSLEngine(peer.getHostName(),
peer.getPort());
}
```
in 2.2.X - org.apache.mina.filter.ssl.SslFilter#createEngine
```
SSLEngine sslEngine = (addr != null) ?
sslContext.createSSLEngine(addr.getHostString(), addr.getPort()) :
sslContext.createSSLEngine();
```
#getHostString seems to be the problem as it is resolved IP address instead
the actual host.
Issue Time Tracking
---
Worklog Id: (was: 861078)
Time Spent: 1h 40m (was: 1.5h)
> Add support for endpoint identification algorithm
> -
>
> Key: DIRMINA-1122
> URL: https://issues.apache.org/jira/browse/DIRMINA-1122
> Project: MINA
> Issue Type: Improvement
> Components: Filter, SSL
>Affects Versions: 2.0.22, 2.1.3
>Reporter: Marcin L
>Assignee: Jonathan Valliere
>Priority: Minor
> Fix For: 2.2.0
>
> Attachments:
> DIRMINA-1122_-_endpoint_identification_algorithm_support.patch
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Support for endpoint identification algorithm was added in Java 1.7.
> Currently MINA supports providing single SNI name via
> org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but
> there is no way verifying it matches the certificate received.
> It would be nice if we could provide endpoint identification algorithm to
> SslFilter so certificate's common name or subject alternative names are
> verified.
--
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] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861077=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861077 ] ASF GitHub Bot logged work on DIRMINA-1122: --- Author: ASF GitHub Bot Created on: 08/May/23 20:37 Start Date: 08/May/23 20:37 Worklog Time Spent: 10m Work Description: elecharny commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1539017831 FTR, here is a part of the logs I get when running the test with Java8: ``` javax.net.ssl|FINE|0F|CLIENT|2023-05-08 22:21:32.416 CEST|SSLExtensions.java:173|Ignore unavailable extension: supported_versions javax.net.ssl|FINE|0F|CLIENT|2023-05-08 22:21:32.417 CEST|ServerHello.java:955|Negotiated protocol version: TLSv1.2 javax.net.ssl|FINE|0F|CLIENT|2023-05-08 22:21:32.417 CEST|SSLExtensions.java:192|Consumed extension: renegotiation_info javax.net.ssl|FINE|0F|CLIENT|2023-05-08 22:21:32.417 CEST|SSLExtensions.java:173|Ignore unavailable extension: server_name ... ``` With Java 11: ``` javax.net.ssl|DEBUG|0F|NioProcessor-2|2023-05-08 22:36:09.415 CEST|SSLExtensions.java:192|Consumed extension: supported_versions javax.net.ssl|DEBUG|0F|NioProcessor-2|2023-05-08 22:36:09.415 CEST|ClientHello.java:839|Negotiated protocol version: TLSv1.2 javax.net.ssl|DEBUG|0F|NioProcessor-2|2023-05-08 22:36:09.416 CEST|ServerNameExtension.java:327|no server name matchers, ignore server name indication ... ``` So it seems there is a missing a **SNIMatcher** instance. Issue Time Tracking --- Worklog Id: (was: 861077) Time Spent: 1.5h (was: 1h 20m) > Add support for endpoint identification algorithm > - > > Key: DIRMINA-1122 > URL: https://issues.apache.org/jira/browse/DIRMINA-1122 > Project: MINA > Issue Type: Improvement > Components: Filter, SSL >Affects Versions: 2.0.22, 2.1.3 >Reporter: Marcin L >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.2.0 > > Attachments: > DIRMINA-1122_-_endpoint_identification_algorithm_support.patch > > Time Spent: 1.5h > Remaining Estimate: 0h > > Support for endpoint identification algorithm was added in Java 1.7. > Currently MINA supports providing single SNI name via > org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but > there is no way verifying it matches the certificate received. > It would be nice if we could provide endpoint identification algorithm to > SslFilter so certificate's common name or subject alternative names are > verified. -- 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] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[
https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861070=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861070
]
ASF GitHub Bot logged work on DIRMINA-1122:
---
Author: ASF GitHub Bot
Created on: 08/May/23 19:31
Start Date: 08/May/23 19:31
Worklog Time Spent: 10m
Work Description: elecharny commented on PR #26:
URL: https://github.com/apache/mina/pull/26#issuecomment-1538929098
Actually, all the handshakes are passing, which make the *shouldFailXXX*
tests failing.
Here is the modified test class for MINA 2.2.X:
```
package org.apache.mina.filter.ssl;
import org.apache.mina.core.filterchain.DefaultIoFilterChainBuilder;
import org.apache.mina.core.filterchain.IoFilterChain;
import org.apache.mina.core.service.IoHandlerAdapter;
import org.apache.mina.core.session.IoSession;
import org.apache.mina.filter.FilterEvent;
import org.apache.mina.filter.codec.ProtocolCodecFilter;
import org.apache.mina.filter.codec.textline.TextLineCodecFactory;
import org.apache.mina.transport.socket.nio.NioSocketAcceptor;
import org.apache.mina.transport.socket.nio.NioSocketConnector;
import org.apache.mina.util.AvailablePortFinder;
import org.junit.Before;
import org.junit.Test;
import javax.net.ssl.KeyManagerFactory;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLException;
import javax.net.ssl.TrustManagerFactory;
import java.net.InetSocketAddress;
import java.security.KeyStore;
import java.security.Security;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;
import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;
/**
* Test SNI matching scenarios. (tests for DIRMINA-1122)
*
*
* emptykeystore.sslTest- empty keystore
* server-cn.keystore - keystore with single certificate chain
(CN=mina)
* client-cn.truststore - keystore with trusted certificate
* server-san-ext.keystore - keystore with single certificate chain
(CN=mina;SAN=*.bbb.ccc,xxx.yyy)
* client-san-ext.truststore- keystore with trusted certificate
*
*/
public class SslIdentificationAlgorithmTest {
private static final String KEY_MANAGER_FACTORY_ALGORITHM;
static {
String algorithm =
Security.getProperty("ssl.KeyManagerFactory.algorithm");
if (algorithm == null) {
algorithm = KeyManagerFactory.getDefaultAlgorithm();
}
KEY_MANAGER_FACTORY_ALGORITHM = algorithm;
}
private int port;
private CountDownLatch handshakeDone;
@Before
public void setUp() {
port = AvailablePortFinder.getNextAvailable();
handshakeDone = new CountDownLatch(2);
}
@Test
public void
shouldAuthenticateWhenServerCertificateCommonNameMatchesClientSNI() throws
Exception {
SSLContext acceptorContext = createSSLContext("server-cn.keystore",
"emptykeystore.sslTest");
SSLContext connectorContext =
createSSLContext("emptykeystore.sslTest", "client-cn.truststore");
startAcceptor(acceptorContext);
startConnector(connectorContext, "mina");
assertTrue(handshakeDone.await(10, TimeUnit.SECONDS));
}
@Test
public void
shouldFailAuthenticationWhenServerCertificateCommonNameDoesNotMatchClientSNI()
throws Exception {
SSLContext acceptorContext = createSSLContext("server-cn.keystore",
"emptykeystore.sslTest");
SSLContext connectorContext =
createSSLContext("emptykeystore.sslTest", "client-cn.truststore");
startAcceptor(acceptorContext);
startConnector(connectorContext, "example.com");
assertFalse(handshakeDone.await(10, TimeUnit.SECONDS));
}
@Test
public void
shouldFailAuthenticationWhenClientMissingSNIAndIdentificationAlgorithmProvided()
throws Exception {
SSLContext acceptorContext = createSSLContext("server-cn.keystore",
"emptykeystore.sslTest");
SSLContext connectorContext =
createSSLContext("emptykeystore.sslTest", "client-cn.truststore");
startAcceptor(acceptorContext);
startConnector(connectorContext, null);
assertFalse(handshakeDone.await(10, TimeUnit.SECONDS));
}
/**
* Subject Alternative Name (SAN) scenarios
*/
@Test
public void
shouldAuthenticateWhenServerCertificateAlternativeNameMatchesClientSNIExactly()
throws Exception {
SSLContext acceptorContext =
createSSLContext("server-san-ext.keystore", "emptykeystore.sslTest");
SSLContext connectorContext =
createSSLContext("emptykeystore.sslTest",
[jira] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861068=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861068 ] ASF GitHub Bot logged work on DIRMINA-1122: --- Author: ASF GitHub Bot Created on: 08/May/23 18:39 Start Date: 08/May/23 18:39 Worklog Time Spent: 10m Work Description: the-thing commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1538856723 Interesting. I can produce a patch quickly if I can recreate the failure. If you could share some of the error logs or environment details it would be helpful. Issue Time Tracking --- Worklog Id: (was: 861068) Time Spent: 1h 10m (was: 1h) > Add support for endpoint identification algorithm > - > > Key: DIRMINA-1122 > URL: https://issues.apache.org/jira/browse/DIRMINA-1122 > Project: MINA > Issue Type: Improvement > Components: Filter, SSL >Affects Versions: 2.0.22, 2.1.3 >Reporter: Marcin L >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.2.0 > > Attachments: > DIRMINA-1122_-_endpoint_identification_algorithm_support.patch > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Support for endpoint identification algorithm was added in Java 1.7. > Currently MINA supports providing single SNI name via > org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but > there is no way verifying it matches the certificate received. > It would be nice if we could provide endpoint identification algorithm to > SslFilter so certificate's common name or subject alternative names are > verified. -- 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] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861065=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861065 ] ASF GitHub Bot logged work on DIRMINA-1122: --- Author: ASF GitHub Bot Created on: 08/May/23 18:23 Start Date: 08/May/23 18:23 Worklog Time Spent: 10m Work Description: elecharny commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1538838101 Hmmm, the patch has been merged, but the tests are failing: the positive tests are OK, but the negative ones aren't. Also the TLS protocol is not anymore supported by Java 8, I had to switch to TLSv1.2. I'm investigating what could go wrong in MINA 2.1.X and 2.2.X branches, as the implementation is different. Issue Time Tracking --- Worklog Id: (was: 861065) Time Spent: 1h (was: 50m) > Add support for endpoint identification algorithm > - > > Key: DIRMINA-1122 > URL: https://issues.apache.org/jira/browse/DIRMINA-1122 > Project: MINA > Issue Type: Improvement > Components: Filter, SSL >Affects Versions: 2.0.22, 2.1.3 >Reporter: Marcin L >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.2.0 > > Attachments: > DIRMINA-1122_-_endpoint_identification_algorithm_support.patch > > Time Spent: 1h > Remaining Estimate: 0h > > Support for endpoint identification algorithm was added in Java 1.7. > Currently MINA supports providing single SNI name via > org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but > there is no way verifying it matches the certificate received. > It would be nice if we could provide endpoint identification algorithm to > SslFilter so certificate's common name or subject alternative names are > verified. -- 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] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=859818=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859818 ] ASF GitHub Bot logged work on DIRMINA-1122: --- Author: ASF GitHub Bot Created on: 30/Apr/23 03:53 Start Date: 30/Apr/23 03:53 Worklog Time Spent: 10m Work Description: elecharny merged PR #26: URL: https://github.com/apache/mina/pull/26 Issue Time Tracking --- Worklog Id: (was: 859818) Time Spent: 50m (was: 40m) > Add support for endpoint identification algorithm > - > > Key: DIRMINA-1122 > URL: https://issues.apache.org/jira/browse/DIRMINA-1122 > Project: MINA > Issue Type: Improvement > Components: Filter, SSL >Affects Versions: 2.0.22, 2.1.3 >Reporter: Marcin L >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.2.0 > > Attachments: > DIRMINA-1122_-_endpoint_identification_algorithm_support.patch > > Time Spent: 50m > Remaining Estimate: 0h > > Support for endpoint identification algorithm was added in Java 1.7. > Currently MINA supports providing single SNI name via > org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but > there is no way verifying it matches the certificate received. > It would be nice if we could provide endpoint identification algorithm to > SslFilter so certificate's common name or subject alternative names are > verified. -- 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] [Work logged] (DIRMINA-1169) BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
[
https://issues.apache.org/jira/browse/DIRMINA-1169?focusedWorklogId=859104=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859104
]
ASF GitHub Bot logged work on DIRMINA-1169:
---
Author: ASF GitHub Bot
Created on: 26/Apr/23 08:59
Start Date: 26/Apr/23 08:59
Worklog Time Spent: 10m
Work Description: chrjohn commented on PR #35:
URL: https://github.com/apache/mina/pull/35#issuecomment-1523040118
No problem at all. :)
Issue Time Tracking
---
Worklog Id: (was: 859104)
Time Spent: 1h (was: 50m)
> BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
> --
>
> Key: DIRMINA-1169
> URL: https://issues.apache.org/jira/browse/DIRMINA-1169
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.23, 2.1.6, 2.2.1
>Reporter: Thomas Wolf
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> See also SSHD-1256.
> The main acceptor loop does basically (somewhat simplified):
> {code:java}
> while (selectable) {
> registerHandles(); // Process registration queue: add new sockets (from
> bind()) to the selector with OP_ACCEPT, fulfills their open futures
> int selected = select();
> if (/* nothing to do */) {
> break; // and end the thread; higher layers will create a new one if
> needed
> }
> if (selected > 0) {
> processHandles(selectedHandles()); // Handle and hand off new connections
> }
> unregisterHandles(); // Process cancel queue: cancel SelectionKey, close
> ServerSocketChannel, fulfill the cancel future
> }
> {code}
> With Java 11, unbinding a {{ServerSocketChannel}} changed:
> * [JDK-8214430|https://bugs.openjdk.org/browse/JDK-8214430]
> * [Java 11 Release
> Notes|https://www.oracle.com/java/technologies/javase/11-relnote-issues.html#JDK-8198562]
> Essentially the unbind gives up the socket only at the next {{select()}}
> call. This causes two problems in Apache MINA's acceptor:
> * The unbind future is set "done" before the socket is actually released.
> * If a new binding for one of the unbound sockets is registered before that
> {{select()}} has been done, {{registerHandles()}} gets a {{BindException}}
> ("address already in use").
> So for Java >= 11, the code must ensure that there is a {{select()}} between
> processing unbindings and processing new bindings, and the unbind futures
> must be set "done" only after that {{select()}}.
--
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] [Work logged] (DIRMINA-1169) BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
[
https://issues.apache.org/jira/browse/DIRMINA-1169?focusedWorklogId=859103=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859103
]
ASF GitHub Bot logged work on DIRMINA-1169:
---
Author: ASF GitHub Bot
Created on: 26/Apr/23 08:57
Start Date: 26/Apr/23 08:57
Worklog Time Spent: 10m
Work Description: elecharny commented on PR #35:
URL: https://github.com/apache/mina/pull/35#issuecomment-1523035898
Will check that for 2.1 and 2.2 this week. Sorry for the delay...
Issue Time Tracking
---
Worklog Id: (was: 859103)
Time Spent: 50m (was: 40m)
> BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
> --
>
> Key: DIRMINA-1169
> URL: https://issues.apache.org/jira/browse/DIRMINA-1169
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.23, 2.1.6, 2.2.1
>Reporter: Thomas Wolf
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> See also SSHD-1256.
> The main acceptor loop does basically (somewhat simplified):
> {code:java}
> while (selectable) {
> registerHandles(); // Process registration queue: add new sockets (from
> bind()) to the selector with OP_ACCEPT, fulfills their open futures
> int selected = select();
> if (/* nothing to do */) {
> break; // and end the thread; higher layers will create a new one if
> needed
> }
> if (selected > 0) {
> processHandles(selectedHandles()); // Handle and hand off new connections
> }
> unregisterHandles(); // Process cancel queue: cancel SelectionKey, close
> ServerSocketChannel, fulfill the cancel future
> }
> {code}
> With Java 11, unbinding a {{ServerSocketChannel}} changed:
> * [JDK-8214430|https://bugs.openjdk.org/browse/JDK-8214430]
> * [Java 11 Release
> Notes|https://www.oracle.com/java/technologies/javase/11-relnote-issues.html#JDK-8198562]
> Essentially the unbind gives up the socket only at the next {{select()}}
> call. This causes two problems in Apache MINA's acceptor:
> * The unbind future is set "done" before the socket is actually released.
> * If a new binding for one of the unbound sockets is registered before that
> {{select()}} has been done, {{registerHandles()}} gets a {{BindException}}
> ("address already in use").
> So for Java >= 11, the code must ensure that there is a {{select()}} between
> processing unbindings and processing new bindings, and the unbind futures
> must be set "done" only after that {{select()}}.
--
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] [Work logged] (DIRMINA-1124) make NioProcessor and NioSocketAcceptor extendable
[ https://issues.apache.org/jira/browse/DIRMINA-1124?focusedWorklogId=837703=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-837703 ] ASF GitHub Bot logged work on DIRMINA-1124: --- Author: ASF GitHub Bot Created on: 07/Jan/23 22:06 Start Date: 07/Jan/23 22:06 Worklog Time Spent: 10m Work Description: jon-valliere closed pull request #25: DIRMINA-1124 : make NioProcessor and NioSocketAcceptor extendable by removing final from class declaration URL: https://github.com/apache/mina/pull/25 Issue Time Tracking --- Worklog Id: (was: 837703) Time Spent: 1h (was: 50m) > make NioProcessor and NioSocketAcceptor extendable > -- > > Key: DIRMINA-1124 > URL: https://issues.apache.org/jira/browse/DIRMINA-1124 > Project: MINA > Issue Type: Improvement > Components: Core >Affects Versions: 2.1.4 >Reporter: anna kukliansky >Priority: Major > Attachments: patch.diff > > Time Spent: 1h > Remaining Estimate: 0h > > We would like to be able to exetnd those two classes: NioProcessor, > NioSocketAcceptor. > In our implemenetastion most of the code is taken from those two classes as > is , except for severl mathod that have some inhensments. Thus it would be a > shame to capy the code and better to extend it. > here is the PR with the implementation: > [https://github.com/apache/mina/pull/25] > [^patch.diff] -- 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] [Work logged] (DIRMINA-1124) make NioProcessor and NioSocketAcceptor extendable
[ https://issues.apache.org/jira/browse/DIRMINA-1124?focusedWorklogId=837702=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-837702 ] ASF GitHub Bot logged work on DIRMINA-1124: --- Author: ASF GitHub Bot Created on: 07/Jan/23 22:06 Start Date: 07/Jan/23 22:06 Worklog Time Spent: 10m Work Description: jon-valliere commented on PR #25: URL: https://github.com/apache/mina/pull/25#issuecomment-1374629832 Closing because the patch was merged into main on https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=53d96b92d4bf14fad2b87d8fdeca4ebc5019b6d8 Issue Time Tracking --- Worklog Id: (was: 837702) Time Spent: 50m (was: 40m) > make NioProcessor and NioSocketAcceptor extendable > -- > > Key: DIRMINA-1124 > URL: https://issues.apache.org/jira/browse/DIRMINA-1124 > Project: MINA > Issue Type: Improvement > Components: Core >Affects Versions: 2.1.4 >Reporter: anna kukliansky >Priority: Major > Attachments: patch.diff > > Time Spent: 50m > Remaining Estimate: 0h > > We would like to be able to exetnd those two classes: NioProcessor, > NioSocketAcceptor. > In our implemenetastion most of the code is taken from those two classes as > is , except for severl mathod that have some inhensments. Thus it would be a > shame to capy the code and better to extend it. > here is the PR with the implementation: > [https://github.com/apache/mina/pull/25] > [^patch.diff] -- 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] [Work logged] (DIRMINA-1169) BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
[
https://issues.apache.org/jira/browse/DIRMINA-1169?focusedWorklogId=830365=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-830365
]
ASF GitHub Bot logged work on DIRMINA-1169:
---
Author: ASF GitHub Bot
Created on: 01/Dec/22 14:45
Start Date: 01/Dec/22 14:45
Worklog Time Spent: 10m
Work Description: chrjohn commented on PR #35:
URL: https://github.com/apache/mina/pull/35#issuecomment-1333873016
@elecharny Any chance that this could be integrated into 2.1.x (and later
2.2.x) and released? It causes spurious failures in our test suite.
Thank you in advance
Issue Time Tracking
---
Worklog Id: (was: 830365)
Time Spent: 40m (was: 0.5h)
> BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
> --
>
> Key: DIRMINA-1169
> URL: https://issues.apache.org/jira/browse/DIRMINA-1169
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.23, 2.1.6, 2.2.1
>Reporter: Thomas Wolf
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> See also SSHD-1256.
> The main acceptor loop does basically (somewhat simplified):
> {code:java}
> while (selectable) {
> registerHandles(); // Process registration queue: add new sockets (from
> bind()) to the selector with OP_ACCEPT, fulfills their open futures
> int selected = select();
> if (/* nothing to do */) {
> break; // and end the thread; higher layers will create a new one if
> needed
> }
> if (selected > 0) {
> processHandles(selectedHandles()); // Handle and hand off new connections
> }
> unregisterHandles(); // Process cancel queue: cancel SelectionKey, close
> ServerSocketChannel, fulfill the cancel future
> }
> {code}
> With Java 11, unbinding a {{ServerSocketChannel}} changed:
> * [JDK-8214430|https://bugs.openjdk.org/browse/JDK-8214430]
> * [Java 11 Release
> Notes|https://www.oracle.com/java/technologies/javase/11-relnote-issues.html#JDK-8198562]
> Essentially the unbind gives up the socket only at the next {{select()}}
> call. This causes two problems in Apache MINA's acceptor:
> * The unbind future is set "done" before the socket is actually released.
> * If a new binding for one of the unbound sockets is registered before that
> {{select()}} has been done, {{registerHandles()}} gets a {{BindException}}
> ("address already in use").
> So for Java >= 11, the code must ensure that there is a {{select()}} between
> processing unbindings and processing new bindings, and the unbind futures
> must be set "done" only after that {{select()}}.
--
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] [Work logged] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
[
https://issues.apache.org/jira/browse/SSHD-1307?focusedWorklogId=821134=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-821134
]
ASF GitHub Bot logged work on SSHD-1307:
Author: ASF GitHub Bot
Created on: 27/Oct/22 18:32
Start Date: 27/Oct/22 18:32
Worklog Time Spent: 10m
Work Description: tomaswolf commented on PR #257:
URL: https://github.com/apache/mina-sshd/pull/257#issuecomment-1293914238
Answer is on
[SSHD-1307](https://issues.apache.org/jira/browse/SSHD-1307?focusedCommentId=17625229=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17625229),
where you had asked the same.
Issue Time Tracking
---
Worklog Id: (was: 821134)
Time Spent: 1h (was: 50m)
> Nio2Session.shutdownOutput() should wait for writes in progress
> ---
>
> Key: SSHD-1307
> URL: https://issues.apache.org/jira/browse/SSHD-1307
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Thomas Wolf
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.9.2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Split out from
> [SSHD-1055|https://issues.apache.org/jira/browse/SSHD-1055?focusedCommentId=17621354=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17621354]:
> I am currently experiencing an exception that appears to be related to the
> use of the serverSession.shudownOutputStream(); in the
> TcpIpClientChannel.handleEOF method.
> My context is the following
> * Apache Mina sshd client version 2.9.1 on the local side.
> * OpenSSH 5.9 on the remote server side.
> * Local port forwarding port 9000 to remote localhost:8080
> * The error occurs on the Apache Mina sshd client side.
> I intermittently take exceptions on URL connections that are completed and
> they have received the last of the data and is processing the
> SSH_MSG_CHANNEL_EOF
> Any ideas or thoughts would be appreciated.
> {code:java}
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=999
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 999 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=2
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 2 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=115
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 115 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleEof(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_EOF
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> shudownOutputStream(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027])
> 09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleWriteCycleFailure(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) failed (ClosedChannelException) to write 115 bytes
> at write cycle=17 afer 987500 nanos: null
> 09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> caught ClosedChannelException[null] - calling handler
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleReadCycleCompletion(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) Socket has been disconnected (result=-1), closing
> IoSession now
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
>
[jira] [Work logged] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
[
https://issues.apache.org/jira/browse/SSHD-1307?focusedWorklogId=821103=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-821103
]
ASF GitHub Bot logged work on SSHD-1307:
Author: ASF GitHub Bot
Created on: 27/Oct/22 17:38
Start Date: 27/Oct/22 17:38
Worklog Time Spent: 10m
Work Description: AlexanderAmador commented on PR #257:
URL: https://github.com/apache/mina-sshd/pull/257#issuecomment-1293857850
I am interested in acquiring this fix in a release. I saw a comment that
your next release may be 2.10.0. Do you have an ETA on that release ?
Issue Time Tracking
---
Worklog Id: (was: 821103)
Time Spent: 50m (was: 40m)
> Nio2Session.shutdownOutput() should wait for writes in progress
> ---
>
> Key: SSHD-1307
> URL: https://issues.apache.org/jira/browse/SSHD-1307
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Thomas Wolf
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.9.2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Split out from
> [SSHD-1055|https://issues.apache.org/jira/browse/SSHD-1055?focusedCommentId=17621354=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17621354]:
> I am currently experiencing an exception that appears to be related to the
> use of the serverSession.shudownOutputStream(); in the
> TcpIpClientChannel.handleEOF method.
> My context is the following
> * Apache Mina sshd client version 2.9.1 on the local side.
> * OpenSSH 5.9 on the remote server side.
> * Local port forwarding port 9000 to remote localhost:8080
> * The error occurs on the Apache Mina sshd client side.
> I intermittently take exceptions on URL connections that are completed and
> they have received the last of the data and is processing the
> SSH_MSG_CHANNEL_EOF
> Any ideas or thoughts would be appreciated.
> {code:java}
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=999
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 999 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=2
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 2 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=115
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 115 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleEof(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_EOF
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> shudownOutputStream(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027])
> 09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleWriteCycleFailure(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) failed (ClosedChannelException) to write 115 bytes
> at write cycle=17 afer 987500 nanos: null
> 09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> caught ClosedChannelException[null] - calling handler
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleReadCycleCompletion(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) Socket has been disconnected (result=-1), closing
> IoSession now
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> close(Nio2Session[local=/127.0.0.1:9000,
[jira] [Work logged] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
[
https://issues.apache.org/jira/browse/SSHD-1307?focusedWorklogId=819817=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-819817
]
ASF GitHub Bot logged work on SSHD-1307:
Author: ASF GitHub Bot
Created on: 24/Oct/22 19:12
Start Date: 24/Oct/22 19:12
Worklog Time Spent: 10m
Work Description: tomaswolf merged PR #257:
URL: https://github.com/apache/mina-sshd/pull/257
Issue Time Tracking
---
Worklog Id: (was: 819817)
Time Spent: 40m (was: 0.5h)
> Nio2Session.shutdownOutput() should wait for writes in progress
> ---
>
> Key: SSHD-1307
> URL: https://issues.apache.org/jira/browse/SSHD-1307
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Thomas Wolf
>Assignee: Thomas Wolf
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Split out from
> [SSHD-1055|https://issues.apache.org/jira/browse/SSHD-1055?focusedCommentId=17621354=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17621354]:
> I am currently experiencing an exception that appears to be related to the
> use of the serverSession.shudownOutputStream(); in the
> TcpIpClientChannel.handleEOF method.
> My context is the following
> * Apache Mina sshd client version 2.9.1 on the local side.
> * OpenSSH 5.9 on the remote server side.
> * Local port forwarding port 9000 to remote localhost:8080
> * The error occurs on the Apache Mina sshd client side.
> I intermittently take exceptions on URL connections that are completed and
> they have received the last of the data and is processing the
> SSH_MSG_CHANNEL_EOF
> Any ideas or thoughts would be appreciated.
> {code:java}
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=999
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 999 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=2
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 2 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=115
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 115 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleEof(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_EOF
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> shudownOutputStream(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027])
> 09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleWriteCycleFailure(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) failed (ClosedChannelException) to write 115 bytes
> at write cycle=17 afer 987500 nanos: null
> 09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> caught ClosedChannelException[null] - calling handler
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleReadCycleCompletion(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) Socket has been disconnected (result=-1), closing
> IoSession now
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> close(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027]) Closing
> immediately
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> doCloseImmediately(Nio2Session[local=/127.0.0.1:9000,
>
[jira] [Work logged] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
[
https://issues.apache.org/jira/browse/SSHD-1307?focusedWorklogId=819792=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-819792
]
ASF GitHub Bot logged work on SSHD-1307:
Author: ASF GitHub Bot
Created on: 24/Oct/22 17:36
Start Date: 24/Oct/22 17:36
Worklog Time Spent: 10m
Work Description: tomaswolf commented on code in PR #257:
URL: https://github.com/apache/mina-sshd/pull/257#discussion_r1003582623
##
sshd-core/src/main/java/org/apache/sshd/common/io/nio2/Nio2Session.java:
##
@@ -298,24 +300,44 @@ public Nio2Service getService() {
@Override
public void shutdownOutputStream() throws IOException {
-AsynchronousSocketChannel socket = getSocket();
-if (socket.isOpen()) {
-if (log.isDebugEnabled()) {
-log.debug("shudownOutputStream({})", this);
-}
-try {
-socket.shutdownOutput();
-} catch (ClosedChannelException e) {
-// This may get called on a Channel EOF in TCP/IP port
forwarding. But reading and writing run
-// asynchronously, so it is possible that the socket channel
is actually closed here and the producer
-// that wrote into this channel has already disconnected.
-//
-// As this is asynchronous, there is a race condition here.
The isOpen() test above does not guarantee
-// that the socket channel is indeed open when we call
shutdownOutput().
-//
-// In any case it's safe here to ignore this exception as
we're trying to shut down an external end
-// of a TCP/IP port forwarding.
+if (outputShutDown.compareAndSet(false, true)) {
+// Schedule a "shut down the output stream" fake write packet with
a null buffer. Let already pending writes
+// finish first.
+Nio2DefaultIoWriteFuture future = new
Nio2DefaultIoWriteFuture("shutdown-" + getRemoteAddress(), null, null);
+writes.add(future);
+startWriting();
+}
+}
+
+protected void doShutdownOutputStream(Nio2DefaultIoWriteFuture future,
AsynchronousSocketChannel socket)
+throws IOException {
+try {
+if (socket.isOpen()) {
+if (log.isDebugEnabled()) {
+log.debug("doShutdownOutputStream({})", this);
+}
+try {
+socket.shutdownOutput();
+} catch (ClosedChannelException e) {
+// This may get called on a Channel EOF in TCP/IP port
forwarding. But reading and writing run
Review Comment:
Done.
Issue Time Tracking
---
Worklog Id: (was: 819792)
Time Spent: 0.5h (was: 20m)
> Nio2Session.shutdownOutput() should wait for writes in progress
> ---
>
> Key: SSHD-1307
> URL: https://issues.apache.org/jira/browse/SSHD-1307
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Thomas Wolf
>Assignee: Thomas Wolf
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Split out from
> [SSHD-1055|https://issues.apache.org/jira/browse/SSHD-1055?focusedCommentId=17621354=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17621354]:
> I am currently experiencing an exception that appears to be related to the
> use of the serverSession.shudownOutputStream(); in the
> TcpIpClientChannel.handleEOF method.
> My context is the following
> * Apache Mina sshd client version 2.9.1 on the local side.
> * OpenSSH 5.9 on the remote server side.
> * Local port forwarding port 9000 to remote localhost:8080
> * The error occurs on the Apache Mina sshd client side.
> I intermittently take exceptions on URL connections that are completed and
> they have received the last of the data and is processing the
> SSH_MSG_CHANNEL_EOF
> Any ideas or thoughts would be appreciated.
> {code:java}
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=999
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 999 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA
[jira] [Work logged] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
[
https://issues.apache.org/jira/browse/SSHD-1307?focusedWorklogId=819786=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-819786
]
ASF GitHub Bot logged work on SSHD-1307:
Author: ASF GitHub Bot
Created on: 24/Oct/22 17:16
Start Date: 24/Oct/22 17:16
Worklog Time Spent: 10m
Work Description: lgoldstein commented on code in PR #257:
URL: https://github.com/apache/mina-sshd/pull/257#discussion_r1003563357
##
sshd-core/src/main/java/org/apache/sshd/common/io/nio2/Nio2Session.java:
##
@@ -298,24 +300,44 @@ public Nio2Service getService() {
@Override
public void shutdownOutputStream() throws IOException {
-AsynchronousSocketChannel socket = getSocket();
-if (socket.isOpen()) {
-if (log.isDebugEnabled()) {
-log.debug("shudownOutputStream({})", this);
-}
-try {
-socket.shutdownOutput();
-} catch (ClosedChannelException e) {
-// This may get called on a Channel EOF in TCP/IP port
forwarding. But reading and writing run
-// asynchronously, so it is possible that the socket channel
is actually closed here and the producer
-// that wrote into this channel has already disconnected.
-//
-// As this is asynchronous, there is a race condition here.
The isOpen() test above does not guarantee
-// that the socket channel is indeed open when we call
shutdownOutput().
-//
-// In any case it's safe here to ignore this exception as
we're trying to shut down an external end
-// of a TCP/IP port forwarding.
+if (outputShutDown.compareAndSet(false, true)) {
+// Schedule a "shut down the output stream" fake write packet with
a null buffer. Let already pending writes
+// finish first.
+Nio2DefaultIoWriteFuture future = new
Nio2DefaultIoWriteFuture("shutdown-" + getRemoteAddress(), null, null);
+writes.add(future);
+startWriting();
+}
+}
+
+protected void doShutdownOutputStream(Nio2DefaultIoWriteFuture future,
AsynchronousSocketChannel socket)
+throws IOException {
+try {
+if (socket.isOpen()) {
+if (log.isDebugEnabled()) {
+log.debug("doShutdownOutputStream({})", this);
+}
+try {
+socket.shutdownOutput();
+} catch (ClosedChannelException e) {
+// This may get called on a Channel EOF in TCP/IP port
forwarding. But reading and writing run
Review Comment:
I think we should log this exception as DEBUG or TRACE level so that we can
tell if it happened.
Issue Time Tracking
---
Worklog Id: (was: 819786)
Time Spent: 20m (was: 10m)
> Nio2Session.shutdownOutput() should wait for writes in progress
> ---
>
> Key: SSHD-1307
> URL: https://issues.apache.org/jira/browse/SSHD-1307
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Thomas Wolf
>Assignee: Thomas Wolf
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Split out from
> [SSHD-1055|https://issues.apache.org/jira/browse/SSHD-1055?focusedCommentId=17621354=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17621354]:
> I am currently experiencing an exception that appears to be related to the
> use of the serverSession.shudownOutputStream(); in the
> TcpIpClientChannel.handleEOF method.
> My context is the following
> * Apache Mina sshd client version 2.9.1 on the local side.
> * OpenSSH 5.9 on the remote server side.
> * Local port forwarding port 9000 to remote localhost:8080
> * The error occurs on the Apache Mina sshd client side.
> I intermittently take exceptions on URL connections that are completed and
> they have received the last of the data and is processing the
> SSH_MSG_CHANNEL_EOF
> Any ideas or thoughts would be appreciated.
> {code:java}
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=999
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 999 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
>
[jira] [Work logged] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
[
https://issues.apache.org/jira/browse/SSHD-1307?focusedWorklogId=819382=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-819382
]
ASF GitHub Bot logged work on SSHD-1307:
Author: ASF GitHub Bot
Created on: 22/Oct/22 21:41
Start Date: 22/Oct/22 21:41
Worklog Time Spent: 10m
Work Description: tomaswolf opened a new pull request, #257:
URL: https://github.com/apache/mina-sshd/pull/257
Nio2Session.shutdownOutputStream() can be invoked while there are still
writes in progress. The output is shut down in TCP/IP port forwarding to
propagate an SSH_MSG_CHANNEL_EOF from the channel to whatever is on the other
side of the forwarded port; see SSHD-1055. However, writing through the socket
is asynchronous, so a channel may get the following sequence of events:
1. receive last SSH_MSG_CHANNEL_DATA
2. Nio2Session.writeBuffer() enqueues the write request
3. SSH_MSG_CHANNEL_DATA handling completes
4. receive SSH_MSG_CHANNEL_EOF
5. call Nio2Session.shutdownOutputStream()
If (5) shuts down the output immediately but the write request from (2) has
not been written yet, that write attempt will fail with a
ClosedChannelException.
The output stream on the socket should not be shut down immediately but only
once already pending writes have been done. This is already the case with the
MINA and Netty transport back-ends, which only schedule a shutdown request on
their write queue.
Implement the same for the NIO2 transport. A write future with a null buffer
signifies a shutdown request; true write requests always have a non-null
buffer. Make shutdownOutputStream() only enqueue such a shutdown request on the
session's write queue; the output will be shut down once startWriting() pops
this shutdown request from the write queue.
Issue Time Tracking
---
Worklog Id: (was: 819382)
Remaining Estimate: 0h
Time Spent: 10m
> Nio2Session.shutdownOutput() should wait for writes in progress
> ---
>
> Key: SSHD-1307
> URL: https://issues.apache.org/jira/browse/SSHD-1307
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Thomas Wolf
>Assignee: Thomas Wolf
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Split out from
> [SSHD-1055|https://issues.apache.org/jira/browse/SSHD-1055?focusedCommentId=17621354=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17621354]:
> I am currently experiencing an exception that appears to be related to the
> use of the serverSession.shudownOutputStream(); in the
> TcpIpClientChannel.handleEOF method.
> My context is the following
> * Apache Mina sshd client version 2.9.1 on the local side.
> * OpenSSH 5.9 on the remote server side.
> * Local port forwarding port 9000 to remote localhost:8080
> * The error occurs on the Apache Mina sshd client side.
> I intermittently take exceptions on URL connections that are completed and
> they have received the last of the data and is processing the
> SSH_MSG_CHANNEL_EOF
> Any ideas or thoughts would be appreciated.
> {code:java}
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=999
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 999 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=2
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 2 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=115
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 115 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleEof(TcpipClientChannel[id=71,
>
[jira] [Work logged] (SSHD-1302) Reading again from exhausted ChannelExec#getInvertedOut() throws IOException instead of returning -1
[
https://issues.apache.org/jira/browse/SSHD-1302?focusedWorklogId=819380=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-819380
]
ASF GitHub Bot logged work on SSHD-1302:
Author: ASF GitHub Bot
Created on: 22/Oct/22 21:37
Start Date: 22/Oct/22 21:37
Worklog Time Spent: 10m
Work Description: tomaswolf merged PR #256:
URL: https://github.com/apache/mina-sshd/pull/256
Issue Time Tracking
---
Worklog Id: (was: 819380)
Time Spent: 20m (was: 10m)
> Reading again from exhausted ChannelExec#getInvertedOut() throws IOException
> instead of returning -1
>
>
> Key: SSHD-1302
> URL: https://issues.apache.org/jira/browse/SSHD-1302
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Assignee: Thomas Wolf
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hello!
> If I read an input stream until end of it, and then read it again, it throws
> an exception.
> Here is the test case:
> {code:java}
> BufferedReader input;
> String line;
> //process.getInputStream() gets its value from
> ChannelExec#getInvertedOut()
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> {code}
> Here is an output excerpt:
> {quote}getInputStream:
> org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> total 0
> drwx--. 3 root root 17 Oct 17 10:31
> systemd-private-c3ce924f90c24e4a86f637831f434fe3-chronyd.service-DwM2fR
> drwx--. 3 root root 17 Oct 14 13:22
> systemd-private-e0701fd845894b6087a236a976c00b35-chronyd.service-2z3OOv
> getInputStream: org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> Exception in thread "main" java.io.IOException: Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389){quote}
> It looks the input stream is closed.
> is it possible not to throw an exception to rely on java.io.InputStream ?
> 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] [Work logged] (SSHD-1302) Handling empty ChannelExec#getInvertedOut() to rely on InputStream
[
https://issues.apache.org/jira/browse/SSHD-1302?focusedWorklogId=819257=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-819257
]
ASF GitHub Bot logged work on SSHD-1302:
Author: ASF GitHub Bot
Created on: 21/Oct/22 20:05
Start Date: 21/Oct/22 20:05
Worklog Time Spent: 10m
Work Description: tomaswolf opened a new pull request, #256:
URL: https://github.com/apache/mina-sshd/pull/256
Closing them when the channel closes leads to the strange situation that the
application reads from an already closed InputStream. That's not a good idea.
It's the caller's responsibility to close the input stream obtained from
Channel.getInvertedOut() or getInvertedErr(). And of course it should do so
only after it has read all the data it wanted, and the channel is closed.
It's not a real problem if the stream is not closed (for instance, if the
application never even called getInvertedOut() and never read anything).
Closing doesn't do much anyway except awaking a potentially waiting read()
call. Moreover, if the channel is short-lived and didn't transmit a lot of
data, the application may well start reading from the stream only after the
underlying SSH channel is already closed.
One problem with this ChannelPipedInputStream is that it may buffer up to a
full SSH channel window. If the window size is large, that may consume a lot of
memory if the application only reads infrequently (or doesn't read at all).
However, not reading from such a stream is bad practice anyway if there is any
chance that there might be a substantial amount of data; as with processes, it
may lead to a blocked execution when buffers fill up or the channel window is
exhausted.
Issue Time Tracking
---
Worklog Id: (was: 819257)
Remaining Estimate: 0h
Time Spent: 10m
> Handling empty ChannelExec#getInvertedOut() to rely on InputStream
> --
>
> Key: SSHD-1302
> URL: https://issues.apache.org/jira/browse/SSHD-1302
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Assignee: Thomas Wolf
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello!
> If I read an input stream until end of it, and then read it again, it throws
> an exception.
> Here is the test case:
> {code:java}
> BufferedReader input;
> String line;
> //process.getInputStream() gets its value from
> ChannelExec#getInvertedOut()
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> {code}
> Here is an output excerpt:
> {quote}getInputStream:
> org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> total 0
> drwx--. 3 root root 17 Oct 17 10:31
> systemd-private-c3ce924f90c24e4a86f637831f434fe3-chronyd.service-DwM2fR
> drwx--. 3 root root 17 Oct 14 13:22
> systemd-private-e0701fd845894b6087a236a976c00b35-chronyd.service-2z3OOv
> getInputStream: org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> Exception in thread "main" java.io.IOException: Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389){quote}
> It looks the input stream is closed.
> is it possible not to throw an exception to rely on java.io.InputStream ?
> 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] [Work logged] (SSHD-1303) Keeping error streams and input streams separate after ChannelExec#setRedirectErrorStream(true) is called
[
https://issues.apache.org/jira/browse/SSHD-1303?focusedWorklogId=819090=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-819090
]
ASF GitHub Bot logged work on SSHD-1303:
Author: ASF GitHub Bot
Created on: 21/Oct/22 10:54
Start Date: 21/Oct/22 10:54
Worklog Time Spent: 10m
Work Description: tomaswolf merged PR #255:
URL: https://github.com/apache/mina-sshd/pull/255
Issue Time Tracking
---
Worklog Id: (was: 819090)
Time Spent: 50m (was: 40m)
> Keeping error streams and input streams separate after
> ChannelExec#setRedirectErrorStream(true) is called
> -
>
> Key: SSHD-1303
> URL: https://issues.apache.org/jira/browse/SSHD-1303
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Assignee: Thomas Wolf
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Hello!
> As I understand, if I call {_}ChannelExec#setRedirectErrorStream(true){_},
> then _ChannelExec#getInvertedErr()_ and _ChannelExec#getInvertedOut()_ return
> the same input stream.
> If I redirect error stream and read the error stream before the input stream,
> then the error stream returns the message even if there is an error or not,
> which is not expected.
> Here is the test case
> {code:java}
> BufferedReader input;
> String line;
>
> //process.getErrorStream() gets its value from
> ChannelExec#getInvertedErr()
> System.out.println("getErrorStream: " + process.getErrorStream());
> input = new BufferedReader(new
> InputStreamReader(process.getErrorStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> //process.getInputStream() gets its value from
> ChannelExec#getInvertedOut()
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> {code}
> Here is an output excerpt:
> {quote}getErrorStream:
> org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> total 0
> drwx--. 3 root root 17 Oct 17 10:31
> systemd-private-c3ce924f90c24e4a86f637831f434fe3-chronyd.service-DwM2fR
> drwx--. 3 root root 17 Oct 14 13:22
> systemd-private-e0701fd845894b6087a236a976c00b35-chronyd.service-2z3OOv
> getInputStream: org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> Exception in thread "main" java.io.IOException: Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389)
> {quote}
> As seen above, _ls_ command output comes from the error stream even if the
> error redirection is set to _true_ and command runs {_}successfully{_}.
> The second problem is an exception problem. It is independent from the error
> stream redirection. I have openned SSHD-1302 for this.
> Requests:
> - Is it possible to make ChannelExec#getInvertedErr() and
> ChannelExec#getInvertedOut() two separate input streams ?
> - Is it possible to rely on java.lang.ProcessBuilder, so that the stream
> returned from error stream will always be a _null input stream_ as below from
> Java 8 source code:
> static class NullInputStream extends InputStream {
> static final NullInputStream INSTANCE = new NullInputStream();
> private NullInputStream() {}
> public int read() \{ return -1; }
> public int available()
> { return 0; }
> }
> 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] [Work logged] (SSHD-1303) Keeping error streams and input streams separate after ChannelExec#setRedirectErrorStream(true) is called
[
https://issues.apache.org/jira/browse/SSHD-1303?focusedWorklogId=819080=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-819080
]
ASF GitHub Bot logged work on SSHD-1303:
Author: ASF GitHub Bot
Created on: 21/Oct/22 10:18
Start Date: 21/Oct/22 10:18
Worklog Time Spent: 10m
Work Description: lgoldstein commented on PR #255:
URL: https://github.com/apache/mina-sshd/pull/255#issuecomment-1286753864
>> Then let's delay doing so to that future until a second concrete use case
for this comes up
My personal philosophy is that if something is relatively simple, generic
enough to be useful then why not make it public.
>> YAGNI
I agree in principle, though it has been my experience that usually you
**are** going to need it.
That being said, I have no issue with leaving this code as-is - like I said,
I **recommend** it, but do not insist on it...
Issue Time Tracking
---
Worklog Id: (was: 819080)
Time Spent: 40m (was: 0.5h)
> Keeping error streams and input streams separate after
> ChannelExec#setRedirectErrorStream(true) is called
> -
>
> Key: SSHD-1303
> URL: https://issues.apache.org/jira/browse/SSHD-1303
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Assignee: Thomas Wolf
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Hello!
> As I understand, if I call {_}ChannelExec#setRedirectErrorStream(true){_},
> then _ChannelExec#getInvertedErr()_ and _ChannelExec#getInvertedOut()_ return
> the same input stream.
> If I redirect error stream and read the error stream before the input stream,
> then the error stream returns the message even if there is an error or not,
> which is not expected.
> Here is the test case
> {code:java}
> BufferedReader input;
> String line;
>
> //process.getErrorStream() gets its value from
> ChannelExec#getInvertedErr()
> System.out.println("getErrorStream: " + process.getErrorStream());
> input = new BufferedReader(new
> InputStreamReader(process.getErrorStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> //process.getInputStream() gets its value from
> ChannelExec#getInvertedOut()
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> {code}
> Here is an output excerpt:
> {quote}getErrorStream:
> org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> total 0
> drwx--. 3 root root 17 Oct 17 10:31
> systemd-private-c3ce924f90c24e4a86f637831f434fe3-chronyd.service-DwM2fR
> drwx--. 3 root root 17 Oct 14 13:22
> systemd-private-e0701fd845894b6087a236a976c00b35-chronyd.service-2z3OOv
> getInputStream: org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> Exception in thread "main" java.io.IOException: Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389)
> {quote}
> As seen above, _ls_ command output comes from the error stream even if the
> error redirection is set to _true_ and command runs {_}successfully{_}.
> The second problem is an exception problem. It is independent from the error
> stream redirection. I have openned SSHD-1302 for this.
> Requests:
> - Is it possible to make ChannelExec#getInvertedErr() and
> ChannelExec#getInvertedOut() two separate input streams ?
> - Is it possible to rely on java.lang.ProcessBuilder, so that the stream
> returned from error stream will always be a _null input stream_ as below from
> Java 8 source code:
> static class NullInputStream extends InputStream {
> static final NullInputStream INSTANCE = new NullInputStream();
> private NullInputStream() {}
> public int read() \{ return -1; }
> public int available()
> { return 0; }
> }
> Thanks in advance...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (SSHD-1303) Keeping error streams and input streams separate after ChannelExec#setRedirectErrorStream(true) is called
[
https://issues.apache.org/jira/browse/SSHD-1303?focusedWorklogId=819026=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-819026
]
ASF GitHub Bot logged work on SSHD-1303:
Author: ASF GitHub Bot
Created on: 21/Oct/22 06:50
Start Date: 21/Oct/22 06:50
Worklog Time Spent: 10m
Work Description: tomaswolf commented on code in PR #255:
URL: https://github.com/apache/mina-sshd/pull/255#discussion_r1001428599
##
sshd-core/src/main/java/org/apache/sshd/client/channel/AbstractClientChannel.java:
##
@@ -474,4 +494,48 @@ public Integer getExitStatus() {
public String getExitSignal() {
return exitSignalHolder.get();
}
+
+private enum NullIoInputStream implements IoInputStream {
Review Comment:
Then let's delay doing so to that future until a _second_ concrete use case
for this comes up. [YAGNI](https://martinfowler.com/bliki/Yagni.html). Which
basically means "implement features when they're actually needed, not when you
think they _might_ be needed."
Issue Time Tracking
---
Worklog Id: (was: 819026)
Time Spent: 0.5h (was: 20m)
> Keeping error streams and input streams separate after
> ChannelExec#setRedirectErrorStream(true) is called
> -
>
> Key: SSHD-1303
> URL: https://issues.apache.org/jira/browse/SSHD-1303
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Assignee: Thomas Wolf
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Hello!
> As I understand, if I call {_}ChannelExec#setRedirectErrorStream(true){_},
> then _ChannelExec#getInvertedErr()_ and _ChannelExec#getInvertedOut()_ return
> the same input stream.
> If I redirect error stream and read the error stream before the input stream,
> then the error stream returns the message even if there is an error or not,
> which is not expected.
> Here is the test case
> {code:java}
> BufferedReader input;
> String line;
>
> //process.getErrorStream() gets its value from
> ChannelExec#getInvertedErr()
> System.out.println("getErrorStream: " + process.getErrorStream());
> input = new BufferedReader(new
> InputStreamReader(process.getErrorStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> //process.getInputStream() gets its value from
> ChannelExec#getInvertedOut()
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> {code}
> Here is an output excerpt:
> {quote}getErrorStream:
> org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> total 0
> drwx--. 3 root root 17 Oct 17 10:31
> systemd-private-c3ce924f90c24e4a86f637831f434fe3-chronyd.service-DwM2fR
> drwx--. 3 root root 17 Oct 14 13:22
> systemd-private-e0701fd845894b6087a236a976c00b35-chronyd.service-2z3OOv
> getInputStream: org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> Exception in thread "main" java.io.IOException: Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389)
> {quote}
> As seen above, _ls_ command output comes from the error stream even if the
> error redirection is set to _true_ and command runs {_}successfully{_}.
> The second problem is an exception problem. It is independent from the error
> stream redirection. I have openned SSHD-1302 for this.
> Requests:
> - Is it possible to make ChannelExec#getInvertedErr() and
> ChannelExec#getInvertedOut() two separate input streams ?
> - Is it possible to rely on java.lang.ProcessBuilder, so that the stream
> returned from error stream will always be a _null input stream_ as below from
> Java 8 source code:
> static class NullInputStream extends InputStream {
> static final NullInputStream INSTANCE = new NullInputStream();
> private NullInputStream() {}
> public int read() \{ return -1; }
> public int available()
>
[jira] [Work logged] (SSHD-1303) Keeping error streams and input streams separate after ChannelExec#setRedirectErrorStream(true) is called
[
https://issues.apache.org/jira/browse/SSHD-1303?focusedWorklogId=818962=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-818962
]
ASF GitHub Bot logged work on SSHD-1303:
Author: ASF GitHub Bot
Created on: 20/Oct/22 23:41
Start Date: 20/Oct/22 23:41
Worklog Time Spent: 10m
Work Description: lgoldstein commented on code in PR #255:
URL: https://github.com/apache/mina-sshd/pull/255#discussion_r1001218334
##
sshd-core/src/main/java/org/apache/sshd/client/channel/AbstractClientChannel.java:
##
@@ -474,4 +494,48 @@ public Integer getExitStatus() {
public String getExitSignal() {
return exitSignalHolder.get();
}
+
+private enum NullIoInputStream implements IoInputStream {
Review Comment:
Recommend making this a *public* class in same package as `IoInputStream`
or a member of it. Might come useful in the future.
Issue Time Tracking
---
Worklog Id: (was: 818962)
Time Spent: 20m (was: 10m)
> Keeping error streams and input streams separate after
> ChannelExec#setRedirectErrorStream(true) is called
> -
>
> Key: SSHD-1303
> URL: https://issues.apache.org/jira/browse/SSHD-1303
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Assignee: Thomas Wolf
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hello!
> As I understand, if I call {_}ChannelExec#setRedirectErrorStream(true){_},
> then _ChannelExec#getInvertedErr()_ and _ChannelExec#getInvertedOut()_ return
> the same input stream.
> If I redirect error stream and read the error stream before the input stream,
> then the error stream returns the message even if there is an error or not,
> which is not expected.
> Here is the test case
> {code:java}
> BufferedReader input;
> String line;
>
> //process.getErrorStream() gets its value from
> ChannelExec#getInvertedErr()
> System.out.println("getErrorStream: " + process.getErrorStream());
> input = new BufferedReader(new
> InputStreamReader(process.getErrorStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> //process.getInputStream() gets its value from
> ChannelExec#getInvertedOut()
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> {code}
> Here is an output excerpt:
> {quote}getErrorStream:
> org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> total 0
> drwx--. 3 root root 17 Oct 17 10:31
> systemd-private-c3ce924f90c24e4a86f637831f434fe3-chronyd.service-DwM2fR
> drwx--. 3 root root 17 Oct 14 13:22
> systemd-private-e0701fd845894b6087a236a976c00b35-chronyd.service-2z3OOv
> getInputStream: org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> Exception in thread "main" java.io.IOException: Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389)
> {quote}
> As seen above, _ls_ command output comes from the error stream even if the
> error redirection is set to _true_ and command runs {_}successfully{_}.
> The second problem is an exception problem. It is independent from the error
> stream redirection. I have openned SSHD-1302 for this.
> Requests:
> - Is it possible to make ChannelExec#getInvertedErr() and
> ChannelExec#getInvertedOut() two separate input streams ?
> - Is it possible to rely on java.lang.ProcessBuilder, so that the stream
> returned from error stream will always be a _null input stream_ as below from
> Java 8 source code:
> static class NullInputStream extends InputStream {
> static final NullInputStream INSTANCE = new NullInputStream();
> private NullInputStream() {}
> public int read() \{ return -1; }
> public int available()
> { return 0; }
> }
> Thanks in advance...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (SSHD-1303) Keeping error streams and input streams separate after ChannelExec#setRedirectErrorStream(true) is called
[
https://issues.apache.org/jira/browse/SSHD-1303?focusedWorklogId=818906=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-818906
]
ASF GitHub Bot logged work on SSHD-1303:
Author: ASF GitHub Bot
Created on: 20/Oct/22 19:06
Start Date: 20/Oct/22 19:06
Worklog Time Spent: 10m
Work Description: tomaswolf opened a new pull request, #255:
URL: https://github.com/apache/mina-sshd/pull/255
If a channel's error stream has been redirected to the output stream, return
null streams from getAsyncErr() and getInvertedErr(). Since they are
redirected, application code should never see any data on them.
Also document the IoReadFuture better, and change the single implementation
of that interface to match. While the future is not done, operations return
null or zero. EOF is signaled by getRead() == -1, or getException() returning
an EOFException.
Issue Time Tracking
---
Worklog Id: (was: 818906)
Remaining Estimate: 0h
Time Spent: 10m
> Keeping error streams and input streams separate after
> ChannelExec#setRedirectErrorStream(true) is called
> -
>
> Key: SSHD-1303
> URL: https://issues.apache.org/jira/browse/SSHD-1303
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello!
> As I understand, if I call {_}ChannelExec#setRedirectErrorStream(true){_},
> then _ChannelExec#getInvertedErr()_ and _ChannelExec#getInvertedOut()_ return
> the same input stream.
> If I redirect error stream and read the error stream before the input stream,
> then the error stream returns the message even if there is an error or not,
> which is not expected.
> Here is the test case
> {code:java}
> BufferedReader input;
> String line;
>
> //process.getErrorStream() gets its value from
> ChannelExec#getInvertedErr()
> System.out.println("getErrorStream: " + process.getErrorStream());
> input = new BufferedReader(new
> InputStreamReader(process.getErrorStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> //process.getInputStream() gets its value from
> ChannelExec#getInvertedOut()
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> {code}
> Here is an output excerpt:
> {quote}getErrorStream:
> org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> total 0
> drwx--. 3 root root 17 Oct 17 10:31
> systemd-private-c3ce924f90c24e4a86f637831f434fe3-chronyd.service-DwM2fR
> drwx--. 3 root root 17 Oct 14 13:22
> systemd-private-e0701fd845894b6087a236a976c00b35-chronyd.service-2z3OOv
> getInputStream: org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> Exception in thread "main" java.io.IOException: Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389)
> {quote}
> As seen above, _ls_ command output comes from the error stream even if the
> error redirection is set to _true_ and command runs {_}successfully{_}.
> The second problem is an exception problem. It is independent from the error
> stream redirection. I have openned SSHD-1302 for this.
> Requests:
> - Is it possible to make ChannelExec#getInvertedErr() and
> ChannelExec#getInvertedOut() two separate input streams ?
> - Is it possible to rely on java.lang.ProcessBuilder, so that the stream
> returned from error stream will always be a _null input stream_ as below from
> Java 8 source code:
> static class NullInputStream extends InputStream {
> static final NullInputStream INSTANCE = new NullInputStream();
> private NullInputStream() {}
> public int read() \{ return -1; }
> public int available()
> { return 0; }
> }
> Thanks in advance...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (SSHD-1173) SFTP worker threads got stuck while processing PUT methods against one specific SFTP server
[
https://issues.apache.org/jira/browse/SSHD-1173?focusedWorklogId=816436=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816436
]
ASF GitHub Bot logged work on SSHD-1173:
Author: ASF GitHub Bot
Created on: 13/Oct/22 05:48
Start Date: 13/Oct/22 05:48
Worklog Time Spent: 10m
Work Description: tomaswolf merged PR #251:
URL: https://github.com/apache/mina-sshd/pull/251
Issue Time Tracking
---
Worklog Id: (was: 816436)
Time Spent: 20m (was: 10m)
> SFTP worker threads got stuck while processing PUT methods against one
> specific SFTP server
> ---
>
> Key: SSHD-1173
> URL: https://issues.apache.org/jira/browse/SSHD-1173
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Assignee: Thomas Wolf
>Priority: Critical
> Labels: SFTP, mina, sshd
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hey guys,
> Recently I've encountered one remote SFTP server, that causes SFTP worker
> threads to enter TIMED_WAITING state, from which they do not recover. Please,
> take a look into this thread dump:
> {code:java}
> SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
> tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
> elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
> monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting
> on at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
> - waiting to re-lock in wait() <0x0006e3bbc420> (a
> org.apache.sshd.common.channel.IoWriteFutureImpl) at
> org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
> at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
> at
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.write(SftpOutputStreamAsync.java:141)
> at java.io.InputStream.transferTo(java.base@11.0.10/InputStream.java:705) at
> com.mina.command.Put.replyInto(Put.java:55) at
> com.sftpserver.MinaSftpHandler.channelReadInternal(MinaSftpHandler.java:251)
> at
> com.sftpserver.MinaSftpHandler.lambda$channelRead$0(MinaSftpHandler.java:125)
> at com.sftpserver.MinaSftpHandler$$Lambda$392/0x000800764040.run(Unknown
> Source) at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.10/Executors.java:515)
> at
> java.util.concurrent.FutureTask.run(java.base@11.0.10/FutureTask.java:264) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
> {code}
> Seems like the thread is waiting for lock in
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java),
> I'm currently not sure what thread holds the lock and why it's not ever
> released.
> Also, I'm not able to reproduce this, but it constantly happens to all the
> PUT methods targeting one specific remote server (which I don't own), so I
> suppose there would be something odd with the remote server, but it doesn't
> mean, that we shouldn't be able to deal with that.
> Have you ever seen such behavior? Could it be Mina sshd's bug? (seems like
> verify() in
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> is called without any timeout, which then defaults to LONG.MAX here: at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43),
> shouldn't we have configurable timeout here? or what's the point of default
> timeout? what are we really waiting for in at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)?)
--
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] [Work logged] (SSHD-1173) SFTP worker threads got stuck while processing PUT methods against one specific SFTP server
[
https://issues.apache.org/jira/browse/SSHD-1173?focusedWorklogId=814732=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-814732
]
ASF GitHub Bot logged work on SSHD-1173:
Author: ASF GitHub Bot
Created on: 07/Oct/22 16:20
Start Date: 07/Oct/22 16:20
Worklog Time Spent: 10m
Work Description: tomaswolf opened a new pull request, #251:
URL: https://github.com/apache/mina-sshd/pull/251
Remove the option not to send a chunk when the remote window is smaller than
the packet size, and we're trying to write more than the remote widow size
bytes. This option may lead to hangs with peers that wait with sending their
window adjustment until the window size is very low, or even zero.
RFC 4254 does not mandate any particular point at which an SSH
implementation should send a window adjustment. Implementations doing so only
once the window has been fully consumed are well within the bounds of the
specification.
Therefore remove this option altogether, and always send some data if the
window size is > 0. Refactor the writePacket() method to make it much simpler
and clearer.
Client options removed:
* SftpModuleProperties.CHUNK_IF_WINDOW_LESS_THAN_PACKET
* CoreModuleProperties.ASYNC_SERVER_STDOUT_CHUNK_BELOW_WINDOW_SIZE
* CoreModuleProperties.ASYNC_SERVER_STDERR_CHUNK_BELOW_WINDOW_SIZE
* ChannelAsyncOutputStream(Channel, byte, boolean) constructor
These options were by default all false, potentially leading to hangs as
described above. Already [SSHD-1123] had pointed out that problem, and bug
[SSHD-1207] might also be caused by this. The feature was introduced in
[SSHD-979] in commit e85b67e0 and later modified in commit 536d0663.
Issue Time Tracking
---
Worklog Id: (was: 814732)
Remaining Estimate: 0h
Time Spent: 10m
> SFTP worker threads got stuck while processing PUT methods against one
> specific SFTP server
> ---
>
> Key: SSHD-1173
> URL: https://issues.apache.org/jira/browse/SSHD-1173
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Priority: Critical
> Labels: SFTP, mina, sshd
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hey guys,
> Recently I've encountered one remote SFTP server, that causes SFTP worker
> threads to enter TIMED_WAITING state, from which they do not recover. Please,
> take a look into this thread dump:
> {code:java}
> SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
> tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
> elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
> monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting
> on at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
> - waiting to re-lock in wait() <0x0006e3bbc420> (a
> org.apache.sshd.common.channel.IoWriteFutureImpl) at
> org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
> at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
> at
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.write(SftpOutputStreamAsync.java:141)
> at java.io.InputStream.transferTo(java.base@11.0.10/InputStream.java:705) at
> com.mina.command.Put.replyInto(Put.java:55) at
> com.sftpserver.MinaSftpHandler.channelReadInternal(MinaSftpHandler.java:251)
> at
> com.sftpserver.MinaSftpHandler.lambda$channelRead$0(MinaSftpHandler.java:125)
> at com.sftpserver.MinaSftpHandler$$Lambda$392/0x000800764040.run(Unknown
> Source) at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.10/Executors.java:515)
> at
> java.util.concurrent.FutureTask.run(java.base@11.0.10/FutureTask.java:264) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
> {code}
> Seems like the thread is waiting for lock in
>
[jira] [Work logged] (DIRMINA-1169) BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
[
https://issues.apache.org/jira/browse/DIRMINA-1169?focusedWorklogId=813939=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-813939
]
ASF GitHub Bot logged work on DIRMINA-1169:
---
Author: ASF GitHub Bot
Created on: 05/Oct/22 19:55
Start Date: 05/Oct/22 19:55
Worklog Time Spent: 10m
Work Description: tomaswolf commented on PR #35:
URL: https://github.com/apache/mina/pull/35#issuecomment-1264660539
@elecharny could you please take look and merge this if you think it's OK?
And then merge or cherry-pick it to the 2.1.X and 2.2.X branches? I'm a bit
confused by the git history of this repo, and it's not clear to me how you
manage back-ports or fixes in old versions, otherwise I might be able to do so
myself. The three 2.* branches seem to be completely separate. That's not what
I'm used to from EGit or JGit, where after a fix on an old maintenance branch
we merge the change up to the current master/main branch.
Having a 2.0.24 including the fix would also be useful. Currently we have
disabled one test in Apache MINA sshd because of this problem.
Issue Time Tracking
---
Worklog Id: (was: 813939)
Time Spent: 0.5h (was: 20m)
> BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
> --
>
> Key: DIRMINA-1169
> URL: https://issues.apache.org/jira/browse/DIRMINA-1169
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.23, 2.1.6, 2.2.1
>Reporter: Thomas Wolf
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> See also SSHD-1256.
> The main acceptor loop does basically (somewhat simplified):
> {code:java}
> while (selectable) {
> registerHandles(); // Process registration queue: add new sockets (from
> bind()) to the selector with OP_ACCEPT, fulfills their open futures
> int selected = select();
> if (/* nothing to do */) {
> break; // and end the thread; higher layers will create a new one if
> needed
> }
> if (selected > 0) {
> processHandles(selectedHandles()); // Handle and hand off new connections
> }
> unregisterHandles(); // Process cancel queue: cancel SelectionKey, close
> ServerSocketChannel, fulfill the cancel future
> }
> {code}
> With Java 11, unbinding a {{ServerSocketChannel}} changed:
> * [JDK-8214430|https://bugs.openjdk.org/browse/JDK-8214430]
> * [Java 11 Release
> Notes|https://www.oracle.com/java/technologies/javase/11-relnote-issues.html#JDK-8198562]
> Essentially the unbind gives up the socket only at the next {{select()}}
> call. This causes two problems in Apache MINA's acceptor:
> * The unbind future is set "done" before the socket is actually released.
> * If a new binding for one of the unbound sockets is registered before that
> {{select()}} has been done, {{registerHandles()}} gets a {{BindException}}
> ("address already in use").
> So for Java >= 11, the code must ensure that there is a {{select()}} between
> processing unbindings and processing new bindings, and the unbind futures
> must be set "done" only after that {{select()}}.
--
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] [Work logged] (DIRMINA-1169) BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
[
https://issues.apache.org/jira/browse/DIRMINA-1169?focusedWorklogId=811922=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-811922
]
ASF GitHub Bot logged work on DIRMINA-1169:
---
Author: ASF GitHub Bot
Created on: 25/Sep/22 13:50
Start Date: 25/Sep/22 13:50
Worklog Time Spent: 10m
Work Description: chrjohn commented on PR #35:
URL: https://github.com/apache/mina/pull/35#issuecomment-1257198626
Would be good if this could also be merged to 2.2.x then. It causes
intermittent failures in our test suite (QuickFIX/J)
Issue Time Tracking
---
Worklog Id: (was: 811922)
Time Spent: 20m (was: 10m)
> BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
> --
>
> Key: DIRMINA-1169
> URL: https://issues.apache.org/jira/browse/DIRMINA-1169
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.23, 2.1.6, 2.2.1
>Reporter: Thomas Wolf
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See also SSHD-1256.
> The main acceptor loop does basically (somewhat simplified):
> {code:java}
> while (selectable) {
> registerHandles(); // Process registration queue: add new sockets (from
> bind()) to the selector with OP_ACCEPT, fulfills their open futures
> int selected = select();
> if (/* nothing to do */) {
> break; // and end the thread; higher layers will create a new one if
> needed
> }
> if (selected > 0) {
> processHandles(selectedHandles()); // Handle and hand off new connections
> }
> unregisterHandles(); // Process cancel queue: cancel SelectionKey, close
> ServerSocketChannel, fulfill the cancel future
> }
> {code}
> With Java 11, unbinding a {{ServerSocketChannel}} changed:
> * [JDK-8214430|https://bugs.openjdk.org/browse/JDK-8214430]
> * [Java 11 Release
> Notes|https://www.oracle.com/java/technologies/javase/11-relnote-issues.html#JDK-8198562]
> Essentially the unbind gives up the socket only at the next {{select()}}
> call. This causes two problems in Apache MINA's acceptor:
> * The unbind future is set "done" before the socket is actually released.
> * If a new binding for one of the unbound sockets is registered before that
> {{select()}} has been done, {{registerHandles()}} gets a {{BindException}}
> ("address already in use").
> So for Java >= 11, the code must ensure that there is a {{select()}} between
> processing unbindings and processing new bindings, and the unbind futures
> must be set "done" only after that {{select()}}.
--
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] [Work logged] (DIRMINA-1169) BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
[
https://issues.apache.org/jira/browse/DIRMINA-1169?focusedWorklogId=811920=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-811920
]
ASF GitHub Bot logged work on DIRMINA-1169:
---
Author: ASF GitHub Bot
Created on: 25/Sep/22 13:15
Start Date: 25/Sep/22 13:15
Worklog Time Spent: 10m
Work Description: tomaswolf opened a new pull request, #35:
URL: https://github.com/apache/mina/pull/35
Since Java 11, closing a ServerSocketChannel may release the socket
only on the next select() call. If we try to register a new binding for
an unbound socket before the next select, a BindException may be thrown.
Ensure that there is a select() call between unbinding some sockets and
binding new sockets. Mark the unbind futures as "done" only after that
intervening select().
Test plan:
- check out this PR
- replace NioSocketAcceptor by the 2.0.23 version
- run the SocketAcceptorTest on a JVM 11 (or newer). It should fail with a
BindException.
- git reset --hard
- run the SocketAcceptorTest on a JVM 11 (or newer) again. It should pass.
Note that if SocketAcceptorTest is run on a JVM 8, it will succeed in either
case.
Issue Time Tracking
---
Worklog Id: (was: 811920)
Remaining Estimate: 0h
Time Spent: 10m
> BindException on Java >= 11 due to race condition in AbstractPollingIoAcceptor
> --
>
> Key: DIRMINA-1169
> URL: https://issues.apache.org/jira/browse/DIRMINA-1169
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.23, 2.1.6, 2.2.1
>Reporter: Thomas Wolf
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See also SSHD-1256.
> The main acceptor loop does basically (somewhat simplified):
> {code:java}
> while (selectable) {
> registerHandles(); // Process registration queue: add new sockets (from
> bind()) to the selector with OP_ACCEPT, fulfills their open futures
> int selected = select();
> if (/* nothing to do */) {
> break; // and end the thread; higher layers will create a new one if
> needed
> }
> if (selected > 0) {
> processHandles(selectedHandles()); // Handle and hand off new connections
> }
> unregisterHandles(); // Process cancel queue: cancel SelectionKey, close
> ServerSocketChannel, fulfill the cancel future
> }
> {code}
> With Java 11, unbinding a {{ServerSocketChannel}} changed:
> * [JDK-8214430|https://bugs.openjdk.org/browse/JDK-8214430]
> * [Java 11 Release
> Notes|https://www.oracle.com/java/technologies/javase/11-relnote-issues.html#JDK-8198562]
> Essentially the unbind gives up the socket only at the next {{select()}}
> call. This causes two problems in Apache MINA's acceptor:
> * The unbind future is set "done" before the socket is actually released.
> * If a new binding for one of the unbound sockets is registered before that
> {{select()}} has been done, {{registerHandles()}} gets a {{BindException}}
> ("address already in use").
> So for Java >= 11, the code must ensure that there is a {{select()}} between
> processing unbindings and processing new bindings, and the unbind futures
> must be set "done" only after that {{select()}}.
--
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] [Work logged] (SSHD-1293) ExplicitPortForwardingTracker does not unbind auto-allocated one
[
https://issues.apache.org/jira/browse/SSHD-1293?focusedWorklogId=810369=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-810369
]
ASF GitHub Bot logged work on SSHD-1293:
Author: ASF GitHub Bot
Created on: 20/Sep/22 12:08
Start Date: 20/Sep/22 12:08
Worklog Time Spent: 10m
Work Description: tomaswolf merged PR #241:
URL: https://github.com/apache/mina-sshd/pull/241
Issue Time Tracking
---
Worklog Id: (was: 810369)
Time Spent: 1h 20m (was: 1h 10m)
> ExplicitPortForwardingTracker does not unbind auto-allocated one
>
>
> Key: SSHD-1293
> URL: https://issues.apache.org/jira/browse/SSHD-1293
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Jan Philipp
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> I have noticed that the de-allocation (unbind of a forwarding) initiated by
> {{org.apache.sshd.client.session.forward.ExplicitPortForwardingTracker}} in
> the {{close()}} method will not no close the actual forwarding. Said that,
> this leaves the connection and a file handler open.
> The actual main reason is that it uses
> \{{manager.stopLocalPortForwarding(this.getLocalAddress());}} which means it
> stops the tunnel identified the "local address" which is the same as provided
> by the user. If the user is using a local address with port {{0}} (which
> seems legit since the docs state this explicitly), the local address will be
> still something like {{0.0.0.0:0}} or maybe {{{}127.0.0.1:0{}}}, but only the
> "bound address" contains the actual dynamic auto-allocated port.
> If the user uses an explicit port, this would work.
> As a workaround, I have added after {{tracker.close()}} an explicit
> {{session.stopLocalPortForwarding(tracker.getBoundAddress())}}. I don't know
> if this would your final solution or this would be an issue in
> \{{DefaultForwarder#stopLocalPortForwarding}}.
>
> I'm using 2.8 right now; as far as I can see there are no changes in 2.9
> regarding this.
--
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] [Work logged] (SSHD-1293) ExplicitPortForwardingTracker does not unbind auto-allocated one
[
https://issues.apache.org/jira/browse/SSHD-1293?focusedWorklogId=810368=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-810368
]
ASF GitHub Bot logged work on SSHD-1293:
Author: ASF GitHub Bot
Created on: 20/Sep/22 12:07
Start Date: 20/Sep/22 12:07
Worklog Time Spent: 10m
Work Description: tomaswolf commented on PR #241:
URL: https://github.com/apache/mina-sshd/pull/241#issuecomment-1252260941
> I've seen there are some changes in the forwarding topic in the meanwhile.
Is it worth to check if there are other leaking situations maybe there? Or at
least checking the tests cover the actual invocations (as noted in my 2nd
comment here)?
Sure. There were some strange failures still in port forwarding in the
Github CI builds (not caused by your change). I cannot reproduce yet locally,
but it seems there are still a few problems with port forwarding. The [failures
I
saw](https://github.com/apache/mina-sshd/actions/runs/3078358458/jobs/4973967007)
are probably timing-related; the Github builds are much slower than on my
local machine.
There's also [this sporadic
failure](https://github.com/apache/mina-sshd/actions/runs/3078358458/jobs/4973882256),
which relates to SSHD-1256. That failure appears to reoccur only with the MINA
transport; don't know yet why unbinding doesn't work or is slow sometimes.
Any help in tracking down the causes of these failures would be greatly
appreciated!
Issue Time Tracking
---
Worklog Id: (was: 810368)
Time Spent: 1h 10m (was: 1h)
> ExplicitPortForwardingTracker does not unbind auto-allocated one
>
>
> Key: SSHD-1293
> URL: https://issues.apache.org/jira/browse/SSHD-1293
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Jan Philipp
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I have noticed that the de-allocation (unbind of a forwarding) initiated by
> {{org.apache.sshd.client.session.forward.ExplicitPortForwardingTracker}} in
> the {{close()}} method will not no close the actual forwarding. Said that,
> this leaves the connection and a file handler open.
> The actual main reason is that it uses
> \{{manager.stopLocalPortForwarding(this.getLocalAddress());}} which means it
> stops the tunnel identified the "local address" which is the same as provided
> by the user. If the user is using a local address with port {{0}} (which
> seems legit since the docs state this explicitly), the local address will be
> still something like {{0.0.0.0:0}} or maybe {{{}127.0.0.1:0{}}}, but only the
> "bound address" contains the actual dynamic auto-allocated port.
> If the user uses an explicit port, this would work.
> As a workaround, I have added after {{tracker.close()}} an explicit
> {{session.stopLocalPortForwarding(tracker.getBoundAddress())}}. I don't know
> if this would your final solution or this would be an issue in
> \{{DefaultForwarder#stopLocalPortForwarding}}.
>
> I'm using 2.8 right now; as far as I can see there are no changes in 2.9
> regarding this.
--
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] [Work logged] (SSHD-1293) ExplicitPortForwardingTracker does not unbind auto-allocated one
[
https://issues.apache.org/jira/browse/SSHD-1293?focusedWorklogId=810362=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-810362
]
ASF GitHub Bot logged work on SSHD-1293:
Author: ASF GitHub Bot
Created on: 20/Sep/22 11:47
Start Date: 20/Sep/22 11:47
Worklog Time Spent: 10m
Work Description: knalli commented on PR #241:
URL: https://github.com/apache/mina-sshd/pull/241#issuecomment-1252237200
Oh, alright
I've seen there are some changes in the forwarding topic in the meanwhile.
Is it worth to check if there are other leaking situations maybe there? Or at
least checking the tests cover the actual invocations (as noted in my 2nd
comment here)?
Issue Time Tracking
---
Worklog Id: (was: 810362)
Time Spent: 1h (was: 50m)
> ExplicitPortForwardingTracker does not unbind auto-allocated one
>
>
> Key: SSHD-1293
> URL: https://issues.apache.org/jira/browse/SSHD-1293
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Jan Philipp
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> I have noticed that the de-allocation (unbind of a forwarding) initiated by
> {{org.apache.sshd.client.session.forward.ExplicitPortForwardingTracker}} in
> the {{close()}} method will not no close the actual forwarding. Said that,
> this leaves the connection and a file handler open.
> The actual main reason is that it uses
> \{{manager.stopLocalPortForwarding(this.getLocalAddress());}} which means it
> stops the tunnel identified the "local address" which is the same as provided
> by the user. If the user is using a local address with port {{0}} (which
> seems legit since the docs state this explicitly), the local address will be
> still something like {{0.0.0.0:0}} or maybe {{{}127.0.0.1:0{}}}, but only the
> "bound address" contains the actual dynamic auto-allocated port.
> If the user uses an explicit port, this would work.
> As a workaround, I have added after {{tracker.close()}} an explicit
> {{session.stopLocalPortForwarding(tracker.getBoundAddress())}}. I don't know
> if this would your final solution or this would be an issue in
> \{{DefaultForwarder#stopLocalPortForwarding}}.
>
> I'm using 2.8 right now; as far as I can see there are no changes in 2.9
> regarding this.
--
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] [Work logged] (SSHD-1293) ExplicitPortForwardingTracker does not unbind auto-allocated one
[
https://issues.apache.org/jira/browse/SSHD-1293?focusedWorklogId=810360=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-810360
]
ASF GitHub Bot logged work on SSHD-1293:
Author: ASF GitHub Bot
Created on: 20/Sep/22 11:42
Start Date: 20/Sep/22 11:42
Worklog Time Spent: 10m
Work Description: tomaswolf commented on PR #241:
URL: https://github.com/apache/mina-sshd/pull/241#issuecomment-1252232948
> Oops.. I missed your comment. Squash & rebase done.
Guess you didn't notice that I had already done so. I just hadn't merged yet.
Issue Time Tracking
---
Worklog Id: (was: 810360)
Time Spent: 50m (was: 40m)
> ExplicitPortForwardingTracker does not unbind auto-allocated one
>
>
> Key: SSHD-1293
> URL: https://issues.apache.org/jira/browse/SSHD-1293
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Jan Philipp
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I have noticed that the de-allocation (unbind of a forwarding) initiated by
> {{org.apache.sshd.client.session.forward.ExplicitPortForwardingTracker}} in
> the {{close()}} method will not no close the actual forwarding. Said that,
> this leaves the connection and a file handler open.
> The actual main reason is that it uses
> \{{manager.stopLocalPortForwarding(this.getLocalAddress());}} which means it
> stops the tunnel identified the "local address" which is the same as provided
> by the user. If the user is using a local address with port {{0}} (which
> seems legit since the docs state this explicitly), the local address will be
> still something like {{0.0.0.0:0}} or maybe {{{}127.0.0.1:0{}}}, but only the
> "bound address" contains the actual dynamic auto-allocated port.
> If the user uses an explicit port, this would work.
> As a workaround, I have added after {{tracker.close()}} an explicit
> {{session.stopLocalPortForwarding(tracker.getBoundAddress())}}. I don't know
> if this would your final solution or this would be an issue in
> \{{DefaultForwarder#stopLocalPortForwarding}}.
>
> I'm using 2.8 right now; as far as I can see there are no changes in 2.9
> regarding this.
--
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] [Work logged] (SSHD-1293) ExplicitPortForwardingTracker does not unbind auto-allocated one
[
https://issues.apache.org/jira/browse/SSHD-1293?focusedWorklogId=810321=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-810321
]
ASF GitHub Bot logged work on SSHD-1293:
Author: ASF GitHub Bot
Created on: 20/Sep/22 10:01
Start Date: 20/Sep/22 10:01
Worklog Time Spent: 10m
Work Description: knalli commented on PR #241:
URL: https://github.com/apache/mina-sshd/pull/241#issuecomment-1252124075
Oops.. I missed your comment. Squash & rebase done.
Issue Time Tracking
---
Worklog Id: (was: 810321)
Time Spent: 40m (was: 0.5h)
> ExplicitPortForwardingTracker does not unbind auto-allocated one
>
>
> Key: SSHD-1293
> URL: https://issues.apache.org/jira/browse/SSHD-1293
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Jan Philipp
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I have noticed that the de-allocation (unbind of a forwarding) initiated by
> {{org.apache.sshd.client.session.forward.ExplicitPortForwardingTracker}} in
> the {{close()}} method will not no close the actual forwarding. Said that,
> this leaves the connection and a file handler open.
> The actual main reason is that it uses
> \{{manager.stopLocalPortForwarding(this.getLocalAddress());}} which means it
> stops the tunnel identified the "local address" which is the same as provided
> by the user. If the user is using a local address with port {{0}} (which
> seems legit since the docs state this explicitly), the local address will be
> still something like {{0.0.0.0:0}} or maybe {{{}127.0.0.1:0{}}}, but only the
> "bound address" contains the actual dynamic auto-allocated port.
> If the user uses an explicit port, this would work.
> As a workaround, I have added after {{tracker.close()}} an explicit
> {{session.stopLocalPortForwarding(tracker.getBoundAddress())}}. I don't know
> if this would your final solution or this would be an issue in
> \{{DefaultForwarder#stopLocalPortForwarding}}.
>
> I'm using 2.8 right now; as far as I can see there are no changes in 2.9
> regarding this.
--
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] [Work logged] (SSHD-822) Research intermittent failure in unit tests using various I/O service factories
[
https://issues.apache.org/jira/browse/SSHD-822?focusedWorklogId=809879=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-809879
]
ASF GitHub Bot logged work on SSHD-822:
---
Author: ASF GitHub Bot
Created on: 18/Sep/22 18:35
Start Date: 18/Sep/22 18:35
Worklog Time Spent: 10m
Work Description: tomaswolf merged PR #244:
URL: https://github.com/apache/mina-sshd/pull/244
Issue Time Tracking
---
Worklog Id: (was: 809879)
Time Spent: 1.5h (was: 1h 20m)
> Research intermittent failure in unit tests using various I/O service
> factories
> ---
>
> Key: SSHD-822
> URL: https://issues.apache.org/jira/browse/SSHD-822
> Project: MINA SSHD
> Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Lyor Goldstein
>Assignee: Thomas Wolf
>Priority: Major
> Labels: junit, scp, sftp, ssh, sshd, unit-test
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> See excluded tests in the various POM(s) as well as {{@Ignore}}-d individual
> tests
--
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] [Work logged] (SSHD-822) Research intermittent failure in unit tests using various I/O service factories
[
https://issues.apache.org/jira/browse/SSHD-822?focusedWorklogId=808619=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-808619
]
ASF GitHub Bot logged work on SSHD-822:
---
Author: ASF GitHub Bot
Created on: 14/Sep/22 10:17
Start Date: 14/Sep/22 10:17
Worklog Time Spent: 10m
Work Description: tomaswolf commented on PR #244:
URL: https://github.com/apache/mina-sshd/pull/244#issuecomment-1246549726
This looks OK now.
- The problem with `ClientDeadlockTest` was
[this](https://github.com/apache/mina-sshd/pull/244/commits/331018f822ccc072acdbcc5d103bfaff0a77ce37#diff-081006a0bb09ef97f2c22a6930fdda78ddfdbbc50cd44566cd254163488c66b8L263),
as explained in the commit message.
- `ClientTest.testClientDisconnect()` then also got a spurious failure; the
problem there was essentially
[this](https://github.com/apache/mina-sshd/pull/244/commits/ff247f539980bfe2231bddf7eaeb809f5c675002#diff-859aa84d4bf7ccdee8fabf7ec1c3b6f77574de417fd7cf308f3b54f0a4b5fe03R1422):
the client closed the session, and the `suspend()` call came when the session
was already closed and the `NettyIoSession.context` was already `null`. Fixed
by ensuring thread safety for accesses to the `ChannelHandlerContext`, and by
making the test invoke `suspend()` earlier.
Some of the test runs done for the PR also had failures of
`PortForwardingTest.testRemoteForwardingSecondTimeInSameSession()` when run
with MINA. The cause is unclear, and it seems to be a spuriously flaky test.
The test tries to re-use a previously bound port. Although SO_REUSEADDR is set,
there may be a timing issue. If there is, it would be in Java/NIO or even at
the OS socket level. Maybe if one tries to re-use a socket too quickly, it can
still fail.
I'd suggest to merge this PR as is, and if that port forwarding test starts
failing frequently, re-open SSHD-1256 and try to fix in a separate change.
Issue Time Tracking
---
Worklog Id: (was: 808619)
Time Spent: 1h 20m (was: 1h 10m)
> Research intermittent failure in unit tests using various I/O service
> factories
> ---
>
> Key: SSHD-822
> URL: https://issues.apache.org/jira/browse/SSHD-822
> Project: MINA SSHD
> Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Lyor Goldstein
>Assignee: Thomas Wolf
>Priority: Major
> Labels: junit, scp, sftp, ssh, sshd, unit-test
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> See excluded tests in the various POM(s) as well as {{@Ignore}}-d individual
> tests
--
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] [Work logged] (SSHD-822) Research intermittent failure in unit tests using various I/O service factories
[
https://issues.apache.org/jira/browse/SSHD-822?focusedWorklogId=808322=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-808322
]
ASF GitHub Bot logged work on SSHD-822:
---
Author: ASF GitHub Bot
Created on: 13/Sep/22 14:45
Start Date: 13/Sep/22 14:45
Worklog Time Spent: 10m
Work Description: tomaswolf commented on PR #244:
URL: https://github.com/apache/mina-sshd/pull/244#issuecomment-1245521520
> Looks like the ClientDeadlockTest has a problem on Windows with Netty,
though.
Actually, it also fails here in GitHub CI on Ubuntu. Still cannot reproduce,
neither on Windows, OS X, nor CentOS. (Don't have any Ubuntu setup, but it's
unlikely to be an OS problem anyway.)
Tests do run here about three times slower than when I run them locally.
Possibly we have a race condition somewhere that somehow leads to that CLOSE
event never be reported. Perhaps some other exception that occurs and prevents
us from ever calling `closeFuture.setClosed()`.
But if I can't reproduce locally, I need to see the log output from the
test, and then hope it gives a clue as to what might be happening.
Issue Time Tracking
---
Worklog Id: (was: 808322)
Time Spent: 1h 10m (was: 1h)
> Research intermittent failure in unit tests using various I/O service
> factories
> ---
>
> Key: SSHD-822
> URL: https://issues.apache.org/jira/browse/SSHD-822
> Project: MINA SSHD
> Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Lyor Goldstein
>Assignee: Thomas Wolf
>Priority: Major
> Labels: junit, scp, sftp, ssh, sshd, unit-test
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> See excluded tests in the various POM(s) as well as {{@Ignore}}-d individual
> tests
--
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] [Work logged] (SSHD-1293) ExplicitPortForwardingTracker does not unbind auto-allocated one
[
https://issues.apache.org/jira/browse/SSHD-1293?focusedWorklogId=807562=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-807562
]
ASF GitHub Bot logged work on SSHD-1293:
Author: ASF GitHub Bot
Created on: 09/Sep/22 19:04
Start Date: 09/Sep/22 19:04
Worklog Time Spent: 10m
Work Description: tomaswolf commented on PR #241:
URL: https://github.com/apache/mina-sshd/pull/241#issuecomment-1242360255
Looks good. Please rebase and squash the commits, then we can merge this.
Issue Time Tracking
---
Worklog Id: (was: 807562)
Time Spent: 0.5h (was: 20m)
> ExplicitPortForwardingTracker does not unbind auto-allocated one
>
>
> Key: SSHD-1293
> URL: https://issues.apache.org/jira/browse/SSHD-1293
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Jan Philipp
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I have noticed that the de-allocation (unbind of a forwarding) initiated by
> {{org.apache.sshd.client.session.forward.ExplicitPortForwardingTracker}} in
> the {{close()}} method will not no close the actual forwarding. Said that,
> this leaves the connection and a file handler open.
> The actual main reason is that it uses
> \{{manager.stopLocalPortForwarding(this.getLocalAddress());}} which means it
> stops the tunnel identified the "local address" which is the same as provided
> by the user. If the user is using a local address with port {{0}} (which
> seems legit since the docs state this explicitly), the local address will be
> still something like {{0.0.0.0:0}} or maybe {{{}127.0.0.1:0{}}}, but only the
> "bound address" contains the actual dynamic auto-allocated port.
> If the user uses an explicit port, this would work.
> As a workaround, I have added after {{tracker.close()}} an explicit
> {{session.stopLocalPortForwarding(tracker.getBoundAddress())}}. I don't know
> if this would your final solution or this would be an issue in
> \{{DefaultForwarder#stopLocalPortForwarding}}.
>
> I'm using 2.8 right now; as far as I can see there are no changes in 2.9
> regarding this.
--
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] [Work logged] (SSHD-822) Research intermittent failure in unit tests using various I/O service factories
[
https://issues.apache.org/jira/browse/SSHD-822?focusedWorklogId=807473=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-807473
]
ASF GitHub Bot logged work on SSHD-822:
---
Author: ASF GitHub Bot
Created on: 09/Sep/22 15:28
Start Date: 09/Sep/22 15:28
Worklog Time Spent: 10m
Work Description: lgoldstein commented on code in PR #244:
URL: https://github.com/apache/mina-sshd/pull/244#discussion_r967206452
##
sshd-sftp/pom.xml:
##
@@ -150,7 +150,6 @@
org.apache.maven.plugins
maven-surefire-plugin
-${surefire.plugin.version}
Review Comment:
Got it...
Issue Time Tracking
---
Worklog Id: (was: 807473)
Time Spent: 1h (was: 50m)
> Research intermittent failure in unit tests using various I/O service
> factories
> ---
>
> Key: SSHD-822
> URL: https://issues.apache.org/jira/browse/SSHD-822
> Project: MINA SSHD
> Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Lyor Goldstein
>Assignee: Thomas Wolf
>Priority: Major
> Labels: junit, scp, sftp, ssh, sshd, unit-test
> Time Spent: 1h
> Remaining Estimate: 0h
>
> See excluded tests in the various POM(s) as well as {{@Ignore}}-d individual
> tests
--
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] [Work logged] (SSHD-822) Research intermittent failure in unit tests using various I/O service factories
[
https://issues.apache.org/jira/browse/SSHD-822?focusedWorklogId=807306=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-807306
]
ASF GitHub Bot logged work on SSHD-822:
---
Author: ASF GitHub Bot
Created on: 09/Sep/22 08:13
Start Date: 09/Sep/22 08:13
Worklog Time Spent: 10m
Work Description: tomaswolf commented on PR #244:
URL: https://github.com/apache/mina-sshd/pull/244#issuecomment-1241652073
Looks like the ClientDeadlockTest has a problem on Windows, though. I'll
have to investigate that before we can merge this.
Issue Time Tracking
---
Worklog Id: (was: 807306)
Time Spent: 50m (was: 40m)
> Research intermittent failure in unit tests using various I/O service
> factories
> ---
>
> Key: SSHD-822
> URL: https://issues.apache.org/jira/browse/SSHD-822
> Project: MINA SSHD
> Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Lyor Goldstein
>Assignee: Thomas Wolf
>Priority: Major
> Labels: junit, scp, sftp, ssh, sshd, unit-test
> Time Spent: 50m
> Remaining Estimate: 0h
>
> See excluded tests in the various POM(s) as well as {{@Ignore}}-d individual
> tests
--
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] [Work logged] (SSHD-822) Research intermittent failure in unit tests using various I/O service factories
[
https://issues.apache.org/jira/browse/SSHD-822?focusedWorklogId=807305=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-807305
]
ASF GitHub Bot logged work on SSHD-822:
---
Author: ASF GitHub Bot
Created on: 09/Sep/22 08:12
Start Date: 09/Sep/22 08:12
Worklog Time Spent: 10m
Work Description: tomaswolf commented on code in PR #244:
URL: https://github.com/apache/mina-sshd/pull/244#discussion_r966757372
##
sshd-sftp/pom.xml:
##
@@ -150,7 +150,6 @@
org.apache.maven.plugins
maven-surefire-plugin
-${surefire.plugin.version}
Review Comment:
The maven-surefire-plugin version is pinned to ${surefire.plugin.version} in
the pluginManagement> of the parent pom. It is therefore unnecessary and in
fact bad practice to define it again here.
Issue Time Tracking
---
Worklog Id: (was: 807305)
Time Spent: 40m (was: 0.5h)
> Research intermittent failure in unit tests using various I/O service
> factories
> ---
>
> Key: SSHD-822
> URL: https://issues.apache.org/jira/browse/SSHD-822
> Project: MINA SSHD
> Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Lyor Goldstein
>Assignee: Thomas Wolf
>Priority: Major
> Labels: junit, scp, sftp, ssh, sshd, unit-test
> Time Spent: 40m
> Remaining Estimate: 0h
>
> See excluded tests in the various POM(s) as well as {{@Ignore}}-d individual
> tests
--
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] [Work logged] (SSHD-822) Research intermittent failure in unit tests using various I/O service factories
[
https://issues.apache.org/jira/browse/SSHD-822?focusedWorklogId=807303=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-807303
]
ASF GitHub Bot logged work on SSHD-822:
---
Author: ASF GitHub Bot
Created on: 09/Sep/22 08:11
Start Date: 09/Sep/22 08:11
Worklog Time Spent: 10m
Work Description: tomaswolf commented on code in PR #244:
URL: https://github.com/apache/mina-sshd/pull/244#discussion_r966757372
##
sshd-sftp/pom.xml:
##
@@ -150,7 +150,6 @@
org.apache.maven.plugins
maven-surefire-plugin
-${surefire.plugin.version}
Review Comment:
The maven-surefire-plugin version is pinned to ${surefire.plugin.version} in
the parent of the parent pom. It is therefore unnecessary
and in fact bad practice to define it again here.
Issue Time Tracking
---
Worklog Id: (was: 807303)
Time Spent: 0.5h (was: 20m)
> Research intermittent failure in unit tests using various I/O service
> factories
> ---
>
> Key: SSHD-822
> URL: https://issues.apache.org/jira/browse/SSHD-822
> Project: MINA SSHD
> Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Lyor Goldstein
>Assignee: Thomas Wolf
>Priority: Major
> Labels: junit, scp, sftp, ssh, sshd, unit-test
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> See excluded tests in the various POM(s) as well as {{@Ignore}}-d individual
> tests
--
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] [Work logged] (SSHD-822) Research intermittent failure in unit tests using various I/O service factories
[
https://issues.apache.org/jira/browse/SSHD-822?focusedWorklogId=807281=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-807281
]
ASF GitHub Bot logged work on SSHD-822:
---
Author: ASF GitHub Bot
Created on: 09/Sep/22 07:22
Start Date: 09/Sep/22 07:22
Worklog Time Spent: 10m
Work Description: lgoldstein commented on code in PR #244:
URL: https://github.com/apache/mina-sshd/pull/244#discussion_r966711733
##
sshd-sftp/pom.xml:
##
@@ -150,7 +150,6 @@
org.apache.maven.plugins
maven-surefire-plugin
-${surefire.plugin.version}
Review Comment:
Why was it necessary to remove this ? If I remember correctly there are
quite a few artifacts that need to use this version version.
Issue Time Tracking
---
Worklog Id: (was: 807281)
Time Spent: 20m (was: 10m)
> Research intermittent failure in unit tests using various I/O service
> factories
> ---
>
> Key: SSHD-822
> URL: https://issues.apache.org/jira/browse/SSHD-822
> Project: MINA SSHD
> Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Lyor Goldstein
>Assignee: Thomas Wolf
>Priority: Major
> Labels: junit, scp, sftp, ssh, sshd, unit-test
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See excluded tests in the various POM(s) as well as {{@Ignore}}-d individual
> tests
--
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] [Work logged] (SSHD-822) Research intermittent failure in unit tests using various I/O service factories
[
https://issues.apache.org/jira/browse/SSHD-822?focusedWorklogId=807277=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-807277
]
ASF GitHub Bot logged work on SSHD-822:
---
Author: ASF GitHub Bot
Created on: 09/Sep/22 06:36
Start Date: 09/Sep/22 06:36
Worklog Time Spent: 10m
Work Description: tomaswolf opened a new pull request, #244:
URL: https://github.com/apache/mina-sshd/pull/244
This series of commits enables most tests for all I/O back-ends. For the
details, see the individual commit messages.
There are two new very minor features; see CHANGES.md.
Issue Time Tracking
---
Worklog Id: (was: 807277)
Remaining Estimate: 0h
Time Spent: 10m
> Research intermittent failure in unit tests using various I/O service
> factories
> ---
>
> Key: SSHD-822
> URL: https://issues.apache.org/jira/browse/SSHD-822
> Project: MINA SSHD
> Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Lyor Goldstein
>Priority: Major
> Labels: junit, scp, sftp, ssh, sshd, unit-test
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See excluded tests in the various POM(s) as well as {{@Ignore}}-d individual
> tests
--
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] [Work logged] (SSHD-1294) Default SshClient FD leak because Selector not closed
[ https://issues.apache.org/jira/browse/SSHD-1294?focusedWorklogId=807269=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-807269 ] ASF GitHub Bot logged work on SSHD-1294: Author: ASF GitHub Bot Created on: 09/Sep/22 06:12 Start Date: 09/Sep/22 06:12 Worklog Time Spent: 10m Work Description: tomaswolf merged PR #243: URL: https://github.com/apache/mina-sshd/pull/243 Issue Time Tracking --- Worklog Id: (was: 807269) Time Spent: 20m (was: 10m) > Default SshClient FD leak because Selector not closed > - > > Key: SSHD-1294 > URL: https://issues.apache.org/jira/browse/SSHD-1294 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: zhangbing >Assignee: Thomas Wolf >Priority: Major > Attachments: image-2022-09-07-09-52-41-327.png, > image-2022-09-07-10-06-03-182.png, image-2022-09-07-10-24-00-969.png, > image-2022-09-07-10-24-35-550.png, image-2022-09-07-10-25-14-435.png, > image-2022-09-07-10-30-41-233.png, image-2022-09-07-10-42-15-818.png, > image-2022-09-07-11-21-33-635.png > > Time Spent: 20m > Remaining Estimate: 0h > > The default SshClient SshClient.setUpDefaultClient() using > MinaServiceFactory.The NioProcessor is created and open the Selector. The > Selector.close() is called in doDispose(). > !image-2022-09-07-09-52-41-327.png! > !image-2022-09-07-10-06-03-182.png! > !image-2022-09-07-10-42-15-818.png! > When creating NioSocketConnector,the field createdProcessor is always false. > !image-2022-09-07-10-24-00-969.png! > !image-2022-09-07-10-24-35-550.png! > !image-2022-09-07-10-25-14-435.png! > Because createdProcessor is always false, processor.dispose() is never > executed. > !image-2022-09-07-10-30-41-233.png! > The dispose() in SimpleIoProcessorPool will not be executed. So，the dispose() > and doDisopose in NioProcessor is nerver executed. The Selector in > NioProcessor is not closed. > FD leak information with the losf command: > !image-2022-09-07-11-21-33-635.png! -- 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] [Work logged] (SSHD-1294) Default SshClient FD leak because Selector not closed
[ https://issues.apache.org/jira/browse/SSHD-1294?focusedWorklogId=807141=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-807141 ] ASF GitHub Bot logged work on SSHD-1294: Author: ASF GitHub Bot Created on: 08/Sep/22 18:32 Start Date: 08/Sep/22 18:32 Worklog Time Spent: 10m Work Description: tomaswolf opened a new pull request, #243: URL: https://github.com/apache/mina-sshd/pull/243 Ensure that the IoProcessor pool is disposed, otherwise a selector may not get closed, leading to a file handle leak. Issue Time Tracking --- Worklog Id: (was: 807141) Remaining Estimate: 0h Time Spent: 10m > Default SshClient FD leak because Selector not closed > - > > Key: SSHD-1294 > URL: https://issues.apache.org/jira/browse/SSHD-1294 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: zhangbing >Assignee: Thomas Wolf >Priority: Major > Attachments: image-2022-09-07-09-52-41-327.png, > image-2022-09-07-10-06-03-182.png, image-2022-09-07-10-24-00-969.png, > image-2022-09-07-10-24-35-550.png, image-2022-09-07-10-25-14-435.png, > image-2022-09-07-10-30-41-233.png, image-2022-09-07-10-42-15-818.png, > image-2022-09-07-11-21-33-635.png > > Time Spent: 10m > Remaining Estimate: 0h > > The default SshClient SshClient.setUpDefaultClient() using > MinaServiceFactory.The NioProcessor is created and open the Selector. The > Selector.close() is called in doDispose(). > !image-2022-09-07-09-52-41-327.png! > !image-2022-09-07-10-06-03-182.png! > !image-2022-09-07-10-42-15-818.png! > When creating NioSocketConnector,the field createdProcessor is always false. > !image-2022-09-07-10-24-00-969.png! > !image-2022-09-07-10-24-35-550.png! > !image-2022-09-07-10-25-14-435.png! > Because createdProcessor is always false, processor.dispose() is never > executed. > !image-2022-09-07-10-30-41-233.png! > The dispose() in SimpleIoProcessorPool will not be executed. So，the dispose() > and doDisopose in NioProcessor is nerver executed. The Selector in > NioProcessor is not closed. > FD leak information with the losf command: > !image-2022-09-07-11-21-33-635.png! -- 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] [Work logged] (SSHD-1293) ExplicitPortForwardingTracker does not unbind auto-allocated one
[
https://issues.apache.org/jira/browse/SSHD-1293?focusedWorklogId=805367=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-805367
]
ASF GitHub Bot logged work on SSHD-1293:
Author: ASF GitHub Bot
Created on: 31/Aug/22 21:03
Start Date: 31/Aug/22 21:03
Worklog Time Spent: 10m
Work Description: knalli commented on PR #241:
URL: https://github.com/apache/mina-sshd/pull/241#issuecomment-1233418548
Note: The existing test `testLocalForwardingNative` isn't covering this
(anymore) because the semaphore `tearDownSignal` is checked in the events (like
`tornDownExplicitTunnel`) only
Issue Time Tracking
---
Worklog Id: (was: 805367)
Time Spent: 20m (was: 10m)
> ExplicitPortForwardingTracker does not unbind auto-allocated one
>
>
> Key: SSHD-1293
> URL: https://issues.apache.org/jira/browse/SSHD-1293
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Jan Philipp
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I have noticed that the de-allocation (unbind of a forwarding) initiated by
> {{org.apache.sshd.client.session.forward.ExplicitPortForwardingTracker}} in
> the {{close()}} method will not no close the actual forwarding. Said that,
> this leaves the connection and a file handler open.
> The actual main reason is that it uses
> \{{manager.stopLocalPortForwarding(this.getLocalAddress());}} which means it
> stops the tunnel identified the "local address" which is the same as provided
> by the user. If the user is using a local address with port {{0}} (which
> seems legit since the docs state this explicitly), the local address will be
> still something like {{0.0.0.0:0}} or maybe {{{}127.0.0.1:0{}}}, but only the
> "bound address" contains the actual dynamic auto-allocated port.
> If the user uses an explicit port, this would work.
> As a workaround, I have added after {{tracker.close()}} an explicit
> {{session.stopLocalPortForwarding(tracker.getBoundAddress())}}. I don't know
> if this would your final solution or this would be an issue in
> \{{DefaultForwarder#stopLocalPortForwarding}}.
>
> I'm using 2.8 right now; as far as I can see there are no changes in 2.9
> regarding this.
--
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] [Work logged] (SSHD-1293) ExplicitPortForwardingTracker does not unbind auto-allocated one
[
https://issues.apache.org/jira/browse/SSHD-1293?focusedWorklogId=805365=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-805365
]
ASF GitHub Bot logged work on SSHD-1293:
Author: ASF GitHub Bot
Created on: 31/Aug/22 20:56
Start Date: 31/Aug/22 20:56
Worklog Time Spent: 10m
Work Description: knalli opened a new pull request, #241:
URL: https://github.com/apache/mina-sshd/pull/241
This fixes de-allocating / unbinding a local port forwarding binding when
using a dynamic auto-allocated port.
The information "localAddress" is controlled by the user and may contain
still a port `0` which means auto-allocating a local port; the actual local
port is available in 'boundAddress". However, "DefaultForwarder" tracks
the actual port mappings only.
I have run the tests locally with a Java 8 without issues.
Related issue https://issues.apache.org/jira/browse/SSHD-1293
I also added an additional commit modifying the test covering the missing
signal. If you are fine with this, I'd squash them. Or maybe as an additional
test?
Issue Time Tracking
---
Worklog Id: (was: 805365)
Remaining Estimate: 0h
Time Spent: 10m
> ExplicitPortForwardingTracker does not unbind auto-allocated one
>
>
> Key: SSHD-1293
> URL: https://issues.apache.org/jira/browse/SSHD-1293
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Jan Philipp
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have noticed that the de-allocation (unbind of a forwarding) initiated by
> {{org.apache.sshd.client.session.forward.ExplicitPortForwardingTracker}} in
> the {{close()}} method will not no close the actual forwarding. Said that,
> this leaves the connection and a file handler open.
> The actual main reason is that it uses
> \{{manager.stopLocalPortForwarding(this.getLocalAddress());}} which means it
> stops the tunnel identified the "local address" which is the same as provided
> by the user. If the user is using a local address with port {{0}} (which
> seems legit since the docs state this explicitly), the local address will be
> still something like {{0.0.0.0:0}} or maybe {{{}127.0.0.1:0{}}}, but only the
> "bound address" contains the actual dynamic auto-allocated port.
> If the user uses an explicit port, this would work.
> As a workaround, I have added after {{tracker.close()}} an explicit
> {{session.stopLocalPortForwarding(tracker.getBoundAddress())}}. I don't know
> if this would your final solution or this would be an issue in
> \{{DefaultForwarder#stopLocalPortForwarding}}.
>
> I'm using 2.8 right now; as far as I can see there are no changes in 2.9
> regarding this.
--
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] [Work logged] (SSHD-1290) Race condition is logged in ChannelAsyncOutputStream
[
https://issues.apache.org/jira/browse/SSHD-1290?focusedWorklogId=800422=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-800422
]
ASF GitHub Bot logged work on SSHD-1290:
Author: ASF GitHub Bot
Created on: 13/Aug/22 11:28
Start Date: 13/Aug/22 11:28
Worklog Time Spent: 10m
Work Description: tomaswolf merged PR #240:
URL: https://github.com/apache/mina-sshd/pull/240
Issue Time Tracking
---
Worklog Id: (was: 800422)
Time Spent: 20m (was: 10m)
> Race condition is logged in ChannelAsyncOutputStream
>
>
> Key: SSHD-1290
> URL: https://issues.apache.org/jira/browse/SSHD-1290
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: Evgeny Pasynkov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After upgrading to 2.9.0 I start receiving in logs records like
> {code}
> onWritten(ChannelAsyncOutputStream[[id=0,
> recipient=0]-SSHServerSessionEx[]] cmd=SSH_MSG_CHANNEL_DATA) future
> changed
> {code}
> Which looks suspicious to racy data structure updates
--
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] [Work logged] (SSHD-1290) Race condition is logged in ChannelAsyncOutputStream
[
https://issues.apache.org/jira/browse/SSHD-1290?focusedWorklogId=800419=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-800419
]
ASF GitHub Bot logged work on SSHD-1290:
Author: ASF GitHub Bot
Created on: 13/Aug/22 10:48
Start Date: 13/Aug/22 10:48
Worklog Time Spent: 10m
Work Description: tomaswolf opened a new pull request, #240:
URL: https://github.com/apache/mina-sshd/pull/240
More precise logging in onWritten() to distinguish the cases better.
Issue Time Tracking
---
Worklog Id: (was: 800419)
Remaining Estimate: 0h
Time Spent: 10m
> Race condition is logged in ChannelAsyncOutputStream
>
>
> Key: SSHD-1290
> URL: https://issues.apache.org/jira/browse/SSHD-1290
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: Evgeny Pasynkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After upgrading to 2.9.0 I start receiving in logs records like
> {code}
> onWritten(ChannelAsyncOutputStream[[id=0,
> recipient=0]-SSHServerSessionEx[]] cmd=SSH_MSG_CHANNEL_DATA) future
> changed
> {code}
> Which looks suspicious to racy data structure updates
--
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] [Work logged] (SSHD-1288) Infinite loop in org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#doRead
[
https://issues.apache.org/jira/browse/SSHD-1288?focusedWorklogId=800417=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-800417
]
ASF GitHub Bot logged work on SSHD-1288:
Author: ASF GitHub Bot
Created on: 13/Aug/22 10:04
Start Date: 13/Aug/22 10:04
Worklog Time Spent: 10m
Work Description: tomaswolf merged PR #239:
URL: https://github.com/apache/mina-sshd/pull/239
Issue Time Tracking
---
Worklog Id: (was: 800417)
Time Spent: 20m (was: 10m)
> Infinite loop in org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#doRead
> -
>
> Key: SSHD-1288
> URL: https://issues.apache.org/jira/browse/SSHD-1288
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Ivan Fiorentini
>Assignee: Thomas Wolf
>Priority: Major
> Attachments: image-2022-08-05-17-08-55-698.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I reported an infinite loop in
> org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#doRead:
> and after the production of a thread and system dump the point in execution
> was:
> {code:java}
> private long doRead(long max, BufferConsumer consumer) throws IOException {
> long orgOffset = clientOffset;
> while (max > 0) {
> if (hasNoData()) {
> if (eofIndicator) {
> break;
> }
> if (!pendingReads.isEmpty()) {
> fillData();
> }
> if (!eofIndicator) {
> sendRequests(); <- (do not send any request ! it does nothing
> !)
> }
> } else {
> int nb = (int) Math.min(max, buffer.available());
> consumer.consume(new ByteArrayBuffer(buffer.array(),
> buffer.rpos(), nb));
> buffer.rpos(buffer.rpos() + nb);
> clientOffset += nb;
> max -= nb;
> }
> }
> return clientOffset - orgOffset;
> }
> {code}
>
> In the system dump it seems the size of file to receive is obtained before
> to start the transfer... this size is 82.132.992 bytes; but during the
> receipt of the data it seems (at the time of the dump) that 82.156.760 was
> successfully received... *_this could happen if , during the file receipt, at
> the remote site the file is written (expanded) with more data._*
> ... but when the size of the received data is greater than the original it
> seems an infinite loop could happen in the
> org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#doRead when the
> sendRequests() is invoked to obtain more data (or receive the end of file);
> In the sendRequest():
> {code:java}
> while (pendingReads.size() < Math.max(1, windowSize / bufferSize)
>&& (fileSize <= 0 || requestOffset < fileSize + bufferSize)) {
>
>... do the send request to obtain more data (or to receive the end of
> file)
> requestOffset += bufferSize;
> }
> {code}
> ... the condition *requestOffset < fileSize + bufferSize*
> is not satisfied if the *requestOffset* >= *fileSize + bufferSize*
> preventing the code from sending a request to receive more data (and/or
> obtain the end of file) and causing the infinite loop.
> The values of the above variables at time of the dump was:
> !image-2022-08-05-17-08-55-698.png!
> ... so that "{*}(fileSize <= 0 || requestOffset < fileSize + bufferSize)"{*}
> is {color:#de350b}*FALSE*{color}
> To reproduce the problem:
> # create the remote file to receive (1Mb size)
> # create SftpClient sftp =
> DefaultSftpClientFactory.NSTANCE.createSftpClient(clientSession)
> # create InputStream is = sftp.read(file, 32768) end read the inputstrem 4kb
> at time
> # stop at the end of while loop block in
> org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#sendRequests
> when the requestOffset > fileSize
> # expand the remote file size to 2Mb
> # remove the stop at point 4 and continue
> # {color:#ffbdad}the code enter into an infinite loop{color}
--
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] [Work logged] (SSHD-1288) Infinite loop in org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#doRead
[
https://issues.apache.org/jira/browse/SSHD-1288?focusedWorklogId=800380=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-800380
]
ASF GitHub Bot logged work on SSHD-1288:
Author: ASF GitHub Bot
Created on: 12/Aug/22 20:58
Start Date: 12/Aug/22 20:58
Worklog Time Spent: 10m
Work Description: tomaswolf opened a new pull request, #239:
URL: https://github.com/apache/mina-sshd/pull/239
If data is appended while a file is read via SFTP, SftpInputStreamAsync
would enter an infinite loop if requestOffset >= fileSize + bufferSize.
Fix this and issue only sequential read requests once we detect that
we're beyond the expected EOF.
Issue Time Tracking
---
Worklog Id: (was: 800380)
Remaining Estimate: 0h
Time Spent: 10m
> Infinite loop in org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#doRead
> -
>
> Key: SSHD-1288
> URL: https://issues.apache.org/jira/browse/SSHD-1288
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Ivan Fiorentini
>Assignee: Thomas Wolf
>Priority: Major
> Attachments: image-2022-08-05-17-08-55-698.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I reported an infinite loop in
> org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#doRead:
> and after the production of a thread and system dump the point in execution
> was:
> {code:java}
> private long doRead(long max, BufferConsumer consumer) throws IOException {
> long orgOffset = clientOffset;
> while (max > 0) {
> if (hasNoData()) {
> if (eofIndicator) {
> break;
> }
> if (!pendingReads.isEmpty()) {
> fillData();
> }
> if (!eofIndicator) {
> sendRequests(); <- (do not send any request ! it does nothing
> !)
> }
> } else {
> int nb = (int) Math.min(max, buffer.available());
> consumer.consume(new ByteArrayBuffer(buffer.array(),
> buffer.rpos(), nb));
> buffer.rpos(buffer.rpos() + nb);
> clientOffset += nb;
> max -= nb;
> }
> }
> return clientOffset - orgOffset;
> }
> {code}
>
> In the system dump it seems the size of file to receive is obtained before
> to start the transfer... this size is 82.132.992 bytes; but during the
> receipt of the data it seems (at the time of the dump) that 82.156.760 was
> successfully received... *_this could happen if , during the file receipt, at
> the remote site the file is written (expanded) with more data._*
> ... but when the size of the received data is greater than the original it
> seems an infinite loop could happen in the
> org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#doRead when the
> sendRequests() is invoked to obtain more data (or receive the end of file);
> In the sendRequest():
> {code:java}
> while (pendingReads.size() < Math.max(1, windowSize / bufferSize)
>&& (fileSize <= 0 || requestOffset < fileSize + bufferSize)) {
>
>... do the send request to obtain more data (or to receive the end of
> file)
> requestOffset += bufferSize;
> }
> {code}
> ... the condition *requestOffset < fileSize + bufferSize*
> is not satisfied if the *requestOffset* >= *fileSize + bufferSize*
> preventing the code from sending a request to receive more data (and/or
> obtain the end of file) and causing the infinite loop.
> The values of the above variables at time of the dump was:
> !image-2022-08-05-17-08-55-698.png!
> ... so that "{*}(fileSize <= 0 || requestOffset < fileSize + bufferSize)"{*}
> is {color:#de350b}*FALSE*{color}
> To reproduce the problem:
> # create the remote file to receive (1Mb size)
> # create SftpClient sftp =
> DefaultSftpClientFactory.NSTANCE.createSftpClient(clientSession)
> # create InputStream is = sftp.read(file, 32768) end read the inputstrem 4kb
> at time
> # stop at the end of while loop block in
> org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#sendRequests
> when the requestOffset > fileSize
> # expand the remote file size to 2Mb
> # remove the stop at point 4 and continue
> # {color:#ffbdad}the code enter into an infinite loop{color}
--
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] [Work logged] (SSHD-1289) Deadlock during session exit
[
https://issues.apache.org/jira/browse/SSHD-1289?focusedWorklogId=800379=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-800379
]
ASF GitHub Bot logged work on SSHD-1289:
Author: ASF GitHub Bot
Created on: 12/Aug/22 20:53
Start Date: 12/Aug/22 20:53
Worklog Time Spent: 10m
Work Description: tomaswolf merged PR #238:
URL: https://github.com/apache/mina-sshd/pull/238
Issue Time Tracking
---
Worklog Id: (was: 800379)
Time Spent: 20m (was: 10m)
> Deadlock during session exit
>
>
> Key: SSHD-1289
> URL: https://issues.apache.org/jira/browse/SSHD-1289
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: Evgeny Pasynkov
>Assignee: Thomas Wolf
>Priority: Critical
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code}
>java.lang.Thread.State: WAITING
> at java.base@11.0.5/jdk.internal.misc.Unsafe.park(Native Method)
> - waiting on
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@c50d1b2
> at
> java.base@11.0.5/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
> at
> java.base@11.0.5/java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885)
> at
> java.base@11.0.5/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:917)
> at
> java.base@11.0.5/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1240)
> at
> java.base@11.0.5/java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:959)
> at
> org.apache.sshd.common.session.helpers.KeyExchangeMessageHandler.updateState(KeyExchangeMessageHandler.java:139)
> at
> org.apache.sshd.common.session.helpers.KeyExchangeMessageHandler.shutdown(KeyExchangeMessageHandler.java:186)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.preClose(AbstractSession.java:967)
> at
> org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:94)
> at
> org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.sessionClosed(AbstractSessionIoHandler.java:46)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.doCloseImmediately(Nio2Session.java:283)
> at
> org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:95)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.exceptionCaught(Nio2Session.java:215)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.writeBuffer(Nio2Session.java:186)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:1118)
> - locked java.lang.Object@3423f353
> at
> org.apache.sshd.common.session.helpers.KeyExchangeMessageHandler.writeOrEnqueue(KeyExchangeMessageHandler.java:285)
> at
> org.apache.sshd.common.session.helpers.KeyExchangeMessageHandler.writePacket(KeyExchangeMessageHandler.java:228)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.writePacket(AbstractSession.java:1039)
> at org.apache.sshd.common.session.Session.writePacket(Session.java:159)
> at org.apache.sshd.common.session.Session.writePacket(Session.java:145)
> at
> org.apache.sshd.common.channel.AbstractChannel$GracefulChannelCloseable.close(AbstractChannel.java:637)
> at
> org.apache.sshd.common.util.closeable.SequentialCloseable$1.operationComplete(SequentialCloseable.java:56)
> at
> org.apache.sshd.common.util.closeable.SequentialCloseable$1.operationComplete(SequentialCloseable.java:45)
> at
> org.apache.sshd.common.util.closeable.SequentialCloseable.doClose(SequentialCloseable.java:69)
> at
> org.apache.sshd.common.util.closeable.SimpleCloseable.close(SimpleCloseable.java:63)
> at
> org.apache.sshd.common.util.closeable.SequentialCloseable$1.operationComplete(SequentialCloseable.java:56)
> at
> org.apache.sshd.common.util.closeable.SequentialCloseable$1.operationComplete(SequentialCloseable.java:45)
> at
> org.apache.sshd.common.future.AbstractSshFuture.lambda$notifyListener$2(AbstractSshFuture.java:162)
> at
> org.apache.sshd.common.future.AbstractSshFuture$$Lambda$352/0x000800890040.call(Unknown
> Source)
> at
> org.apache.sshd.common.util.threads.ThreadUtils.runAsInternal(ThreadUtils.java:66)
> at
> org.apache.sshd.common.future.AbstractSshFuture.notifyListener(AbstractSshFuture.java:161)
> at
> org.apache.sshd.common.future.DefaultSshFuture.addListener(DefaultSshFuture.java:166)
> at
>
[jira] [Work logged] (SSHD-1289) Deadlock during session exit
[
https://issues.apache.org/jira/browse/SSHD-1289?focusedWorklogId=800119=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-800119
]
ASF GitHub Bot logged work on SSHD-1289:
Author: ASF GitHub Bot
Created on: 11/Aug/22 21:54
Start Date: 11/Aug/22 21:54
Worklog Time Spent: 10m
Work Description: tomaswolf opened a new pull request, #238:
URL: https://github.com/apache/mina-sshd/pull/238
Make sure that a thread does not try to acquire the write lock if
it already holds the read lock. This could happen if a write is not
enqueued and there is an exception during writing, and we then try
to close the session on the same thread.
The read/write lock is used for three purposes: first, it gives the
flushing thread trying to empty the queue of pending packets priority
over other threads trying to enqueue more packets, and second, it is
held during writeOrEnqueue() while writing a packet directly to prevent
that the KEX state changes between being checked and the write being
done, and third, to prevent that the KEX state changes asynchronously
while the flushing thread is checking it. The read/write lock itself
does not serve to ensure mutual exclusion on the KEX state itself.
These three functions can also be fulfilled if update() is executed
when only the read lock is held. If a thread in update() holds the read
lock, this can only occur if it wrote the buffer directly in
writeOrEnqueue(), in which case it is fine to proceed, and the flushing
thread for sure is not in its critical region where it holds the write
lock. Otherwise, any other thread either is the flushing thread and
holds the write lock already, or it's a thread not holding the lock at
all. In both cases it is fine to acquire the write lock.
Issue Time Tracking
---
Worklog Id: (was: 800119)
Remaining Estimate: 0h
Time Spent: 10m
> Deadlock during session exit
>
>
> Key: SSHD-1289
> URL: https://issues.apache.org/jira/browse/SSHD-1289
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: Evgeny Pasynkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
>java.lang.Thread.State: WAITING
> at java.base@11.0.5/jdk.internal.misc.Unsafe.park(Native Method)
> - waiting on
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@c50d1b2
> at
> java.base@11.0.5/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
> at
> java.base@11.0.5/java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885)
> at
> java.base@11.0.5/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:917)
> at
> java.base@11.0.5/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1240)
> at
> java.base@11.0.5/java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:959)
> at
> org.apache.sshd.common.session.helpers.KeyExchangeMessageHandler.updateState(KeyExchangeMessageHandler.java:139)
> at
> org.apache.sshd.common.session.helpers.KeyExchangeMessageHandler.shutdown(KeyExchangeMessageHandler.java:186)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.preClose(AbstractSession.java:967)
> at
> org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:94)
> at
> org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.sessionClosed(AbstractSessionIoHandler.java:46)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.doCloseImmediately(Nio2Session.java:283)
> at
> org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:95)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.exceptionCaught(Nio2Session.java:215)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.writeBuffer(Nio2Session.java:186)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:1118)
> - locked java.lang.Object@3423f353
> at
> org.apache.sshd.common.session.helpers.KeyExchangeMessageHandler.writeOrEnqueue(KeyExchangeMessageHandler.java:285)
> at
> org.apache.sshd.common.session.helpers.KeyExchangeMessageHandler.writePacket(KeyExchangeMessageHandler.java:228)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.writePacket(AbstractSession.java:1039)
> at org.apache.sshd.common.session.Session.writePacket(Session.java:159)
> at org.apache.sshd.common.session.Session.writePacket(Session.java:145)
> at
>
[jira] [Work logged] (SSHD-1285) 2.9.0 release broken on Java 8
[
https://issues.apache.org/jira/browse/SSHD-1285?focusedWorklogId=797532=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-797532
]
ASF GitHub Bot logged work on SSHD-1285:
Author: ASF GitHub Bot
Created on: 03/Aug/22 08:15
Start Date: 03/Aug/22 08:15
Worklog Time Spent: 10m
Work Description: norrisjeremy commented on PR #235:
URL: https://github.com/apache/mina-sshd/pull/235#issuecomment-1203632844
The `pom.xml` for this project already has the following, so it seems more
consistent to do it the way I proposed:
```
org.apache.maven.plugins
maven-compiler-plugin
3.8.1
${javac.source}
${javac.target}
...
```
Issue Time Tracking
---
Worklog Id: (was: 797532)
Time Spent: 40m (was: 0.5h)
> 2.9.0 release broken on Java 8
> --
>
> Key: SSHD-1285
> URL: https://issues.apache.org/jira/browse/SSHD-1285
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: macOS
>Reporter: Jeremy Norris
>Priority: Critical
> Fix For: 2.9.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> It appears the 2.9.0 release is broken on Java 8:
> [sshd-SshServer[130ad58d](port=)-nio2-thread-5] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Acceptor - Caught NoSuchMethodError while
> accepting incoming connection from /127.0.0.1::
> java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
> java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
> at
> org.apache.sshd.common.io.nio2.Nio2Session.doReadCycle(Nio2Session.java:455)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.doReadCycle(Nio2Session.java:334)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:327)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:323)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:319)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:315)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:311)
> at
> org.apache.sshd.common.io.nio2.Nio2Acceptor$AcceptCompletionHandler.onCompleted(Nio2Acceptor.java:305)
> at
> org.apache.sshd.common.io.nio2.Nio2Acceptor$AcceptCompletionHandler.onCompleted(Nio2Acceptor.java:260)
> at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
> at sun.nio.ch.Invoker$2.run(Invoker.java:218)
> at
> sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:750)
--
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] [Work logged] (SSHD-1285) 2.9.0 release broken on Java 8
[ https://issues.apache.org/jira/browse/SSHD-1285?focusedWorklogId=797520=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-797520 ] ASF GitHub Bot logged work on SSHD-1285: Author: ASF GitHub Bot Created on: 03/Aug/22 07:06 Start Date: 03/Aug/22 07:06 Worklog Time Spent: 10m Work Description: elecharny commented on PR #235: URL: https://github.com/apache/mina-sshd/pull/235#issuecomment-1203567816 Hi, I think this can also be done with just a property, like what we have in MINA: ``` 2.9.0 release broken on Java 8 > -- > > Key: SSHD-1285 > URL: https://issues.apache.org/jira/browse/SSHD-1285 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: macOS >Reporter: Jeremy Norris >Priority: Critical > Fix For: 2.9.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > It appears the 2.9.0 release is broken on Java 8: > [sshd-SshServer[130ad58d](port=)-nio2-thread-5] DEBUG > org.apache.sshd.common.io.nio2.Nio2Acceptor - Caught NoSuchMethodError while > accepting incoming connection from /127.0.0.1:: > java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer; > java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer; > at > org.apache.sshd.common.io.nio2.Nio2Session.doReadCycle(Nio2Session.java:455) > at > org.apache.sshd.common.io.nio2.Nio2Session.doReadCycle(Nio2Session.java:334) > at > org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:327) > at > org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:323) > at > org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:319) > at > org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:315) > at > org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:311) > at > org.apache.sshd.common.io.nio2.Nio2Acceptor$AcceptCompletionHandler.onCompleted(Nio2Acceptor.java:305) > at > org.apache.sshd.common.io.nio2.Nio2Acceptor$AcceptCompletionHandler.onCompleted(Nio2Acceptor.java:260) > at > org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37) > at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) > at sun.nio.ch.Invoker$2.run(Invoker.java:218) > at > sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:750) -- 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] [Work logged] (SSHD-1281) ClientSession.auth().verify() is terminated with timeout
[
https://issues.apache.org/jira/browse/SSHD-1281?focusedWorklogId=797404=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-797404
]
ASF GitHub Bot logged work on SSHD-1281:
Author: ASF GitHub Bot
Created on: 02/Aug/22 21:40
Start Date: 02/Aug/22 21:40
Worklog Time Spent: 10m
Work Description: tomaswolf merged PR #236:
URL: https://github.com/apache/mina-sshd/pull/236
Issue Time Tracking
---
Worklog Id: (was: 797404)
Remaining Estimate: 0h
Time Spent: 10m
> ClientSession.auth().verify() is terminated with timeout
>
>
> Key: SSHD-1281
> URL: https://issues.apache.org/jira/browse/SSHD-1281
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server
> 9.23
>Reporter: dgü
>Assignee: Thomas Wolf
>Priority: Major
> Attachments: SSHD-NoTimeout-2.8.9.PNG, SSHDTimeout.PNG,
> screenshot-1.png, screenshot-2.png, screenshot-3.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello!
> The following code works successfully in SSHD 2.8.0; but it fails in SSHD
> 2.9.0:
> {code:java}
> final ClientSession clientSession =
> SSH_CLIENT.connect(pURI.toString()).verify().getSession();
> System.out.println("clientSession.getSessionState(): " +
> clientSession.getSessionState());
> System.out.println("clientSession.isClosed() : " +
> clientSession.isClosed());
> System.out.println("clientSession.isClosing() : " +
> clientSession.isClosing());
> System.out.println("clientSession.isOpen() : " +
> clientSession.isOpen());
> System.out.println("before addPasswordIdentity: " + new
> Date(System.currentTimeMillis()));
> clientSession.addPasswordIdentity("deneme123");
> try {
> Thread.sleep(3000);
> } catch (InterruptedException ex) {
>
> Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE,
> null, ex);
> }
> System.out.println("clientSession.getSessionState(): " +
> clientSession.getSessionState());
> System.out.println("clientSession.isClosed() : " +
> clientSession.isClosed());
> System.out.println("clientSession.isClosing() : " +
> clientSession.isClosing());
> System.out.println("clientSession.isOpen() : " +
> clientSession.isOpen());
> System.out.println("before auth().verify(): " + new
> Date(System.currentTimeMillis()));
> clientSession.auth().verify();
> {code}
> The output and exception:
> {quote}Tem 27, 2022 11:50:19 PM
> org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider
> INFO: No detected/configured IoServiceFactoryFactory using
> Nio2ServiceFactoryFactory
> clientSession.getSessionState(): []
> clientSession.isClosed() : false
> clientSession.isClosing() : false
> clientSession.isOpen() : true
> before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022
> clientSession.getSessionState(): []
> clientSession.isClosed() : false
> clientSession.isClosing() : false
> clientSession.isOpen() : true
> before auth().verify(): Wed Jul 27 23:50:22 EET 2022
> Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper
> disconnect
> INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]):
> SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms.
> Exception in thread "main" org.apache.sshd.common.SshException: Session is
> being closed
> at
> org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127)
> at
> org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39)
> at
> org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32)
> at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
> at
> com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85)
> at
> com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:19)
> at
> com.ubtools.ubutils.service.UBServiceManager.getServiceConnection(UBServiceManager.java:135)
> at com.ubtools.ubutils.UBExec.main(UBExec.java:33)
> Caused by: org.apache.sshd.common.SshException: Session is being closed
> at
> org.apache.sshd.client.session.ClientSessionImpl.preClose(ClientSessionImpl.java:169)
> at
> org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:94)
> at
> org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.sessionClosed(AbstractSessionIoHandler.java:46)
> at
>
[jira] [Work logged] (SSHD-1285) 2.9.0 release broken on Java 8
[ https://issues.apache.org/jira/browse/SSHD-1285?focusedWorklogId=796860=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-796860 ] ASF GitHub Bot logged work on SSHD-1285: Author: ASF GitHub Bot Created on: 01/Aug/22 11:58 Start Date: 01/Aug/22 11:58 Worklog Time Spent: 10m Work Description: tomaswolf merged PR #235: URL: https://github.com/apache/mina-sshd/pull/235 Issue Time Tracking --- Worklog Id: (was: 796860) Time Spent: 20m (was: 10m) > 2.9.0 release broken on Java 8 > -- > > Key: SSHD-1285 > URL: https://issues.apache.org/jira/browse/SSHD-1285 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: macOS >Reporter: Jeremy Norris >Priority: Critical > Time Spent: 20m > Remaining Estimate: 0h > > It appears the 2.9.0 release is broken on Java 8: > [sshd-SshServer[130ad58d](port=)-nio2-thread-5] DEBUG > org.apache.sshd.common.io.nio2.Nio2Acceptor - Caught NoSuchMethodError while > accepting incoming connection from /127.0.0.1:: > java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer; > java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer; > at > org.apache.sshd.common.io.nio2.Nio2Session.doReadCycle(Nio2Session.java:455) > at > org.apache.sshd.common.io.nio2.Nio2Session.doReadCycle(Nio2Session.java:334) > at > org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:327) > at > org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:323) > at > org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:319) > at > org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:315) > at > org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:311) > at > org.apache.sshd.common.io.nio2.Nio2Acceptor$AcceptCompletionHandler.onCompleted(Nio2Acceptor.java:305) > at > org.apache.sshd.common.io.nio2.Nio2Acceptor$AcceptCompletionHandler.onCompleted(Nio2Acceptor.java:260) > at > org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37) > at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) > at sun.nio.ch.Invoker$2.run(Invoker.java:218) > at > sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:750) -- 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] [Work logged] (SSHD-1285) 2.9.0 release broken on Java 8
[ https://issues.apache.org/jira/browse/SSHD-1285?focusedWorklogId=796367=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-796367 ] ASF GitHub Bot logged work on SSHD-1285: Author: ASF GitHub Bot Created on: 29/Jul/22 12:23 Start Date: 29/Jul/22 12:23 Worklog Time Spent: 10m Work Description: norrisjeremy opened a new pull request, #235: URL: https://github.com/apache/mina-sshd/pull/235 … Java versions > 8 Issue Time Tracking --- Worklog Id: (was: 796367) Remaining Estimate: 0h Time Spent: 10m > 2.9.0 release broken on Java 8 > -- > > Key: SSHD-1285 > URL: https://issues.apache.org/jira/browse/SSHD-1285 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: macOS >Reporter: Jeremy Norris >Priority: Critical > Time Spent: 10m > Remaining Estimate: 0h > > It appears the 2.9.0 release is broken on Java 8: > [sshd-SshServer[130ad58d](port=)-nio2-thread-5] DEBUG > org.apache.sshd.common.io.nio2.Nio2Acceptor - Caught NoSuchMethodError while > accepting incoming connection from /127.0.0.1:: > java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer; > java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer; > at > org.apache.sshd.common.io.nio2.Nio2Session.doReadCycle(Nio2Session.java:455) > at > org.apache.sshd.common.io.nio2.Nio2Session.doReadCycle(Nio2Session.java:334) > at > org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:327) > at > org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:323) > at > org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:319) > at > org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:315) > at > org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:311) > at > org.apache.sshd.common.io.nio2.Nio2Acceptor$AcceptCompletionHandler.onCompleted(Nio2Acceptor.java:305) > at > org.apache.sshd.common.io.nio2.Nio2Acceptor$AcceptCompletionHandler.onCompleted(Nio2Acceptor.java:260) > at > org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37) > at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) > at sun.nio.ch.Invoker$2.run(Invoker.java:218) > at > sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:750) -- 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] [Work logged] (SSHD-1283) Add configurable support for ScpShell usage
[ https://issues.apache.org/jira/browse/SSHD-1283?focusedWorklogId=796153=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-796153 ] ASF GitHub Bot logged work on SSHD-1283: Author: ASF GitHub Bot Created on: 28/Jul/22 17:54 Start Date: 28/Jul/22 17:54 Worklog Time Spent: 10m Work Description: lgoldstein opened a new pull request, #234: URL: https://github.com/apache/mina-sshd/pull/234 @tomaswolf Do you mind giving this a quick look-over ? Thx Issue Time Tracking --- Worklog Id: (was: 796153) Remaining Estimate: 0h Time Spent: 10m > Add configurable support for ScpShell usage > --- > > Key: SSHD-1283 > URL: https://issues.apache.org/jira/browse/SSHD-1283 > Project: MINA SSHD > Issue Type: Question >Reporter: Sandeep >Assignee: Lyor Goldstein >Priority: Major > Attachments: SFTP.zip, image-2022-07-28-17-25-36-368.png > > Time Spent: 10m > Remaining Estimate: 0h > > Hi Team, > We have implemented sftp server where we are giving SFTP and SCP both > support. > Both are working fine if we connected via winscp or any terminal client like > putty etc. > > But if we use ssh command *ssh @localhost -p * > then it goes to interactive mode and exposes the current program running > directory to do all operations(screenshot shows dir command) (sftp is showing > correct directory as C:/ ) > > !image-2022-07-28-17-25-36-368.png|width=462,height=485! > > So just wanted to check if can we just disable the above ssh command and > still we can use scp and sftp? any help appreciated. > May be this fix is causing the problem? : > https://issues.apache.org/jira/browse/SSHD-1009, > I have attached the sample code. > -- 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] [Work logged] (SSHD-1276) Add support for merged inverted output and error streams of remote process
[
https://issues.apache.org/jira/browse/SSHD-1276?focusedWorklogId=789269=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-789269
]
ASF GitHub Bot logged work on SSHD-1276:
Author: ASF GitHub Bot
Created on: 09/Jul/22 16:24
Start Date: 09/Jul/22 16:24
Worklog Time Spent: 10m
Work Description: lgoldstein closed pull request #231: [SSHD-1276] Added
capability to redirect command/shell STDERR stream to STDOUT one
URL: https://github.com/apache/mina-sshd/pull/231
Issue Time Tracking
---
Worklog Id: (was: 789269)
Time Spent: 40m (was: 0.5h)
> Add support for merged inverted output and error streams of remote process
> --
>
> Key: SSHD-1276
> URL: https://issues.apache.org/jira/browse/SSHD-1276
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.8.0
> Environment: Java SE 8, Apache NetBeans IDE 8.2
>Reporter: dgü
>Assignee: Lyor Goldstein
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Hello!
> I want to merge output and error streams of remote process as
> {{java.lang.ProcessBuilder#redirectErrorStream(true)}} does.
> If I set output and error streams;
> {quote}channelExec.setOut(mergedOutputStream);
> channelExec.setErr(mergedOutputStream);
> channelExec.open.verify();
> {quote}
> Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}}
> return {{{}null{}}}.
> If I don't set output and error streams;
> {quote}//channelExec.setOut(mergedOutputStream);
> //channelExec.setErr(mergedOutputStream);
> channelExec.open.verify();
> {quote}
> Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}}
> return not {{{}null{}}}. But, streams are not merged.
> How can I merge output and error streams of remote process ?
> 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] [Work logged] (SSHD-1276) Add support for merged inverted output and error streams of remote process
[
https://issues.apache.org/jira/browse/SSHD-1276?focusedWorklogId=788680=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-788680
]
ASF GitHub Bot logged work on SSHD-1276:
Author: ASF GitHub Bot
Created on: 07/Jul/22 17:10
Start Date: 07/Jul/22 17:10
Worklog Time Spent: 10m
Work Description: lgoldstein commented on PR #231:
URL: https://github.com/apache/mina-sshd/pull/231#issuecomment-1177947787
You are correct - fixed it...
Issue Time Tracking
---
Worklog Id: (was: 788680)
Time Spent: 0.5h (was: 20m)
> Add support for merged inverted output and error streams of remote process
> --
>
> Key: SSHD-1276
> URL: https://issues.apache.org/jira/browse/SSHD-1276
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.8.0
> Environment: Java SE 8, Apache NetBeans IDE 8.2
>Reporter: dgü
>Assignee: Lyor Goldstein
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Hello!
> I want to merge output and error streams of remote process as
> {{java.lang.ProcessBuilder#redirectErrorStream(true)}} does.
> If I set output and error streams;
> {quote}channelExec.setOut(mergedOutputStream);
> channelExec.setErr(mergedOutputStream);
> channelExec.open.verify();
> {quote}
> Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}}
> return {{{}null{}}}.
> If I don't set output and error streams;
> {quote}//channelExec.setOut(mergedOutputStream);
> //channelExec.setErr(mergedOutputStream);
> channelExec.open.verify();
> {quote}
> Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}}
> return not {{{}null{}}}. But, streams are not merged.
> How can I merge output and error streams of remote process ?
> 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] [Work logged] (SSHD-1276) Add support for merged inverted output and error streams of remote process
[
https://issues.apache.org/jira/browse/SSHD-1276?focusedWorklogId=788564=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-788564
]
ASF GitHub Bot logged work on SSHD-1276:
Author: ASF GitHub Bot
Created on: 07/Jul/22 10:26
Start Date: 07/Jul/22 10:26
Worklog Time Spent: 10m
Work Description: tomaswolf commented on PR #231:
URL: https://github.com/apache/mina-sshd/pull/231#issuecomment-1177369294
What about ```Streaming.Async```?
Issue Time Tracking
---
Worklog Id: (was: 788564)
Time Spent: 20m (was: 10m)
> Add support for merged inverted output and error streams of remote process
> --
>
> Key: SSHD-1276
> URL: https://issues.apache.org/jira/browse/SSHD-1276
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.8.0
> Environment: Java SE 8, Apache NetBeans IDE 8.2
>Reporter: dgü
>Assignee: Lyor Goldstein
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hello!
> I want to merge output and error streams of remote process as
> {{java.lang.ProcessBuilder#redirectErrorStream(true)}} does.
> If I set output and error streams;
> {quote}channelExec.setOut(mergedOutputStream);
> channelExec.setErr(mergedOutputStream);
> channelExec.open.verify();
> {quote}
> Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}}
> return {{{}null{}}}.
> If I don't set output and error streams;
> {quote}//channelExec.setOut(mergedOutputStream);
> //channelExec.setErr(mergedOutputStream);
> channelExec.open.verify();
> {quote}
> Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}}
> return not {{{}null{}}}. But, streams are not merged.
> How can I merge output and error streams of remote process ?
> 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] [Work logged] (SSHD-1276) Add support for merged inverted output and error streams of remote process
[
https://issues.apache.org/jira/browse/SSHD-1276?focusedWorklogId=788541=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-788541
]
ASF GitHub Bot logged work on SSHD-1276:
Author: ASF GitHub Bot
Created on: 07/Jul/22 08:56
Start Date: 07/Jul/22 08:56
Worklog Time Spent: 10m
Work Description: lgoldstein opened a new pull request, #231:
URL: https://github.com/apache/mina-sshd/pull/231
@tomaswolf I would appreciate your feedback...
Issue Time Tracking
---
Worklog Id: (was: 788541)
Remaining Estimate: 0h
Time Spent: 10m
> Add support for merged inverted output and error streams of remote process
> --
>
> Key: SSHD-1276
> URL: https://issues.apache.org/jira/browse/SSHD-1276
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.8.0
> Environment: Java SE 8, Apache NetBeans IDE 8.2
>Reporter: dgü
>Assignee: Lyor Goldstein
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello!
> I want to merge output and error streams of remote process as
> {{java.lang.ProcessBuilder#redirectErrorStream(true)}} does.
> If I set output and error streams;
> {quote}channelExec.setOut(mergedOutputStream);
> channelExec.setErr(mergedOutputStream);
> channelExec.open.verify();
> {quote}
> Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}}
> return {{{}null{}}}.
> If I don't set output and error streams;
> {quote}//channelExec.setOut(mergedOutputStream);
> //channelExec.setErr(mergedOutputStream);
> channelExec.open.verify();
> {quote}
> Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}}
> return not {{{}null{}}}. But, streams are not merged.
> How can I merge output and error streams of remote process ?
> 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] [Work logged] (SSHD-1273) Send environment variable and open subsystem at the same time for SSH session
[
https://issues.apache.org/jira/browse/SSHD-1273?focusedWorklogId=787296=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-787296
]
ASF GitHub Bot logged work on SSHD-1273:
Author: ASF GitHub Bot
Created on: 02/Jul/22 06:14
Start Date: 02/Jul/22 06:14
Worklog Time Spent: 10m
Work Description: lgoldstein commented on PR #230:
URL: https://github.com/apache/mina-sshd/pull/230#issuecomment-1172843838
[RFC 4254 - section
6.4](https://datatracker.ietf.org/doc/html/rfc4254#section-6.4) mentions shell
and/or command but not subsystem. However, I see no harm in allowing this for
subsystems as well. IMO it is the **user's** responsibility to make sure that
the peer handles environment settings correctly. Our code simply updates a
`StandardEnvironment` instance.
Issue Time Tracking
---
Worklog Id: (was: 787296)
Time Spent: 2h (was: 1h 50m)
> Send environment variable and open subsystem at the same time for SSH session
> -
>
> Key: SSHD-1273
> URL: https://issues.apache.org/jira/browse/SSHD-1273
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.8.0
>Reporter: Andrei Danilenka
>Priority: Major
> Fix For: 2.9.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> I use Apache Mina SSH client. The request that I want to send looks like:
> {code:java}
> user@host -w my_password -o SendEnv=SOME_VAR -s subsystem_name{code}
> But for now it is impossible to use env vars and subsystem together.
> What I have tried so far
> 1. ChannelShell class has setEnv(key, value) method but I can't go in
> subsystem
> 2. ChannelSubsystem class allows to go to subsystem but it has no
> setEnv(key, value) method
> 3. Also I have tried to open ChannelShell, set env, then open
> ChannelSubsystem using the same session as was used for ChannelShell, but it
> seems env variable hasn't gotten to ChannelSubsystem.
--
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] [Work logged] (SSHD-1273) Send environment variable and open subsystem at the same time for SSH session
[
https://issues.apache.org/jira/browse/SSHD-1273?focusedWorklogId=787216=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-787216
]
ASF GitHub Bot logged work on SSHD-1273:
Author: ASF GitHub Bot
Created on: 01/Jul/22 20:38
Start Date: 01/Jul/22 20:38
Worklog Time Spent: 10m
Work Description: tomaswolf merged PR #230:
URL: https://github.com/apache/mina-sshd/pull/230
Issue Time Tracking
---
Worklog Id: (was: 787216)
Time Spent: 1h 50m (was: 1h 40m)
> Send environment variable and open subsystem at the same time for SSH session
> -
>
> Key: SSHD-1273
> URL: https://issues.apache.org/jira/browse/SSHD-1273
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.8.0
>Reporter: Andrei Danilenka
>Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> I use Apache Mina SSH client. The request that I want to send looks like:
> {code:java}
> user@host -w my_password -o SendEnv=SOME_VAR -s subsystem_name{code}
> But for now it is impossible to use env vars and subsystem together.
> What I have tried so far
> 1. ChannelShell class has setEnv(key, value) method but I can't go in
> subsystem
> 2. ChannelSubsystem class allows to go to subsystem but it has no
> setEnv(key, value) method
> 3. Also I have tried to open ChannelShell, set env, then open
> ChannelSubsystem using the same session as was used for ChannelShell, but it
> seems env variable hasn't gotten to ChannelSubsystem.
--
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] [Work logged] (SSHD-1273) Send environment variable and open subsystem at the same time for SSH session
[
https://issues.apache.org/jira/browse/SSHD-1273?focusedWorklogId=787197=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-787197
]
ASF GitHub Bot logged work on SSHD-1273:
Author: ASF GitHub Bot
Created on: 01/Jul/22 18:38
Start Date: 01/Jul/22 18:38
Worklog Time Spent: 10m
Work Description: andreid911 commented on code in PR #230:
URL: https://github.com/apache/mina-sshd/pull/230#discussion_r912182439
##
sshd-core/src/main/java/org/apache/sshd/client/channel/ChannelSession.java:
##
@@ -217,4 +223,42 @@ protected int securedRead(
}
}
}
+
+/**
+ * @param key The (never {@code null}) key (Note: may be empty...)
+ * @param value The value to set - if {@code null} then the pre-existing
value for the key (if any) is
+ * removed.
+ * @return The replaced/removed previous value - {@code null} if no
previous value set for the key.
+ */
+public Object setEnv(String key, Object value) {
+ValidateUtils.checkNotNull(key, "No key provided");
Review Comment:
@tomaswolf Agree. Changes were reverted.
Issue Time Tracking
---
Worklog Id: (was: 787197)
Time Spent: 1h 40m (was: 1.5h)
> Send environment variable and open subsystem at the same time for SSH session
> -
>
> Key: SSHD-1273
> URL: https://issues.apache.org/jira/browse/SSHD-1273
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.8.0
>Reporter: Andrei Danilenka
>Priority: Major
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> I use Apache Mina SSH client. The request that I want to send looks like:
> {code:java}
> user@host -w my_password -o SendEnv=SOME_VAR -s subsystem_name{code}
> But for now it is impossible to use env vars and subsystem together.
> What I have tried so far
> 1. ChannelShell class has setEnv(key, value) method but I can't go in
> subsystem
> 2. ChannelSubsystem class allows to go to subsystem but it has no
> setEnv(key, value) method
> 3. Also I have tried to open ChannelShell, set env, then open
> ChannelSubsystem using the same session as was used for ChannelShell, but it
> seems env variable hasn't gotten to ChannelSubsystem.
--
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] [Work logged] (SSHD-1273) Send environment variable and open subsystem at the same time for SSH session
[
https://issues.apache.org/jira/browse/SSHD-1273?focusedWorklogId=787196=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-787196
]
ASF GitHub Bot logged work on SSHD-1273:
Author: ASF GitHub Bot
Created on: 01/Jul/22 18:31
Start Date: 01/Jul/22 18:31
Worklog Time Spent: 10m
Work Description: tomaswolf commented on code in PR #230:
URL: https://github.com/apache/mina-sshd/pull/230#discussion_r912174964
##
sshd-core/src/main/java/org/apache/sshd/client/channel/ChannelSession.java:
##
@@ -217,4 +223,42 @@ protected int securedRead(
}
}
}
+
+/**
+ * @param key The (never {@code null}) key (Note: may be empty...)
+ * @param value The value to set - if {@code null} then the pre-existing
value for the key (if any) is
+ * removed.
+ * @return The replaced/removed previous value - {@code null} if no
previous value set for the key.
+ */
+public Object setEnv(String key, Object value) {
+ValidateUtils.checkNotNull(key, "No key provided");
Review Comment:
Agree. Let's _not_ change this in this refactoring. One thing at a time. The
current version of this PR _does_ change this, though. @andreid911 : if you
want to undo that, it's fine. Just amend and force push.
Issue Time Tracking
---
Worklog Id: (was: 787196)
Time Spent: 1.5h (was: 1h 20m)
> Send environment variable and open subsystem at the same time for SSH session
> -
>
> Key: SSHD-1273
> URL: https://issues.apache.org/jira/browse/SSHD-1273
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.8.0
>Reporter: Andrei Danilenka
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> I use Apache Mina SSH client. The request that I want to send looks like:
> {code:java}
> user@host -w my_password -o SendEnv=SOME_VAR -s subsystem_name{code}
> But for now it is impossible to use env vars and subsystem together.
> What I have tried so far
> 1. ChannelShell class has setEnv(key, value) method but I can't go in
> subsystem
> 2. ChannelSubsystem class allows to go to subsystem but it has no
> setEnv(key, value) method
> 3. Also I have tried to open ChannelShell, set env, then open
> ChannelSubsystem using the same session as was used for ChannelShell, but it
> seems env variable hasn't gotten to ChannelSubsystem.
--
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] [Work logged] (SSHD-1273) Send environment variable and open subsystem at the same time for SSH session
[
https://issues.apache.org/jira/browse/SSHD-1273?focusedWorklogId=787186=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-787186
]
ASF GitHub Bot logged work on SSHD-1273:
Author: ASF GitHub Bot
Created on: 01/Jul/22 18:12
Start Date: 01/Jul/22 18:12
Worklog Time Spent: 10m
Work Description: andreid911 commented on code in PR #230:
URL: https://github.com/apache/mina-sshd/pull/230#discussion_r912164373
##
sshd-core/src/main/java/org/apache/sshd/client/channel/ChannelSession.java:
##
@@ -217,4 +223,42 @@ protected int securedRead(
}
}
}
+
+/**
+ * @param key The (never {@code null}) key (Note: may be empty...)
+ * @param value The value to set - if {@code null} then the pre-existing
value for the key (if any) is
+ * removed.
+ * @return The replaced/removed previous value - {@code null} if no
previous value set for the key.
+ */
+public Object setEnv(String key, Object value) {
+ValidateUtils.checkNotNull(key, "No key provided");
Review Comment:
According to the current javadoc: key can be empty string. I am not planning
to make any constraints changes to avoid behavior changes.
@lgoldstein do you think we can change javadoc and update validation or use
old validation without empty check?
Issue Time Tracking
---
Worklog Id: (was: 787186)
Time Spent: 1h 20m (was: 1h 10m)
> Send environment variable and open subsystem at the same time for SSH session
> -
>
> Key: SSHD-1273
> URL: https://issues.apache.org/jira/browse/SSHD-1273
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.8.0
>Reporter: Andrei Danilenka
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> I use Apache Mina SSH client. The request that I want to send looks like:
> {code:java}
> user@host -w my_password -o SendEnv=SOME_VAR -s subsystem_name{code}
> But for now it is impossible to use env vars and subsystem together.
> What I have tried so far
> 1. ChannelShell class has setEnv(key, value) method but I can't go in
> subsystem
> 2. ChannelSubsystem class allows to go to subsystem but it has no
> setEnv(key, value) method
> 3. Also I have tried to open ChannelShell, set env, then open
> ChannelSubsystem using the same session as was used for ChannelShell, but it
> seems env variable hasn't gotten to ChannelSubsystem.
--
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] [Work logged] (SSHD-1273) Send environment variable and open subsystem at the same time for SSH session
[
https://issues.apache.org/jira/browse/SSHD-1273?focusedWorklogId=787184=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-787184
]
ASF GitHub Bot logged work on SSHD-1273:
Author: ASF GitHub Bot
Created on: 01/Jul/22 18:04
Start Date: 01/Jul/22 18:04
Worklog Time Spent: 10m
Work Description: andreid911 commented on code in PR #230:
URL: https://github.com/apache/mina-sshd/pull/230#discussion_r912141627
##
sshd-core/src/main/java/org/apache/sshd/client/channel/PtyCapableChannelSession.java:
##
@@ -200,21 +199,6 @@ public void setPtyModes(Map ptyModes) {
config.setPtyModes((ptyModes == null) ? Collections.emptyMap() :
ptyModes);
}
-/**
- * @param key The (never {@code null}) key (Note: may be empty...)
- * @param value The value to set - if {@code null} then the pre-existing
value for the key (if any) is
- * removed.
- * @return The replaced/removed previous value - {@code null} if no
previous value set for the key.
- */
-public Object setEnv(String key, Object value) {
-ValidateUtils.checkNotNull(key, "No key provided");
Review Comment:
It's deleted section. Will comment in another place.
Issue Time Tracking
---
Worklog Id: (was: 787184)
Time Spent: 1h 10m (was: 1h)
> Send environment variable and open subsystem at the same time for SSH session
> -
>
> Key: SSHD-1273
> URL: https://issues.apache.org/jira/browse/SSHD-1273
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.8.0
>Reporter: Andrei Danilenka
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I use Apache Mina SSH client. The request that I want to send looks like:
> {code:java}
> user@host -w my_password -o SendEnv=SOME_VAR -s subsystem_name{code}
> But for now it is impossible to use env vars and subsystem together.
> What I have tried so far
> 1. ChannelShell class has setEnv(key, value) method but I can't go in
> subsystem
> 2. ChannelSubsystem class allows to go to subsystem but it has no
> setEnv(key, value) method
> 3. Also I have tried to open ChannelShell, set env, then open
> ChannelSubsystem using the same session as was used for ChannelShell, but it
> seems env variable hasn't gotten to ChannelSubsystem.
--
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] [Work logged] (SSHD-1273) Send environment variable and open subsystem at the same time for SSH session
[
https://issues.apache.org/jira/browse/SSHD-1273?focusedWorklogId=787183=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-787183
]
ASF GitHub Bot logged work on SSHD-1273:
Author: ASF GitHub Bot
Created on: 01/Jul/22 17:55
Start Date: 01/Jul/22 17:55
Worklog Time Spent: 10m
Work Description: andreid911 commented on code in PR #230:
URL: https://github.com/apache/mina-sshd/pull/230#discussion_r912141627
##
sshd-core/src/main/java/org/apache/sshd/client/channel/PtyCapableChannelSession.java:
##
@@ -200,21 +199,6 @@ public void setPtyModes(Map ptyModes) {
config.setPtyModes((ptyModes == null) ? Collections.emptyMap() :
ptyModes);
}
-/**
- * @param key The (never {@code null}) key (Note: may be empty...)
- * @param value The value to set - if {@code null} then the pre-existing
value for the key (if any) is
- * removed.
- * @return The replaced/removed previous value - {@code null} if no
previous value set for the key.
- */
-public Object setEnv(String key, Object value) {
-ValidateUtils.checkNotNull(key, "No key provided");
Review Comment:
It's deleted section. Changes applied in new code
Issue Time Tracking
---
Worklog Id: (was: 787183)
Time Spent: 1h (was: 50m)
> Send environment variable and open subsystem at the same time for SSH session
> -
>
> Key: SSHD-1273
> URL: https://issues.apache.org/jira/browse/SSHD-1273
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.8.0
>Reporter: Andrei Danilenka
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> I use Apache Mina SSH client. The request that I want to send looks like:
> {code:java}
> user@host -w my_password -o SendEnv=SOME_VAR -s subsystem_name{code}
> But for now it is impossible to use env vars and subsystem together.
> What I have tried so far
> 1. ChannelShell class has setEnv(key, value) method but I can't go in
> subsystem
> 2. ChannelSubsystem class allows to go to subsystem but it has no
> setEnv(key, value) method
> 3. Also I have tried to open ChannelShell, set env, then open
> ChannelSubsystem using the same session as was used for ChannelShell, but it
> seems env variable hasn't gotten to ChannelSubsystem.
--
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] [Work logged] (SSHD-1273) Send environment variable and open subsystem at the same time for SSH session
[
https://issues.apache.org/jira/browse/SSHD-1273?focusedWorklogId=787180=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-787180
]
ASF GitHub Bot logged work on SSHD-1273:
Author: ASF GitHub Bot
Created on: 01/Jul/22 17:37
Start Date: 01/Jul/22 17:37
Worklog Time Spent: 10m
Work Description: andreid911 commented on PR #230:
URL: https://github.com/apache/mina-sshd/pull/230#issuecomment-1172572248
@lgoldstein fixed defects from comments and squashed to 1 commit.
Issue Time Tracking
---
Worklog Id: (was: 787180)
Time Spent: 50m (was: 40m)
> Send environment variable and open subsystem at the same time for SSH session
> -
>
> Key: SSHD-1273
> URL: https://issues.apache.org/jira/browse/SSHD-1273
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.8.0
>Reporter: Andrei Danilenka
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I use Apache Mina SSH client. The request that I want to send looks like:
> {code:java}
> user@host -w my_password -o SendEnv=SOME_VAR -s subsystem_name{code}
> But for now it is impossible to use env vars and subsystem together.
> What I have tried so far
> 1. ChannelShell class has setEnv(key, value) method but I can't go in
> subsystem
> 2. ChannelSubsystem class allows to go to subsystem but it has no
> setEnv(key, value) method
> 3. Also I have tried to open ChannelShell, set env, then open
> ChannelSubsystem using the same session as was used for ChannelShell, but it
> seems env variable hasn't gotten to ChannelSubsystem.
--
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] [Work logged] (SSHD-1273) Send environment variable and open subsystem at the same time for SSH session
[
https://issues.apache.org/jira/browse/SSHD-1273?focusedWorklogId=787179=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-787179
]
ASF GitHub Bot logged work on SSHD-1273:
Author: ASF GitHub Bot
Created on: 01/Jul/22 17:34
Start Date: 01/Jul/22 17:34
Worklog Time Spent: 10m
Work Description: andreid911 commented on code in PR #230:
URL: https://github.com/apache/mina-sshd/pull/230#discussion_r912141534
##
sshd-core/src/main/java/org/apache/sshd/client/channel/ChannelSession.java:
##
@@ -48,6 +53,7 @@ public class ChannelSession extends AbstractClientChannel {
private CloseableExecutorService pumperService;
private Future pumper;
+private Map env = new LinkedHashMap<>();
Review Comment:
agree, no reasons to leave it mutable. Fixed
##
sshd-core/src/main/java/org/apache/sshd/client/channel/PtyCapableChannelSession.java:
##
@@ -200,21 +199,6 @@ public void setPtyModes(Map ptyModes) {
config.setPtyModes((ptyModes == null) ? Collections.emptyMap() :
ptyModes);
}
-/**
- * @param key The (never {@code null}) key (Note: may be empty...)
- * @param value The value to set - if {@code null} then the pre-existing
value for the key (if any) is
- * removed.
- * @return The replaced/removed previous value - {@code null} if no
previous value set for the key.
- */
-public Object setEnv(String key, Object value) {
-ValidateUtils.checkNotNull(key, "No key provided");
Review Comment:
it is just deleted code :)
Issue Time Tracking
---
Worklog Id: (was: 787179)
Time Spent: 40m (was: 0.5h)
> Send environment variable and open subsystem at the same time for SSH session
> -
>
> Key: SSHD-1273
> URL: https://issues.apache.org/jira/browse/SSHD-1273
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.8.0
>Reporter: Andrei Danilenka
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I use Apache Mina SSH client. The request that I want to send looks like:
> {code:java}
> user@host -w my_password -o SendEnv=SOME_VAR -s subsystem_name{code}
> But for now it is impossible to use env vars and subsystem together.
> What I have tried so far
> 1. ChannelShell class has setEnv(key, value) method but I can't go in
> subsystem
> 2. ChannelSubsystem class allows to go to subsystem but it has no
> setEnv(key, value) method
> 3. Also I have tried to open ChannelShell, set env, then open
> ChannelSubsystem using the same session as was used for ChannelShell, but it
> seems env variable hasn't gotten to ChannelSubsystem.
--
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] [Work logged] (SSHD-1273) Send environment variable and open subsystem at the same time for SSH session
[
https://issues.apache.org/jira/browse/SSHD-1273?focusedWorklogId=787174=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-787174
]
ASF GitHub Bot logged work on SSHD-1273:
Author: ASF GitHub Bot
Created on: 01/Jul/22 17:16
Start Date: 01/Jul/22 17:16
Worklog Time Spent: 10m
Work Description: lgoldstein commented on code in PR #230:
URL: https://github.com/apache/mina-sshd/pull/230#discussion_r912124733
##
sshd-core/src/main/java/org/apache/sshd/client/channel/ChannelSession.java:
##
@@ -48,6 +53,7 @@ public class ChannelSession extends AbstractClientChannel {
private CloseableExecutorService pumperService;
private Future pumper;
+private Map env = new LinkedHashMap<>();
Review Comment:
Should be `final` - unless there is some reason to make it mutabel (?)
##
sshd-core/src/main/java/org/apache/sshd/client/channel/ChannelSession.java:
##
@@ -217,4 +223,42 @@ protected int securedRead(
}
}
}
+
+/**
+ * @param key The (never {@code null}) key (Note: may be empty...)
+ * @param value The value to set - if {@code null} then the pre-existing
value for the key (if any) is
+ * removed.
+ * @return The replaced/removed previous value - {@code null} if no
previous value set for the key.
+ */
+public Object setEnv(String key, Object value) {
+ValidateUtils.checkNotNull(key, "No key provided");
+if (value == null) {
+return env.remove(key);
+} else {
+return env.put(key, value);
+}
+}
+
+protected void sendEnvVariables(Session session) throws IOException {
+if (MapEntryUtils.size(env) > 0) {
+if (log.isDebugEnabled()) {
+log.debug("Sending env variables ({}) Send
SSH_MSG_CHANNEL_REQUEST env: {}", this, env);
+}
+
+// Cannot use forEach because of the IOException being thrown by
writePacket
+for (Map.Entry entry : env.entrySet()) {
+String key = entry.getKey();
+Object value = entry.getValue();
+String str = Objects.toString(value);
+Buffer buffer = session.createBuffer(
+SshConstants.SSH_MSG_CHANNEL_REQUEST, key.length() +
GenericUtils.length(str) + Integer.SIZE);
+buffer.putInt(getRecipient());
+buffer.putString("env");
+buffer.putBoolean(false); // want-reply
Review Comment:
The standard does not say that *wantReply* must be *false* - while I do
agree that it is a sensible default have you given thought how yo handle *true*
? At the very least this choice should be documented and perhaps open a
follow-up issue to add support for *wantReply=true* in some future release
##
sshd-core/src/main/java/org/apache/sshd/client/channel/PtyCapableChannelSession.java:
##
@@ -289,25 +273,6 @@ protected void doOpenPty() throws IOException {
writePacket(buffer);
}
-if (MapEntryUtils.size(env) > 0) {
-if (debugEnabled) {
-log.debug("doOpenPty({}) Send SSH_MSG_CHANNEL_REQUEST env:
{}", this, env);
-}
-
-// Cannot use forEach because of the IOException being thrown by
writePacket
-for (Map.Entry entry : env.entrySet()) {
-String key = entry.getKey();
-Object value = entry.getValue();
-String str = Objects.toString(value);
-Buffer buffer = session.createBuffer(
-SshConstants.SSH_MSG_CHANNEL_REQUEST, key.length() +
GenericUtils.length(str) + Integer.SIZE);
-buffer.putInt(getRecipient());
-buffer.putString("env");
-buffer.putBoolean(false); // want-reply
Review Comment:
See previous comment regarding *wantReply=false* as hardwired value
##
sshd-core/src/main/java/org/apache/sshd/client/channel/ChannelSession.java:
##
@@ -217,4 +223,42 @@ protected int securedRead(
}
}
}
+
+/**
+ * @param key The (never {@code null}) key (Note: may be empty...)
+ * @param value The value to set - if {@code null} then the pre-existing
value for the key (if any) is
+ * removed.
+ * @return The replaced/removed previous value - {@code null} if no
previous value set for the key.
+ */
+public Object setEnv(String key, Object value) {
+ValidateUtils.checkNotNull(key, "No key provided");
Review Comment:
Please use `ValidateUtils#checkNotNullAndNotEmpty(key)`
##
sshd-core/src/main/java/org/apache/sshd/client/channel/ChannelSession.java:
##
@@ -48,6 +53,7 @@ public class ChannelSession extends AbstractClientChannel {
private
[jira] [Work logged] (SSHD-1273) Send environment variable and open subsystem at the same time for SSH session
[
https://issues.apache.org/jira/browse/SSHD-1273?focusedWorklogId=787175=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-787175
]
ASF GitHub Bot logged work on SSHD-1273:
Author: ASF GitHub Bot
Created on: 01/Jul/22 17:16
Start Date: 01/Jul/22 17:16
Worklog Time Spent: 10m
Work Description: lgoldstein commented on code in PR #230:
URL: https://github.com/apache/mina-sshd/pull/230#discussion_r912124733
##
sshd-core/src/main/java/org/apache/sshd/client/channel/ChannelSession.java:
##
@@ -48,6 +53,7 @@ public class ChannelSession extends AbstractClientChannel {
private CloseableExecutorService pumperService;
private Future pumper;
+private Map env = new LinkedHashMap<>();
Review Comment:
Should be `final` - unless there is some reason to make it mutable (?)
Issue Time Tracking
---
Worklog Id: (was: 787175)
Time Spent: 0.5h (was: 20m)
> Send environment variable and open subsystem at the same time for SSH session
> -
>
> Key: SSHD-1273
> URL: https://issues.apache.org/jira/browse/SSHD-1273
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.8.0
>Reporter: Andrei Danilenka
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I use Apache Mina SSH client. The request that I want to send looks like:
> {code:java}
> user@host -w my_password -o SendEnv=SOME_VAR -s subsystem_name{code}
> But for now it is impossible to use env vars and subsystem together.
> What I have tried so far
> 1. ChannelShell class has setEnv(key, value) method but I can't go in
> subsystem
> 2. ChannelSubsystem class allows to go to subsystem but it has no
> setEnv(key, value) method
> 3. Also I have tried to open ChannelShell, set env, then open
> ChannelSubsystem using the same session as was used for ChannelShell, but it
> seems env variable hasn't gotten to ChannelSubsystem.
--
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] [Work logged] (SSHD-1273) Send environment variable and open subsystem at the same time for SSH session
[
https://issues.apache.org/jira/browse/SSHD-1273?focusedWorklogId=787099=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-787099
]
ASF GitHub Bot logged work on SSHD-1273:
Author: ASF GitHub Bot
Created on: 01/Jul/22 13:22
Start Date: 01/Jul/22 13:22
Worklog Time Spent: 10m
Work Description: tomaswolf commented on code in PR #230:
URL: https://github.com/apache/mina-sshd/pull/230#discussion_r911959262
##
sshd-core/src/main/java/org/apache/sshd/client/channel/PtyCapableChannelSession.java:
##
@@ -200,21 +200,6 @@ public void setPtyModes(Map ptyModes) {
config.setPtyModes((ptyModes == null) ? Collections.emptyMap() :
ptyModes);
}
-/**
- * @param key The (never {@code null}) key (Note: may be empty...)
- * @param value The value to set - if {@code null} then the pre-existing
value for the key (if any) is
- * removed.
- * @return The replaced/removed previous value - {@code null} if no
previous value set for the key.
- */
-public Object setEnv(String key, Object value) {
-ValidateUtils.checkNotNull(key, "No key provided");
-if (value == null) {
-return env.remove(key);
-} else {
-return env.put(key, value);
-}
-}
-
Review Comment:
Also remove the map in line 88.
Issue Time Tracking
---
Worklog Id: (was: 787099)
Remaining Estimate: 0h
Time Spent: 10m
> Send environment variable and open subsystem at the same time for SSH session
> -
>
> Key: SSHD-1273
> URL: https://issues.apache.org/jira/browse/SSHD-1273
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.8.0
>Reporter: Andrei Danilenka
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use Apache Mina SSH client. The request that I want to send looks like:
> {code:java}
> user@host -w my_password -o SendEnv=SOME_VAR -s subsystem_name{code}
> But for now it is impossible to use env vars and subsystem together.
> What I have tried so far
> 1. ChannelShell class has setEnv(key, value) method but I can't go in
> subsystem
> 2. ChannelSubsystem class allows to go to subsystem but it has no
> setEnv(key, value) method
> 3. Also I have tried to open ChannelShell, set env, then open
> ChannelSubsystem using the same session as was used for ChannelShell, but it
> seems env variable hasn't gotten to ChannelSubsystem.
--
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
