+1. We need to keep performance aspect in mind too. If we try to commit the session per message, there might be a performance drawback. Also, publisher >> session relationship should be one to one I guess. Need to be careful with session caching etc.
On Wed, Jul 8, 2015 at 6:22 AM, Prabath Ariyarathna <[email protected]> wrote: > 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 > > -- *Hasitha Abeykoon* Senior Software Engineer; WSO2, Inc.; http://wso2.com *cell:* *+94 719363063* *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
