Does ActiveMQ have something between persistent and non persistent messages?
E.g.: messages are sent to the broker's memory and are lazily written to
disk if they start to overflow memory?
Ideally the behavior I'm looking for is the speed of nonpersistent messages
but if the consumers get backed
bump, would also like to know the answer to this
--
View this message in context:
http://activemq.2283324.n4.nabble.com/overflow-messages-to-disk-tp2357768p3040327.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Anyone have any idea whether this might be user error or a problem with
ActiveMQ? If it's the latter I can open a JIRA issue.
Thanks,
Jim
On 11/9/2010 5:19 PM, Jim Newsham wrote:
P.S. ActiveMQ 5.3.2, Camel 2.4.0. I'm running both embedded (i.e.,
starting up in Java code), and no custom
there is a open issue [1], is the virtual topic approach viable for you.
The fix will need some interface changes, so will need a major release.
[1] https://issues.apache.org/activemq/browse/AMQ-3003
On 12 November 2010 17:50, kroekle wrote:
>
> I'm having this same problem. Has anyone found a
I'm having this same problem. Has anyone found a workaround to this?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Dead-letter-queue-per-consumer-tp2366345p3040034.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
On Fri, Nov 12, 2010 at 4:01 PM, Neil Pritchard
wrote:
> I'm running a network of brokers on three different boxes (xml config below)
> using kaha for persistence. I will need to take one of the brokers out of
> the network and decommission the hardware permanently, it will be replaced
> with
I'm running a network of brokers on three different boxes (xml config below)
using kaha for persistence. I will need to take one of the brokers out of the
network and decommission the hardware permanently, it will be replaced with new
hardware at a later date. Each box has a producer and consu
