[jira] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL

[Jonathan Valliere (Jira)]

[ 
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

Re: Test of MINA branch bugfix/DIRMINA-1173

[Jonathan Valliere]

 When we get the stack trace can someone attach it to the ticket please



On Feb 27, 2024 at 5:00:52 PM, Emmanuel Lécharny 
wrote:

> Hi Henrik,
>
> the thread dump never made it, it was discarded by the ASF mail server.
>
> Could you push it in a place we can pull it?
>
> Another option is for you to send it to me privately as an attachement.
>
> Thanks !
>
> On 27/02/2024 15:51, Baastrup, Henrik wrote:
>
> Hi Jonathan,
>
>
> I have this e-mail address from M.V.S. Kishore which have manage the
>
> problem with MINA we have, up till now.
>
>
> I would like to inform you, I have tested the branch in subject and
>
> attached the dump (kill -3 ) to this e-mail. As you can see we
>
> still have the deadlock.
>
>
> I'm ready to try to help out if I get some indications.
>
>
> Regards,
>
> Henrik
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
>
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>
> --
> *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> elecha...@apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

[jira] [Resolved] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL

[Jonathan Valliere (Jira)]

 [ 
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

[Jonathan Valliere (Jira)]

[ 
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

[Jonathan Valliere (Jira)]

[ 
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

[Jonathan Valliere (Jira)]

[ 
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

[Jonathan Valliere (Jira)]

 [ 
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

[Jonathan Valliere (Jira)]

[ 
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

2.2.X unit tests failing

[Jonathan Valliere]

I pulled 2.2.X down on my Mac today and many of the unit tests are failing
if I try to run ALL of them.

Many are related to this issue: Could not initialize class
net.sf.cglib.proxy.Enhancer

Any ideas?

mina-core does pass all of the tests.

[jira] [Commented] (DIRMINA-963) Socks5 and ProxyConnector don't work with InetSocketAddress.createUnresolved

[Jonathan Valliere (Jira)]

[ 
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

Re: Throwing RuntimeException is usually an anti-pattern

[Jonathan Valliere]

Make a PR

On Mon, Jul 3, 2023 at 7:12 PM Gary Gregory  wrote:

> Hi All,
>
> I noticed that in org.apache.ftpserver.util.EncryptUtils we explicitly
> throw RuntimeException. This is usually an anti-pattern as
> IllegalArgumentException, IllegalStateException, and others are more
> descriptive.
>
> In the case of EncryptUtils, IllegalArgumentException seems more
> appropriate.
>
> Thoughts?
>
> Gary
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: Apache MINA Mastodon account is on!

[Jonathan Valliere]



On Sun, Jul 2, 2023 at 6:32 PM Emmanuel Lécharny 
wrote:

> Hi!
>
> we just have created a Mastodon account to inform the world abouut the
> Apache MINA project evolution.
>
> Feel free to follow @apachem...@fosstodon.org  !
> --
> *Emmanuel Lécharny*
>
> -
> To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
> For additional commands, e-mail: users-h...@mina.apache.org
>
>

Re: [VOTE] Apache MINA 2.2.2, 2.1.7, 2.0.24 releases

[Jonathan Valliere]

+3

On Thu, Jun 1, 2023 at 6:58 PM Emmanuel Lécharny 
wrote:

> hi!
>
> WARNING: there are 3 votes to cast!
>
>
> This is a vote for a triple release:
> * MINA 2.2.2
> * MINA 2.1.7
> * MINA 2.0.24
>
> Those versions are fixing some SSL/TLS issues and bring some added
> features:
> DIRMINA-1122: support for endpoint identification algorithm (thanks to
> Marcin L)
> DIRMINA-1157: A fix for a sporadic SSL/TLS connection establishement for
> version 2.0.X and 2.1.X (thanks to  Steffen Liersch)
> DIRMINA-1169: A fix in the Acceptor for  Java 11 and upper (thanks to
> Thomas Wolf)
>
>
> Temporary tags have been created (they can be removed if the vote is not
> approved) :
>
> * MINA 2.2.2:
>
> https://github.com/apache/mina/commit/bd0b2da0c1993c5bbb5498c5542a263e2a69e554
> * MINA 2.1.7:
>
> https://github.com/apache/mina/commit/f112272a3c1c84aad650a2772d82fcf4ac87
> * MINA 2.0.24:
>
> https://github.com/apache/mina/commit/ff0dd253fe1416951ebffd2f622bfcb56e5873d3
>
>
>
> The final artifacts are stored in a staging repository:
> * MINA 2.2.2:
> https://repository.apache.org/content/repositories/orgapachemina-1082
> * MINA 2.1.7:
> https://repository.apache.org/content/repositories/orgapachemina-1084
> * MINA 2.0.24:
> https://repository.apache.org/content/repositories/orgapachemina-1083
>
>
>
> The distributions are available for download on :
> * MINA 2.2.2: https://dist.apache.org/repos/dist/dev/mina/mina/2.2.2
> * MINA 2.1.7: https://dist.apache.org/repos/dist/dev/mina/mina/2.1.7
> * MINA 2.0.24: https://dist.apache.org/repos/dist/dev/mina/mina/2.0.24
>
>
> Let us vote :
> [ ] +1 | Release MINA 2.2.2
> [ ] ± | Abstain
> [ ] -1 | Do *NOT* release MINA 2.2.2
>
> [ ] +1 | Release MINA 2.1.7
> [ ] ± | Abstain
> [ ] -1 | Do *NOT* release MINA 2.1.7
>
>
> [ ] +1 | Release MINA 2.0.24
> [ ] ± | Abstain
> [ ] -1 | Do *NOT* release MINA 2.0.24
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> 
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
> --
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.

[jira] [Commented] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721051#comment-17721051
 ] 

Jonathan Valliere commented on DIRMINA-1173:


Think of it like this.  All of the Processor Pool threads share the same
FilterChain. So if you have 8 cores there are 16 Processor Threads. If you
add a ExecutorFilter with 4 threads then then all the tasks produced by
those 16 threads will then be executed on the 4 shared threads and it will
bottleneck.




> 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
>
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread 
> blocking issue, So used latest mina verstion 2.2.1 but still threads were 
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.  
> Once this issue comes  in sub sequest launches nothing will work all threads 
> will be blocked forever,i have to restart the process to make it work. For 
> single thread working fine,if i start 50-100 threads this thread blocking 
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this 
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with 
> the first ip in the list.if it did n't work then again i will try to 
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then 
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and 
> response processing is in another thread.
>  
> *Thread 1:*
>  Public class g10CaptureService
>  {
>  
> private static final ProtocolCodecFilter probeCodecFilter = new 
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
>     *private static final ExecutorFilter executorFilter = new 
> ExecutorFilter(16,32);*
>     private static final G10GPBMessageIoFilter gpbMessageFilter = new 
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
>  static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine = 
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
>                 G10MinaClient.CONNECTED, new G10MinaClient(processor));
>         IoHandler ioHandler = new 
> StateMachineProxyBuilder().setStateContextLookup(
>                 new IoSessionStateContextLookup(new StateContextFactory() {
>                     @Override
>                     public StateContext create() {
>                         final G10StateContext stateContext = new 
> G10StateContext();
>                         stateContext.setStartedTime(new Date());
>                         return stateContext;
>                     }
>                 })).create(IoHandler.class, stateMachine);
>                 
>                 
> //Global connector across the system, i.e multiple threads uses the same 
> connector.            
> NioSocketConnector connector = new NioSocketConnector();
>         connector.getFilterChain().addLast("LoggingFilter", 
> G10CaptureService.loggingFilter);
>         connector.getFilterChain().addLast("codecFilter", 
> G10CaptureService.probeCodecFilter);
>         connector.getFilterChain().addLast("executorFilter", 
> G10CaptureService.executorFilter);
>         connector.getFilterChain().addLast("gpbMessageFilter", 
> G10CaptureService.gpbMessageFilter);
>         connector.getFilterChain().addLast("keepAliveFilter", 
> G10CaptureService.keepAliveFilter);
>         connector.setHandler(ioHandler);
> }
>         
> public void StartRecordCapture()
> {
> connectionLock.lock();
> try
> {
> ConnectFuture primaryConnectFuture = connector.connect(primaryAddress, 
> initializer);
> //hungs forever if the no. of threads are more than 30
> primaryConnectFuture.awaitUninterruptibly();//no time out specified
> if (!primaryConnectFuture.isConnected()) 
> {
>                
&

Re: [jira] [Commented] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever

[Jonathan Valliere]

Think of it like this.  All of the Processor Pool threads share the same
FilterChain. So if you have 8 cores there are 16 Processor Threads. If you
add a ExecutorFilter with 4 threads then then all the tasks produced by
those 16 threads will then be executed on the 4 shared threads and it will
bottleneck.

On Tue, May 9, 2023 at 2:39 PM KMVS (Jira)  wrote:

>
> [
> https://issues.apache.org/jira/browse/DIRMINA-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721040#comment-17721040
> ]
>
> KMVS commented on DIRMINA-1173:
> ---
>
> What is the effect of using our own thread pool in the execution filter ?
>
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
>
> vs
>
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(Executors.newCachedThreadPool());*
>
>
> > 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
> >
> >
> > Hi All,
> > I have attached thread dump too for analysis.
> > I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at
> {*}awaitUninterruptibly{*}.  Once this issue comes  in sub sequest launches
> nothing will work all threads will be blocked forever,i have to restart the
> process to make it work. For single thread working fine,if i start 50-100
> threads this thread blocking issue will surface.I am using the same
> NioSocketConnector across the threads.
> > Here is an scenario, I have one gate way IP which i connect initially
> ,this gate way will return list of ips.
> > now i will close the previous IOsession and will create a nio connection
> with the first ip in the list.if it did n't work then again i will try to
> > connect to next ip etc..
> > All these are in the critical section. i.e i will acquire a lock and
> then after successful connection i will release the lock.
> > But problem i have noticed is with the awaitUninterruptibly().
> > I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
> >
> > *Thread 1:*
> >  Public class g10CaptureService
> >  {
> >
> > private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> > *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> > private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> >  static
> > {
> > initConnectors()
> > }
> > protected static void initConnectors()
> > {
> > StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> > G10MinaClient.CONNECTED, new G10MinaClient(processor));
> > IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> > new IoSessionStateContextLookup(new
> StateContextFactory() {
> > @Override
> > public StateContext create() {
> > final G10StateContext stateContext = new
> G10StateContext();
> > stateContext.setStartedTime(new Date());
> > return stateContext;
> > }
> > })).create(IoHandler.class, stateMachine);
> >
> >
> > //Global connector across the system, i.e multiple threads uses the same
> connector.
> > NioSocketConnector connector = new NioSocketConnector();
> > connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> > connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> > connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.executorFilter);
> > connector.getFilterChain().addLast("gpbMessageFilter",
> G10CaptureService.gpbMessageFilter);
> > connector.getFilterChain().addLast("keepAliveFilter",
> G10CaptureService.keepAliveFilter);
> > connector.setHandler(ioHandler);
> > }
> >
> > public void StartRecordCapture()
> > {
> > connectionLock.lock();
> > try
> > {
> > ConnectFuture primaryConnectFuture = connector.connect(primaryAddress,
> initializer);
> > //hungs forever if the no. of threads are more than 30
> > primaryConnectFuture.awaitUninterruptibly();//no time out specified
> > if (!primaryConnectFuture.isConnected())
> 

Re: [jira] [Comment Edited] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever

[Jonathan Valliere]

Yes, all sockets

On Tue, May 9, 2023 at 11:21 AM KMVS (Jira)  wrote:

>
> [
> https://issues.apache.org/jira/browse/DIRMINA-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720884#comment-17720884
> ]
>
> KMVS edited comment on DIRMINA-1173 at 5/9/23 3:20 PM:
> ---
>
> What the association between NIO Connector and executorFilter ?
>
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
>
> If I have a static executorFilter  then will the worker threads will be
> shared across all NIO sockets ?
>
>
>
>
> was (Author: JIRAUSER300071):
> How the association between NIO Connector and executorFilter ?
>
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
>
> If I have a static executorFilter  then will the worker threads will be
> shared across all NIO sockets ?
>
>
>
> > 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
> >
> >
> > Hi All,
> > I have attached thread dump too for analysis.
> > I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at
> {*}awaitUninterruptibly{*}.  Once this issue comes  in sub sequest launches
> nothing will work all threads will be blocked forever,i have to restart the
> process to make it work. For single thread working fine,if i start 50-100
> threads this thread blocking issue will surface.I am using the same
> NioSocketConnector across the threads.
> > Here is an scenario, I have one gate way IP which i connect initially
> ,this gate way will return list of ips.
> > now i will close the previous IOsession and will create a nio connection
> with the first ip in the list.if it did n't work then again i will try to
> > connect to next ip etc..
> > All these are in the critical section. i.e i will acquire a lock and
> then after successful connection i will release the lock.
> > But problem i have noticed is with the awaitUninterruptibly().
> > I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
> >
> > *Thread 1:*
> >  Public class g10CaptureService
> >  {
> >
> > private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> > *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> > private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> >  static
> > {
> > initConnectors()
> > }
> > protected static void initConnectors()
> > {
> > StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> > G10MinaClient.CONNECTED, new G10MinaClient(processor));
> > IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> > new IoSessionStateContextLookup(new
> StateContextFactory() {
> > @Override
> > public StateContext create() {
> > final G10StateContext stateContext = new
> G10StateContext();
> > stateContext.setStartedTime(new Date());
> > return stateContext;
> > }
> > })).create(IoHandler.class, stateMachine);
> >
> >
> > //Global connector across the system, i.e multiple threads uses the same
> connector.
> > NioSocketConnector connector = new NioSocketConnector();
> > connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> > connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> > connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.executorFilter);
> > connector.getFilterChain().addLast("gpbMessageFilter",
> G10CaptureService.gpbMessageFilter);
> > connector.getFilterChain().addLast("keepAliveFilter",
> G10CaptureService.keepAliveFilter);
> > connector.setHandler(ioHandler);
> > }
> >
> > public void StartRecordCapture()
> > {
> > connectionLock.lock();
> > try
> > {
> > ConnectFuture primaryConnectFuture = connector.connect(primaryAddress,
> initializer);
> > //hungs forever if the no. of threads are more than 30
> > primaryConnectFuture.awaitUninterruptibly();//no time out specified
> > 

[jira] [Commented] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720971#comment-17720971
 ] 

Jonathan Valliere commented on DIRMINA-1173:


Yes, all sockets


CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.


> 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
>
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread 
> blocking issue, So used latest mina verstion 2.2.1 but still threads were 
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.  
> Once this issue comes  in sub sequest launches nothing will work all threads 
> will be blocked forever,i have to restart the process to make it work. For 
> single thread working fine,if i start 50-100 threads this thread blocking 
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this 
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with 
> the first ip in the list.if it did n't work then again i will try to 
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then 
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and 
> response processing is in another thread.
>  
> *Thread 1:*
>  Public class g10CaptureService
>  {
>  
> private static final ProtocolCodecFilter probeCodecFilter = new 
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
>     *private static final ExecutorFilter executorFilter = new 
> ExecutorFilter(16,32);*
>     private static final G10GPBMessageIoFilter gpbMessageFilter = new 
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
>  static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine = 
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
>                 G10MinaClient.CONNECTED, new G10MinaClient(processor));
>         IoHandler ioHandler = new 
> StateMachineProxyBuilder().setStateContextLookup(
>                 new IoSessionStateContextLookup(new StateContextFactory() {
>                     @Override
>                     public StateContext create() {
>                         final G10StateContext stateContext = new 
> G10StateContext();
>                         stateContext.setStartedTime(new Date());
>                         return stateContext;
>                     }
>                 })).create(IoHandler.class, stateMachine);
>                 
>                 
> //Global connector across the system, i.e multiple threads uses the same 
> connector.            
> NioSocketConnector connector = new NioSocketConnector();
>         connector.getFilterChain().addLast("LoggingFilter", 
> G10CaptureService.loggingFilter);
>         connector.getFilterChain().addLast("codecFilter", 
> G10CaptureService.probeCodecFilter);
>         connector.getFilterChain().addLast("executorFilter", 
> G10CaptureService.executorFilter);
>         connector.getFilterChain().addLast("gpbMessageFilter", 
> G10CaptureService.gpbMessageFilter);
>         connector.getFilterChain().addLast("keepAliveFilter", 
> G10CaptureService.keepAliveFilter);
>         connector.setHandler(ioHandler);
> }
>         
> public void StartRecordCapture()
> {
> connectionLock.lock();
> try
> {
> ConnectFuture primaryConnectFuture = connector.connect(primaryAddress, 
> initializer);
> //hungs forever if the no. of threads are more than 30
> primaryConnectFuture.awaitUninterruptibly();//no time out specified
> if (!primaryConnectFuture.isConnected()) 
> {
>                
>                     if (handleIOException(searchExpression, captureHan

[jira] [Resolved] (DIRMINA-1170) Will Apache MINA 2.1 and Apache MINA 2.2 evolve in dual branches?

[Jonathan Valliere (Jira)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Valliere resolved DIRMINA-1170.

Resolution: Information Provided

> Will Apache MINA 2.1 and Apache MINA 2.2 evolve in dual branches?
> -
>
> Key: DIRMINA-1170
> URL: https://issues.apache.org/jira/browse/DIRMINA-1170
> Project: MINA
>  Issue Type: Wish
>Reporter: Radar wen
>Priority: Major
>
> Excuse me, I would like to ask whether Apache MINA 2.1 and 2.2 will be 
> dual-branch evolution in the future?
> In other words, if the 2.1 version has vulnerabilities in the future, will 
> the 2.1.x version be released to fix the vulnerabilities? Or just release 
> 2.2.x to fix the vulnerabilities?



--
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-1170) Will Apache MINA 2.1 and Apache MINA 2.2 evolve in dual branches?

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17713339#comment-17713339
 ] 

Jonathan Valliere commented on DIRMINA-1170:


Yes, we maintain at least two branches as LTS. However new features will
likely only be added to the newest branch.




> Will Apache MINA 2.1 and Apache MINA 2.2 evolve in dual branches?
> -
>
> Key: DIRMINA-1170
> URL: https://issues.apache.org/jira/browse/DIRMINA-1170
> Project: MINA
>  Issue Type: Wish
>Reporter: Radar wen
>Priority: Major
>
> Excuse me, I would like to ask whether Apache MINA 2.1 and 2.2 will be 
> dual-branch evolution in the future?
> In other words, if the 2.1 version has vulnerabilities in the future, will 
> the 2.1.x version be released to fix the vulnerabilities? Or just release 
> 2.2.x to fix the vulnerabilities?



--
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

Re: [jira] [Created] (DIRMINA-1170) Will Apache MINA 2.1 and Apache MINA 2.2 evolve in dual branches?

[Jonathan Valliere]

Yes, we maintain at least two branches as LTS. However new features will
likely only be added to the newest branch.

On Mon, Apr 17, 2023 at 9:36 PM Radar wen (Jira)  wrote:

> Radar wen created DIRMINA-1170:
> --
>
>  Summary: Will Apache MINA 2.1 and Apache MINA 2.2 evolve in
> dual branches?
>  Key: DIRMINA-1170
>  URL: https://issues.apache.org/jira/browse/DIRMINA-1170
>  Project: MINA
>   Issue Type: Wish
> Reporter: Radar wen
>
>
> Excuse me, I would like to ask whether Apache MINA 2.1 and 2.2 will be
> dual-branch evolution in the future?
> In other words, if the 2.1 version has vulnerabilities in the future, will
> the 2.1.x version be released to fix the vulnerabilities? Or just release
> 2.2.x to fix the vulnerabilities?
>
>
>
> --
> 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
>
>

Re: Please help code review

[Jonathan Valliere]

I don’t know how to connect my personal account to my Apache permissions
for Apache repos.

On Thu, Sep 8, 2022 at 3:25 AM Emmanuel Lécharny 
wrote:

> Hi Jonathan,
>
> what is the pb you are having with GH ? Can't connect? Can't access to
> the mina-sshd repo?
>
> On 2022/09/07 12:32, Jonathan Valliere wrote:
> > Emmanuel do you have a link somewhere how to fix my connection to Apache
> on
> > GitHub?
> >
> > On Wed, Sep 7, 2022 at 4:29 AM Edward Zheng
> >  wrote:
> >
> >> Hi guys,
> >>
> >> I create a pull request several days ago.
> >> https://github.com/apache/mina-sshd/pull/242. I’m not sure if it’s a
> >> bugfix or my usage is wrong, could someone help review and give me some
> >> suggestions?
> >>
> >> Thanks.
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> >> For additional commands, e-mail: dev-h...@mina.apache.org
> >>
> >
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: Please help code review

[Jonathan Valliere]

Emmanuel do you have a link somewhere how to fix my connection to Apache on
GitHub?

On Wed, Sep 7, 2022 at 4:29 AM Edward Zheng
 wrote:

> Hi guys,
>
> I create a pull request several days ago.
> https://github.com/apache/mina-sshd/pull/242. I’m not sure if it’s a
> bugfix or my usage is wrong, could someone help review and give me some
> suggestions?
>
> Thanks.
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

[Jonathan Valliere]

https://github.com/apache/mina/blob/7893dfc29bb37dcef1345ffb482709902b6b6c9f/mina-core/src/main/java/org/apache/mina/transport/socket/nio/NioSocketSession.java#L94

On Aug 26, 2022 at 5:15:42 AM, Christoph John 
wrote:

> The constant PEER_ADDRESS is no longer present in the code in 2.2.x
>
> I can see however that in
> https://github.com/apache/mina/blob/7893dfc29bb37dcef1345ffb482709902b6b6c9f/mina-core/src/main/java/org/apache/mina/filter/ssl/SslFilter.java#L272
> and
> https://github.com/apache/mina/blob/7893dfc29bb37dcef1345ffb482709902b6b6c9f/mina-core/src/main/java/org/apache/mina/filter/ssl/SslFilter.java#L239
> the remoteAddress is used if it is not NULL.
> But I am not able to find out where the remoteAddress is set on the
> IoSession.
>
> Cheers,
> Chris.
>
> On 25.08.22 12:27, Jonathan Valliere wrote:
>
> It should be either doing it automatically or is a configurable option in
> the filter.
>
> I’m far away from my computer right now so I can’t check.
>
> On Wed, Aug 24, 2022 at 6:44 AM Christoph John  
> 
> wrote:
>
>
> Hi Jonathan,
>
> are you able to help me with the last item on the list (see quote below)?
>
> Thank you in advance and best regards,
> Chris.
>
> On 28.07.22 16:42, Emmanuel Lécharny wrote:
>
> 3. to use SNI we formerly set the "PEER_ADDRESS". Is this still possible?
> Please see 
> here:https://github.com/quickfix-j/quickfixj/blob/c4c963cdb2a6c4f1942f12bcfd890bff166788c2/quickfixj-core/src/main/java/quickfix/mina/ssl/SSLFilter.java#L66-L78
>
> Good question. I don't know... Jonathan ?
>
>
>
>
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557080-28christoph.j...@macd.com
>
> MACD GmbHOppenhoffallee 103
> 52066 Aachen, Germany 
> <https://www.google.com/maps/search/Oppenhoffallee+103%0D%0A52066+Aachen,+Germany?entry=gmail=g>
>  
> <https://www.google.com/maps/search/Oppenhoffallee+103%0D%0A52066+Aachen,+Germany?entry=gmail=g>www.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557080-28christoph.j...@macd.com
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germanywww.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

[Jonathan Valliere]

It should be either doing it automatically or is a configurable option in
the filter.

I’m far away from my computer right now so I can’t check.

On Wed, Aug 24, 2022 at 6:44 AM Christoph John 
wrote:

> Hi Jonathan,
>
> are you able to help me with the last item on the list (see quote below)?
>
> Thank you in advance and best regards,
> Chris.
>
> On 28.07.22 16:42, Emmanuel Lécharny wrote:
>
> 3. to use SNI we formerly set the "PEER_ADDRESS". Is this still possible?
> Please see here:
> https://github.com/quickfix-j/quickfixj/blob/c4c963cdb2a6c4f1942f12bcfd890bff166788c2/quickfixj-core/src/main/java/quickfix/mina/ssl/SSLFilter.java#L66-L78
>
> Good question. I don't know... Jonathan ?
>
>
>
>
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557080-28christoph.j...@macd.com
>
> MACD GmbHOppenhoffallee 103
> 52066 Aachen, Germany 
> www.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>

Re: Infinite loop in Apache Directory Server when using MINA 2.2.1

[Jonathan Valliere]

Was the fix in Mina or Directory?

On Wed, Aug 10, 2022 at 5:34 AM Emmanuel Lécharny 
wrote:

> I confirm. I built the LDAP API with Java 11 targetting Java 8, but it's
> not enough.
>
> Fixed in trunk.
>
> On 30/07/2022 10:23, Emmanuel Lécharny wrote:
> > Seems like it's an issue with a mixed Java version being used: the lib
> > built with Java 11 and running tests in Java 8, or something like that.
> >
> > Still investigating.
> >
> > On 30/07/2022 10:03, Emmanuel Lécharny wrote:
> >> Hi,
> >>
> >>
> >> I'm currently investiagting some infinite loop in Apache DS when
> >> setting up a LDAPS server. I have no idea what's going on atm - but I
> >> will keep you posted.
> >>
> >>
> >> Here is the trace I get when doing a kill -3:
> >>
> >>
> >> "NioProcesso--
> > *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> > T. +33 (0)4 89 97 36 50
> > P. +33 (0)6 08 33 32 61
> > emmanuel.lecha...@busit.com https://www.busit.com/
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: BindException on MacOS

[Jonathan Valliere]

I think it’s related to how the kqueue works in combination with the socket
shutdown cycle in SocketChannel.

It’s likely that our close event is triggering too early.

On Thu, Jul 28, 2022 at 9:31 AM Christoph John
 wrote:

> Hi,
>
> we have a test suite for QuickFIX/J which runs (at least) every day.
> Sometimes I can observe that
> there are BindExceptions because a port is already in use. Context: we
> stop and start an acceptor in
> quick succession and it is expected that the port is already available
> again when the acceptor
> starts the second time. To clean up all sessions and unbind we use the
> following code:
>
>
> https://github.com/quickfix-j/quickfixj/blob/de63b0c1c4d41bf1b6ce1add5305890b81e1ad51/quickfixj-core/src/main/java/quickfix/mina/SessionConnector.java#L445-L471
>
> IMHO this should be enough to free the port, however especially (or as I
> recall only) on MacOS the
> BindException occurs every once in a while.
>
> Question: I think this is some kind of race condition or glitch on MacOS.
> So it should be safe to
> ignore it I guess?
> Is there something I can do in the code to make sure that the port is
> really unbound?
>
> Thanks
> Chris
>
> --
> Christoph John
> Software Engineering
> T +49 241 557080-28
> christoph.j...@macd.com
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germany
> www.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>

Re: [VOTE] Apache MINA 2.2.1 release

[Jonathan Valliere]

+1

On Wed, Jul 20, 2022 at 9:46 AM Jeff Genender  wrote:

> +1
>
> Jeff
>
> > On Jul 20, 2022, at 7:41 AM, Emmanuel Lécharny 
> wrote:
> >
> > hi!
> >
> >
> > This is a vote for MINA 2.2.1.
> >
> > This version just fixes an issue in the export declaration for OSGi: a
> missing comma made MINA 2.2.0 impossible to use by application that
> leverage OSGi, due to a concatenation of package name.
> >
> >
> > A temporary tag has been created (it can be removed if the vote is not
> approved) :
> >
> >
> https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=023fdeb33e2a783498ef23a5cdb57d051ffbe65d
> >
> >
> >
> > The final artifacts are stored in a staging repository:
> > https://repository.apache.org/content/repositories/orgapachemina-1077
> >
> >
> > The distributions are available for download on :
> > https://dist.apache.org/repos/dist/dev/mina/mina/2.2.1
> >
> > Let us vote :
> > [ ] +1 | Release MINA 2.2.1
> > [ ] ± | Abstain
> > [ ] -1 | Do *NOT*   release MINA 2.2.1
> >
> > --
> > *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> > T. +33 (0)4 89 97 36 50
> > P. +33 (0)6 08 33 32 61
> > emmanuel.lecha...@busit.com https://www.busit.com/
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> > For additional commands, e-mail: dev-h...@mina.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
> --
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.

Re: [Vote] MINA 2.2.0 release

[Jonathan Valliere]

 mine is binding so we should be over the threshold now


On Jul 16, 2022 at 11:54:40 AM, Jeff Genender  wrote:

> I dont remember if I voted or not…but if not… here it is…
>
> Jeff
>
>
> On Jul 16, 2022, at 8:49 AM, Emmanuel Lécharny 
> wrote:
>
>
>
>
> On 16/07/2022 11:31, Christoph John wrote:
>
> > +1
>
>
> Thanks!
>
>
> > But don't know if my vote counts.
>
>
> Every vote *do* count, even if not all the votes are binding. The idea is
> that if someone casts a -1, that means there is something that requires
> some investigation.
>
>
> Typically, when I started the vote last week, you correctly asked if the
> pb you had was fixed, and we had to spend some extra time verifying that it
> was indeed the case.
>
>
>
> So please, feel free to vote :-)
>
>
> > Thanks for your investigation. I will take a closer look next week.
>
> > Cheers
>
> > Chris
>
> > Jul 16, 2022 10:32:02 Emmanuel Lécharny :
>
> >> Hi,
>
> >>
>
> >> I need one more vote at least to get the release out.
>
> >>
>
> >> I'm confident the pb Christoph had was due to some bad test, not to a
> MINA issue.
>
> >>
>
> >> Thanks !
>
> >>
>
> >> On 05/07/2022 09:38, Christoph John wrote:
>
> >>> Hi Emmanuel
>
> >>> Did you manage to fix the bug which we talked about in the mail thread
> from May regarding the M1 milestone?
>
> >>> Thanks
>
> >>> Chris
>
> >>> 04.07.2022 23:43:37 Emmanuel Lécharny :
>
> >>> Hi!
>
> 
>
> 
>
>  it has been a couple of months now that I cut a version of MINA
> 2.2.0, but haven't started a vote, because I wanted to test that exception
> were properly handled when generated from the SslFilter. It took may way
> longer to check that, mainly due to external factors).
>
> 
>
>  Anyway, I'm done with the test, all is nominal, so here is a formal
> vote for MINA 2.2.0.
>
> 
>
>  This version comes with a complete rewrite of the SSL layer, thanks
> for Jonathan hard work !
>
> 
>
> 
>
>  A temporary tag has been created (it can be removed if the vote is
> not approved) :
>
> 
>
> 
> https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4
>
> 
>
> 
>
> 
>
>  The newly approved Nexus has been used for the preparation of this
>
>  release and all final artifacts are stored in a staging repository:
>
>  https://repository.apache.org/content/repositories/orgapachemina-1051
>
> 
>
> 
>
>  The distributions are available for download on :
>
>  https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0
>
> 
>
>  Let us vote :
>
>  [ ] +1 | Release MINA 2.2.0
>
>  [ ] ± | Abstain
>
>  [ ] -1 | Do *NOT*  release MINA 2.2.0
>
> 
>
>  -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
>
>  T. +33 (0)4 89 97 36 50
>
>  P. +33 (0)6 08 33 32 61
>
>  emmanuel.lecha...@busit.com https://www.busit.com/
>
> 
>
>  -
>
>  To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
>
>  For additional commands, e-mail: dev-h...@mina.apache.org
>
> >>
>
> >> --
>
> >> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
>
> >> T. +33 (0)4 89 97 36 50
>
> >> P. +33 (0)6 08 33 32 61
>
> >> emmanuel.lecha...@busit.com https://www.busit.com/
>
>
> --
>
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
>
> T. +33 (0)4 89 97 36 50
>
> P. +33 (0)6 08 33 32 61
>
> emmanuel.lecha...@busit.com 
> https://www.busit.com/ 
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org  dev-unsubscr...@mina.apache.org>
>
> For additional commands, e-mail: dev-h...@mina.apache.org  dev-h...@mina.apache.org>
>
>

Re: [Vote] MINA 2.2.0 release

[Jonathan Valliere]

 +1

CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.


On Jul 16, 2022 at 4:31:51 AM, Emmanuel Lécharny 
wrote:

> Hi,
>
> I need one more vote at least to get the release out.
>
> I'm confident the pb Christoph had was due to some bad test, not to a
> MINA issue.
>
> Thanks !
>
> On 05/07/2022 09:38, Christoph John wrote:
>
> Hi Emmanuel
>
>
> Did you manage to fix the bug which we talked about in the mail thread
> from May regarding the M1 milestone?
>
>
> Thanks
>
> Chris
>
>
> 04.07.2022 23:43:37 Emmanuel Lécharny :
>
>
> > Hi!
>
> >
>
> >
>
> > it has been a couple of months now that I cut a version of MINA 2.2.0,
> but haven't started a vote, because I wanted to test that exception were
> properly handled when generated from the SslFilter. It took may way longer
> to check that, mainly due to external factors).
>
> >
>
> > Anyway, I'm done with the test, all is nominal, so here is a formal vote
> for MINA 2.2.0.
>
> >
>
> > This version comes with a complete rewrite of the SSL layer, thanks for
> Jonathan hard work !
>
> >
>
> >
>
> > A temporary tag has been created (it can be removed if the vote is not
> approved) :
>
> >
>
> >
> https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4
>
> >
>
> >
>
> >
>
> > The newly approved Nexus has been used for the preparation of this
>
> > release and all final artifacts are stored in a staging repository:
>
> > https://repository.apache.org/content/repositories/orgapachemina-1051
>
> >
>
> >
>
> > The distributions are available for download on :
>
> > https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0
>
> >
>
> > Let us vote :
>
> > [ ] +1 | Release MINA 2.2.0
>
> > [ ] ± | Abstain
>
> > [ ] -1 | Do *NOT*   release MINA 2.2.0
>
> >
>
> > --
>
> > *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
>
> > T. +33 (0)4 89 97 36 50
>
> > P. +33 (0)6 08 33 32 61
>
> > emmanuel.lecha...@busit.com https://www.busit.com/
>
> >
>
> > -
>
> > To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
>
> > For additional commands, e-mail: dev-h...@mina.apache.org
>
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

[Jonathan Valliere]

Sooo… do I need to look into this or was this resolved?

On Fri, Jul 8, 2022 at 11:51 PM Emmanuel Lécharny 
wrote:

> The changes I did were to ensure that any ouutbound data are sent when a
> TLS erroroccurs, because the Alert must be sent no matter what. This is
> critical for a client to know what is the cause of the failure
> (typically when a bad certificate is provided - expired, revoked, etc -):
> https://datatracker.ietf.org/doc/html/rfc5246#section-7.2
>
> I also checked that in this case an exception is propagated up to the
> IoHandler for teh server to be informed about the situuation.
>
>
> On 06/07/2022 12:42, Jonathan Valliere wrote:
> >   What test are you trying?  Emmanuel made changes from the original
> design
> > to cause it to throw on the filter.  My original design threw on the
> filter
> > but only during a subsequent read or write action thereby enforcing
> strong
> > concurrency within the pipeline.
> >
> > On Jul 6, 2022 at 3:53:57 AM, Christoph John
> >  wrote:
> >
> >> Ok, the tests in QuickFIX/J which expect the exception to be caught in a
> >> filter still don't work.
> >> I recall that you also did some changes in other Apache projects to make
> >> it work with MINA 2.2.0. Could it be that I also need to adapt
> something in
> >> this regard?
> >>
> >> Thanks
> >> Chris
> >>
> >> Jul 5, 2022 18:47:09 Emmanuel Lécharny :
> >>
> >> I have tested that the exception gets propagated before launching the
> vote
> >> to be clear :-)
> >>
> >>
> >> On 05/07/2022 18:17, Christoph John wrote:
> >>
> >>> Sorry, no. The last message regarding this was:
> >>
> >>>
> >>
> >>> --snip-
> >>
> >>>
> >>
> >>> 11.04.2022 09:37:30 Emmanuel Lécharny :
> >>
> >>> Hi Christophe,
> >>
> >>> sorry, my late mail was off base.
> >>
> >>> The pb here is that the SSLEngine excpeiton is not propagated to the
> >> handler, when it should.
> >>
> >>> My guess is that we have some missing call somewhere in the stack. I'm
> >> going to check that out.
> >>
> >>> On 11/04/2022 00:15, Christoph John wrote:
> >>
> >>>> Hi,
> >>
> >>>> thanks Jonathan and Emmanuel for working on this!
> >>
> >>>> I tried to integrate this into QuickFIX/J and it compiles
> successfully.
> >> However there are some tests failing that expect an Exception. For
> example
> >> we have
> >>
> >>>>
> >>
> https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
> >>
> >>>> Up to now it was tried to get the Exception via a filter in the chain.
> >> This no longer seems to work but I think I can see the error getting
> thrown
> >> in the log:
> >>
> >>>> SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false] task() -
> >> storing error {}
> >>
> >>>> javax.net.ssl.SSLHandshakeException: No available authentication
> scheme
> >>
> >>>>  at
> >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
> >>
> >>>>  at
> >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
> >>
> >>>>  at
> >>
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
> >>
> >>>>  at
> >>
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
> >>
> >>>>  at
> >>
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
> >>
> >>>>  at
> >>
> java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:972)
> >>
> >>>>  at
> >>
> java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:961)
> >>
> >>>>  at
> >> java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
> >>
> >>>>  at
> >>
> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1246)
> >>
> >>>>  at
> >>
> java.base/sun.security.ssl.ClientHello$T13ClientHell

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

[Jonathan Valliere]

 What test are you trying?  Emmanuel made changes from the original design
to cause it to throw on the filter.  My original design threw on the filter
but only during a subsequent read or write action thereby enforcing strong
concurrency within the pipeline.

On Jul 6, 2022 at 3:53:57 AM, Christoph John
 wrote:

> Ok, the tests in QuickFIX/J which expect the exception to be caught in a
> filter still don't work.
> I recall that you also did some changes in other Apache projects to make
> it work with MINA 2.2.0. Could it be that I also need to adapt something in
> this regard?
>
> Thanks
> Chris
>
> Jul 5, 2022 18:47:09 Emmanuel Lécharny :
>
> I have tested that the exception gets propagated before launching the vote
> to be clear :-)
>
>
> On 05/07/2022 18:17, Christoph John wrote:
>
> > Sorry, no. The last message regarding this was:
>
> >
>
> > --snip-
>
> >
>
> > 11.04.2022 09:37:30 Emmanuel Lécharny :
>
> > Hi Christophe,
>
> > sorry, my late mail was off base.
>
> > The pb here is that the SSLEngine excpeiton is not propagated to the
> handler, when it should.
>
> > My guess is that we have some missing call somewhere in the stack. I'm
> going to check that out.
>
> > On 11/04/2022 00:15, Christoph John wrote:
>
> >> Hi,
>
> >> thanks Jonathan and Emmanuel for working on this!
>
> >> I tried to integrate this into QuickFIX/J and it compiles successfully.
> However there are some tests failing that expect an Exception. For example
> we have
>
> >>
> https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
>
> >> Up to now it was tried to get the Exception via a filter in the chain.
> This no longer seems to work but I think I can see the error getting thrown
> in the log:
>
> >> SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false] task() -
> storing error {}
>
> >> javax.net.ssl.SSLHandshakeException: No available authentication scheme
>
> >> at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
>
> >> at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>
> >> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
>
> >> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>
> >> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
>
> >> at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:972)
>
> >> at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:961)
>
> >> at
> java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
>
> >> at
> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1246)
>
> >> at
> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1182)
>
> >> at
> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:840)
>
> >> at
> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:801)
>
> >> at
> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
>
> >> at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
>
> >> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1277)
>
> >> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1264)
>
> >> at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
>
> >> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1209)
>
> >> at
> org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)
>
> >> at
> org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)
>
> >> at
> org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
>
> >> at
> org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)
>
> >> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
>
> >> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
>
> >> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
>
> >> at
> org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
>
> >> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
>
> >> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:643)
>
> >> at
> 

