Hi Tim,
sorry for the late response, but we spent the last days to make the
workaround working well.
My suggestion was that you subdivide your future messages based on time,
so
that only a small number of them are actually scheduled messages (and the
rest are normal messages, which the
Hi Kavin,
thanks for your input: we know that we stressed a lot the ActiveMQ
scheduling mechanism and consequently that we could incur in performance
degradation . What sound strange to us was:
- the fact that the performance degradation was for all ActiveMQ and not
only for the scheduled queue
-
Hi Tim,
your suggestion was one of the first tentative we perform: but the result
doesn't change. The problem seems very related to the use of the ActiveMQ
schedule-area with a great amount of messages.
At the moment, we are implementing a work-around based on persistence-queues
and application
Hi Tim,
thank you for your answer and support.
At the moment we moving in two different direction:
- from one side, we are analyzing deeply the issue it self, because we think
that the original architecture is the best choice and we would like to stay
sticky with it... but we know also that this
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
