I'd be interested as well.
I'm not using TTL, so I assumed my orphaned/non-sequence log files were due to
out of order message consumption, but I also see the occasional log file hang
around longer than expected. (say db-50.log then next is db-400.log, so big gap)
-Original Message-
Fr
are there now:
https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.4-SNAPSHOT/
thanks for the validation.
2010/1/26 Daniel Kluesing
> Any eta on the 5.4-snapshot? (
> https://repository.apache.org/content/repositories/snapshots/org/apache/ac
@gmail.com]
Sent: Thursday, January 21, 2010 9:42 AM
To: users@activemq.apache.org
Subject: Re: OOM with high KahaDB index time
Thanks Daniel! Though please wait for the next valid 5.4 build - looks
like its missing a dependency at the moment
On 21 Jan 2010, at 16:48, Daniel Kluesing wrote:
>
o the trunk and
ride Rob's patch.
Joe
Daniel Kluesing-2 wrote:
>
> I tried the suggestion of going with the default cursor, but I still get
> OOM errors. I've included my full config file below, I think I'm running
> fairly vanilla/default.
>
> After abou
t;;
brokerName="sub01chi" dataDirectory="${activemq.base}/data">
-Original Message-
From: Rob Davies [mailto:rajdav...@gmail.com]
Sent: Monday, January 18, 2010 10:42 PM
To: users@activemq.apache.org
Subject: Re: OOM with high KahaDB in
I'm happy to give 5.4-snapshot a try
-Original Message-
From: Rob Davies [mailto:rajdav...@gmail.com]
Sent: Wednesday, January 20, 2010 2:08 PM
To: users@activemq.apache.org
Subject: Re: OOM with high KahaDB index time
I have a potential fix for this problem - hoping someone will try out
Hi,
I'm running the 5.3 release as a standalone broker. In one case, a producer is
running without a consumer, producing small, persistent messages, with the
FileCursor pendingQueuePolicy (per
https://issues.apache.org/activemq/browse/AMQ-2512) option and flow control
memoryLimit set to 100mb
Hi,
I'm looking at ActiveMQ 5.3, with particular interest in the producer flow
control. Is there any way to have per-queue limits on the amount of disk space
a durable queue is using? I've seen the memory limit on the destination policy,
which looks to only apply to non-durable messages.
In ca