Re: Has anyone ever used the HTTP Module?

[Jonathan Valliere]

What HTTP module?

On Wed, Jun 22, 2022 at 11:26 AM Emmanuel Lécharny 
wrote:

> Hi !
>
> Just wondering if anyone has ever used this module. To me, it seems
> *really* like a proof of concept.
>
> Thanks !
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> 
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: MINA 2.2.0-M1

[Jonathan Valliere]

 Its now exposed through this Attribute
https://github.com/apache/mina/blob/9c237cabb4ecc5ef8c379cc2d7a75c9d09c164cb/mina-core/src/main/java/org/apache/mina/filter/ssl/SslFilter.java#L57

This change ensures that the developer can only access that object after
the handshake is complete.

CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.


On Apr 11, 2022 at 7:07:42 AM, Christoph John
 wrote:

> Hi Emmanuel,
>
> another short question that came up when checking my unit tests. Formerly
> there was a method
> SslFilter.getSslSession:
>
> https://github.com/apache/mina/blob/35aafff17ee3fc655844058b28489c4c14af65fa/mina-core/src/main/java/org/apache/mina/filter/ssl/SslFilter.java#L199
>
> What is the replacement for that? I want to check the peer certificates of
> the SSLSession.
>
> Thanks in advance and best regards,
> Christoph.
>
>
> On 11.04.22 10:53, Emmanuel Lécharny wrote:
>
> Hi!
>
>
> I've made a slight mistake yesterday evening (or should I say this early
> this morning): I name the
>
> release 2.2.0.
>
>
> I haven't yet launch the vote, so I may revert and delete the release to
> name it 2.2.0-M1, and
>
> also check the pb Cristoph is mentionning (the non propagation of an
> exception to the IoAdapter
>
> when the SSLEngine throw it).
>
>
> I'll keep you inform...
>
>
>
> On 09/04/2022 00:26, Emmanuel Lécharny wrote:
>
> > Hi !
>
> >
>
> > I will start to cut a first milestone for the MINA 2.2.X branch. It has
> been tested on Apache
>
> > Ftpserver, Ldap API and Directory Server with success.
>
> >
>
> > There will probably be more milestone, but that would be a first step.
>
> >
>
> > The main changes are:
>
> > - a complete redesign of the TLS handling
>
> > - the removal of the SslFilter.DISABLE_ENCRYPTION_ONCE attribute, which
> is either replaced by a
>
> > dedicated filter, or the encapsulation of the message in a
> DisableEncryptWriteRequest interface
>
> >
>
> >
>
> > I'll do that this week-end.
>
> >
>
> > Thanks !
>
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557080-28
> christoph.j...@macd.com
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germany
> www.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>

Re: Releasing a MINA 2.2.0-alpha soon ?

[Jonathan Valliere]

Did I cause that problem because I remember there being a bug request
because we weren’t applying the Need and Want from the Impl config.

On Fri, Apr 1, 2022 at 10:55 AM Emmanuel Lécharny 
wrote:

