Hi Harald, First off, I would be hesitant to have multiple SJMS projects. We want to take everyones good work to build a better product overall while keeping Camel as simple and easy to use as possible.
WRT your question, SJMS was built to live in any environment. It does have its own built in Connection Pool management but it is also pluggable. What I would like to see is the JBoss JCA connection pool extension to the project if possible. Checkout the Pluggable Connection Resource Management section of the document. WRT the session issue, SJMS is optimized for best practices. One of those is that we try not to close connections or sessions after every call. In a custom JBoss Connection Plugin you will want to do a JNDI lookup and hold the reference to the connection. With all that said there are definite ways to improve the handling of connections in SJMS. We just need to do it in a way that is as simple and performant as possible. Thanks, Scott ES On Mon, Nov 11, 2013 at 2:35 AM, Harald Wellmann <[email protected]>wrote: > As a proof of concept, I created a new component camel-sjmsee as a > simplified version of camel-sjms: > https://github.com/hwellmann/camel/tree/sjmsee/components/camel-sjmsee > > Given that a Java EE container provides connection pools anyway, this > component does not pool any connections, producers or InOut reply consumers > but creates them on the fly (closing a managed connection simply returns it > to the container-managed pool). There is still a pool for ordinary > consumers. Each consumer registers an exception listener on its connection > which removes the consumer from the pool when an exception occurs. There is > a reconnect task submitted to the consumer's executor which tries to refill > the pool every 10 seconds. > > I've tested this manually on JBoss AS 7.2.0 in the context of my > application. I can now stop and restart the external ActiveMQ broker, and > communication is restored automatically. > > If this approach makes sense, I'm happy to improve it and make an official > contribution. My main question is whether or not this should be a separate > component or be integrated into camel-sjms somehow. > > Feedback welcome. > > Best regards, > Harald > > > 2013/11/9 Harald Wellmann <[email protected]> > > > Ok, I'll watch that issue. > > > > Broadening the scope of the discussion a bit, is SJMS designed for Java > > SE, Java EE or both? > > > > In a Java EE 6/7 server, you get managed connections from a JCA resource > > adapter, pooling and reconnection is provided by the container, so > there's > > no need to add reconnection to SJMS, and the pooling implemented in SJMS > > may be either redundant or even in conflict with connection pooling in > the > > container. > > > > Would it make sense to implement Java EE-optimized behaviour in > > camel-sjms, activated by a bunch of new options? > > > > Or would this be a case for a new camel-jmsee component? > > > > Regads, > > Harald > > > > Am 09.11.2013 17:33, schrieb Raul Kripalani: > > > > Yes, exactly. JIRA: https://issues.apache.org/jira/browse/CAMEL-6950. > >> > >> > > > -- -- Scott England-Sullivan Apache Camel Committer Principal Consultant / Sr. Architect | Red Hat, Inc. FuseSource is now part of Red Hat Web: fusesource.com <http://www.fusesource.com> | redhat.com<http://www.redhat.com> Blog: sully6768.blogspot.com Twitter: sully6768
