[
https://issues.apache.org/activemq/browse/AMQ-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Davies resolved AMQ-1081.
-----------------------------
Resolution: Fixed
Fix Version/s: 5.0.0
Assignee: Rob Davies
> Ack range checking, etc.
> ------------------------
>
> Key: AMQ-1081
> URL: https://issues.apache.org/activemq/browse/AMQ-1081
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.0.0
> Reporter: [EMAIL PROTECTED]
> 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. PrefetchSubscription.java 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 TopicSubscription.java 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 TopicSubscription.java; not sure about PrefetchSubscription.java).
> 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.
