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 <[email protected]> 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 > -- *Hasitha Abeykoon* Senior Software Engineer; WSO2, Inc.; http://wso2.com *cell:* *+94 719363063* *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
