On Sat, Jul 6, 2013 at 2:56 PM, Supun Malinga <[email protected]> wrote:
> Hi Azeez, > > Totally +1 for the approach. > I can suggest some improvement if you haven't already done. > Several components in carbon platform will be using the hazelcast based > clustering impl. We should have some mechanism to embed the usage of the > each cluster message into the message itself. > For eg. depsync messages will have the message type : depsync > cluster initialization/coordination messages will have > message type: cluster > etc. > (I'm aware there is some kind of identification via the cluster message > class, but I'm talking about embedding into api level.) > > So with this (message type), as the next step, we can have some rules on > which messages to re-play. > For eg: depsync messages, we can only re-play the latest (here we might > need to embed a timstamp into the message also). > WDYT? > > +1 We could have normal and reliable messaging APIs. +1 for cluster messages to have UUIDs for reliable messaging. IMHO the reliable messaging can also be implemented with the hazelcast cache, where we can store those messages in the cache and when a member joins/rejoins it can read the missed messages from the cache. but for this we have to use sequence numbers. This is just my thought, not sure how feasible it is. Suho thanks, > > > > > On Sat, Jul 6, 2013 at 2:30 PM, Afkham Azeez <[email protected]> wrote: > >> I have implemented a simple replay mechanism based on message UUIDs. >> >> >> On Thu, Jul 4, 2013 at 5:44 PM, Afkham Azeez <[email protected]> wrote: >> >>> There could be a situation where when a cluster message is sent, a >>> member momentarily leaves the cluster, but joins immediately. This >>> generally could happen when the nodes slow down under load, or due to >>> intermittent network failures. However, this could lead to failures because >>> crucial cluster messages may not be received by members. >>> >>> To overcome this, or reduce the probability of loss of such messages, we >>> can replay a certain number of messages when a member joins. On the sender >>> side, messages over a particular time period can be buffered, and then >>> replayed when new members join. However, we should ensure that the messages >>> are idempotent, and messages should declare whether they are idempotent or >>> not. If a message is not idempotent, we will not replay it. All the >>> messages we have at the moment are idempotent, AFAIK. >>> >>> How does this approach sound? >>> >>> -- >>> *Afkham Azeez* >>> Director of Architecture; WSO2, Inc.; http://wso2.com >>> Member; Apache Software Foundation; http://www.apache.org/ >>> * <http://www.apache.org/>** >>> email: **[email protected]* <[email protected]>* cell: +94 77 3320919 >>> blog: **http://blog.afkham.org* <http://blog.afkham.org>* >>> twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >>> * >>> linked-in: **http://lk.linkedin.com/in/afkhamazeez* >>> * >>> * >>> *Lean . Enterprise . Middleware* >>> >> >> >> >> -- >> *Afkham Azeez* >> Director of Architecture; WSO2, Inc.; http://wso2.com >> Member; Apache Software Foundation; http://www.apache.org/ >> * <http://www.apache.org/>** >> email: **[email protected]* <[email protected]>* cell: +94 77 3320919 >> blog: **http://blog.afkham.org* <http://blog.afkham.org>* >> twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >> * >> linked-in: **http://lk.linkedin.com/in/afkhamazeez* >> * >> * >> *Lean . Enterprise . Middleware* >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Supun Malinga, > > Senior Software Engineer, > WSO2 Inc. > http://wso2.com > http://wso2.org > email - [email protected] <[email protected]> > mobile - 071 56 91 321 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *S. Suhothayan * Associate Technical Lead, *WSO2 Inc. *http://wso2.com * <http://wso2.com/>* lean . enterprise . middleware *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ twitter: http://twitter.com/suhothayan | linked-in: http://lk.linkedin.com/in/suhothayan* * *
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
