Hazecast has an atomic Long ( http://www.hazelcast.com/javadoc/com/hazelcast/core/AtomicNumber.html) we can use that as the messageID and that way we can detect all missing messages as Suho mentioned (need to check the performance though)
--Srinath On Sun, Jul 7, 2013 at 2:53 PM, Sriskandarajah Suhothayan <[email protected]>wrote: > > > 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 > > -- ============================ Srinath Perera, Ph.D. http://people.apache.org/~hemapani/ http://srinathsview.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
