You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Albert Strasheim <13...@sun.ac.za> on 2007/02/28 11:02:51 UTC

Kaha persistence/UsageManager.waitForSpace and fast producer/slow consumer again

Hello all/Rob

We're still having problems with Kaha persistence when running a fast 
producer/slow consumer.

The last time I ran our test, we saw that messages would arrive out of 
order, presumably when they were being retrieved from the Kaha store 
and sent out (since they were definately being sent in order). Rob, 
looks like you checked in a test for this kind of thing in revision 
512643? Were you seeing problems of this nature?

Having updated to revision 512643, when I run our test, it runs for 
about two seconds before the only remaining ActiveMQ Session Task 
thread hangs in UsageManager.waitForSpace.

Rob, could you give a summary of the broker/VM/application parameters 
that we should try to tweak to avoid this problem?

By the way, we're still seeing the exact same issues with the test case 
attached to the AMQ-1148 issue. Maybe the same parameters can be 
tweaked to make that test pass? In that case, we're trying to 
VMPendingSubscriberMessageStoragePolicy instead of having messages 
persisted to the Kaha store.

Thanks for any feedback.

Cheers,

Albert

Re: Kaha persistence/UsageManager.waitForSpace and fast producer/slow consumer again

Posted by Rob Davies <ra...@gmail.com>.
btw Albert - the test case attached to AMQ-1148 runs better if there  
are separate connections for the publishers and consumers.

cheers,

Rob

On 28 Feb 2007, at 10:02, Albert Strasheim wrote:

> Hello all/Rob
>
> We're still having problems with Kaha persistence when running a fast
> producer/slow consumer.
>
> The last time I ran our test, we saw that messages would arrive out of
> order, presumably when they were being retrieved from the Kaha store
> and sent out (since they were definately being sent in order). Rob,
> looks like you checked in a test for this kind of thing in revision
> 512643? Were you seeing problems of this nature?
>
> Having updated to revision 512643, when I run our test, it runs for
> about two seconds before the only remaining ActiveMQ Session Task
> thread hangs in UsageManager.waitForSpace.
>
> Rob, could you give a summary of the broker/VM/application parameters
> that we should try to tweak to avoid this problem?
>
> By the way, we're still seeing the exact same issues with the test  
> case
> attached to the AMQ-1148 issue. Maybe the same parameters can be
> tweaked to make that test pass? In that case, we're trying to
> VMPendingSubscriberMessageStoragePolicy instead of having messages
> persisted to the Kaha store.
>
> Thanks for any feedback.
>
> Cheers,
>
> Albert


Re: Kaha persistence/UsageManager.waitForSpace and fast producer/slow consumer again

Posted by Rob Davies <ra...@gmail.com>.
Hi albert,

I'm just going to start using your test case and see if I can figure  
out whats going on

cheers,

Rob
On 28 Feb 2007, at 10:02, Albert Strasheim wrote:

> Hello all/Rob
>
> We're still having problems with Kaha persistence when running a fast
> producer/slow consumer.
>
> The last time I ran our test, we saw that messages would arrive out of
> order, presumably when they were being retrieved from the Kaha store
> and sent out (since they were definately being sent in order). Rob,
> looks like you checked in a test for this kind of thing in revision
> 512643? Were you seeing problems of this nature?
>
> Having updated to revision 512643, when I run our test, it runs for
> about two seconds before the only remaining ActiveMQ Session Task
> thread hangs in UsageManager.waitForSpace.
>
> Rob, could you give a summary of the broker/VM/application parameters
> that we should try to tweak to avoid this problem?
>
> By the way, we're still seeing the exact same issues with the test  
> case
> attached to the AMQ-1148 issue. Maybe the same parameters can be
> tweaked to make that test pass? In that case, we're trying to
> VMPendingSubscriberMessageStoragePolicy instead of having messages
> persisted to the Kaha store.
>
> Thanks for any feedback.
>
> Cheers,
>
> Albert