> Got it !!!
>
> What a nasty bug it was...
>
> The new SslFilter.createEngine() method was doing:
>
> protected SSLEngine createEngine(IoSession session, InetSocketAddress
> addr) {
>  SSLEngine sslEngine = (addr != null) ?
> sslContext.createSSLEngine(addr.getHostString(), addr.getPort())
>  : sslContext.createSSLEngine();
>  sslEngine.setNeedClientAuth(needClientAuth);
>  sslEngine.setWantClientAuth(wantClientAuth);
> ...
>
> And in SslEngineImpl :
>
>  public synchronized void setNeedClientAuth(boolean need) {
>  conContext.sslConfig.clientAuthType =
>  (need ? ClientAuthType.CLIENT_AUTH_REQUIRED :
>  ClientAuthType.CLIENT_AUTH_NONE);
>  }
>
> plus
>
>  public synchronized void setWantClientAuth(boolean want) {
>  conContext.sslConfig.clientAuthType =
>  (want ? ClientAuthType.CLIENT_AUTH_REQUESTED :
>  ClientAuthType.CLIENT_AUTH_NONE);
>  }
>
> when you set Need & Want, the later wins. Here, I had Need but not Want,
> so it ends with ClientAuthType.CLIENT_AUTH_NONE :/
>
> You can't have both, you need to pick the one that has to be set and
> ignore the other. In MINA 2.1.5, we have :
>
>  // Those parameters are only valid when in server mode
>  if (sslFilter.isWantClientAuth()) {
>  sslEngine.setWantClientAuth(true);
>  }
>
>  if (sslFilter.isNeedClientAuth()) {
>  sslEngine.setNeedClientAuth(true);
>  }
>
> which only call the proper setting. Of course, if you set both to true,
> you'll end with NEED, which is just fine.
>
> On 01/04/2022 16:18, Emmanuel Lécharny wrote:
> > Some progress:
> >
> > With MINA 2.1.5, the SSLEngine.SSLConfiguration instance has the
> > clientAuthType set to CLIENT_AUTH_REQUIRED, while in MINA 2.2.0, it's
> > set to CLIENT_AUTH_NONE. That explain why the CertificateRequest is not
> > sent to the client.
> >
> > Now to understand why this flag is improperly set...
> >
> > On 01/04/2022 11:06, Emmanuel Lécharny wrote:
> >> Still fighting...
> >>
> >> When using MINA 2.1.6, I see that the client (FTPSCLient, a java class
> >> that is not using MINA) sends a client Certificate to the server after
> >> having received a CertificateRequest:
> >>
> >> javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.544
> >> CEST|CertificateRequest.java:692|Consuming CertificateRequest
> >> handshake message (
> >> "CertificateRequest": {
> >>"certificate types": [ecdsa_sign, rsa_sign, dss_sign]
> >>"supported signature algorithms": [ecdsa_secp256r1_sha256,
> >> ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256,
> >> rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256,
> >> rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256,
> >> rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224,
> >> rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
> >>"certificate authorities": [CN=ftpserver, CN=ftpclient]
> >> }
> >> )
> >> ...
> >> javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.546
> >> CEST|ServerHelloDone.java:151|Consuming ServerHelloDone handshake
> >> message (
> >> 
> >> )
> >> javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.547
> >> CEST|CertificateMessage.java:330|Produced client Certificate handshake
> >> message (
> >> "Certificates": [
> >>"certificate" : {
> >>  "version": "v3",
> >>  "serial number"  : "60 38 4B B4",
> >>  "signature algorithm": "SHA256withRSA",
> >>  "issuer" : "CN=ftpclient",
> >>  "not before" : "2021-02-26 02:15:32.000 CET",
> >>  "not  after" : "2031-02-26 02:15:32.000 CET",
> >>  "subject": "CN=ftpclient",
> >>  "subject public key" : "RSA"}
> >> ]
> >> )
> >> ...
> >>
> >> With MINA 2.2.0, I don't see any CertificateRequest being sent by the
> >> server. Whic

Re: MINA and TLS 1.3 (1ms sleep hack?)

[Jonathan Valliere]

 Another way to do that is to have the SslFilter -> Your Clear Text Control
Plane Filter

The Control Plane Filter can conditionally wrap a WriteRequest in a
DisableEncryptWriteRequest.  This guarantees that ONLY that message
bypasses the SslFilter

CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.


On Mar 31, 2022 at 4:34:18 PM, Emmanuel Lécharny 
wrote:

> Hi Guus,
>
> On 31/03/2022 19:43, Guus der Kinderen wrote:
>
> Thanks for the fast response Emmanuel,
>
>
> Although I was able to build 2.2.0-SNAPSHOT, it doesn't seem to be API
>
> compatible with 2.1.3.
>
>
> Things that I ran into:
>
>
>   * SslFilter.DISABLE_ENCRYPTION_ONCE no longer exists (which we use to
>
> implement StartTLS).
>
>
> Yes, it was a source of problem. The way we deal with the requirement to
> send the StartTLS response in clear text *before* setting the SslFilter
> now is to use a dedicated filter. here is what we do in Apache Diectory
> Server:
>
> public class StartTlsFilter extends IoFilterAdapter
> {
> /**
>  * {@inheritDoc}
>  */
> @Override
> public void filterWrite( NextFilter nextFilter, IoSession session,
> WriteRequest writeRequest ) throws Exception
> {
> if ( writeRequest.getOriginalMessage() instanceof
> StartTlsResponse )
> {
> // We need to bypass the SslFilter
> IoFilterChain chain = session.getFilterChain();
>
> for ( IoFilterChain.Entry entry : chain.getAll() )
> {
> IoFilter filter = entry.getFilter();
>
> if ( filter instanceof SslFilter )
> {
> entry.getNextFilter().filterWrite( session,
> writeRequest );
> }
> }
> }
> else
> {
> nextFilter.filterWrite( session, writeRequest );
> }
> }
> }
>
> This is pretty straight forward: when we go through this filter with a
> StartTLS response message, we bypass the SslFilter, otherwise we call it.
>
>
>   * SslFilter.SSL_SESSION no longer exists. Is SslFilter.SSL_SECURED a
>
> drop-in replacement?
>
>
> Yes. For instance, in FtpServer:
>
> if (getFilterChain().contains(SslFilter.class)) {
> SSLSession sslSession =
> (SSLSession)getAttribute(SslFilter.SSL_SECURED);
>
>
>   * SslFilter.setUseClientMode(boolean) no longer exists.
>
>
> It's computed automatically:
>
> sslEngine.setUseClientMode(!session.isServer());
>
> You may want to add the isServer() method in your IoSession
> implementation, but by default it's defined in the AbstractIoSession to be
> :
>
>
> @Override
> public boolean isServer() {
> return (getService() instanceof IoAcceptor);
> }
>
>
> WIth all that commented out, I'm still getting errors, but I'm not sure
>
> if that's the same error, or if I'm now seeing a new error because I
>
> broke StartTLS (which our test depends on)
>
>
> Most certainly it's broken because of teh lack of clear text response
> before the filter is set. See the added filter upper.
>
>
> On Thu, Mar 31, 2022 at 3:37 PM Emmanuel Lécharny 
> > wrote:
>
>
> Hi Guus,
>
>
> I have successfully ran Apache Directory LDAP API and Server with MINA
>
> 2.2.0-SNAPSHOT, which has a fully rewritten SSL handling code.
>
>
> It seems there are some kind of race condition in MINA 2.0.X/2.1.X
>
> and I
>
> expect MINA 2.2.X solve this issue.
>
>
> Could you give it a try ? You'll have to build the 2.2.X branch:
>
>
> $ git clone -b 2.2.X https://gitbox.apache.org/repos/asf/mina.git
>
>  mina-2.2.X
>
> $ cd mina-2.2.X
>
> $ mvn clean install
>
>
> Just let me know if it's any better...
>
>
> On 31/03/2022 14:53, Guus der Kinderen wrote:
>
>  > Hi Emanuel,
>
>  >
>
>  > I remember that you wrote that you were engaged in an epic battle
>
> with
>
>  > an elusive TLS 1.3 bug in MINA. I'm now running into an issue
>
> that is
>
>  > specific to TLS 1.3, which occurs in MINA 2.1.3 as well as 2.1.6
>
> (I did
>
>  > not try other versions), and does /not/ occur with a connection
>
> manager
>
>  > that is not powered by MINA.
>
>  >
>
>  > The work-around that a third party developer found is surprising.
>
> They
>
>  > add a 1ms delay before starting to send data over a socket that
>
> has just
>
>  > finished the TLS handshake. With that delay, the problem is
>
> consistently
>
>  > gone. Without that delay, it consistently is reproducible.
>
>  >
>
>  > Their evaluation of the problem is documented here:
>
>  > https://github.com/xmppjs/xmpp.js/issues/889
>
> 
>
>  > 

Re: Releasing a MINA 2.2.0-alpha soon ?

[Jonathan Valliere]

Are you trying to get the peer cert after the filter emits the connected
after the handshake completes? If you do it too early it won’t populate.

On Fri, Mar 25, 2022 at 2:33 PM Emmanuel Lécharny 
wrote:

> Hi!
>
> following the effort put in rewriting the Sslfilter (and all the inner
> code) by Jonathan lately, I would like to know if we could mive forward
> with an alpha version of this work.
>
> I have tested it with Apache LDAP API and Apache Directory Server, with
> success. I still have some work to do on FtpServer to have it working
> with 2.2.X, we get some NPE when trying to fetch the peer certificate
> from the SSLSession (for some unkown reason, when I call
> sslSession.getPeerCertiticate() it returns null).
>
> Wdyt ?
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> 
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: [VOTE] Apache FtpServer 1.1.4/1.2.0 releases

[Jonathan Valliere]

+1

On Tue, Mar 8, 2022 at 1:23 AM Emmanuel Lecharny 
wrote:

> Hi,
>
> A mistake was made while releasing Apache MINA FtpServer 1.1.3: the
> API was broken. Those two releases are fixing this mistake:
> - 1.1.4 will revert back ion the changes that broke the API ascendant
> compatibility
> - 1.2.0 will contain the changes in the API that makes it possible to
> specify more than one enabled TLS version
>
> The newly approved Nexus has been used for the preparation of this
> release and all final artifacts are stored in a staging repository:
>
> 1.1.4:
> https://repository.apache.org/content/repositories/orgapachemina-1069/
> 1.2.0:
> https://repository.apache.org/content/repositories/orgapachemina-1068/
>
>
> The distributions are available for download on :
>
> 1.1.4:
>
> https://repository.apache.org/content/repositories/orgapachemina-&069/org/apache/ftpserver/ftpserver/1.1.4/
>
> 1.2.0:
>
> https://repository.apache.org/content/repositories/orgapachemina-1068/org/apache/ftpserver/ftpserver/1.2.0/
>
> Packages can also be downloaded from:
>
> 1.1.4: https://dist.apache.org/repos/dist/dev/mina/ftpserver/1.1.4/
> 1.2.0: https://dist.apache.org/repos/dist/dev/mina/ftpserver/1.2.0/
>
> Let us vote :
> [ ] +1 | Release Apache FtpServer 1.1.4 and 1.2.0
> [ ] +/- | Abstain
> [ ] -1 | Do *NOT* release Apache FtpServer 1.1.4 and 1.2.0
>
> Thanks !
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
> --
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.

Re: SSL handler and SSLEngine tasks

[Jonathan Valliere]

*Cores

On Wed, Mar 2, 2022 at 8:31 PM Jonathan Valliere  wrote:

> I was using an Executor to limit the number of threads that consume this
> action to prevent the server from an SSL attack spinning on all the codes.
>
> On Wed, Mar 2, 2022 at 6:43 PM Emmanuel Lécharny 
> wrote:
>
>> FTR, there is no point in using an executor to try to spread the load of
>> tasks across many threads:
>>
>>  private static class DelegatedTask implements Runnable {
>>  private final SSLEngineImpl engine;
>>
>>  DelegatedTask(SSLEngineImpl engineInstance) {
>>  this.engine = engineInstance;
>>  }
>>
>>  @Override
>>  public void run() {
>>  synchronized (engine) { <<-- This...
>>
>> Whatever we do, when a task is executed, it will block any other
>> DelegatedTask.
>>
>>
>> On 02/03/2022 15:33, Emmanuel Lécharny wrote:
>> >
>> >
>> > On 02/03/2022 13:57, Jonathan Valliere wrote:
>> >>
>> >> CONFIDENTIALITY NOTICE: The contents of this email message and any
>> >> attachments are intended solely for the addressee(s) and may contain
>> >> confidential and/or privileged information and may be legally
>> >> protected from disclosure.
>> >>
>> >>
>> >> On Wed, Mar 2, 2022 at 7:33 AM Emmanuel Lécharny > >> <mailto:elecha...@gmail.com>> wrote:
>> >>
>> >>
>> >>
>> >> On 02/03/2022 12:36, Jonathan Valliere wrote:
>> >>  > It’s already running in an Executor
>> >>
>> >> Can you clarify ? What is running in an executor?
>> >>
>> >>
>> >> The SSLEngine delegated task is run in a thread pool executor outside
>> >> of the filterchain.
>> >>
>> https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java#L617
>> >> <
>> https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java#L617>
>>
>> >>
>> >>
>> >>
>> >>which is why it’s a runnable
>> >>
>> >> Well, it's not related. You can create Runnable instances and
>> execute
>> >> them outside of an executor.
>> >>
>> >> .  The
>> >>  > Runnable defers the actual execution logic to the execute task
>> >> function
>> >>  > which should be the one that is looping to perform all queued
>> >> tasks from
>> >>  > the SSL Engine.
>> >>
>> >> Yes, but my point is that we could spawn threads inside the execute
>> >> task
>> >> (one thread per task) instead of creating an executor inside the
>> >> schedule_task.
>> >>
>> >>
>> >> It uses a configured Executor instance which is generally the same one
>> >> for every SSL session.
>> >>
>> https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandler.java#L84
>> >> <
>> https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandler.java#L84>
>>
>> >>
>> >>
>> https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L72
>> >> <
>> https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L72>
>>
>> >>
>> >
>> > Ok, so we are on the same page here.
>> >
>> > So the goal here is to spawn a thread that will process the
>> > delegatedTask and let the IoProcessor deal with another session.
>> >
>> > That's pretty much needed considering the potentially costly task done
>> > in the delegated task.
>> >
>> >
>> >
>> >>
>> >>
>> >> My fear is that bu creating a new thread for each schedule_task
>> >> call is
>> >> that we may have many pending threads waiting for the thread
>> >> executing
>> >> execute_task to be completed, because of the synchronized nature
>> >> of the
&

Re: SSL handler and SSLEngine tasks

[Jonathan Valliere]

I was using an Executor to limit the number of threads that consume this
action to prevent the server from an SSL attack spinning on all the codes.

On Wed, Mar 2, 2022 at 6:43 PM Emmanuel Lécharny 
wrote:

> FTR, there is no point in using an executor to try to spread the load of
> tasks across many threads:
>
>  private static class DelegatedTask implements Runnable {
>  private final SSLEngineImpl engine;
>
>  DelegatedTask(SSLEngineImpl engineInstance) {
>  this.engine = engineInstance;
>  }
>
>  @Override
>  public void run() {
>  synchronized (engine) { <<-- This...
>
> Whatever we do, when a task is executed, it will block any other
> DelegatedTask.
>
>
> On 02/03/2022 15:33, Emmanuel Lécharny wrote:
> >
> >
> > On 02/03/2022 13:57, Jonathan Valliere wrote:
> >>
> >> CONFIDENTIALITY NOTICE: The contents of this email message and any
> >> attachments are intended solely for the addressee(s) and may contain
> >> confidential and/or privileged information and may be legally
> >> protected from disclosure.
> >>
> >>
> >> On Wed, Mar 2, 2022 at 7:33 AM Emmanuel Lécharny  >> <mailto:elecha...@gmail.com>> wrote:
> >>
> >>
> >>
> >> On 02/03/2022 12:36, Jonathan Valliere wrote:
> >>  > It’s already running in an Executor
> >>
> >> Can you clarify ? What is running in an executor?
> >>
> >>
> >> The SSLEngine delegated task is run in a thread pool executor outside
> >> of the filterchain.
> >>
> https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java#L617
> >> <
> https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java#L617>
>
> >>
> >>
> >>
> >>which is why it’s a runnable
> >>
> >> Well, it's not related. You can create Runnable instances and
> execute
> >> them outside of an executor.
> >>
> >> .  The
> >>  > Runnable defers the actual execution logic to the execute task
> >> function
> >>  > which should be the one that is looping to perform all queued
> >> tasks from
> >>  > the SSL Engine.
> >>
> >> Yes, but my point is that we could spawn threads inside the execute
> >> task
> >> (one thread per task) instead of creating an executor inside the
> >> schedule_task.
> >>
> >>
> >> It uses a configured Executor instance which is generally the same one
> >> for every SSL session.
> >>
> https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandler.java#L84
> >> <
> https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandler.java#L84>
>
> >>
> >>
> https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L72
> >> <
> https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L72>
>
> >>
> >
> > Ok, so we are on the same page here.
> >
> > So the goal here is to spawn a thread that will process the
> > delegatedTask and let the IoProcessor deal with another session.
> >
> > That's pretty much needed considering the potentially costly task done
> > in the delegated task.
> >
> >
> >
> >>
> >>
> >> My fear is that bu creating a new thread for each schedule_task
> >> call is
> >> that we may have many pending threads waiting for the thread
> >> executing
> >> execute_task to be completed, because of the synchronized nature
> >> of the
> >> execute_task method. All in all, it seems to create a bottleneck
> >> that is
> >> going to be problematic, when the tasks are supposed to be ran
> >> concurrently.
> >>
> >> Am I missing something ?
> >>
> >>
> >> If more than one scheduled task could happen (which I doubt it
> >> honestly) yes they would block on each other because the execute_task
> >> function is synchronized. 

Re: SSL handler and SSLEngine tasks

[Jonathan Valliere]

CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.


On Wed, Mar 2, 2022 at 7:33 AM Emmanuel Lécharny 
wrote:

>
>
> On 02/03/2022 12:36, Jonathan Valliere wrote:
> > It’s already running in an Executor
>
> Can you clarify ? What is running in an executor?
>

The SSLEngine delegated task is run in a thread pool executor outside of
the filterchain.
https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java#L617

>
>   which is why it’s a runnable
>
> Well, it's not related. You can create Runnable instances and execute
> them outside of an executor.
>
> .  The
> > Runnable defers the actual execution logic to the execute task function
> > which should be the one that is looping to perform all queued tasks from
> > the SSL Engine.
>
> Yes, but my point is that we could spawn threads inside the execute task
> (one thread per task) instead of creating an executor inside the
> schedule_task.
>

It uses a configured Executor instance which is generally the same one for
every SSL session.
https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandler.java#L84
https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L72


>
> My fear is that bu creating a new thread for each schedule_task call is
> that we may have many pending threads waiting for the thread executing
> execute_task to be completed, because of the synchronized nature of the
> execute_task method. All in all, it seems to create a bottleneck that is
> going to be problematic, when the tasks are supposed to be ran
> concurrently.
>
> Am I missing something ?
>

If more than one scheduled task could happen (which I doubt it honestly)
yes they would block on each other because the execute_task function is
synchronized.  But we want to block here because the delegated tasks MUST
be executed in order, if a second scheduled task is created, it's a
guaranteed that any subsequent delegated tasks are actually executed and
not lost in the time between a previous execution of a delegated task and
the exit of the synchronized block in execute_task.  We don't want any
weird race conditions here.

I wanted to ensure that the async captured exception elevates to the Filter
exception handler in a very standard and known way.  A simple way to force
the handling of the exception on the filter-chain is to cause a throwing of
a special WriteRequest which will flow down the filter chain and cause the
error to be thrown.  You already see where I'm
https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java#L473
writing the EncryptedWriteRequest from the async execute_task function.
Just create an EncryptedErrorRequest or some other object to write and
force the trigger.


> >
> > On Wed, Mar 2, 2022 at 3:51 AM Emmanuel Lécharny  > <mailto:elecha...@gmail.com>> wrote:
> >
> > Hi,
> >
> > an alternative would be to modify the execute_task method to become:
> >
> >   synchronized protected void execute_task(NextFilter next) {
> >   Runnable task = null;
> >
> >   while ((task = mEngine.getDelegatedTask()) != null) {
> >   try {
> >   if (ENABLE_ASYNC_TASKS && (mExecutor != null)) {
> >   mExecutor.execute(task);
> >   } else {
> >   task.run();
> >   }
> >
> >   write_handshake(next);
> >   } catch (SSLException e) {
> >
> > So here, we push the tasks into an executor to be processed
> > concurrently.
> >
> > On 02/03/2022 07:05, Emmanuel Lécharny wrote:
> >  > Hi Jonathan,
> >  >
> >  > I wonder if using an executor to process SSLEngine tasks is
> > useful at
> >  > all, considering that the execute_task method is synchronized:
> >  >
> >  >  protected void schedule_task(NextFilter next) {
> >  >  if (ENABLE_ASYNC_TASKS) {
> >  >  if (mExecutor == null) {
> >  >  execute_task(next);
> >  >  } else {
> >  >  mExecutor.execute(new Runnable() {
> >  >  

Re: SSL handler and SSLEngine tasks

[Jonathan Valliere]

It’s already running in an Executor which is why it’s a runnable.  The
Runnable defers the actual execution logic to the execute task function
which should be the one that is looping to perform all queued tasks from
the SSL Engine.

On Wed, Mar 2, 2022 at 3:51 AM Emmanuel Lécharny 
wrote:

> Hi,
>
> an alternative would be to modify the execute_task method to become:
>
>  synchronized protected void execute_task(NextFilter next) {
>  Runnable task = null;
>
>  while ((task = mEngine.getDelegatedTask()) != null) {
>  try {
>  if (ENABLE_ASYNC_TASKS && (mExecutor != null)) {
>  mExecutor.execute(task);
>  } else {
>  task.run();
>  }
>
>  write_handshake(next);
>  } catch (SSLException e) {
>
> So here, we push the tasks into an executor to be processed concurrently.
>
> On 02/03/2022 07:05, Emmanuel Lécharny wrote:
> > Hi Jonathan,
> >
> > I wonder if using an executor to process SSLEngine tasks is useful at
> > all, considering that the execute_task method is synchronized:
> >
> >  protected void schedule_task(NextFilter next) {
> >  if (ENABLE_ASYNC_TASKS) {
> >  if (mExecutor == null) {
> >  execute_task(next);
> >  } else {
> >  mExecutor.execute(new Runnable() {
> >  @Override
> >  public void run() {
> >  SSLHandlerG0.this.execute_task(next);
> >  }
> >  });
> >
> > and
> >
> >  synchronized protected void execute_task(NextFilter next) {
> >  ...
> >
> >
> > Also the execute_task will pull tasks from the SSLEngine - we may have
> > more than one, so it will loop on the tasks - and it's unlikely that we
> > will have more tasks to execute when exiting the execute_tasks method.
> >
> > The only benefit I can see is that the main thread will be freed for
> > other tasks - like processing another IoSession - while tasks are being
> > processed by another thread. And may be this is what was intended, but I
> > wonder iff we should not simply spawn a dedicated thread for that
> purpose.
> >
> > IMO, if we want to introduce an executor in the equation, it should be
> > done in the execute_task method, not in the schedule_task, it would
> > speed up the TLS processing, while also freeing the main thread fast
> > enough - even a bit slower than having the task loop being processed by
> > a dedicated thread.
> >
> > wdyt?
> >
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
> --
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.

Re: SSL Code format

[Jonathan Valliere]

It’s fine. I only use nondescript names when there just isn’t something
great.

On Fri, Feb 25, 2022 at 12:43 PM Emmanuel Lécharny 
wrote:

> Hi Jonathan
>
> do you mind if I do a bit of formatting in the SSL classes, like :
> - using meaningful variables instead of single letter ones (sslHandler
> instead of x, for instance)
> - get rid of useless 'final' keyword
> - add some missing {} around LOGs
> - rename the mXyx member variables to xyz
>
> The idea is to have a code base which is globally using the same scheme...
>
> Thanks !
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> 
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler

[Jonathan Valliere]

If we close the ssl instantly then that’s a point of DDOS.  Relying on the
idleness timers is important for handling connections in a bad state like
this example. What’s the exception that unit test is supposed to cause?

On Thu, Feb 24, 2022 at 4:56 PM Emmanuel Lécharny 
wrote:

> So the idea is first to loop on a NEED_TASK because we may need to send
> the alert before closing the connection (but I need to triple check
> that, it's a bit late here, and the day was a bit tough on my brain with
> all the bad news...)
>
> On 24/02/2022 19:18, Emmanuel Lécharny wrote:
> >
> >
> > On 24/02/2022 17:21, Jonathan Valliere wrote:
> >> If we were to elevate this error in another way like an error handler
> >> then what would you do? Close the session?
> >
> > Actually, yes, we should send a Error alert (see
> > https://datatracker.ietf.org/doc/html/rfc8446#section-6, par. 6.2) and
> > close the session.
> >
> >
> >>
> >> On Thu, Feb 24, 2022 at 10:35 AM Emmanuel Lécharny
> >> mailto:elecha...@gmail.com>> wrote:
> >>
> >> Understood, but here if a task fails, I'm not sure the exception
> >> will be
> >> handled at all. In the case of a handshake, nothing will be written
> >> back
> >> to the remote client, AFAICT, so the connection will remain pending
> >> forever.
> >>
> >> On 24/02/2022 14:23, Jonathan Valliere wrote:
> >>  > The reason I did this was an ensure the concurrency model of the
> >>  > filterchain.
> >>  >
> >>  > On Thu, Feb 24, 2022 at 8:22 AM Jonathan Valliere
> >>  > mailto:jon.valli...@emoten.com>
> >> <mailto:jon.valli...@emoten.com <mailto:jon.valli...@emoten.com>>>
> >> wrote:
> >>  >
> >>  > The pending error is elevated back on either read or
> >> write.  That
> >>  > way the async error will be thrown on a filter chain call
> >> stack.
> >>  >
> >>  > On Wed, Feb 23, 2022 at 11:13 PM Emmanuel Lécharny
> >>  > mailto:elecha...@gmail.com>
> >> <mailto:elecha...@gmail.com <mailto:elecha...@gmail.com>>> wrote:
> >>  >
> >>  > Hi Jonathan,
> >>  >
> >>  > I have a test that isn't happy with the way we deal with
> >>  > delegatedTasks
> >>  > in MINA 2.2 new SSLFilter implementation.
> >>  >
> >>  > The context:
> >>  > We do a TLS connection with a wrong certificate, the
> >> test is
> >>  > expected to
> >>  > fail, because of this error:
> >>  >
> >>  > javax.net.ssl.SSLHandshakeException: PKIX path building
> >> failed:
> >>  >
> >>  sun.security.provider.certpath.SunCertPathBuilderException:
> >>  > unable to
> >>  > find valid certification path to requested target
> >>  >
> >>  > The problem is that this exception is never caught, for
> >> some
> >>  > reason I'm
> >>  > trying to understand.The SSLHandlerG0.execute_task do
> >> catch an
> >>  > exception
> >>  > and stores it into the mPendingError variable, but this
> >> is never
> >>  > used.
> >>  >
> >>  > --
> >>  > *Emmanuel Lécharny - CTO* 205 Promenade des Anglais –
> >> 06200 NICE
> >>  >
> >>  <
> https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail=g
> >> <
> https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail=g>>
>
> >>
> >>  > T. +33 (0)4 89 97 36 50
> >>  > P. +33 (0)6 08 33 32 61
> >>  > emmanuel.lecha...@busit.com <mailto:emmanuel.lecha...@busit.com>
> >> <mailto:emmanuel.lecha...@busit.com
> >> <mailto:emmanuel.lecha...@busit.com>>
> >>  > https://www.busit.com/ <https://www.busit.com/>
> >> <https://www.busit.com/ <https://www.busit.com/>>
> >>  >
> >>  >
> >>  --

Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler

[Jonathan Valliere]

If we were to elevate this error in another way like an error handler then
what would you do? Close the session?

On Thu, Feb 24, 2022 at 10:35 AM Emmanuel Lécharny 
wrote:

> Understood, but here if a task fails, I'm not sure the exception will be
> handled at all. In the case of a handshake, nothing will be written back
> to the remote client, AFAICT, so the connection will remain pending
> forever.
>
> On 24/02/2022 14:23, Jonathan Valliere wrote:
> > The reason I did this was an ensure the concurrency model of the
> > filterchain.
> >
> > On Thu, Feb 24, 2022 at 8:22 AM Jonathan Valliere
> > mailto:jon.valli...@emoten.com>> wrote:
> >
> > The pending error is elevated back on either read or write.  That
> > way the async error will be thrown on a filter chain call stack.
> >
> > On Wed, Feb 23, 2022 at 11:13 PM Emmanuel Lécharny
> > mailto:elecha...@gmail.com>> wrote:
> >
> > Hi Jonathan,
> >
> > I have a test that isn't happy with the way we deal with
> > delegatedTasks
> > in MINA 2.2 new SSLFilter implementation.
> >
> > The context:
> > We do a TLS connection with a wrong certificate, the test is
> > expected to
> > fail, because of this error:
> >
> > javax.net.ssl.SSLHandshakeException: PKIX path building failed:
> > sun.security.provider.certpath.SunCertPathBuilderException:
> > unable to
> > find valid certification path to requested target
> >
> > The problem is that this exception is never caught, for some
> > reason I'm
> > trying to understand.The SSLHandlerG0.execute_task do catch an
> > exception
> > and stores it into the mPendingError variable, but this is never
> > used.
> >
> > --
> > *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> > <
> https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail=g
> >
> > T. +33 (0)4 89 97 36 50
> > P. +33 (0)6 08 33 32 61
> > emmanuel.lecha...@busit.com <mailto:emmanuel.lecha...@busit.com>
> > https://www.busit.com/ <https://www.busit.com/>
> >
> >
>  -
> > To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> > <mailto:dev-unsubscr...@mina.apache.org>
> > For additional commands, e-mail: dev-h...@mina.apache.org
> > <mailto:dev-h...@mina.apache.org>
> >
> > --
> > CONFIDENTIALITY NOTICE: The contents of this email message and any
> > attachments are intended solely for the addressee(s) and may contain
> > confidential and/or privileged information and may be legally
> > protected from disclosure.
> >
> > --
> > CONFIDENTIALITY NOTICE: The contents of this email message and any
> > attachments are intended solely for the addressee(s) and may contain
> > confidential and/or privileged information and may be legally protected
> > from disclosure.
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
> --
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.

Re: Vote needed: [VOTE] Apache FtpServer 1.1.3 release

[Jonathan Valliere]

+1

On Wed, Feb 23, 2022 at 1:06 AM Emmanuel Lécharny 
wrote:

> Hi,
>
> I need at least one more vote for this release...
>
> Thanks !
>
> On 20/02/2022 09:48, Emmanuel Lecharny wrote:
> > Hi,
> >
> > This is a bug fix release. This version uses the latest MINA release
> > (2.1.6), the latest Log4j version (2.17.1) and an issue with TLS 1.3
> > that wasn't enabled properly.
> >
> > A temporary tag has been created (it can be removed if the vote is not
> approved)
> >
> > The newly approved Nexus has been used for the preparation of this
> > release and all final artifacts are stored in a staging repository:
> > https://repository.apache.org/content/repositories/orgapachemina-1067/
> >
> >
> > The distributions are available for download on :
> >
> https://repository.apache.org/content/repositories/orgapachemina-004/org/apache/mina/ftpserver/1.1.3/
> >
> > Let us vote :
> > [ ] +1 | Release Apache FtpServer 1.1.3
> > [ ] +/- | Abstain
> > [ ] -1 | Do *NOT* release Apache FtpServer 1.1.3
> >
> > Thanks !
> >
> >
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
> --
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.

Re: Triuble with deleghated tasks in MINA 2.2 SSLHandler

[Jonathan Valliere]

The reason I did this was an ensure the concurrency model of the
filterchain.

On Thu, Feb 24, 2022 at 8:22 AM Jonathan Valliere 
wrote:

> The pending error is elevated back on either read or write.  That way the
> async error will be thrown on a filter chain call stack.
>
> On Wed, Feb 23, 2022 at 11:13 PM Emmanuel Lécharny 
> wrote:
>
>> Hi Jonathan,
>>
>> I have a test that isn't happy with the way we deal with delegatedTasks
>> in MINA 2.2 new SSLFilter implementation.
>>
>> The context:
>> We do a TLS connection with a wrong certificate, the test is expected to
>> fail, because of this error:
>>
>> javax.net.ssl.SSLHandshakeException: PKIX path building failed:
>> sun.security.provider.certpath.SunCertPathBuilderException: unable to
>> find valid certification path to requested target
>>
>> The problem is that this exception is never caught, for some reason I'm
>> trying to understand.The SSLHandlerG0.execute_task do catch an exception
>> and stores it into the mPendingError variable, but this is never used.
>>
>> --
>> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
>> <https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail=g>
>> T. +33 (0)4 89 97 36 50
>> P. +33 (0)6 08 33 32 61
>> emmanuel.lecha...@busit.com https://www.busit.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
>> For additional commands, e-mail: dev-h...@mina.apache.org
>>
>> --
> CONFIDENTIALITY NOTICE: The contents of this email message and any
> attachments are intended solely for the addressee(s) and may contain
> confidential and/or privileged information and may be legally protected
> from disclosure.
>
-- 
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.

Re: Triuble with deleghated tasks in MINA 2.2 SSLHandler

[Jonathan Valliere]

The pending error is elevated back on either read or write.  That way the
async error will be thrown on a filter chain call stack.

On Wed, Feb 23, 2022 at 11:13 PM Emmanuel Lécharny 
wrote:

> Hi Jonathan,
>
> I have a test that isn't happy with the way we deal with delegatedTasks
> in MINA 2.2 new SSLFilter implementation.
>
> The context:
> We do a TLS connection with a wrong certificate, the test is expected to
> fail, because of this error:
>
> javax.net.ssl.SSLHandshakeException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to
> find valid certification path to requested target
>
> The problem is that this exception is never caught, for some reason I'm
> trying to understand.The SSLHandlerG0.execute_task do catch an exception
> and stores it into the mPendingError variable, but this is never used.
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> 
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
> --
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.

Re: SSL classes name

[Jonathan Valliere]

I’m okay with that except the new SSL isn’t exactly a drop in replacement
for the old one. I felt this would cause enough confusion on purpose to
force devs to look at their code and make sure it’s compatible.

On Wed, Feb 23, 2022 at 10:52 AM Emmanuel Lécharny 
wrote:

> Hi Jonathan,
>
> the ssl filter classes should be renamed from SSLxxx to Sslxxx. This is
> breaking a lot of applications using them. I have no problem with using
> SSLxxx in a 3.0, but for a 2.2, I think that would be too much trouble
> for our users...
>
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> 
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
> --
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.

Re: [VOTE] Release Apache MINA 2.0.23

[Jonathan Valliere]

+1

On Thu, Feb 10, 2022 at 7:03 PM Emmanuel Lecharny 
wrote:

> Hi,
>
> This is a maintenance release for MINA 2.0.
>
> It contains many backported issues from the 2.1 and 2.2 branches.
>
> A temporary tag has been created (it can be removed if the vote is not
> approved):
>
>
> https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=ccb577ed622490a84780f039840ddc640c6a0874
>
> The newly approved Nexus has been used for the preparation of this
> release and all final artifacts are stored
> in a staging repository:
> https://repository.apache.org/content/repositories/orgapachemina-1066/
>
>
> The distributions are available for download on :
> https://dist.apache.org/repos/dist/dev/mina/mina/2.0.23/
>
> Let us vote :
> [ ] +1 | Release MINA 2.0.23
> [ ] +/- | Abstain
> [ ] -1 | Do *NOT*  release MINA 2.0.23
>
> Thanks !
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
> --
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.

Re: Removing Google Analytics from our web site

[Jonathan Valliere]

+1
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.


On Feb 10, 2022 at 11:54:58 AM, Jeff MAURY  wrote:

> +1
>
> Shouldn't it be a general ASF concern ?
>
> On Thu, Feb 10, 2022 at 5:06 PM Emmanuel Lécharny 
> wrote:
>
> Hi !
>
>
> we have set up google analytics on MINA web site. It seems that it might
>
> cause issues with the european GDPR rules.
>
>
> I suggest we remove this feature we don't really use anyway.
>
>
> wdyt ?
>
> --
>
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
>
> T. +33 (0)4 89 97 36 50
>
> P. +33 (0)6 08 33 32 61
>
> emmanuel.lecha...@busit.com https://www.busit.com/
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
>
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>
>
>
> --
> "Legacy code" often differs from its suggested alternative by actually
> working and scaling.
> - Bjarne Stroustrup
>
> http://www.jeffmaury.com
> http://riadiscuss.jeffmaury.com
> http://www.twitter.com/jeffmaury
>

Re: Chage in NioDatagramAcceptor in 2.1 vs 2.0

[Jonathan Valliere]

 Actually, looks like I fixed something unrelated to DIRMINA-996 and marked
it 996 for some reason.

On Feb 7, 2022 at 5:43:49 PM, Emmanuel Lécharny  wrote:

> The thing is that I can't see how it the commit is related to the
> problem described in the JIRA...
>
>
> On 07/02/2022 19:24, Jonathan Valliere wrote:
>
> Mark fixed
>
>
> On Mon, Feb 7, 2022 at 12:14 PM Emmanuel Lécharny 
> <mailto:elecha...@gmail.com>> wrote:
>
>
> Hi Jonathan,
>
>
> the commit 896b170d8d7c0769bca171f0fbe7de9b13a65968 is commented as a
>
> fix for DIRMINA-996
>
> (
> https://github.com/apache/mina/commit/896b170d8d7c0769bca171f0fbe7de9b13a65968
>
> <
> https://github.com/apache/mina/commit/896b170d8d7c0769bca171f0fbe7de9b13a65968
> >)
>
>
> Is it the case?
>
>
> If so, can we close the issue and mark it fixed (note: the patch has
>
> been applied to 2.1 and 2.2 branches).
>
>
> Thanks !
>
>
> --
>
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
>
> <
> https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail=g
> >
>
> T. +33 (0)4 89 97 36 50
>
> P. +33 (0)6 08 33 32 61
>
> emmanuel.lecha...@busit.com <mailto:emmanuel.lecha...@busit.com>
>
> https://www.busit.com/ <https://www.busit.com/>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
>
> <mailto:dev-unsubscr...@mina.apache.org>
>
> For additional commands, e-mail: dev-h...@mina.apache.org
>
> <mailto:dev-h...@mina.apache.org>
>
>
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>

Re: Chage in NioDatagramAcceptor in 2.1 vs 2.0

[Jonathan Valliere]

Mark fixed

On Mon, Feb 7, 2022 at 12:14 PM Emmanuel Lécharny 
wrote:

> Hi Jonathan,
>
> the commit 896b170d8d7c0769bca171f0fbe7de9b13a65968 is commented as a
> fix for DIRMINA-996
> (
> https://github.com/apache/mina/commit/896b170d8d7c0769bca171f0fbe7de9b13a65968
> )
>
> Is it the case?
>
> If so, can we close the issue and mark it fixed (note: the patch has
> been applied to 2.1 and 2.2 branches).
>
> Thanks !
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> 
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: [VOTE] Release Apache MINA 2.1.6

[Jonathan Valliere]

+1

On Sun, Feb 6, 2022 at 3:18 AM Emmanuel Lecharny 
wrote:

> Hi,
>
> This is a bug fix release for MINA.
>
> Here is the list of fixed issues :
>
>
>* [DIRMINA-1152] IoServiceStatistics introduces huge latencies
>* [DIRMINA-1156]Inconsistent worker / idleWorker in
> OrderedThreadPoolExecutor
>
> It also contain some minor fixes (ignored tests being fixed, a minor
> infinite loop fixed in the Buffer toString() method if used in some
> corner case, etc)
>
>
> Here's the Jira link for this version if you'd like to review issues
> in more details:
>
> https://issues.apache.org/jira/projects/DIRMINA/versions/12351317
>
> A temporary tag has been created (it can be removed if the vote is not
> approved):
>
>
> https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=a58e68216d492f78d0341aef997ad3c78275cb65
>
> The newly approved Nexus has been used for the preparation of this
> release and all final artifacts are stored
> in a staging repository:
> https://repository.apache.org/content/repositories/orgapachemina-1065/
>
>
> The distributions are available for download on :
> https://dist.apache.org/repos/dist/dev/mina/mina/2.1.6/
>
> Let us vote :
> [ ] +1 | Release MINA 2.1.6
> [ ] +/- | Abstain
> [ ] -1 | Do *NOT*  release MINA 2.1.6
>
> Thanks !
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
> --
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.

[jira] [Commented] (DIRMINA-1161) Accessing the session buffer of multiple decoders

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486480#comment-17486480
 ] 

Jonathan Valliere commented on DIRMINA-1161:


Can't do that either.  The AttributeKeys are global for the entire IoSession.  
What is the use-case for this?

> Accessing the session buffer of multiple decoders
> -
>
> Key: DIRMINA-1161
> URL: https://issues.apache.org/jira/browse/DIRMINA-1161
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.22, 2.1.4
> Environment: Ubuntu 16.04.7 LTS
> Open JDK 11.0.10
> Mina 2.0.22
>Reporter: Pavel Garin
>Priority: Major
> Fix For: 2.0.23, 2.1.5
>
>
> As of Mina 2.0.17, the line of code in CumulativeProtocolDecoder 
>  
> {code:java}
> private final AttributeKey BUFFER = new AttributeKey(getClass(), "buffer"); 
> {code}
> has been replaced with line 
> {code:java}
> private static final AttributeKey BUFFER = new 
> AttributeKey(CumulativeProtocolDecoder.class, "buffer");{code}
> When using an architecture where multiple decoders inherited from 
> CumulativeProtocolDecoder are used, the decoders corrupt each other's data. 
> The key for the attribute in line 
> {code:java}
> IoBuffer buf = (IoBuffer) session.getAttribute(BUFFER);{code}
> has become the same for all decoders.
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Commented] (DIRMINA-1161) Accessing the session buffer of multiple decoders

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486425#comment-17486425
 ] 

Jonathan Valliere commented on DIRMINA-1161:


The ProtocolDecoder system is not concurrent and does not support one
Session operating concurrent via ThreadExecutors.

This has been resolved in an upcoming release.


CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.


> Accessing the session buffer of multiple decoders
> -
>
> Key: DIRMINA-1161
> URL: https://issues.apache.org/jira/browse/DIRMINA-1161
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.22, 2.1.4
> Environment: Ubuntu 16.04.7 LTS
> Open JDK 11.0.10
> Mina 2.0.22
>Reporter: Pavel Garin
>Priority: Major
> Fix For: 2.0.23, 2.1.5
>
>
> As of Mina 2.0.17, the line of code in CumulativeProtocolDecoder 
>  
> {code:java}
> private final AttributeKey BUFFER = new AttributeKey(getClass(), "buffer"); 
> {code}
> has been replaced with line 
> {code:java}
> private static final AttributeKey BUFFER = new 
> AttributeKey(CumulativeProtocolDecoder.class, "buffer");{code}
> When using an architecture where multiple decoders inherited from 
> CumulativeProtocolDecoder are used, the decoders corrupt each other's data. 
> The key for the attribute in line 
> {code:java}
> IoBuffer buf = (IoBuffer) session.getAttribute(BUFFER);{code}
> has become the same for all decoders.
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: [jira] [Updated] (DIRMINA-1161) Accessing the session buffer of multiple decoders

[Jonathan Valliere]

The ProtocolDecoder system is not concurrent and does not support one
Session operating concurrent via ThreadExecutors.

This has been resolved in an upcoming release.

On Thu, Feb 3, 2022 at 5:17 AM Pavel Garin (Jira)  wrote:

>
>  [
> https://issues.apache.org/jira/browse/DIRMINA-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Pavel Garin updated DIRMINA-1161:
> -
> Description:
> As of Mina 2.0.17, the line of code in CumulativeProtocolDecoder
>
>
> {code:java}
> private final AttributeKey BUFFER = new AttributeKey(getClass(),
> "buffer"); {code}
> has been replaced with line
> {code:java}
> private static final AttributeKey BUFFER = new
> AttributeKey(CumulativeProtocolDecoder.class, "buffer");{code}
> When using an architecture where multiple decoders inherited from
> CumulativeProtocolDecoder are used, the decoders corrupt each other's data.
> The key for the attribute in line
> {code:java}
> IoBuffer buf = (IoBuffer) session.getAttribute(BUFFER);{code}
> has become the same for all decoders.
>
>
>
>
>
>   was:
> As of Mina 2.0.17, the line of code in CumulativeProtocolDecoder
>
>
> {code:java}
> private final AttributeKey BUFFER = new AttributeKey(getClass(),
> "buffer"); {code}
> has been replaced with line
>
>
> {code:java}
> private static final AttributeKey BUFFER = new
> AttributeKey(CumulativeProtocolDecoder.class, "buffer");{code}
> When using an architecture where multiple decoders inherited from
> CumulativeProtocolDecoder are used, the decoders corrupt each other's data.
> The key for the attribute in line
> {code:java}
> IoBuffer buf = (IoBuffer) session.getAttribute(BUFFER);{code}
>  has become the same for all decoders.
>
>
>
>
>
>
> > Accessing the session buffer of multiple decoders
> > -
> >
> > Key: DIRMINA-1161
> > URL: https://issues.apache.org/jira/browse/DIRMINA-1161
> > Project: MINA
> >  Issue Type: Bug
> >  Components: Core
> >Affects Versions: 2.0.22, 2.1.4
> > Environment: Ubuntu 16.04.7 LTS
> > Open JDK 11.0.10
> > Mina 2.0.22
> >Reporter: Pavel Garin
> >Priority: Major
> > Fix For: 2.0.23, 2.1.5
> >
> >
> > As of Mina 2.0.17, the line of code in CumulativeProtocolDecoder
> >
> > {code:java}
> > private final AttributeKey BUFFER = new AttributeKey(getClass(),
> "buffer"); {code}
> > has been replaced with line
> > {code:java}
> > private static final AttributeKey BUFFER = new
> AttributeKey(CumulativeProtocolDecoder.class, "buffer");{code}
> > When using an architecture where multiple decoders inherited from
> CumulativeProtocolDecoder are used, the decoders corrupt each other's data.
> The key for the attribute in line
> > {code:java}
> > IoBuffer buf = (IoBuffer) session.getAttribute(BUFFER);{code}
> > has become the same for all decoders.
> >
> >
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.20.1#820001)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
> --
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

 Have you tried printing the entirety of the contents from the Socket
inbound and compare against what is passed into the SSLEngine to make sure
our buffer combination/management isn’t corrupting the stream?

On Jan 28, 2022 at 7:45:29 PM, Emmanuel Lécharny 
wrote:

> Ok, moving forward:
>
> The test does:
>
> - create the server and set the SSLFilter with TLS 1.2
> - create the secured connection (TLSv1.2)
> - write a first message ('test-1')
> - that initiate the HS, then the message is written to the server
> - once the HS is completed, the response is sent (response 1)
> - the SSLSocket session is invalidated on the client side
> - we do a startHandshake on the client
> - the server receives the HS message and send back the HS response
> *** The client never processes the incoming HS message***
> - the client sends the second message
> - the server receives the message and write back the response
> - the server closes the connection
>
>
> I have no idea why the client does not prcoess the second HS message
> received from the server...
>
> On 29/01/2022 00:29, Emmanuel Lécharny wrote:
>
> It should.
>
>
> What is really puzzling is when we set the server to use TLS 1.2 *and*
>
> the client to TLS 1.2, and that fails whatever Java version we use...
>
>
> On 29/01/2022 00:14, Jonathan Valliere wrote:
>
> > Shouldn’t it be downgrading during the handshake?
>
> >
>
> > On Fri, Jan 28, 2022 at 6:12 PM Emmanuel Lécharny 
> > <mailto:elecha...@gmail.com>> wrote:
>
> >
>
> > Hi Jonathan,
>
> >
>
> > after a big fight, I finally found that the SslFilterTest was
>
> > failing in
>
> > Mina 2.2 with Java 8 and 11 when the client was not set to use TLS
>
> > V1.3
>
> > (it was set to use "TLS"). Note that the client is a plain SSL
>
> > Socket,
>
> > created by a SSLSocketFactory.
>
> >
>
> > So the combinations that work :
>
> > Java  8 + Client TLSv1.3 + Server TLSv1.2 -> OK
>
> > Java 11 + Client TLSv1.3 + Server TLSv1.2 -> OK
>
> > Java  8 + Client TLSv1.3 + Server TLSv1.3 -> OK
>
> > Java 11 + Client TLSv1.3 + Server TLSv1.3 -> OK
>
> >
>
> > And for those that don't work:
>
> > Java  8 + Client TLSv1.2 + Server TLSv1.2 -> KO
>
> > Java 11 + Client TLSv1.2 + Server TLSv1.2 -> KO
>
> > Java  8 + Client TLSv1.2 + Server TLSv1.3 -> KO
>
> > Java 11 + Client TLSv1.2 + Server TLSv1.3 -> KO
>
> >
>
> > That is a bit problematic as we may have client that aren't using
>
> > TLS 1.3...
>
> >
>
> > On 21/01/2022 16:23, Emmanuel Lécharny wrote:
>
> >  >
>
> >  >
>
> >  > On 21/01/2022 13:23, Jonathan Valliere wrote:
>
> >  >> You can also use the DisableEncryptionWriteRequesf to wrap your
>
> >  >> WriteRequest you want to bypass the SSL filter.
>
> >  >
>
> >  > Yes, but all in all, I think this WriteRequest class should go.
>
> > The
>
> >  > original Attribute was specifically created to bypass the
>
> > SslFilter for
>
> >  > the StartTLS operation, and in retrospect, thatw as a mistake.
>
> >  >
>
> >  > I like the Filter idea.
>
> >  >
>
> >
>
> > -- *Emmanuel Lécharny - CTO* 205 Promenade
>
> >
>
> > <
> https://www.google.com/maps/search/Emmanuel+L%C3%A9charny+-+CTO*+205+Promenade+?entry=gmail=g>des
>
>
> >
>
> > Anglais – 06200 NICE
>
> > T. +33 (0)4 89 97 36 50
>
> > P. +33 (0)6 08 33 32 61
>
> > emmanuel.lecha...@busit.com <mailto:emmanuel.lecha...@busit.com>
>
> > https://www.busit.com/ <https://www.busit.com/>
>
> >
>
> > -
>
> > To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
>
> > <mailto:dev-unsubscr...@mina.apache.org>
>
> > For additional commands, e-mail: dev-h...@mina.apache.org
>
> > <mailto:dev-h...@mina.apache.org>
>
> >
>
>
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

勞

On Fri, Jan 28, 2022 at 6:30 PM Emmanuel Lécharny 
wrote:

> It should.
>
> What is really puzzling is when we set the server to use TLS 1.2 *and*
> the client to TLS 1.2, and that fails whatever Java version we use...
>
> On 29/01/2022 00:14, Jonathan Valliere wrote:
> > Shouldn’t it be downgrading during the handshake?
> >
> > On Fri, Jan 28, 2022 at 6:12 PM Emmanuel Lécharny  > <mailto:elecha...@gmail.com>> wrote:
> >
> > Hi Jonathan,
> >
> > after a big fight, I finally found that the SslFilterTest was
> > failing in
> > Mina 2.2 with Java 8 and 11 when the client was not set to use TLS
> V1.3
> > (it was set to use "TLS"). Note that the client is a plain SSL
> Socket,
> > created by a SSLSocketFactory.
> >
> > So the combinations that work :
> > Java  8 + Client TLSv1.3 + Server TLSv1.2 -> OK
> > Java 11 + Client TLSv1.3 + Server TLSv1.2 -> OK
> > Java  8 + Client TLSv1.3 + Server TLSv1.3 -> OK
> > Java 11 + Client TLSv1.3 + Server TLSv1.3 -> OK
> >
> > And for those that don't work:
> > Java  8 + Client TLSv1.2 + Server TLSv1.2 -> KO
> > Java 11 + Client TLSv1.2 + Server TLSv1.2 -> KO
> > Java  8 + Client TLSv1.2 + Server TLSv1.3 -> KO
> > Java 11 + Client TLSv1.2 + Server TLSv1.3 -> KO
> >
> > That is a bit problematic as we may have client that aren't using
> > TLS 1.3...
> >
> > On 21/01/2022 16:23, Emmanuel Lécharny wrote:
> >  >
> >  >
> >  > On 21/01/2022 13:23, Jonathan Valliere wrote:
> >  >> You can also use the DisableEncryptionWriteRequesf to wrap your
> >  >> WriteRequest you want to bypass the SSL filter.
> >  >
> >  > Yes, but all in all, I think this WriteRequest class should go.
> The
> >  > original Attribute was specifically created to bypass the
> > SslFilter for
> >  > the StartTLS operation, and in retrospect, thatw as a mistake.
> >  >
> >  > I like the Filter idea.
> >  >
> >
> > --
> > *Emmanuel Lécharny - CTO* 205 Promenade
> > <
> https://www.google.com/maps/search/Emmanuel+L%C3%A9charny+-+CTO*+205+Promenade+?entry=gmail=g
> >des
> > Anglais – 06200 NICE
> > T. +33 (0)4 89 97 36 50
> > P. +33 (0)6 08 33 32 61
> > emmanuel.lecha...@busit.com <mailto:emmanuel.lecha...@busit.com>
> > https://www.busit.com/ <https://www.busit.com/>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> > <mailto:dev-unsubscr...@mina.apache.org>
> > For additional commands, e-mail: dev-h...@mina.apache.org
> > <mailto:dev-h...@mina.apache.org>
> >
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

Shouldn’t it be downgrading during the handshake?

On Fri, Jan 28, 2022 at 6:12 PM Emmanuel Lécharny 
wrote:

> Hi Jonathan,
>
> after a big fight, I finally found that the SslFilterTest was failing in
> Mina 2.2 with Java 8 and 11 when the client was not set to use TLS V1.3
> (it was set to use "TLS"). Note that the client is a plain SSL Socket,
> created by a SSLSocketFactory.
>
> So the combinations that work :
> Java  8 + Client TLSv1.3 + Server TLSv1.2 -> OK
> Java 11 + Client TLSv1.3 + Server TLSv1.2 -> OK
> Java  8 + Client TLSv1.3 + Server TLSv1.3 -> OK
> Java 11 + Client TLSv1.3 + Server TLSv1.3 -> OK
>
> And for those that don't work:
> Java  8 + Client TLSv1.2 + Server TLSv1.2 -> KO
> Java 11 + Client TLSv1.2 + Server TLSv1.2 -> KO
> Java  8 + Client TLSv1.2 + Server TLSv1.3 -> KO
> Java 11 + Client TLSv1.2 + Server TLSv1.3 -> KO
>
> That is a bit problematic as we may have client that aren't using TLS
> 1.3...
>
> On 21/01/2022 16:23, Emmanuel Lécharny wrote:
> >
> >
> > On 21/01/2022 13:23, Jonathan Valliere wrote:
> >> You can also use the DisableEncryptionWriteRequesf to wrap your
> >> WriteRequest you want to bypass the SSL filter.
> >
> > Yes, but all in all, I think this WriteRequest class should go. The
> > original Attribute was specifically created to bypass the SslFilter for
> > the StartTLS operation, and in retrospect, thatw as a mistake.
> >
> > I like the Filter idea.
> >
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade
> <https://www.google.com/maps/search/Emmanuel+L%C3%A9charny+-+CTO*+205+Promenade+?entry=gmail=g>des
> Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: Moving 2.2.X to 4.0.X

[Jonathan Valliere]

Yes, I agree.

On Sat, Jan 22, 2022 at 3:24 PM Emmanuel Lécharny 
wrote:

> Hi Jonathan,
>
> yes I think this is the right move.
>
> The current 2.2.X shoulld move to a 4.0.X branch, to become an offical 4.0.
>
> I also think that there is no reason to move with faster major versions
> (à la Chrome or FF)
>
> In any case, we will keep the 2.0 and 2.1 branches alive for a bit of time.
>
> Also note that it may make sense to support Java 11+ only for 4.0.
>
> wdyt ?
>
> On 22/01/2022 17:05, Jonathan Valliere wrote:
> > Hello friends,
> >
> > After some discussion, the breaking changes in the current 2.2.X branch
> > necessitates moving to a new major version.  One would expect a move to
> > 3.0 however, a 3.0 branch and tags were created many years ago for an
> > abandoned effort to re-engineer the entirety of MINA.  The prospect of
> > this is not lost but for the time being that old work is now defunct.
> > Long story short, 2.2.X is moving to 4.0.X.
> >
> > Thank you for your patience.  Some new Quality of Life changes are
> > coming soon as well as an official 4.0 release.
> >
> > Cheers,
> > JV
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenad
> <https://www.google.com/maps/search/%0A*Emmanuel+L%C3%A9charny+-+CTO*+205+Promenad?entry=gmail=g>e
> des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>

Moving 2.2.X to 4.0.X

[Jonathan Valliere]

Hello friends,

After some discussion, the breaking changes in the current 2.2.X branch
necessitates moving to a new major version.  One would expect a move to 3.0
however, a 3.0 branch and tags were created many years ago for an abandoned
effort to re-engineer the entirety of MINA.  The prospect of this is not
lost but for the time being that old work is now defunct.  Long story
short, 2.2.X is moving to 4.0.X.

Thank you for your patience.  Some new Quality of Life changes are coming
soon as well as an official 4.0 release.

Cheers,
JV

[jira] [Commented] (DIRMINA-1157) Sporadic error when establishing a StartTLS or SSL connection

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480470#comment-17480470
 ] 

Jonathan Valliere commented on DIRMINA-1157:


I'm starting to think this should be just 3.0 but if we're going to break 
things might as well break some other things for some overall QOL improvements.

> Sporadic error when establishing a StartTLS or SSL connection
> -
>
> Key: DIRMINA-1157
> URL: https://issues.apache.org/jira/browse/DIRMINA-1157
> Project: MINA
>  Issue Type: Bug
>  Components: Core, SSL
>Affects Versions: 2.1.5
>Reporter: Steffen Liersch
>Priority: Blocker
>  Labels: security
> Attachments: SslHandler-compare.png, SslHandler-mod.java, 
> SslHandler.java
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> With the Mina components, a connection error occasionally occurs when 
> establishing a StartTLS or TLS connection. The cause is that payload data was 
> received immediately on the acknowledgement and is already in the receive 
> buffer.
> My colleagues have changed the checkStatus function of the SslHandler class 
> from apache-mina-2.1.5-src.zip so that the sporadic error demonstrably no 
> longer occurs. Please review the changes and include them in the codebase for 
> the next release.
> I have attached the original version of SslHandler.java, as well as the 
> modified version. Thank you for your support!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Commented] (DIRMINA-1157) Sporadic error when establishing a StartTLS or SSL connection

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480438#comment-17480438
 ] 

Jonathan Valliere commented on DIRMINA-1157:


[~elecharny] I had changed it originally to match the acronym standard in the 
JDK e.g. SSLContext.  It also had the advantage of not letting someone in 
another project just bump up the MINA version number without testing because 
the majority of SSLFilter is different and is incompatible with previous 
versions.

> Sporadic error when establishing a StartTLS or SSL connection
> -
>
> Key: DIRMINA-1157
> URL: https://issues.apache.org/jira/browse/DIRMINA-1157
> Project: MINA
>  Issue Type: Bug
>  Components: Core, SSL
>Affects Versions: 2.1.5
>Reporter: Steffen Liersch
>Priority: Blocker
>  Labels: security
> Attachments: SslHandler-compare.png, SslHandler-mod.java, 
> SslHandler.java
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> With the Mina components, a connection error occasionally occurs when 
> establishing a StartTLS or TLS connection. The cause is that payload data was 
> received immediately on the acknowledgement and is already in the receive 
> buffer.
> My colleagues have changed the checkStatus function of the SslHandler class 
> from apache-mina-2.1.5-src.zip so that the sporadic error demonstrably no 
> longer occurs. Please review the changes and include them in the codebase for 
> the next release.
> I have attached the original version of SslHandler.java, as well as the 
> modified version. Thank you for your support!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Comment Edited] (DIRMINA-1157) Sporadic error when establishing a StartTLS or SSL connection

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480416#comment-17480416
 ] 

Jonathan Valliere edited comment on DIRMINA-1157 at 1/22/22, 1:02 PM:
--

[~elecharny] 

I don't understand the case sensitive thing, I had renamed all of the 
references already.  Are you trying to back-port this?  The way you rename 
things in case-insensitive is by adding a 2 at the end so like "SslSomething" 
becomes "SSLSomething2" then remove the 2 "SSLSomething"

MacOS is case insensitive which is why the renaming problems happen.  Linux is 
case sensitive which doesn't have the renaming problems (which is what I use 
for development)

 

My MINA workspace should have been set to spaces to match everything else.  My 
work work stuff is set to tabs and line breaks (it would have looked way 
different).  I will check it the next time I work on something.


was (Author: johnnyv):
[~elecharny] 

I don't understand the case sensitive thing, I had renamed all of the 
references already.  Are you trying to back-port this?  The way you rename 
things in case-sensitive is by adding a 2 at the end so like "SslSomething" 
becomes "SSLSomething2" then remove the 2 "SSLSomething"

My MINA workspace should have been set to spaces to match everything else.  My 
work work stuff is set to tabs and line breaks (it would have looked way 
different).  I will check it the next time I work on something.

> Sporadic error when establishing a StartTLS or SSL connection
> -
>
> Key: DIRMINA-1157
> URL: https://issues.apache.org/jira/browse/DIRMINA-1157
> Project: MINA
>  Issue Type: Bug
>  Components: Core, SSL
>Affects Versions: 2.1.5
>Reporter: Steffen Liersch
>Priority: Blocker
>  Labels: security
> Attachments: SslHandler-compare.png, SslHandler-mod.java, 
> SslHandler.java
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> With the Mina components, a connection error occasionally occurs when 
> establishing a StartTLS or TLS connection. The cause is that payload data was 
> received immediately on the acknowledgement and is already in the receive 
> buffer.
> My colleagues have changed the checkStatus function of the SslHandler class 
> from apache-mina-2.1.5-src.zip so that the sporadic error demonstrably no 
> longer occurs. Please review the changes and include them in the codebase for 
> the next release.
> I have attached the original version of SslHandler.java, as well as the 
> modified version. Thank you for your support!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Comment Edited] (DIRMINA-1157) Sporadic error when establishing a StartTLS or SSL connection

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480416#comment-17480416
 ] 

Jonathan Valliere edited comment on DIRMINA-1157 at 1/22/22, 1:02 PM:
--

[~elecharny] 

I don't understand the case sensitive thing, I had renamed all of the 
references already.  Are you trying to back-port this?  The way you rename 
things in case-insensitive is by adding a 2 at the end so like "SslSomething" 
becomes "SSLSomething2" then remove the 2 "SSLSomething"

MacOS is case insensitive which is why the renaming problems happen.  Linux is 
case sensitive which doesn't have the renaming problems (which is what I use 
for development)

My MINA workspace should have been set to spaces to match everything else.  My 
work work stuff is set to tabs and line breaks (it would have looked way 
different).  I will check it the next time I work on something.


was (Author: johnnyv):
[~elecharny] 

I don't understand the case sensitive thing, I had renamed all of the 
references already.  Are you trying to back-port this?  The way you rename 
things in case-insensitive is by adding a 2 at the end so like "SslSomething" 
becomes "SSLSomething2" then remove the 2 "SSLSomething"

MacOS is case insensitive which is why the renaming problems happen.  Linux is 
case sensitive which doesn't have the renaming problems (which is what I use 
for development)

 

My MINA workspace should have been set to spaces to match everything else.  My 
work work stuff is set to tabs and line breaks (it would have looked way 
different).  I will check it the next time I work on something.

> Sporadic error when establishing a StartTLS or SSL connection
> -
>
> Key: DIRMINA-1157
> URL: https://issues.apache.org/jira/browse/DIRMINA-1157
> Project: MINA
>  Issue Type: Bug
>  Components: Core, SSL
>Affects Versions: 2.1.5
>Reporter: Steffen Liersch
>Priority: Blocker
>  Labels: security
> Attachments: SslHandler-compare.png, SslHandler-mod.java, 
> SslHandler.java
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> With the Mina components, a connection error occasionally occurs when 
> establishing a StartTLS or TLS connection. The cause is that payload data was 
> received immediately on the acknowledgement and is already in the receive 
> buffer.
> My colleagues have changed the checkStatus function of the SslHandler class 
> from apache-mina-2.1.5-src.zip so that the sporadic error demonstrably no 
> longer occurs. Please review the changes and include them in the codebase for 
> the next release.
> I have attached the original version of SslHandler.java, as well as the 
> modified version. Thank you for your support!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Comment Edited] (DIRMINA-1157) Sporadic error when establishing a StartTLS or SSL connection

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480416#comment-17480416
 ] 

Jonathan Valliere edited comment on DIRMINA-1157 at 1/22/22, 12:55 PM:
---

[~elecharny] 

I don't understand the case sensitive thing, I had renamed all of the 
references already.  Are you trying to back-port this?  The way you rename 
things in case-sensitive is by adding a 2 at the end so like "SslSomething" 
becomes "SSLSomething2" then remove the 2 "SSLSomething"

My MINA workspace should have been set to spaces to match everything else.  My 
work work stuff is set to tabs and line breaks (it would have looked way 
different).  I will check it the next time I work on something.


was (Author: johnnyv):
[~elecharny] 

I don't understand the case sensitive thing, I had renamed all of the 
references already.  Are you trying to back-port this?  The way you rename 
things is by adding a 2 at the end so like "SslSomething" becomes 
"SSLSomething2" then remove the 2 "SSLSomething"

My MINA workspace should have been set to spaces to match everything else.  My 
work work stuff is set to tabs and line breaks (it would have looked way 
different).  I will check it the next time I work on something.

> Sporadic error when establishing a StartTLS or SSL connection
> -
>
> Key: DIRMINA-1157
> URL: https://issues.apache.org/jira/browse/DIRMINA-1157
> Project: MINA
>  Issue Type: Bug
>  Components: Core, SSL
>Affects Versions: 2.1.5
>Reporter: Steffen Liersch
>Priority: Blocker
>  Labels: security
> Attachments: SslHandler-compare.png, SslHandler-mod.java, 
> SslHandler.java
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> With the Mina components, a connection error occasionally occurs when 
> establishing a StartTLS or TLS connection. The cause is that payload data was 
> received immediately on the acknowledgement and is already in the receive 
> buffer.
> My colleagues have changed the checkStatus function of the SslHandler class 
> from apache-mina-2.1.5-src.zip so that the sporadic error demonstrably no 
> longer occurs. Please review the changes and include them in the codebase for 
> the next release.
> I have attached the original version of SslHandler.java, as well as the 
> modified version. Thank you for your support!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Comment Edited] (DIRMINA-1157) Sporadic error when establishing a StartTLS or SSL connection

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480416#comment-17480416
 ] 

Jonathan Valliere edited comment on DIRMINA-1157 at 1/22/22, 12:54 PM:
---

[~elecharny] 

I don't understand the case sensitive thing, I had renamed all of the 
references already.  Are you trying to back-port this?  The way you rename 
things is by adding a 2 at the end so like "SslSomething" becomes 
"SSLSomething2" then remove the 2 "SSLSomething"

My MINA workspace should have been set to spaces to match everything else.  My 
work work stuff is set to tabs and line breaks (it would have looked way 
different).  I will check it the next time I work on something.


was (Author: johnnyv):
[~elecharny] 

I don't understand the case sensitive thing, I had renamed all of the 
references already.  Are you trying to back-port this?

My MINA workspace should have been set to spaces to match everything else.  My 
work work stuff is set to tabs and line breaks (it would have looked way 
different).  I will check it the next time I work on something.

> Sporadic error when establishing a StartTLS or SSL connection
> -
>
> Key: DIRMINA-1157
> URL: https://issues.apache.org/jira/browse/DIRMINA-1157
> Project: MINA
>  Issue Type: Bug
>  Components: Core, SSL
>Affects Versions: 2.1.5
>Reporter: Steffen Liersch
>Priority: Blocker
>  Labels: security
> Attachments: SslHandler-compare.png, SslHandler-mod.java, 
> SslHandler.java
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> With the Mina components, a connection error occasionally occurs when 
> establishing a StartTLS or TLS connection. The cause is that payload data was 
> received immediately on the acknowledgement and is already in the receive 
> buffer.
> My colleagues have changed the checkStatus function of the SslHandler class 
> from apache-mina-2.1.5-src.zip so that the sporadic error demonstrably no 
> longer occurs. Please review the changes and include them in the codebase for 
> the next release.
> I have attached the original version of SslHandler.java, as well as the 
> modified version. Thank you for your support!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Commented] (DIRMINA-1157) Sporadic error when establishing a StartTLS or SSL connection

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480416#comment-17480416
 ] 

Jonathan Valliere commented on DIRMINA-1157:


[~elecharny] 

I don't understand the case sensitive thing, I had renamed all of the 
references already.  Are you trying to back-port this?

My MINA workspace should have been set to spaces to match everything else.  My 
work work stuff is set to tabs and line breaks (it would have looked way 
different).  I will check it the next time I work on something.

> Sporadic error when establishing a StartTLS or SSL connection
> -
>
> Key: DIRMINA-1157
> URL: https://issues.apache.org/jira/browse/DIRMINA-1157
> Project: MINA
>  Issue Type: Bug
>  Components: Core, SSL
>Affects Versions: 2.1.5
>Reporter: Steffen Liersch
>Priority: Blocker
>  Labels: security
> Attachments: SslHandler-compare.png, SslHandler-mod.java, 
> SslHandler.java
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> With the Mina components, a connection error occasionally occurs when 
> establishing a StartTLS or TLS connection. The cause is that payload data was 
> received immediately on the acknowledgement and is already in the receive 
> buffer.
> My colleagues have changed the checkStatus function of the SslHandler class 
> from apache-mina-2.1.5-src.zip so that the sporadic error demonstrably no 
> longer occurs. Please review the changes and include them in the codebase for 
> the next release.
> I have attached the original version of SslHandler.java, as well as the 
> modified version. Thank you for your support!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Commented] (DIRMINA-1157) Sporadic error when establishing a StartTLS or SSL connection

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480113#comment-17480113
 ] 

Jonathan Valliere commented on DIRMINA-1157:


Most, if not all SSL issues are resolved in the 2.2.X version of MINA.  It's 
been in pre-release for a year because we can't get enough eyes on it.

 

Emmanuel, can you update the SNAPSHOT?

> Sporadic error when establishing a StartTLS or SSL connection
> -
>
> Key: DIRMINA-1157
> URL: https://issues.apache.org/jira/browse/DIRMINA-1157
> Project: MINA
>  Issue Type: Bug
>  Components: Core, SSL
>Affects Versions: 2.1.5
>Reporter: Steffen Liersch
>Priority: Blocker
>  Labels: security
> Attachments: SslHandler-compare.png, SslHandler-mod.java, 
> SslHandler.java
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> With the Mina components, a connection error occasionally occurs when 
> establishing a StartTLS or TLS connection. The cause is that payload data was 
> received immediately on the acknowledgement and is already in the receive 
> buffer.
> My colleagues have changed the checkStatus function of the SslHandler class 
> from apache-mina-2.1.5-src.zip so that the sporadic error demonstrably no 
> longer occurs. Please review the changes and include them in the codebase for 
> the next release.
> I have attached the original version of SslHandler.java, as well as the 
> modified version. Thank you for your support!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

You can also use the DisableEncryptionWriteRequesf to wrap your
WriteRequest you want to bypass the SSL filter.

On Fri, Jan 21, 2022 at 3:58 AM Emmanuel Lécharny 
wrote:

> I have it working. The filter approach is actually the silmpler way to
> deal with the requirement, I don't even have to leverage the crypt
> bypass flag. I just check if the message to be written is the
> StartTlsResponse one, and if so, I 'jump' over the SslFilter:
>
>  public void filterWrite(NextFilter nextFilter, IoSession session,
> WriteRequest writeRequest) throws Exception {
>  if ( writeRequest.getOriginalMessage() instanceof
> StartTlsResponse )
>  {
>  // We need to bypass the SslFilter
>  IoFilterChain chain = session.getFilterChain();
>
>  for ( IoFilterChain.Entry entry : chain.getAll() )
>  {
>  IoFilter filter = entry.getFilter();
>
>  if ( filter instanceof SslFilter )
>  {
>  entry.getNextFilter().filterWrite( session,
> writeRequest );
>  }
>  }
>  }
>  else
>  {
>  nextFilter.filterWrite(session, writeRequest);
>  }
>  }
>
> Note: I set up the SslFilter first in the chain, immediately followed by
> the StartTLS filter:
>
>  chain.addFirst( "startTls", startTlsFilter );
>  chain.addFirst( "sslFilter", sslFilter );
>
> Simple, easy.
>
>
> Thanks Jonathan !
>
> On 20/01/2022 18:22, Emmanuel Lécharny wrote:
> >
> >
> > On 20/01/2022 13:25, Jonathan Valliere wrote:
> >> The old method was unsafe from a concurrency standpoint.  This
> >> switching logic should be in a filter.
> >
> > Agreed. StartTLS is by itself very intrusive and I think it deserves to
> > be made a MINA filter, instead of expecting MINA to be twisted in a way
> > that is not natural.
> >
> > Actually, with such a filter, we wouldn't even require the flag you have
> > added as a substitute for the session attribute.
> >
> > Thanks Jonathan !
> >
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

The old method was unsafe from a concurrency standpoint.  This switching
logic should be in a filter.

On Thu, Jan 20, 2022 at 1:40 AM Emmanuel Lécharny 
wrote:

>
>
> On 18/01/2022 14:06, Jonathan Valliere wrote:
> > Yes, I added that specifically for anyone who needed that attribute I
> > removed. Unlike that attribute of disable once, this is completely safe
> > to use.
>
> But sadly, it can't be used from the outside.
>
> The typical use from an application PoV is :
>
>  session.getIoSession().write( message );
>
> and it ends with:
>
>  public WriteFuture write(Object message, SocketAddress remoteAddress)
> {
>  ...
>  // Now, we can write the message. First, create a future
>  WriteFuture writeFuture = new DefaultWriteFuture(this);
>  WriteRequest writeRequest = new DefaultWriteRequest(message,
> writeFuture, remoteAddress);
>
>
> That means we should bypass this part, which would require some
> modification in this method.
>
>
>
> >
> > On Tue, Jan 18, 2022 at 3:12 AM Emmanuel Lécharny  > <mailto:elecha...@gmail.com>> wrote:
> >
> >
> >
> > On 18/01/2022 05:04, Jonathan Valliere wrote:
> >  > Doesn't the DisableEncryptionWriteRequest get you where you need
> > to go?
> >  > Just wrap the startTLS message and pass upstream into the
> SSLFilter.
> >
> >
> > You mean DisableEncryptWriteRequest, I guess. Yes, that should do the
> > trick !
> >
> > Will test it and tell you...
> >
> > Thanks !
> >
> > --
> > Emmanuel Lécharny
> >
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

Yes, I added that specifically for anyone who needed that attribute I
removed. Unlike that attribute of disable once, this is completely safe to
use.

On Tue, Jan 18, 2022 at 3:12 AM Emmanuel Lécharny 
wrote:

>
>
> On 18/01/2022 05:04, Jonathan Valliere wrote:
> > Doesn't the DisableEncryptionWriteRequest get you where you need to go?
> > Just wrap the startTLS message and pass upstream into the SSLFilter.
>
>
> You mean DisableEncryptWriteRequest, I guess. Yes, that should do the
> trick !
>
> Will test it and tell you...
>
> Thanks !
>
> --
> Emmanuel Lécharny
>

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

Doesn't the DisableEncryptionWriteRequest get you where you need to go?
Just wrap the startTLS message and pass upstream into the SSLFilter.

On Mon, Jan 17, 2022 at 10:11 PM Emmanuel Lécharny 
wrote:

>
>
> On 17/01/2022 17:13, Jonathan Valliere wrote:
> > Shouldn’t Directory be able to configure and add the SSLFiler on demand?
>
> Yes, this is done when it receives a startTLS request.
>
> There is a trick though: When the server receives the request, it should
> establish the SSL layer, then send back the StartTLS response *in clear*
>   for the client to start the HS when it receives the response. This is
> the reason we added the DISBALED_ENCRYPPTIPN_ONCE attributeKey in MINA:
>
>  /**
>   * A session attribute key that makes next one write request bypass
>   * this filter (not encrypting the data).  This is a marker attribute,
>   * which means that you can put whatever as its value. ({@link
> Boolean#TRUE}
>   * is preferred.)  The attribute is automatically removed from the
> session
>   * attribute map as soon as {@link IoSession#write(Object)} is
> invoked,
>   * and therefore should be put again if you want to make more messages
>   * bypass this filter.  This is especially useful when you implement
>   * StartTLS.
>   */
>  public static final AttributeKey DISABLE_ENCRYPTION_ONCE = new
> AttributeKey(SslFilter.class, "disableOnce");
>
> Without this flag, we would have potentially faced a race condition
> where we could send the startTLS response * before having established
> fully the SslFilter, and the client would then start the HS before the
> server is ready to process it.
>
> To summarize:
>
> C ---> startTLS request ---> S
>   
>   
> C <--- startTLS response <-- S
> .
> .
> .
> C ---> TLS ClientHELLO   --> S
>   
>  ...
>
>
> As you can see, the way LDAP protocol works make it necessary for MINA
> to be tweaked this way.
>
>
> >
> > It will setup and attempt to start the moment it’s added on the server
> > filterchain.
> >
> > On Mon, Jan 17, 2022 at 11:10 AM Emmanuel Lécharny  > <mailto:elecha...@gmail.com>> wrote:
> >
> >
> >
> > On 17/01/2022 16:48, Jonathan Valliere wrote:
> >  > I think that piece of code is trying to move the concern of
> > configuring
> >  > the SSL into a place which doesn’t have enough information about
> the
> >  > state.  The Ciphers can be set when the Filter is created.  If a
> > special
> >  > workflow is needed, you can always extend SSLFilter now which has
> >  > convenient override handlers.
> >
> > Well, I don't think it's necessary in this case.
> >
> > What we need in LDAP Server is the possibility, on demand, to
> establish
> > a crypted session. That means the previous communication was in
> clear,
> > and we ask the server to be ready to handle a HS.
> >
> > That is as simple.
> >
> > Note that in Apache Directory server we have the possibility to
> define
> > the ciphers per configuration, and this is taken into account in the
> > first part of the 'if'.
> >
> > I question the second part as it seems to violate the (LDAP
> > StartTLS) RFC.
> >
> > So bottom line, it's not a MINA issue, but rather a Directory one.
> >
> > --
> > Emmanuel Lécharny
> >
> > --
> > CONFIDENTIALITY NOTICE: The contents of this email message and any
> > attachments are intended solely for the addressee(s) and may contain
> > confidential and/or privileged information and may be legally protected
> > from disclosure.
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

Shouldn’t Directory be able to configure and add the SSLFiler on demand?

It will setup and attempt to start the moment it’s added on the server
filterchain.

On Mon, Jan 17, 2022 at 11:10 AM Emmanuel Lécharny 
wrote:

>
>
> On 17/01/2022 16:48, Jonathan Valliere wrote:
> > I think that piece of code is trying to move the concern of configuring
> > the SSL into a place which doesn’t have enough information about the
> > state.  The Ciphers can be set when the Filter is created.  If a special
> > workflow is needed, you can always extend SSLFilter now which has
> > convenient override handlers.
>
> Well, I don't think it's necessary in this case.
>
> What we need in LDAP Server is the possibility, on demand, to establish
> a crypted session. That means the previous communication was in clear,
> and we ask the server to be ready to handle a HS.
>
> That is as simple.
>
> Note that in Apache Directory server we have the possibility to define
> the ciphers per configuration, and this is taken into account in the
> first part of the 'if'.
>
> I question the second part as it seems to violate the (LDAP StartTLS) RFC.
>
> So bottom line, it's not a MINA issue, but rather a Directory one.
>
> --
> Emmanuel Lécharny
>
-- 
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

I think that piece of code is trying to move the concern of configuring the
SSL into a place which doesn’t have enough information about the state.
The Ciphers can be set when the Filter is created.  If a special workflow
is needed, you can always extend SSLFilter now which has convenient
override handlers.

Maintaining clear understanding of which code and which flow has the
responsibility of setting up the SSL is important for maintainability and
testing.

On Mon, Jan 17, 2022 at 10:30 AM Emmanuel Lécharny 
wrote:

> Some more difference:
>
> In order to be able to programatically start a SSL session, we need the
> startSsl/stopTls methods in the SslFilter.
>
> I'm trying to figure out if this is not a superfluous addition in MINA.
> The directory server code looks like that:
>
> public void handleExtendedOperation( LdapSession session,
> ExtendedRequest req ) throws Exception
> {
>  IoFilterChain chain = session.getIoSession().getFilterChain();
>  SslFilter sslFilter = ( SslFilter ) chain.get( "sslFilter" );
>
>  if ( sslFilter == null )
>  {
>  // Establish the ssl filter
>  }
>  else
>  {
>  // Be sure we disable SSLV3
>  sslFilter.setEnabledProtocols( new String[]
>  { "TLSv1", "TLSv1.1", "TLSv1.2" } );
>  sslFilter.startSsl( session.getIoSession() ); // What for ???
>  }
>
> Actually, there is no reason to redo a handshake if the SSLFilter has
> already been established, and I think we mis-understood the RFC, which
> says:
>
> "3.1.1.  StartTLS Request Sequencing
>
> A client may send the StartTLS extended request at any time after
> establishing an LDAP session, except:
>
>- when TLS is currently established on the session,"
>
> So I guess this missing method is a no problem.
>
>
> On 17/01/2022 15:50, Jonathan Valliere wrote:
> > AFAIK the usage you described is fully compatible with the process I
> > outlined in my previous email.
> >
> > You have access to the peer certificate after the handshake is done or
> are
> > you needing access earlier?
> >
> > On Mon, Jan 17, 2022 at 9:40 AM Emmanuel Lécharny 
> > wrote:
> >
> >>
> >>
> >> On 17/01/2022 15:09, Jonathan Valliere wrote:
> >>> Emmanuel,
> >>>
> >>> The access of the SslSession was moved into an AttributeKey which is
> set
> >>> BEFORE the SECURED event is fired.  This was done to help improve best
> >>> practices for when this object is accessible.  Your application can
> >> listen
> >>> for the SECURED event then read the AttributeKey to obtain the
> >> SslSession.
> >>>
> >>>
> >>
> https://github.com/apache/mina/blob/660ab2375b4b47b5ebe86226c92f3138be4c96e8/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L56
> >>
> >> My second mail clarified my requirement. I need to have access to the
> >> SslSession instance, to grab the client certificate from it.
> >>
> >> --
> >> Emmanuel Lécharny
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> >> For additional commands, e-mail: dev-h...@mina.apache.org
> >>
> >>
> >
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
> --
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

AFAIK the usage you described is fully compatible with the process I
outlined in my previous email.

You have access to the peer certificate after the handshake is done or are
you needing access earlier?

On Mon, Jan 17, 2022 at 9:40 AM Emmanuel Lécharny 
wrote:

>
>
> On 17/01/2022 15:09, Jonathan Valliere wrote:
> > Emmanuel,
> >
> > The access of the SslSession was moved into an AttributeKey which is set
> > BEFORE the SECURED event is fired.  This was done to help improve best
> > practices for when this object is accessible.  Your application can
> listen
> > for the SECURED event then read the AttributeKey to obtain the
> SslSession.
> >
> >
> https://github.com/apache/mina/blob/660ab2375b4b47b5ebe86226c92f3138be4c96e8/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L56
>
> My second mail clarified my requirement. I need to have access to the
> SslSession instance, to grab the client certificate from it.
>
> --
> Emmanuel Lécharny
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: MINA read buffer default size: is it too small ?

[Jonathan Valliere]

Emmanuel,

The socket receive side buffer is stored for as long as necessary.  You are
referring to the clear-text application buffer here
https://github.com/apache/mina/blob/660ab2375b4b47b5ebe86226c92f3138be4c96e8/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandler.java#L277

It would be possible to cache this in a Thread-Local-style however, not all
SSL sessions have the same parameters so you risk necessary expansions;
additionally you would have to permanently remove that buffer from
Thread-Local once anything is written into it for safety of the
user-application.  Have to be very careful not to maintain any pointers
once that or a section of that buffer has been passed onto the next
downstream filter.

Doesn't IoBuffer have a built-in caching mechanism?  free() is called when
its no longer needed which should make it fully compatible
https://github.com/apache/mina/blob/660ab2375b4b47b5ebe86226c92f3138be4c96e8/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java#L201

There is some room for improvements on decoding as many messages as
possible on the receive side before looping.  I will think about that.

On Mon, Jan 17, 2022 at 1:30 AM Emmanuel Lécharny 
wrote:

>
>
> On 14/01/2022 14:46, Jonathan Valliere wrote:
> >
> https://github.com/apache/mina/blob/c0ee516726c21115b196834ee984be786cea5818/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandler.java#L277
> >
> > in 2.2.X the decode buffer is automatically calculated based on the input
> > size so the entire input buffer can be decoded.  These buffers cannot be
> > cached anywhere like Thread-Local because the decoded buffer must be
> > cleanly passed onto the next filter which may or may not go asynchronous.
>
>
> Hi Jonathan,
>
> when we receive data, we first allocate a 2048 buffer (default size, can
> be changed with config), read the data and propagate it to the chain.
>
> The Sslhandler first step is to allocate a big (16Kb) buffer before
> calling SslEngine.unwrap().
>
> This is where I think it might make sense to use a TLS stored buffer:
> - we reuse it in SslHandler for the app buffer
> - if unwrap does not have any byte produced (HS), then we can simply
> reset the buffer
> - otherwise we can now allocate the proper buffer (which is likely to be
> way smaller) to fit the clear text data into it, instead of passing the
> big allocated buffer to the next filter.
>
> The gain would be:
> - avoiding allocating a buffer during the HS when unwrap does not
> produce anything
> - creating smaller objects in the standard processing (ie data processing)
>
> Emmanuel
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: MINA 2.1 vs MINA 2.2 API differences

[Jonathan Valliere]

Emmanuel,

The access of the SslSession was moved into an AttributeKey which is set
BEFORE the SECURED event is fired.  This was done to help improve best
practices for when this object is accessible.  Your application can listen
for the SECURED event then read the AttributeKey to obtain the SslSession.

https://github.com/apache/mina/blob/660ab2375b4b47b5ebe86226c92f3138be4c96e8/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L56

Since the state of SslSession is tied to actually connecting, it is really
only valid from a flow process after the first handshake is completed.  The
AttributeKey also doubles in meaning that, if present, the session is
secured.

The option to manually set UseClientMode was removed to help prevent
accidental incorrect usage.  Is there a specific reason you would like that
back?

On Mon, Jan 17, 2022 at 8:49 AM Emmanuel Lécharny 
wrote:

>
>
> On 17/01/2022 14:17, Emmanuel Lécharny wrote:
> > Hi Jonathan,
> >
> > I'm testing MINA 2.2 in Apache Directory, and there are two API
> > differences :
> >
> > - The SslSession is not anymore present in the IoSession attributes. Is
> > there any reason for the removal ?
>
> To clarify, we need this information in the Directory server:
>
>  /**
>   * {@inheritDoc}
>   */
>  public byte[] evaluateResponse( byte[] initialResponse ) throws
> SaslException
>  {
>  try
>  {
>  SSLSession sslSession = ( SSLSession )
> getLdapSession().getIoSession().getAttribute( SslFilter.SSL_SESSION );
>  Certificate[] peerCertificates =
> sslSession.getPeerCertificates();
>
>  if ( null == peerCertificates || 1 > peerCertificates.length )
>  {
>  throw new SaslException( "No peer certificate provided
> - cancel bind." );
>  }
>
>  getLdapSession().setCoreSession( authenticate(
> peerCertificates[0] ) );
>  state = NegotiationState.COMPLETED;
>  }
>
> --
> Emmanuel Lécharny
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: MINA 2.2: some more test failures

[Jonathan Valliere]

Emmanuel,

Disabling the handshake aggregation by setting ENABLE_FAST_HANDSHAKE to
false still has it fail on Java 8.

This could be a straight up bug in Java 8 with renegotiations.  I also
tried disabling the CLOSE messages, but it didn't make any difference.



On Sat, Jan 15, 2022 at 1:05 AM Emmanuel Lécharny 
wrote:

>
> Hi Jona than,
>
> indeed, same here. If I switch to Java 11, it passes.
>
> What puzzles me is that the same test passes with Java 8 on MINA 2.1.5...
>
> Now, let's face reality: in TLS 1.3, reneg has been deprecated, so this
> test is soon going to be useless. And Java 8 is not anymore maintained
> (unless you pay for it), so I don't really mind if we decide that Java
> 11 is mandatory for MINA 2.2.
>
> I suspect there is some issue in the way Java 8 process incoming data.
> In MINA 2.2, the read buffer contains all the HS server data
> (ServerHello + ChangeCipherSpec +ServerHandshakeFinished) in one PDU,
> while in MINA 2.1.5 the client has to read 3 PDUs to get the same data.
> This may make a difference.
>
>
> Thanks !
>
>
> On 15/01/2022 04:17, Jonathan Valliere wrote:
> > Additionally, that unit test you referenced is passing for me on
> > AdoptOpenJDK 11
> >
> > On Fri, Jan 14, 2022 at 10:10 PM Jonathan Valliere  > <mailto:john...@apache.org>> wrote:
> >
> > Can you send the server debugging logs?
> >
> > On Fri, Jan 14, 2022 at 7:46 PM Emmanuel Lécharny
> > mailto:elecha...@gmail.com>> wrote:
> >
> >
> >
> > On 14/01/2022 18:48, Emmanuel Lécharny wrote:
> >  > Hi Jonathan,
> >  >
> >  > I also have a failure in
> > SslFilterTest.testMessageSentIsCalled_With_SSL.
> >  >
> >  > What happens is that we try to send 2 messages (test-1 and
> > test-2) with
> >  > SSL established, but we do a SSL renegociation in between the
> > first
> >  > message sending and the second.
> >  >
> >  > For some unknown reason, when we try to read the response on
> > the client
> >  > side (something we do in one shot after the second message
> > has been
> >  > sent), we never get back the second message.
> >  >
> >  > I'm positive it has been sent, I strongly suspect that the
> > client socket
> >  > lose it during the SSL uncrypting *after* the Ssl reneg has
> > occured.
> >
> > So here are the data being sent by the server with MINA 2.1.5:
> >
> > HeapBuffer[pos=0 lim=1332 cap=2115: 16 03 03 05 2F 02 00 00 51
> > 03 03 61
> > E2 12 0B 67] (ServerHello)
> > HeapBuffer[pos=0 lim=6 cap=8: 14 03 03 00 01 01]
> (ChangeCipherSpec)
> > HeapBuffer[pos=0 lim=101 cap=132: 16 03 03 00 60 43 27 00 F6 69
> > CD 46 99
> > 0D A4 B2] (ServerHandshakeFinished)
> > HeapBuffer[pos=0 lim=85 cap=132: 17 03 03 00 50 6E 02 38 7C 72
> > 31 73 EF
> > 12 00 F6] (Data)
> >
> > rehandhsake
> >
> > HeapBuffer[pos=0 lim=181 cap=264: 16 03 03 00 B0 7D 9A 82 9D 00
> > 34 46 FB
> > 53 6C 16] (ServerHello)
> > HeapBuffer[pos=0 lim=85 cap=132: 14 03 03 00 50 99 F3 FC 9C 7E
> > FF 9A 7C
> > 5C BA C7] (ChangeCipherSpec)
> > HeapBuffer[pos=0 lim=101 cap=132: 16 03 03 00 60 80 B1 2C C0 6F
> > B8 5A 5C
> > 2D 46 26] (ServerHandshakeFinished)
> > HeapBuffer[pos=0 lim=85 cap=132: 17 03 03 00 50 0C D5 D8 0E CB
> > 18 F1 A4
> > AA 75 27]
> > HeapBuffer[pos=0 lim=85 cap=132: 15 03 03 00 50 42 7B BE AF B8
> > 2C 64 88
> > F3 F5 A6]
> >
> >
> > And with MLINA 2.2.0:
> >
> > HeapBuffer@4b38503[pos=0 lim=1332 cap=33842: 16 03 03 05 2F 02
> > 00 00 51
> > 03 03 61 E2 13 CE CD] (ServerHello)
> > HeapBuffer@58e57fe3[pos=0 lim=107 cap=33842: 14 03 03 00 01 01
> > 16 03 03
> > 00 60 AA 0C 98 25 E0] (ChangeCipherSpec) +
> (ServerHandshakeFinished)
> > HeapBuffer@26e25a06[pos=0 lim=85 cap=33842: 17 03 03 00 50 F9 A1
> > D5 CB
> > 5E 78 73 29 60 C0 FF] (Data)
> >
> > rehandshake
> >
> > HeapBuffer@1558ae1[pos=0 lim=367 cap=33842: 16 03 03 00 B0 BF CD
> > B1 5D
> > F9 5B FC 56 11 52 69] (ServerHello) + ChangeCipherSpec

Re: MINA 2.2 SSL issue when removing the SSL filter on the client side

[Jonathan Valliere]

What if the server is sending encrypted responses and the client sends a
close command.  If we allowed continued writing in clear text on the
server, we could end up exposing data the sender thought was encrypted.

On Fri, Jan 14, 2022 at 11:02 PM Jonathan Valliere 
wrote:

> I checked that test and you are correct it fails.  I could easily add
> mEngine.isInboundDone() check and bypass decoding and the same for
> encoding.  However, I pose this question.  Should we really support this
> behavior in the SSLFilter; couldn't that lead to situations where someone
> is expecting an encrypted session without knowing it was removed?  I
> removed the attribute to enable and disable SSL because that was inherently
> insecure and prone to concurrent/race conditions.
>
> The best thing we could probably do is throw Close exceptions when
> receiving or writing to the closed SSLFilter.
>
> On Fri, Jan 14, 2022 at 12:30 PM Emmanuel Lécharny 
> wrote:
>
>> Hi Jonathan,
>>
>> I'm reviewing the SSL code in Mina 2.2 and we have an issue in a
>> specific use case, ie ConnectorTest.testTCPWithSSL:
>> - the client establishes a SSL connection
>> - it sends some data (all is ok)
>> - the client removes the SSL filter (but keep the connection opened)
>> - it tries to send clear text messages and the Sslhandler is trying to
>> uncrypt them
>>
>> The pb is probably in the test where the server does not remove the
>> SslFilter from the chain. Note that this test is @disabled in 2.1.X (and
>> I'm positive that this test has the same issue in 2.1.X)
>>
>> I think we either have to fix the test (removing the SslFilter from the
>> server when we remove it from the client) or @ignore the test.
>> --
>> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
>> T. +33 (0)4 89 97 36 50
>> P. +33 (0)6 08 33 32 61
>> emmanuel.lecha...@busit.com https://www.busit.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
>> For additional commands, e-mail: dev-h...@mina.apache.org
>>
>>

Re: MINA 2.2 SSL issue when removing the SSL filter on the client side

[Jonathan Valliere]

I checked that test and you are correct it fails.  I could easily add
mEngine.isInboundDone() check and bypass decoding and the same for
encoding.  However, I pose this question.  Should we really support this
behavior in the SSLFilter; couldn't that lead to situations where someone
is expecting an encrypted session without knowing it was removed?  I
removed the attribute to enable and disable SSL because that was inherently
insecure and prone to concurrent/race conditions.

The best thing we could probably do is throw Close exceptions when
receiving or writing to the closed SSLFilter.

On Fri, Jan 14, 2022 at 12:30 PM Emmanuel Lécharny 
wrote:

> Hi Jonathan,
>
> I'm reviewing the SSL code in Mina 2.2 and we have an issue in a
> specific use case, ie ConnectorTest.testTCPWithSSL:
> - the client establishes a SSL connection
> - it sends some data (all is ok)
> - the client removes the SSL filter (but keep the connection opened)
> - it tries to send clear text messages and the Sslhandler is trying to
> uncrypt them
>
> The pb is probably in the test where the server does not remove the
> SslFilter from the chain. Note that this test is @disabled in 2.1.X (and
> I'm positive that this test has the same issue in 2.1.X)
>
> I think we either have to fix the test (removing the SslFilter from the
> server when we remove it from the client) or @ignore the test.
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: MINA 2.2: some more test failures

[Jonathan Valliere]

r] -
> SSLHandlerG0@4240f14c[mode=server, connected=true] receive() - recursion
> [22:19:09] DEBUG [org.apache.mina.filter.ssl.SSLHandler] -
> SSLHandlerG0@4240f14c[mode=server, connected=true] receive_loop() -
> source HeapBuffer@a3aae2a[pos=88 lim=133 cap=1024: 17 03 03 00 28 58 7B
> 99 DA B0 9C 48 DC A0 57 01]
> [22:19:09] DEBUG [org.apache.mina.filter.ssl.SSLHandler] -
> SSLHandlerG0@4240f14c[mode=server, connected=true] receive_loop() -
> bytes-consumed 45, bytes-produced 7, status OK, handshake NOT_HANDSHAKING
> [22:19:09] DEBUG [org.apache.mina.filter.ssl.SSLHandler] -
> SSLHandlerG0@4240f14c[mode=server, connected=true] receive_loop() - *result
> HeapBuffer@5843a2bd[pos=0 lim=7 cap=16676: 74 65 73 74 2D 32 0A]*
> *[22:19:09] DEBUG [org.apache.mina.filter.codec.ProtocolCodecFilter] -
> Processing a MESSAGE_RECEIVED for session 1*


On Fri, Jan 14, 2022 at 10:17 PM Jonathan Valliere 
wrote:

> Additionally, that unit test you referenced is passing for me on
> AdoptOpenJDK 11
>
> On Fri, Jan 14, 2022 at 10:10 PM Jonathan Valliere 
> wrote:
>
>> Can you send the server debugging logs?
>>
>> On Fri, Jan 14, 2022 at 7:46 PM Emmanuel Lécharny 
>> wrote:
>>
>>>
>>>
>>> On 14/01/2022 18:48, Emmanuel Lécharny wrote:
>>> > Hi Jonathan,
>>> >
>>> > I also have a failure in
>>> SslFilterTest.testMessageSentIsCalled_With_SSL.
>>> >
>>> > What happens is that we try to send 2 messages (test-1 and test-2)
>>> with
>>> > SSL established, but we do a SSL renegociation in between the first
>>> > message sending and the second.
>>> >
>>> > For some unknown reason, when we try to read the response on the
>>> client
>>> > side (something we do in one shot after the second message has been
>>> > sent), we never get back the second message.
>>> >
>>> > I'm positive it has been sent, I strongly suspect that the client
>>> socket
>>> > lose it during the SSL uncrypting *after* the Ssl reneg has occured.
>>>
>>> So here are the data being sent by the server with MINA 2.1.5:
>>>
>>> HeapBuffer[pos=0 lim=1332 cap=2115: 16 03 03 05 2F 02 00 00 51 03 03 61
>>> E2 12 0B 67] (ServerHello)
>>> HeapBuffer[pos=0 lim=6 cap=8: 14 03 03 00 01 01] (ChangeCipherSpec)
>>> HeapBuffer[pos=0 lim=101 cap=132: 16 03 03 00 60 43 27 00 F6 69 CD 46 99
>>> 0D A4 B2] (ServerHandshakeFinished)
>>> HeapBuffer[pos=0 lim=85 cap=132: 17 03 03 00 50 6E 02 38 7C 72 31 73 EF
>>> 12 00 F6] (Data)
>>>
>>> rehandhsake
>>>
>>> HeapBuffer[pos=0 lim=181 cap=264: 16 03 03 00 B0 7D 9A 82 9D 00 34 46 FB
>>> 53 6C 16] (ServerHello)
>>> HeapBuffer[pos=0 lim=85 cap=132: 14 03 03 00 50 99 F3 FC 9C 7E FF 9A 7C
>>> 5C BA C7] (ChangeCipherSpec)
>>> HeapBuffer[pos=0 lim=101 cap=132: 16 03 03 00 60 80 B1 2C C0 6F B8 5A 5C
>>> 2D 46 26] (ServerHandshakeFinished)
>>> HeapBuffer[pos=0 lim=85 cap=132: 17 03 03 00 50 0C D5 D8 0E CB 18 F1 A4
>>> AA 75 27]
>>> HeapBuffer[pos=0 lim=85 cap=132: 15 03 03 00 50 42 7B BE AF B8 2C 64 88
>>> F3 F5 A6]
>>>
>>>
>>> And with MLINA 2.2.0:
>>>
>>> HeapBuffer@4b38503[pos=0 lim=1332 cap=33842: 16 03 03 05 2F 02 00 00 51
>>> 03 03 61 E2 13 CE CD] (ServerHello)
>>> HeapBuffer@58e57fe3[pos=0 lim=107 cap=33842: 14 03 03 00 01 01 16 03 03
>>> 00 60 AA 0C 98 25 E0] (ChangeCipherSpec) + (ServerHandshakeFinished)
>>> HeapBuffer@26e25a06[pos=0 lim=85 cap=33842: 17 03 03 00 50 F9 A1 D5 CB
>>> 5E 78 73 29 60 C0 FF] (Data)
>>>
>>> rehandshake
>>>
>>> HeapBuffer@1558ae1[pos=0 lim=367 cap=33842: 16 03 03 00 B0 BF CD B1 5D
>>> F9 5B FC 56 11 52 69] (ServerHello) + ChangeCipherSpec) +
>>> (ServerHandshakeFinished)
>>> HeapBuffer@5038afc9[pos=0 lim=85 cap=33842: 17 03 03 00 50 6A F9 B7 57
>>> 5C A3 1D A0 14 26 87] (Data)
>>>
>>>
>>> It's pretty much like if the server sends HS data as a whole instead of
>>> splitting them in pieces. However, I think everything is there, so I
>>> don't understand why it fails in MINA 2.2...
>>>
>>> --
>>> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
>>> T. +33 (0)4 89 97 36 50
>>> P. +33 (0)6 08 33 32 61
>>> emmanuel.lecha...@busit.com https://www.busit.com/
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
>>> For additional commands, e-mail: dev-h...@mina.apache.org
>>>
>>>

Re: MINA 2.2: some more test failures

[Jonathan Valliere]

Additionally, that unit test you referenced is passing for me on
AdoptOpenJDK 11

On Fri, Jan 14, 2022 at 10:10 PM Jonathan Valliere 
wrote:

> Can you send the server debugging logs?
>
> On Fri, Jan 14, 2022 at 7:46 PM Emmanuel Lécharny 
> wrote:
>
>>
>>
>> On 14/01/2022 18:48, Emmanuel Lécharny wrote:
>> > Hi Jonathan,
>> >
>> > I also have a failure in SslFilterTest.testMessageSentIsCalled_With_SSL.
>> >
>> > What happens is that we try to send 2 messages (test-1 and test-2) with
>> > SSL established, but we do a SSL renegociation in between the first
>> > message sending and the second.
>> >
>> > For some unknown reason, when we try to read the response on the client
>> > side (something we do in one shot after the second message has been
>> > sent), we never get back the second message.
>> >
>> > I'm positive it has been sent, I strongly suspect that the client
>> socket
>> > lose it during the SSL uncrypting *after* the Ssl reneg has occured.
>>
>> So here are the data being sent by the server with MINA 2.1.5:
>>
>> HeapBuffer[pos=0 lim=1332 cap=2115: 16 03 03 05 2F 02 00 00 51 03 03 61
>> E2 12 0B 67] (ServerHello)
>> HeapBuffer[pos=0 lim=6 cap=8: 14 03 03 00 01 01] (ChangeCipherSpec)
>> HeapBuffer[pos=0 lim=101 cap=132: 16 03 03 00 60 43 27 00 F6 69 CD 46 99
>> 0D A4 B2] (ServerHandshakeFinished)
>> HeapBuffer[pos=0 lim=85 cap=132: 17 03 03 00 50 6E 02 38 7C 72 31 73 EF
>> 12 00 F6] (Data)
>>
>> rehandhsake
>>
>> HeapBuffer[pos=0 lim=181 cap=264: 16 03 03 00 B0 7D 9A 82 9D 00 34 46 FB
>> 53 6C 16] (ServerHello)
>> HeapBuffer[pos=0 lim=85 cap=132: 14 03 03 00 50 99 F3 FC 9C 7E FF 9A 7C
>> 5C BA C7] (ChangeCipherSpec)
>> HeapBuffer[pos=0 lim=101 cap=132: 16 03 03 00 60 80 B1 2C C0 6F B8 5A 5C
>> 2D 46 26] (ServerHandshakeFinished)
>> HeapBuffer[pos=0 lim=85 cap=132: 17 03 03 00 50 0C D5 D8 0E CB 18 F1 A4
>> AA 75 27]
>> HeapBuffer[pos=0 lim=85 cap=132: 15 03 03 00 50 42 7B BE AF B8 2C 64 88
>> F3 F5 A6]
>>
>>
>> And with MLINA 2.2.0:
>>
>> HeapBuffer@4b38503[pos=0 lim=1332 cap=33842: 16 03 03 05 2F 02 00 00 51
>> 03 03 61 E2 13 CE CD] (ServerHello)
>> HeapBuffer@58e57fe3[pos=0 lim=107 cap=33842: 14 03 03 00 01 01 16 03 03
>> 00 60 AA 0C 98 25 E0] (ChangeCipherSpec) + (ServerHandshakeFinished)
>> HeapBuffer@26e25a06[pos=0 lim=85 cap=33842: 17 03 03 00 50 F9 A1 D5 CB
>> 5E 78 73 29 60 C0 FF] (Data)
>>
>> rehandshake
>>
>> HeapBuffer@1558ae1[pos=0 lim=367 cap=33842: 16 03 03 00 B0 BF CD B1 5D
>> F9 5B FC 56 11 52 69] (ServerHello) + ChangeCipherSpec) +
>> (ServerHandshakeFinished)
>> HeapBuffer@5038afc9[pos=0 lim=85 cap=33842: 17 03 03 00 50 6A F9 B7 57
>> 5C A3 1D A0 14 26 87] (Data)
>>
>>
>> It's pretty much like if the server sends HS data as a whole instead of
>> splitting them in pieces. However, I think everything is there, so I
>> don't understand why it fails in MINA 2.2...
>>
>> --
>> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
>> T. +33 (0)4 89 97 36 50
>> P. +33 (0)6 08 33 32 61
>> emmanuel.lecha...@busit.com https://www.busit.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
>> For additional commands, e-mail: dev-h...@mina.apache.org
>>
>>

Re: MINA 2.2: some more test failures

[Jonathan Valliere]

Can you send the server debugging logs?

On Fri, Jan 14, 2022 at 7:46 PM Emmanuel Lécharny 
wrote:

>
>
> On 14/01/2022 18:48, Emmanuel Lécharny wrote:
> > Hi Jonathan,
> >
> > I also have a failure in SslFilterTest.testMessageSentIsCalled_With_SSL.
> >
> > What happens is that we try to send 2 messages (test-1 and test-2) with
> > SSL established, but we do a SSL renegociation in between the first
> > message sending and the second.
> >
> > For some unknown reason, when we try to read the response on the client
> > side (something we do in one shot after the second message has been
> > sent), we never get back the second message.
> >
> > I'm positive it has been sent, I strongly suspect that the client socket
> > lose it during the SSL uncrypting *after* the Ssl reneg has occured.
>
> So here are the data being sent by the server with MINA 2.1.5:
>
> HeapBuffer[pos=0 lim=1332 cap=2115: 16 03 03 05 2F 02 00 00 51 03 03 61
> E2 12 0B 67] (ServerHello)
> HeapBuffer[pos=0 lim=6 cap=8: 14 03 03 00 01 01] (ChangeCipherSpec)
> HeapBuffer[pos=0 lim=101 cap=132: 16 03 03 00 60 43 27 00 F6 69 CD 46 99
> 0D A4 B2] (ServerHandshakeFinished)
> HeapBuffer[pos=0 lim=85 cap=132: 17 03 03 00 50 6E 02 38 7C 72 31 73 EF
> 12 00 F6] (Data)
>
> rehandhsake
>
> HeapBuffer[pos=0 lim=181 cap=264: 16 03 03 00 B0 7D 9A 82 9D 00 34 46 FB
> 53 6C 16] (ServerHello)
> HeapBuffer[pos=0 lim=85 cap=132: 14 03 03 00 50 99 F3 FC 9C 7E FF 9A 7C
> 5C BA C7] (ChangeCipherSpec)
> HeapBuffer[pos=0 lim=101 cap=132: 16 03 03 00 60 80 B1 2C C0 6F B8 5A 5C
> 2D 46 26] (ServerHandshakeFinished)
> HeapBuffer[pos=0 lim=85 cap=132: 17 03 03 00 50 0C D5 D8 0E CB 18 F1 A4
> AA 75 27]
> HeapBuffer[pos=0 lim=85 cap=132: 15 03 03 00 50 42 7B BE AF B8 2C 64 88
> F3 F5 A6]
>
>
> And with MLINA 2.2.0:
>
> HeapBuffer@4b38503[pos=0 lim=1332 cap=33842: 16 03 03 05 2F 02 00 00 51
> 03 03 61 E2 13 CE CD] (ServerHello)
> HeapBuffer@58e57fe3[pos=0 lim=107 cap=33842: 14 03 03 00 01 01 16 03 03
> 00 60 AA 0C 98 25 E0] (ChangeCipherSpec) + (ServerHandshakeFinished)
> HeapBuffer@26e25a06[pos=0 lim=85 cap=33842: 17 03 03 00 50 F9 A1 D5 CB
> 5E 78 73 29 60 C0 FF] (Data)
>
> rehandshake
>
> HeapBuffer@1558ae1[pos=0 lim=367 cap=33842: 16 03 03 00 B0 BF CD B1 5D
> F9 5B FC 56 11 52 69] (ServerHello) + ChangeCipherSpec) +
> (ServerHandshakeFinished)
> HeapBuffer@5038afc9[pos=0 lim=85 cap=33842: 17 03 03 00 50 6A F9 B7 57
> 5C A3 1D A0 14 26 87] (Data)
>
>
> It's pretty much like if the server sends HS data as a whole instead of
> splitting them in pieces. However, I think everything is there, so I
> don't understand why it fails in MINA 2.2...
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: MINA read buffer default size: is it too small ?

[Jonathan Valliere]

https://github.com/apache/mina/blob/c0ee516726c21115b196834ee984be786cea5818/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandler.java#L277

in 2.2.X the decode buffer is automatically calculated based on the input
size so the entire input buffer can be decoded.  These buffers cannot be
cached anywhere like Thread-Local because the decoded buffer must be
cleanly passed onto the next filter which may or may not go asynchronous.

On Fri, Jan 14, 2022 at 7:38 AM Jonathan Valliere 
wrote:

> Please point to the line of code in GitHub.  GitHub has a great tool for
> linking directly to lines.
>
> On Fri, Jan 14, 2022 at 3:49 AM Emmanuel Lécharny 
> wrote:
>
>> Hi,
>>
>> I'm reviewing some parts of MINA (more specifically the SSL part), and I
>> found that we default the read buffer to 2048 bytes, which seems a bit
>> too small to me.
>>
>> Typically, when handling TLS messages, we may have up to 16384 PDUs
>> (max). If the buffer is too small, we havve to do some extra read up to
>> the point we have received all the needed data.
>>
>> At this point, I wonder if it wouldn't be a better idea to size the
>> buffer to at least the max PDU size of a TLS message (ie 16384 bytes).
>>
>> The drawback is that it may be more demanding on the GC, as we will
>> allocate bigger buffers for each incoming message.
>>
>>
>> Incenditally I wonder if it wouldn't be a good idea to use a Thread
>> Local Storage to keep the allocated buffer, and avoiding the allocation
>> of such a buffer for every call (assuming we copy it if there is an
>> executor in the chain).
>>
>>
>> Thoughts ?
>>
>> --
>> Emmanuel Lécharny
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
>> For additional commands, e-mail: dev-h...@mina.apache.org
>>
>>

Re: MINA read buffer default size: is it too small ?

[Jonathan Valliere]

Please point to the line of code in GitHub.  GitHub has a great tool for
linking directly to lines.

On Fri, Jan 14, 2022 at 3:49 AM Emmanuel Lécharny 
wrote:

> Hi,
>
> I'm reviewing some parts of MINA (more specifically the SSL part), and I
> found that we default the read buffer to 2048 bytes, which seems a bit
> too small to me.
>
> Typically, when handling TLS messages, we may have up to 16384 PDUs
> (max). If the buffer is too small, we havve to do some extra read up to
> the point we have received all the needed data.
>
> At this point, I wonder if it wouldn't be a better idea to size the
> buffer to at least the max PDU size of a TLS message (ie 16384 bytes).
>
> The drawback is that it may be more demanding on the GC, as we will
> allocate bigger buffers for each incoming message.
>
>
> Incenditally I wonder if it wouldn't be a good idea to use a Thread
> Local Storage to keep the allocated buffer, and avoiding the allocation
> of such a buffer for every call (assuming we copy it if there is an
> executor in the chain).
>
>
> Thoughts ?
>
> --
> Emmanuel Lécharny
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

[jira] [Resolved] (DIRMINA-1153) MINA: Exception thrown at the client side - ProtocolDecoderException:BufferDataException

[Jonathan Valliere (Jira)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Valliere resolved DIRMINA-1153.

  Assignee: Jonathan Valliere
Resolution: Won't Fix

> MINA: Exception thrown at the client side - 
> ProtocolDecoderException:BufferDataException
> 
>
> Key: DIRMINA-1153
> URL: https://issues.apache.org/jira/browse/DIRMINA-1153
> Project: MINA
>  Issue Type: Bug
>  Components: Handler
>Affects Versions: 2.0.19
>Reporter: Saravanan
>    Assignee: Jonathan Valliere
>Priority: Major
>
> Mina version:
> mina-core-2.0.19.jar
> Server code snippet:
>         IoAcceptor acceptor = new NioSocketAcceptor();
>         DefaultIoFilterChainBuilder chain = acceptor.getFilterChain();
>         LoggingFilter loggingFilter = new LoggingFilter();
>         loggingFilter.setMessageSentLogLevel(LogLevel.DEBUG);
>         loggingFilter.setMessageReceivedLogLevel(LogLevel.DEBUG);
>         loggingFilter.setSessionClosedLogLevel(LogLevel.DEBUG);
>         loggingFilter.setSessionCreatedLogLevel(LogLevel.DEBUG);
>         loggingFilter.setSessionIdleLogLevel(LogLevel.DEBUG);
>         loggingFilter.setSessionOpenedLogLevel(LogLevel.DEBUG);
>         chain.addLast("logger", loggingFilter);
>         MdcInjectionFilter mdcInjectionFilter = new MdcInjectionFilter();
>         chain.addLast("mdc", mdcInjectionFilter);
>         chain.addLast("codec", new ProtocolCodecFilter(new 
> ObjectSerializationCodecFactory()));
> Client code snippet:
>         NioSocketConnector connector = new NioSocketConnector();
>         LoggingFilter LOGGING_FILTER = new LoggingFilter("MinaLogging");
>         LOGGING_FILTER.setMessageSentLogLevel(LogLevel.DEBUG);
>         LOGGING_FILTER.setMessageReceivedLogLevel(LogLevel.DEBUG);
>         
>         IoFilter CODEC_FILTER = new ProtocolCodecFilter(new 
> ObjectSerializationCodecFactory());
>         connector.getFilterChain().addLast("mdc", new MdcInjectionFilter());
>         connector.getFilterChain().addLast("codec", CODEC_FILTER);
>         connector.getFilterChain().addLast("logger", LOGGING_FILTER);
> Exception:
> org.apache.mina.filter.codec.ProtocolDecoderException: 
> org.apache.mina.core.buffer.BufferDataException: dataLength: 1048985 
> (Hexdump: XX...)
> at 
> org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:262)
>  [mina-core-2.0.19.jar:?]
> at 
> org.apache.mina.filter.codec.CumulativeProtocolDecoder.decode(CumulativeProtocolDecoder.java:180)
>  ~[mina-core-2.0.19.jar:?]
> at 
> org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:253)
>  ~[mina-core-2.0.19.jar:?]
> Points:
> - There is no synchronization while writing...
> - There are multiple threads parallely wirting into the tcp connection 
> (around 100-200)
> - The problem is observed only when the load is high...
> I have seen similar tickets here and not sure about the RCA.
> https://issues.apache.org/jira/browse/DIRMINA-653
> Need help...



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Commented] (DIRMINA-1153) MINA: Exception thrown at the client side - ProtocolDecoderException:BufferDataException

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452961#comment-17452961
 ] 

Jonathan Valliere commented on DIRMINA-1153:


Prior to 2.2.X the ProtocolCodecFilter did not support concurrency.  Only 
SNAPSHOTS are available for 2.2.X right now.

> MINA: Exception thrown at the client side - 
> ProtocolDecoderException:BufferDataException
> 
>
> Key: DIRMINA-1153
> URL: https://issues.apache.org/jira/browse/DIRMINA-1153
> Project: MINA
>  Issue Type: Bug
>  Components: Handler
>Affects Versions: 2.0.19
>Reporter: Saravanan
>Priority: Major
>
> Mina version:
> mina-core-2.0.19.jar
> Server code snippet:
>         IoAcceptor acceptor = new NioSocketAcceptor();
>         DefaultIoFilterChainBuilder chain = acceptor.getFilterChain();
>         LoggingFilter loggingFilter = new LoggingFilter();
>         loggingFilter.setMessageSentLogLevel(LogLevel.DEBUG);
>         loggingFilter.setMessageReceivedLogLevel(LogLevel.DEBUG);
>         loggingFilter.setSessionClosedLogLevel(LogLevel.DEBUG);
>         loggingFilter.setSessionCreatedLogLevel(LogLevel.DEBUG);
>         loggingFilter.setSessionIdleLogLevel(LogLevel.DEBUG);
>         loggingFilter.setSessionOpenedLogLevel(LogLevel.DEBUG);
>         chain.addLast("logger", loggingFilter);
>         MdcInjectionFilter mdcInjectionFilter = new MdcInjectionFilter();
>         chain.addLast("mdc", mdcInjectionFilter);
>         chain.addLast("codec", new ProtocolCodecFilter(new 
> ObjectSerializationCodecFactory()));
> Client code snippet:
>         NioSocketConnector connector = new NioSocketConnector();
>         LoggingFilter LOGGING_FILTER = new LoggingFilter("MinaLogging");
>         LOGGING_FILTER.setMessageSentLogLevel(LogLevel.DEBUG);
>         LOGGING_FILTER.setMessageReceivedLogLevel(LogLevel.DEBUG);
>         
>         IoFilter CODEC_FILTER = new ProtocolCodecFilter(new 
> ObjectSerializationCodecFactory());
>         connector.getFilterChain().addLast("mdc", new MdcInjectionFilter());
>         connector.getFilterChain().addLast("codec", CODEC_FILTER);
>         connector.getFilterChain().addLast("logger", LOGGING_FILTER);
> Exception:
> org.apache.mina.filter.codec.ProtocolDecoderException: 
> org.apache.mina.core.buffer.BufferDataException: dataLength: 1048985 
> (Hexdump: XX...)
> at 
> org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:262)
>  [mina-core-2.0.19.jar:?]
> at 
> org.apache.mina.filter.codec.CumulativeProtocolDecoder.decode(CumulativeProtocolDecoder.java:180)
>  ~[mina-core-2.0.19.jar:?]
> at 
> org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:253)
>  ~[mina-core-2.0.19.jar:?]
> Points:
> - There is no synchronization while writing...
> - There are multiple threads parallely wirting into the tcp connection 
> (around 100-200)
> - The problem is observed only when the load is high...
> I have seen similar tickets here and not sure about the RCA.
> https://issues.apache.org/jira/browse/DIRMINA-653
> Need help...



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Commented] (DIRMINA-1152) IoServiceStatistics introduces huge latencies

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452440#comment-17452440
 ] 

