Gaurav-
We have redundant master/slave brokers, pretty beefy machines, 3120MB
allocated on the JVM.
Using in the producer side using PooledConnectionFactory (with a pool size
of 100, not sure of utilization, but thats held up so far)
If there was something else y
That's pretty good volume without pooling the connexn factory. I don't have
numbers just yet but it will be within an order of magnitude of that. Mind
sharing what message store you are using for persistence and the broker
topology.
Sent from my iPhone
On Jul 20, 2012, at 12:13, Jeremy Levy w
Thanks again for the quick response. That's good info. What volume of
messages are you processing? I'm doing about 25 million a day.
Jeremy
On Fri, Jul 20, 2012 at 2:54 PM, Gaurav Sharma
wrote:
> Connection factory is thread-safe, so, a single instance should be fine.
> Pooled connection facto
Connection factory is thread-safe, so, a single instance should be fine.
Pooled connection factory should help greatly. One other optimization I
added was to keep a concurrent LRU cache of DestinationViewMBean keyed off
of destination name because I am heavily relying on JMX for destination
lookups
Thanks Gaurav-
I'll give the Pooled Factory a try. What do you think about keeping once
instance of the connection factory around statically? I've played with
async sending with mixed results.
Jeremy
On Thu, Jul 19, 2012 at 7:53 PM, Gaurav Sharma
wrote:
> You might wanna use the PooledConnect
You might wanna use the PooledConnectionFactory wrapper with the
ActiveMQConnectionFactory. That's what I switched to too. If you have a
listener, you will have to leave the session open as well until msg delivery. I
am using mysql as the msg-store and nio connector transport to the broker.
Als
I suspect that the way I am currently producing messages within my
application server is wrong.
We using JBoss 5.1 with a standalone ActiveMQ 5.6.0 broker. In regards to
producing messages I am caching a static instance of the
ActiveMQConnectionFactory, everything else
Connection,Session,Destinat
