Torsten,
Thank you for your response. For your background, in my
application, the messages consist of indicators of the status of
progress toward a certain end state. My app just lights up buttons
in various colors depending on the status messages received. Thus,
in a strop and restart situation, the indicators are blank (unlit)
for (possibly) a long while until new messages are received.
This
is why I wanted messages redelivered.
However, Raul, Kripalani has pointed out in a similar thread that
ActiveMQ has a "Recovery Policy" that can be setup to allow message
redelivery for this kind of situation. So this is the solution that
I had been hoping for... that I can acknowledge messages, and yet
still get them redelivered upon client restart (up to a certain
amount of time or disk space).
Mark
On 8/13/2012 3:52 AM, Torsten Mielke-2
[via ActiveMQ] wrote:
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
[hidden email]
[hidden email]
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.
If you reply to this email, your
message will be added to the discussion below:
http://activemq.2283324.n4.nabble.com/The-dilemma-of-not-acknowledging-messages-tp4654973p4655038.html
To unsubscribe from The dilemma of not acknowledging messages, click
here .
NAML
--
View this message in context:
http://activemq.2283324.n4.nabble.com/The-dilemma-of-not-acknowledging-messages-tp4654973p4655043.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
