Not for messages that were in the andes client consumer buffer without being actually consumed by the application.
On Thu, Mar 2, 2017 at 7:20 AM, Asanka Abeyweera <asank...@wso2.com> wrote: > 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> >> >> -- *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
