Hi Dushan. Initially we planned to implement retry mechanism based on per message since current implementation only support for the single message per JMS session and once batch processing task has completed it should be batch retry.
Agreed with you. We should add optimization parameters like batch size as configuration parameter. Thanks. On Wed, Jul 8, 2015 at 5:52 AM, Dushan Abeyruwan <[email protected]> wrote: > HI > > On Tue, Jul 7, 2015 at 11:21 AM, Prabath Ariyarathna <[email protected]> > wrote: > >> Hi All, >> >> We are planning to implement guaranteed message delivery capability to >> the MSMP. We can divided current implementation into two basic sections >> based on process. >> >> 1. *Message Store:* Message store mainly responsible for producing >> messages to the message broker using message store mediator. >> 2. *Message process*: Message processor picks the messages from the >> message store and send to the specified endpoint. >> >> When we implement a guaranteed message delivery mechanism to the MSMP, we >> need to think about both of above scenarios. JMS specification provided us >> to two mechanisms(Acknowledgement, Transaction), which can be used to >> achieve guaranteed delivery. >> In our case message processor(consumer) side guaranteed delivery was >> already implemented using acknowledgements. Message processor ACK to the >> message store only if message was successfully processed. Message store >> removes the message once ACK received by the processor else redeliver the >> message, but for the message storing(producer) part, we don’t have any >> mechanism implemented to achieve this feature. Main intention of this >> implementation is to provide a way to handle guaranteed delivery for the >> message storing(producer) part. >> >> *Problem.* >> We don’t have mechanism to handle guaranteed delivery in message >> storing(producer) section. This issue can be occurred for following use >> cases. >> >> 1. Message was sent to the MB, but didn’t received to the MB side due >> to communication failure. >> 2. Message broker not available when try to store the message. >> >> >> *Solution.* >> We can choose either acknowledgement or transaction as a solution of >> guaranteed delivery implementation but since JMS 1.1 doesn't support for >> the producer acknowledgement, we decided to enable transaction support for >> the message storing section to provide guaranteed delivery. Other than the >> transactions enable in the message storing process, we planned to add retry >> mechanism to avoid scenario like message store is not available when we try >> to produce messages. User can define retry count and retry delay in the >> configuration of the store mediator. Message retry process is executing If >> message broker connection not available or transaction has already >> rollbacked. In addition to that features we are planning to add batch >> process facility to store mediator to improve performance, while enabling >> transactions as the future improvement. >> > > This sounds good however, any design that we could see how to achieve > this model, I guess we may have to re-design JMSStore to look-up messages > queued in then then dispatch (if connections ENV conditions are positive) > or will this retry is based on per message ? > > I guess Batch process might be the abstract implementation for retry so > batch count should be the variable and control post conditions .. > >> >> >> Thanks >> -- >> >> *Prabath Ariyarathna* >> >> *Associate Technical Lead* >> >> *WSO2, Inc. * >> >> *lean . enterprise . middleware * >> >> >> *Email: [email protected] <[email protected]>* >> >> *Blog: http://prabu-lk.blogspot.com <http://prabu-lk.blogspot.com>* >> >> *Flicker : https://www.flickr.com/photos/47759189@N08 >> <https://www.flickr.com/photos/47759189@N08>* >> >> *Mobile: +94 77 699 4730 * >> >> >> >> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Dushan Abeyruwan | Technical Lead > Technical Support-Bloomington US > PMC Member Apache Synpase > WSO2 Inc. http://wso2.com/ > Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>* > Mobile:(001)812-391-7441 > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Prabath Ariyarathna* *Associate Technical Lead* *WSO2, Inc. * *lean . enterprise . middleware * *Email: [email protected] <[email protected]>* *Blog: http://prabu-lk.blogspot.com <http://prabu-lk.blogspot.com>* *Flicker : https://www.flickr.com/photos/47759189@N08 <https://www.flickr.com/photos/47759189@N08>* *Mobile: +94 77 699 4730 *
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
