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 <hwellmann...@gmail.com> > 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. >> >> >
