[jira] [Work logged] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=918949=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918949
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 11/May/24 23:53
Start Date: 11/May/24 23:53
Worklog Time Spent: 10m
Work Description: elecharny commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597523524
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
I missed the MSS part. Ok, so makes sense to keep the parameter as is, but I
do agree that *not* setting a default at all would be a better option. At
least, you let the developer makes a choice depending on what they actually
measure.
Thanks Jon!
Issue Time Tracking
---
Worklog Id: (was: 918949)
Time Spent: 1.5h (was: 1h 20m)
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> connector.getFilterChain().addLast("codecFilter"
[jira] [Work logged] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=918948=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918948
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 11/May/24 22:28
Start Date: 11/May/24 22:28
Worklog Time Spent: 10m
Work Description: jon-valliere commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597516034
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
See https://en.wikipedia.org/wiki/Nagle%27s_algorithm
Nagle only really applies for when the packets are smaller than the MSS
which is usually 1280 bytes. AFAIK only the HELLO message in TLS HS is smaller
than this; all other messages SHOULD be aggregated together by the SSL layer.
There IS a _well known_ interaction with Nagle and Delayed Ack which can cause
Nagle to be worse than it would be by itself. What is the order of delays you
are seeing?
Issue Time Tracking
---
Worklog Id: (was: 918948)
Time Spent: 1h 20m (was: 1h 10m)
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new Ni
[jira] [Work logged] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=918947=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918947
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 11/May/24 22:09
Start Date: 11/May/24 22:09
Worklog Time Spent: 10m
Work Description: jon-valliere commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597513918
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
In my other IO framework, all of the TCP/SOCK options all have `unset`
states where the framework code will not call the SOCK configuration at all and
allow the OS defaults to be applied.
Issue Time Tracking
---
Worklog Id: (was: 918947)
Time Spent: 1h 10m (was: 1h)
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> connec
[jira] [Work logged] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=918946=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918946
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 11/May/24 22:02
Start Date: 11/May/24 22:02
Worklog Time Spent: 10m
Work Description: elecharny commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597513323
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
Not arguing here, I will revert but...
I do think that this flag should be opt-in, ie the Nagle algorithm should be
disabled by default. The use cases were it's useful are not really the most
frequent, and the drawbacks are numerous. If the default sendBuffer size is
set to 64Ko, then you have a delayed for every packet that has a lower number
of bytes to transfert. if you set the sendBuffer size to a lower value, then
you are sending way more packet than needed. In any case, if you are to send
some data that span on more than one packet, and the last packet is not
completed, then you'll pay a 200ms delay every time. Not very cool.
With Gigabits connections, sending a lot of packets is not really an issue
anymore, except on heavily loaded applications that aren't interactive (HTTP
may enter into this category, but with REST application, I would argue that an
immediate sending is a plus).
Regarding LDAP, requests are small there is no interest in differing the
packet sendings, so yes, I'm likely to deactivate the Nagle Algorithm.
Seems like on Linux they have added the TCP_CORK parameter to let the sender
decide when to send the data, bypassing the Nagle's algorithm completely, and
also solving the context switching pb at the same time (somehow it's a way to
say "you're responsability, not teh OS one", and I tend to agree). Sadly, this
is not portable, so currently it's not an option.
Last, not least, for TLS HS, Nagle's Algorithm is delaying the whole
negociation, which is a real PITA...
Issue Time Tracking
---
Worklog Id: (was: 918946)
Time Spent: 1h (was: 50m)
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFac
[jira] [Work logged] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=918930=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918930
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 11/May/24 16:40
Start Date: 11/May/24 16:40
Worklog Time Spent: 10m
Work Description: jon-valliere commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597475482
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
Disabling Nagle by default may create context switching performance hits in
certain applications. Any situation where you may invoke more than one write
in sequence, receives performance boosts from the way the IO scheduler works in
TCP because it can produce MORE packets in a single go and does not have to be
woken up as often. The OS itself does not disable Nagle by default and I do
not think we should make this decision for the end user. As long as they can
configure it, I think the default should be `unset` (to allow the OS default to
apply). If other applications, built on MINA, want to configure a new default
then it is up to them. For SSHD or Apache Directory, if you want to disable
Nagle there, that is fine.
Issue Time Tracking
---
Worklog Id: (was: 918930)
Time Spent: 50m (was: 40m)
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
>
[jira] [Work logged] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=918929=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918929
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 11/May/24 16:21
Start Date: 11/May/24 16:21
Worklog Time Spent: 10m
Work Description: elecharny commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597473106
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
Hi @jon-valliere, just read this blog post:
https://brooker.co.za/blog/2024/05/09/nagle.html
Somehow, Nagle's algorithm is a thing of the past (ie when we were dealing
with terminals over slow connections). In MINA's context, and if we except
SSHD, I do think that the default to disable Nagle's algorithm actually makes
sense. Most of MINA based application don't deal with char by char
communication, rather with quite big chunks of data, so there is little need to
wait for an ACK from the server.
Anyway, this is configurable, so I guess it should not be a big deal.
Issue Time Tracking
---
Worklog Id: (was: 918929)
Time Spent: 40m (was: 0.5h)
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e mu
[jira] [Work logged] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=918927=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918927
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 11/May/24 13:44
Start Date: 11/May/24 13:44
Worklog Time Spent: 10m
Work Description: jon-valliere commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597451055
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
Hey @elecharny I'm not sure this is a good idea. If we want todo this also,
I think it should be as part of a separate PR.
Issue Time Tracking
---
Worklog Id: (was: 918927)
Time Spent: 0.5h (was: 20m)
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.e
[jira] [Work logged] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=918926=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918926
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 11/May/24 13:43
Start Date: 11/May/24 13:43
Worklog Time Spent: 10m
Work Description: jon-valliere commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597451055
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
Hey @elecharny I'm not sure this is a good idea
Issue Time Tracking
---
Worklog Id: (was: 918926)
Time Spent: 20m (was: 10m)
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.executorFilter);
> connector.getFilterChain().addLast("gpbMessageFilter&
[jira] [Resolved] (SSHD-1237) SftpClient logs warnings on keepalive messages
[
https://issues.apache.org/jira/browse/SSHD-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf resolved SSHD-1237.
---
Fix Version/s: 2.13.0
Resolution: Fixed
PR 492 merged.
> SftpClient logs warnings on keepalive messages
> --
>
> Key: SSHD-1237
> URL: https://issues.apache.org/jira/browse/SSHD-1237
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Jens Grassel
>Assignee: Lyor Goldstein
>Priority: Minor
> Fix For: 2.13.0
>
>
> Hi,
> we just noticed that using the default SshClient we get lots of warning
> messages in our logs about keep alive requests like this:
> {noformat}
> 08:55:32.122 [sshd-SshClient[40b05dd]-nio2-thread-2] WARN
> o.a.s.s.c.i.DefaultSftpClient$SftpChannelSubsystem -
> handleUnknownChannelRequest(SftpChannelSubsystem[id=0,
> recipient=0]-ClientSessionImpl[XXX@XXX/XXX:22][sftp]) Unknown channel
> request: keepal...@openssh.com[want-reply=true]
> {noformat}
> We're using the {{SshClient.setUpDefaultClient()}} function then create our
> session and finally use the {{createSftpClient(session)}} function on a
> SftpClientFactory.
--
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] [Created] (SSHD-1340) SSH Certificate support
Sreedhar J created SSHD-1340: Summary: SSH Certificate support Key: SSHD-1340 URL: https://issues.apache.org/jira/browse/SSHD-1340 Project: MINA SSHD Issue Type: Question Reporter: Sreedhar J is Apache SSHD/SFTP Server support SSH Certificates? If yes, please provide the details. looks like openssh supports Certificate based authentication. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication -- 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] [Commented] (SSHD-1339) Available keys,values in map to FileSystems.newFileSystem(URI,Map) ?
[
https://issues.apache.org/jira/browse/SSHD-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833285#comment-17833285
]
dgü commented on SSHD-1339:
---
If I can pass password in the _Map_ argument, I will not have to pass passwords
in {_}URI{_}.
> Available keys,values in map to FileSystems.newFileSystem(URI,Map) ?
>
>
> Key: SSHD-1339
> URL: https://issues.apache.org/jira/browse/SSHD-1339
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.9.1
>Reporter: dgü
>Priority: Major
>
> Hello!
> I create file systems as below:
> {code:java}
> URI uri = new URI("sftp://deneme:deneme123@127.0.0.1:22;);
> try (FileSystem fs = FileSystems.newFileSystem(uri,
> Collections.emptyMap())) {
> //...
> }{code}
> Which keys,values in map argument can be passed to
> _FileSystems.newFileSystem(...)_ above ?
> 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] [Created] (SSHD-1339) Available keys,values in map to FileSystems.newFileSystem(URI,Map) ?
dgü created SSHD-1339:
-
Summary: Available keys,values in map to
FileSystems.newFileSystem(URI,Map) ?
Key: SSHD-1339
URL: https://issues.apache.org/jira/browse/SSHD-1339
Project: MINA SSHD
Issue Type: Question
Affects Versions: 2.9.1
Reporter: dgü
Hello!
I create file systems as below:
{code:java}
URI uri = new URI("sftp://deneme:deneme123@127.0.0.1:22;);
try (FileSystem fs = FileSystems.newFileSystem(uri,
Collections.emptyMap())) {
//...
}{code}
Which keys,values in map argument can be passed to
_FileSystems.newFileSystem(...)_ above ?
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] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822891#comment-17822891
]
Eissam Yassin commented on DIRMINA-1176:
Hi [~johnnyv]
The consumer is waiting for incoming messages.
Regards,
Eissam
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
> at
> com.bmc.ctms.common.services.Service$3.handleEvent(Service.java:358)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.handleSubscriberEntryEvent(EventDispatcher.java:687)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publishByUniqeID(EventDispatcher.java:673)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publish(EventDispatcher.java:694)
> a
[jira] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822127#comment-17822127
]
Jonathan Valliere commented on DIRMINA-1176:
How sure are you that the consumer of these messages isn’t the problem?
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
> at
> com.bmc.ctms.common.services.Service$3.handleEvent(Service.java:358)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.handleSubscriberEntryEvent(EventDispatcher.java:687)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publishByUniqeID(EventDispatcher.java:673)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publish(EventDispatcher.java:694)
> a
[jira] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822115#comment-17822115
]
Eissam Yassin commented on DIRMINA-1176:
Hi [~johnnyv]
Thanks for your response.
Our code checks the number of wait messages returned by
IoSession.getScheduledWriteMessages().
We stop writing messages when the return number exceeds a threshold (4000).
We saw in our customers environment that this number increased to about 5000
and we stopped writing. The number remains steady about 5000 for long time
(hour) until we restarted the application.
Regards,
Eissam
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
> at
> com.bmc.ctms.common.services.Service$3.handleEvent(Service.java:358)
> at
> com.bmc.ctms.infra.
[jira] [Commented] (DIRMINA-1146) TLS enabled session got disconnected when outbound messages add up to the value of maxscheduledwriterequests
[ https://issues.apache.org/jira/browse/DIRMINA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822114#comment-17822114 ] Eissam Yassin commented on DIRMINA-1146: Hi [~johnnyv] We do not have an independent runnable with the problem reproduced in it. The problem was reproduced consistently in a customer environment. I the lab we could reproduce it intermittently with full of installation of our products. Regards, Eissam > TLS enabled session got disconnected when outbound messages add up to the > value of maxscheduledwriterequests > > > Key: DIRMINA-1146 > URL: https://issues.apache.org/jira/browse/DIRMINA-1146 > Project: MINA > Issue Type: Bug >Reporter: Chily >Assignee: Jonathan Valliere >Priority: Blocker > Fix For: 2.2.2 > > Attachments: ConnectionEndPointIoHandler.java, > EmDsectProtocolIoHandlare.java > > > Slow Consumer Protection Feature does not work on TLS enabled session > -> ioSession.getScheduledWriteMessages() never decreases in > IoSessionResponder#send method > internal.engine.session.maxscheduledwriterequests=1 > Our TLS enabled session got disconneced when the outbound messages added up > to 1. > -- 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] [Commented] (DIRMINA-1132) TLSv1.3 - MINA randomly fails in reading the message sent by client
[
https://issues.apache.org/jira/browse/DIRMINA-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821986#comment-17821986
]
Eissam Yassin commented on DIRMINA-1132:
Many Thanks [~johnnyv] for the update
> TLSv1.3 - MINA randomly fails in reading the message sent by client
> ---
>
> Key: DIRMINA-1132
> URL: https://issues.apache.org/jira/browse/DIRMINA-1132
> Project: MINA
> Issue Type: Bug
> Components: Core, SSL
>Affects Versions: 2.0.21
> Environment: Operating System: Windows 10 1903
> Java Version: jdk-11.0.7, jdk-12.0.2
>Reporter: Venkata Kishore Tavva
>Assignee: Jonathan Valliere
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: console.log, example-project.zip, keyStore.pfx,
> trustStore.pfx
>
>
> While trying to Implement TLSv1.3 in our systems, we found an issue with Mina
> Core dependency. For TLSv1.2 we never had the issue. But with TLSv1.3,
> randomly the message sent by the client is discarded. In such scenarios, the
> server waits for session to pass idle timeout and closes the session. Please
> find the sample code below:
> {code:java}
> import org.apache.mina.core.service.IoHandlerAdapter;
> import org.apache.mina.core.session.IdleStatus;
> import org.apache.mina.core.session.IoSession;
> import org.apache.mina.filter.ssl.SslFilter;
> import org.apache.mina.transport.socket.SocketAcceptor;
> import org.apache.mina.transport.socket.nio.NioSocketAcceptor;
> import javax.net.ssl.*;
> import java.io.*;
> import java.net.InetSocketAddress;
> import java.security.KeyStore;
> public class Main {
>public static void main(String[] args) throws Exception {
> System.setProperty("javax.net.debug","all");
> KeyManagerFactory keyManagerFactory;
> try(FileInputStream fis = new FileInputStream("keyStore.pfx")) {
> keyManagerFactory =
> KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
> KeyStore keyStore = KeyStore.getInstance("PKCS12");
> keyStore.load(fis, "passphrase".toCharArray());
> keyManagerFactory.init(keyStore, "passphrase".toCharArray());
> }
> TrustManagerFactory trustManagerFactory;
> try(FileInputStream fis = new FileInputStream("trustStore.pfx")){
> trustManagerFactory = TrustManagerFactory.getInstance("SunX509");
> KeyStore trustStore = KeyStore.getInstance("PKCS12");
> trustStore.load(fis, "passphrase".toCharArray());
> trustManagerFactory.init(trustStore);
> }
> SSLContext context = SSLContext.getInstance("TLSv1.3");
> context.init(keyManagerFactory.getKeyManagers(),
> trustManagerFactory.getTrustManagers(), null);
> SslFilter filter = new SslFilter(context);
> filter.setEnabledProtocols(new String[]{"TLSv1.3"});
> filter.setEnabledCipherSuites(new String[]{"TLS_AES_128_GCM_SHA256",
> "TLS_AES_256_GCM_SHA384"});
> SocketAcceptor acceptor = new NioSocketAcceptor();
> acceptor.setReuseAddress(true);
> acceptor.getFilterChain().addLast("sslFilter", filter);
> acceptor.setHandler( new ServerHandler());
> acceptor.bind(new InetSocketAddress(53001));
> System.out.println("Server started on Port : 53001");
> System.out.println("Start sending data using cUrl below:");
> System.out.println("-> curl --location --insecure --tlsv1.3 --ipv4
> 'https://localhost:53001' --data-raw 'Sample Text'");
>}
> }
> class ServerHandler extends IoHandlerAdapter {
>@Override
>public void sessionCreated(IoSession session) {
> System.out.println( "\nSession created : " + session);
>}
>@Override
>public void sessionOpened(IoSession session) {
> System.out.println( "Session opened : " + session);
> session.getConfig().setIdleTime(IdleStatus.BOTH_IDLE, 60);
>}
>@Override
>public void sessionClosed(IoSession session) {
> System.out.println( "Session closed : " + session);
> session.closeNow();
>}
>@Override
>public void sessionIdle(IoSession session, IdleStatus status) {
> System.out.println( "==" );
> System.out.println( "Session is idle for 60 secs hence closing session:
> " + session.getRemoteAddress());
[jira] [Resolved] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Valliere resolved DIRMINA-1176.
Resolution: Not A Problem
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
> at
> com.bmc.ctms.common.services.Service$3.handleEvent(Service.java:358)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.handleSubscriberEntryEvent(EventDispatcher.java:687)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publishByUniqeID(EventDispatcher.java:673)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publish(EventDispatcher.java:694)
> at
> com.bmc.ctms.infra.EventDispatcher.publish(EventDispatcher.java:194)
> at
[jira] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821233#comment-17821233
]
Jonathan Valliere commented on DIRMINA-1176:
@[~eissam_yassin] this is not a bug, this is caused by your application not
performing any flow control on the messages that it is sending to the peer.
Think of it like water flowing through pipes, if you have an 8cm diameter pipe
and I have a 2cm diameter pipe the water is only going to go as fast as the 2cm
pipe will allow.
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
> at
> com.bmc.ctms.common.services.Service$3.handleEvent(Service.java:358)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.handleSubscriberE
[jira] [Comment Edited] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821229#comment-17821229
]
Jonathan Valliere edited comment on DIRMINA-1176 at 2/27/24 1:16 PM:
-
[~elecharny] the hard limit was to prevent memory leaks which would normally be
handled by the max enqueued messages on the IoSession. The idea here is that
we want to perform flow control at the SSL and not waste CPU cycles encrypting
messages which will simply be queued for write because the writer speed is
exceeding the reader. A perfect example of this is: if you want to download a
5GB file, you don't encrypt the entire file then write to the socket, you grab
pieces of it.
was (Author: johnnyv):
[~elecharny] the hard limit was to prevent memory leaks which would normally be
handled by the max enqueued messages on the IoSession. The idea here is that
we want to perform flow control at the SSL and not waste CPU cycles encrypting
messages which will simply be queued for write because the writer speed is
exceeding the reader.
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
>
[jira] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821229#comment-17821229
]
Jonathan Valliere commented on DIRMINA-1176:
[~elecharny] the hard limit was to prevent memory leaks which would normally be
handled by the max enqueued messages on the IoSession. The idea here is that
we want to perform flow control at the SSL and not waste CPU cycles encrypting
messages which will simply be queued for write because the writer speed is
exceeding the reader.
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
> at
> com.bmc.ctms.common.services.Service$3.handleEvent(Service.java:358)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.handleSubscriberE
[jira] [Resolved] (DIRMINA-1132) TLSv1.3 - MINA randomly fails in reading the message sent by client
[
https://issues.apache.org/jira/browse/DIRMINA-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Valliere resolved DIRMINA-1132.
Resolution: Fixed
This was fixed as part of the SSL rewrite for 2.2
> TLSv1.3 - MINA randomly fails in reading the message sent by client
> ---
>
> Key: DIRMINA-1132
> URL: https://issues.apache.org/jira/browse/DIRMINA-1132
> Project: MINA
> Issue Type: Bug
> Components: Core, SSL
>Affects Versions: 2.0.21
> Environment: Operating System: Windows 10 1903
> Java Version: jdk-11.0.7, jdk-12.0.2
>Reporter: Venkata Kishore Tavva
>Assignee: Jonathan Valliere
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: console.log, example-project.zip, keyStore.pfx,
> trustStore.pfx
>
>
> While trying to Implement TLSv1.3 in our systems, we found an issue with Mina
> Core dependency. For TLSv1.2 we never had the issue. But with TLSv1.3,
> randomly the message sent by the client is discarded. In such scenarios, the
> server waits for session to pass idle timeout and closes the session. Please
> find the sample code below:
> {code:java}
> import org.apache.mina.core.service.IoHandlerAdapter;
> import org.apache.mina.core.session.IdleStatus;
> import org.apache.mina.core.session.IoSession;
> import org.apache.mina.filter.ssl.SslFilter;
> import org.apache.mina.transport.socket.SocketAcceptor;
> import org.apache.mina.transport.socket.nio.NioSocketAcceptor;
> import javax.net.ssl.*;
> import java.io.*;
> import java.net.InetSocketAddress;
> import java.security.KeyStore;
> public class Main {
>public static void main(String[] args) throws Exception {
> System.setProperty("javax.net.debug","all");
> KeyManagerFactory keyManagerFactory;
> try(FileInputStream fis = new FileInputStream("keyStore.pfx")) {
> keyManagerFactory =
> KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
> KeyStore keyStore = KeyStore.getInstance("PKCS12");
> keyStore.load(fis, "passphrase".toCharArray());
> keyManagerFactory.init(keyStore, "passphrase".toCharArray());
> }
> TrustManagerFactory trustManagerFactory;
> try(FileInputStream fis = new FileInputStream("trustStore.pfx")){
> trustManagerFactory = TrustManagerFactory.getInstance("SunX509");
> KeyStore trustStore = KeyStore.getInstance("PKCS12");
> trustStore.load(fis, "passphrase".toCharArray());
> trustManagerFactory.init(trustStore);
> }
> SSLContext context = SSLContext.getInstance("TLSv1.3");
> context.init(keyManagerFactory.getKeyManagers(),
> trustManagerFactory.getTrustManagers(), null);
> SslFilter filter = new SslFilter(context);
> filter.setEnabledProtocols(new String[]{"TLSv1.3"});
> filter.setEnabledCipherSuites(new String[]{"TLS_AES_128_GCM_SHA256",
> "TLS_AES_256_GCM_SHA384"});
> SocketAcceptor acceptor = new NioSocketAcceptor();
> acceptor.setReuseAddress(true);
> acceptor.getFilterChain().addLast("sslFilter", filter);
> acceptor.setHandler( new ServerHandler());
> acceptor.bind(new InetSocketAddress(53001));
> System.out.println("Server started on Port : 53001");
> System.out.println("Start sending data using cUrl below:");
> System.out.println("-> curl --location --insecure --tlsv1.3 --ipv4
> 'https://localhost:53001' --data-raw 'Sample Text'");
>}
> }
> class ServerHandler extends IoHandlerAdapter {
>@Override
>public void sessionCreated(IoSession session) {
> System.out.println( "\nSession created : " + session);
>}
>@Override
>public void sessionOpened(IoSession session) {
> System.out.println( "Session opened : " + session);
> session.getConfig().setIdleTime(IdleStatus.BOTH_IDLE, 60);
>}
>@Override
>public void sessionClosed(IoSession session) {
> System.out.println( "Session closed : " + session);
> session.closeNow();
>}
>@Override
>public void sessionIdle(IoSession session, IdleStatus status) {
> System.out.println( "==" );
> System.out.println( "Session is idle for 60 secs hence closing session:
> " + session.getRemoteAddress());
[jira] [Commented] (DIRMINA-1146) TLS enabled session got disconnected when outbound messages add up to the value of maxscheduledwriterequests
[ https://issues.apache.org/jira/browse/DIRMINA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821223#comment-17821223 ] Jonathan Valliere commented on DIRMINA-1146: [~eissam_yassin] I see the attached code but do you have a runnable example which reproduces this problem? > TLS enabled session got disconnected when outbound messages add up to the > value of maxscheduledwriterequests > > > Key: DIRMINA-1146 > URL: https://issues.apache.org/jira/browse/DIRMINA-1146 > Project: MINA > Issue Type: Bug >Reporter: Chily >Assignee: Jonathan Valliere >Priority: Blocker > Fix For: 2.2.2 > > Attachments: ConnectionEndPointIoHandler.java, > EmDsectProtocolIoHandlare.java > > > Slow Consumer Protection Feature does not work on TLS enabled session > -> ioSession.getScheduledWriteMessages() never decreases in > IoSessionResponder#send method > internal.engine.session.maxscheduledwriterequests=1 > Our TLS enabled session got disconneced when the outbound messages added up > to 1. > -- 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-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=906344=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-906344
]
ASF GitHub Bot logged work on DIRMINA-1173:
---
Author: ASF GitHub Bot
Created on: 22/Feb/24 03:02
Start Date: 22/Feb/24 03:02
Worklog Time Spent: 10m
Work Description: jon-valliere opened a new pull request, #44:
URL: https://github.com/apache/mina/pull/44
(no comment)
Issue Time Tracking
---
Worklog Id: (was: 906344)
Remaining Estimate: 0h
Time Spent: 10m
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.executorFilter);
> connector.getFilterChain().addLast("gpbMessageFilter",
> G10CaptureService.gpbMessageFilter);
> connector.getFilterChain().addLast("keepAliveFilter",
> G10CaptureService.keepAliveFilter);
> connector.setHandler(ioHandler);
> }
>
> public void StartRecordCapture()
> {
> connectionLock.lock();
> try
> {
> ConnectFuture primaryConnectFuture = connector.connect(primaryAddress,
> initializer);
> //hungs forever if the no. of threads are more
[jira] [Commented] (DIRMINA-963) Socks5 and ProxyConnector don't work with InetSocketAddress.createUnresolved
[
https://issues.apache.org/jira/browse/DIRMINA-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815906#comment-17815906
]
Jonathan Valliere commented on DIRMINA-963:
---
I can try to look at this sometime in the next couple of weeks. However, it
clearly looks like this isn't a problem for many people given how old this
ticket is.
> Socks5 and ProxyConnector don't work with InetSocketAddress.createUnresolved
>
>
> Key: DIRMINA-963
> URL: https://issues.apache.org/jira/browse/DIRMINA-963
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.7
>Reporter: Daniele guiducci
>Assignee: Jonathan Valliere
>Priority: Major
> Labels: InetSocketAddress, bug, proxy, socks
>
> I'm tring to use Tor to connect using proxy (SOCKS5).
> InetSocketAddress resolve dns without use Tor, so i can not use in production.
> To use tor to resolve dns i must use InetSocketAddress.createUnresolved.
> java.net.Socket work perfectly also with .onion url.
> {code}
> public static void main(String[] args) throws Exception{
> NioSocketConnector nioConnector=new NioSocketConnector();
> nioConnector.setConnectTimeoutMillis(6);
> SocksProxyRequest pr = new SocksProxyRequest(
> SocksProxyConstants.SOCKS_VERSION_5,
> SocksProxyConstants.ESTABLISH_TCPIP_STREAM,
> new InetSocketAddress("www.google.com", 80), "");
> ProxyIoSession ps=new ProxyIoSession(new
> InetSocketAddress("127.0.0.1", 9050), pr);
> ProxyConnector connector=new ProxyConnector(nioConnector);
> connector.getFilterChain().addLast("logger", new LoggingFilter());
> connector.setProxyIoSession(ps);
> connector.setHandler(new MyHandler());
> ConnectFuture cf=connector.connect();
> IoSession session=cf.getSession();
> session.getCloseFuture().awaitUninterruptibly();
> cf.awaitUninterruptibly();
>Thread.sleep(4);
> }
> private static class MyHandler extends AbstractProxyIoHandler {
> @Override
> public void proxySessionOpened(IoSession session) {
> System.out.println("ProxySession aperta");
> session.write(IoBuffer.wrap("GET / HTTP/1.0\n\n".getBytes()));
> }
> @Override
> public void messageReceived(IoSession session, Object msg) {
> System.out.println("Data:"+new String(((IoBuffer)msg).array()));
> }
> @Override
> public void exceptionCaught(IoSession session, Throwable cause)
> throws Exception {
> System.out.println("Error: "+cause);
> }
> }
> {code}
> ===
> {code}
> public static void main(String[] args) throws Exception{
> NioSocketConnector nioConnector=new NioSocketConnector();
> nioConnector.setConnectTimeoutMillis(6);
> SocksProxyRequest pr = new SocksProxyRequest(
> SocksProxyConstants.SOCKS_VERSION_5,
> SocksProxyConstants.ESTABLISH_TCPIP_STREAM,
> InetSocketAddress.createUnresolved("www.google.com", 80),
> "");
> ProxyIoSession ps=new ProxyIoSession(new
> InetSocketAddress("127.0.0.1", 9050), pr);
> ProxyConnector connector=new ProxyConnector(nioConnector);
> connector.getFilterChain().addLast("logger", new LoggingFilter());
> connector.setProxyIoSession(ps);
> connector.setHandler(new MyHandler());
> ConnectFuture cf=connector.connect();
> IoSession session=cf.getSession();
> session.getCloseFuture().awaitUninterruptibly();
> cf.awaitUninterruptibly();
>Thread.sleep(4);
> }
> private static class MyHandler extends AbstractProxyIoHandler {
> @Override
> public void proxySessionOpened(IoSession session) {
> System.out.println("ProxySession aperta");
> session.write(IoBuffer.wrap("GET / HTTP/1.0\n\n".getBytes()));
> }
> @Override
> public void messageReceived(IoSession session, Object msg) {
> System.out.println("Data:"+new String(((IoBuffer)msg).array()));
> }
> @Override
> public void exceptionCaught(IoSession session, Throwable cause)
> throws Exce
[jira] [Commented] (DIRMINA-963) Socks5 and ProxyConnector don't work with InetSocketAddress.createUnresolved
[
https://issues.apache.org/jira/browse/DIRMINA-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813720#comment-17813720
]
Christoph John commented on DIRMINA-963:
I am no project maintainer of MINA (but QuickFIX/J) but I guess your best bet
is to change the code by yourself (and optionally create a pull request),
build, and use that version with QFJ.
> Socks5 and ProxyConnector don't work with InetSocketAddress.createUnresolved
>
>
> Key: DIRMINA-963
> URL: https://issues.apache.org/jira/browse/DIRMINA-963
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.7
>Reporter: Daniele guiducci
>Assignee: Jonathan Valliere
>Priority: Major
> Labels: InetSocketAddress, bug, proxy, socks
>
> I'm tring to use Tor to connect using proxy (SOCKS5).
> InetSocketAddress resolve dns without use Tor, so i can not use in production.
> To use tor to resolve dns i must use InetSocketAddress.createUnresolved.
> java.net.Socket work perfectly also with .onion url.
> {code}
> public static void main(String[] args) throws Exception{
> NioSocketConnector nioConnector=new NioSocketConnector();
> nioConnector.setConnectTimeoutMillis(6);
> SocksProxyRequest pr = new SocksProxyRequest(
> SocksProxyConstants.SOCKS_VERSION_5,
> SocksProxyConstants.ESTABLISH_TCPIP_STREAM,
> new InetSocketAddress("www.google.com", 80), "");
> ProxyIoSession ps=new ProxyIoSession(new
> InetSocketAddress("127.0.0.1", 9050), pr);
> ProxyConnector connector=new ProxyConnector(nioConnector);
> connector.getFilterChain().addLast("logger", new LoggingFilter());
> connector.setProxyIoSession(ps);
> connector.setHandler(new MyHandler());
> ConnectFuture cf=connector.connect();
> IoSession session=cf.getSession();
> session.getCloseFuture().awaitUninterruptibly();
> cf.awaitUninterruptibly();
>Thread.sleep(4);
> }
> private static class MyHandler extends AbstractProxyIoHandler {
> @Override
> public void proxySessionOpened(IoSession session) {
> System.out.println("ProxySession aperta");
> session.write(IoBuffer.wrap("GET / HTTP/1.0\n\n".getBytes()));
> }
> @Override
> public void messageReceived(IoSession session, Object msg) {
> System.out.println("Data:"+new String(((IoBuffer)msg).array()));
> }
> @Override
> public void exceptionCaught(IoSession session, Throwable cause)
> throws Exception {
> System.out.println("Error: "+cause);
> }
> }
> {code}
> ===
> {code}
> public static void main(String[] args) throws Exception{
> NioSocketConnector nioConnector=new NioSocketConnector();
> nioConnector.setConnectTimeoutMillis(6);
> SocksProxyRequest pr = new SocksProxyRequest(
> SocksProxyConstants.SOCKS_VERSION_5,
> SocksProxyConstants.ESTABLISH_TCPIP_STREAM,
> InetSocketAddress.createUnresolved("www.google.com", 80),
> "");
> ProxyIoSession ps=new ProxyIoSession(new
> InetSocketAddress("127.0.0.1", 9050), pr);
> ProxyConnector connector=new ProxyConnector(nioConnector);
> connector.getFilterChain().addLast("logger", new LoggingFilter());
> connector.setProxyIoSession(ps);
> connector.setHandler(new MyHandler());
> ConnectFuture cf=connector.connect();
> IoSession session=cf.getSession();
> session.getCloseFuture().awaitUninterruptibly();
> cf.awaitUninterruptibly();
>Thread.sleep(4);
> }
> private static class MyHandler extends AbstractProxyIoHandler {
> @Override
> public void proxySessionOpened(IoSession session) {
> System.out.println("ProxySession aperta");
> session.write(IoBuffer.wrap("GET / HTTP/1.0\n\n".getBytes()));
> }
> @Override
> public void messageReceived(IoSession session, Object msg) {
> System.out.println("Data:"+new String(((IoBuffer)msg).array()));
> }
> @Override
> public void exceptionCaught(IoSession session, Throwable caus
[jira] [Commented] (DIRMINA-963) Socks5 and ProxyConnector don't work with InetSocketAddress.createUnresolved
[
https://issues.apache.org/jira/browse/DIRMINA-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813617#comment-17813617
]
Beate Pomahatsch commented on DIRMINA-963:
--
We faced this issue just recently and it makes me wonder that this issue has
not been resolved since 2012. Isn't there anyone else using Quickfix/J with
Socks5-Proxy and no local dns resolution for external addresses?
> Socks5 and ProxyConnector don't work with InetSocketAddress.createUnresolved
>
>
> Key: DIRMINA-963
> URL: https://issues.apache.org/jira/browse/DIRMINA-963
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.7
>Reporter: Daniele guiducci
>Assignee: Jonathan Valliere
>Priority: Major
> Labels: InetSocketAddress, bug, proxy, socks
>
> I'm tring to use Tor to connect using proxy (SOCKS5).
> InetSocketAddress resolve dns without use Tor, so i can not use in production.
> To use tor to resolve dns i must use InetSocketAddress.createUnresolved.
> java.net.Socket work perfectly also with .onion url.
> {code}
> public static void main(String[] args) throws Exception{
> NioSocketConnector nioConnector=new NioSocketConnector();
> nioConnector.setConnectTimeoutMillis(6);
> SocksProxyRequest pr = new SocksProxyRequest(
> SocksProxyConstants.SOCKS_VERSION_5,
> SocksProxyConstants.ESTABLISH_TCPIP_STREAM,
> new InetSocketAddress("www.google.com", 80), "");
> ProxyIoSession ps=new ProxyIoSession(new
> InetSocketAddress("127.0.0.1", 9050), pr);
> ProxyConnector connector=new ProxyConnector(nioConnector);
> connector.getFilterChain().addLast("logger", new LoggingFilter());
> connector.setProxyIoSession(ps);
> connector.setHandler(new MyHandler());
> ConnectFuture cf=connector.connect();
> IoSession session=cf.getSession();
> session.getCloseFuture().awaitUninterruptibly();
> cf.awaitUninterruptibly();
>Thread.sleep(4);
> }
> private static class MyHandler extends AbstractProxyIoHandler {
> @Override
> public void proxySessionOpened(IoSession session) {
> System.out.println("ProxySession aperta");
> session.write(IoBuffer.wrap("GET / HTTP/1.0\n\n".getBytes()));
> }
> @Override
> public void messageReceived(IoSession session, Object msg) {
> System.out.println("Data:"+new String(((IoBuffer)msg).array()));
> }
> @Override
> public void exceptionCaught(IoSession session, Throwable cause)
> throws Exception {
> System.out.println("Error: "+cause);
> }
> }
> {code}
> ===
> {code}
> public static void main(String[] args) throws Exception{
> NioSocketConnector nioConnector=new NioSocketConnector();
> nioConnector.setConnectTimeoutMillis(6);
> SocksProxyRequest pr = new SocksProxyRequest(
> SocksProxyConstants.SOCKS_VERSION_5,
> SocksProxyConstants.ESTABLISH_TCPIP_STREAM,
> InetSocketAddress.createUnresolved("www.google.com", 80),
> "");
> ProxyIoSession ps=new ProxyIoSession(new
> InetSocketAddress("127.0.0.1", 9050), pr);
> ProxyConnector connector=new ProxyConnector(nioConnector);
> connector.getFilterChain().addLast("logger", new LoggingFilter());
> connector.setProxyIoSession(ps);
> connector.setHandler(new MyHandler());
> ConnectFuture cf=connector.connect();
> IoSession session=cf.getSession();
> session.getCloseFuture().awaitUninterruptibly();
> cf.awaitUninterruptibly();
>Thread.sleep(4);
> }
> private static class MyHandler extends AbstractProxyIoHandler {
> @Override
> public void proxySessionOpened(IoSession session) {
> System.out.println("ProxySession aperta");
> session.write(IoBuffer.wrap("GET / HTTP/1.0\n\n".getBytes()));
> }
> @Override
> public void messageReceived(IoSession session, Object msg) {
> System.out.println("Data:"+new String(((IoBuffer)msg).array()));
> }
> @Override
> public v
[jira] [Closed] (SSHD-1338) SSHD 2.12 not binary compatible with JGIT 5.13
[
https://issues.apache.org/jira/browse/SSHD-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed SSHD-1338.
-
Resolution: Fixed
> SSHD 2.12 not binary compatible with JGIT 5.13
> --
>
> Key: SSHD-1338
> URL: https://issues.apache.org/jira/browse/SSHD-1338
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Tomas Hofman
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.12.1
>
>
> Current version of SSHD still contains a dependency on JGIT 5.13. This is to
> keep SSHD compatible with Java 1.8, as JGIT 6.x requires Java 11.
> However SSHD 2.12 is not binary compatible with 2.9.x versions, which is the
> version that JGIT 5.13.x were build against. The result is that when SSHD
> 2.12 and JGIT 5.13 are used together, one can get NoSuchMethodErrors like
> here:
> {code}
> Caused by: java.lang.NoSuchMethodError: 'java.lang.Object
> org.apache.sshd.client.future.ConnectFuture.verify()'
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:189)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:142)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:99)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSessionFactory.getSession(SshdSessionFactory.java:235)
> {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] [Commented] (SSHD-1338) SSHD 2.12 not binary compatible with JGIT 5.13
[
https://issues.apache.org/jira/browse/SSHD-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809887#comment-17809887
]
Tomas Hofman commented on SSHD-1338:
The issues that I identified so far are around {{VerifiableFuture#verify(...)}}
methods:
https://github.com/apache/mina-sshd/compare/sshd-2.9.3...sshd-2.12.0#diff-2677740efc7588ab5882de60562ee8d2ae99db843052880ef8187747f87d2f1bL42
E.g. {{default T verify() throws IOException}} was changed to {{default T
verify(CancelOption... options) throws IOException}}, which is source
compatible, but not binary compatible.
> SSHD 2.12 not binary compatible with JGIT 5.13
> --
>
> Key: SSHD-1338
> URL: https://issues.apache.org/jira/browse/SSHD-1338
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Tomas Hofman
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.12.1
>
>
> Current version of SSHD still contains a dependency on JGIT 5.13. This is to
> keep SSHD compatible with Java 1.8, as JGIT 6.x requires Java 11.
> However SSHD 2.12 is not binary compatible with 2.9.x versions, which is the
> version that JGIT 5.13.x were build against. The result is that when SSHD
> 2.12 and JGIT 5.13 are used together, one can get NoSuchMethodErrors like
> here:
> {code}
> Caused by: java.lang.NoSuchMethodError: 'java.lang.Object
> org.apache.sshd.client.future.ConnectFuture.verify()'
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:189)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:142)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:99)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSessionFactory.getSession(SshdSessionFactory.java:235)
> {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] [Updated] (SSHD-1338) SSHD 2.12 not binary compatible with JGIT 5.13
[
https://issues.apache.org/jira/browse/SSHD-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated SSHD-1338:
--
Fix Version/s: 2.12.1
> SSHD 2.12 not binary compatible with JGIT 5.13
> --
>
> Key: SSHD-1338
> URL: https://issues.apache.org/jira/browse/SSHD-1338
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Tomas Hofman
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.12.1
>
>
> Current version of SSHD still contains a dependency on JGIT 5.13. This is to
> keep SSHD compatible with Java 1.8, as JGIT 6.x requires Java 11.
> However SSHD 2.12 is not binary compatible with 2.9.x versions, which is the
> version that JGIT 5.13.x were build against. The result is that when SSHD
> 2.12 and JGIT 5.13 are used together, one can get NoSuchMethodErrors like
> here:
> {code}
> Caused by: java.lang.NoSuchMethodError: 'java.lang.Object
> org.apache.sshd.client.future.ConnectFuture.verify()'
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:189)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:142)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:99)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSessionFactory.getSession(SshdSessionFactory.java:235)
> {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] [Assigned] (SSHD-1338) SSHD 2.12 not binary compatible with JGIT 5.13
[
https://issues.apache.org/jira/browse/SSHD-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned SSHD-1338:
-
Assignee: Guillaume Nodet
> SSHD 2.12 not binary compatible with JGIT 5.13
> --
>
> Key: SSHD-1338
> URL: https://issues.apache.org/jira/browse/SSHD-1338
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Tomas Hofman
>Assignee: Guillaume Nodet
>Priority: Major
>
> Current version of SSHD still contains a dependency on JGIT 5.13. This is to
> keep SSHD compatible with Java 1.8, as JGIT 6.x requires Java 11.
> However SSHD 2.12 is not binary compatible with 2.9.x versions, which is the
> version that JGIT 5.13.x were build against. The result is that when SSHD
> 2.12 and JGIT 5.13 are used together, one can get NoSuchMethodErrors like
> here:
> {code}
> Caused by: java.lang.NoSuchMethodError: 'java.lang.Object
> org.apache.sshd.client.future.ConnectFuture.verify()'
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:189)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:142)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:99)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSessionFactory.getSession(SshdSessionFactory.java:235)
> {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] [Created] (SSHD-1338) SSHD 2.12 not binary compatible with JGIT 5.13
Tomas Hofman created SSHD-1338:
--
Summary: SSHD 2.12 not binary compatible with JGIT 5.13
Key: SSHD-1338
URL: https://issues.apache.org/jira/browse/SSHD-1338
Project: MINA SSHD
Issue Type: Improvement
Reporter: Tomas Hofman
Current version of SSHD still contains a dependency on JGIT 5.13. This is to
keep SSHD compatible with Java 1.8, as JGIT 6.x requires Java 11.
However SSHD 2.12 is not binary compatible with 2.9.x versions, which is the
version that JGIT 5.13.x were build against. The result is that when SSHD 2.12
and JGIT 5.13 are used together, one can get NoSuchMethodErrors like here:
{code}
Caused by: java.lang.NoSuchMethodError: 'java.lang.Object
org.apache.sshd.client.future.ConnectFuture.verify()'
at
org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:189)
at
org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:142)
at
org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:99)
at
org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSessionFactory.getSession(SshdSessionFactory.java:235)
{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] [Commented] (DIRMINA-1177) The Connector will blocked when execute dispose, And multiple threads are leaking
[
https://issues.apache.org/jira/browse/DIRMINA-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804220#comment-17804220
]
Christoph John commented on DIRMINA-1177:
-
OK, maybe you should just test if a newer version solves your problem?!
> The Connector will blocked when execute dispose, And multiple threads are
> leaking
> -
>
> Key: DIRMINA-1177
> URL: https://issues.apache.org/jira/browse/DIRMINA-1177
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.13
>Reporter: Vegeta
>Priority: Major
> Attachments: RpcClien3.java, image-2024-01-08-16-53-27-846.png,
> image-2024-01-08-16-54-02-222.png, image-2024-01-08-16-58-34-700.png,
> stack_2023-07-02_22.log
>
>
> In an old project, a RpcClient using mina 2.0.13 version has a memory leak.
> After investigation, it was found that many NioProcessor and
> NioSocketConnector were not recycled, and the number of threads was
> continuously increasing (the traffic did not increase).
> Below is the RpcClient code used in the project. After reading, I also found
> some problems:
> [^RpcClien3.java]
> {code:java}
> new RpcClient3().start();{code}
> 1.session close is not right
> {code:java}
> RpcClient#close()
> future.getSession().close(false);
> // this future is ConnectFuture,not CloseFuture
> futureUInterrupt = future.awaitUninterruptibly(CONNECTOR_WORKER_TIMEOUT);
> {code}
> 2.RpcClient#close has concurrent calls
> {code:java}
> 1.RpcClient#startHealthCheck
> 2.RpcClient#activateConnectionSensor{code}
>
> But I still can't reproduce this problem, My leader want to locate the
> problem as much as possible before trying on the prod environment, such as
> updating the version, modifying session close to
> future.getSession().close(true) and wait().
> ps: The heap.prof file cannot be uploaded as it exceeds 60MB. this is a
> google drive link:
> [https://drive.google.com/file/d/14UBnhAF-7sdfYJsh7FMfKxx-dm0BqU9t/view?usp=drive_link]
> !image-2024-01-08-16-53-27-846.png!
> !image-2024-01-08-16-54-02-222.png!
> !image-2024-01-08-16-58-34-700.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] [Commented] (DIRMINA-1177) The Connector will blocked when execute dispose, And multiple threads are leaking
[
https://issues.apache.org/jira/browse/DIRMINA-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804217#comment-17804217
]
Vegeta commented on DIRMINA-1177:
-
Hi，I also saw this issue, and I thought it was very similar when I first saw
it. But I found that all of my NioProcessor Threads are in the RUNNABLE state,
not in the TIMED_WAITING state.
> The Connector will blocked when execute dispose, And multiple threads are
> leaking
> -
>
> Key: DIRMINA-1177
> URL: https://issues.apache.org/jira/browse/DIRMINA-1177
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.13
>Reporter: Vegeta
>Priority: Major
> Attachments: RpcClien3.java, image-2024-01-08-16-53-27-846.png,
> image-2024-01-08-16-54-02-222.png, image-2024-01-08-16-58-34-700.png,
> stack_2023-07-02_22.log
>
>
> In an old project, a RpcClient using mina 2.0.13 version has a memory leak.
> After investigation, it was found that many NioProcessor and
> NioSocketConnector were not recycled, and the number of threads was
> continuously increasing (the traffic did not increase).
> Below is the RpcClient code used in the project. After reading, I also found
> some problems:
> [^RpcClien3.java]
> {code:java}
> new RpcClient3().start();{code}
> 1.session close is not right
> {code:java}
> RpcClient#close()
> future.getSession().close(false);
> // this future is ConnectFuture,not CloseFuture
> futureUInterrupt = future.awaitUninterruptibly(CONNECTOR_WORKER_TIMEOUT);
> {code}
> 2.RpcClient#close has concurrent calls
> {code:java}
> 1.RpcClient#startHealthCheck
> 2.RpcClient#activateConnectionSensor{code}
>
> But I still can't reproduce this problem, My leader want to locate the
> problem as much as possible before trying on the prod environment, such as
> updating the version, modifying session close to
> future.getSession().close(true) and wait().
> ps: The heap.prof file cannot be uploaded as it exceeds 60MB. this is a
> google drive link:
> [https://drive.google.com/file/d/14UBnhAF-7sdfYJsh7FMfKxx-dm0BqU9t/view?usp=drive_link]
> !image-2024-01-08-16-53-27-846.png!
> !image-2024-01-08-16-54-02-222.png!
> !image-2024-01-08-16-58-34-700.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] [Commented] (DIRMINA-1177) The Connector will blocked when execute dispose, And multiple threads are leaking
[
https://issues.apache.org/jira/browse/DIRMINA-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804196#comment-17804196
]
Christoph John commented on DIRMINA-1177:
-
I am no maintainer of this project but was hit by a similar bug some years ago.
This sounds a bit like https://issues.apache.org/jira/browse/DIRMINA-1076
> The Connector will blocked when execute dispose, And multiple threads are
> leaking
> -
>
> Key: DIRMINA-1177
> URL: https://issues.apache.org/jira/browse/DIRMINA-1177
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.13
>Reporter: Vegeta
>Priority: Major
> Attachments: RpcClien3.java, image-2024-01-08-16-53-27-846.png,
> image-2024-01-08-16-54-02-222.png, image-2024-01-08-16-58-34-700.png,
> stack_2023-07-02_22.log
>
>
> In an old project, a RpcClient using mina 2.0.13 version has a memory leak.
> After investigation, it was found that many NioProcessor and
> NioSocketConnector were not recycled, and the number of threads was
> continuously increasing (the traffic did not increase).
> Below is the RpcClient code used in the project. After reading, I also found
> some problems:
> [^RpcClien3.java]
> {code:java}
> new RpcClient3().start();{code}
> 1.session close is not right
> {code:java}
> RpcClient#close()
> future.getSession().close(false);
> // this future is ConnectFuture,not CloseFuture
> futureUInterrupt = future.awaitUninterruptibly(CONNECTOR_WORKER_TIMEOUT);
> {code}
> 2.RpcClient#close has concurrent calls
> {code:java}
> 1.RpcClient#startHealthCheck
> 2.RpcClient#activateConnectionSensor{code}
>
> But I still can't reproduce this problem, My leader want to locate the
> problem as much as possible before trying on the prod environment, such as
> updating the version, modifying session close to
> future.getSession().close(true) and wait().
> ps: The heap.prof file cannot be uploaded as it exceeds 60MB. this is a
> google drive link:
> [https://drive.google.com/file/d/14UBnhAF-7sdfYJsh7FMfKxx-dm0BqU9t/view?usp=drive_link]
> !image-2024-01-08-16-53-27-846.png!
> !image-2024-01-08-16-54-02-222.png!
> !image-2024-01-08-16-58-34-700.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] [Updated] (DIRMINA-1177) The Connector will blocked when execute dispose, And multiple threads are leaking
[
https://issues.apache.org/jira/browse/DIRMINA-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vegeta updated DIRMINA-1177:
Attachment: RpcClien3.java
> The Connector will blocked when execute dispose, And multiple threads are
> leaking
> -
>
> Key: DIRMINA-1177
> URL: https://issues.apache.org/jira/browse/DIRMINA-1177
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.13
>Reporter: Vegeta
>Priority: Major
> Attachments: RpcClien3.java, image-2024-01-08-16-53-27-846.png,
> image-2024-01-08-16-54-02-222.png, image-2024-01-08-16-58-34-700.png,
> stack_2023-07-02_22.log
>
>
> In an old project, a RpcClient using mina 2.0.13 version has a memory leak.
> After investigation, it was found that many NioProcessor and
> NioSocketConnector were not recycled, and the number of threads was
> continuously increasing (the traffic did not increase).
> Below is the RpcClient code used in the project. After reading, I also found
> some problems:
> 1.session close is not right
>
> {code:java}
> RpcClient#close()
> future.getSession().close(false);
> // this future is ConnectFuture,not CloseFuture
> futureUInterrupt = future.awaitUninterruptibly(CONNECTOR_WORKER_TIMEOUT);
> {code}
> 2.RpcClient#close has concurrent calls
> {code:java}
> 1.RpcClient#startHealthCheck
> 2.RpcClient#activateConnectionSensor{code}
>
> But I still can't reproduce this problem, My leader want to locate the
> problem as much as possible before trying on the prod environment, such as
> updating the version, modifying session close to
> future.getSession().close(true) and wait().
> ps: The heap.prof file cannot be uploaded as it exceeds 60MB. this is a
> google drive link:
> https://drive.google.com/file/d/14UBnhAF-7sdfYJsh7FMfKxx-dm0BqU9t/view?usp=drive_link
> !image-2024-01-08-16-53-27-846.png!
> !image-2024-01-08-16-54-02-222.png!
> !image-2024-01-08-16-58-34-700.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] [Updated] (DIRMINA-1177) The Connector will blocked when execute dispose, And multiple threads are leaking
[
https://issues.apache.org/jira/browse/DIRMINA-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vegeta updated DIRMINA-1177:
Description:
In an old project, a RpcClient using mina 2.0.13 version has a memory leak.
After investigation, it was found that many NioProcessor and NioSocketConnector
were not recycled, and the number of threads was continuously increasing (the
traffic did not increase).
Below is the RpcClient code used in the project. After reading, I also found
some problems:
[^RpcClien3.java]
{code:java}
new RpcClient3().start();{code}
1.session close is not right
{code:java}
RpcClient#close()
future.getSession().close(false);
// this future is ConnectFuture,not CloseFuture
futureUInterrupt = future.awaitUninterruptibly(CONNECTOR_WORKER_TIMEOUT);
{code}
2.RpcClient#close has concurrent calls
{code:java}
1.RpcClient#startHealthCheck
2.RpcClient#activateConnectionSensor{code}
But I still can't reproduce this problem, My leader want to locate the problem
as much as possible before trying on the prod environment, such as updating the
version, modifying session close to future.getSession().close(true) and wait().
ps: The heap.prof file cannot be uploaded as it exceeds 60MB. this is a
google drive link:
[https://drive.google.com/file/d/14UBnhAF-7sdfYJsh7FMfKxx-dm0BqU9t/view?usp=drive_link]
!image-2024-01-08-16-53-27-846.png!
!image-2024-01-08-16-54-02-222.png!
!image-2024-01-08-16-58-34-700.png!
was:
In an old project, a RpcClient using mina 2.0.13 version has a memory leak.
After investigation, it was found that many NioProcessor and NioSocketConnector
were not recycled, and the number of threads was continuously increasing (the
traffic did not increase).
Below is the RpcClient code used in the project. After reading, I also found
some problems:
1.session close is not right
{code:java}
RpcClient#close()
future.getSession().close(false);
// this future is ConnectFuture,not CloseFuture
futureUInterrupt = future.awaitUninterruptibly(CONNECTOR_WORKER_TIMEOUT);
{code}
2.RpcClient#close has concurrent calls
{code:java}
1.RpcClient#startHealthCheck
2.RpcClient#activateConnectionSensor{code}
But I still can't reproduce this problem, My leader want to locate the problem
as much as possible before trying on the prod environment, such as updating the
version, modifying session close to future.getSession().close(true) and wait().
ps: The heap.prof file cannot be uploaded as it exceeds 60MB. this is a
google drive link:
https://drive.google.com/file/d/14UBnhAF-7sdfYJsh7FMfKxx-dm0BqU9t/view?usp=drive_link
!image-2024-01-08-16-53-27-846.png!
!image-2024-01-08-16-54-02-222.png!
!image-2024-01-08-16-58-34-700.png!
> The Connector will blocked when execute dispose, And multiple threads are
> leaking
> -
>
> Key: DIRMINA-1177
> URL: https://issues.apache.org/jira/browse/DIRMINA-1177
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.13
>Reporter: Vegeta
>Priority: Major
> Attachments: RpcClien3.java, image-2024-01-08-16-53-27-846.png,
> image-2024-01-08-16-54-02-222.png, image-2024-01-08-16-58-34-700.png,
> stack_2023-07-02_22.log
>
>
> In an old project, a RpcClient using mina 2.0.13 version has a memory leak.
> After investigation, it was found that many NioProcessor and
> NioSocketConnector were not recycled, and the number of threads was
> continuously increasing (the traffic did not increase).
> Below is the RpcClient code used in the project. After reading, I also found
> some problems:
> [^RpcClien3.java]
> {code:java}
> new RpcClient3().start();{code}
> 1.session close is not right
> {code:java}
> RpcClient#close()
> future.getSession().close(false);
> // this future is ConnectFuture,not CloseFuture
> futureUInterrupt = future.awaitUninterruptibly(CONNECTOR_WORKER_TIMEOUT);
> {code}
> 2.RpcClient#close has concurrent calls
> {code:java}
> 1.RpcClient#startHealthCheck
> 2.RpcClient#activateConnectionSensor{code}
>
> But I still can't reproduce this problem, My leader want to locate the
> problem as much as possible before trying on the prod environment, such as
> updating the version, modifying session close to
> future.getSession().close(true) and wait().
> ps: The heap.prof file cannot be uploaded as it exceeds 60MB. this is a
> google drive link:
> [https://drive.google.com/file/d/14UBnhAF-7sdfYJsh7FMfKxx-dm0BqU9t/view?usp=drive_link]
> !image-2024-01-08-16-53-27-846.png!
> !image-2024-01-08-16-54-02-222.png!
> !image-2024-01-08-16-58-34-700.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DIRMINA-1177) The Connector will blocked when execute dispose, And multiple threads are leaking
Vegeta created DIRMINA-1177:
---
Summary: The Connector will blocked when execute dispose, And
multiple threads are leaking
Key: DIRMINA-1177
URL: https://issues.apache.org/jira/browse/DIRMINA-1177
Project: MINA
Issue Type: Bug
Components: Core
Affects Versions: 2.0.13
Reporter: Vegeta
Attachments: image-2024-01-08-16-53-27-846.png,
image-2024-01-08-16-54-02-222.png, image-2024-01-08-16-58-34-700.png,
stack_2023-07-02_22.log
In an old project, a RpcClient using mina 2.0.13 version has a memory leak.
After investigation, it was found that many NioProcessor and NioSocketConnector
were not recycled, and the number of threads was continuously increasing (the
traffic did not increase).
Below is the RpcClient code used in the project. After reading, I also found
some problems:
1.session close is not right
{code:java}
RpcClient#close()
future.getSession().close(false);
// this future is ConnectFuture,not CloseFuture
futureUInterrupt = future.awaitUninterruptibly(CONNECTOR_WORKER_TIMEOUT);
{code}
2.RpcClient#close has concurrent calls
{code:java}
1.RpcClient#startHealthCheck
2.RpcClient#activateConnectionSensor{code}
But I still can't reproduce this problem, My leader want to locate the problem
as much as possible before trying on the prod environment, such as updating the
version, modifying session close to future.getSession().close(true) and wait().
ps: The heap.prof file cannot be uploaded as it exceeds 60MB. this is a
google drive link:
https://drive.google.com/file/d/14UBnhAF-7sdfYJsh7FMfKxx-dm0BqU9t/view?usp=drive_link
!image-2024-01-08-16-53-27-846.png!
!image-2024-01-08-16-54-02-222.png!
!image-2024-01-08-16-58-34-700.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] [Commented] (DIRMINA-1146) TLS enabled session got disconnected when outbound messages add up to the value of maxscheduledwriterequests
[ https://issues.apache.org/jira/browse/DIRMINA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17797879#comment-17797879 ] Eissam Yassin commented on DIRMINA-1146: Hello, [~elecharny] Any update on this issue? Many Thanks, Eissam Yassin > TLS enabled session got disconnected when outbound messages add up to the > value of maxscheduledwriterequests > > > Key: DIRMINA-1146 > URL: https://issues.apache.org/jira/browse/DIRMINA-1146 > Project: MINA > Issue Type: Bug >Reporter: Chily >Assignee: Jonathan Valliere >Priority: Blocker > Fix For: 2.2.2 > > Attachments: ConnectionEndPointIoHandler.java, > EmDsectProtocolIoHandlare.java > > > Slow Consumer Protection Feature does not work on TLS enabled session > -> ioSession.getScheduledWriteMessages() never decreases in > IoSessionResponder#send method > internal.engine.session.maxscheduledwriterequests=1 > Our TLS enabled session got disconneced when the outbound messages added up > to 1. > -- 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] [Commented] (DIRMINA-1146) TLS enabled session got disconnected when outbound messages add up to the value of maxscheduledwriterequests
[ https://issues.apache.org/jira/browse/DIRMINA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794057#comment-17794057 ] Eissam Yassin commented on DIRMINA-1146: Hi [~elecharny] Sorry for the delay. Here attached classes extending IoHandler used by our application: [^EmDsectProtocolIoHandlare.java] and [^ConnectionEndPointIoHandler.java] ConnectEndPointIoHandler extends IoHandlerAdapter EmDsectProtolcolIoHandler extends ConnectionEndPointIoHandler Looking forward to hear from you. Many Thanks, Eissam Yassin > TLS enabled session got disconnected when outbound messages add up to the > value of maxscheduledwriterequests > > > Key: DIRMINA-1146 > URL: https://issues.apache.org/jira/browse/DIRMINA-1146 > Project: MINA > Issue Type: Bug >Reporter: Chily >Assignee: Jonathan Valliere >Priority: Blocker > Fix For: 2.2.2 > > Attachments: ConnectionEndPointIoHandler.java, > EmDsectProtocolIoHandlare.java > > > Slow Consumer Protection Feature does not work on TLS enabled session > -> ioSession.getScheduledWriteMessages() never decreases in > IoSessionResponder#send method > internal.engine.session.maxscheduledwriterequests=1 > Our TLS enabled session got disconneced when the outbound messages added up > to 1. > -- 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] [Updated] (DIRMINA-1146) TLS enabled session got disconnected when outbound messages add up to the value of maxscheduledwriterequests
[ https://issues.apache.org/jira/browse/DIRMINA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eissam Yassin updated DIRMINA-1146: --- Attachment: ConnectionEndPointIoHandler.java > TLS enabled session got disconnected when outbound messages add up to the > value of maxscheduledwriterequests > > > Key: DIRMINA-1146 > URL: https://issues.apache.org/jira/browse/DIRMINA-1146 > Project: MINA > Issue Type: Bug >Reporter: Chily >Assignee: Jonathan Valliere >Priority: Blocker > Fix For: 2.2.2 > > Attachments: ConnectionEndPointIoHandler.java, > EmDsectProtocolIoHandlare.java > > > Slow Consumer Protection Feature does not work on TLS enabled session > -> ioSession.getScheduledWriteMessages() never decreases in > IoSessionResponder#send method > internal.engine.session.maxscheduledwriterequests=1 > Our TLS enabled session got disconneced when the outbound messages added up > to 1. > -- 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] [Updated] (DIRMINA-1146) TLS enabled session got disconnected when outbound messages add up to the value of maxscheduledwriterequests
[ https://issues.apache.org/jira/browse/DIRMINA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eissam Yassin updated DIRMINA-1146: --- Attachment: EmDsectProtocolIoHandlare.java > TLS enabled session got disconnected when outbound messages add up to the > value of maxscheduledwriterequests > > > Key: DIRMINA-1146 > URL: https://issues.apache.org/jira/browse/DIRMINA-1146 > Project: MINA > Issue Type: Bug >Reporter: Chily >Assignee: Jonathan Valliere >Priority: Blocker > Fix For: 2.2.2 > > Attachments: EmDsectProtocolIoHandlare.java > > > Slow Consumer Protection Feature does not work on TLS enabled session > -> ioSession.getScheduledWriteMessages() never decreases in > IoSessionResponder#send method > internal.engine.session.maxscheduledwriterequests=1 > Our TLS enabled session got disconneced when the outbound messages added up > to 1. > -- 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] [Commented] (DIRMINA-1146) TLS enabled session got disconnected when outbound messages add up to the value of maxscheduledwriterequests
[ https://issues.apache.org/jira/browse/DIRMINA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791672#comment-17791672 ] Emmanuel Lécharny commented on DIRMINA-1146: Hi [~eissam_yassin] Thanks, get it. What I don't get is why this counter is not decremented when it absolutely *should*... Is there a way I can check your application IoHandler code? > TLS enabled session got disconnected when outbound messages add up to the > value of maxscheduledwriterequests > > > Key: DIRMINA-1146 > URL: https://issues.apache.org/jira/browse/DIRMINA-1146 > Project: MINA > Issue Type: Bug >Reporter: Chily >Assignee: Jonathan Valliere >Priority: Blocker > Fix For: 2.2.2 > > > Slow Consumer Protection Feature does not work on TLS enabled session > -> ioSession.getScheduledWriteMessages() never decreases in > IoSessionResponder#send method > internal.engine.session.maxscheduledwriterequests=1 > Our TLS enabled session got disconneced when the outbound messages added up > to 1. > -- 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] [Commented] (DIRMINA-1146) TLS enabled session got disconnected when outbound messages add up to the value of maxscheduledwriterequests
[ https://issues.apache.org/jira/browse/DIRMINA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791615#comment-17791615 ] Eissam Yassin commented on DIRMINA-1146: Hi [~elecharny] Thanks for your response. Let me explain again the problem we are facing. We see that messages sent by the application are received by the remote peer. When getScheduledWriteMessages number exceeds 4000 our application stops writing messages, but we see that getScheduledWriteMessages number remains constant and it does not decrease. Because of this our application is stuck waiting for getScheduledWriteMessages to decrease below 4000, but it does not. Many Thanks, Eissam > TLS enabled session got disconnected when outbound messages add up to the > value of maxscheduledwriterequests > > > Key: DIRMINA-1146 > URL: https://issues.apache.org/jira/browse/DIRMINA-1146 > Project: MINA > Issue Type: Bug >Reporter: Chily >Assignee: Jonathan Valliere >Priority: Blocker > Fix For: 2.2.2 > > > Slow Consumer Protection Feature does not work on TLS enabled session > -> ioSession.getScheduledWriteMessages() never decreases in > IoSessionResponder#send method > internal.engine.session.maxscheduledwriterequests=1 > Our TLS enabled session got disconneced when the outbound messages added up > to 1. > -- 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] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791525#comment-17791525
]
Emmanuel Lécharny commented on DIRMINA-1176:
Hi [~eissam_yassin],
even if it 'worked' in 2.0.7, teh logic was exactly the same, ie nothing get
sent to the peer while the application handler give back the hand. That means
you still need to check the _messageSent_ *before* sending some new data,
either in 2.0.x or in 2.2.x.
Anyway, if you were to stay in 2.0.X, you still should switch to 2.0.25.
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
> at
> com.bmc.ctms.common.services.Service$3.handleEvent(Service.java:358)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.handleSubscriberE
[jira] [Commented] (DIRMINA-1146) TLS enabled session got disconnected when outbound messages add up to the value of maxscheduledwriterequests
[
https://issues.apache.org/jira/browse/DIRMINA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790963#comment-17790963
]
Emmanuel Lécharny commented on DIRMINA-1146:
Hi [~eissam_yassin], if the *maxscheduledwriterequests* keep increasing, it's
because messages never get written to the remote peer.
There are two places this counter get decremented:
1) When the message get actually written (at the very end, we decrement the
scheduled messages counter)
{code:java}
/**
* Increase the number of written messages
*
* @param request The written message
* @param currentTime The current tile
*/
public final void increaseWrittenMessages(WriteRequest request, long
currentTime) {
Object message = request.getMessage();
if (message instanceof IoBuffer) {
IoBuffer b = (IoBuffer) message;
if (b.hasRemaining()) {
return;
}
}
writtenMessages++;
lastWriteTime = currentTime;
if (getService() instanceof AbstractIoService) {
((AbstractIoService)
getService()).getStatistics().increaseWrittenMessages(currentTime);
}
decreaseScheduledWriteMessages();
}
{code}
This method is called when the {{messageSent}} event is received:
{code:java}
@Override
public void messageSent(NextFilter nextFilter, IoSession session,
WriteRequest writeRequest) throws Exception {
long now = System.currentTimeMillis();
((AbstractIoSession) session).increaseWrittenMessages(writeRequest,
now);
{code}
2) When we get an error:
{code:java}
private void clearWriteRequestQueue(S session) {
...
// Create an exception and notify.
if (!failedRequests.isEmpty()) {
WriteToClosedSessionException cause = new
WriteToClosedSessionException(failedRequests);
for (WriteRequest r : failedRequests) {
session.decreaseScheduledBytesAndMessages(r);
r.getFuture().setException(cause);
}
IoFilterChain filterChain = session.getFilterChain();
filterChain.fireExceptionCaught(cause);
}
}
{code}
called by:
{code:java}
private boolean removeNow(S session) {
clearWriteRequestQueue(session);
{code}
which is part of the session cleanup.
> TLS enabled session got disconnected when outbound messages add up to the
> value of maxscheduledwriterequests
>
>
> Key: DIRMINA-1146
> URL: https://issues.apache.org/jira/browse/DIRMINA-1146
> Project: MINA
> Issue Type: Bug
>Reporter: Chily
>Assignee: Jonathan Valliere
>Priority: Blocker
> Fix For: 2.2.2
>
>
> Slow Consumer Protection Feature does not work on TLS enabled session
> -> ioSession.getScheduledWriteMessages() never decreases in
> IoSessionResponder#send method
> internal.engine.session.maxscheduledwriterequests=1
> Our TLS enabled session got disconneced when the outbound messages added up
> to 1.
>
--
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] [Commented] (DIRMINA-1146) TLS enabled session got disconnected when outbound messages add up to the value of maxscheduledwriterequests
[ https://issues.apache.org/jira/browse/DIRMINA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790921#comment-17790921 ] Eissam Yassin commented on DIRMINA-1146: Hi [~elecharny] The message is sent to the remote peer, but this number keeps increasing. The remote peer gets the message. When maxscheduledwriterequests number exceeds 4000 we stop writing messages to the remote peer. Because this number is not decreasing (We see that messages are read by the remote peer) we are stuck waiting for it to decrease. Because it does not decrease, we are stuck and we need to restart the application to fix it. Many Thanks, Eissam Yassin > TLS enabled session got disconnected when outbound messages add up to the > value of maxscheduledwriterequests > > > Key: DIRMINA-1146 > URL: https://issues.apache.org/jira/browse/DIRMINA-1146 > Project: MINA > Issue Type: Bug >Reporter: Chily >Assignee: Jonathan Valliere >Priority: Blocker > Fix For: 2.2.2 > > > Slow Consumer Protection Feature does not work on TLS enabled session > -> ioSession.getScheduledWriteMessages() never decreases in > IoSessionResponder#send method > internal.engine.session.maxscheduledwriterequests=1 > Our TLS enabled session got disconneced when the outbound messages added up > to 1. > -- 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] [Commented] (DIRMINA-1146) TLS enabled session got disconnected when outbound messages add up to the value of maxscheduledwriterequests
[ https://issues.apache.org/jira/browse/DIRMINA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790911#comment-17790911 ] Eissam Yassin commented on DIRMINA-1146: Hi [~elecharny] The message is sent to the remote peer, but this number keeps increasing. We maxscheduledwriterequests number exceeds 4000 we stop writing messages to the remote peer. Because this number is not decreasing (the messages are read by the remote peer) we are stuck waiting for it to decrease. Because it does not decrease we are stuck and we need to restart the application to fix it. Many Thanks, Eissam Yassin > TLS enabled session got disconnected when outbound messages add up to the > value of maxscheduledwriterequests > > > Key: DIRMINA-1146 > URL: https://issues.apache.org/jira/browse/DIRMINA-1146 > Project: MINA > Issue Type: Bug >Reporter: Chily >Assignee: Jonathan Valliere >Priority: Blocker > Fix For: 2.2.2 > > > Slow Consumer Protection Feature does not work on TLS enabled session > -> ioSession.getScheduledWriteMessages() never decreases in > IoSessionResponder#send method > internal.engine.session.maxscheduledwriterequests=1 > Our TLS enabled session got disconneced when the outbound messages added up > to 1. > -- 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] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790908#comment-17790908
]
Eissam Yassin commented on DIRMINA-1176:
Hi [~elecharny]
We used Mina 2.0.7, we did not face this problem in this version.
We faced it when we moved to Mina 2.2.1.
Now it is clear.
Many Thanks,
Eissam Yassin
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
> at
> com.bmc.ctms.common.services.Service$3.handleEvent(Service.java:358)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.handleSubscriberEntryEvent(EventDispatcher.java:687)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publishByUniqeID(EventDispatcher.java:673)
> at
>
[jira] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790828#comment-17790828
]
Emmanuel Lécharny commented on DIRMINA-1176:
Hi [~eissam_yassin],
so checking the code again,; I think the pb is that you try to write as much
data as you can in the IoHandler. But the thing is that the messages can't be
written if you don't quit the IoHandler, because you hold the thread.
The way to go is to write the messages, and quit, waiting for the
{{messageSent}} event to send some more message.
There is a limit of messages you can send in one go, and this limit is 64.
So you probably should revisit your application logic to give hand once the
message have been written in the IoHandler, and wait for the {{messageSent}}
event to write more.
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Downlo
[jira] [Commented] (DIRMINA-1146) TLS enabled session got disconnected when outbound messages add up to the value of maxscheduledwriterequests
[ https://issues.apache.org/jira/browse/DIRMINA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790826#comment-17790826 ] Emmanuel Lécharny commented on DIRMINA-1146: Hi [~eissam_yassin], not sure what is the exact problem you are facing. AFAICT, the counter keep increasing until the messages get written (and then the counter is decremented). At some point, if the remote peer does not read the messages, then everything could explode... Is that your problem? > TLS enabled session got disconnected when outbound messages add up to the > value of maxscheduledwriterequests > > > Key: DIRMINA-1146 > URL: https://issues.apache.org/jira/browse/DIRMINA-1146 > Project: MINA > Issue Type: Bug >Reporter: Chily >Assignee: Jonathan Valliere >Priority: Blocker > Fix For: 2.2.2 > > > Slow Consumer Protection Feature does not work on TLS enabled session > -> ioSession.getScheduledWriteMessages() never decreases in > IoSessionResponder#send method > internal.engine.session.maxscheduledwriterequests=1 > Our TLS enabled session got disconneced when the outbound messages added up > to 1. > -- 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] [Commented] (DIRMINA-1146) TLS enabled session got disconnected when outbound messages add up to the value of maxscheduledwriterequests
[ https://issues.apache.org/jira/browse/DIRMINA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790411#comment-17790411 ] Eissam Yassin commented on DIRMINA-1146: Hello [~johnnyv] I am facing this issue in one my environments. I am using Mina-2.2.1. When the outbound messages added up to 1 and more the session is not disconnected. Is this issue fixed? in which Mina version? Many Thanks, Eissam Yassin > TLS enabled session got disconnected when outbound messages add up to the > value of maxscheduledwriterequests > > > Key: DIRMINA-1146 > URL: https://issues.apache.org/jira/browse/DIRMINA-1146 > Project: MINA > Issue Type: Bug >Reporter: Chily >Assignee: Jonathan Valliere >Priority: Blocker > Fix For: 2.2.2 > > > Slow Consumer Protection Feature does not work on TLS enabled session > -> ioSession.getScheduledWriteMessages() never decreases in > IoSessionResponder#send method > internal.engine.session.maxscheduledwriterequests=1 > Our TLS enabled session got disconneced when the outbound messages added up > to 1. > -- 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] [Commented] (DIRMINA-459) IoSession.getScheduledWriteMessages() returns a negative value.
[ https://issues.apache.org/jira/browse/DIRMINA-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790399#comment-17790399 ] Eissam Yassin commented on DIRMINA-459: --- Hello, I am facing this problem in one of my environments. I am using Mina 2.2.1. Is this fixed? Which version fixes it. Many Thanks, Eissam Yassin > IoSession.getScheduledWriteMessages() returns a negative value. > --- > > Key: DIRMINA-459 > URL: https://issues.apache.org/jira/browse/DIRMINA-459 > Project: MINA > Issue Type: Bug > Components: Transport >Affects Versions: 1.0.6, 1.1.3 >Reporter: Trustin Lee >Assignee: Trustin Lee >Priority: Critical > Fix For: 1.0.7, 1.1.4 > > > Calling increaseWrittenMessages() causes scheduledWriteMessages to decrease. > It seems like the number of increaseScheduledWriteMessages() calls and the > number of increaseWrittenMessages() differ. -- 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] [Deleted] (SSHD-1337) New Attacks on SSH Channel Integrity
[
https://issues.apache.org/jira/browse/SSHD-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny deleted SSHD-1337:
> New Attacks on SSH Channel Integrity
>
>
> Key: SSHD-1337
> URL: https://issues.apache.org/jira/browse/SSHD-1337
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Lyor Goldstein
>Priority: Major
>
> {quote}We [1] are security researchers from the Ruhr University Bochum, and
> have discovered new attacks on the SSH channel integrity, which we want
> to disclose to you. You can find the draft version of our research
> paper, which we submitted to the USENIX Security conference, in [2].
> Please treat it confidential until public disclosure, which is currently
> planned for 18th of December 2023 (2023-12-18).
> Prefix truncation attack on BPP: By manipulating sequence numbers during
> the handshake, an attacker can remove the initial messages on the secure
> channel, without causing a MAC failure. The vulnerable cipher modes are
> ChaCha20-Poly1305 (chacha20-poly1...@openssh.com) and Encrypt-then-MAC
> (-e...@openssh.com MAC algorithms).
> Practical Exploits and Impact: With channel integrity broken, we also
> show several exploits. An extension negotiation downgrade attack
> undermines channel security by removing the extension info message, and
> works against all compliant implementations. For example, an attacker
> can disable the ping extension and thus disable the new countermeasure
> in OpenSSH 9.5 against keystroke timing attacks. Two other exploits
> against AsyncSSH are even more severe, but additionally rely on
> implementation flaws in AsyncSSH.
> Mitigations: We already disclosed our findings to the OpenSSH
> maintainers on 17th of October. Because fixing the flaw requires changes
> to the SSH specification, we worked together with them to come up with a
> specific countermeasure that ensures interoperability. We support the
> proposed changes in OpenSSH called "strict kex", which is negotiated as
> part of the SSH_MSG_KEXINIT. When negotiated, the following changes to
> the protocol are made:
> - The connection must be terminated if an unexpected or out-of-order
> message is received during initial key exchange. This includes insertion
> of any messages like SSH_MSG_IGNORE and similar, or if the
> SSH_MSG_KEXINIT is not the first message after the banner.
> - The implicit sequence numbers must be reset on every SSH_MSG_NEWKEYS.
> The OpenSSH project was kind enough to share with us, ahead of time, a
> "strict kex" patch that implements these changes (can be found in [2] as
> well). The patch enables you to build a version of OpenSSH that
> implements the proposed countermeasures for evaluation and
> interoperability testing. The patch also includes the amendment to the
> PROTOCOL file containing the specification for this extension. OpenSSH
> will release an updated version with these countermeasures on 18th of
> December 2024. As with our findings, we ask that you treat this patch
> confidential until public disclosure.
> As an alternative, less invasive countermeasure, the affected cipher
> modes chacha20-poly1305 and any encrypt-then-mac variants (generic EtM)
> may be (temporarily) disabled. Some cipher modes, in particular AES-GCM,
> are not affected by our findings and can still be used without changes.
> {quote}
> Draft paper and OpenSSH patch available at:
> [https://drive.google.com/drive/folders/1vJQYPqlaiDghv3jQ_TqOqgIowU_KO9ae?usp=drive_link]
> {quote}Based on feedback, OpenSSH updated the PROTOCOL specification for
> "strict
> kex" to resolve some ambiguities. First and foremost, the behaviour when
> encountering "strict kex" identifiers during key re-exchange is now
> well-defined. You can find the updated PROTOCOL specification below or in
> the Google Drive folder that I shared with you during the initial
> disclosure. If you have any additional feedback regarding this, I'll make
> sure to pass it along to the OpenSSH team and keep all of you updated.
> 1.9 transport: strict key exchange extension
> OpenSSH supports a number of transport-layer hardening measures under
> a "strict KEX" feature. This feature is signalled similarly to the
> RFC8305 ext-info feature: by including a additional algorithm in the
> initiial SSH2_MSG_KEXINIT kex_algorithms field. The client may append
> "kex-strict-c-...@openssh.com" to its kex_algorithms and the server
> may append "kex-strict-s-...@openssh.com".
> These pseudo-algorithms are only valid in the initial SSH2_MSG_KEXINIT and
>
[jira] [Updated] (SSHD-1337) New Attacks on SSH Channel Integrity
[
https://issues.apache.org/jira/browse/SSHD-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein updated SSHD-1337:
-
Description:
{quote}We [1] are security researchers from the Ruhr University Bochum, and
have discovered new attacks on the SSH channel integrity, which we want
to disclose to you. You can find the draft version of our research
paper, which we submitted to the USENIX Security conference, in [2].
Please treat it confidential until public disclosure, which is currently
planned for 18th of December 2023 (2023-12-18).
Prefix truncation attack on BPP: By manipulating sequence numbers during
the handshake, an attacker can remove the initial messages on the secure
channel, without causing a MAC failure. The vulnerable cipher modes are
ChaCha20-Poly1305 (chacha20-poly1...@openssh.com) and Encrypt-then-MAC
(-e...@openssh.com MAC algorithms).
Practical Exploits and Impact: With channel integrity broken, we also
show several exploits. An extension negotiation downgrade attack
undermines channel security by removing the extension info message, and
works against all compliant implementations. For example, an attacker
can disable the ping extension and thus disable the new countermeasure
in OpenSSH 9.5 against keystroke timing attacks. Two other exploits
against AsyncSSH are even more severe, but additionally rely on
implementation flaws in AsyncSSH.
Mitigations: We already disclosed our findings to the OpenSSH
maintainers on 17th of October. Because fixing the flaw requires changes
to the SSH specification, we worked together with them to come up with a
specific countermeasure that ensures interoperability. We support the
proposed changes in OpenSSH called "strict kex", which is negotiated as
part of the SSH_MSG_KEXINIT. When negotiated, the following changes to
the protocol are made:
- The connection must be terminated if an unexpected or out-of-order
message is received during initial key exchange. This includes insertion
of any messages like SSH_MSG_IGNORE and similar, or if the
SSH_MSG_KEXINIT is not the first message after the banner.
- The implicit sequence numbers must be reset on every SSH_MSG_NEWKEYS.
The OpenSSH project was kind enough to share with us, ahead of time, a
"strict kex" patch that implements these changes (can be found in [2] as
well). The patch enables you to build a version of OpenSSH that
implements the proposed countermeasures for evaluation and
interoperability testing. The patch also includes the amendment to the
PROTOCOL file containing the specification for this extension. OpenSSH
will release an updated version with these countermeasures on 18th of
December 2024. As with our findings, we ask that you treat this patch
confidential until public disclosure.
As an alternative, less invasive countermeasure, the affected cipher
modes chacha20-poly1305 and any encrypt-then-mac variants (generic EtM)
may be (temporarily) disabled. Some cipher modes, in particular AES-GCM,
are not affected by our findings and can still be used without changes.
{quote}
Draft paper and OpenSSH patch available at:
[https://drive.google.com/drive/folders/1vJQYPqlaiDghv3jQ_TqOqgIowU_KO9ae?usp=drive_link]
{quote}Based on feedback, OpenSSH updated the PROTOCOL specification for "strict
kex" to resolve some ambiguities. First and foremost, the behaviour when
encountering "strict kex" identifiers during key re-exchange is now
well-defined. You can find the updated PROTOCOL specification below or in
the Google Drive folder that I shared with you during the initial
disclosure. If you have any additional feedback regarding this, I'll make
sure to pass it along to the OpenSSH team and keep all of you updated.
1.9 transport: strict key exchange extension
OpenSSH supports a number of transport-layer hardening measures under
a "strict KEX" feature. This feature is signalled similarly to the
RFC8305 ext-info feature: by including a additional algorithm in the
initiial SSH2_MSG_KEXINIT kex_algorithms field. The client may append
"kex-strict-c-...@openssh.com" to its kex_algorithms and the server
may append "kex-strict-s-...@openssh.com".
These pseudo-algorithms are only valid in the initial SSH2_MSG_KEXINIT and MUST
be ignored
if they are present in subsequent SSH2_MSG_KEXINIT packets.
When an endpoint that supports this extension observes this algorithm
name in a peer's KEXINIT packet, it MUST make the following changes to
the the protocol:
a) During initial KEX, terminate the connection if any unexpected or
out-of-sequence packet is received. This includes terminating the
connection if the first packet received is not SSH2_MSG_KEXINIT.
Unexpected packets for the purpose of strict KEX include messages
that are otherwise valid at any time during the connection such as
SSH2_MSG_DEBUG and SSH2_MSG_IGNORE.
b) At each SSH2_MSG_NEWKEYS mess
[jira] [Created] (SSHD-1337) New Attacks on SSH Channel Integrity
Lyor Goldstein created SSHD-1337:
Summary: New Attacks on SSH Channel Integrity
Key: SSHD-1337
URL: https://issues.apache.org/jira/browse/SSHD-1337
Project: MINA SSHD
Issue Type: Improvement
Reporter: Lyor Goldstein
{quote}
We [1] are security researchers from the Ruhr University Bochum, and
have discovered new attacks on the SSH channel integrity, which we want
to disclose to you. You can find the draft version of our research
paper, which we submitted to the USENIX Security conference, in [2].
Please treat it confidential until public disclosure, which is currently
planned for 18th of December 2023 (2023-12-18).
Prefix truncation attack on BPP: By manipulating sequence numbers during
the handshake, an attacker can remove the initial messages on the secure
channel, without causing a MAC failure. The vulnerable cipher modes are
ChaCha20-Poly1305 (chacha20-poly1...@openssh.com) and Encrypt-then-MAC
(-e...@openssh.com MAC algorithms).
Practical Exploits and Impact: With channel integrity broken, we also
show several exploits. An extension negotiation downgrade attack
undermines channel security by removing the extension info message, and
works against all compliant implementations. For example, an attacker
can disable the ping extension and thus disable the new countermeasure
in OpenSSH 9.5 against keystroke timing attacks. Two other exploits
against AsyncSSH are even more severe, but additionally rely on
implementation flaws in AsyncSSH.
Mitigations: We already disclosed our findings to the OpenSSH
maintainers on 17th of October. Because fixing the flaw requires changes
to the SSH specification, we worked together with them to come up with a
specific countermeasure that ensures interoperability. We support the
proposed changes in OpenSSH called "strict kex", which is negotiated as
part of the SSH_MSG_KEXINIT. When negotiated, the following changes to
the protocol are made:
- The connection must be terminated if an unexpected or out-of-order
message is received during initial key exchange. This includes insertion
of any messages like SSH_MSG_IGNORE and similar, or if the
SSH_MSG_KEXINIT is not the first message after the banner.
- The implicit sequence numbers must be reset on every SSH_MSG_NEWKEYS.
The OpenSSH project was kind enough to share with us, ahead of time, a
"strict kex" patch that implements these changes (can be found in [2] as
well). The patch enables you to build a version of OpenSSH that
implements the proposed countermeasures for evaluation and
interoperability testing. The patch also includes the amendment to the
PROTOCOL file containing the specification for this extension. OpenSSH
will release an updated version with these countermeasures on 18th of
December 2024. As with our findings, we ask that you treat this patch
confidential until public disclosure.
As an alternative, less invasive countermeasure, the affected cipher
modes chacha20-poly1305 and any encrypt-then-mac variants (generic EtM)
may be (temporarily) disabled. Some cipher modes, in particular AES-GCM,
are not affected by our findings and can still be used without changes.
{quote}
Draft paper and OpenSSH patch available at:
https://drive.google.com/drive/folders/1vJQYPqlaiDghv3jQ_TqOqgIowU_KO9ae?usp=drive_link
{quote}
Based on feedback, OpenSSH updated the PROTOCOL specification for "strict
kex" to resolve some ambiguities. First and foremost, the behaviour when
encountering "strict kex" identifiers during key re-exchange is now
well-defined. You can find the updated PROTOCOL specification below or in
the Google Drive folder that I shared with you during the initial
disclosure. If you have any additional feedback regarding this, I'll make
sure to pass it along to the OpenSSH team and keep all of you updated.
1.9 transport: strict key exchange extension
OpenSSH supports a number of transport-layer hardening measures under
a "strict KEX" feature. This feature is signalled similarly to the
RFC8305 ext-info feature: by including a additional algorithm in the
initiial SSH2_MSG_KEXINIT kex_algorithms field. The client may append
"kex-strict-c-...@openssh.com" to its
kex_algorithms and the server
may append "kex-strict-s-...@openssh.com" .
These pseudo-algorithms
are only valid in the initial SSH2_MSG_KEXINIT and MUST be ignored
if they are present in subsequent SSH2_MSG_KEXINIT packets.
When an endpoint that supports this extension observes this algorithm
name in a peer's KEXINIT packet, it MUST make the following changes to
the the protocol:
a) During initial KEX, terminate the connection if any unexpected or
out-of-sequence packet is received. This includes terminating the
connection if the first packet received is not SSH2_MSG_KEXINIT.
Unexpected packets for the purpose of strict KEX include messages
that are other
[jira] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788468#comment-17788468
]
Eissam Yassin commented on DIRMINA-1176:
Hi [~elecharny]
Any update about this issue?
Many Thanks,
Eissam Yassin
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
> at
> com.bmc.ctms.common.services.Service$3.handleEvent(Service.java:358)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.handleSubscriberEntryEvent(EventDispatcher.java:687)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publishByUniqeID(EventDispatcher.java:673)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publish(EventDispatcher.java:694)
> a
[jira] [Created] (SSHD-1336) Add support for SSH2_MSG_PING/PONG
Lyor Goldstein created SSHD-1336: Summary: Add support for SSH2_MSG_PING/PONG Key: SSHD-1336 URL: https://issues.apache.org/jira/browse/SSHD-1336 Project: MINA SSHD Issue Type: New Feature Reporter: Lyor Goldstein See https://raw.githubusercontent.com/openssh/openssh-portable/master/PROTOCOL -- 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] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786876#comment-17786876
]
Eissam Yassin commented on DIRMINA-1176:
Hi [~elecharny]
Thanks for your response.
Waiting for your investigation results.
Eissam
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
> at
> com.bmc.ctms.common.services.Service$3.handleEvent(Service.java:358)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.handleSubscriberEntryEvent(EventDispatcher.java:687)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publishByUniqeID(EventDispatcher.java:673)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publish(EventDispatcher.java:694)
> a
[jira] [Commented] (FTPSERVER-507) bin/ftpd.sh res/conf/ftp-typical.xml causes "Cannot find the declaration of element 'server'"
[
https://issues.apache.org/jira/browse/FTPSERVER-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784006#comment-17784006
]
Jürgen Weber commented on FTPSERVER-507:
Same here with apache-ftpserver-1.2.0
Corporate firewall prevents resolving XML schemas.
apache-ftpserver should have an option to prevent resolving XML schemas in the
internet.
> bin/ftpd.sh res/conf/ftp-typical.xml causes "Cannot find the declaration of
> element 'server'"
> -
>
> Key: FTPSERVER-507
> URL: https://issues.apache.org/jira/browse/FTPSERVER-507
> Project: FtpServer
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.1.3
> Environment: Linux and Windows Version 21H2. jdk1.8.0_112 or jdk11.
>Reporter: Donald Smith
>Priority: Major
>
> {{Running *bin/ftpd.sh res/conf/ftpd-typical.xml* results in }}
> {{Using XML configuration file res/conf/ftpd-typical.xml...}}
> {{org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line
> 21 in XML document from file
> [C:\java\apache-ftpserver\apache-ftpserver-1.1.3\res\conf\ftpd-typical.xml]
> is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber:
> 21; columnNumber: 17; cvc-elt.1: Cannot find the declaration of element
> 'server'.}}
> {{ }}
> {{The bug manifests both on Windows and linux.}}
> {{The same thing happens for *bin/ftpd.sh res/conf/ftpd-full.xml* .}}
--
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] [Commented] (DIRMINA-1132) TLSv1.3 - MINA randomly fails in reading the message sent by client
[
https://issues.apache.org/jira/browse/DIRMINA-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781657#comment-17781657
]
Eissam Yassin commented on DIRMINA-1132:
Thanks [~elecharny] i will
> TLSv1.3 - MINA randomly fails in reading the message sent by client
> ---
>
> Key: DIRMINA-1132
> URL: https://issues.apache.org/jira/browse/DIRMINA-1132
> Project: MINA
> Issue Type: Bug
> Components: Core, SSL
>Affects Versions: 2.0.21
> Environment: Operating System: Windows 10 1903
> Java Version: jdk-11.0.7, jdk-12.0.2
>Reporter: Venkata Kishore Tavva
>Assignee: Jonathan Valliere
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: console.log, example-project.zip, keyStore.pfx,
> trustStore.pfx
>
>
> While trying to Implement TLSv1.3 in our systems, we found an issue with Mina
> Core dependency. For TLSv1.2 we never had the issue. But with TLSv1.3,
> randomly the message sent by the client is discarded. In such scenarios, the
> server waits for session to pass idle timeout and closes the session. Please
> find the sample code below:
> {code:java}
> import org.apache.mina.core.service.IoHandlerAdapter;
> import org.apache.mina.core.session.IdleStatus;
> import org.apache.mina.core.session.IoSession;
> import org.apache.mina.filter.ssl.SslFilter;
> import org.apache.mina.transport.socket.SocketAcceptor;
> import org.apache.mina.transport.socket.nio.NioSocketAcceptor;
> import javax.net.ssl.*;
> import java.io.*;
> import java.net.InetSocketAddress;
> import java.security.KeyStore;
> public class Main {
>public static void main(String[] args) throws Exception {
> System.setProperty("javax.net.debug","all");
> KeyManagerFactory keyManagerFactory;
> try(FileInputStream fis = new FileInputStream("keyStore.pfx")) {
> keyManagerFactory =
> KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
> KeyStore keyStore = KeyStore.getInstance("PKCS12");
> keyStore.load(fis, "passphrase".toCharArray());
> keyManagerFactory.init(keyStore, "passphrase".toCharArray());
> }
> TrustManagerFactory trustManagerFactory;
> try(FileInputStream fis = new FileInputStream("trustStore.pfx")){
> trustManagerFactory = TrustManagerFactory.getInstance("SunX509");
> KeyStore trustStore = KeyStore.getInstance("PKCS12");
> trustStore.load(fis, "passphrase".toCharArray());
> trustManagerFactory.init(trustStore);
> }
> SSLContext context = SSLContext.getInstance("TLSv1.3");
> context.init(keyManagerFactory.getKeyManagers(),
> trustManagerFactory.getTrustManagers(), null);
> SslFilter filter = new SslFilter(context);
> filter.setEnabledProtocols(new String[]{"TLSv1.3"});
> filter.setEnabledCipherSuites(new String[]{"TLS_AES_128_GCM_SHA256",
> "TLS_AES_256_GCM_SHA384"});
> SocketAcceptor acceptor = new NioSocketAcceptor();
> acceptor.setReuseAddress(true);
> acceptor.getFilterChain().addLast("sslFilter", filter);
> acceptor.setHandler( new ServerHandler());
> acceptor.bind(new InetSocketAddress(53001));
> System.out.println("Server started on Port : 53001");
> System.out.println("Start sending data using cUrl below:");
> System.out.println("-> curl --location --insecure --tlsv1.3 --ipv4
> 'https://localhost:53001' --data-raw 'Sample Text'");
>}
> }
> class ServerHandler extends IoHandlerAdapter {
>@Override
>public void sessionCreated(IoSession session) {
> System.out.println( "\nSession created : " + session);
>}
>@Override
>public void sessionOpened(IoSession session) {
> System.out.println( "Session opened : " + session);
> session.getConfig().setIdleTime(IdleStatus.BOTH_IDLE, 60);
>}
>@Override
>public void sessionClosed(IoSession session) {
> System.out.println( "Session closed : " + session);
> session.closeNow();
>}
>@Override
>public void sessionIdle(IoSession session, IdleStatus status) {
> System.out.println( "==" );
> System.out.println( "Session is idle for 60 secs hence closing session:
> " + session.getRemoteAddress());
[jira] [Commented] (DIRMINA-1132) TLSv1.3 - MINA randomly fails in reading the message sent by client
[
https://issues.apache.org/jira/browse/DIRMINA-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781648#comment-17781648
]
Emmanuel Lécharny commented on DIRMINA-1132:
[~eissam_yassin] Give 2.2.3 a try.
> TLSv1.3 - MINA randomly fails in reading the message sent by client
> ---
>
> Key: DIRMINA-1132
> URL: https://issues.apache.org/jira/browse/DIRMINA-1132
> Project: MINA
> Issue Type: Bug
> Components: Core, SSL
>Affects Versions: 2.0.21
> Environment: Operating System: Windows 10 1903
> Java Version: jdk-11.0.7, jdk-12.0.2
>Reporter: Venkata Kishore Tavva
>Assignee: Jonathan Valliere
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: console.log, example-project.zip, keyStore.pfx,
> trustStore.pfx
>
>
> While trying to Implement TLSv1.3 in our systems, we found an issue with Mina
> Core dependency. For TLSv1.2 we never had the issue. But with TLSv1.3,
> randomly the message sent by the client is discarded. In such scenarios, the
> server waits for session to pass idle timeout and closes the session. Please
> find the sample code below:
> {code:java}
> import org.apache.mina.core.service.IoHandlerAdapter;
> import org.apache.mina.core.session.IdleStatus;
> import org.apache.mina.core.session.IoSession;
> import org.apache.mina.filter.ssl.SslFilter;
> import org.apache.mina.transport.socket.SocketAcceptor;
> import org.apache.mina.transport.socket.nio.NioSocketAcceptor;
> import javax.net.ssl.*;
> import java.io.*;
> import java.net.InetSocketAddress;
> import java.security.KeyStore;
> public class Main {
>public static void main(String[] args) throws Exception {
> System.setProperty("javax.net.debug","all");
> KeyManagerFactory keyManagerFactory;
> try(FileInputStream fis = new FileInputStream("keyStore.pfx")) {
> keyManagerFactory =
> KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
> KeyStore keyStore = KeyStore.getInstance("PKCS12");
> keyStore.load(fis, "passphrase".toCharArray());
> keyManagerFactory.init(keyStore, "passphrase".toCharArray());
> }
> TrustManagerFactory trustManagerFactory;
> try(FileInputStream fis = new FileInputStream("trustStore.pfx")){
> trustManagerFactory = TrustManagerFactory.getInstance("SunX509");
> KeyStore trustStore = KeyStore.getInstance("PKCS12");
> trustStore.load(fis, "passphrase".toCharArray());
> trustManagerFactory.init(trustStore);
> }
> SSLContext context = SSLContext.getInstance("TLSv1.3");
> context.init(keyManagerFactory.getKeyManagers(),
> trustManagerFactory.getTrustManagers(), null);
> SslFilter filter = new SslFilter(context);
> filter.setEnabledProtocols(new String[]{"TLSv1.3"});
> filter.setEnabledCipherSuites(new String[]{"TLS_AES_128_GCM_SHA256",
> "TLS_AES_256_GCM_SHA384"});
> SocketAcceptor acceptor = new NioSocketAcceptor();
> acceptor.setReuseAddress(true);
> acceptor.getFilterChain().addLast("sslFilter", filter);
> acceptor.setHandler( new ServerHandler());
> acceptor.bind(new InetSocketAddress(53001));
> System.out.println("Server started on Port : 53001");
> System.out.println("Start sending data using cUrl below:");
> System.out.println("-> curl --location --insecure --tlsv1.3 --ipv4
> 'https://localhost:53001' --data-raw 'Sample Text'");
>}
> }
> class ServerHandler extends IoHandlerAdapter {
>@Override
>public void sessionCreated(IoSession session) {
> System.out.println( "\nSession created : " + session);
>}
>@Override
>public void sessionOpened(IoSession session) {
> System.out.println( "Session opened : " + session);
> session.getConfig().setIdleTime(IdleStatus.BOTH_IDLE, 60);
>}
>@Override
>public void sessionClosed(IoSession session) {
> System.out.println( "Session closed : " + session);
> session.closeNow();
>}
>@Override
>public void sessionIdle(IoSession session, IdleStatus status) {
> System.out.println( "==" );
> System.out.println( "Session is idle for 60 secs hence closing session:
> " +
[jira] [Commented] (DIRMINA-1132) TLSv1.3 - MINA randomly fails in reading the message sent by client
[
https://issues.apache.org/jira/browse/DIRMINA-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781645#comment-17781645
]
Eissam Yassin commented on DIRMINA-1132:
Hello,
Is this issue fixed? in which Mina version?
Many Thanks,
Eissam
> TLSv1.3 - MINA randomly fails in reading the message sent by client
> ---
>
> Key: DIRMINA-1132
> URL: https://issues.apache.org/jira/browse/DIRMINA-1132
> Project: MINA
> Issue Type: Bug
> Components: Core, SSL
>Affects Versions: 2.0.21
> Environment: Operating System: Windows 10 1903
> Java Version: jdk-11.0.7, jdk-12.0.2
>Reporter: Venkata Kishore Tavva
>Assignee: Jonathan Valliere
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: console.log, example-project.zip, keyStore.pfx,
> trustStore.pfx
>
>
> While trying to Implement TLSv1.3 in our systems, we found an issue with Mina
> Core dependency. For TLSv1.2 we never had the issue. But with TLSv1.3,
> randomly the message sent by the client is discarded. In such scenarios, the
> server waits for session to pass idle timeout and closes the session. Please
> find the sample code below:
> {code:java}
> import org.apache.mina.core.service.IoHandlerAdapter;
> import org.apache.mina.core.session.IdleStatus;
> import org.apache.mina.core.session.IoSession;
> import org.apache.mina.filter.ssl.SslFilter;
> import org.apache.mina.transport.socket.SocketAcceptor;
> import org.apache.mina.transport.socket.nio.NioSocketAcceptor;
> import javax.net.ssl.*;
> import java.io.*;
> import java.net.InetSocketAddress;
> import java.security.KeyStore;
> public class Main {
>public static void main(String[] args) throws Exception {
> System.setProperty("javax.net.debug","all");
> KeyManagerFactory keyManagerFactory;
> try(FileInputStream fis = new FileInputStream("keyStore.pfx")) {
> keyManagerFactory =
> KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
> KeyStore keyStore = KeyStore.getInstance("PKCS12");
> keyStore.load(fis, "passphrase".toCharArray());
> keyManagerFactory.init(keyStore, "passphrase".toCharArray());
> }
> TrustManagerFactory trustManagerFactory;
> try(FileInputStream fis = new FileInputStream("trustStore.pfx")){
> trustManagerFactory = TrustManagerFactory.getInstance("SunX509");
> KeyStore trustStore = KeyStore.getInstance("PKCS12");
> trustStore.load(fis, "passphrase".toCharArray());
> trustManagerFactory.init(trustStore);
> }
> SSLContext context = SSLContext.getInstance("TLSv1.3");
> context.init(keyManagerFactory.getKeyManagers(),
> trustManagerFactory.getTrustManagers(), null);
> SslFilter filter = new SslFilter(context);
> filter.setEnabledProtocols(new String[]{"TLSv1.3"});
> filter.setEnabledCipherSuites(new String[]{"TLS_AES_128_GCM_SHA256",
> "TLS_AES_256_GCM_SHA384"});
> SocketAcceptor acceptor = new NioSocketAcceptor();
> acceptor.setReuseAddress(true);
> acceptor.getFilterChain().addLast("sslFilter", filter);
> acceptor.setHandler( new ServerHandler());
> acceptor.bind(new InetSocketAddress(53001));
> System.out.println("Server started on Port : 53001");
> System.out.println("Start sending data using cUrl below:");
> System.out.println("-> curl --location --insecure --tlsv1.3 --ipv4
> 'https://localhost:53001' --data-raw 'Sample Text'");
>}
> }
> class ServerHandler extends IoHandlerAdapter {
>@Override
>public void sessionCreated(IoSession session) {
> System.out.println( "\nSession created : " + session);
>}
>@Override
>public void sessionOpened(IoSession session) {
> System.out.println( "Session opened : " + session);
> session.getConfig().setIdleTime(IdleStatus.BOTH_IDLE, 60);
>}
>@Override
>public void sessionClosed(IoSession session) {
> System.out.println( "Session closed : " + session);
> session.closeNow();
>}
>@Override
>public void sessionIdle(IoSession session, IdleStatus status) {
> System.out.println( "==" );
> System.out.println( "Session is idle for 60 secs hence closing session:
>
[jira] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779985#comment-17779985
]
Emmanuel Lécharny commented on DIRMINA-1176:
This is curious. When a message is received by the SslFilter, it is processed
immediately, and should be written in the socket.
I'll investigate.
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
> at
> com.bmc.ctms.common.services.Service$3.handleEvent(Service.java:358)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.handleSubscriberEntryEvent(EventDispatcher.java:687)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publishByUniqeID(EventDispatcher.java:673)
> at
>
[jira] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779892#comment-17779892
]
Eissam Yassin commented on DIRMINA-1176:
Hi [~elecharny]
Yes, the remote peer reading the messages fast enough.
>From our research we saw that there are delays in Mina between buffering the
>messages and sending them to the remote peer.
The time between the write of the message calling the write method and the
message was reported as sent to the remote peer by the write future object
increased gradually from 5 milli second to more than 4 seconds until we got the
buffer overflow exception. In that time the remote peer was idle.
Regards,
Eissam
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
> at
> com.bmc.ctms.common.service
[jira] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779583#comment-17779583
]
Emmanuel Lécharny commented on DIRMINA-1176:
Hi Eissam,
can you check that the remote peer is readin the messages fast enough?
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
> at
> com.bmc.ctms.common.services.Service$3.handleEvent(Service.java:358)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.handleSubscriberEntryEvent(EventDispatcher.java:687)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publishByUniqeID(EventDispatcher.java:673)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publish(EventDispatcher.java:694)
> a
[jira] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779582#comment-17779582
]
Emmanuel Lécharny commented on DIRMINA-1176:
Hi [~johnnyv],
the BufferOverflow occurs because the number of enqueued message exceed the 64
mimit (MAX_QUEUED_MESSAGES):
{code:java}
/* package protected */ class SSLHandlerG0 extends SslHandler {
...
/**
* {@inheritDoc}
*/
@Overridesynchronized public void write(NextFilter next, WriteRequest
request) throws SSLException, WriteRejectedException {
...
if (mEncodeQueue.size() == MAX_QUEUED_MESSAGES) {
throw new BufferOverflowException();
}
...{code}
Do you remind what was the rational for the addition of this hard limit? This
was this commit:
https://github.com/apache/mina/commit/94a43f8e035c83b09ce72721418c3f20f8e4f084
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.service
[jira] [Created] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
Eissam Yassin created DIRMINA-1176:
--
Summary: Buffer overflow exception when writing messages over SSL
Key: DIRMINA-1176
URL: https://issues.apache.org/jira/browse/DIRMINA-1176
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 2.2.1, 2.2.3
Reporter: Eissam Yassin
Hello,
When many messages written over SSL we get BufferOverflowException exception:
{noformat}
0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
T@113, T:ctm.COMM_EM.113, , , COMM_EM,
EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
at
org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
at
com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
at
org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
at
org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
at
org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
at
org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
at
org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
at
com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
at
com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
at
com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
at
com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
at
com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
at
com.bmc.ctms.common.services.Service$3.handleEvent(Service.java:358)
at
com.bmc.ctms.infra.EventDispatcher$EventEntry.handleSubscriberEntryEvent(EventDispatcher.java:687)
at
com.bmc.ctms.infra.EventDispatcher$EventEntry.publishByUniqeID(EventDispatcher.java:673)
at
com.bmc.ctms.infra.EventDispatcher$EventEntry.publish(EventDispatcher.java:694)
at
com.bmc.ctms.infra.EventDispatcher.publish(EventDispatcher.java:194)
at com.bmc.ctms.infra.EventDispatcher.publish(EventDispatcher.java:154)
at
com.bmc.ctms.common.Ipc2EventAdapter.handleIpcGtwMsg(Ipc2EventAdapter.java:206)
at
com.bmc.ctms.common.Ipc2EventAdapter$1.handleEvent(Ipc2EventAdapter.java:41)
at
com.bmc.ctms.infra.EventDispatcher$EventEntry.handleSubscriberEntryEvent(EventDispatcher.java:687)
at
com.bmc.ctms.infra.EventDispatcher$EventEntry.handleSubscribersEntryEvent(EventDispatcher.java:733)
at
com.bmc.ctms.infra.EventDispatcher$EventEntry.publish(EventDispatcher.java:701)
at
com.bmc.ctms.infra.Ev
[jira] [Updated] (SSHD-1324) Rooted file system can leak informations
[ https://issues.apache.org/jira/browse/SSHD-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SSHD-1324: -- Fix Version/s: 2.9.3 > Rooted file system can leak informations > > > Key: SSHD-1324 > URL: https://issues.apache.org/jira/browse/SSHD-1324 > Project: MINA SSHD > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.10.0, 2.9.3 > > -- 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] [Updated] (SSHD-1259) DefaultKnownHostsServerKeyVerifier not checking all Key algorithms present in known_hosts
[
https://issues.apache.org/jira/browse/SSHD-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1259:
--
Fix Version/s: 2.11.0
> DefaultKnownHostsServerKeyVerifier not checking all Key algorithms present in
> known_hosts
> -
>
> Key: SSHD-1259
> URL: https://issues.apache.org/jira/browse/SSHD-1259
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Klaus Nguetsa
>Priority: Major
> Fix For: 2.10.1, 2.11.0
>
>
> Hello everyone,
> Assuming I have the following known_hosts file containing twice the public
> key of the same host but with different algorithms.:
>
> {code:java}
> lserver1 ssh-dss
>
> #
> lserver1 ecdsa-sha2-nistp256
> {code}
>
>
> During the connection when I use DefaultKnownHostsServerKeyVerifier to
> verify the keys, if the target host presents a ecdsa-sha2-nistp256 key, the
> verification will fail because DefaultKnownHostsServerKeyVerifier seems to
> match to the first occurence of the hostname in the know_host file. Therefore
> It will match the key _lserver1 ssh-dss ..._ and the comparison
> to the same key but with ecdsa-sha2-nistp256 algorithm presented by the
> target host will fail. Shouldn't it iterate through the file until the right
> combination (hostname, algorithm) is found? This way it could check with
> lserver1 ecdsa-sha2-nistp256 . instead of lserver1 ssh-dss X..
> This works fine with openssh.
> Thanks
>
--
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] [Updated] (SSHD-1310) SftpFileSystem.close() method, closes the session as well.
[
https://issues.apache.org/jira/browse/SSHD-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1310:
--
Fix Version/s: 2.11.0
> SftpFileSystem.close() method, closes the session as well.
> ---
>
> Key: SSHD-1310
> URL: https://issues.apache.org/jira/browse/SSHD-1310
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Tilden
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.10.1, 2.11.0
>
>
> SftpFileSystem.close() method, closes the session as well.
> We expect only the sftpfilesystem channel to be closed. Since we use the
> same session for multiple operations (exec command, SFTP download & upload,
> SFTP client list directory).
>
> SftpFileSystem.java
> public void close() throws IOException {
> if (this.isOpen()) {
> SftpFileSystemProvider provider = this.provider();
> String fsId = this.getId();
> SftpFileSystem fs = provider.removeFileSystem(fsId);
> ClientSession session = this.getClientSession();
> *session.close(true);*
> if (fs != null && fs != this) {
> throw new FileSystemException(fsId, fsId, "Mismatched FS
> instance for id=" + fsId);
> }
> }
> }
>
>
> can you please check and let us know, if this can be fixed ?
--
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] [Updated] (SSHD-1332) Identities using tilde specified in config are not loaded
[
https://issues.apache.org/jira/browse/SSHD-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1332:
--
Fix Version/s: 2.10.1
> Identities using tilde specified in config are not loaded
> -
>
> Key: SSHD-1332
> URL: https://issues.apache.org/jira/browse/SSHD-1332
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Bernhard Geisberger
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.10.1, 2.11.0
>
>
> In the latest version of sshd, the library fails to load any identities
> specified in the {{.ssh/config}} file if they use tilde in their path (e.g.
> {{~/.ssh/id_test}}).
> This seems to be a regression from
> [https://github.com/apache/mina-sshd/pull/353] because the
> {{resolveIdentityFilePath}} method inside {{HostConfigEntry}} is no longer
> called.
--
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] [Updated] (SSHD-1327) WriteState causes memory overflow
[ https://issues.apache.org/jira/browse/SSHD-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Wolf updated SSHD-1327: -- Fix Version/s: 2.11.0 > WriteState causes memory overflow > - > > Key: SSHD-1327 > URL: https://issues.apache.org/jira/browse/SSHD-1327 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.10.0 >Reporter: fuzhoupeng >Assignee: Thomas Wolf >Priority: Major > Fix For: 2.10.1, 2.11.0 > > Attachments: image-2023-05-16-09-58-04-005.png, > image-2023-05-16-10-03-30-225.png, image-2023-05-16-10-03-44-339.png, > image-2023-05-16-10-04-31-679.png, image-2023-05-16-10-04-53-165.png, > image-2023-05-16-10-06-12-880.png, image-2023-05-16-10-12-13-163.png, > image-2023-05-16-10-12-23-189.png > > > When data is written to a channel, the writeBuffer method is invoked, and a > writeState is recorded. > !image-2023-05-16-10-03-44-339.png! > > WriteState records the last sent packet, which causes memory overflow. > !image-2023-05-16-10-04-31-679.png! > !image-2023-05-16-10-06-12-880.png! > > When a large number of devices are managed and a large number of packets are > delivered last time, the cached packets delivered last time cause service > memory overflow. > !image-2023-05-16-10-12-13-163.png! > !image-2023-05-16-10-12-23-189.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] [Updated] (SSHD-1330) keep-alive handler on client
[
https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1330:
--
Fix Version/s: 2.10.1
> keep-alive handler on client
>
>
> Key: SSHD-1330
> URL: https://issues.apache.org/jira/browse/SSHD-1330
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.10.0
>Reporter: Florian Hof
>Assignee: Lyor Goldstein
>Priority: Minor
> Fix For: 2.10.1, 2.11.0
>
>
> After a connection using the default SFTP client, I get lot's of WARN logs
> like the following:
> {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]])
> unknown global request: keepal...@proftpd.org}}
> It seems that the server send keep-alive messages to the client. The
> {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}}
> handles this properly. It is per default in the server handlers. I propose
> to add it per default in the client handlers. This shouldn't have negative
> effect, should it? Adding it afterwards avoids the WARN logs.
> Implementation on
> {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}}
> would be trivial:
> {code:java}
> public static final List>
> DEFAULT_GLOBAL_REQUEST_HANDLERS
> = List.of(OpenSshHostKeysHandler.INSTANCE,
> KeepAliveHandler.INSTANCE);
> {code}
> (and eventually move the {{KeepAliveHandler}} from
> {{org.apache.sshd.*server*.global}} to
> {{{}org.apache.sshd.*common*.global{}}}).
--
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] [Updated] (SSHD-1330) keep-alive handler on client
[
https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1330:
--
Fix Version/s: 2.11.0
(was: 2.10.1)
> keep-alive handler on client
>
>
> Key: SSHD-1330
> URL: https://issues.apache.org/jira/browse/SSHD-1330
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.10.0
>Reporter: Florian Hof
>Assignee: Lyor Goldstein
>Priority: Minor
> Fix For: 2.11.0
>
>
> After a connection using the default SFTP client, I get lot's of WARN logs
> like the following:
> {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]])
> unknown global request: keepal...@proftpd.org}}
> It seems that the server send keep-alive messages to the client. The
> {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}}
> handles this properly. It is per default in the server handlers. I propose
> to add it per default in the client handlers. This shouldn't have negative
> effect, should it? Adding it afterwards avoids the WARN logs.
> Implementation on
> {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}}
> would be trivial:
> {code:java}
> public static final List>
> DEFAULT_GLOBAL_REQUEST_HANDLERS
> = List.of(OpenSshHostKeysHandler.INSTANCE,
> KeepAliveHandler.INSTANCE);
> {code}
> (and eventually move the {{KeepAliveHandler}} from
> {{org.apache.sshd.*server*.global}} to
> {{{}org.apache.sshd.*common*.global{}}}).
--
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] [Updated] (SSHD-1332) Identities using tilde specified in config are not loaded
[
https://issues.apache.org/jira/browse/SSHD-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1332:
--
Fix Version/s: 2.11.0
(was: 2.10.1)
> Identities using tilde specified in config are not loaded
> -
>
> Key: SSHD-1332
> URL: https://issues.apache.org/jira/browse/SSHD-1332
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Bernhard Geisberger
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.11.0
>
>
> In the latest version of sshd, the library fails to load any identities
> specified in the {{.ssh/config}} file if they use tilde in their path (e.g.
> {{~/.ssh/id_test}}).
> This seems to be a regression from
> [https://github.com/apache/mina-sshd/pull/353] because the
> {{resolveIdentityFilePath}} method inside {{HostConfigEntry}} is no longer
> called.
--
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] [Resolved] (SSHD-1330) keep-alive handler on client
[
https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-1330.
--
Fix Version/s: 2.10.1
Resolution: Fixed
> keep-alive handler on client
>
>
> Key: SSHD-1330
> URL: https://issues.apache.org/jira/browse/SSHD-1330
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.10.0
>Reporter: Florian Hof
>Assignee: Lyor Goldstein
>Priority: Minor
> Fix For: 2.10.1
>
>
> After a connection using the default SFTP client, I get lot's of WARN logs
> like the following:
> {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]])
> unknown global request: keepal...@proftpd.org}}
> It seems that the server send keep-alive messages to the client. The
> {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}}
> handles this properly. It is per default in the server handlers. I propose
> to add it per default in the client handlers. This shouldn't have negative
> effect, should it? Adding it afterwards avoids the WARN logs.
> Implementation on
> {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}}
> would be trivial:
> {code:java}
> public static final List>
> DEFAULT_GLOBAL_REQUEST_HANDLERS
> = List.of(OpenSshHostKeysHandler.INSTANCE,
> KeepAliveHandler.INSTANCE);
> {code}
> (and eventually move the {{KeepAliveHandler}} from
> {{org.apache.sshd.*server*.global}} to
> {{{}org.apache.sshd.*common*.global{}}}).
--
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] [Commented] (SSHD-1335) Add landing directory feature
[
https://issues.apache.org/jira/browse/SSHD-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767695#comment-17767695
]
Thomas Wolf commented on SSHD-1335:
---
It depends. If the user should only be able to access {{/A/B}} via SFTP, then
just set that as his home directory in
{{{}VirtualFileSystemFactory.setUserHomeDir(){}}}. It does not have to be the
user's real home directory in the operating system.
But if the user should also be able to access {{/A}} via SFTP, then what you
want is not doable server-side. Commands like {{cd}} or {{pwd}} must be
implemented client-side; and doing an initial "{{{}cd B{}}}" after log-in would
also have to happen in the client.
> Add landing directory feature
> -
>
> Key: SSHD-1335
> URL: https://issues.apache.org/jira/browse/SSHD-1335
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Ananth kumar
>Priority: Critical
>
> Currently, we are able to set only the home directory using the
> VirtualFileSystemFactory class.
> Our requirement is to land the user in the subdirectories of the home
> directory.
> Is some feature can be provided to land the user in a different directory?
> Eg:
> The User A has the home directory as /A. But the User A should be landed into
> the /A/B directory after login
> Current scenario:
> {code:java}
> sftp> pwd
> /{code}
> required Scenario:
> {code:java}
> sftp> pwd
> /B {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] [Commented] (SSHD-1335) Add landing directory feature
[
https://issues.apache.org/jira/browse/SSHD-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766888#comment-17766888
]
Ananth kumar commented on SSHD-1335:
Thanks, [~twolf] for the quick response.
Basically, Just for my confirmation, there is no way to land the user in some
subdirectory instead of the root directory?
> Add landing directory feature
> -
>
> Key: SSHD-1335
> URL: https://issues.apache.org/jira/browse/SSHD-1335
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Ananth kumar
>Priority: Critical
>
> Currently, we are able to set only the home directory using the
> VirtualFileSystemFactory class.
> Our requirement is to land the user in the subdirectories of the home
> directory.
> Is some feature can be provided to land the user in a different directory?
> Eg:
> The User A has the home directory as /A. But the User A should be landed into
> the /A/B directory after login
> Current scenario:
> {code:java}
> sftp> pwd
> /{code}
> required Scenario:
> {code:java}
> sftp> pwd
> /B {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] [Commented] (SSHD-1335) Add landing directory feature
[
https://issues.apache.org/jira/browse/SSHD-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766877#comment-17766877
]
Thomas Wolf commented on SSHD-1335:
---
AFAIK there is no server-side concept of a "current working directory" in SFTP.
You could set the user's SFTP root directory (his "SFTP home directory") to
{{/A/B}} in the {{{}VirtualFileSystemFactory{}}}, but then the the SFTP path
"/" would refer to {{{}/A/B{}}}, and {{pwd}} on the client would still show "/"
after login.
> Add landing directory feature
> -
>
> Key: SSHD-1335
> URL: https://issues.apache.org/jira/browse/SSHD-1335
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Ananth kumar
>Priority: Critical
>
> Currently, we are able to set only the home directory using the
> VirtualFileSystemFactory class.
> Our requirement is to land the user in the subdirectories of the home
> directory.
> Is some feature can be provided to land the user in a different directory?
> Eg:
> The User A has the home directory as /A. But the User A should be landed into
> the /A/B directory after login
> Current scenario:
> {code:java}
> sftp> pwd
> /{code}
> required Scenario:
> {code:java}
> sftp> pwd
> /B {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] [Closed] (SSHD-1333) Adding java.nio.file.CopyOption to SCP transfer methods
[
https://issues.apache.org/jira/browse/SSHD-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein closed SSHD-1333.
> Adding java.nio.file.CopyOption to SCP transfer methods
> ---
>
> Key: SSHD-1333
> URL: https://issues.apache.org/jira/browse/SSHD-1333
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: dgü
>Assignee: Lyor Goldstein
>Priority: Major
>
> Hello!
> remote-to-remote file transfer is available in SCP protocol. If I'm not
> wrong, it is not available in SFTP protocol.
> I'm trying to use the following code to handle remote-to-remote file transfer.
> {code:java}
> public class SSHDFileSystemProvider extends SftpFileSystemProvider {
> private final static String URI_SCHEME = "ssh";
>
> private final static boolean PRESERVE_ATTRIBUTES = true;
> @Override
> public String getScheme() {
> return URI_SCHEME;
> }
> @Override
> public void copy(Path sourcePath, Path targetPath, CopyOption... options)
> throws IOException {
> ClientSession sourceClientSession = ((SftpFileSystem)
> (sourcePath.getFileSystem())).getClientSession();
> ClientSession targetClientSession = ((SftpFileSystem)
> (targetPath.getFileSystem())).getClientSession();
> ScpRemote2RemoteTransferHelper helper = new
> ScpRemote2RemoteTransferHelper(sourceClientSession, targetClientSession);
> helper.transferFile(sourcePath.toString(), targetPath.toString(),
> PRESERVE_ATTRIBUTES);
> }
> }
> {code}
> _ScpRemote2RemoteTransferHelper.transferFile(String,String,boolean)_ accepts
> preserve attributes only as the copy option.
> My request:
> - is it possible to add java.nio.file.CopyOption to SCP transfer methods?
> 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] [Resolved] (SSHD-1333) Adding java.nio.file.CopyOption to SCP transfer methods
[
https://issues.apache.org/jira/browse/SSHD-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-1333.
--
Resolution: Won't Fix
> Adding java.nio.file.CopyOption to SCP transfer methods
> ---
>
> Key: SSHD-1333
> URL: https://issues.apache.org/jira/browse/SSHD-1333
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: dgü
>Assignee: Lyor Goldstein
>Priority: Major
>
> Hello!
> remote-to-remote file transfer is available in SCP protocol. If I'm not
> wrong, it is not available in SFTP protocol.
> I'm trying to use the following code to handle remote-to-remote file transfer.
> {code:java}
> public class SSHDFileSystemProvider extends SftpFileSystemProvider {
> private final static String URI_SCHEME = "ssh";
>
> private final static boolean PRESERVE_ATTRIBUTES = true;
> @Override
> public String getScheme() {
> return URI_SCHEME;
> }
> @Override
> public void copy(Path sourcePath, Path targetPath, CopyOption... options)
> throws IOException {
> ClientSession sourceClientSession = ((SftpFileSystem)
> (sourcePath.getFileSystem())).getClientSession();
> ClientSession targetClientSession = ((SftpFileSystem)
> (targetPath.getFileSystem())).getClientSession();
> ScpRemote2RemoteTransferHelper helper = new
> ScpRemote2RemoteTransferHelper(sourceClientSession, targetClientSession);
> helper.transferFile(sourcePath.toString(), targetPath.toString(),
> PRESERVE_ATTRIBUTES);
> }
> }
> {code}
> _ScpRemote2RemoteTransferHelper.transferFile(String,String,boolean)_ accepts
> preserve attributes only as the copy option.
> My request:
> - is it possible to add java.nio.file.CopyOption to SCP transfer methods?
> 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] [Assigned] (SSHD-1333) Adding java.nio.file.CopyOption to SCP transfer methods
[
https://issues.apache.org/jira/browse/SSHD-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein reassigned SSHD-1333:
Assignee: Lyor Goldstein
> Adding java.nio.file.CopyOption to SCP transfer methods
> ---
>
> Key: SSHD-1333
> URL: https://issues.apache.org/jira/browse/SSHD-1333
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: dgü
>Assignee: Lyor Goldstein
>Priority: Major
>
> Hello!
> remote-to-remote file transfer is available in SCP protocol. If I'm not
> wrong, it is not available in SFTP protocol.
> I'm trying to use the following code to handle remote-to-remote file transfer.
> {code:java}
> public class SSHDFileSystemProvider extends SftpFileSystemProvider {
> private final static String URI_SCHEME = "ssh";
>
> private final static boolean PRESERVE_ATTRIBUTES = true;
> @Override
> public String getScheme() {
> return URI_SCHEME;
> }
> @Override
> public void copy(Path sourcePath, Path targetPath, CopyOption... options)
> throws IOException {
> ClientSession sourceClientSession = ((SftpFileSystem)
> (sourcePath.getFileSystem())).getClientSession();
> ClientSession targetClientSession = ((SftpFileSystem)
> (targetPath.getFileSystem())).getClientSession();
> ScpRemote2RemoteTransferHelper helper = new
> ScpRemote2RemoteTransferHelper(sourceClientSession, targetClientSession);
> helper.transferFile(sourcePath.toString(), targetPath.toString(),
> PRESERVE_ATTRIBUTES);
> }
> }
> {code}
> _ScpRemote2RemoteTransferHelper.transferFile(String,String,boolean)_ accepts
> preserve attributes only as the copy option.
> My request:
> - is it possible to add java.nio.file.CopyOption to SCP transfer methods?
> 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] [Comment Edited] (SSHD-1333) Adding java.nio.file.CopyOption to SCP transfer methods
[
https://issues.apache.org/jira/browse/SSHD-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766857#comment-17766857
]
Lyor Goldstein edited comment on SSHD-1333 at 9/19/23 3:45 PM:
---
I understand that - my question was what would be the +semantics+ of the extra
supported options. Please note that any other option makes no sense. Please
note that we can only support what SCP protocol allows - adding a bunch of
options that have no meaning only muddle the API. If you need to call
{{FileSystemProvider#copy(Path, Path, CopyOption...)}} then do so after
translating the SCP options to {{CopyOption}}-s - if such translation is even
possible
{code:java|title=StandardCopyOption(s)}
package java.nio.file;
/**
* Defines the standard copy options.
*
* @since 1.7
*/
public enum StandardCopyOption implements CopyOption {
/**
* Replace an existing file if it exists.
*/
REPLACE_EXISTING,
/**
* Copy attributes to the new file.
*/
COPY_ATTRIBUTES,
/**
* Move the file as an atomic file system operation.
*/
ATOMIC_MOVE;
}
{code}
{code:java|title=SCP options}
public interface ScpClient extends SessionHolder,
ClientSessionHolder {
enum Option {
Recursive("-r"),
PreserveAttributes("-p"),
TargetIsDirectory("-d"),
;
private final String optionValue;
Option(String optionValue) {
this.optionValue = optionValue;
}
/**
* @return The option value to use in the issued SCP command
*/
public String getOptionValue() {
return optionValue;
}
}
{code}
was (Author: lgoldstein):
I understand that - my question was what would be the +semantics+ of the extra
supported options. Please note that any other option makes no sense.
> Adding java.nio.file.CopyOption to SCP transfer methods
> ---
>
> Key: SSHD-1333
> URL: https://issues.apache.org/jira/browse/SSHD-1333
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: dgü
>Priority: Major
>
> Hello!
> remote-to-remote file transfer is available in SCP protocol. If I'm not
> wrong, it is not available in SFTP protocol.
> I'm trying to use the following code to handle remote-to-remote file transfer.
> {code:java}
> public class SSHDFileSystemProvider extends SftpFileSystemProvider {
> private final static String URI_SCHEME = "ssh";
>
> private final static boolean PRESERVE_ATTRIBUTES = true;
> @Override
> public String getScheme() {
> return URI_SCHEME;
> }
> @Override
> public void copy(Path sourcePath, Path targetPath, CopyOption... options)
> throws IOException {
> ClientSession sourceClientSession = ((SftpFileSystem)
> (sourcePath.getFileSystem())).getClientSession();
> ClientSession targetClientSession = ((SftpFileSystem)
> (targetPath.getFileSystem())).getClientSession();
> ScpRemote2RemoteTransferHelper helper = new
> ScpRemote2RemoteTransferHelper(sourceClientSession, targetClientSession);
> helper.transferFile(sourcePath.toString(), targetPath.toString(),
> PRESERVE_ATTRIBUTES);
> }
> }
> {code}
> _ScpRemote2RemoteTransferHelper.transferFile(String,String,boolean)_ accepts
> preserve attributes only as the copy option.
> My request:
> - is it possible to add java.nio.file.CopyOption to SCP transfer methods?
> 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] [Commented] (SSHD-1333) Adding java.nio.file.CopyOption to SCP transfer methods
[
https://issues.apache.org/jira/browse/SSHD-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766857#comment-17766857
]
Lyor Goldstein commented on SSHD-1333:
--
I understand that - my question was what would be the +semantics+ of the extra
supported options. Please note that any other option makes no sense.
> Adding java.nio.file.CopyOption to SCP transfer methods
> ---
>
> Key: SSHD-1333
> URL: https://issues.apache.org/jira/browse/SSHD-1333
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: dgü
>Priority: Major
>
> Hello!
> remote-to-remote file transfer is available in SCP protocol. If I'm not
> wrong, it is not available in SFTP protocol.
> I'm trying to use the following code to handle remote-to-remote file transfer.
> {code:java}
> public class SSHDFileSystemProvider extends SftpFileSystemProvider {
> private final static String URI_SCHEME = "ssh";
>
> private final static boolean PRESERVE_ATTRIBUTES = true;
> @Override
> public String getScheme() {
> return URI_SCHEME;
> }
> @Override
> public void copy(Path sourcePath, Path targetPath, CopyOption... options)
> throws IOException {
> ClientSession sourceClientSession = ((SftpFileSystem)
> (sourcePath.getFileSystem())).getClientSession();
> ClientSession targetClientSession = ((SftpFileSystem)
> (targetPath.getFileSystem())).getClientSession();
> ScpRemote2RemoteTransferHelper helper = new
> ScpRemote2RemoteTransferHelper(sourceClientSession, targetClientSession);
> helper.transferFile(sourcePath.toString(), targetPath.toString(),
> PRESERVE_ATTRIBUTES);
> }
> }
> {code}
> _ScpRemote2RemoteTransferHelper.transferFile(String,String,boolean)_ accepts
> preserve attributes only as the copy option.
> My request:
> - is it possible to add java.nio.file.CopyOption to SCP transfer methods?
> 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] [Created] (SSHD-1335) Add landing directory feature
Ananth kumar created SSHD-1335:
--
Summary: Add landing directory feature
Key: SSHD-1335
URL: https://issues.apache.org/jira/browse/SSHD-1335
Project: MINA SSHD
Issue Type: Improvement
Reporter: Ananth kumar
Currently, we are able to set only the home directory using the
VirtualFileSystemFactory class.
Our requirement is to land the user in the subdirectories of the home directory.
Is some feature can be provided to land the user in a different directory?
Eg:
The User A has the home directory as /A. But the User A should be landed into
the /A/B directory after login
Current scenario:
{code:java}
sftp> pwd
/{code}
required Scenario:
{code:java}
sftp> pwd
/B {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] [Commented] (SSHD-1333) Adding java.nio.file.CopyOption to SCP transfer methods
[
https://issues.apache.org/jira/browse/SSHD-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766698#comment-17766698
]
dgü commented on SSHD-1333:
---
If this feature is added, overrided copy method will be fully compatible with
{_}FileSystemProvider#copy(Path, Path, CopyOption...){_}.
Thanks!
> Adding java.nio.file.CopyOption to SCP transfer methods
> ---
>
> Key: SSHD-1333
> URL: https://issues.apache.org/jira/browse/SSHD-1333
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: dgü
>Priority: Major
>
> Hello!
> remote-to-remote file transfer is available in SCP protocol. If I'm not
> wrong, it is not available in SFTP protocol.
> I'm trying to use the following code to handle remote-to-remote file transfer.
> {code:java}
> public class SSHDFileSystemProvider extends SftpFileSystemProvider {
> private final static String URI_SCHEME = "ssh";
>
> private final static boolean PRESERVE_ATTRIBUTES = true;
> @Override
> public String getScheme() {
> return URI_SCHEME;
> }
> @Override
> public void copy(Path sourcePath, Path targetPath, CopyOption... options)
> throws IOException {
> ClientSession sourceClientSession = ((SftpFileSystem)
> (sourcePath.getFileSystem())).getClientSession();
> ClientSession targetClientSession = ((SftpFileSystem)
> (targetPath.getFileSystem())).getClientSession();
> ScpRemote2RemoteTransferHelper helper = new
> ScpRemote2RemoteTransferHelper(sourceClientSession, targetClientSession);
> helper.transferFile(sourcePath.toString(), targetPath.toString(),
> PRESERVE_ATTRIBUTES);
> }
> }
> {code}
> _ScpRemote2RemoteTransferHelper.transferFile(String,String,boolean)_ accepts
> preserve attributes only as the copy option.
> My request:
> - is it possible to add java.nio.file.CopyOption to SCP transfer methods?
> 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] [Updated] (SSHD-1330) keep-alive handler on client
[
https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein updated SSHD-1330:
-
Affects Version/s: 2.10.0
> keep-alive handler on client
>
>
> Key: SSHD-1330
> URL: https://issues.apache.org/jira/browse/SSHD-1330
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.10.0
>Reporter: Florian Hof
>Assignee: Lyor Goldstein
>Priority: Minor
>
> After a connection using the default SFTP client, I get lot's of WARN logs
> like the following:
> {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]])
> unknown global request: keepal...@proftpd.org}}
> It seems that the server send keep-alive messages to the client. The
> {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}}
> handles this properly. It is per default in the server handlers. I propose
> to add it per default in the client handlers. This shouldn't have negative
> effect, should it? Adding it afterwards avoids the WARN logs.
> Implementation on
> {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}}
> would be trivial:
> {code:java}
> public static final List>
> DEFAULT_GLOBAL_REQUEST_HANDLERS
> = List.of(OpenSshHostKeysHandler.INSTANCE,
> KeepAliveHandler.INSTANCE);
> {code}
> (and eventually move the {{KeepAliveHandler}} from
> {{org.apache.sshd.*server*.global}} to
> {{{}org.apache.sshd.*common*.global{}}}).
--
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 started] (SSHD-1330) keep-alive handler on client
[
https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-1330 started by Lyor Goldstein.
> keep-alive handler on client
>
>
> Key: SSHD-1330
> URL: https://issues.apache.org/jira/browse/SSHD-1330
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Florian Hof
>Assignee: Lyor Goldstein
>Priority: Minor
>
> After a connection using the default SFTP client, I get lot's of WARN logs
> like the following:
> {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]])
> unknown global request: keepal...@proftpd.org}}
> It seems that the server send keep-alive messages to the client. The
> {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}}
> handles this properly. It is per default in the server handlers. I propose
> to add it per default in the client handlers. This shouldn't have negative
> effect, should it? Adding it afterwards avoids the WARN logs.
> Implementation on
> {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}}
> would be trivial:
> {code:java}
> public static final List>
> DEFAULT_GLOBAL_REQUEST_HANDLERS
> = List.of(OpenSshHostKeysHandler.INSTANCE,
> KeepAliveHandler.INSTANCE);
> {code}
> (and eventually move the {{KeepAliveHandler}} from
> {{org.apache.sshd.*server*.global}} to
> {{{}org.apache.sshd.*common*.global{}}}).
--
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] [Commented] (SSHD-1330) keep-alive handler on client
[
https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766453#comment-17766453
]
Lyor Goldstein commented on SSHD-1330:
--
This is the 1st time we encounter servers sending {{keepalive}} global requests
to clients. However, I see no reason why not to implement your suggestion.
> keep-alive handler on client
>
>
> Key: SSHD-1330
> URL: https://issues.apache.org/jira/browse/SSHD-1330
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Florian Hof
>Priority: Minor
>
> After a connection using the default SFTP client, I get lot's of WARN logs
> like the following:
> {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]])
> unknown global request: keepal...@proftpd.org}}
> It seems that the server send keep-alive messages to the client. The
> {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}}
> handles this properly. It is per default in the server handlers. I propose
> to add it per default in the client handlers. This shouldn't have negative
> effect, should it? Adding it afterwards avoids the WARN logs.
> Implementation on
> {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}}
> would be trivial:
> {code:java}
> public static final List>
> DEFAULT_GLOBAL_REQUEST_HANDLERS
> = List.of(OpenSshHostKeysHandler.INSTANCE,
> KeepAliveHandler.INSTANCE);
> {code}
> (and eventually move the {{KeepAliveHandler}} from
> {{org.apache.sshd.*server*.global}} to
> {{{}org.apache.sshd.*common*.global{}}}).
--
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] [Assigned] (SSHD-1330) keep-alive handler on client
[
https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein reassigned SSHD-1330:
Assignee: Lyor Goldstein
> keep-alive handler on client
>
>
> Key: SSHD-1330
> URL: https://issues.apache.org/jira/browse/SSHD-1330
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Florian Hof
>Assignee: Lyor Goldstein
>Priority: Minor
>
> After a connection using the default SFTP client, I get lot's of WARN logs
> like the following:
> {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]])
> unknown global request: keepal...@proftpd.org}}
> It seems that the server send keep-alive messages to the client. The
> {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}}
> handles this properly. It is per default in the server handlers. I propose
> to add it per default in the client handlers. This shouldn't have negative
> effect, should it? Adding it afterwards avoids the WARN logs.
> Implementation on
> {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}}
> would be trivial:
> {code:java}
> public static final List>
> DEFAULT_GLOBAL_REQUEST_HANDLERS
> = List.of(OpenSshHostKeysHandler.INSTANCE,
> KeepAliveHandler.INSTANCE);
> {code}
> (and eventually move the {{KeepAliveHandler}} from
> {{org.apache.sshd.*server*.global}} to
> {{{}org.apache.sshd.*common*.global{}}}).
--
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] [Commented] (SSHD-1333) Adding java.nio.file.CopyOption to SCP transfer methods
[
https://issues.apache.org/jira/browse/SSHD-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766451#comment-17766451
]
Lyor Goldstein commented on SSHD-1333:
--
I don't see the use-case for this - what extra options would make sense ?
> Adding java.nio.file.CopyOption to SCP transfer methods
> ---
>
> Key: SSHD-1333
> URL: https://issues.apache.org/jira/browse/SSHD-1333
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: dgü
>Priority: Major
>
> Hello!
> remote-to-remote file transfer is available in SCP protocol. If I'm not
> wrong, it is not available in SFTP protocol.
> I'm trying to use the following code to handle remote-to-remote file transfer.
> {code:java}
> public class SSHDFileSystemProvider extends SftpFileSystemProvider {
> private final static String URI_SCHEME = "ssh";
>
> private final static boolean PRESERVE_ATTRIBUTES = true;
> @Override
> public String getScheme() {
> return URI_SCHEME;
> }
> @Override
> public void copy(Path sourcePath, Path targetPath, CopyOption... options)
> throws IOException {
> ClientSession sourceClientSession = ((SftpFileSystem)
> (sourcePath.getFileSystem())).getClientSession();
> ClientSession targetClientSession = ((SftpFileSystem)
> (targetPath.getFileSystem())).getClientSession();
> ScpRemote2RemoteTransferHelper helper = new
> ScpRemote2RemoteTransferHelper(sourceClientSession, targetClientSession);
> helper.transferFile(sourcePath.toString(), targetPath.toString(),
> PRESERVE_ATTRIBUTES);
> }
> }
> {code}
> _ScpRemote2RemoteTransferHelper.transferFile(String,String,boolean)_ accepts
> preserve attributes only as the copy option.
> My request:
> - is it possible to add java.nio.file.CopyOption to SCP transfer methods?
> 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] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764105#comment-17764105
]
Alexander B commented on DIRMINA-1172:
--
Thanks a lot. (y)
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Fix For: 2.2.3, 2.0.25, 2.1.8
>
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
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] [Resolved] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny resolved DIRMINA-1172.
Fix Version/s: 2.2.3
2.0.25
2.1.8
Resolution: Fixed
Fixed by adding the local address port in the Datagram session key
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Fix For: 2.2.3, 2.0.25, 2.1.8
>
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
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] [Resolved] (DIRMINA-996) IoSessionRecycler RemoteAddress Collision
[
https://issues.apache.org/jira/browse/DIRMINA-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny resolved DIRMINA-996.
---
Fix Version/s: 2.2.3
2.0.25
2.1.8
Resolution: Fixed
I fixed the issue by creating a key that also contains the local port:
{code:java}
String key = session.getRemoteAddress() + ":" +
((InetSocketAddress)session.getLocalAddress()).getPort(); {code}
> IoSessionRecycler RemoteAddress Collision
> -
>
> Key: DIRMINA-996
> URL: https://issues.apache.org/jira/browse/DIRMINA-996
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.7
>Reporter: Flavio Battimo
>Assignee: Jonathan Valliere
>Priority: Critical
> Fix For: 2.2.3, 2.0.25, 2.1.8
>
>
> When using NioDatagramAcceptor with multiple binded local addresses the
> IoSessionRecycler is not working as expected.
> If the acceptor has been prefilled with two sessions:
> remoteaddr=192.168.1.10:2001 localaddr=192.168.1.20:1000
> remoteaddr=192.168.1.10:2001 localaddr=192.168.1.20:1001
> so with same remote address but different local address, when the recycle
> method of IoSessionRecycler interface is called only remote address is
> passed. The recycler returns the same IoSession for incoming datagrams on two
> different local addresses of the same acceptor.
> The IoSessionRecycler should have the local address parameter also in order
> to find the correct IoSession.
--
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] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759366#comment-17759366
]
Emmanuel Lécharny commented on DIRMINA-1172:
Hi Alexander,
will work on a triple release (2.0,X, 2.1.X and 2.2.X in the coming days). Not
a lot of available time, but that should not take me a lot of time either.
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
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] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758563#comment-17758563
]
Alexander B commented on DIRMINA-1172:
--
Actually, the two Cmd's are running in parallel.
But, anyway, I think, if it works now - would it be possible to fix this
officially in 2.1.x and/or 2.2.x ?
Thanks a lot
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
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] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758540#comment-17758540
]
Emmanuel Lécharny commented on DIRMINA-1172:
The session does not last forever, may be it expired in scenario 2?
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
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] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758460#comment-17758460
]
Alexander B commented on DIRMINA-1172:
--
Actually, I still did not get the clue. Before, the port was not part of the
session key. And scenario 2 worked before. It was just scenario 3, that did not
work. Scenario 2 and 3 are both sending to different ports. The difference is
just from two applications or just from one. In both scenarios you can find
just one sending machine.
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
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] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758452#comment-17758452
]
Emmanuel Lécharny commented on DIRMINA-1172:
Hi, Alexender,
they do have the same IP address, but they aren't sending the data to the same
port. Now that the port is part of the session key, two sessions will be
created.
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
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
