activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Konkov <>
Subject Trouble with message prioritization and JDBC
Date Thu, 15 Dec 2011 11:43:44 GMT

We are implementing internal notification system for our customer. On some point we have requirement
to implement message prioritization. The simplest way, in my opinion, is to use JMS message
prioritization feature describer in this doc:

In our case sender and reciever is Camel routes. On reviewer side we have 1 conduming endpoing
with 2 or more concurrent consumers. In the reciever route we do routing and balancing of
messages between external service providers. We can't use many separate endpoints with selective
consumers to implement prioritization, because of implementation logic in balancer.

We have stand alone Activemq broker for supporting our notification gate. For persistence
we try 2 options:

1. Plain JDBC:

After some threshold of queue size (about 6000msg) hi priority messages stoped to dispatch.
Even after all low priority messages dispatched ! We are see not dispatched messages through
web console and JMX. Restarging the broker will dispatch messages.
Similar to described in that bug:

In searching of solution we try to use journaled JDBC...

2. Journaled JDBC:


                <policyEntry memoryLimit="1mb" producerFlowControl="true" topic="&gt;">
                <policyEntry queue="&gt;" memoryLimit="10mb" prioritizedMessages="true"
producerFlowControl="true"  maxAuditDepth="100000">
            <managementContext createConnector="true"/>

            <journalPersistenceAdapterFactory dataDirectory="${activemq.base}/data" journalLogFiles="5"

After 2200 msgs in queue messages are dispatched without prioritization at all. But the is
no stacked messages. After queue size is down to 2200 and less prioritization is restored
to expected.
Changing log size and other documented params of broker do not resolve issue :(

For both variants we are tried all versions from: 5.4.* to latest 5.5.* incude FUSE Source
Situation 100% reproducible.

Please, help with that... Actualy we already in production with variant 2 and must constantly
tune consuming speed to not exceed 2000 msgs in queue.

P.S.: currently we are investigating that ticket
. Can it be relevant ?

Vladimir Konkov
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message