Jonathan Valliere commented on DIRMINA-1152:


PRs are welcome

> IoServiceStatistics introduces huge latencies
> -
>
> Key: DIRMINA-1152
> URL: https://issues.apache.org/jira/browse/DIRMINA-1152
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.1.4, 2.1.5
>Reporter: Dmitrii Novikov
>Priority: Major
>
> Current implementation of IoServiceStatistics is blocking - it blocks on 
> _throughputCalculationLock_ for almost all operations
> However, _IoServiceStatistics_ is used by all threads which writes to 
> _IoSession_ and by all _NioProcessor_ threads.
> Blocking _IoServiceStatistics_ dramatically decreases performance in case of 
> multithreaded writing to {_}IoSession{_}.
> Please, refer to my 
> [benchmark|https://github.com/dmitriinovikov/apache-mina-benchmark] to ensure 
> that it is so. The measurements are taken between the time the message was 
> written to _IoSession_ by client and the time when it was actually sent to 
> the server by _NioProcessor._ Latency percentiles are calculated for all 
> messages except the first 20% - consider it as a warmup. You can read about 
> benchmark details in the README file.
>  
> My benchmark results:
> {code:java}
> # non-blocking IoServiceStatistics vs blocking IoServiceStatistics:
> p50: 85mcs vs 140mcs
> p75: 150mcs vs 400mcs
> p90: 239mcs vs 905mcs
> p95: 319mcs vs 1418mcs
> p99: 1311mcs vs 11485mcs {code}
>  
> As a simple workaround solution, I would suggest to add an option to disable 
> _IoServiceStatistics_ or replace it with custom implementation.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Commented] (DIRMINA-1144) Deadlock with SSL + Proxy

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17447708#comment-17447708
 ] 

