You can use the activemq pooled connection factory to make pooling transparent to your session beans for message production, it should be a case of swapping ActiveMQConnectionFactory with PooledConnectionFactory where ever the jms resource is configured.
Alternatively, for short lived consumers, use a prefetch of 0 or 1 is best, because there is no point in prefetching messages if they will not be consumed. On 15 December 2010 13:44, robert.sl...@misys.com <robert.sl...@misys.com> wrote: > > I believe the cause of the EOFException and the blocking behaviour and > slowdown is caused by creating and closing connections for each read/write. > In the standalone j2se application I attached in an earlier post, each > thread creates a new connection for each request before closing down the > resources once it has written to or consumed from the queue. This produces > lots of EOFExceptions and the blocking/slowdown behaviour I outlined > earlier. If I modify the class to ensure that a single connection is used > for all requests from the producer thread and a single connection is shared > for all the requests from the consumer thread, this stops the slowdown and > the EOFExceptions are no longer thrown. Unfortunately, this is not a viable > approach for us, as our application uses stateless session beans, which may > be persisted by the container, therefore a new connection to the broker is > created and closed once used for each request. > > My question now is, what could be causing this delay/problem with opening > and closing lots of connections to the broker? Does ActiveMQ maintain a > connection pool internally - could it be maintenance of this pool causing > the delay? Is there some configuration that can be made to the broker which > may impact the behaviour of the connection handling? > > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Slow-throughput-after-several-hundred-messages-tp3082431p3089010.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > -- http://blog.garytully.com http://fusesource.com