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: 4.2.0
Reporter: [EMAIL PROTECTED]
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.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
