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
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
