Hi Prabath,
On Tue, Jul 7, 2015 at 6:21 PM, 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. > How do you really going to implement the retry feature ? Will the retry happen using the same thread or will you be creating a separate thread for it ? > > > 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 * > > > > > > -- Regards, *Shafreen* Software Engineer WSO2 Inc Mobile : 077-556-395-1
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