Jonathan Valliere commented on DIRMINA-1144:


{quote}In 
[https://github.com/quickfix-j/quickfixj/blob/8bee941f9d6b8b01e5231572dad3a9be4e7ea748/quickfixj-core/src/test/java/quickfix/mina/ssl/SSLCertificateTest.java#L512]
 we now get an SSLPeerUnverifiedException which wasn't thrown before.
{quote}
I think you're trying to use a self-signed cert without overriding the 
{{{}TrustManager{}}}.  An SSL implementation should NEVER trust self-signed 
certs by default.  If you are running a server try setting {{NeedClientAuth}} 
and {{WantClientAuth}} to {{{}false{}}}.
{quote}In other tests we are expecting an Exception but there is none thrown 
anymore. E.g 
[https://github.com/quickfix-j/quickfixj/blob/8bee941f9d6b8b01e5231572dad3a9be4e7ea748/quickfixj-core/src/test/java/quickfix/mina/ssl/SSLCertificateTest.java#L365]
We are trying to get the Exception via a filter as can be seen here: 
[https://github.com/quickfix-j/quickfixj/blob/8bee941f9d6b8b01e5231572dad3a9be4e7ea748/quickfixj-core/src/test/java/quickfix/mina/ssl/SSLCertificateTest.java#L456]
This does not seem to be triggered anymore. I've noticed that the old SslFilter 
has an exceptionCaught method: 
[https://github.com/apache/mina/blob/ff39f496b746b780e4637d8e940cbfae2cdd3809/mina-core/src/main/java/org/apache/mina/filter/ssl/SslFilter.java#L577]
 but even if the new filter had no such method it shouldn't prevent exceptions 
from being propagated, right?
{quote}
SSLFilter extends IoFIlterAdapter which includes the standard exception handler 
and calls nextFilter.exceptionCaught.  I don't know why this isn't working for 
you.

Email me directly and we can schedule a time to debug on Skype.

> Deadlock with SSL + Proxy
> -
>
> Key: DIRMINA-1144
> URL: https://issues.apache.org/jira/browse/DIRMINA-1144
> Project: MINA
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 2.1.3, 2.1.4
>Reporter: Giuseppe Persico
>    Assignee: Jonathan Valliere
>Priority: Critical
> Fix For: 2.2.0
>
> Attachments: thread-dump-clean.txt
>
>
> You will find the thread dump attached. This seems to be a problem that 
> occurs using SSL in combination with proxy. I found the problem in the 2.1.4 
> and 2.1.3 versions. The 2.0.20, instead, seems to work,



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Commented] (DIRMINA-1144) Deadlock with SSL + Proxy

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445583#comment-17445583
 ] 

Jonathan Valliere commented on DIRMINA-1144:


I'm fine with this for now.  Here is the change 
[https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=f38dde9ff18843c2eaae695dc76b823637c197a8]

[~elecharny]  please update the SNAPSHOT in Maven.

> Deadlock with SSL + Proxy
> -
>
> Key: DIRMINA-1144
> URL: https://issues.apache.org/jira/browse/DIRMINA-1144
> Project: MINA
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 2.1.3, 2.1.4
>Reporter: Giuseppe Persico
>    Assignee: Jonathan Valliere
>Priority: Critical
> Fix For: 2.2.0
>
> Attachments: thread-dump-clean.txt
>
>
> You will find the thread dump attached. This seems to be a problem that 
> occurs using SSL in combination with proxy. I found the problem in the 2.1.4 
> and 2.1.3 versions. The 2.0.20, instead, seems to work,



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Commented] (DIRMINA-1144) Deadlock with SSL + Proxy

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445488#comment-17445488
 ] 

