Hi Adrian, thanks for your response.

I'm currently running tests where I have a very fast producer and a
relatively slow consumer. The producer publishes persistent messages to a
topic, where the enqueue and dequeue count diverge fairly rapidly to a
difference of around 80,000 messages. The producer then gets whacked and the
enqueue graph in visualvm completely levels off. This is more or less
expected, as I've turned on producerFlowControl for topics. However, the
entire broker stalls. I have several queues that are filled and emptied at
the same time as the topic, and their dequeue/enqueue stats flatline as
well, even though flow control shouldn't apply to them. Thats why I was
interested to find out if you'd discovered some kind of fresh angle.
Regards,
Maarten

Adrian A wrote:
> 
> Hi Maarten
> 
> Kinda.
> 
> MapMessages are significantly more expensive but no real surprise there.
> 
> I upgraded the machine and did significant optimising on the GC, paying
> particular attention to parallel / conc mark sweep
> 
> eg
> -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing
> -XX:CMSIncrementalDutyCycleMin=0
> or
>  -XX:+UseParallelGC"
> or
> -XX:-UseParallelOldGC
> 
> I couldn't find any good info on what GC settings people have used for
> their platform.... but working with known test cases and measuring over
> multiple 10,000's tests helped to determine optimum settings on mine.
> 
> what are you seeing?
> 
> thanks
> 
> Adrian
> 
> 
> 
> Maarten_D wrote:
>> 
>> Hi Adrian,
>> Have you made any progress on this issue? I believe I'm running into the
>> same things occasionally.
>> Regards,
>> Maarten
>> 
>> 
>> Adrian A wrote:
>>> 
>>> Setting them to MapMessages (what I am using) makes it even worse:
>>> 
>>> //TextMessage message = session.createTextMessage(createMessageText(i));
>>> MapMessage message  = session.createMapMessage();
>>> message.setJMSType("blahasdadasdsd");
>>>             message.setLong("test1",2222);
>>>             message.setLong("test2",2222);
>>>             message.setLong("test3",2222);
>>>             message.setLong("test4",2222);
>>>             message.setLong("test5",2222);
>>> 
>>> by 10 to 20 times worse.
>>> 
>>> 
>>> Adrian A wrote:
>>>> 
>>>> long start = System.currentTimeMillis();
>>>> producer.send(message);
>>>> long stop = System.currentTimeMillis();
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Slow-sending-of-messages-tp26849964p27612143.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Reply via email to