FWIW, it appears this commit [1] from 2013 is the one that changed the behavior as compared to Netty 4.0.39.Final which was used in Artemis 1.4.0. That commit is in every version of Netty 4.1 so it's not surprising you saw the same behavior using 4.1.12.Final.
As far as reverting back to a pre-4.1 version of Netty, I can't whether or not that would still work properly with Artemis. You can certainly give it a shot. Justin [1] https://github.com/netty/netty/commit/b533a1361bbbc457c974ca365f8293ec27ffda1c On Fri, Jun 30, 2017 at 4:22 PM, Justin Bertram <jbert...@redhat.com> wrote: > Is that the full stack-trace? I imagine there is something before the > call to org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl. > createSessionFactory(). > > Also, this Netty issue [1] looks similar. It involves a stack overflow > with Spring and java.security.SecureClassLoader.defineClass(). The > reporter apparently didn't provide a reproducible test-case. Do you have > an available test-case which reproduces this? > > > Justin > > [1] https://github.com/netty/netty/issues/6732 > > On Fri, Jun 30, 2017 at 3:53 PM, abhijith <topcoderabhij...@gmail.com> > wrote: > >> We have a load balancer in front on Artemis which does ssl offloading. To >> handle this we have custom ConnectionLoadBalancingPolicy. This policy >> determines which transport configuration to use for initial connection >> >> >> >> -- >> View this message in context: http://activemq.2283324.n4.nab >> ble.com/Artemis-v2-1-Spring-MessageListener-Netty-StackOve >> rflow-tp4728139p4728141.html >> Sent from the ActiveMQ - User mailing list archive at Nabble.com. >> > >
