I have found one thing in the PooledSession that is probably worth
keeping in a Cache. The Consumer which waits for reply messages. At the
moment in the JMSConduit a request is sent out then the thread waits
synchronously for a reply on the consumer of the pooled session.
Wouldn´t it be
Actually, one more note:
He STRONGLY suggests not writing any JMS code in the JMS transport at all:
jstrachan dkulp: don't even think of writing any JMS code within cxf, just
use spring message listener container
jstrachan you can configure the spring JMS stuff however you want
jstrachan we
Guillaume Nodet schrieb:
The Spring JMS layer contains two parts: the JmsTemplate which can be
used to send / consume messages, and the MessageListenerContainers
that can be used to consumer messages more efficiently. Caching is
configurable on the DefaultMessageListenerContainer, but the
Commons-pool is not a JMS connection pool.
I was mostly thinking about the ActiveMQ one, but i think each JMS
provider should have its own connection pool. In a Java EE
environment, the connection pool is done by the server and you don't
have to think about it. Anyway, it's part of the
Guillaume Nodet schrieb:
Commons-pool is not a JMS connection pool.
I was mostly thinking about the ActiveMQ one, but i think each JMS
provider should have its own connection pool. In a Java EE
environment, the connection pool is done by the server and you don't
have to think about it. Anyway,
Hi Christian,
comments inline...
-- Ulhas
Christian Schneider wrote:
Guillaume Nodet schrieb:
Commons-pool is not a JMS connection pool.
I was mostly thinking about the ActiveMQ one, but i think each JMS
provider should have its own connection pool. In a Java EE
environment, the connection
Ulhas Bhole schrieb:
I think this behaviour is not implemented in any of the Connection
Pools I know.
So my question here is how would we implement this with a
JMSTemplate. Without any further configuration the JMSTemplate even
with SingleConnectionFactory would create a new Session,
