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 msgs.
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 msgs.
(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
tors...@fusesource.com
tmie...@blogspot.com
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 ${activemq.data}/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:
> http://activemq.2283324.n4.nabble.com/The-dilemma-of-not-acknowledging-messages-tp4654973.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
