activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco Zapletal <>
Subject Re: Strategy for browsing a DLQ containing a high number of (large) messages
Date Wed, 05 Dec 2012 14:55:52 GMT

On 05.12.2012 04:42, kimmking wrote:
> The first one may be a nice way.

I guess, (1) is the most problematic one in this case, since it does not 
support pagination and partial loading of messages as outlined below.

>   Pagination: count the queue size, view the section.
>   You neednt care about headers or whole messages.
Let's consider for example a DLQ containing 60 messages with a size of 
10MB each. If we have web-based administration tool, we have to care 
whether the full message is loaded during browsing and re-queuing or 
only the headers. In such case, (1) leads to serious issues

I would be happy to hear any further thoughts.



> From: Marco Zapletal [via ActiveMQ]
> Date: 2012-12-04 22:11
> To: kimmking
> Subject: Strategy for browsing a DLQ containing a high number of (large) messages
> Hi folks,
> I am thinking about an appropriate strategy for browsing the DLQ from a
> Web application, whereby it is assumed that the DLQ potentially contains
> a high number of (large) messages. Browsing should support pagination
> (similar to databases) as well as loading only the headers during
> browsing. Loading the full body should only take place when a single
> message is inspected. I can think of the following three alternatives
> and would be happy to hear your thoughts:
> 1) Browsing the DLQ directly via the (JMX) QueueBrowser. Pagination and
> loading only the headers is not supported. However, using the file-based
> cursor as suggested here
> (
> may circumvent a resource shortage problem for a certain number of messages.
> 2) Using the JDBC persistence. Advantages: This would allow to browse
> the underlying database directly. Disadvantage: JDBC must be used.
> 3) Moving all messages from the DLQ to a database using a short, custom
> Camel route. In this case, the DLQ is used as a kind of sink. The Camel
> route would be responsible for moving all messages to a database using
> JDBC/JPA. Advantages: KahaDB can be used. Browsing/Pagination of
> messages is supported by the underlying database. Disadvantages: Moving
> and potential re-queuing involves custom Camel code.
> I am personally tending to approach n°3 and I am looking forward to hear
> your opinions and/or other approaches for tackling this issue.
> Best regards,
> Marco
> If you reply to this email, your message will be added to the discussion below:
> To unsubscribe from ActiveMQ - User, click here.
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at

View raw message