Can you point to to that thread ?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/LevelDB-Invalid-log-position-WARN-after-destroying-durable-subscriber-tp4688904p4689114.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
First of all thanks for responding to this thread.
Right, I did go through following post:-
http://activemq.2283324.n4.nabble.com/when-should-you-set-maxInactivityDuration-0-td4688281.html
But was wondering whether the setting of flag "keepAlive=true" helps in this
case, where wireFormat.maxInact
I’m looking at a way to decommission one queue and move the load to another
queue. But scheduled messages pose a problem. They are kind of hidden.
Is it possible to read all of them in one pass? a queue browser would work
but they aren’t exposed as queues.
--
Founder/CEO Spinn3r.com
Location
is there a jira for this. If not. please raise one so it gets on the radar
On 19 November 2014 at 17:35, Kevin Burton wrote:
> Right now scheduled messages only use KahaDb… not LevelDB… so even if you
> setup your instance for LevelDB the store is created as KahaDB.
>
> That means that if your bo
I suspect there’s a bad leveldb corruption bug that’s been present for a
while so I’m going to write a test to verify that it’s present.
… so I’m trying to write a test.
My idea is to write 1000 messages or so and keep consuming/producing more
and giving them unique counters.
If we lose some of
god. the performance of replicated levelDB seems horrible here.
On Tue, Dec 2, 2014 at 10:19 PM, khandelwalanuj wrote:
>
> I have done performance testing for kahadb, leveldb and replication
> leveldb.
> Details:
>
> *Scenario: *
> > ActiveMQ : 5.10
> > Machine : Unix
> > I tested performance by
I’ve started another thread for this. IE the Invalid log position thing.
I suspect it’s not a WARN but an ERROR.
Kevin
On Mon, Dec 15, 2014 at 11:10 PM, khandelwalanuj <
khandelwal.anu...@gmail.com> wrote:
>
> Hi,
>
> Using ActiveMQ 5.10.
> We are getting below warning messages after durable sub
I’m worried this is a sever LevelDB bug that’s been around for more than a
year without any fix…
https://issues.apache.org/jira/browse/AMQ-5300
seems to be relocated to log rolling and a restart. LevelDB ends up
corrupted if you restart it after the logs have rolled over. At least that
would exp
Hey. I have a similar configuration and I’m getting a ton of "No reader
available for position” messages as well as significant data loss on AMQ
restart.
It literally loses about 95% of the messages I enqueued..
On Wed, Dec 17, 2014 at 9:06 AM, Christian Grassi wrote:
>
> I have a 3 node 5.10 c
I’m trying to track down a bunch of concerning production bugs in ActiveMQ
that might be related.
The biggest problem I’m seeing is that on restart, it seems that we’re
losing a LARGE percentage of our messages.
We had about 7k in a queue, and on restart, it went down to almost zero.
I’m getting
Setting wireFormat.maxInactivityDuration=0 means you'll never detect that a
client has disappeared without closing the TCP socket cleanly; I'd be very
hesitant about making that change unless you actually need to. If you're
just trying to avoid getting those lines in your logs, I'm not sure that's
Hi there,
Following is my activemq.xml, configuration on production, please let me
know if this is good enough to handle production load. Additional
information is that we are not using cluster environment, hence one node is
running the service. And it's only one queque being used for our purpose
Fixing following issue:- WARN | Transport Connection to:
blockingQueue_1942843618 failed:
org.apache.activemq.transport.InactivityIOException: Channel was inactive
for too (>3) long
Made following change:-
activemq.xml:-
Client broker url:-
failover:(nio://127.0.0.1:61616?wireFormat.maxIna
13 matches
Mail list logo
