Ah - ok that's useful - I'll see if I can reproduce
cheers,
Rob
On 17 Feb 2007, at 18:48, Tom wrote:
Op zaterdag 17 februari 2007 19:07, schreef Rob Davies:
thank you!!
Rob,
I figured out that the SlowReceive1 junit test probably deadlocks
because the connection is shared between sender
Op zaterdag 17 februari 2007 19:07, schreef Rob Davies:
> thank you!!
>
Rob,
I figured out that the SlowReceive1 junit test probably deadlocks
because the connection is shared between sender and consumer.
So I rewrote the test and now the test runs to completion.
Halfway during the send the Pr
to DUPS_OK_ACKNOWLEDGE. We're doing some message selection with
string
and integer properties.
Cheers,
Albert
--
View this message in context: http://www.nabble.com/Blocking-on-
UsageManager.waitForSpace-again-tf3031460s2354.html#a9021999
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
t; usageMutex.wait();
>>
>> that is blocking on.
>>
>> Any thoughts? Is it wrong to produce straight from a message listener?
>>
>> By the way, I noticed that increasing the memory available to the
>> memory manager from 20 MB to 128 MB actually makes the application
>> block
>> sooner rather than later. I also experimented with some prefetch
>> policy
>> settings, but these don't make much of a difference. Currently, we're
>> simply using
>>
>> vm://localhost?broker.useJmx=true&broker.persistent=false
>>
>> as our broker URL.
>>
>> We're using topics throughout. Sessions' acknowledge modes are all set
>> to DUPS_OK_ACKNOWLEDGE. We're doing some message selection with string
>> and integer properties.
>>
>> Cheers,
>>
>> Albert
>
>
>
--
View this message in context:
http://www.nabble.com/Blocking-on-UsageManager.waitForSpace-again-tf3031460s2354.html#a9021999
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