Jonathan Valliere commented on DIRMINA-1144:


I have no interest in dying on this hill.  If its a simple as removing that one 
line then I'll do it.

> Deadlock with SSL + Proxy
> -
>
> Key: DIRMINA-1144
> URL: https://issues.apache.org/jira/browse/DIRMINA-1144
> Project: MINA
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 2.1.3, 2.1.4
>Reporter: Giuseppe Persico
>    Assignee: Jonathan Valliere
>Priority: Critical
> Fix For: 2.2.0
>
> Attachments: thread-dump-clean.txt
>
>
> You will find the thread dump attached. This seems to be a problem that 
> occurs using SSL in combination with proxy. I found the problem in the 2.1.4 
> and 2.1.3 versions. The 2.0.20, instead, seems to work,



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: ByteBuffer (Was: Re: JIRA Emails)

[Jonathan Valliere]

Good job.   So yeah, back to adopting Java 11 moving forward.

On Wed, Nov 17, 2021 at 9:23 AM Thomas Wolf  wrote:

> On 17.11.21 14:37 , Jonathan Valliere wrote:
> > The error you posted was related to java.lang.NoSuchMethodError:
> > java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer; and not the SSLFilter.
> You
> > sure there wasn’t something else
> > wrong with your env cause I’m pretty sure ByteBuffer.fip() has been
> around
> > since ByteBuffer.
>
> But there was a co-variant return type override. In Java 1.8,
> ByteBuffer.flip() is inherited from Buffer and returns a Buffer.
>
> In Java > 1.8, ByteBuffer.flip() is an override returning ByteBuffer.
>
> So when you compile with Java > 1.8 w/o --release 8 and then run on Java
> 1.8, you'll get that NoSuchMethodError.
>
> Cheers,
>
>Thomas
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

