Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
Le 29/06/2018 à 13:10, Guillaume Nodet a écrit : > Sorry for the delay. > I gave it another try and unfortunately, the problem persists with my local > build of 2.20-SNAPSHOT. Ah, crap :/ > I'll try to find a fix next week. Okiedo. What is surprizing is that I fixed the change you pointed, so it must be something different... -- Emmanuel Lecharny Symas.com directory.apache.org pEpkey.asc Description: application/pgp-keys
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
Sorry for the delay. I gave it another try and unfortunately, the problem persists with my local build of 2.20-SNAPSHOT. I'll try to find a fix next week. Le mar. 26 juin 2018 à 00:39, Emmanuel Lécharny a écrit : > > > Le 23/06/2018 à 01:40, Guillaume Nodet a écrit : > > Sorry, I've been on meetings the whole week. I'll give it a try on > monday. > > Hi Guillaume, > > any update ? > > Thanks ! > > -- > Emmanuel Lecharny > > Symas.com > directory.apache.org > > -- Guillaume Nodet
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
Le 23/06/2018 à 01:40, Guillaume Nodet a écrit : > Sorry, I've been on meetings the whole week. I'll give it a try on monday. Hi Guillaume, any update ? Thanks ! -- Emmanuel Lecharny Symas.com directory.apache.org pEpkey.asc Description: application/pgp-keys
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
Sorry, I've been on meetings the whole week. I'll give it a try on monday. Le ven. 22 juin 2018 à 10:12, Emmanuel Lécharny a écrit : > Hi Guillaume, > > I have reverted the change. Can you give it a try ? If it's ok, I can > cut a release right away. > > Thanks ! > > -- > Emmanuel Lecharny > > Symas.com > directory.apache.org > > -- Guillaume Nodet
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
I don’t think we should start from a blank page; we could always create a whole new project todo that. I think we will be doing our jobs If we can focus on improving pain points and stability. I don’t have a problem with SSL being a filter; In fact, it is the most flexible way to do it; just needs to be designed better. Not only is it overly complicated in implementation, there are several pieces of code which scream “this will probably cause a concurrent memory problem”. On Fri, Jun 22, 2018 at 8:54 AM, Emmanuel Lécharny wrote: > > > Le 22/06/2018 à 14:01, Jonathan Valliere a écrit : > > At what point is the SSL going to be redesigned and anyone using it will > be > > forced to update their code? > > Sadly, we have thousands of peope using MINA as it is. > > Mina 3.0 was an effort we started a few years ago to redesign this piece > of code. > > > > > Are we going to continue to support other projects which use internal > APIs > > or variables? > > I don't think any projects are using MINA internals. The change I > reverted was a mistake I did. The local variable name made it easy to > shot you in the foot, though. > > Seems like every good idea Emmanuel had was reverted for > > reasons from “using a private event you shouldn’t” to “not wanting to add > > an empty function handler”. Is there some official policy on > compatibility? > > The policy is : "do not break the API in 'fix' versions", aka the Z in > MINA-x.y.z > > This is why I forked a 2.1.0. We can play in this branch as much as we > like. > > Although I think it would be better to keep Y versions for added > features, still keeping the API ascendant compatible, and use a X update > for breaking the API. > > I do think we should do what you suggested : > - rename the 3.0 branch to something related to a coming future version > - really start from a blank page (which is what we did with the MINA 3.0 > effort, btw). > > FTR, MINA 3.0 was expected to keep the idea of filters, but the SSL part > was not designed as a filter. Also we wanted to have MINA handling > either non-blocking IO and also blocking IO, to make it a generic > framework, instead of being a NIO framework. > > The hard part are : > - obviously find people interested in being part of the effort in the > long term > - keeping some kind of the existing MINA logic > - simplifying the existing design which is, IMHO, way too complex > - remove as much contention as we can > > > That is a lot of work... > > -- > Emmanuel Lecharny > > Symas.com > directory.apache.org > >
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
Le 22/06/2018 à 14:01, Jonathan Valliere a écrit : > At what point is the SSL going to be redesigned and anyone using it will be > forced to update their code? Sadly, we have thousands of peope using MINA as it is. Mina 3.0 was an effort we started a few years ago to redesign this piece of code. > > Are we going to continue to support other projects which use internal APIs > or variables? I don't think any projects are using MINA internals. The change I reverted was a mistake I did. The local variable name made it easy to shot you in the foot, though. Seems like every good idea Emmanuel had was reverted for > reasons from “using a private event you shouldn’t” to “not wanting to add > an empty function handler”. Is there some official policy on compatibility? The policy is : "do not break the API in 'fix' versions", aka the Z in MINA-x.y.z This is why I forked a 2.1.0. We can play in this branch as much as we like. Although I think it would be better to keep Y versions for added features, still keeping the API ascendant compatible, and use a X update for breaking the API. I do think we should do what you suggested : - rename the 3.0 branch to something related to a coming future version - really start from a blank page (which is what we did with the MINA 3.0 effort, btw). FTR, MINA 3.0 was expected to keep the idea of filters, but the SSL part was not designed as a filter. Also we wanted to have MINA handling either non-blocking IO and also blocking IO, to make it a generic framework, instead of being a NIO framework. The hard part are : - obviously find people interested in being part of the effort in the long term - keeping some kind of the existing MINA logic - simplifying the existing design which is, IMHO, way too complex - remove as much contention as we can That is a lot of work... -- Emmanuel Lecharny Symas.com directory.apache.org pEpkey.asc Description: application/pgp-keys
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
At what point is the SSL going to be redesigned and anyone using it will be forced to update their code? Are we going to continue to support other projects which use internal APIs or variables? Seems like every good idea Emmanuel had was reverted for reasons from “using a private event you shouldn’t” to “not wanting to add an empty function handler”. Is there some official policy on compatibility? On Fri, Jun 22, 2018 at 4:12 AM Emmanuel Lécharny wrote: > Hi Guillaume, > > I have reverted the change. Can you give it a try ? If it's ok, I can > cut a release right away. > > Thanks ! > > -- > Emmanuel Lecharny > > Symas.com > directory.apache.org > >
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
Hi Guillaume, I have reverted the change. Can you give it a try ? If it's ok, I can cut a release right away. Thanks ! -- Emmanuel Lecharny Symas.com directory.apache.org pEpkey.asc Description: application/pgp-keys
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
Le 21/06/2018 à 18:30, Guillaume Nodet a écrit : > Sorry, my link does not work. > I pinned it down to the removal of the SslHandler#handshakeStatus variable. Ok, that makes more sense :-) Can you test a 2.0.19 with this change reverted ? I can easily cut a 2.0.20 fast. (makes me think that may cause the random failures in SSHD, btw). Thanks ! -- Emmanuel Lecharny Symas.com directory.apache.org
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
Sorry, my link does not work.
I pinned it down to the removal of the SslHandler#handshakeStatus variable.
Guillaume
Le jeu. 21 juin 2018 à 16:43, Emmanuel Lécharny a
écrit :
>
>
> Le 21/06/2018 à 12:42, Guillaume Nodet a écrit :
> > So I can't explain exactly why, but the problem comes from the removal of
> > the following variable:
> >
> >
> https://github.com/apache/mina/commit/60cb619b6f0a940e7a6b18c060158270c227255b#diff-e3418ff2f83464c155b780cdbfb9e4aaL754
>
> Hmmm...
>
>
> public final class StandardCharsets {
> ...
> public static final Charset UTF_8 = Charset.forName("UTF-8");
>
>
> There must be something else.
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
> --
Guillaume Nodet
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
Le 21/06/2018 à 12:42, Guillaume Nodet a écrit :
> So I can't explain exactly why, but the problem comes from the removal of
> the following variable:
>
> https://github.com/apache/mina/commit/60cb619b6f0a940e7a6b18c060158270c227255b#diff-e3418ff2f83464c155b780cdbfb9e4aaL754
Hmmm...
public final class StandardCharsets {
...
public static final Charset UTF_8 = Charset.forName("UTF-8");
There must be something else.
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
So I can't explain exactly why, but the problem comes from the removal of the following variable: https://github.com/apache/mina/commit/60cb619b6f0a940e7a6b18c060158270c227255b#diff-e3418ff2f83464c155b780cdbfb9e4aaL754 Le jeu. 21 juin 2018 à 10:47, Guillaume Nodet a écrit : > It looks like visper is receiving a duplicate message from mina or > something like that and thus is closing the session because it assumes a > protocol error. > The actual location is the following: > java.lang.Throwable > at > org.apache.vysper.xmpp.protocol.ProtocolWorker.processTLSEstablishedInternal(ProtocolWorker.java:206) > at > org.apache.vysper.xmpp.protocol.QueuedStanzaProcessor.processTLSEstablished(QueuedStanzaProcessor.java:61) > at > org.apache.vysper.mina.XmppIoHandlerAdapter.messageReceivedNoStanza(XmppIoHandlerAdapter.java:82) > at > org.apache.vysper.mina.XmppIoHandlerAdapter.messageReceived(XmppIoHandlerAdapter.java:65) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:997) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114) > at > org.apache.vysper.mina.StanzaLoggingFilter.messageReceived(StanzaLoggingFilter.java:67) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114) > at > org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:236) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114) > at > org.apache.mina.filter.ssl.SslHandler.flushScheduledEvents(SslHandler.java:323) > at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:683) > at > org.apache.mina.filter.ssl.SslHandler.flushPreHandshakeEvents(SslHandler.java:286) > at org.apache.mina.filter.ssl.SslFilter.handleSslData(SslFilter.java:811) > at org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:533) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114) > at > org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:121) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:634) > 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:1242) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1231) > 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) > > I'm going to git bisect between 2.0.17 and 2.0.19 to see which commit is > the culprit. > > Le mer. 20 juin 2018 à 20:39, Emmanuel Lécharny a > écrit : > >> >> >> Le 20/06/2018 à 19:00, Guillaume Nodet a écrit : >> > So I've enabled debug logging which helps a bit. >> > https://gist.github.com/gnodet/04b08b1d19caa67359f352522774a70d >> > >> > I suspect a concurrent access to the byte buffer because the exception >> > should be thrown from the HeapByteBuffer#checkIndex instead of from >> > HeapByteBuffer#get. So I think there is a concurrent access which is >> > called between the call to checkIndex and the array access. >> > But this exception may be irrelevant as it's happening while handling >> > another exception which is >> >
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
It looks like visper is receiving a duplicate message from mina or something like that and thus is closing the session because it assumes a protocol error. The actual location is the following: java.lang.Throwable at org.apache.vysper.xmpp.protocol.ProtocolWorker.processTLSEstablishedInternal(ProtocolWorker.java:206) at org.apache.vysper.xmpp.protocol.QueuedStanzaProcessor.processTLSEstablished(QueuedStanzaProcessor.java:61) at org.apache.vysper.mina.XmppIoHandlerAdapter.messageReceivedNoStanza(XmppIoHandlerAdapter.java:82) at org.apache.vysper.mina.XmppIoHandlerAdapter.messageReceived(XmppIoHandlerAdapter.java:65) at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:997) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114) at org.apache.vysper.mina.StanzaLoggingFilter.messageReceived(StanzaLoggingFilter.java:67) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114) at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:236) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114) at org.apache.mina.filter.ssl.SslHandler.flushScheduledEvents(SslHandler.java:323) at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:683) at org.apache.mina.filter.ssl.SslHandler.flushPreHandshakeEvents(SslHandler.java:286) at org.apache.mina.filter.ssl.SslFilter.handleSslData(SslFilter.java:811) at org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:533) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114) at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:121) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:634) 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:1242) at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1231) 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) I'm going to git bisect between 2.0.17 and 2.0.19 to see which commit is the culprit. Le mer. 20 juin 2018 à 20:39, Emmanuel Lécharny a écrit : > > > Le 20/06/2018 à 19:00, Guillaume Nodet a écrit : > > So I've enabled debug logging which helps a bit. > > https://gist.github.com/gnodet/04b08b1d19caa67359f352522774a70d > > > > I suspect a concurrent access to the byte buffer because the exception > > should be thrown from the HeapByteBuffer#checkIndex instead of from > > HeapByteBuffer#get. So I think there is a concurrent access which is > > called between the call to checkIndex and the array access. > > But this exception may be irrelevant as it's happening while handling > > another exception which is > > org.apache.mina.core.write.WriteToClosedSessionException > > > > While debugging, I noticed that during the call to isCloseNotify, the > > IoBuffer is at the end, so not sure that this is expected by the code. > > Looking at the logs, what I see is that the apps is sending a message : > > 2018-06-20 18:51:59,863 [NioProcessor-2 ] DEBUG SslFilter > - Session Server[1](SSL): Writing Message : WriteRequest: > HeapBuffer[pos=0 lim=177 cap=256: 3C 3F 78 6D 6C 20 76 65 72 73 69 6F 6E >
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
Le 20/06/2018 à 19:00, Guillaume Nodet a écrit : > So I've enabled debug logging which helps a bit. > https://gist.github.com/gnodet/04b08b1d19caa67359f352522774a70d > > I suspect a concurrent access to the byte buffer because the exception > should be thrown from the HeapByteBuffer#checkIndex instead of from > HeapByteBuffer#get. So I think there is a concurrent access which is > called between the call to checkIndex and the array access. > But this exception may be irrelevant as it's happening while handling > another exception which is > org.apache.mina.core.write.WriteToClosedSessionException > > While debugging, I noticed that during the call to isCloseNotify, the > IoBuffer is at the end, so not sure that this is expected by the code. Looking at the logs, what I see is that the apps is sending a message : 2018-06-20 18:51:59,863 [NioProcessor-2 ] DEBUG SslFilter - Session Server[1](SSL): Writing Message : WriteRequest: HeapBuffer[pos=0 lim=177 cap=256: 3C 3F 78 6D 6C 20 76 65 72 73 69 6F 6E 3D 22 31 2E 30 22 20 65 6E 63 6F 64 69 6E 67 3D 22 55 54 46 2D 38 22 3F 3E 3C 65 72 72 6F 72 20 78 6D 6C 6E 73 3D 22 75 72 6E 3A 69 65 74 66 3A 70 61 72 61 6D 73 3A 78 6D 6C 3A 6E 73 3A 78 6D 70 70 2D 73 74 72 65 61 6D 73 22 3E 3C 62 61 64 2D 66 6F 72 6D 61 74 3E 3C 2F 62 61 64 2D 66 6F 72 6D 61 74 3E 3C 74 65 78 74 20 78 6D 6C 3A 6C 61 6E 67 3D 22 65 6E 5F 55 53 22 3E 63 6F 75 6C 64 20 6E 6F 74 20 70 72 6F 63 65 73 73 20 69 6E 63 6F 6D 69 6E 67 20 73 74 61 6E 7A 61 3C 2F 74 65 78 74 3E...] ie "could not process incoming stanza" then it closes the session: 2018-06-20 18:51:59,864 [NioProcessor-2 ] INFO MinaBackedSessionContext - session will be closed now Now, what happens is that MINA will try to flush the pending messages, which leads to errors. What need to be analyzed is why we get a IndexOutOfBoundsException, but regardless, it's teh app that has closed the connection, MINA is not responsible for that. Unless the error message is a direct consequence of a MINA failure... -- Emmanuel Lecharny Symas.com directory.apache.org
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
So I've enabled debug logging which helps a bit. https://gist.github.com/gnodet/04b08b1d19caa67359f352522774a70d I suspect a concurrent access to the byte buffer because the exception should be thrown from the HeapByteBuffer#checkIndex instead of from HeapByteBuffer#get. So I think there is a concurrent access which is called between the call to checkIndex and the array access. But this exception may be irrelevant as it's happening while handling another exception which is org.apache.mina.core.write.WriteToClosedSessionException While debugging, I noticed that during the call to isCloseNotify, the IoBuffer is at the end, so not sure that this is expected by the code. Le mer. 20 juin 2018 à 17:59, Emmanuel Lécharny a écrit : > > > Le 20/06/2018 à 17:29, Guillaume Nodet a écrit : > > Here it is: > >https://gist.github.com/gnodet/e2f63e474965ba4d02e9625a1c69cbb5 > > There is some message : > > Padded plaintext before ENCRYPTION: len = 240 > : 2A 74 62 52 BC 59 24 C5 82 77 DB B3 B6 70 E6 D0 *tbR.Y$..w...p.. > 0010: 3C 3F 78 6D 6C 20 76 65 72 73 69 6F 6E 3D 22 31 0020: 2E 30 22 20 65 6E 63 6F 64 69 6E 67 3D 22 55 54 .0" encoding="UT > 0030: 46 2D 38 22 3F 3E 3C 65 72 72 6F 72 20 78 6D 6C F-8"?> 0040: 6E 73 3D 22 75 72 6E 3A 69 65 74 66 3A 70 61 72 ns="urn:ietf:par > 0050: 61 6D 73 3A 78 6D 6C 3A 6E 73 3A 78 6D 70 70 2D ams:xml:ns:xmpp- > 0060: 73 74 72 65 61 6D 73 22 3E 3C 62 61 64 2D 66 6F streams"> 0070: 72 6D 61 74 3E 3C 2F 62 61 64 2D 66 6F 72 6D 61 rmat> 0080: 74 3E 3C 74 65 78 74 20 78 6D 6C 3A 6C 61 6E 67 t> 0090: 3D 22 65 6E 5F 55 53 22 3E 63 6F 75 6C 64 20 6E ="en_US">could n > 00A0: 6F 74 20 70 72 6F 63 65 73 73 20 69 6E 63 6F 6D ot process incom > 00B0: 69 6E 67 20 73 74 61 6E 7A 61 3C 2F 74 65 78 74 ing stanza 00C0: 3E 28 A5 2F 6A 93 2E E7 B1 AA 46 6C D1 6D 51 70 >(./j.Fl.mQp > 00D0: 33 92 83 AF A5 86 AA BD F5 89 66 5A 43 DB EC 8D 3.fZC... > 00E0: 61 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E a... > > > that might have cause one of the peer to close the connection, leading > to the error you get. > > In any case, the handshake has been properly handled, ending with a > FINISHED message on both side. > > What we see is : > > ... > NioProcessor-2, called closeInbound() > Smack Reader (0), received EOFException: error > Smack Reader (0), handling exception: > javax.net.ssl.SSLHandshakeException: Remote host closed connection > during handshake > NioProcessor-2, fatal error: 80: Inbound closed before receiving peer's > close_notify: possible truncation attack? > javax.net.ssl.SSLException: Inbound closed before receiving peer's > close_notify: possible truncation attack? > ... > > Could it be a problem in Camel ? > > > > > Le mer. 20 juin 2018 à 17:22, Emmanuel Lécharny a > > écrit : > > > >> I'd like to have the following test ran with -Djavax.net.debug=all > >> option set : > >> org.apache.camel.component.xmpp.XmppMultiUserChatTest.testXmppChat > >> > >> There is clearly some SSL weirdness going on... > >> > >> java.lang.RuntimeException: Could not connect to XMPP server: > >> localhost:5222/null > >> Caused by: org.jivesoftware.smack.SmackException: > >> javax.net.ssl.SSLHandshakeException: Remote host closed connection > >> during handshake > >> Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed > >> connection during handshake > >> Caused by: java.io.EOFException: SSL peer shut down incorrectly > >> > >> > >> Le 20/06/2018 à 14:50, Guillaume Nodet a écrit : > >>> It seems mina-core 2.0.19 contains changes that could cause SSL > problems > >> in > >>> the following camel tests. > >>> Any idea ? > >>> > >>> Guillaume > >>> > >>> -- Forwarded message - > >>> From: Pascal Schumacher > >>> Date: mar. 19 juin 2018 à 19:27 > >>> Subject: Upgrade to Mina 2.0.19 broke camel-xmpp tests > >>> To: d...@camel.apache.org > >>> > >>> > >>> Hi everybody, > >>> > >>> after the recent updated to Mina 2.0.19 four camel-xmpp tests are > broken: > >>> > >>> > >> > https://builds.apache.org/view/C/view/Apache%20Camel/job/Camel/job/master/411/testReport/junit/org.apache.camel.component.xmpp/ > >>> > >>> I can replicated this locally. Reverting commit > >>> 2b16d9b1c224e0d4b131f70017cf8010bb16edfe "Upgrade Mina to version > >>> 2.0.19" makes the tests pass again. > >>> > >>> No idea how to probably fix this, but I think we should fix this before > >>> releasing camel 2.22. > >>> > >>> Cheers, > >>> > >>> Pascal > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> -- > >> Emmanuel Lecharny > >> > >> Symas.com > >> directory.apache.org > >> > >> > > > > -- > Emmanuel Lecharny > > Symas.com > directory.apache.org > > -- Guillaume Nodet
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
Le mer. 20 juin 2018 à 18:09, Lyor Goldstein a écrit : > I believe CAMEL can simply choose to use mina-core 2.0.18 (since they have > the same API) by simply overriding its version in the CAMEL POM. > Yeah, I'm not reporting a problem for camel per se, the upgrade has been revert to 2.0.17 and it works. However, it's not really expected that the upgrade breaks existing tests. I'll try to investigate a bit. > Furthermore, since SSHD does not really need MINA, it can be configured to > use NIO2 and thus avoid dragging in the MINA dependency. > It's not using SSHD, just mina-core. -- Guillaume Nodet
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
Le 20/06/2018 à 18:09, Lyor Goldstein a écrit : > I believe CAMEL can simply choose to use mina-core 2.0.18 2.0.17. There is an API regression in 2.0.18 which has been solved in 2.0.19. -- Emmanuel Lecharny Symas.com directory.apache.org
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
I believe CAMEL can simply choose to use mina-core 2.0.18 (since they have the same API) by simply overriding its version in the CAMEL POM. Furthermore, since SSHD does not really need MINA, it can be configured to use NIO2 and thus avoid dragging in the MINA dependency.
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
Le 20/06/2018 à 17:29, Guillaume Nodet a écrit : > Here it is: >https://gist.github.com/gnodet/e2f63e474965ba4d02e9625a1c69cbb5 There is some message : Padded plaintext before ENCRYPTION: len = 240 : 2A 74 62 52 BC 59 24 C5 82 77 DB B3 B6 70 E6 D0 *tbR.Y$..w...p.. 0010: 3C 3F 78 6D 6C 20 76 65 72 73 69 6F 6E 3D 22 31 could n 00A0: 6F 74 20 70 72 6F 63 65 73 73 20 69 6E 63 6F 6D ot process incom 00B0: 69 6E 67 20 73 74 61 6E 7A 61 3C 2F 74 65 78 74 ing stanza(./j.Fl.mQp 00D0: 33 92 83 AF A5 86 AA BD F5 89 66 5A 43 DB EC 8D 3.fZC... 00E0: 61 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E a... that might have cause one of the peer to close the connection, leading to the error you get. In any case, the handshake has been properly handled, ending with a FINISHED message on both side. What we see is : ... NioProcessor-2, called closeInbound() Smack Reader (0), received EOFException: error Smack Reader (0), handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake NioProcessor-2, fatal error: 80: Inbound closed before receiving peer's close_notify: possible truncation attack? javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack? ... Could it be a problem in Camel ? > > Le mer. 20 juin 2018 à 17:22, Emmanuel Lécharny a > écrit : > >> I'd like to have the following test ran with -Djavax.net.debug=all >> option set : >> org.apache.camel.component.xmpp.XmppMultiUserChatTest.testXmppChat >> >> There is clearly some SSL weirdness going on... >> >> java.lang.RuntimeException: Could not connect to XMPP server: >> localhost:5222/null >> Caused by: org.jivesoftware.smack.SmackException: >> javax.net.ssl.SSLHandshakeException: Remote host closed connection >> during handshake >> Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed >> connection during handshake >> Caused by: java.io.EOFException: SSL peer shut down incorrectly >> >> >> Le 20/06/2018 à 14:50, Guillaume Nodet a écrit : >>> It seems mina-core 2.0.19 contains changes that could cause SSL problems >> in >>> the following camel tests. >>> Any idea ? >>> >>> Guillaume >>> >>> -- Forwarded message - >>> From: Pascal Schumacher >>> Date: mar. 19 juin 2018 à 19:27 >>> Subject: Upgrade to Mina 2.0.19 broke camel-xmpp tests >>> To: d...@camel.apache.org >>> >>> >>> Hi everybody, >>> >>> after the recent updated to Mina 2.0.19 four camel-xmpp tests are broken: >>> >>> >> https://builds.apache.org/view/C/view/Apache%20Camel/job/Camel/job/master/411/testReport/junit/org.apache.camel.component.xmpp/ >>> >>> I can replicated this locally. Reverting commit >>> 2b16d9b1c224e0d4b131f70017cf8010bb16edfe "Upgrade Mina to version >>> 2.0.19" makes the tests pass again. >>> >>> No idea how to probably fix this, but I think we should fix this before >>> releasing camel 2.22. >>> >>> Cheers, >>> >>> Pascal >>> >>> >>> >>> >>> >>> >> >> -- >> Emmanuel Lecharny >> >> Symas.com >> directory.apache.org >> >> > -- Emmanuel Lecharny Symas.com directory.apache.org
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
Here it is: https://gist.github.com/gnodet/e2f63e474965ba4d02e9625a1c69cbb5 Le mer. 20 juin 2018 à 17:22, Emmanuel Lécharny a écrit : > I'd like to have the following test ran with -Djavax.net.debug=all > option set : > org.apache.camel.component.xmpp.XmppMultiUserChatTest.testXmppChat > > There is clearly some SSL weirdness going on... > > java.lang.RuntimeException: Could not connect to XMPP server: > localhost:5222/null > Caused by: org.jivesoftware.smack.SmackException: > javax.net.ssl.SSLHandshakeException: Remote host closed connection > during handshake > Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed > connection during handshake > Caused by: java.io.EOFException: SSL peer shut down incorrectly > > > Le 20/06/2018 à 14:50, Guillaume Nodet a écrit : > > It seems mina-core 2.0.19 contains changes that could cause SSL problems > in > > the following camel tests. > > Any idea ? > > > > Guillaume > > > > -- Forwarded message - > > From: Pascal Schumacher > > Date: mar. 19 juin 2018 à 19:27 > > Subject: Upgrade to Mina 2.0.19 broke camel-xmpp tests > > To: d...@camel.apache.org > > > > > > Hi everybody, > > > > after the recent updated to Mina 2.0.19 four camel-xmpp tests are broken: > > > > > https://builds.apache.org/view/C/view/Apache%20Camel/job/Camel/job/master/411/testReport/junit/org.apache.camel.component.xmpp/ > > > > I can replicated this locally. Reverting commit > > 2b16d9b1c224e0d4b131f70017cf8010bb16edfe "Upgrade Mina to version > > 2.0.19" makes the tests pass again. > > > > No idea how to probably fix this, but I think we should fix this before > > releasing camel 2.22. > > > > Cheers, > > > > Pascal > > > > > > > > > > > > > > -- > Emmanuel Lecharny > > Symas.com > directory.apache.org > > -- Guillaume Nodet
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
I'd like to have the following test ran with -Djavax.net.debug=all option set : org.apache.camel.component.xmpp.XmppMultiUserChatTest.testXmppChat There is clearly some SSL weirdness going on... java.lang.RuntimeException: Could not connect to XMPP server: localhost:5222/null Caused by: org.jivesoftware.smack.SmackException: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake Caused by: java.io.EOFException: SSL peer shut down incorrectly Le 20/06/2018 à 14:50, Guillaume Nodet a écrit : > It seems mina-core 2.0.19 contains changes that could cause SSL problems in > the following camel tests. > Any idea ? > > Guillaume > > -- Forwarded message - > From: Pascal Schumacher > Date: mar. 19 juin 2018 à 19:27 > Subject: Upgrade to Mina 2.0.19 broke camel-xmpp tests > To: d...@camel.apache.org > > > Hi everybody, > > after the recent updated to Mina 2.0.19 four camel-xmpp tests are broken: > > https://builds.apache.org/view/C/view/Apache%20Camel/job/Camel/job/master/411/testReport/junit/org.apache.camel.component.xmpp/ > > I can replicated this locally. Reverting commit > 2b16d9b1c224e0d4b131f70017cf8010bb16edfe "Upgrade Mina to version > 2.0.19" makes the tests pass again. > > No idea how to probably fix this, but I think we should fix this before > releasing camel 2.22. > > Cheers, > > Pascal > > > > > > -- Emmanuel Lecharny Symas.com directory.apache.org
Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
It seems mina-core 2.0.19 contains changes that could cause SSL problems in the following camel tests. Any idea ? Guillaume -- Forwarded message - From: Pascal Schumacher Date: mar. 19 juin 2018 à 19:27 Subject: Upgrade to Mina 2.0.19 broke camel-xmpp tests To: d...@camel.apache.org Hi everybody, after the recent updated to Mina 2.0.19 four camel-xmpp tests are broken: https://builds.apache.org/view/C/view/Apache%20Camel/job/Camel/job/master/411/testReport/junit/org.apache.camel.component.xmpp/ I can replicated this locally. Reverting commit 2b16d9b1c224e0d4b131f70017cf8010bb16edfe "Upgrade Mina to version 2.0.19" makes the tests pass again. No idea how to probably fix this, but I think we should fix this before releasing camel 2.22. Cheers, Pascal -- Guillaume Nodet
