On 29/07/14 20:06, Sanne Grinovero wrote:
This is a nasty problem and I also feel passionately we need to get
rid of it ASAP.
+1
I did have the same problems many times, and we discussed this also
in
Farnborough; AFAIR Dan and Pedro had some excellent ideas to fix this.
You don't need TO, and you don't need to lock at all as long as you
guarantee the backup owners are getting the number with some
monotonicity sequence attached to it,
all that backup owners need to do is ignore incoming commands which
are outdated.
Right. And we need to handle the scenario where we get updates from
multiple members, e.g. P40,P41,Q6,Q7 in the case where the primary owner
changed from P to Q (or from Q to P ?)
Another aspect is that the "user thread" on the primary
owner needs to
wait (at least until we improve further) and only proceed after ACK
from backup nodes, but this is better modelled through a state
machine. (Also discussed in Farnborough).
It's also conceptually linked to:
-
https://issues.jboss.org/browse/ISPN-1599
As you need to separate the locks of entries from the effective user
facing lock, at least to implement transactions on top of this model.
I expect this to improve performance in a very significant way, but
it's getting embarrassing that it's still not done; at the next face
to face meeting we should also reserve some time for retrospective
sessions.
Yes - there's a link to the agenda of the 2015 team meeting, please feel
free to update the agenda. I'll send out an email re dates and location
shortly.
[1]
https://mojo.redhat.com/docs/DOC-977279
--
Bela Ban, JGroups lead (
http://www.jgroups.org)