[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=934242&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-934242 ] ASF GitHub Bot logged work on DIRMINA-1173: --- Author: ASF GitHub Bot Created on: 11/Sep/24 11:38 Start Date: 11/Sep/24 11:38 Worklog Time Spent: 10m Work Description: asfgit merged PR #44: URL: https://github.com/apache/mina/pull/44 Issue Time Tracking --- Worklog Id: (was: 934242) Time Spent: 1h 40m (was: 1.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: 1h 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", > 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 connection setup time out > happend.", > ha
[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&page=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); > conne
[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&page=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&page=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", > G10CaptureServ
[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&page=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&page=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&page=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", > G10CaptureService.loggingFi
[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&page=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&page=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(); > t
[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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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", "client-san-ext.tr
[jira] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861068&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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.com
[jira] [Work logged] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
[ https://issues.apache.org/jira/browse/SSHD-1307?focusedWorklogId=821103&page=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&page=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:900
[jira] [Work logged] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
[ https://issues.apache.org/jira/browse/SSHD-1307?focusedWorklogId=819817&page=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&page=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:90
[jira] [Work logged] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
[ https://issues.apache.org/jira/browse/SSHD-1307?focusedWorklogId=819792&page=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&page=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
[jira] [Work logged] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
[ https://issues.apache.org/jira/browse/SSHD-1307?focusedWorklogId=819786&page=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&page=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, > re
[jira] [Work logged] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
[ https://issues.apache.org/jira/browse/SSHD-1307?focusedWorklogId=819382&page=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&page=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]-ClientSession
[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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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 > org.apache.sshd.common.future.Defa
[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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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 theof 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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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 > org.apache.sshd.common.util.closeable.SequentialCloseable$1.operationComplete(SequentialCloseable.jav
[jira] [Work logged] (SSHD-1289) Deadlock during session exit
[ https://issues.apache.org/jira/browse/SSHD-1289?focusedWorklogId=800119&page=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 > org.apache.sshd.common.channe
[jira] [Work logged] (SSHD-1285) 2.9.0 release broken on Java 8
[ https://issues.apache.org/jira/browse/SSHD-1285?focusedWorklogId=797532&page=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&page=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&page=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 > org.apache.sshd.common.io.nio2.Nio2Session.doCloseImm
[jira] [Work logged] (SSHD-1285) 2.9.0 release broken on Java 8
[ https://issues.apache.org/jira/browse/SSHD-1285?focusedWorklogId=796860&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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&page=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 Closeable
[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&page=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