Re: JIRA Emails

[Jonathan Valliere]

 @Christoph

The error you posted was related to java.lang.NoSuchMethodError:
java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer; and not the SSLFilter. You
sure there wasn’t something else
wrong with your env cause I’m pretty sure ByteBuffer.fip() has been around
since ByteBuffer.

On Nov 17, 2021 at 8:30:25 AM, Christoph John 
wrote:

> I think one is for your personal mail address, the second for the dev
> mailing list. At least that is
> the case for me.
>
> Cheers,
> Chris.
>
> On 17.11.21 14:06, Jonathan Valliere wrote:
>
> Is everyone getting the JIRA emails twice or is that just me?
>
>
>
>

JIRA Emails

[Jonathan Valliere]

Is everyone getting the JIRA emails twice or is that just me?

[jira] [Comment Edited] (DIRMINA-1144) Deadlock with SSL + Proxy

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445145#comment-17445145
 ] 

Jonathan Valliere edited comment on DIRMINA-1144 at 11/17/21, 1:04 PM:
---

There is also another feature somewhere which requires Java 9 but I don't 
remember what.  Officially deprecating Java 8 is a good idea since it's not 
really being maintained anymore.  I'm also fairly sure there is some lambda 
code somewhere which is also incompatible with Java 8.

 

