8:49 a.m.
Hi,
FYI, I've just created a design page:
https://github.com/infinispan/infinispan/wiki/Total-Order-non-Transaction...
My plan is to implement it in 7.1 release.
Feel free to comment.
Cheers,
Pedro
6:22 a.m.
Hello Pedro,
I read your design page with interest, and formulated a few
remarks/questions below. Despite I do not know in details the internals,
I Hope that they might be useful.
Cheers,
Pierre
- It is unclear to me how the protocol execute reads, in particular
regarding causality. If a reader waits for a single replica to answer,
in case every write requires all replicas to answer, this is fine.
However, it seems that a writer can return as soon as a single replica
returns an acknowledgement. In such a case, it might be the case that a
reader do not see its own modifications, if it retrieves data from a
replica that did not apply the modifications yet.
- Do you ensure impotency of commands inside ISPN ? In my understanding,
it is necessary when switching from a view v1 to a view v2, as commands
delivered at the end of v1 might be already executed.
- I would call your replication protocol "virtual synchrony based"
instead, as it is relying on the virtual synchrony abstraction provided
by JGroups.
On 10. 11. 14 15:49, Pedro Ruivo wrote:
Hi,
FYI, I've just created a design page:
https://github.com/infinispan/infinispan/wiki/Total-Order-non-Transaction...
My plan is to implement it in 7.1 release.
Feel free to comment.
Cheers,
Pedro
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
4:53 a.m.
Hi Pierre,
Thanks for the feedback.
My comments are inline.
Cheers,
Pedro
On 11/17/2014 12:22 PM, Pierre Sutra wrote:
Hello Pedro,
I read your design page with interest, and formulated a few
remarks/questions below. Despite I do not know in details the internals,
I Hope that they might be useful.
Cheers,
Pierre
- It is unclear to me how the protocol execute reads, in particular
regarding causality. If a reader waits for a single replica to answer,
in case every write requires all replicas to answer, this is fine.
However, it seems that a writer can return as soon as a single replica
returns an acknowledgement. In such a case, it might be the case that a
reader do not see its own modifications, if it retrieves data from a
replica that did not apply the modifications yet.
You're right. The writer must wait for all the replies except if the
cache is full replicated (in this case, it can wait for the self-deliver).
- Do you ensure impotency of commands inside ISPN ? In my understanding,
it is necessary when switching from a view v1 to a view v2, as commands
delivered at the end of v1 might be already executed.
I'm lost here. can you be clear? are you talking about JGroups view or
Infinispan cache topology?
On the latter matters and it will delivered the cache topology changes
in total order. So, everybody receives the same order of events.
- I would call your replication protocol "virtual synchrony based"
instead, as it is relying on the virtual synchrony abstraction provided
by JGroups.
I don't think so. If I recall correctly, virtual synchrony ensures that
if a message is sent in view *v* then it is delivered in view *v*.
First, that cases is not necessary since we retry the commands received
in different topologies. Second, the protocol relies on the order in
which the operations are delivered.
On 10. 11. 14 15:49, Pedro Ruivo wrote:
> Hi,
>
> FYI, I've just created a design page:
> https://github.com/infinispan/infinispan/wiki/Total-Order-non-Transaction...
>
> My plan is to implement it in 7.1 release.
>
> Feel free to comment.
>
> Cheers,
> Pedro
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5:47 a.m.
Hi Pedro,
I added a few comments inline to your responses.
Cheers,
Pierre
You're right. The writer must wait for all the replies except if
the
cache is full replicated (in this case, it can wait for the self-deliver).
Indeed,
in the case of full replication, returning after the local
replica applies the update is fine.
Some precautions must be taken however if, for instance, the client is
accessing the system via
HotRod in round-robin mode.
- Do you ensure impotency of commands inside ISPN ? In my
understanding,
it is necessary when switching from a view v1 to a view v2, as commands
delivered at the end of v1 might be already executed.
I'm lost here. can you be clear? are you talking about JGroups view or
Infinispan cache topology?
On the latter matters and it will delivered the cache topology changes
in total order. So, everybody receives the same order of events.
Sorry if I was not
very clear. I was asking if an Infinispan replica
knows whether it has applied some command or not.
In the case where FLUSH is not at the top of the stack this might be
necessary between two view changes, no ?
> - I would call your replication protocol "virtual synchrony
based"
> instead, as it is relying on the virtual synchrony abstraction provided
> by JGroups.
I don't think so. If I recall correctly, virtual synchrony ensures that
if a message is sent in view *v* then it is delivered in view *v*.
I believe that
this is not the case, as processes have to simply agree
on the set of messages they receive
in the view they are currently leaving.
First, that cases is not necessary since we retry the commands
received
in different topologies. Second, the protocol relies on the order in
which the operations are delivered.
I see, but it seems to me in such a case you
would need either
idempotent commands,
or that processes agree on the message to deliver before the view
changes using FLUSH.
In the latter case, I was thinking that the abstraction implemented by
JGroups is virtual synchrony [1].
|1] http://www.jgroups.org/manual/html/user-advanced.html#d0e3025
(Section 5.7)
10:17 a.m.
On 11/18/2014 11:53 AM, Pedro Ruivo wrote:
Hi Pierre,
Thanks for the feedback.
My comments are inline.
Cheers,
Pedro
On 11/17/2014 12:22 PM, Pierre Sutra wrote:
> Hello Pedro,
>
> I read your design page with interest, and formulated a few
> remarks/questions below. Despite I do not know in details the internals,
> I Hope that they might be useful.
>
> Cheers,
> Pierre
>
> - It is unclear to me how the protocol execute reads, in particular
> regarding causality. If a reader waits for a single replica to answer,
> in case every write requires all replicas to answer, this is fine.
> However, it seems that a writer can return as soon as a single replica
> returns an acknowledgement. In such a case, it might be the case that a
> reader do not see its own modifications, if it retrieves data from a
> replica that did not apply the modifications yet.
You're right. The writer must wait for all the replies except if the
cache is full replicated (in this case, it can wait for the self-deliver).
>
> - Do you ensure impotency of commands inside ISPN ? In my understanding,
> it is necessary when switching from a view v1 to a view v2, as commands
> delivered at the end of v1 might be already executed.
I'm lost here. can you be clear? are you talking about JGroups view or
Infinispan cache topology?
On the latter matters and it will delivered the cache topology changes
in total order. So, everybody receives the same order of events.
>
> - I would call your replication protocol "virtual synchrony based"
> instead, as it is relying on the virtual synchrony abstraction provided
> by JGroups.
I don't think so. If I recall correctly, virtual synchrony ensures that
if a message is sent in view *v* then it is delivered in view *v*.
Are you using virtual synchrony at all ? IIRC there's no FLUSH protocol
in the default configs. TBH, I don't recommend this anyway.
First, that cases is not necessary since we retry the commands
received
in different topologies. Second, the protocol relies on the order in
which the operations are delivered.
>
>
> On 10. 11. 14 15:49, Pedro Ruivo wrote:
>> Hi,
>>
>> FYI, I've just created a design page:
>>
https://github.com/infinispan/infinispan/wiki/Total-Order-non-Transaction...
>>
>> My plan is to implement it in 7.1 release.
>>
>> Feel free to comment.
>>
>> Cheers,
>> Pedro
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
3708
days inactive
3717
days old
infinispan-dev@lists.jboss.org
4 comments
3 participants
participants (3)
-
Bela Ban -
Pedro Ruivo -
Pierre Sutra