11:24 a.m.
Hi,
I managed to rewrite the old NBST design document and created a v2 [1]
that should cover the interesting aspects. I'm not sure I managed to
make it intelligible and sound enough, but this is the best I could do
after several attempts at rewriting :)
Please read it. Your feedback is welcome!
The old document is still there [2] for now but should not be relied
upon. I kept it because some parts of it might still be relevant and
could be moved to v2 doc, but I don't think they are essential in
understading the code of our pull request. Dan, could you have a look if
there are any bits that we need to move to v2?
Thanks,
Adrian
[1] https://community.jboss.org/wiki/Non-BlockingStateTransferV2
[2] https://community.jboss.org/wiki/Non-blockingStateTransfer
12:02 p.m.
First of all, code apart, the document that Adrian has written is very well written,
clear, concise and with loads of important information. So kudos to Adrian for the write
up!
Now, onto the contents. I'm not yet finished reading the doc, the following comes up:
"The hash of the address of a node no longer participates in the computation of the
CH…"
Hmmm, sounds like this is gonna break the Hot Rod protocol:
https://docs.jboss.org/author/display/ISPN/Hot+Rod+Protocol+-+Version+1.1...
The hash code of each node was sent back to the clients as part of the topologies so that
they could locate which node has the keys.
Seems like we're now gonna have to send that routing table back to Hot Rod clients?
Hmmmmmmm...
Cheers,
On Aug 15, 2012, at 11:24 AM, Adrian Nistor wrote:
Hi,
I managed to rewrite the old NBST design document and created a v2 [1]
that should cover the interesting aspects. I'm not sure I managed to
make it intelligible and sound enough, but this is the best I could do
after several attempts at rewriting :)
Please read it. Your feedback is welcome!
The old document is still there [2] for now but should not be relied
upon. I kept it because some parts of it might still be relevant and
could be moved to v2 doc, but I don't think they are essential in
understading the code of our pull request. Dan, could you have a look if
there are any bits that we need to move to v2?
Thanks,
Adrian
[1] https://community.jboss.org/wiki/Non-BlockingStateTransferV2
[2] https://community.jboss.org/wiki/Non-blockingStateTransfer
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
1:35 p.m.
Hi Galder,
My (superficial) understanding of the HR v1.0 and v1.1 is that clients
will actually derive the CH of the cluster based on the received member
address list + virtual node info.
Now with in the new CH algo we do not use the address of members in the
computation and the concept of virtual nodes has vanished.
So my feeling is we need a HR v1.2 where the full CH (the routing table)
si sent to the client as you said. Are you worried about sending the
routing table for reasons other than backward compatibility?
Regarding backward compat, I know Dan Berindei has done some wizardry
there to be able to support old clients, but I do not know any details.
He will hopefully clear things up, and it seems we also need to update
the HR protocol wiki page regarding this aspect.
Cheers,
Adrian
On 08/15/2012 01:02 PM, Galder Zamarreño wrote:
First of all, code apart, the document that Adrian has written is
very well written, clear, concise and with loads of important information. So kudos to
Adrian for the write up!
Now, onto the contents. I'm not yet finished reading the doc, the following comes
up:
"The hash of the address of a node no longer participates in the computation of the
CH…"
Hmmm, sounds like this is gonna break the Hot Rod protocol:
https://docs.jboss.org/author/display/ISPN/Hot+Rod+Protocol+-+Version+1.1...
The hash code of each node was sent back to the clients as part of the topologies so that
they could locate which node has the keys.
Seems like we're now gonna have to send that routing table back to Hot Rod clients?
Hmmmmmmm...
Cheers,
On Aug 15, 2012, at 11:24 AM, Adrian Nistor wrote:
> Hi,
>
> I managed to rewrite the old NBST design document and created a v2 [1]
> that should cover the interesting aspects. I'm not sure I managed to
> make it intelligible and sound enough, but this is the best I could do
> after several attempts at rewriting :)
>
> Please read it. Your feedback is welcome!
>
> The old document is still there [2] for now but should not be relied
> upon. I kept it because some parts of it might still be relevant and
> could be moved to v2 doc, but I don't think they are essential in
> understading the code of our pull request. Dan, could you have a look if
> there are any bits that we need to move to v2?
>
> Thanks,
> Adrian
>
> [1] https://community.jboss.org/wiki/Non-BlockingStateTransferV2
>
> [2] https://community.jboss.org/wiki/Non-blockingStateTransfer
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5:22 p.m.
Another aspect Erik raised is the TACH/server hinting (rack, machine in particular) - I
guess these would be parameters of the CH factory?
Also a notes on the RoutingTable: it is a more effective data structure than the old CH,
as it basically keeps a cache with all the possible outcomes of the CH function (instead
of building the collection of owner on every call)
On 15 Aug 2012, at 12:35, Adrian Nistor wrote:
Hi Galder,
My (superficial) understanding of the HR v1.0 and v1.1 is that clients
will actually derive the CH of the cluster based on the received member
address list + virtual node info.
Now with in the new CH algo we do not use the address of members in the
computation and the concept of virtual nodes has vanished.
So my feeling is we need a HR v1.2 where the full CH (the routing table)
si sent to the client as you said. Are you worried about sending the
routing table for reasons other than backward compatibility?
Regarding backward compat, I know Dan Berindei has done some wizardry
there to be able to support old clients, but I do not know any details.
He will hopefully clear things up, and it seems we also need to update
the HR protocol wiki page regarding this aspect.
12:19 p.m.
More comments:
Leave flow, step 2: "The topology id is not incremented because the new topology does
not have state to be transferered with respect to previous topology."
Hmmm, if you have 2 owners for data and one leaves, aren't you gonna have to do some
transfering to find a new backup owner for that data?
On Aug 15, 2012, at 11:24 AM, Adrian Nistor wrote:
Hi,
I managed to rewrite the old NBST design document and created a v2 [1]
that should cover the interesting aspects. I'm not sure I managed to
make it intelligible and sound enough, but this is the best I could do
after several attempts at rewriting :)
Please read it. Your feedback is welcome!
The old document is still there [2] for now but should not be relied
upon. I kept it because some parts of it might still be relevant and
could be moved to v2 doc, but I don't think they are essential in
understading the code of our pull request. Dan, could you have a look if
there are any bits that we need to move to v2?
Thanks,
Adrian
[1] https://community.jboss.org/wiki/Non-BlockingStateTransferV2
[2] https://community.jboss.org/wiki/Non-blockingStateTransfer
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
1:07 p.m.
Hi Galder,
The intention is to decouple membership changes from the actual state
transfer as much as possible. But they are still related of course. So
in your example, when a node leaves the cluster everybody has to
immediately remove it from the CH to avoid sending commands to a dead
node. This all we need to care for now. The actual state transfer to a
new backup owner is going to happen immediately after (but in a separate
flow) when the rebalancer notices the imbalance (< num_owners) and acts
accordingly. This separation allows us to process multiple joiners and
leavers without disturbing any in-progress state transfer.
Cheers,
Adrian
On 08/15/2012 01:19 PM, Galder Zamarreño wrote:
More comments:
Leave flow, step 2: "The topology id is not incremented because the new topology
does not have state to be transferered with respect to previous topology."
Hmmm, if you have 2 owners for data and one leaves, aren't you gonna have to do some
transfering to find a new backup owner for that data?
On Aug 15, 2012, at 11:24 AM, Adrian Nistor wrote:
> Hi,
>
> I managed to rewrite the old NBST design document and created a v2 [1]
> that should cover the interesting aspects. I'm not sure I managed to
> make it intelligible and sound enough, but this is the best I could do
> after several attempts at rewriting :)
>
> Please read it. Your feedback is welcome!
>
> The old document is still there [2] for now but should not be relied
> upon. I kept it because some parts of it might still be relevant and
> could be moved to v2 doc, but I don't think they are essential in
> understading the code of our pull request. Dan, could you have a look if
> there are any bits that we need to move to v2?
>
> Thanks,
> Adrian
>
> [1] https://community.jboss.org/wiki/Non-BlockingStateTransferV2
>
> [2] https://community.jboss.org/wiki/Non-blockingStateTransfer
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
4333
days inactive
4335
days old
infinispan-dev@lists.jboss.org
5 comments
3 participants
participants (3)
-
Adrian Nistor -
Galder Zamarreño -
Mircea Markus