activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Davies (JIRA)" <>
Subject [jira] Resolved: (AMQ-1081) Ack range checking, etc.
Date Wed, 01 Aug 2007 11:42:49 GMT


Rob Davies resolved AMQ-1081.

       Resolution: Fixed
    Fix Version/s: 5.0.0
         Assignee: Rob Davies

> Ack range checking, etc.
> ------------------------
>                 Key: AMQ-1081
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.0.0
>            Reporter:
>            Assignee: Rob Davies
>             Fix For: 5.0.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.
You can reply to this email to add a comment to the issue online.

View raw message