activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From " (JIRA)" <>
Subject [jira] Created: (AMQ-1081) Ack range checking, etc.
Date Fri, 01 Dec 2006 03:07:02 GMT
Ack range checking, etc.

                 Key: AMQ-1081
             Project: ActiveMQ
          Issue Type: Bug
          Components: Broker
    Affects Versions: 4.2.0

I'm not sure if this is serious; if not please reduce its severity.

There seem to be some confusing things happening with acknowledgments.

1. does a "range check" on the acknowledgement.  However, when the
acknowledgment gets to the JDBC or Memory TOPIC store (possibly other stores as well), it
is assumed that all acknowledgements up to the last are counted.  This seems to suggest that
the "first" part of the range should NOT be verified for >= (in other words, it should
acknowledge everything from the beginning of the dispatched LinkedList to ack.getLastMessageId
-- this means taking out the inAckRange variable, or acting like it is always true).  I believe
this may need to happen ONLY when the prefetch is doing a topic (DurableTopicSubscription)
, not a queue (QueueSubscription), but I'm totally not sure.

2. When kahaadaptor.KahaTopicMessageStore is called to do an acknowledge, it blindly does
a removeFirst on the container, and never uses the MessageId parameter to do anything.  I
believe it should do a getFirst, verify that that the MessageId of the ConsumerMessageRef
matches the parameter, if it does not match, cancel the acknowledgement (not clear how to
do this because the PrefetchSubscription.acknowledge has already done work).  In any event,
crashing the subscription might be better than risking goofing up which messages have been
acknowledged. (Another possibility is to walk the LinkedList looking for a match, but this
doesn't seem to make sense given how PrefetchSubscription tracks the acknowledgments; I haven't
fully thought this through).

3. Looks like is ignoring all of the ID info in the ack parameter (this
is the non-durable subscriber case).  Is this right?  Seems like client could just send extraneous
ack messages with arbitrary IDs on a non-durable subscription and goof this up.

4.  In either durable or non-durable case, attempt by the client to ack out of sequence should
error out on the client and not mess up any of the subscription state.  Most worried about
the case where the messageis > than what has been delivered, not sure if the < case
is a problem as long as it is just ignored without impact (which certainly does not look like
the current impl in; not sure about  It
looks like this isn't being enforced, or did I miss something?

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message