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?
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
