activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Burton <>
Subject Re: Performance degrade issue using ActiveMQ scheduler
Date Mon, 25 May 2015 21:40:05 GMT
One warning about using the activemq scheduler is that it requires the use
of KahaDB. It doesn’t yet support LevelDB (or replication).

So if you go down the scheduler path, you’re stuck with KahaDB…

At least for the foreseeable future.

On Thu, May 21, 2015 at 1:14 AM, contezero74 <> wrote:

> Hi Everyone,
> in one of our project we are suffering for ActiveMQ performance degrade
> when
> we use the schedule facility (enabling schedulerSupport in ActiveMQ
> configuration) with high amount of message (1M or more). We are, also,
> using
> Camel for route management.
> Our routes are configured as follow:
> - a producer P produces 800 messages/sec and send them through a non
> persistent ActiveMQ queue Q
> - a consumer C1 processes messages from Q according to the following rule:
> for each message it verifies if the message can be process immediately
> (every message has a time-window attribute to define that). If it can, it
> forwards the message to the Throttling queue T; if it cannot, it forwards
> the messages into a support queue S
> - a consumer Cs processes messages from S and it schedules the message
> according to its time-window (setting the ActiveMQ property
> ScheduledMessage.AMQ_SCHEDULED_DELAY with the following statement:
> "message.setLongProperty(ScheduledMessage.AMQ_SCHEDULED_DELAY, <delay>);")
> - when a scheduled message wakes up from the ActiveMQ scheduled area, it is
> forwarded to the Throttling queue T
> - the consumer Ct processes the message from T using a third parties
> component (TCP connection)
> When P produces messages for immediate processing (i.e., without
> time-window) the system performs well even with an high amount of messages
> (1M or more): monitoring the queue we can see them almost empty (no message
> stays pending in any queue).
> When P produces messages for delayed processing (i.e., with time-window) we
> see the following behavior:
> - we have messages pending in all the queues (Q and S), while we expect to
> have it only on the S queue
> - when the message scheduled in S wakes up they moves to the T queue: this
> messages are processed according to the throttling configuration (1K
> messages/sec)
> - the message still pending in Q and S are moved very slowly to T (around
> 50
> messages/sec)
> - in case we try a second round of messages (without time-window) produced
> by P, just after all the precious messages have been processed, we still
> sending out messages to 50 messages/sec
> Summary of the issue:
> * ActiveMQ version: 5.9.0 (configured with 3GB of max memory limit)
> * Camel version: 2.15.1
> * Spring version: 4.1.3.RELEASE
> * Critical route:
> * Without using scheduler: within 1M messages, we process easily 1K
> messages/sec (the limit depends from a Camel Throttling queue)
> * Using scheduler: within 1M messages, we process 50 messages/sec
> * Monitoring CPUs and memory usage, we cannot spot-out any issue: from 2%
> to
> 5% of CPUs usage and we never go out-of-memory (the Java GC seems works
> fine
> too=
> * Hardware: virtualized based on VMWare:
>    - CPUs: 24 vCPUs mapped on 'Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz'
>    - Ram: 31744MB
> cheers and thanks in advance for your help,
> Eros
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at


Location: *San Francisco, CA*
… or check out my Google+ profile

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message