[infinispan-dev] ISPN-263 and handling partitions

[Pedro Ruivo]

After think a bit about it, we can conclude that the behaviour when we 
have partition totally depends on the application.

So, why not create an generic interface (like, execute(Operation, Key, 
isPrimaryPartition)) that is invoked when a partition occurs?

Maybe I'm losing the focus of the first email, but this way the 
application can choose what it is better for it. For example, if the 
application does not care about consistency, it can allow all partitions 
to read and write. On other hand, if the application is more restrict, 
it can allow only one partition to read and write and the others 
partitions reject all the operations.

Pedro

On 04/19/2013 10:51 AM, Sanne Grinovero wrote:
> TBH I'm not understanding which problem this thread is about :)
>
> Surely network partitions are a problem, but there are many forms of
> "partition", and many different opinions of what an "acceptable"
> behaviour is that the grid should implement, which largely depend on
> assumptions the client application is making.
>
> Since we seem to be discussing a case in which the minority group is
> expected to flip into read-only mode, could we step back and describe:
>   - why this is an accepatble solution for some class of applications?
>   - what kind of potential network failure we want to take compensating
> actions for?
>
> I'm not an expert on how people physically wire up single nodes, racks
> and rooms to allow for our virtual connections, but let's assume that
> all nodes are connected with a single "cable" between each other, or
> if concrete multiple cables are actually used, could we rely on system
> configuration to guarantee packets can find alternative routes if one
> wire is eaten by mice?
> It seems important to me to define what level of network failure we
> want to address, for example are we assuming we don't deal with cases
> in which nodes can talk to one group but not vice-versa?
>
> If the effect of a nework failure is a completely isolated group, can
> we assume Hot Rod clients can't reach them either?
>
> If the group is totally isolated, would it still need read-only (with
> the risk of outdated reads) or could the whole group just shutdown
> since it's not reachable by anyone anyway? That is making more
> assumptions, like that all produced state change goes via the network
> as well, not suited for example to driving an assembly chain in a
> manufacturing plant, but then again it might be safer to stop the
> production belt rather than going ahead without being able to perform
> fresh read operations.
>
> I'm just trying to make an example of entirely different class of
> requirements, not proposing any solution but it seems to me that,
> given the complexity of the problem, we'll always need to make some
> trade off and which trade off is acceptable depends on the problem. If
> we described a very specific problem, we can work to make sure
> Infinispan and JGroups have enough extension points and smart
> protocols to deal with it, but I don't think we can resolve this issue
> at a one-size-fits-all level.
>
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>