On Thu, Nov 14, 2013 at 1:50 AM, Scott England-Sullivan <[email protected]> wrote: > 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. >
Yes I agree with Scott that camel-sjms should be container agnostic and only rely on the JMS API. > > 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 -- Claus Ibsen ----------------- Red Hat, Inc. Email: [email protected] Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
