AFAIK we need to set the redelivered flag. I remember reading it in a spec or something.
Sent from my mobile -- Asanka Abeyweera Software Engineer WSO2 Inc. Phone: +94 71 222 8648 On Mar 2, 2017 7:04 AM, "Hasitha Hiranya" <hasit...@wso2.com> wrote: > Hi Pamod and all, > > IMO, *we need both side's changes.* > > Andes client - when receover() is called, send reject to application > consumed messages, and clear internal buffer > Server - while recovering, do not increase redelivery count (do not > consider as a redelivery, as app has not consumed). Redelivery header flag > is not needed as well. > > Let us investigate and implement > > Thanks > > > On Wed, Mar 1, 2017 at 4:11 PM, Pamod Sylvester <pa...@wso2.com> wrote: > >> Hi All, >> >> Based on the issue mentioned in the $subject and described in [1] . >> Here's what we discussed, >> >> *Issue Summary* >> >> During an error, when recover() session is called by the consumer (i.e >> jms client/ESB), all unacked messages gets re-tried. This includes the >> messages which were received by the JMS consumer as well as the messages >> which were buffered in the client. >> >> As a result, the messages which were buffered in the client and which >> have not being received by the consumer get's diverted to the DLC after the >> retry count has being breached. >> >> *Problem Description* >> >> The could also be described as a gap between the AMQP and the JMS >> specifications. According to the AMQP the messages should be sent to the >> client as a batch. Though JMS provides a way to acknowledge messages >> individually. It doesn't provide a way to rollback an individual message. >> >> The only option is to recover the whole session, when the client choses >> to recover() the corresponding channel id of the client is sent to the >> broker, for it to recover all unacknowledged messages. When the server >> recovers unacked messages it will include the messages which were received >> by the JMS client as well messages which are buffered in the client and >> which were not received. >> >> *Proposed Solution* >> >> One way of solving this is through the following steps, >> >> *Andes client side changes * >> >> 1. When recover() is called from the client, distinguish the difference >> between the received messages and the messages which are buffered. We've >> done something similar for the rollback operation. >> 2. The messages which were received by the JMS client, could be >> explicitly rejected(). Sending a null ack for the message to the server. >> Since this messages need to be retried for the given number of times. >> 3. Once the rejection is sent the server will re-schedule the message >> until the max retry count is reached in the >> >> *server side changes* >> >> When session recover is called in the broker, >> >> *AndesSubscription.recoverMessages()* >> >> We could maintain a seperate flag for each *DeliverableAndesMetadata *object. >> So that when it's being re-scheduled for delivery, in the >> *MaximumNumOfDeliveryRule.evaluate() >> *would filter out these messages and will not increase the >> *maximumRedeliveryTimes >> *for the message. >> >> The above is one way we could solve the problem. Would there be any >> implications to it ? or will there be a better way of solving this? wdyt ? >> >> [1] https://wso2.org/jira/browse/MB-1887 >> >> Thanks, >> Pamod >> >> -- >> *Pamod Sylvester * >> >> *WSO2 Inc.; http://wso2.com <http://wso2.com>* >> cell: +94 77 7779495 <+94%2077%20777%209495> >> > > > > -- > *Hasitha Abeykoon* > Senior Software Engineer; WSO2, Inc.; http://wso2.com > *cell:* *+94 719363063* > *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> > >
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
