[jira] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822127#comment-17822127
]
Jonathan Valliere commented on DIRMINA-1176:
How sure are you that the consumer of these messages isn’t the problem?
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
> at
> com.bmc.ctms.common.services.Service$3.handleEvent(Service.java:358)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.handleSubscriberEntryEvent(EventDispatcher.java:687)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publishByUniqeID(EventDispatcher.java:673)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publish(EventDispatcher.java:694)
> at
> com.bmc.ctms.infra.EventDispatcher.publish(EventDispatcher.java:194)
> at com.bmc.ctms.infra.EventDispatcher.publish(EventDispatcher.java:154)
> at
> com.bmc.ctms.common.Ipc2EventAdapter.handleIpcGtwMsg(Ipc2EventAdapter.java:206)
> at
>
[jira] [Resolved] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Valliere resolved DIRMINA-1176.
Resolution: Not A Problem
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
> at
> com.bmc.ctms.common.services.Service$3.handleEvent(Service.java:358)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.handleSubscriberEntryEvent(EventDispatcher.java:687)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publishByUniqeID(EventDispatcher.java:673)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.publish(EventDispatcher.java:694)
> at
> com.bmc.ctms.infra.EventDispatcher.publish(EventDispatcher.java:194)
> at com.bmc.ctms.infra.EventDispatcher.publish(EventDispatcher.java:154)
> at
> com.bmc.ctms.common.Ipc2EventAdapter.handleIpcGtwMsg(Ipc2EventAdapter.java:206)
> at
> com.bmc.ctms.common.Ipc2EventAdapter$1.handleEvent(Ipc2EventAdapter.java:41)
>
[jira] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821233#comment-17821233
]
Jonathan Valliere commented on DIRMINA-1176:
@[~eissam_yassin] this is not a bug, this is caused by your application not
performing any flow control on the messages that it is sending to the peer.
Think of it like water flowing through pipes, if you have an 8cm diameter pipe
and I have a 2cm diameter pipe the water is only going to go as fast as the 2cm
pipe will allow.
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
> at
> com.bmc.ctms.common.services.Service$3.handleEvent(Service.java:358)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.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
>
[jira] [Comment Edited] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821229#comment-17821229
]
Jonathan Valliere edited comment on DIRMINA-1176 at 2/27/24 1:16 PM:
-
[~elecharny] the hard limit was to prevent memory leaks which would normally be
handled by the max enqueued messages on the IoSession. The idea here is that
we want to perform flow control at the SSL and not waste CPU cycles encrypting
messages which will simply be queued for write because the writer speed is
exceeding the reader. A perfect example of this is: if you want to download a
5GB file, you don't encrypt the entire file then write to the socket, you grab
pieces of it.
was (Author: johnnyv):
[~elecharny] the hard limit was to prevent memory leaks which would normally be
handled by the max enqueued messages on the IoSession. The idea here is that
we want to perform flow control at the SSL and not waste CPU cycles encrypting
messages which will simply be queued for write because the writer speed is
exceeding the reader.
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
>
[jira] [Commented] (DIRMINA-1176) Buffer overflow exception when writing messages over SSL
[
https://issues.apache.org/jira/browse/DIRMINA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821229#comment-17821229
]
Jonathan Valliere commented on DIRMINA-1176:
[~elecharny] the hard limit was to prevent memory leaks which would normally be
handled by the max enqueued messages on the IoSession. The idea here is that
we want to perform flow control at the SSL and not waste CPU cycles encrypting
messages which will simply be queued for write because the writer speed is
exceeding the reader.
> Buffer overflow exception when writing messages over SSL
> -
>
> Key: DIRMINA-1176
> URL: https://issues.apache.org/jira/browse/DIRMINA-1176
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.2.1, 2.2.3
>Reporter: Eissam Yassin
>Priority: Critical
>
> Hello,
> When many messages written over SSL we get BufferOverflowException exception:
>
> {noformat}
> 0831_07:00:31.831, "Io Exception in Em<->Gw connection named 'GW'", [INFO],
> T@113, T:ctm.COMM_EM.113, , , COMM_EM,
> EmDsectProtocolIoHandlare::exceptionCaught, "java.nio.BufferOverflowException
> at
> org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:339)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> com.bmc.ctms.infra.comm.RawCommunicationLogger.filterWrite(RawCommunicationLogger.java:102)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:513)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.write(EmGwProtocolManager.java:473)
> at
> com.bmc.ctms.ctminfra.protocols.emdsect.EmGwProtocolManager.writeWithoutExceptions(EmGwProtocolManager.java:448)
> at
> com.bmc.ctms.common.services.Service.handleResponse(Service.java:245)
> at
> com.bmc.ctms.ctmce.Download$SlaveService.handleResponse(Download.java:251)
> at
> com.bmc.ctms.common.services.Service$3.handleEvent(Service.java:358)
> at
> com.bmc.ctms.infra.EventDispatcher$EventEntry.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
>
[jira] [Resolved] (DIRMINA-1132) TLSv1.3 - MINA randomly fails in reading the message sent by client
[
https://issues.apache.org/jira/browse/DIRMINA-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Valliere resolved DIRMINA-1132.
Resolution: Fixed
This was fixed as part of the SSL rewrite for 2.2
> TLSv1.3 - MINA randomly fails in reading the message sent by client
> ---
>
> Key: DIRMINA-1132
> URL: https://issues.apache.org/jira/browse/DIRMINA-1132
> Project: MINA
> Issue Type: Bug
> Components: Core, SSL
>Affects Versions: 2.0.21
> Environment: Operating System: Windows 10 1903
> Java Version: jdk-11.0.7, jdk-12.0.2
>Reporter: Venkata Kishore Tavva
>Assignee: Jonathan Valliere
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: console.log, example-project.zip, keyStore.pfx,
> trustStore.pfx
>
>
> While trying to Implement TLSv1.3 in our systems, we found an issue with Mina
> Core dependency. For TLSv1.2 we never had the issue. But with TLSv1.3,
> randomly the message sent by the client is discarded. In such scenarios, the
> server waits for session to pass idle timeout and closes the session. Please
> find the sample code below:
> {code:java}
> import org.apache.mina.core.service.IoHandlerAdapter;
> import org.apache.mina.core.session.IdleStatus;
> import org.apache.mina.core.session.IoSession;
> import org.apache.mina.filter.ssl.SslFilter;
> import org.apache.mina.transport.socket.SocketAcceptor;
> import org.apache.mina.transport.socket.nio.NioSocketAcceptor;
> import javax.net.ssl.*;
> import java.io.*;
> import java.net.InetSocketAddress;
> import java.security.KeyStore;
> public class Main {
>public static void main(String[] args) throws Exception {
> System.setProperty("javax.net.debug","all");
> KeyManagerFactory keyManagerFactory;
> try(FileInputStream fis = new FileInputStream("keyStore.pfx")) {
> keyManagerFactory =
> KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
> KeyStore keyStore = KeyStore.getInstance("PKCS12");
> keyStore.load(fis, "passphrase".toCharArray());
> keyManagerFactory.init(keyStore, "passphrase".toCharArray());
> }
> TrustManagerFactory trustManagerFactory;
> try(FileInputStream fis = new FileInputStream("trustStore.pfx")){
> trustManagerFactory = TrustManagerFactory.getInstance("SunX509");
> KeyStore trustStore = KeyStore.getInstance("PKCS12");
> trustStore.load(fis, "passphrase".toCharArray());
> trustManagerFactory.init(trustStore);
> }
> SSLContext context = SSLContext.getInstance("TLSv1.3");
> context.init(keyManagerFactory.getKeyManagers(),
> trustManagerFactory.getTrustManagers(), null);
> SslFilter filter = new SslFilter(context);
> filter.setEnabledProtocols(new String[]{"TLSv1.3"});
> filter.setEnabledCipherSuites(new String[]{"TLS_AES_128_GCM_SHA256",
> "TLS_AES_256_GCM_SHA384"});
> SocketAcceptor acceptor = new NioSocketAcceptor();
> acceptor.setReuseAddress(true);
> acceptor.getFilterChain().addLast("sslFilter", filter);
> acceptor.setHandler( new ServerHandler());
> acceptor.bind(new InetSocketAddress(53001));
> System.out.println("Server started on Port : 53001");
> System.out.println("Start sending data using cUrl below:");
> System.out.println("-> curl --location --insecure --tlsv1.3 --ipv4
> 'https://localhost:53001' --data-raw 'Sample Text'");
>}
> }
> class ServerHandler extends IoHandlerAdapter {
>@Override
>public void sessionCreated(IoSession session) {
> System.out.println( "\nSession created : " + session);
>}
>@Override
>public void sessionOpened(IoSession session) {
> System.out.println( "Session opened : " + session);
> session.getConfig().setIdleTime(IdleStatus.BOTH_IDLE, 60);
>}
>@Override
>public void sessionClosed(IoSession session) {
> System.out.println( "Session closed : " + session);
> session.closeNow();
>}
>@Override
>public void sessionIdle(IoSession session, IdleStatus status) {
> System.out.println( "==" );
> System.out.println( "Session is idle for 60 secs hence closing session:
> " + session.getRemoteAddress());
> System.out.println( "==" );
> session.closeNow();
>}
>@Override
>public void exceptionCaught(IoSession session, Throwable cause) {
> System.out.println("Exception :\n");
> cause.printStackTrace();
> session.closeNow();
>}
>@Override
>public void messageReceived(IoSession session, Object message) {
> System.out.println("Message Received!!!");
> //do further processing on @param{message}
>
[jira] [Commented] (DIRMINA-1146) TLS enabled session got disconnected when outbound messages add up to the value of maxscheduledwriterequests
[ https://issues.apache.org/jira/browse/DIRMINA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821223#comment-17821223 ] Jonathan Valliere commented on DIRMINA-1146: [~eissam_yassin] I see the attached code but do you have a runnable example which reproduces this problem? > TLS enabled session got disconnected when outbound messages add up to the > value of maxscheduledwriterequests > > > Key: DIRMINA-1146 > URL: https://issues.apache.org/jira/browse/DIRMINA-1146 > Project: MINA > Issue Type: Bug >Reporter: Chily >Assignee: Jonathan Valliere >Priority: Blocker > Fix For: 2.2.2 > > Attachments: ConnectionEndPointIoHandler.java, > EmDsectProtocolIoHandlare.java > > > Slow Consumer Protection Feature does not work on TLS enabled session > -> ioSession.getScheduledWriteMessages() never decreases in > IoSessionResponder#send method > internal.engine.session.maxscheduledwriterequests=1 > Our TLS enabled session got disconneced when the outbound messages added up > to 1. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-963) Socks5 and ProxyConnector don't work with InetSocketAddress.createUnresolved
[
https://issues.apache.org/jira/browse/DIRMINA-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815906#comment-17815906
]
Jonathan Valliere commented on DIRMINA-963:
---
I can try to look at this sometime in the next couple of weeks. However, it
clearly looks like this isn't a problem for many people given how old this
ticket is.
> Socks5 and ProxyConnector don't work with InetSocketAddress.createUnresolved
>
>
> Key: DIRMINA-963
> URL: https://issues.apache.org/jira/browse/DIRMINA-963
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.7
>Reporter: Daniele guiducci
>Assignee: Jonathan Valliere
>Priority: Major
> Labels: InetSocketAddress, bug, proxy, socks
>
> I'm tring to use Tor to connect using proxy (SOCKS5).
> InetSocketAddress resolve dns without use Tor, so i can not use in production.
> To use tor to resolve dns i must use InetSocketAddress.createUnresolved.
> java.net.Socket work perfectly also with .onion url.
> {code}
> public static void main(String[] args) throws Exception{
> NioSocketConnector nioConnector=new NioSocketConnector();
> nioConnector.setConnectTimeoutMillis(6);
> SocksProxyRequest pr = new SocksProxyRequest(
> SocksProxyConstants.SOCKS_VERSION_5,
> SocksProxyConstants.ESTABLISH_TCPIP_STREAM,
> new InetSocketAddress("www.google.com", 80), "");
> ProxyIoSession ps=new ProxyIoSession(new
> InetSocketAddress("127.0.0.1", 9050), pr);
> ProxyConnector connector=new ProxyConnector(nioConnector);
> connector.getFilterChain().addLast("logger", new LoggingFilter());
> connector.setProxyIoSession(ps);
> connector.setHandler(new MyHandler());
> ConnectFuture cf=connector.connect();
> IoSession session=cf.getSession();
> session.getCloseFuture().awaitUninterruptibly();
> cf.awaitUninterruptibly();
>Thread.sleep(4);
> }
> private static class MyHandler extends AbstractProxyIoHandler {
> @Override
> public void proxySessionOpened(IoSession session) {
> System.out.println("ProxySession aperta");
> session.write(IoBuffer.wrap("GET / HTTP/1.0\n\n".getBytes()));
> }
> @Override
> public void messageReceived(IoSession session, Object msg) {
> System.out.println("Data:"+new String(((IoBuffer)msg).array()));
> }
> @Override
> public void exceptionCaught(IoSession session, Throwable cause)
> throws Exception {
> System.out.println("Error: "+cause);
> }
> }
> {code}
> ===
> {code}
> public static void main(String[] args) throws Exception{
> NioSocketConnector nioConnector=new NioSocketConnector();
> nioConnector.setConnectTimeoutMillis(6);
> SocksProxyRequest pr = new SocksProxyRequest(
> SocksProxyConstants.SOCKS_VERSION_5,
> SocksProxyConstants.ESTABLISH_TCPIP_STREAM,
> InetSocketAddress.createUnresolved("www.google.com", 80),
> "");
> ProxyIoSession ps=new ProxyIoSession(new
> InetSocketAddress("127.0.0.1", 9050), pr);
> ProxyConnector connector=new ProxyConnector(nioConnector);
> connector.getFilterChain().addLast("logger", new LoggingFilter());
> connector.setProxyIoSession(ps);
> connector.setHandler(new MyHandler());
> ConnectFuture cf=connector.connect();
> IoSession session=cf.getSession();
> session.getCloseFuture().awaitUninterruptibly();
> cf.awaitUninterruptibly();
>Thread.sleep(4);
> }
> private static class MyHandler extends AbstractProxyIoHandler {
> @Override
> public void proxySessionOpened(IoSession session) {
> System.out.println("ProxySession aperta");
> session.write(IoBuffer.wrap("GET / HTTP/1.0\n\n".getBytes()));
> }
> @Override
> public void messageReceived(IoSession session, Object msg) {
> System.out.println("Data:"+new String(((IoBuffer)msg).array()));
> }
> @Override
> public void exceptionCaught(IoSession session, Throwable cause)
> throws Exception {
> System.out.println("Error: "+cause);
> }
> }
> {code}
> =
> java.net.Socket example working with tor.
> {code}
> Socket socket=new Socket(new Proxy(Proxy.Type.SOCKS,new
> InetSocketAddress("127.0.0.1", 9050)));
> System.out.println("Tryng connect ");
>
> socket.connect(InetSocketAddress.createUnresolved("kpvz7ki2v5agwT35.onion",
> 80),20);
>
[jira] [Commented] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
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())
> {
>
> if (handleIOException(searchExpression, captureHandler)) {
> return;
> }
> LOG.info("{} Apache mina connection setup time out
> happend.",
> handleConnectionFailed(primaryAddress, captureHandler,
> "Primary IP connection timeout");
>
[jira] [Commented] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
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, captureHandler)) {
> return;
> }
> LOG.info("{} Apache mina connection setup time out
> happend.",
> handleConnectionFailed(primaryAddress, captureHandler,
> "Primary IP connection timeout");
> return;
> }
> }catch(Exception e)
> {
> }finally
> {
>
[jira] [Resolved] (DIRMINA-1170) Will Apache MINA 2.1 and Apache MINA 2.2 evolve in dual branches?
[ 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?
[ 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
[jira] [Commented] (DIRMINA-1161) Accessing the session buffer of multiple decoders
[
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
[
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
[jira] [Commented] (DIRMINA-1157) Sporadic error when establishing a StartTLS or SSL connection
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[jira] [Resolved] (DIRMINA-1153) MINA: Exception thrown at the client side - ProtocolDecoderException:BufferDataException
[
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
[
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
[
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
[
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
[ 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
[ 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
[jira] [Comment Edited] (DIRMINA-1144) Deadlock with SSL + Proxy
[
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
[ 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
[ 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
[ 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
[ 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
[jira] [Commented] (DIRMINA-1144) Deadlock with SSL + Proxy
[ https://issues.apache.org/jira/browse/DIRMINA-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443309#comment-17443309 ] Jonathan Valliere commented on DIRMINA-1144: Okay are there instructions somewhere where I can setup my credentials so I can do that in the future? On Sun, Nov 14, 2021 at 2:33 AM Emmanuel Lécharny (Jira) 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. > 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-1151) SSLException "Outbound done" happens occasionally on the client side
[
https://issues.apache.org/jira/browse/DIRMINA-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17436788#comment-17436788
]
Jonathan Valliere commented on DIRMINA-1151:
It's supposed to be caused by trying to write to the SSL after it was closed,
however the lifecycle of SSL in 2.1.4 was buggy which is one of the reasons it
was totally rewritten for 2.2.0.
> SSLException "Outbound done" happens occasionally on the client side
>
>
> Key: DIRMINA-1151
> URL: https://issues.apache.org/jira/browse/DIRMINA-1151
> Project: MINA
> Issue Type: Bug
> Components: Core, SSL
>Affects Versions: 2.1.4
>Reporter: Eliran
>Priority: Major
>
> We use Mina-core-2.1.4 on both client and server with Java 11.
> Occasionally (every several hours) we get on the client this "Outbound done"
> exception:
> {code}
> 28-10-2021 11:27:51.486 ERROR pool-2-thread-12
> SendClientSessionHandler.exceptionCaught(82) - Exception caught
> javax.net.ssl.SSLException: Outbound done
> at
> org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:513)
> ~[mina-core-2.1.4.jar:?]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
> ~[mina-core-2.1.4.jar:?]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
> ~[mina-core-2.1.4.jar:?]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
> ~[mina-core-2.1.4.jar:?]
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
> ~[mina-core-2.1.4.jar:?]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
> ~[mina-core-2.1.4.jar:?]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:643)
> ~[mina-core-2.1.4.jar:?]
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
> ~[mina-core-2.1.4.jar:?]
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
> ~[mina-core-2.1.4.jar:?]
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1224)
> ~[mina-core-2.1.4.jar:?]
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1213)
> ~[mina-core-2.1.4.jar:?]
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
> ~[mina-core-2.1.4.jar:?]
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> ~[mina-core-2.1.4.jar:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> ~[?:?]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> ~[?:?]
> at java.lang.Thread.run(Unknown Source) [?:?]
> {code}
> I tried to google it, but I couldn't understand why it happens.
> Can you please explain why it happens?
> I also tried to debug it, but it doesn't reproduce on my dev environment
> (only on QA lab)
> Just want to note that I don't see any functionally impact of this exception.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1150) Server is getting "stuck" when using mina-core-2.1.5-SNAPSHOT with SSL2Filter
[ https://issues.apache.org/jira/browse/DIRMINA-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17433274#comment-17433274 ] Jonathan Valliere commented on DIRMINA-1150: What do you mean by wrong jar? > Server is getting "stuck" when using mina-core-2.1.5-SNAPSHOT with SSL2Filter > - > > Key: DIRMINA-1150 > URL: https://issues.apache.org/jira/browse/DIRMINA-1150 > Project: MINA > Issue Type: Bug > Components: Filter, SSL >Affects Versions: 2.1.4 >Reporter: Eliran >Assignee: Jonathan Valliere >Priority: Critical > Attachments: mina-core-2.1.5-SNAPSHOT-working.jar, > thread_dump_server.txt > > > This is a bug is resulted from > https://issues.apache.org/jira/browse/DIRMINA-1145 > Please see attached mina-core-2.1.5-SNAPSHOT-working.jar (copied from > DIRMINA-1145) > This jar also includes SSL2Filter to fix DIRMINA-1145. > The issue is that when using this jar, it fixes DIRMINA-1145, but the server > gets "stuck" i.e not responding to anything (open connections, sent messages) > This happens from time to time usually after the server is running for an > hour or so, but it happened once only after a few minutes. > Sometimes I waited for 2 hours and it didn't reproduced, so it is hard to > know why it happens. > Attached the thread dump "thread_dump_server.txt" when it happened. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (DIRMINA-1150) Server is getting "stuck" when using mina-core-2.1.5-SNAPSHOT with SSL2Filter
[ https://issues.apache.org/jira/browse/DIRMINA-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Valliere reassigned DIRMINA-1150: -- Assignee: Jonathan Valliere > Server is getting "stuck" when using mina-core-2.1.5-SNAPSHOT with SSL2Filter > - > > Key: DIRMINA-1150 > URL: https://issues.apache.org/jira/browse/DIRMINA-1150 > Project: MINA > Issue Type: Bug > Components: Filter, SSL >Affects Versions: 2.1.4 >Reporter: Eliran >Assignee: Jonathan Valliere >Priority: Critical > Attachments: mina-core-2.1.5-SNAPSHOT-working.jar, > thread_dump_server.txt > > > This is a bug is resulted from > https://issues.apache.org/jira/browse/DIRMINA-1145 > Please see attached mina-core-2.1.5-SNAPSHOT-working.jar (copied from > DIRMINA-1145) > This jar also includes SSL2Filter to fix DIRMINA-1145. > The issue is that when using this jar, it fixes DIRMINA-1145, but the server > gets "stuck" i.e not responding to anything (open connections, sent messages) > This happens from time to time usually after the server is running for an > hour or so, but it happened once only after a few minutes. > Sometimes I waited for 2 hours and it didn't reproduced, so it is hard to > know why it happens. > Attached the thread dump "thread_dump_server.txt" when it happened. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (DIRMINA-1150) Server is getting "stuck" when using mina-core-2.1.5-SNAPSHOT with SSL2Filter
[ https://issues.apache.org/jira/browse/DIRMINA-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17432409#comment-17432409 ] Jonathan Valliere edited comment on DIRMINA-1150 at 10/21/21, 11:45 AM: Can you get me a thread dump after about 5 minutes of the server running. I don't see any deadlocks in the attached dump but would like to compare against what it looks like when it is working as expected. I would also like to confirm that TCP sockets cannot be opened when this happens. Next time it happens please grab me a wireshark capture while you're trying to connect to the server. There is an issue I discovered here https://issues.apache.org/jira/browse/DIRMINA-1147 but I haven't seen it cause stalls. was (Author: johnnyv): Can you get me a thread dump after about 5 minutes of the server running. I don't see any deadlocks in the attached dump but would like to compare against what it looks like when it is working as expected. I would also like to confirm that TCP sockets cannot be opened when this happens. There is an issue I discovered here https://issues.apache.org/jira/browse/DIRMINA-1147 but I haven't seen it cause stalls. > Server is getting "stuck" when using mina-core-2.1.5-SNAPSHOT with SSL2Filter > - > > Key: DIRMINA-1150 > URL: https://issues.apache.org/jira/browse/DIRMINA-1150 > Project: MINA > Issue Type: Bug > Components: Filter, SSL >Affects Versions: 2.1.4 >Reporter: Eliran >Priority: Critical > Attachments: mina-core-2.1.5-SNAPSHOT-working.jar, > thread_dump_server.txt > > > This is a bug is resulted from > https://issues.apache.org/jira/browse/DIRMINA-1145 > Please see attached mina-core-2.1.5-SNAPSHOT-working.jar (copied from > DIRMINA-1145) > This jar also includes SSL2Filter to fix DIRMINA-1145. > The issue is that when using this jar, it fixes DIRMINA-1145, but the server > gets "stuck" i.e not responding to anything (open connections, sent messages) > This happens from time to time usually after the server is running for an > hour or so, but it happened once only after a few minutes. > Sometimes I waited for 2 hours and it didn't reproduced, so it is hard to > know why it happens. > Attached the thread dump "thread_dump_server.txt" when it happened. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1150) Server is getting "stuck" when using mina-core-2.1.5-SNAPSHOT with SSL2Filter
[ https://issues.apache.org/jira/browse/DIRMINA-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17432409#comment-17432409 ] Jonathan Valliere commented on DIRMINA-1150: Can you get me a thread dump after about 5 minutes of the server running. I don't see any deadlocks in the attached dump but would like to compare against what it looks like when it is working as expected. I would also like to confirm that TCP sockets cannot be opened when this happens. There is an issue I discovered here https://issues.apache.org/jira/browse/DIRMINA-1147 but I haven't seen it cause stalls. > Server is getting "stuck" when using mina-core-2.1.5-SNAPSHOT with SSL2Filter > - > > Key: DIRMINA-1150 > URL: https://issues.apache.org/jira/browse/DIRMINA-1150 > Project: MINA > Issue Type: Bug > Components: Filter, SSL >Affects Versions: 2.1.4 >Reporter: Eliran >Priority: Critical > Attachments: mina-core-2.1.5-SNAPSHOT-working.jar, > thread_dump_server.txt > > > This is a bug is resulted from > https://issues.apache.org/jira/browse/DIRMINA-1145 > Please see attached mina-core-2.1.5-SNAPSHOT-working.jar (copied from > DIRMINA-1145) > This jar also includes SSL2Filter to fix DIRMINA-1145. > The issue is that when using this jar, it fixes DIRMINA-1145, but the server > gets "stuck" i.e not responding to anything (open connections, sent messages) > This happens from time to time usually after the server is running for an > hour or so, but it happened once only after a few minutes. > Sometimes I waited for 2 hours and it didn't reproduced, so it is hard to > know why it happens. > Attached the thread dump "thread_dump_server.txt" when it happened. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427877#comment-17427877 ] Jonathan Valliere commented on DIRMINA-1145: It says "Affects Version 2.1.4, Fix Version 2.2.0" means it is fixed in 2.2.0 (Unreleased) The 2.2.X branch in GIT contains the HEAD of the 2.2.0. > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.1.5-SNAPSHOT-working.jar, > mina-core-2.2.0-SNAPSHOT.jar, mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427827#comment-17427827 ] Jonathan Valliere edited comment on DIRMINA-1145 at 10/12/21, 5:58 PM: --- Yes, the new SSLFilter (SSL2Filter) is only 2.2+ There are a number of issues in the 2.2 sprint (in JIRA) and anything you could do to help us test and complete issues will get us closer to an official 2.2 release. https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=321=planning.nodetail=100 was (Author: jon.valli...@emoten.com): Yes, the new SSLFilter (SSL2Filter) is only 2.2+ There are a number of issues in the 2.2 sprint (in JIRA) and anything you could do to help us test and complete issues will get us closer to an official 2.2 release. > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.1.5-SNAPSHOT-working.jar, > mina-core-2.2.0-SNAPSHOT.jar, mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427827#comment-17427827 ] Jonathan Valliere edited comment on DIRMINA-1145 at 10/12/21, 5:57 PM: --- Yes, the new SSLFilter (SSL2Filter) is only 2.2+ There are a number of issues in the 2.2 sprint (in JIRA) and anything you could do to help us test and complete issues will get us closer to an official 2.2 release. was (Author: jon.valli...@emoten.com): Yes, the new SSLFilter (SSL2Filter) is only 2.2+ There are a number of issues in the 2.2 sprint (in JIRA) and anything you could do to help us test and complete issues will get us closer to an official 2.2 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. > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.1.5-SNAPSHOT-working.jar, > mina-core-2.2.0-SNAPSHOT.jar, mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427827#comment-17427827 ] Jonathan Valliere commented on DIRMINA-1145: Yes, the new SSLFilter (SSL2Filter) is only 2.2+ There are a number of issues in the 2.2 sprint (in JIRA) and anything you could do to help us test and complete issues will get us closer to an official 2.2 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. > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.1.5-SNAPSHOT-working.jar, > mina-core-2.2.0-SNAPSHOT.jar, mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427650#comment-17427650 ] Jonathan Valliere commented on DIRMINA-1145: [~Eliran1] MINA 2.1.5 is being released very soon. MINA 2.2 still has a few significant QOS issues which need to be addressed and I'm the only one currently available to contribute (and not that much time per week) SSL2Filter automatically detects whether the IoSession is a client or server. > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.1.5-SNAPSHOT-working.jar, > mina-core-2.2.0-SNAPSHOT.jar, mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1133) Add Pretty HexDumps to IoBuffer
[ https://issues.apache.org/jira/browse/DIRMINA-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Valliere updated DIRMINA-1133: --- Fix Version/s: (was: 2.1.4) 2.1.5 > Add Pretty HexDumps to IoBuffer > --- > > Key: DIRMINA-1133 > URL: https://issues.apache.org/jira/browse/DIRMINA-1133 > Project: MINA > Issue Type: Improvement > Components: Core >Affects Versions: 2.1.4 >Reporter: Jonathan Valliere >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.1.5 > > > Add pretty-style hex dumps to IoBuffer for printing multi-line dumps with > line numbers, columns, and ASCII representation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1118) NPE in SslHandler.checkStatus
[
https://issues.apache.org/jira/browse/DIRMINA-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Valliere updated DIRMINA-1118:
---
Sprint: (was: Mina Sprint 2.2.0)
> NPE in SslHandler.checkStatus
> -
>
> Key: DIRMINA-1118
> URL: https://issues.apache.org/jira/browse/DIRMINA-1118
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.1.3
>Reporter: Christoph John
>Assignee: Jonathan Valliere
>Priority: Major
> Fix For: 2.1.4
>
>
> Since some days we receive this NPE on our build server when running tests.
> Interestingly this occurs since OpenJDK has been switched from 8.192 to
> 8.222. However, it is probably just coincidence.
> {code}
> <20190810-14:45:11, FIX.4.4:ALFA0->ZULU0, error>
> (java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.mina.filter.ssl.SslHandler.checkStatus(SslHandler.java:539)
> at
> org.apache.mina.filter.ssl.SslHandler.messageReceived(SslHandler.java:374)
> at
> org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:517)
> 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.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
> org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1222)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1211)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> https://github.com/apache/mina/blame/2.1.X/mina-core/src/main/java/org/apache/mina/filter/ssl/SslHandler.java#L539
> IMHO when polling a queue then NULL can also be returned.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1118) NPE in SslHandler.checkStatus
[
https://issues.apache.org/jira/browse/DIRMINA-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Valliere updated DIRMINA-1118:
---
Fix Version/s: (was: 2.1.4)
2.2.0
> NPE in SslHandler.checkStatus
> -
>
> Key: DIRMINA-1118
> URL: https://issues.apache.org/jira/browse/DIRMINA-1118
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.1.3
>Reporter: Christoph John
>Assignee: Jonathan Valliere
>Priority: Major
> Fix For: 2.2.0
>
>
> Since some days we receive this NPE on our build server when running tests.
> Interestingly this occurs since OpenJDK has been switched from 8.192 to
> 8.222. However, it is probably just coincidence.
> {code}
> <20190810-14:45:11, FIX.4.4:ALFA0->ZULU0, error>
> (java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.mina.filter.ssl.SslHandler.checkStatus(SslHandler.java:539)
> at
> org.apache.mina.filter.ssl.SslHandler.messageReceived(SslHandler.java:374)
> at
> org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:517)
> 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.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
> org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1222)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1211)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> https://github.com/apache/mina/blame/2.1.X/mina-core/src/main/java/org/apache/mina/filter/ssl/SslHandler.java#L539
> IMHO when polling a queue then NULL can also be returned.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1113) Random failure on PriorityThreadPoolExecutorTest.testPrioritisation
[
https://issues.apache.org/jira/browse/DIRMINA-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Valliere updated DIRMINA-1113:
---
Sprint: (was: )
> Random failure on PriorityThreadPoolExecutorTest.testPrioritisation
> ---
>
> Key: DIRMINA-1113
> URL: https://issues.apache.org/jira/browse/DIRMINA-1113
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.22, 2.1.2
>Reporter: Emmanuel Lécharny
>Priority: Major
> Attachments: PriorityThreadPoolExecutor-failure.diff
>
>
> We have random failure when running {{mvn clean install}} :
> {noformat}
> ...
> [ERROR] Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 38.815 s <<< FAILURE! - in
> org.apache.mina.filter.executor.PriorityThreadPoolExecutorTest
> [ERROR]
> testPrioritisation(org.apache.mina.filter.executor.PriorityThreadPoolExecutorTest)
> Time elapsed: 38.815 s <<< FAILURE!
> java.lang.AssertionError: All other sessions should have finished later than
> the preferred session (but at least one did not).
> at
> org.apache.mina.filter.executor.PriorityThreadPoolExecutorTest.testPrioritisation(PriorityThreadPoolExecutorTest.java:214)
> [INFO] Running org.apache.mina.filter.keepalive.KeepAliveFilterTest
> [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.02
> s - in org.apache.mina.filter.keepalive.KeepAliveFilterTest
> [INFO] Running org.apache.mina.filter.logging.MdcInjectionFilterTest
> [INFO] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.118
> s - in org.apache.mina.filter.logging.MdcInjectionFilterTest
> [INFO] Running org.apache.mina.filter.buffer.BufferedWriteFilterTest
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002
> s - in org.apache.mina.filter.buffer.BufferedWriteFilterTest
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] PriorityThreadPoolExecutorTest.testPrioritisation:214 All other
> sessions should have finished later than the preferred session (but at least
> one did not).
> [INFO]
> [ERROR] Tests run: 214, Failures: 1, Errors: 0, Skipped: 8
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-723) OrderedThreadPoolExecutor behavior: configurable queue size, corePoolSize, maximumPoolSize
[ https://issues.apache.org/jira/browse/DIRMINA-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Valliere updated DIRMINA-723: -- Sprint: (was: ) > OrderedThreadPoolExecutor behavior: configurable queue size, corePoolSize, > maximumPoolSize > -- > > Key: DIRMINA-723 > URL: https://issues.apache.org/jira/browse/DIRMINA-723 > Project: MINA > Issue Type: Improvement > Components: Core >Affects Versions: 2.0.0-M6 > Environment: Ubuntu Linux, kernel 2.6.x >Reporter: Victor N >Priority: Minor > > The problem was discussed with Emmanuel Lecharny in mail lists: > http://www.nabble.com/OrderedThreadPoolExecutor%3A-limited-workQueue-td24275973.html > If you compare OrderedThreadPoolExecutor and standard ThreadPoolExecutor, you > can see that ThreadPoolExecutor has useful params: > - core pool size > - maximum pool size > - work queue size > If you use unbounded thread pools and queues with mina Acceptor or Connector, > you may get OutOfMemoryError under critical load because Java creates too > many threads. > With ThreadPoolExecutor you may limit the number of threads (maximumPoolSize) > and use a bounded queue (ex. LinkedBlockingQueue of limited capacity). > Unfortunately, this does not work with OrderedThreadPoolExecutor -both > "waitingSessions" and "sessionTasksQueue" do not allow to configure their > size nor pass a different queue implementation. > Even though OrderedThreadPoolExecutor extends ThreadPoolExecutor, it > overrides the behavior significantly - seems that its meaning of > "corePoolSize" and "maximumPoolSize" is different. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1118) NPE in SslHandler.checkStatus
[
https://issues.apache.org/jira/browse/DIRMINA-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Valliere updated DIRMINA-1118:
---
Fix Version/s: (was: 2.2.0)
2.1.4
> NPE in SslHandler.checkStatus
> -
>
> Key: DIRMINA-1118
> URL: https://issues.apache.org/jira/browse/DIRMINA-1118
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.1.3
>Reporter: Christoph John
>Assignee: Jonathan Valliere
>Priority: Major
> Fix For: 2.1.4
>
>
> Since some days we receive this NPE on our build server when running tests.
> Interestingly this occurs since OpenJDK has been switched from 8.192 to
> 8.222. However, it is probably just coincidence.
> {code}
> <20190810-14:45:11, FIX.4.4:ALFA0->ZULU0, error>
> (java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.mina.filter.ssl.SslHandler.checkStatus(SslHandler.java:539)
> at
> org.apache.mina.filter.ssl.SslHandler.messageReceived(SslHandler.java:374)
> at
> org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:517)
> 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.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
> org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1222)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1211)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> https://github.com/apache/mina/blame/2.1.X/mina-core/src/main/java/org/apache/mina/filter/ssl/SslHandler.java#L539
> IMHO when polling a queue then NULL can also be returned.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1110) Ordered Executors concurrency
[
https://issues.apache.org/jira/browse/DIRMINA-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Valliere updated DIRMINA-1110:
---
Sprint: (was: )
> Ordered Executors concurrency
> -
>
> Key: DIRMINA-1110
> URL: https://issues.apache.org/jira/browse/DIRMINA-1110
> Project: MINA
> Issue Type: Improvement
>Affects Versions: 2.1.2
>Reporter: Guus der Kinderen
>Priority: Major
> Attachments: mina-ordered-executors.patch
>
>
> MINA contains two ThreadPoolExecutor implementations that maintains the order
> of IoEvents per session:
> * OrderedThreadPoolExecutor
> * PriorityThreadPoolExecutor
> This issue applies to both.
> A private class called {{SessionTasksQueue}} (confusingly using different
> names in both implementations, which is an undesired side-effect having code
> duplication) is used to represent the ordered collection of events to be
> processed for each individual session. It also contains a boolean that
> represents the state of the queue prior to addition of the task: 'true' if
> the collection was empty ("processing complete"), otherwise 'false'. This
> queue is stored as an attribute on the session.
> An {{IoEvent}} is _scheduled_ for execution by being passed to the
> {{execute}} method. "Scheduling" an {{IoEvent}} involves identifying the
> session that it belongs to, and placing it in its SessionTaskQueue. Finally,
> the session itself is, conditionally (more in this later), placed in a queue
> named {{waitingSessions}}.
> The {{IoEvent}} execution itself is implemented by {{Runnable}}
> implementations called {{Worker}}. These workers take their workload from the
> {{waitingSessions}} queue, doing blocking polls.
> The placing of the Session on the {{waitingSessions}} queue depends on the
> state of the {{SessionTasksQueue}}. If it was empty ("processingComplete"),
> the session is placed on the {{waitingSessions}} queue. There is comment that
> describes this as follows:
> {quote}As the tasksQueue was empty, the task has been executed immediately,
> so we can move the session to the queue of sessions waiting for
> completion.{quote}
> As an aside: I believe this comment to be misleading: there's no guarantee
> that the task has actually been executed immediately, as workers might still
> be working on other threads. On top of that, as both the production on, and
> consumption of that queue is guarded by the same mutex, I think it's quite
> impossible that the task has already been executed. A more proper comment
> would be:
> {quote}Processing of the tasks queue of this session is currently not
> scheduled or underway. As new tasks have now been added, the session needs to
> be offered for processing.{quote}
> The determination if the session needs to be offered up for processing is
> based on an evaluation of the state of the {{sessionTasksQueue}} that happens
> under a mutex. The actual offer of the session for processing (adding the
> session to the {{waitingSessions}} queue, is not. We believe, but have not
> been able to conclusively prove, that this can lead to concurrency issues,
> where a session might not be queued, even though it has tasks to be executed.
> Nonetheless, we suggest moving the addition of the session to
> {{waitingSessions}} into the guarded code block. At the very least, this
> reduces code complexity.
> The patch attached to this issue applies this change. It also changes the
> name of the Session tasks queue in {{PriorityThreadPoolExecutor}}, to match
> the name used in {{OrderedThreadPoolExecutor}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1109) Improve PriorityThreadPoolExecutor unit test
[ https://issues.apache.org/jira/browse/DIRMINA-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Valliere updated DIRMINA-1109: --- Sprint: (was: ) > Improve PriorityThreadPoolExecutor unit test > > > Key: DIRMINA-1109 > URL: https://issues.apache.org/jira/browse/DIRMINA-1109 > Project: MINA > Issue Type: Improvement >Reporter: Guus der Kinderen >Priority: Major > Attachments: PriorityThreadPoolExecutorTest.java > > > The original test was authored by me. > The test should be improved to: > * include a non-single-thread executor thread pool. > * take into account that once a task queue for a session has already been > picked up by a worker thread, any 'prioritized' session tasks will still have > to wait for the work that's already underway to be finished (the original > code does not allow for this, hence it only works with a single thread). > * should take considerably less time to execute (currently runs for ~34 > seconds - see DIRMINA-1108) > * be self-validating. > Also, much of the formatting appears to have been lost when my original code > was merged. That could be improved upon too. > As the formatting changes changed ~80% of all lines, I've not bothered to > create a diff of my work. Instead, I'm supplying the java file in its > entirety in an attachment to this JIRA issue. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1108) ThreadPoolExecutors should terminate faster
[
https://issues.apache.org/jira/browse/DIRMINA-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Valliere updated DIRMINA-1108:
---
Sprint: (was: )
> ThreadPoolExecutors should terminate faster
> ---
>
> Key: DIRMINA-1108
> URL: https://issues.apache.org/jira/browse/DIRMINA-1108
> Project: MINA
> Issue Type: Improvement
>Affects Versions: 2.1.2
>Reporter: Guus der Kinderen
>Priority: Minor
>
> I've observed that the termination of
> {{org.apache.mina.filter.executor.PriorityThreadPoolExecutor}} takes another
> 30 seconds after the last task was executed. More specifically, it takes 30
> seconds "to long" before
> {{org.apache.mina.filter.executor.PriorityThreadPoolExecutor#awaitTermination}}
> returns {{true}}.
> It is likely that this issue also applies to
> {{org.apache.mina.filter.executor.OrderedThreadPoolExecutor}}, and maybe
> {{org.apache.mina.filter.executor.UnorderedThreadPoolExecutor}}, as a lot of
> code is shared between these implementations. I did not explicitly verify
> these implementations though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1149) IoSession.write under multi-thread enviroment, lose message order
[
https://issues.apache.org/jira/browse/DIRMINA-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17417150#comment-17417150
]
Jonathan Valliere commented on DIRMINA-1149:
The 2.2.X branch is thread-safe.
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.
> IoSession.write under multi-thread enviroment, lose message order
> -
>
> Key: DIRMINA-1149
> URL: https://issues.apache.org/jira/browse/DIRMINA-1149
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.21
> Environment: Java 1.8
> Windows 10
>Reporter: Zhang Hua
>Priority: Minor
> Attachments: minatest.zip
>
>
> I am writing a stress-test that tests multi-thread safetyness of
> IoSession.write method, and find lose message order.
> My test method is as follows
> 1. The client test code starts 50 threads, sharing the same IoSession object
> 2. Each test thread simulates a user and sends data in sequence
> I believe that the IoFilter I use meets the thread safety conditions
> The result I expect is that the server receives the data of each user in an
> orderly manner, but not
> Synchronizing on the session.write makes the problem go away;
> Do I really have to synchronize on the session to solve this issue?
>
> ClientDemo.java
> {code:java}
> public class ClientDemo {
> public static void main(String[] args) throws Exception {
> NioSocketConnector connector = new NioSocketConnector();
> DefaultIoFilterChainBuilder chain = connector.getFilterChain();
> chain.addLast("mdc", new MdcInjectionFilter());
> chain.addLast("codec", new ProtocolCodecFilter(new
> MessagePackCodecFactory()));
> TcpRPCHandler responseHandler = new TcpRPCHandler();
> connector.setHandler(responseHandler);
> connector.setConnectTimeoutCheckInterval(30);
> ConnectFuture cf = connector.connect(new
> InetSocketAddress("127.0.0.1", ));
> IoSession session = cf.awaitUninterruptibly().getSession();
> ExecutorService executor = Executors.newFixedThreadPool(50);
> for (int i = 0; i < 50; ++i) {
> executor.execute(new SenderWorker(i, session));
> }
> while (true) {
> Thread.sleep(5000);
> System.out.println("client alive..");
> //responseHandler.printProgress();
> }}
> }
> class SenderWorker implements Runnable {
> private int userId;
> private IoSession session;public SenderWorker(int userId, IoSession
> session) {
> this.userId = userId;
> this.session = session;
> }@Override
> public void run() {
> for (int i = 0; i < 100; ++i) {
> MessageData data = new MessageData(userId, i);
> /*synchronized (session)*/ {
> session.write(data);
> }
> if (i % 5 == 0) {
> try {
> Thread.sleep(10);
> } catch (Exception e) {
> }
> }
> }
> }
> }
> {code}
> See the attachment for the complete code, I use maven to manage the project
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1149) IoSession.write under multi-thread enviroment, lose message order
[
https://issues.apache.org/jira/browse/DIRMINA-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416448#comment-17416448
]
Jonathan Valliere commented on DIRMINA-1149:
Here is the example
{code:java}
import java.util.ArrayDeque;
import java.util.Queue;
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.ConcurrentLinkedDeque;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
public class Main
{
public static void main(String[] args)
{
final Queue result = new ConcurrentLinkedDeque<>();
final ExecutorService ex = new ThreadPoolExecutor(50, 50, 5,
TimeUnit.SECONDS, new ArrayBlockingQueue<>(100));
final Queue tasks = new ArrayDeque<>();
for (int i = 0; i < 50; i++)
{
tasks.add(new Task(result, i));
}
while (tasks.isEmpty() == false)
{
ex.execute(tasks.poll());
}
while (result.size() != 50)
{
try
{
Thread.sleep(5);
}
catch (InterruptedException e)
{
}
}
System.out.println(result.toString());
}
static class Task implements Runnable
{
final Queue t;
final Numberx;
public Task(Queue t, int num)
{
this.x = num;
this.t = t;
}
@Override
public void run()
{
this.t.add(this.x);
}
}
}
{code}
The output was
{code:java}
[0, 3, 2, 1, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21,
22, 23, 24, 25, 26, 27, 29, 28, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41,
42, 43, 44, 45, 46, 47, 48, 49]
{code}
> IoSession.write under multi-thread enviroment, lose message order
> -
>
> Key: DIRMINA-1149
> URL: https://issues.apache.org/jira/browse/DIRMINA-1149
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.21
> Environment: Java 1.8
> Windows 10
>Reporter: Zhang Hua
>Priority: Minor
> Attachments: minatest.zip
>
>
> I am writing a stress-test that tests multi-thread safetyness of
> IoSession.write method, and find lose message order.
> My test method is as follows
> 1. The client test code starts 50 threads, sharing the same IoSession object
> 2. Each test thread simulates a user and sends data in sequence
> I believe that the IoFilter I use meets the thread safety conditions
> The result I expect is that the server receives the data of each user in an
> orderly manner, but not
> Synchronizing on the session.write makes the problem go away;
> Do I really have to synchronize on the session to solve this issue?
>
> ClientDemo.java
> {code:java}
> public class ClientDemo {
> public static void main(String[] args) throws Exception {
> NioSocketConnector connector = new NioSocketConnector();
> DefaultIoFilterChainBuilder chain = connector.getFilterChain();
> chain.addLast("mdc", new MdcInjectionFilter());
> chain.addLast("codec", new ProtocolCodecFilter(new
> MessagePackCodecFactory()));
> TcpRPCHandler responseHandler = new TcpRPCHandler();
> connector.setHandler(responseHandler);
> connector.setConnectTimeoutCheckInterval(30);
> ConnectFuture cf = connector.connect(new
> InetSocketAddress("127.0.0.1", ));
> IoSession session = cf.awaitUninterruptibly().getSession();
> ExecutorService executor = Executors.newFixedThreadPool(50);
> for (int i = 0; i < 50; ++i) {
> executor.execute(new SenderWorker(i, session));
> }
> while (true) {
> Thread.sleep(5000);
> System.out.println("client alive..");
> //responseHandler.printProgress();
> }}
> }
> class SenderWorker implements Runnable {
> private int userId;
> private IoSession session;public SenderWorker(int userId, IoSession
> session) {
> this.userId = userId;
> this.session = session;
> }@Override
> public void run() {
> for (int i = 0; i < 100; ++i) {
> MessageData data = new MessageData(userId, i);
> /*synchronized (session)*/ {
> session.write(data);
> }
> if (i % 5 ==
[jira] [Commented] (DIRMINA-1149) IoSession.write under multi-thread enviroment, lose message order
[
https://issues.apache.org/jira/browse/DIRMINA-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416415#comment-17416415
]
Jonathan Valliere commented on DIRMINA-1149:
For example a program:
1) generate 50 Runnable instances e.g. Runnable ( add(N+1) )
2) each Runnable adds a number to a shared concurrent Queue.
3) each Runnable is executed sequentially using the ThreadPoolExecutor.
You will see that eventually the resulting Queue will contain out of order
numbers.
> IoSession.write under multi-thread enviroment, lose message order
> -
>
> Key: DIRMINA-1149
> URL: https://issues.apache.org/jira/browse/DIRMINA-1149
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.21
> Environment: Java 1.8
> Windows 10
>Reporter: Zhang Hua
>Priority: Minor
> Attachments: minatest.zip
>
>
> I am writing a stress-test that tests multi-thread safetyness of
> IoSession.write method, and find lose message order.
> My test method is as follows
> 1. The client test code starts 50 threads, sharing the same IoSession object
> 2. Each test thread simulates a user and sends data in sequence
> I believe that the IoFilter I use meets the thread safety conditions
> The result I expect is that the server receives the data of each user in an
> orderly manner, but not
> Synchronizing on the session.write makes the problem go away;
> Do I really have to synchronize on the session to solve this issue?
>
> ClientDemo.java
> {code:java}
> public class ClientDemo {
> public static void main(String[] args) throws Exception {
> NioSocketConnector connector = new NioSocketConnector();
> DefaultIoFilterChainBuilder chain = connector.getFilterChain();
> chain.addLast("mdc", new MdcInjectionFilter());
> chain.addLast("codec", new ProtocolCodecFilter(new
> MessagePackCodecFactory()));
> TcpRPCHandler responseHandler = new TcpRPCHandler();
> connector.setHandler(responseHandler);
> connector.setConnectTimeoutCheckInterval(30);
> ConnectFuture cf = connector.connect(new
> InetSocketAddress("127.0.0.1", ));
> IoSession session = cf.awaitUninterruptibly().getSession();
> ExecutorService executor = Executors.newFixedThreadPool(50);
> for (int i = 0; i < 50; ++i) {
> executor.execute(new SenderWorker(i, session));
> }
> while (true) {
> Thread.sleep(5000);
> System.out.println("client alive..");
> //responseHandler.printProgress();
> }}
> }
> class SenderWorker implements Runnable {
> private int userId;
> private IoSession session;public SenderWorker(int userId, IoSession
> session) {
> this.userId = userId;
> this.session = session;
> }@Override
> public void run() {
> for (int i = 0; i < 100; ++i) {
> MessageData data = new MessageData(userId, i);
> /*synchronized (session)*/ {
> session.write(data);
> }
> if (i % 5 == 0) {
> try {
> Thread.sleep(10);
> } catch (Exception e) {
> }
> }
> }
> }
> }
> {code}
> See the attachment for the complete code, I use maven to manage the project
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1149) IoSession.write under multi-thread enviroment, lose message order
[
https://issues.apache.org/jira/browse/DIRMINA-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416164#comment-17416164
]
Jonathan Valliere commented on DIRMINA-1149:
#1 the version of MINA you are using doesn't support concurrent
ProtocolCodecFilter operations.
#2 the process of spawning 50 threads and executing sequential tasks is always
going to lead to situations where one subsequent may obtain a lock unfairly and
out of order.
Once the WriteRequest makes it to the IoProcessor, it is added to a FIFO queue.
The order in which the locks are granted is not guaranteed. So, two threads
fighting for the same lock may lead to out of order situations. This is not
unique to MINA but rather parallel execution in general.
> IoSession.write under multi-thread enviroment, lose message order
> -
>
> Key: DIRMINA-1149
> URL: https://issues.apache.org/jira/browse/DIRMINA-1149
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.21
> Environment: Java 1.8
> Windows 10
>Reporter: Zhang Hua
>Priority: Minor
> Attachments: minatest.zip
>
>
> I am writing a stress-test that tests multi-thread safetyness of
> IoSession.write method, and find lose message order.
> My test method is as follows
> 1. The client test code starts 50 threads, sharing the same IoSession object
> 2. Each test thread simulates a user and sends data in sequence
> I believe that the IoFilter I use meets the thread safety conditions
> The result I expect is that the server receives the data of each user in an
> orderly manner, but not
> Synchronizing on the session.write makes the problem go away;
> Do I really have to synchronize on the session to solve this issue?
>
> ClientDemo.java
> {code:java}
> public class ClientDemo {
> public static void main(String[] args) throws Exception {
> NioSocketConnector connector = new NioSocketConnector();
> DefaultIoFilterChainBuilder chain = connector.getFilterChain();
> chain.addLast("mdc", new MdcInjectionFilter());
> chain.addLast("codec", new ProtocolCodecFilter(new
> MessagePackCodecFactory()));
> TcpRPCHandler responseHandler = new TcpRPCHandler();
> connector.setHandler(responseHandler);
> connector.setConnectTimeoutCheckInterval(30);
> ConnectFuture cf = connector.connect(new
> InetSocketAddress("127.0.0.1", ));
> IoSession session = cf.awaitUninterruptibly().getSession();
> ExecutorService executor = Executors.newFixedThreadPool(50);
> for (int i = 0; i < 50; ++i) {
> executor.execute(new SenderWorker(i, session));
> }
> while (true) {
> Thread.sleep(5000);
> System.out.println("client alive..");
> //responseHandler.printProgress();
> }}
> }
> class SenderWorker implements Runnable {
> private int userId;
> private IoSession session;public SenderWorker(int userId, IoSession
> session) {
> this.userId = userId;
> this.session = session;
> }@Override
> public void run() {
> for (int i = 0; i < 100; ++i) {
> MessageData data = new MessageData(userId, i);
> /*synchronized (session)*/ {
> session.write(data);
> }
> if (i % 5 == 0) {
> try {
> Thread.sleep(10);
> } catch (Exception e) {
> }
> }
> }
> }
> }
> {code}
> See the attachment for the complete code, I use maven to manage the project
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (DIRMINA-1148) NPE in Socks4LogicHandler
[
https://issues.apache.org/jira/browse/DIRMINA-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Valliere resolved DIRMINA-1148.
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=667517901d27ff9f342917bf1966aba150a427af
> NPE in Socks4LogicHandler
> -
>
> Key: DIRMINA-1148
> URL: https://issues.apache.org/jira/browse/DIRMINA-1148
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.1.4
>Reporter: Grzegorz Grzybek
>Priority: Critical
>
> {{SOCKS4}} 0x01 packet (establish a TCP/IP stream connection) may contain
> {{ID}} field to send variable-length, null-terminated user ID. However the
> code in
> {{org.apache.mina.proxy.handlers.socks.Socks4LogicHandler#writeRequest}}
> simply contains:
> {code:java}
> byte[] userID = request.getUserName().getBytes("ASCII");
> {code}
> leading to NPE, when the user ID is not set. For example camel-quickfix uses
> mina through quickfix-j library and username is optional.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1148) NPE in Socks4LogicHandler
[
https://issues.apache.org/jira/browse/DIRMINA-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Valliere updated DIRMINA-1148:
---
Fix Version/s: 2.2.0
> NPE in Socks4LogicHandler
> -
>
> Key: DIRMINA-1148
> URL: https://issues.apache.org/jira/browse/DIRMINA-1148
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.1.4
>Reporter: Grzegorz Grzybek
>Priority: Critical
> Fix For: 2.2.0
>
>
> {{SOCKS4}} 0x01 packet (establish a TCP/IP stream connection) may contain
> {{ID}} field to send variable-length, null-terminated user ID. However the
> code in
> {{org.apache.mina.proxy.handlers.socks.Socks4LogicHandler#writeRequest}}
> simply contains:
> {code:java}
> byte[] userID = request.getUserName().getBytes("ASCII");
> {code}
> leading to NPE, when the user ID is not set. For example camel-quickfix uses
> mina through quickfix-j library and username is optional.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1148) NPE in Socks4LogicHandler
[
https://issues.apache.org/jira/browse/DIRMINA-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17410619#comment-17410619
]
Jonathan Valliere commented on DIRMINA-1148:
Does getUserName() return NULL? Seems like you should be checking for NULL
there.
> NPE in Socks4LogicHandler
> -
>
> Key: DIRMINA-1148
> URL: https://issues.apache.org/jira/browse/DIRMINA-1148
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.1.4
>Reporter: Grzegorz Grzybek
>Priority: Critical
>
> {{SOCKS4}} 0x01 packet (establish a TCP/IP stream connection) may contain
> {{ID}} field to send variable-length, null-terminated user ID. However the
> code in
> {{org.apache.mina.proxy.handlers.socks.Socks4LogicHandler#writeRequest}}
> simply contains:
> {code:java}
> byte[] userID = request.getUserName().getBytes("ASCII");
> {code}
> leading to NPE, when the user ID is not set. For example camel-quickfix uses
> mina through quickfix-j library and username is optional.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17410618#comment-17410618 ] Jonathan Valliere commented on DIRMINA-1145: Update everywhere MINA is used. > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.1.5-SNAPSHOT-working.jar, > mina-core-2.2.0-SNAPSHOT.jar, mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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
[ https://issues.apache.org/jira/browse/DIRMINA-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404774#comment-17404774 ] Jonathan Valliere commented on DIRMINA-1144: [~sebb] I was referring to how Maven detects that the locally cached version of e.g. 2.2-SNAPSHOT is older than the one on the server with the same name 2.2-SNAPSHOT unless it uses the HTTP headers to determine age or something. > 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.3.4#803005) - 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
[ https://issues.apache.org/jira/browse/DIRMINA-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404572#comment-17404572 ] Jonathan Valliere commented on DIRMINA-1144: How would you invalidate your local copy of SNAPSHOT when a new one is uploaded? > 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.3.4#803005) - 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
[ https://issues.apache.org/jira/browse/DIRMINA-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404520#comment-17404520 ] Jonathan Valliere commented on DIRMINA-1144: The policy of Maven / Central is upload once and never touch the file again. Unless they change the policy to allow continuous builds special for SNAPSHOTs then we can't store SNAPSHOTs there. > 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.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17399803#comment-17399803 ] Jonathan Valliere commented on DIRMINA-1145: Probably when this sprint is completed https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=321 > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.1.5-SNAPSHOT-working.jar, > mina-core-2.2.0-SNAPSHOT.jar, mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1132) TLSv1.3 - MINA randomly fails in reading the message sent by client
[
https://issues.apache.org/jira/browse/DIRMINA-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17394935#comment-17394935
]
Jonathan Valliere commented on DIRMINA-1132:
[~seelmann]
https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=4c1115590e183267d5536ded8d3eec316efb128f
> 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.0
>
> 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());
> System.out.println( "==" );
> session.closeNow();
>}
>@Override
>public void exceptionCaught(IoSession session, Throwable cause) {
> System.out.println("Exception :\n");
> cause.printStackTrace();
> session.closeNow();
>}
>@Override
>public void messageReceived(IoSession session, Object message) {
> System.out.println("Message Received!!!");
[jira] [Comment Edited] (DIRMINA-1132) TLSv1.3 - MINA randomly fails in reading the message sent by client
[
https://issues.apache.org/jira/browse/DIRMINA-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17394895#comment-17394895
]
Jonathan Valliere edited comment on DIRMINA-1132 at 8/6/21, 4:49 PM:
-
[~seelmann] do you need the {{SSLSession}} before the session is connected? I
can make the value of the AttributeKey SSL_SECURED be the SSLSession.
was (Author: johnnyv):
[~seelmann] do you need the {{SSLSession}} before the session is connected?
> 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.0
>
> 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());
> System.out.println( "==" );
> session.closeNow();
>}
>@Override
>public void exceptionCaught(IoSession session, Throwable cause) {
> System.out.println("Exception :\n");
>
[jira] [Commented] (DIRMINA-1132) TLSv1.3 - MINA randomly fails in reading the message sent by client
[
https://issues.apache.org/jira/browse/DIRMINA-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17394895#comment-17394895
]
Jonathan Valliere commented on DIRMINA-1132:
[~seelmann] do you need the {{SSLSession}} before the session is connected?
> 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.0
>
> 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());
> System.out.println( "==" );
> session.closeNow();
>}
>@Override
>public void exceptionCaught(IoSession session, Throwable cause) {
> System.out.println("Exception :\n");
> cause.printStackTrace();
> session.closeNow();
>}
>@Override
>public void messageReceived(IoSession session, Object message) {
> System.out.println("Message Received!!!");
> //do further processing on
[jira] [Comment Edited] (DIRMINA-1132) TLSv1.3 - MINA randomly fails in reading the message sent by client
[
https://issues.apache.org/jira/browse/DIRMINA-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17394881#comment-17394881
]
Jonathan Valliere edited comment on DIRMINA-1132 at 8/6/21, 4:35 PM:
-
[~seelmann] I have no problem adding that back. However, all you would need to
do to expose that without changing the mainline is create your own
{{AttributeKey}} extend {{SSL2Filter#createEngine()}} and set the attribute key
to the {{IoSession}}. That way you can retrieve the {{SSLSession}} anywhere
using the {{AttributeKey}}.
I want to come up with solutions which benefit ApacheDirectory while ensuring
that ApacheDirectory is implementing the features in a safe and secure way.
was (Author: johnnyv):
[~seelmann] I have no problem adding that back. However, all you would need to
do to expose that without changing the mainline is create your own
{{AttributeKey}} extend {{SSL2Filter#createEngine()}} and set the attribute key
to the {{IoSession}}. That way you can retrieve the {{SSLSession}} anywhere
using the {{AttributeKey}}.
> 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.0
>
> 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
[jira] [Commented] (DIRMINA-1132) TLSv1.3 - MINA randomly fails in reading the message sent by client
[
https://issues.apache.org/jira/browse/DIRMINA-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17394881#comment-17394881
]
Jonathan Valliere commented on DIRMINA-1132:
[~seelmann] I have no problem adding that back. However, all you would need to
do to expose that without changing the mainline is create your own
{{AttributeKey}} extend {{SSL2Filter#createEngine()}} and set the attribute key
to the {{IoSession}}. That way you can retrieve the {{SSLSession}} anywhere
using the {{AttributeKey}}.
> 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.0
>
> 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());
> System.out.println( "==" );
> session.closeNow();
>}
>@Override
>public void exceptionCaught(IoSession session, Throwable cause) {
>
[jira] [Comment Edited] (DIRMINA-1132) TLSv1.3 - MINA randomly fails in reading the message sent by client
[
https://issues.apache.org/jira/browse/DIRMINA-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17394864#comment-17394864
]
Jonathan Valliere edited comment on DIRMINA-1132 at 8/6/21, 4:30 PM:
-
[~canberkizgi]
* {{setUseClientMode()}} is no longer needed because client mode is
automatically determined by the type of {{IoSession}}. An {{IoSession}}
created by the {{IoConnector}} will automatically start in client mode. The
new API {{IoSession#isServer()}} simplifies the determination as to whether the
{{IoSession}} is owned by a server or not.
* {{isSslStarted()}} is no longer needed because SSL will automatically start
when added to the filter-chain for client mode {{IoSessions}}. The moment the
filter is added to the chain, you assume that the SSL has begun. The SSL
process should be completely transparent; you should not have to engineer
solutions based on knowing the internal state of the SSL. If you have to know
the internal state of the SSL then I've designed something poorly.
* {{getSslSession()}} can be added back in another form if necessary; if you
want to configure the {{SSLSession}} before handshaking all you need to do is
extend {{SSL2Filter#createEngine()}} to apply your own config.
* {{PEER_ADDRESS}} is determined automatically by reading the IoSession
address. This could be added back if justifiable.
* {{DISABLE_ENCRYPTION_ONCE}} is completely thread unsafe because there is
never any order guarantee that the next message is the one you want to not
encrypt. I'm also not sure what the particular usage scenario is for this. If
this functionality is absolutely necessary, then some kind of
DoNotEncryptWriteRequest would need to be added.
* {{USE_NOTIFICATION}} (while IMHO is completely unnecessary) is enabled by
default; the notification event is dispatched and the session attribute
{{SSL_SECURED}} is set to NOT NULL. Otherwise, it is perfectly safe to write
messages at any time after the SSL2 filter has been added to the filter-chain.
The old SSL package will be completely removed from 2.2.X forward. The new
SSL2 package will become the default SSL implementation for MINA. The old SSL
package was very weirdly designed from the start and many many patches were
added trying to save it from itself. Kind of like slapping duct tape on a
sinking boat. Our boat was more duct tape than boat at this point. Unresolved
SSL bugs were a large percentage of the open and unresolved issues in MINA.
This led to something that was completely unmanageable and should not represent
the code quality we are striving for moving forward.
My goal here is to end up with something which is cleanly written an
extendable. It is my preference to have the design allow users to extend the
package to implement their own features rather than adding features only one
organization uses to the mainline.
was (Author: johnnyv):
[~canberkizgi]
* {{setUseClientMode()}} is no longer needed because client mode is
automatically determined by the type of {{IoSession}}. An {{IoSession}}
created by the {{IoConnector}} will automatically start in client mode. The
new API {{IoSession#isServer()}} simplifies the determination as to whether the
{{IoSession}} is owned by a server or not.
* {{isSslStarted()}} is no longer needed because SSL will automatically start
when added to the filter-chain for client mode {{IoSessions}}. The moment the
filter is added to the chain, you assume that the SSL has begun. The SSL
process should be completely transparent; you should not have to engineer
solutions based on knowing the internal state of the SSL. If you have to know
the internal state of the SSL then I've designed something poorly.
* {{getSslSession()}} can be added back in another form if necessary; if you
want to configure the {{SSLSession}} before handshaking all you need to do is
extend {{SSL2Filter#onEngineCreated()}} to apply your own config.
* {{PEER_ADDRESS}} is determined automatically by reading the IoSession
address. This could be added back if justifiable.
* {{DISABLE_ENCRYPTION_ONCE}} is completely thread unsafe because there is
never any order guarantee that the next message is the one you want to not
encrypt. I'm also not sure what the particular usage scenario is for this. If
this functionality is absolutely necessary, then some kind of
DoNotEncryptWriteRequest would need to be added.
* {{USE_NOTIFICATION}} (while IMHO is completely unnecessary) is enabled by
default; the notification event is dispatched and the session attribute
{{SSL_SECURED}} is set to NOT NULL. Otherwise, it is perfectly safe to write
messages at any time after the SSL2 filter has been added to the filter-chain.
The old SSL package will be completely removed from 2.2.X forward. The new
SSL2 package will become the default SSL implementation for MINA. The old SSL
[jira] [Comment Edited] (DIRMINA-1132) TLSv1.3 - MINA randomly fails in reading the message sent by client
[
https://issues.apache.org/jira/browse/DIRMINA-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17394864#comment-17394864
]
Jonathan Valliere edited comment on DIRMINA-1132 at 8/6/21, 4:11 PM:
-
[~canberkizgi]
* {{setUseClientMode()}} is no longer needed because client mode is
automatically determined by the type of {{IoSession}}. An {{IoSession}}
created by the {{IoConnector}} will automatically start in client mode. The
new API {{IoSession#isServer()}} simplifies the determination as to whether the
{{IoSession}} is owned by a server or not.
* {{isSslStarted()}} is no longer needed because SSL will automatically start
when added to the filter-chain for client mode {{IoSessions}}. The moment the
filter is added to the chain, you assume that the SSL has begun. The SSL
process should be completely transparent; you should not have to engineer
solutions based on knowing the internal state of the SSL. If you have to know
the internal state of the SSL then I've designed something poorly.
* {{getSslSession()}} can be added back in another form if necessary; if you
want to configure the {{SSLSession}} before handshaking all you need to do is
extend {{SSL2Filter#onEngineCreated()}} to apply your own config.
* {{PEER_ADDRESS}} is determined automatically by reading the IoSession
address. This could be added back if justifiable.
* {{DISABLE_ENCRYPTION_ONCE}} is completely thread unsafe because there is
never any order guarantee that the next message is the one you want to not
encrypt. I'm also not sure what the particular usage scenario is for this. If
this functionality is absolutely necessary, then some kind of
DoNotEncryptWriteRequest would need to be added.
* {{USE_NOTIFICATION}} (while IMHO is completely unnecessary) is enabled by
default; the notification event is dispatched and the session attribute
{{SSL_SECURED}} is set to NOT NULL. Otherwise, it is perfectly safe to write
messages at any time after the SSL2 filter has been added to the filter-chain.
The old SSL package will be completely removed from 2.2.X forward. The new
SSL2 package will become the default SSL implementation for MINA. The old SSL
package was very weirdly designed from the start and many many patches were
added trying to save it from itself. Kind of like slapping duct tape on a
sinking boat. Our boat was more duct tape than boat at this point. Unresolved
SSL bugs were a large percentage of the open and unresolved issues in MINA.
This led to something that was completely unmanageable and should not represent
the code quality we are striving for moving forward.
My goal here is to end up with something which is cleanly written an
extendable. It is my preference to have the design allow users to extend the
package to implement their own features rather than adding features only one
organization uses to the mainline.
was (Author: johnnyv):
[~canberkizgi]
* {{setUseClientMode() }}is no longer needed because client mode is
automatically determined by the type of {{IoSession}}. An {{IoSession}}
created by the {{IoConnector}} will automatically start in client mode. The
new API {{IoSession#isServer()}} simplifies the determination as to whether the
{{IoSession}} is owned by a server or not.
* {{isSslStarted()}} is no longer needed because SSL will automatically start
when added to the filter-chain for client mode {{IoSessions}}. The moment the
filter is added to the chain, you assume that the SSL has begun. The SSL
process should be completely transparent; you should not have to engineer
solutions based on knowing the internal state of the SSL. If you have to know
the internal state of the SSL then I've designed something poorly.
* {{getSslSession()}} can be added back in another form if necessary; if you
want to configure the {{SSLSession}} before handshaking all you need to do is
extend {{SSL2Filter#onEngineCreated()}} to apply your own config.
* {{PEER_ADDRESS}} is determined automatically by reading the IoSession
address. This could be added back if justifiable.
* {{DISABLE_ENCRYPTION_ONCE}} is completely thread unsafe because there is
never any order guarantee that the next message is the one you want to not
encrypt. I'm also not sure what the particular usage scenario is for this. If
this functionality is absolutely necessary, then some kind of
DoNotEncryptWriteRequest would need to be added.
* {{USE_NOTIFICATION}} (while IMHO is completely unnecessary) is enabled by
default; the notification event is dispatched and the session attribute
{{SSL_SECURED}} is set to NOT NULL. Otherwise, it is perfectly safe to write
messages at any time after the SSL2 filter has been added to the filter-chain.
The old SSL package will be completely removed from 2.2.X forward. The new
SSL2 package will become the default SSL implementation for MINA. The old
[jira] [Comment Edited] (DIRMINA-1132) TLSv1.3 - MINA randomly fails in reading the message sent by client
[
https://issues.apache.org/jira/browse/DIRMINA-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17394864#comment-17394864
]
Jonathan Valliere edited comment on DIRMINA-1132 at 8/6/21, 4:11 PM:
-
[~canberkizgi]
* {{setUseClientMode() }}is no longer needed because client mode is
automatically determined by the type of {{IoSession}}. An {{IoSession}}
created by the {{IoConnector}} will automatically start in client mode. The
new API {{IoSession#isServer()}} simplifies the determination as to whether the
{{IoSession}} is owned by a server or not.
* {{isSslStarted()}} is no longer needed because SSL will automatically start
when added to the filter-chain for client mode {{IoSessions}}. The moment the
filter is added to the chain, you assume that the SSL has begun. The SSL
process should be completely transparent; you should not have to engineer
solutions based on knowing the internal state of the SSL. If you have to know
the internal state of the SSL then I've designed something poorly.
* {{getSslSession()}} can be added back in another form if necessary; if you
want to configure the {{SSLSession}} before handshaking all you need to do is
extend {{SSL2Filter#onEngineCreated()}} to apply your own config.
* {{PEER_ADDRESS}} is determined automatically by reading the IoSession
address. This could be added back if justifiable.
* {{DISABLE_ENCRYPTION_ONCE}} is completely thread unsafe because there is
never any order guarantee that the next message is the one you want to not
encrypt. I'm also not sure what the particular usage scenario is for this. If
this functionality is absolutely necessary, then some kind of
DoNotEncryptWriteRequest would need to be added.
* {{USE_NOTIFICATION}} (while IMHO is completely unnecessary) is enabled by
default; the notification event is dispatched and the session attribute
{{SSL_SECURED}} is set to NOT NULL. Otherwise, it is perfectly safe to write
messages at any time after the SSL2 filter has been added to the filter-chain.
The old SSL package will be completely removed from 2.2.X forward. The new
SSL2 package will become the default SSL implementation for MINA. The old SSL
package was very weirdly designed from the start and many many patches were
added trying to save it from itself. Kind of like slapping duct tape on a
sinking boat. Our boat was more duct tape than boat at this point. Unresolved
SSL bugs were a large percentage of the open and unresolved issues in MINA.
This led to something that was completely unmanageable and should not represent
the code quality we are striving for moving forward.
My goal here is to end up with something which is cleanly written an
extendable. It is my preference to have the design allow users to extend the
package to implement their own features rather than adding features only one
organization uses to the mainline.
was (Author: johnnyv):
[~canberkizgi]
* {{setUseClientMode() }}is no longer needed because client mode is
automatically determined by the type of {{IoSession}}. An {{IoSession}}
created by the {{IoConnector}} will automatically start in client mode. The
new API {{IoSession#isServer()}} simplifies the determination as to whether the
{{IoSession}} is owned by a server or not.
* i{{sSslStarted()}} is no longer needed because SSL will automatically start
when added to the filter-chain for client mode {{IoSessions}}. The moment the
filter is added to the chain, you assume that the SSL has begun. {{}}The SSL
process should be completely transparent; you should not have to engineer
solutions based on knowing the internal state of the SSL. If you have to know
the internal state of the SSL then I've designed something poorly.
* {{getSslSession()}} can be added back in another form if necessary; if you
want to configure the {{SSLSession}} before handshaking all you need to do is
extend {{SSL2Filter#onEngineCreated()}} to apply your own config.
* {{PEER_ADDRESS}} is determined automatically by reading the IoSession
address. This could be added back if justifiable.
* {{DISABLE_ENCRYPTION_ONCE}} is completely thread unsafe because there is
never any order guarantee that the next message is the one you want to not
encrypt. I'm also not sure what the particular usage scenario is for this. If
this functionality is absolutely necessary, then some kind of
DoNotEncryptWriteRequest would need to be added.
* {{USE_NOTIFICATION}} (while IMHO is completely unnecessary) is enabled by
default; the notification event is dispatched and the session attribute
{{SSL_SECURED}} is set to NOT NULL. Otherwise, it is perfectly safe to write
messages at any time after the SSL2 filter has been added to the filter-chain.
The old SSL package will be completely removed from 2.2.X forward. The new
SSL2 package will become the default SSL implementation for MINA. The
[jira] [Commented] (DIRMINA-1132) TLSv1.3 - MINA randomly fails in reading the message sent by client
[
https://issues.apache.org/jira/browse/DIRMINA-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17394864#comment-17394864
]
Jonathan Valliere commented on DIRMINA-1132:
[~canberkizgi]
* {{setUseClientMode() }}is no longer needed because client mode is
automatically determined by the type of {{IoSession}}. An {{IoSession}}
created by the {{IoConnector}} will automatically start in client mode. The
new API {{IoSession#isServer()}} simplifies the determination as to whether the
{{IoSession}} is owned by a server or not.
* i{{sSslStarted()}} is no longer needed because SSL will automatically start
when added to the filter-chain for client mode {{IoSessions}}. The moment the
filter is added to the chain, you assume that the SSL has begun. {{}}The SSL
process should be completely transparent; you should not have to engineer
solutions based on knowing the internal state of the SSL. If you have to know
the internal state of the SSL then I've designed something poorly.
* {{getSslSession()}} can be added back in another form if necessary; if you
want to configure the {{SSLSession}} before handshaking all you need to do is
extend {{SSL2Filter#onEngineCreated()}} to apply your own config.
* {{PEER_ADDRESS}} is determined automatically by reading the IoSession
address. This could be added back if justifiable.
* {{DISABLE_ENCRYPTION_ONCE}} is completely thread unsafe because there is
never any order guarantee that the next message is the one you want to not
encrypt. I'm also not sure what the particular usage scenario is for this. If
this functionality is absolutely necessary, then some kind of
DoNotEncryptWriteRequest would need to be added.
* {{USE_NOTIFICATION}} (while IMHO is completely unnecessary) is enabled by
default; the notification event is dispatched and the session attribute
{{SSL_SECURED}} is set to NOT NULL. Otherwise, it is perfectly safe to write
messages at any time after the SSL2 filter has been added to the filter-chain.
The old SSL package will be completely removed from 2.2.X forward. The new
SSL2 package will become the default SSL implementation for MINA. The old SSL
package was very weirdly designed from the start and many many patches were
added trying to save it from itself. Kind of like slapping duct tape on a
sinking boat. Our boat was more duct tape than boat at this point. Unresolved
SSL bugs were a large percentage of the open and unresolved issues in MINA.
This led to something that was completely unmanageable and should not represent
the code quality we are striving for moving forward.
My goal here is to end up with something which is cleanly written an
extendable. It is my preference to have the design allow users to extend the
package to implement their own features rather than adding features only one
organization uses to the mainline.
> 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.0
>
> 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,
[jira] [Commented] (DIRMINA-1144) Deadlock with SSL + Proxy
[ https://issues.apache.org/jira/browse/DIRMINA-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17394718#comment-17394718 ] Jonathan Valliere commented on DIRMINA-1144: [~chrjohn] thanks a million. The SSL2Filter has an onEngineCreated override method making it very easy to add customizations. SSL2Filter is a drop in replacement which AFAIK emits all the same signals that the old version does and should be fully compatible. > 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.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1014) SocketAcceptor doesn't unbind correctly
[ https://issues.apache.org/jira/browse/DIRMINA-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Valliere updated DIRMINA-1014: --- Fix Version/s: 2.2.0 > SocketAcceptor doesn't unbind correctly > --- > > Key: DIRMINA-1014 > URL: https://issues.apache.org/jira/browse/DIRMINA-1014 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.0.9 > Environment: Ubuntu 12.04.5 x64 > Oracle JDK 1.6.0_45 > Mina 2.0.9 >Reporter: Nipun Jawalkar >Assignee: Emmanuel Lécharny >Priority: Major > Fix For: 2.2.0 > > > When the AbstractIoAcceptor binds a socket, it adds an entry to the > "boundAddresses" set to keep track of that socket. > In my case, I am passing a SocketAddress initialized with a specific port, > and "null" for host (I want to listen on that port on all interfaces on the > the local machine, i.e 0.0.0.0:). This InetSocketAddress instance has an > Inet4Address in it when created. > When the Acceptor is given this v4 SocketAddress to bind, it creates a > ServerSocketChannel, and then calls > ServerSocketChannel.socket().getLocalSocketAddress() to retrieve a > SocketAddress. This is the value that is then put in the "boundAddresses" > collection. > The problem is that the ServerSocketChannel.socket().getLocalSocketAddress() > returns a SocketAddress with an Inet6Address value in it > (0.0.0.0.0.0.0.0:), even though the SocketAcceptor.bind() was given a v4 > address. So when I try to unbind that socket (using the same v4 address I > used to do the bind() call), it fails because the "boundAddresses" set has > the v6 version in it, and "Inet6Address.equals(Inet4Address) is false". > Basically: > 1. I call NioSocketAcceptor.bind() on a v4 SocketAddress > 2. A ServerSocketChannel is created for that v4 address. > 3. The ServerSocketChannel.socket().getLocalSocketAddress() is called, which > returns a v6 SocketAddress (which is the equivalent of the v4 SocketAddress > given) > 4. NioSocketAcceptor puts the v6 address in its "boundAddresses" list. > 5. When I ask to unbind the same v4 address, it fails because the > "boundAddresses" list only contains a v6 address. > Suggested Fix: > 1. Make the "boundAddresses" field a Map. The > keys should be the SocketAddress parameter passed to the bind() call, the > values should be the ServerSocketChannel.socket().getLocalSocketAddress(). > 2. When unbind(a) is called, check "boundAddresses.hasKey(a)", and if true, > then unbind "boundAddresses.get(a)". > This makes it consistent for the client; they can use the same instance of > SocketAddress to bind and unbind reliably. > This will match Mina v1.x version, where the SocketAddress passed to the > bind() method could be used to also unbind. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Work started] (DIRMINA-1014) SocketAcceptor doesn't unbind correctly
[ https://issues.apache.org/jira/browse/DIRMINA-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on DIRMINA-1014 started by Jonathan Valliere. -- > SocketAcceptor doesn't unbind correctly > --- > > Key: DIRMINA-1014 > URL: https://issues.apache.org/jira/browse/DIRMINA-1014 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.0.9 > Environment: Ubuntu 12.04.5 x64 > Oracle JDK 1.6.0_45 > Mina 2.0.9 >Reporter: Nipun Jawalkar >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > > When the AbstractIoAcceptor binds a socket, it adds an entry to the > "boundAddresses" set to keep track of that socket. > In my case, I am passing a SocketAddress initialized with a specific port, > and "null" for host (I want to listen on that port on all interfaces on the > the local machine, i.e 0.0.0.0:). This InetSocketAddress instance has an > Inet4Address in it when created. > When the Acceptor is given this v4 SocketAddress to bind, it creates a > ServerSocketChannel, and then calls > ServerSocketChannel.socket().getLocalSocketAddress() to retrieve a > SocketAddress. This is the value that is then put in the "boundAddresses" > collection. > The problem is that the ServerSocketChannel.socket().getLocalSocketAddress() > returns a SocketAddress with an Inet6Address value in it > (0.0.0.0.0.0.0.0:), even though the SocketAcceptor.bind() was given a v4 > address. So when I try to unbind that socket (using the same v4 address I > used to do the bind() call), it fails because the "boundAddresses" set has > the v6 version in it, and "Inet6Address.equals(Inet4Address) is false". > Basically: > 1. I call NioSocketAcceptor.bind() on a v4 SocketAddress > 2. A ServerSocketChannel is created for that v4 address. > 3. The ServerSocketChannel.socket().getLocalSocketAddress() is called, which > returns a v6 SocketAddress (which is the equivalent of the v4 SocketAddress > given) > 4. NioSocketAcceptor puts the v6 address in its "boundAddresses" list. > 5. When I ask to unbind the same v4 address, it fails because the > "boundAddresses" list only contains a v6 address. > Suggested Fix: > 1. Make the "boundAddresses" field a Map. The > keys should be the SocketAddress parameter passed to the bind() call, the > values should be the ServerSocketChannel.socket().getLocalSocketAddress(). > 2. When unbind(a) is called, check "boundAddresses.hasKey(a)", and if true, > then unbind "boundAddresses.get(a)". > This makes it consistent for the client; they can use the same instance of > SocketAddress to bind and unbind reliably. > This will match Mina v1.x version, where the SocketAddress passed to the > bind() method could be used to also unbind. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (DIRMINA-1014) SocketAcceptor doesn't unbind correctly
[ https://issues.apache.org/jira/browse/DIRMINA-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Valliere reassigned DIRMINA-1014: -- Assignee: Jonathan Valliere (was: Emmanuel Lécharny) > SocketAcceptor doesn't unbind correctly > --- > > Key: DIRMINA-1014 > URL: https://issues.apache.org/jira/browse/DIRMINA-1014 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.0.9 > Environment: Ubuntu 12.04.5 x64 > Oracle JDK 1.6.0_45 > Mina 2.0.9 >Reporter: Nipun Jawalkar >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > > When the AbstractIoAcceptor binds a socket, it adds an entry to the > "boundAddresses" set to keep track of that socket. > In my case, I am passing a SocketAddress initialized with a specific port, > and "null" for host (I want to listen on that port on all interfaces on the > the local machine, i.e 0.0.0.0:). This InetSocketAddress instance has an > Inet4Address in it when created. > When the Acceptor is given this v4 SocketAddress to bind, it creates a > ServerSocketChannel, and then calls > ServerSocketChannel.socket().getLocalSocketAddress() to retrieve a > SocketAddress. This is the value that is then put in the "boundAddresses" > collection. > The problem is that the ServerSocketChannel.socket().getLocalSocketAddress() > returns a SocketAddress with an Inet6Address value in it > (0.0.0.0.0.0.0.0:), even though the SocketAcceptor.bind() was given a v4 > address. So when I try to unbind that socket (using the same v4 address I > used to do the bind() call), it fails because the "boundAddresses" set has > the v6 version in it, and "Inet6Address.equals(Inet4Address) is false". > Basically: > 1. I call NioSocketAcceptor.bind() on a v4 SocketAddress > 2. A ServerSocketChannel is created for that v4 address. > 3. The ServerSocketChannel.socket().getLocalSocketAddress() is called, which > returns a v6 SocketAddress (which is the equivalent of the v4 SocketAddress > given) > 4. NioSocketAcceptor puts the v6 address in its "boundAddresses" list. > 5. When I ask to unbind the same v4 address, it fails because the > "boundAddresses" list only contains a v6 address. > Suggested Fix: > 1. Make the "boundAddresses" field a Map. The > keys should be the SocketAddress parameter passed to the bind() call, the > values should be the ServerSocketChannel.socket().getLocalSocketAddress(). > 2. When unbind(a) is called, check "boundAddresses.hasKey(a)", and if true, > then unbind "boundAddresses.get(a)". > This makes it consistent for the client; they can use the same instance of > SocketAddress to bind and unbind reliably. > This will match Mina v1.x version, where the SocketAddress passed to the > bind() method could be used to also unbind. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (DIRMINA-1082) SSLHandler calling wrap method after closeOutBound() on SSLEngine
[
https://issues.apache.org/jira/browse/DIRMINA-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Valliere resolved DIRMINA-1082.
Resolution: Not A Problem
AFAIK you have to call {{closeOutbound()}} to start the closure handshake. It
is correct to call {{closeOutbound()}} then {{wrap()}} to cause the closure
handshake messages to be produced.
> SSLHandler calling wrap method after closeOutBound() on SSLEngine
> -
>
> Key: DIRMINA-1082
> URL: https://issues.apache.org/jira/browse/DIRMINA-1082
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.16
>Reporter: Kamal Rathod
>Assignee: Emmanuel Lécharny
>Priority: Major
> Fix For: 2.2.0
>
>
> Hi,
> I am trying to connect through SSL and Proxy and getting below error.
> _ERROR quickfix.mina.initiator.InitiatorIoHandler - Socket :
> javax.net.ssl.SSLException: Improper close state: Status = OK HandshakeStatus
> = NEED_WRAP_
> _bytesConsumed = 0 bytesProduced = 87_
> _javax.net.ssl.SSLException: Improper close state: Status = OK
> HandshakeStatus = NEED_WRAP_
> _bytesConsumed = 0 bytesProduced = 87_
> _at org.apache.mina.filter.ssl.SslHandler.closeOutbound(SslHandler.java:500)
> ~[mina-core.jar:?]_
> _at org.apache.mina.filter.ssl.SslFilter.initiateClosure(SslFilter.java:742)
> ~[mina-core.jar:?]_
> _at org.apache.mina.filter.ssl.SslFilter.filterClose(SslFilter.java:677)
> ~[mina-core.jar:?]_
> _at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterClose(DefaultIoFilterChain.java:648)
> ~[mina-core.jar:?]_
>
> I had a look at closeOutBound() method of SslHandler.java and suspect bug
> there.
> Line 484: sslEngine.closeOutBound()
> Line 490: sslEngine.wrap(emptyBuffer.buf(), outNetBuffer.buf());
>
> In the scenario the sslEngine is closed first and then the wrap method is
> called.
> As per java docs:
> _In all cases, closure handshake messages are generated by the engine, and
> {{wrap()}} should be repeatedly called until the resulting
> {{SSLEngineResult}}'s status returns "CLOSED", or
> [{{isOutboundDone()}}|https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLEngine.html#isOutboundDone()]
> returns true. All data obtained from the {{wrap()}} method should be sent to
> the peer._
> _[{{closeOutbound()}}|https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLEngine.html#closeOutbound()]
> is used to signal the engine that the application will not be sending any
> more data._
> So as per docs, wrap should be called repeatedly and then closeOutbound()
> method, but in code its reverse, after closeOutbound wrap is called.
> Can someone please check and comment on this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1119) Deadlock when using SSL and proxy
[ https://issues.apache.org/jira/browse/DIRMINA-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17394332#comment-17394332 ] Jonathan Valliere commented on DIRMINA-1119: This will probably be fixed from the changed in DIRMINA-1132 but I need some example code to reproduce this in order to verify that it is fixed. > Deadlock when using SSL and proxy > - > > Key: DIRMINA-1119 > URL: https://issues.apache.org/jira/browse/DIRMINA-1119 > Project: MINA > Issue Type: Bug > Components: Core, Filter >Affects Versions: 2.1.3 >Reporter: Sergey Staritsin >Assignee: Jonathan Valliere >Priority: Critical > Fix For: 2.2.0 > > Attachments: Deadlock_QFJ Timer_NioProcessor.txt > > > The issue seems to be the same as DIRMINA-995 (at least they have exactly the > same symptoms and conditions). > > 2019-09-09 12:04:38 > Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.151-b12 mixed mode): > Found one Java-level deadlock: > = > "NioProcessor-138": > waiting to lock monitor 0x0001040b88f8 (object 0x2ef07520, a > org.apache.mina.filter.ssl.SslHandler), > which is held by "OutputEventRoutingHandler" > "OutputEventRoutingHandler": > waiting to lock monitor 0x00010386a108 (object 0x2eff53b0, a > org.apache.mina.proxy.handlers.socks.Socks5LogicHandler), > which is held by "NioProcessor-138" > > Java stack information for the threads listed above: > === > "NioProcessor-138": > at > org.apache.mina.filter.ssl.SslFilter.getSslSessionHandler(SslFilter.java:823) > - waiting to lock <0x2ef07520> (a > org.apache.mina.filter.ssl.SslHandler) > at org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:499) > 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.proxy.filter.ProxyFilter.messageReceived(ProxyFilter.java:153) > - locked <0x2eff53b0> (a > org.apache.mina.proxy.handlers.socks.Socks5LogicHandler) > 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 > org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1222) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1211) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683) > at > org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > "OutputEventRoutingHandler": > at org.apache.mina.proxy.filter.ProxyFilter.writeData(ProxyFilter.java:214) > - waiting to lock <0x2eff53b0> (a > org.apache.mina.proxy.handlers.socks.Socks5LogicHandler) > at org.apache.mina.proxy.filter.ProxyFilter.filterWrite(ProxyFilter.java:198) > 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.ssl.SslHandler.flushFilterWrite(SslHandler.java:310) > at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:668) > - locked <0x2ef07520> (a org.apache.mina.filter.ssl.SslHandler) > at >
[jira] [Resolved] (DIRMINA-1035) HttpServerDecoder not handling colons in header values
[ https://issues.apache.org/jira/browse/DIRMINA-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Valliere resolved DIRMINA-1035. Resolution: Fixed https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=3726e4a3720eb4c0e60295b13af4ad2b0765bc75 > HttpServerDecoder not handling colons in header values > -- > > Key: DIRMINA-1035 > URL: https://issues.apache.org/jira/browse/DIRMINA-1035 > Project: MINA > Issue Type: Bug > Components: Protocol - HTTP >Affects Versions: 2.0.13 >Reporter: Mark Ford >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1035.patch > > > The HttpServerDecoder is splitting the HTTP header name/value on a colon via > a regular expression. The problem is that some HTTP headers from applications > contain colons in their values. The correct behavior would be to split on the > *first* colon and not every colon in the header name/value pair line. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Work started] (DIRMINA-1132) TLSv1.3 - MINA randomly fails in reading the message sent by client
[
https://issues.apache.org/jira/browse/DIRMINA-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on DIRMINA-1132 started by Jonathan Valliere.
--
> 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.0
>
> 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());
> System.out.println( "==" );
> session.closeNow();
>}
>@Override
>public void exceptionCaught(IoSession session, Throwable cause) {
> System.out.println("Exception :\n");
> cause.printStackTrace();
> session.closeNow();
>}
>@Override
>public void messageReceived(IoSession session, Object message) {
> System.out.println("Message Received!!!");
> //do further processing on @param{message}
> session.closeOnFlush();
>}
> }
> {code}
> Note: Try sending the
[jira] [Resolved] (DIRMINA-1105) SSLHandler buffer handling
[
https://issues.apache.org/jira/browse/DIRMINA-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Valliere resolved DIRMINA-1105.
Resolution: Won't Do
Using {{ThreadLocal}} storage then copying the decoded message again is not a
performance advantage. What if the TL storage isn't large enough to hold the
decoded message? Expanding the buffer requires copying all the data to a new
buffer... which just made the performance even worse than the TL method under
the best scenario. The minimum application buffer size may be 16k give or take
but the maximum is much larger and you don't want to end up in situations where
you have to cycle the encode or decode loop needlessly because you didn't
allocate enough memory the first time or are force to copy the buffers.
Garbage collection is a separate performance problem, that can be alleviated
using memory pools, from a solution which forces the copying data again and
again needlessly.
> SSLHandler buffer handling
> --
>
> Key: DIRMINA-1105
> URL: https://issues.apache.org/jira/browse/DIRMINA-1105
> Project: MINA
> Issue Type: Improvement
>Affects Versions: 2.0.21, 2.1.1
>Reporter: Emmanuel Lécharny
>Assignee: Emmanuel Lécharny
>Priority: Major
> Fix For: 2.2.0
>
>
> The {{SSLEngine.wrap()}} method requires the provided buffer to be 'big
> enough' to contain any kind of *SSL/TLS* message. That means 16921 bytes. The
> way it's implemented is that we allocate such a buffer every time we need to
> call the {{wrap}} method, then we copy the result into a smaller buffer that
> is injected into thee write queue.
> This is quite ineficient. It would rather be a better idea to use a Thread
> Local Storage buffer when calling the {{wrap}} method, and copy the content
> into a temporary buffer.
> Another optimization could be to concatenate the successive calls to the
> {{wrap}} method into a single buffer, that will be sent in one shot (it's
> frequent that more than one call to {{wrap}} is needed during the handshake).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Valliere resolved DIRMINA-1145. Resolution: Fixed Looks like this issue is fixed. There is still more work to be done to certify correctness of the SSL2 package before it is pushed into 2.2.X. Since this depends on the whole new SSL implementation, it cannot be back ported to 2.1.X because of our policy to not make any potentially functionality breaking changes between patch releases. > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.1.5-SNAPSHOT-working.jar, > mina-core-2.2.0-SNAPSHOT.jar, mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Valliere updated DIRMINA-1145: --- Sprint: Mina Sprint 1 > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.2.0-SNAPSHOT.jar, > mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1147) Concurrency problem on write interest
[ https://issues.apache.org/jira/browse/DIRMINA-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Valliere updated DIRMINA-1147: --- Description: *THIS IS A MAJOR ISSUE; I've seen it dozens of times today occurring during an event write and the concurrent send/write from another thread.* Write interest is not concurrent and full of issues relating to the synchronization between the backlog queue and the atomic flag write interest. It is possible to check for a queue to be not full, and add to the queue whereas the queue is emptied and write interest is disabled before the additional item is added to the queue. What happens is 2-3 atomic operations occur and cannot/do not check to see whether the state changed between the time of assertion and subsequent action. The scheduledFlush queue also suffers from the same concurrency problem. Events may be added to the queue after the scheduledFlush operation has removed it from the scheduledFlush queue and after queue is empited causing items to be added to the backlog but not trigger the scheduledFlush queue or interest. was: *THIS IS A MAJOR ISSUE; I've seen it dozens of times today occurring during an event write and the send/write from another thread.* Write interest is not concurrent and full of issues relating to the synchronization between the backlog queue and the atomic flag write interest. It is possible to check for a queue to be not full, and add to the queue whereas the queue is emptied and write interest is disabled before the additional item is added to the queue. What happens is 2-3 atomic operations occur and cannot/do not check to see whether the state changed between the time of assertion and subsequent action. The scheduledFlush queue also suffers from the same concurrency problem. Events may be added to the queue after the scheduledFlush operation has removed it from the scheduledFlush queue and after queue is empited causing items to be added to the backlog but not trigger the scheduledFlush queue or interest. > Concurrency problem on write interest > - > > Key: DIRMINA-1147 > URL: https://issues.apache.org/jira/browse/DIRMINA-1147 > Project: MINA > Issue Type: Bug > Components: Transport >Affects Versions: 2.1.4 > Environment: AdoptJDK 11 >Reporter: Jonathan Valliere >Assignee: Jonathan Valliere >Priority: Critical > Fix For: 2.2.0 > > > *THIS IS A MAJOR ISSUE; I've seen it dozens of times today occurring during > an event write and the concurrent send/write from another thread.* > Write interest is not concurrent and full of issues relating to the > synchronization between the backlog queue and the atomic flag write interest. > It is possible to check for a queue to be not full, and add to the queue > whereas the queue is emptied and write interest is disabled before the > additional item is added to the queue. > What happens is 2-3 atomic operations occur and cannot/do not check to see > whether the state changed between the time of assertion and subsequent action. > The scheduledFlush queue also suffers from the same concurrency problem. > Events may be added to the queue after the scheduledFlush operation has > removed it from the scheduledFlush queue and after queue is empited causing > items to be added to the backlog but not trigger the scheduledFlush queue or > interest. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Created] (DIRMINA-1147) Concurrency problem on write interest
Jonathan Valliere created DIRMINA-1147: -- Summary: Concurrency problem on write interest Key: DIRMINA-1147 URL: https://issues.apache.org/jira/browse/DIRMINA-1147 Project: MINA Issue Type: Bug Components: Transport Affects Versions: 2.1.4 Environment: AdoptJDK 11 Reporter: Jonathan Valliere Assignee: Jonathan Valliere Fix For: 2.2.0 *THIS IS A MAJOR ISSUE; I've seen it dozens of times today occurring during an event write and the send/write from another thread.* Write interest is not concurrent and full of issues relating to the synchronization between the backlog queue and the atomic flag write interest. It is possible to check for a queue to be not full, and add to the queue whereas the queue is emptied and write interest is disabled before the additional item is added to the queue. What happens is 2-3 atomic operations occur and cannot/do not check to see whether the state changed between the time of assertion and subsequent action. The scheduledFlush queue also suffers from the same concurrency problem. Events may be added to the queue after the scheduledFlush operation has removed it from the scheduledFlush queue and after queue is empited causing items to be added to the backlog but not trigger the scheduledFlush queue or interest. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (DIRMINA-1145) Mina Server is losing messages
[
https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17393426#comment-17393426
]
Jonathan Valliere edited comment on DIRMINA-1145 at 8/4/21, 7:59 PM:
-
Checkout
[https://gitbox.apache.org/repos/asf?p=mina.git;a=shortlog;h=refs/heads/bugfix/DIRMINA1132]
and build {{mina-core-2.1.5-SNAPSHOT}}. Then load [^DIRMINA-1145-EXAMPLE.zip]
I removed the {{ExecutorFilter}} because 2.1.5 does not include the concurrent
{{ProtocolCodecFactory}} improvements. The issue was related to JDK SSLEngine
emitting FINISHED twice where NOT_HANDSHAKING was expected. I had to enable
safe recursion of the receiver to ensure that all received messages are
processed regardless of where the FINISHED event occurs.
Setting {{MinaConfig.ENABLE_LOOP = true}} will cause stress testing. Setting
{{MinaConfig.NUM_CONCURRENT_PINGS > 1}} will cause message aggregation ensuring
message receive loop works correctly.
was (Author: johnnyv):
Checkout
[https://gitbox.apache.org/repos/asf?p=mina.git;a=shortlog;h=refs/heads/bugfix/DIRMINA1132]
and build {{mina-core-2.1.5-SNAPSHOT}}. Then load [^DIRMINA-1145-EXAMPLE.zip]
I removed the {{ExecutorFilter}} because 2.1.5 does not include the concurrent
{{ProtocolCodecFactory}} improvements. The issue was related to JDK SSLEngine
emitting FINISHED twice where NOT_HANDSHAKING was expected. I had to enable
safe recursion of the receiver to ensure that all received messages are
processed regardless of where the FINISHED event occurs.
> Mina Server is losing messages
> --
>
> Key: DIRMINA-1145
> URL: https://issues.apache.org/jira/browse/DIRMINA-1145
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.4
>Reporter: Guy Itzhaki
>Assignee: Jonathan Valliere
>Priority: Major
> Fix For: 2.2.0
>
> Attachments: DIRMINA-1145-EXAMPLE.zip,
> mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.2.0-SNAPSHOT.jar,
> mina_client_server.zip
>
>
> During our tests we found that in some circumstances Mina server loses
> messages.
> From what we understand this happens when client opens connection and then
> sends message(s) and the server is still busy processing the sessionOpened
> event while the message the client sent went through the server’s filterChain.
>
> Attached is a simple client and server that will help you reproduce the
> problem, before you run it please perform the following steps:
> *+Configuration:+*
> # In order to reproduce the problem SSL filter *must* be defined (already
> implemented in the attached example)
> # Update the keystore and truststore files locations in *addSSLFilter()*
> method in *MinaClient* and *MinaServer*
> # Set server break points at:
> # MinaServerHandler#sessionOpened
> # MinaServerHandler#messageReceived
> # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived
> # Set client break points at:
> # MinaClientHandler#sessionOpened
>
> *Since this is a timing problem you need to run a debugger as described
> below:*
> # Start server
> # Start client
> # At the client at *MinaClientHandler#sessionOpened* release the break point
> # Release all break points +except+ server’s
> *MinaServerHandler#sessionOpened*
> # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived
> completed to process all events, you can release
> *MinaServerHandler#sessionOpened*
>
> +*Expected result:*+
> MinaServerHandler#messageReceived will be invoked with the message sent by
> the client
> *+Actual result:+*
> MinaServerHandler#messageReceived is not invoked.
>
> To use the example, add the following jars to your class path:
> commons-lang3-3.9.jar
> log4j-api-2.13.3.jar
> log4j-core-2.13.3.jar
> log4j-jcl-2.13.3.jar
> mina-core-2.1.4.jar
> slf4j-api-1.7.26.jar
> spring-jcl-5.2.12.RELEASE.jar
>
> The java we use is *AdoptJDK 11.0.8*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1145) Mina Server is losing messages
[
https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17393426#comment-17393426
]
Jonathan Valliere commented on DIRMINA-1145:
Checkout
[https://gitbox.apache.org/repos/asf?p=mina.git;a=shortlog;h=refs/heads/bugfix/DIRMINA1132]
and build {{mina-core-2.1.5-SNAPSHOT}}. Then load [^DIRMINA-1145-EXAMPLE.zip]
I removed the {{ExecutorFilter}} because 2.1.5 does not include the concurrent
{{ProtocolCodecFactory}} improvements. The issue was related to JDK SSLEngine
emitting FINISHED twice where NOT_HANDSHAKING was expected. I had to enable
safe recursion of the receiver to ensure that all received messages are
processed regardless of where the FINISHED event occurs.
> Mina Server is losing messages
> --
>
> Key: DIRMINA-1145
> URL: https://issues.apache.org/jira/browse/DIRMINA-1145
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.4
>Reporter: Guy Itzhaki
>Assignee: Jonathan Valliere
>Priority: Major
> Fix For: 2.2.0
>
> Attachments: DIRMINA-1145-EXAMPLE.zip,
> mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.2.0-SNAPSHOT.jar,
> mina_client_server.zip
>
>
> During our tests we found that in some circumstances Mina server loses
> messages.
> From what we understand this happens when client opens connection and then
> sends message(s) and the server is still busy processing the sessionOpened
> event while the message the client sent went through the server’s filterChain.
>
> Attached is a simple client and server that will help you reproduce the
> problem, before you run it please perform the following steps:
> *+Configuration:+*
> # In order to reproduce the problem SSL filter *must* be defined (already
> implemented in the attached example)
> # Update the keystore and truststore files locations in *addSSLFilter()*
> method in *MinaClient* and *MinaServer*
> # Set server break points at:
> # MinaServerHandler#sessionOpened
> # MinaServerHandler#messageReceived
> # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived
> # Set client break points at:
> # MinaClientHandler#sessionOpened
>
> *Since this is a timing problem you need to run a debugger as described
> below:*
> # Start server
> # Start client
> # At the client at *MinaClientHandler#sessionOpened* release the break point
> # Release all break points +except+ server’s
> *MinaServerHandler#sessionOpened*
> # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived
> completed to process all events, you can release
> *MinaServerHandler#sessionOpened*
>
> +*Expected result:*+
> MinaServerHandler#messageReceived will be invoked with the message sent by
> the client
> *+Actual result:+*
> MinaServerHandler#messageReceived is not invoked.
>
> To use the example, add the following jars to your class path:
> commons-lang3-3.9.jar
> log4j-api-2.13.3.jar
> log4j-core-2.13.3.jar
> log4j-jcl-2.13.3.jar
> mina-core-2.1.4.jar
> slf4j-api-1.7.26.jar
> spring-jcl-5.2.12.RELEASE.jar
>
> The java we use is *AdoptJDK 11.0.8*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Valliere updated DIRMINA-1145: --- Attachment: (was: DIRMINA-1145-EXAMPLE.zip) > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.2.0-SNAPSHOT.jar, > mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Valliere updated DIRMINA-1145: --- Attachment: DIRMINA-1145-EXAMPLE.zip > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.2.0-SNAPSHOT.jar, > mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Reopened] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Valliere reopened DIRMINA-1145: I think I can reproduce this now, working on it. > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.2.0-SNAPSHOT.jar, > mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17393049#comment-17393049 ] Jonathan Valliere edited comment on DIRMINA-1145 at 8/4/21, 11:45 AM: -- Please remove the idleness timeouts from your example project and try again. I had it fail once because it takes too long for the break point to release. Also, please set the logging level to DEBUG and post your console log. was (Author: johnnyv): Please remove the idleness timeouts from your example project and try again. I had it fail once because it takes too long for the break point to release. > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.2.0-SNAPSHOT.jar, > mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17393049#comment-17393049 ] Jonathan Valliere commented on DIRMINA-1145: Please remove the idleness timeouts from your example project and try again. I had it fail once because it takes too long for the break point to release. > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.2.0-SNAPSHOT.jar, > mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Valliere updated DIRMINA-1145: --- Attachment: mina-core-2.2.0-SNAPSHOT.jar > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.2.0-SNAPSHOT.jar, > mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17391606#comment-17391606 ] Jonathan Valliere commented on DIRMINA-1145: Sure thing [^mina-core-2.2.0-SNAPSHOT.jar] > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina-core-2.2.0-SNAPSHOT.jar, > mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17391280#comment-17391280 ] Jonathan Valliere commented on DIRMINA-1145: If it is still not working for you then you need to checkout bugfix/DIRMINA-1132 and rebase on 2.2.X. The 2.2.X branch contains the multi-threaded improvements for ProtocolCodecFilter. I just rebased bugfix/DIRMINA-1132 on 2.1.X in the repo so your rebase should be conflict free. > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17391173#comment-17391173 ] Jonathan Valliere commented on DIRMINA-1145: I just uploaded my example project using SSL2 (modified from the original version you used but works with portable locations for the trust and cert stores) > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Valliere updated DIRMINA-1145: --- Attachment: DIRMINA-1145-EXAMPLE.zip > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: DIRMINA-1145-EXAMPLE.zip, > mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1145) Mina Server is losing messages
[ https://issues.apache.org/jira/browse/DIRMINA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Valliere updated DIRMINA-1145: --- Attachment: (was: DIRMINA-1145.zip) > Mina Server is losing messages > -- > > Key: DIRMINA-1145 > URL: https://issues.apache.org/jira/browse/DIRMINA-1145 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.1.4 >Reporter: Guy Itzhaki >Assignee: Jonathan Valliere >Priority: Major > Fix For: 2.2.0 > > Attachments: mina-core-2.1.5-SNAPSHOT-ssl2.jar, mina_client_server.zip > > > During our tests we found that in some circumstances Mina server loses > messages. > From what we understand this happens when client opens connection and then > sends message(s) and the server is still busy processing the sessionOpened > event while the message the client sent went through the server’s filterChain. > > Attached is a simple client and server that will help you reproduce the > problem, before you run it please perform the following steps: > *+Configuration:+* > # In order to reproduce the problem SSL filter *must* be defined (already > implemented in the attached example) > # Update the keystore and truststore files locations in *addSSLFilter()* > method in *MinaClient* and *MinaServer* > # Set server break points at: > # MinaServerHandler#sessionOpened > # MinaServerHandler#messageReceived > # org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > # Set client break points at: > # MinaClientHandler#sessionOpened > > *Since this is a timing problem you need to run a debugger as described > below:* > # Start server > # Start client > # At the client at *MinaClientHandler#sessionOpened* release the break point > # Release all break points +except+ server’s > *MinaServerHandler#sessionOpened* > # After org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived > completed to process all events, you can release > *MinaServerHandler#sessionOpened* > > +*Expected result:*+ > MinaServerHandler#messageReceived will be invoked with the message sent by > the client > *+Actual result:+* > MinaServerHandler#messageReceived is not invoked. > > To use the example, add the following jars to your class path: > commons-lang3-3.9.jar > log4j-api-2.13.3.jar > log4j-core-2.13.3.jar > log4j-jcl-2.13.3.jar > mina-core-2.1.4.jar > slf4j-api-1.7.26.jar > spring-jcl-5.2.12.RELEASE.jar > > The java we use is *AdoptJDK 11.0.8* -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
