activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Mielke <>
Subject Re: The dilemma of not acknowledging messages
Date Mon, 13 Aug 2012 07:51:43 GMT
Hello Mark,

You do have to acknowledge messages that you consume in your JMS clients.
There is no way you can run a broker reliably over a longer period of time without ever acking
any consumed messages.
As you already observe, the brokers journal files will be piling up and I would not be surprised
if you get into other side affects because of that.

A JMS broker's job is to move accept messages from a producer and pass them to a or more consumers.
Its the duty of the consumer to ack any messages it has processed. 
If you don't ack the messages and if your consumer disconnects and reconnects, your messages
will be redelivered and thus be processed twice. You generally don't want this behavior. 
But bottom line is it is wrong to not ack any messages that have been processed successfully
in your clients. 

I don't understand the reasoning why you don't want to ack msgs after they got processed by
your consumers, but I am fairly sure you need to find a different approach than not acking
Also, I cannot suggest deleting any of the brokers journal files manually while the broker
is running. I presume this could corrupt the persistence adapter entirely. 

For whatever your requirements are, find a different solution than not acking the consumed
(e.g. if you need to process some messages again at a later point in time, perhaps store these
msgs in a dedicated area of a database and have some other app process this db table and resubmit
these messages to the broker if necessary?)

Torsten Mielke

On Aug 9, 2012, at 8:17 PM, fenbers wrote:

> Greetings!
> I want unexpired JMS messages to be redelivered if my client application is
> stopped and restarted.  To accomplish this, I do not have the client
> acknowledge the receipt of messages.  An unfortunate side-effect of this
> practice is that the db-/N/.log files in the ${}/kahadb
> directory never get cleaned up, and after these build up to a few hundred in
> number, ActiveMQ starts affecting the performance of it clients (although I
> cannot yet tell if it is the producer part that's bogging down or the
> consumer part that's bogging down).  I did add  to activemq.xml, but
> commented out  and don't remember why, but this did cause some sort of
> problem when I last tried it over a year ago...
> As I see it, there are three ways to get around this problem.  I don't know
> if any of them are possible, and is what I am seeking advice about.  They
> are:
> 1) figure out a way to have unexpired messages redelivered even if they've
> been acknowledged.
> 2) figure out a way to have the delivered (but expired) messages purged even
> though they haven't been acknowledged by the client.  (Currently, if they
> are not acknowledged, they are marked "in-use" and the db-/N/.log files
> aren't cleaned up.)
> 3) occasionally delete the older db-/N/.log outside of ActiveMQ (say on
> cron, etc.), but will this cause ActiveMQ to behave improperly?
> Or is there a different way altogether?
> Mark
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at

View raw message