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

Reply via email to