[
https://issues.apache.org/jira/browse/AMQ-4850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13838742#comment-13838742
]
Amichai Rothman commented on AMQ-4850:
--------------------------------------
I'm running with Equinox rather than Felix as the OSGi engine in Karaf, which
might explain the different classloaders, and maybe the issue only happens with
one and not the other. I'm using Equinox since I've hit some other unrelated
issues using Felix, and in any case ActiveMQ should work with both.
As for the threading:
- The messaging bundle has an abstract Session class that does a simple new
Thread(...) in it's init() method.
- The thread's ContextClassLoader is not modified.
- It has a corresponding destroy() method which interrupts and joins the
thread, so I believe it is properly closed across bundle restarts.
- The whole Session implementation (and messaging bundle) uses clean JMS APIs,
nothing AMQ-specific.
- The bus bundle has an ActiveMQSession subclass of Session.
- The ActiveMQSession is created in a blueprint configuration, which binds
init-method to init() and destroy-method to destroy(). So that's basically the
root of the thread's lifecycle.
- The subclass only overrides a createConnection() method for creating an
AMQ-specific connection using ActiveMQConnectionFactory. It doesn't change or
add anything else on top of Session.
- There is another bundle which similarly subclasses Session for creating
Websphere MQ connections. It works properly, and is not running during these
AMQ tests (I'm only mentioning it to explain the design which supports multiple
MQ/JMS implementations via subclassing of Session in different bundles, and to
show that it works ok with other provider implementations).
I hope I answered all the questions :-)
Thanks for taking the time to look into this!
> NoClassDefFoundError: javax/net/ssl/SSLServerSocket (in Karaf)
> --------------------------------------------------------------
>
> Key: AMQ-4850
> URL: https://issues.apache.org/jira/browse/AMQ-4850
> Project: ActiveMQ
> Issue Type: Bug
> Components: OSGi/Karaf
> Affects Versions: 5.9.0
> Environment: Oracle JDK 7u45, Karaf 2.3.3 with activemq-broker
> installed from 5.9.0 feature
> Reporter: Amichai Rothman
> Assignee: Jean-Baptiste Onofré
>
> I couldn't find a way to recreate this consistently, but after repeating
> several times the following steps reproduce it:
> 1. Install custom Karaf 2.3.3 from scratch. Customizations include installing
> the activemq-broker feature using the featuresBoot configuration (along with
> a couple other unrelated features), and a dozen or so of my application's
> bundles in the deploy folder.
> 2. Start Karaf - everything works fine.
> 3. Shut down Karaf.
> 4. Touch my application's 'common' bundle (in deploy folder). The other
> application bundles depend on this one. This is *not* the bundle that uses
> ActiveMQ.
> 5. Start Karaf - it first starts all the app bundles (the old version I
> think), then it picks up the modified bundle timestamp and restarts the app
> bundles in what appears to be arbitrary order. This usually works, but once
> in a while the app's 'bus' bundle (which connects to ActiveMQ) fails to start
> with this exception showing up in the logs.
> 6. Interestingly, restarting the app or activemq bundles, or even restarting
> Karaf itself, doesn't fix things - once it enters this invalid state, it
> seems to stay stuck in it and continues with the same exception and with the
> app unable to connect to ActiveMQ. However, if I shut down Karaf and once
> again touch my app's 'common' bundle in the deploy folder and then start up
> Karaf again, it restarts the app bundles and this time everything goes back
> to normal, with a successful connection to ActiveMQ. So it looks like while
> the first occurrence is not recreated consistently, this state is not just a
> runtime thing but remains persisted somehow for as long as the app bundle
> files aren't modified.
> Here is the stack trace:
> java.lang.NoClassDefFoundError: javax/net/ssl/SSLServerSocket
> at
> org.apache.activemq.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:163)
> at
> org.apache.activemq.util.IntrospectionSupport.setProperties(IntrospectionSupport.java:151)
> at
> org.apache.activemq.transport.failover.FailoverTransportFactory.createTransport(FailoverTransportFactory.java:74)
> at
> org.apache.activemq.transport.failover.FailoverTransportFactory.createTransport(FailoverTransportFactory.java:63)
> at
> org.apache.activemq.transport.failover.FailoverTransportFactory.doConnect(FailoverTransportFactory.java:38)
> at
> org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:64)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:258)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:273)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:246)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:186)
> ...
--
This message was sent by Atlassian JIRA
(v6.1#6144)