P.S. [~chrjohn] 's error is with {{ByteBufer}}
{code:java}
java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer; 
{code}
{{ }}


was (Author: johnnyv):
There is also another feature somewhere which requires Java 9 but I don't 
remember what.  Officially deprecating Java 8 is a good idea since it's not 
really being maintained anymore.  I'm also fairly sure there is some lambda 
code somewhere which is also incompatible with Java 8.

> Deadlock with SSL + Proxy
> -
>
> Key: DIRMINA-1144
> URL: https://issues.apache.org/jira/browse/DIRMINA-1144
> Project: MINA
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 2.1.3, 2.1.4
>Reporter: Giuseppe Persico
>    Assignee: Jonathan Valliere
>Priority: Critical
> Fix For: 2.2.0
>
> Attachments: thread-dump-clean.txt
>
>
> You will find the thread dump attached. This seems to be a problem that 
> occurs using SSL in combination with proxy. I found the problem in the 2.1.4 
> and 2.1.3 versions. The 2.0.20, instead, seems to work,



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Commented] (DIRMINA-1144) Deadlock with SSL + Proxy

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445145#comment-17445145
 ] 

Jonathan Valliere commented on DIRMINA-1144:


There is also another feature somewhere which requires Java 9 but I don't 
remember what.  Officially deprecating Java 8 is a good idea since it's not 
really being maintained anymore.  I'm also fairly sure there is some lambda 
code somewhere which is also incompatible with Java 8.

> Deadlock with SSL + Proxy
> -
>
> Key: DIRMINA-1144
> URL: https://issues.apache.org/jira/browse/DIRMINA-1144
> Project: MINA
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 2.1.3, 2.1.4
>Reporter: Giuseppe Persico
>    Assignee: Jonathan Valliere
>Priority: Critical
> Fix For: 2.2.0
>
> Attachments: thread-dump-clean.txt
>
>
> You will find the thread dump attached. This seems to be a problem that 
> occurs using SSL in combination with proxy. I found the problem in the 2.1.4 
> and 2.1.3 versions. The 2.0.20, instead, seems to work,



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Commented] (DIRMINA-1144) Deadlock with SSL + Proxy

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443837#comment-17443837
 ] 

Jonathan Valliere commented on DIRMINA-1144:


Grab the SSLFilter.SSL_SECURED Attribute from the IoSession

> Deadlock with SSL + Proxy
> -
>
> Key: DIRMINA-1144
> URL: https://issues.apache.org/jira/browse/DIRMINA-1144
> Project: MINA
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 2.1.3, 2.1.4
>Reporter: Giuseppe Persico
>    Assignee: Jonathan Valliere
>Priority: Critical
> Fix For: 2.2.0
>
> Attachments: thread-dump-clean.txt
>
>
> You will find the thread dump attached. This seems to be a problem that 
> occurs using SSL in combination with proxy. I found the problem in the 2.1.4 
> and 2.1.3 versions. The 2.0.20, instead, seems to work,



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Commented] (DIRMINA-1144) Deadlock with SSL + Proxy

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443495#comment-17443495
 ] 

Jonathan Valliere commented on DIRMINA-1144:


[~chrjohn]  bugfix/DIRMINA1132 was [merged into the 2.2.X 
branch|https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=656426159477b4c1e6c64c80b16c7bea16bde3d6]
 please use 2.2.0-SNAPSHOT

> Deadlock with SSL + Proxy
> -
>
> Key: DIRMINA-1144
> URL: https://issues.apache.org/jira/browse/DIRMINA-1144
> Project: MINA
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 2.1.3, 2.1.4
>Reporter: Giuseppe Persico
>    Assignee: Jonathan Valliere
>Priority: Critical
> Fix For: 2.2.0
>
> Attachments: thread-dump-clean.txt
>
>
> You will find the thread dump attached. This seems to be a problem that 
> occurs using SSL in combination with proxy. I found the problem in the 2.1.4 
> and 2.1.3 versions. The 2.0.20, instead, seems to work,



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Commented] (DIRMINA-1144) Deadlock with SSL + Proxy

[Jonathan Valliere (Jira)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443493#comment-17443493
 ] 

Jonathan Valliere commented on DIRMINA-1144:


[~sebb] I think using Jenkins is a good idea but anyway for the purpose of the 
issue at hand the 2.2.0-SNAPSHOT is now up on the repo.

> Deadlock with SSL + Proxy
> -
>
> Key: DIRMINA-1144
> URL: https://issues.apache.org/jira/browse/DIRMINA-1144
> Project: MINA
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 2.1.3, 2.1.4
>Reporter: Giuseppe Persico
>    Assignee: Jonathan Valliere
>Priority: Critical
> Fix For: 2.2.0
>
> Attachments: thread-dump-clean.txt
>
>
> You will find the thread dump attached. This seems to be a problem that 
> occurs using SSL in combination with proxy. I found the problem in the 2.1.4 
> and 2.1.3 versions. The 2.0.20, instead, seems to work,



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org