Wanted some feedback on this.
https://gist.github.com/burtonator/34a67c24ca9ce0574c04
I think I want to refactor the cancel method…
it calls purge() which is VERY expensive on large numbers of queues. N^2
expensive.
once the cancel() is called, the timer task won’t get executed, HOWEVER
there’s
I’m confused by something. Why don’t messages pile up in advisory topics?
Topics only deliver messages to consumers who are actually listening I
assume?
On Sat, May 2, 2015 at 2:07 PM, Kevin Burton wrote:
> I’m sorry.. this is N^2 because the Timer just keeps growing for every new
> queue and t
And it looks like these changes, along with setting expireMessagesPeriod=0
on advisory topics, dramatically improves performance. On small numbers of
queues (5k) it’s 100x. In large numbers it will be even higher.
On Sat, May 2, 2015 at 3:08 PM, Kevin Burton wrote:
> I’ve found 3 places where
I’ve found 3 places where CopyOnWriteArrayList was being used and causing
significant performance impact O(N^2) when using large numbers of queues.
Could I get feedback on these 3 changes?
https://github.com/spinn3r/activemq/commit/06ebfbf2a4d9201b57069644bdb7eb8274da0714
https://github.com/spin
OK. I’ve fixed 2-3 significant bugs in ActiveMQ with large numbers of
queues and degraded performance. Most of theses are O(N^2) bugs so the more
queues you have the more this becomes VERY painful.
I don’t have an easy fix of this one though.
Queue creation right now is about 3x slower than it co
Hi,
I came across a problem recently. The java program serves as message
producer and sends message to a queue. When the program is run in my
laptop(a windows machine), that message is logged in activemq logging and
shows in the queue when I look at the activemq web console(running in
linux). Howe
I’m sorry.. this is N^2 because the Timer just keeps growing for every new
queue and they need to be purged and it has to evaluate each one.
On Sat, May 2, 2015 at 1:40 PM, Kevin Burton wrote:
> Also, while this is a small performance boost in my example, this should
> have a massive impact when
Also, while this is a small performance boost in my example, this should
have a massive impact when running with large queues. It’s calling
Timer.purge() on each queue GC and if you have a lot of queues you’re going
to have a lot of TimerTasks so this is a O(N). It also holds a global lock
during
If you want your receive-response to be synchronous (the sender can't send
the second message till it receives the response message for the first
one), use the same thread. If you want to be asynchronous (each message
needs a response in within some timeout window, but you can send the second
and
I’m doing a bunch of performance analysis of ActiveMQ this weekend to see
if I can improve queue creation and destruction time. The good news is
that there are a lot of areas of optimization.
It looks like one is that advisory topics are created with the default
expireMessagesPeriod (which is 300
Also I get:
WARN | java.lang.NullPointerException
I think all the issue seems to happen when the producer is producing faster
than the consumer can consume. Initially the consumer keeps up, but when I
kill and restart the consumer, it slows down, likely since it is consuming
from the persistent
11 matches
Mail list logo
