[
https://issues.apache.org/jira/browse/QPID-6313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14277002#comment-14277002
]
Rob Godfrey commented on QPID-6313:
-----------------------------------
Essentially yes...
In prior versions the recover was a no-op... but would have prevented the
acknowledgement of the message. I presume at that point there is some
server-side lock timeout on Azure. After that timeout expires I further
presume that the Azure server increments the delivery count and looks for a
client that is waiting for messages, which will cause redlivery.
On trunk recover() will cause the messages which have been delivered but not
acknowledged (cached on the client) to be redelivered to the application by the
client. At the moment it appears to be taking the cahced message and
incrementing the dleivery count... which means that the delivery count never
goes above 1 + initial delivery count
> [AMQP 1.0] - Calling session.Recover() with CLIENT_ACKNOWLEDGE cached message
> -----------------------------------------------------------------------------
>
> Key: QPID-6313
> URL: https://issues.apache.org/jira/browse/QPID-6313
> Project: Qpid
> Issue Type: Bug
> Components: JMS AMQP 1.0 Client
> Affects Versions: Future
> Reporter: Mathias Wiberg
>
> Hi,
> I'm using Qpid 1.0 client to integrate with a Microsoft Azure bus. I've been
> using the latest version of Qpid (compiled today from trunk). The testcase is
> very simple:
> 1. One application sends a message to a queue, and another application starts
> a MessageListener.
> 2. In the onMessage method, the MessageId and DeliveryFailues variables are
> printed out. After this, the session is recover (session.recover()).
> When using version 0.28, and 0.30 each recovery would be printed each minute
> (pre-defined value in service bus for locking messages), and the
> deliveryCount property on the message would be increased by 1.
> When using version 0.32, each recovery is happening within ms of each other,
> and the deliveryCount property is the same for all (almost) messages. I can
> even disconnect the link between the client and the server and the
> MessageListener still prints out the messageId and DeliveryFailues. Therefor,
> it seems like there is some caching involved, or repeating the last sent
> message without notifying the broker.
> Here are some logstatements from my test application:
> [0.30]
> 2015-01-14T15:30:08.057 - Received message with JMSMessageID:
> ID:2581847573616249688, RedeliveryCount: 0
> 2015-01-14T15:31:08.094 - Received message with JMSMessageID:
> ID:2581847573616249688, RedeliveryCount: 1
> 2015-01-14T15:32:08.117 - Received message with JMSMessageID:
> ID:2581847573616249688, RedeliveryCount: 2
> [0.32]
> 2015-01-14T15:35:38.964 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 0
> 2015-01-14T15:35:38.979 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:38.979 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:38.979 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:38.979 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:38.979 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:38.995 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:38.995 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:38.995 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:38.995 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:38.995 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:38.995 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:38.995 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:38.995 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:38.995 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:38.995 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:38.995 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:38.995 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:38.995 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:39.011 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:39.011 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:39.011 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:39.011 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:39.011 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:39.011 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:39.011 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:39.011 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:39.011 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:39.011 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> 2015-01-14T15:35:39.011 - Received message with JMSMessageID:
> ID:907900209320220697, RedeliveryCount: 1
> Thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
