[JBoss JIRA] (ISPN-2772) Implement REPLICATED mode as a degenerated DISTRIBUTED mode (nowOwners>=clusterSize)
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2772?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2772:
-------------------------------------
Well, actually we do need to modify ReplicatedConsistentHash a bit in order to spread primary lock ownership within the cluster, but we do not need to keep lists of owners as in DefaultConsistentHash. All we need is a deterministic function that assigns a primary owner to a key.
> Implement REPLICATED mode as a degenerated DISTRIBUTED mode (nowOwners>=clusterSize)
> ------------------------------------------------------------------------------------
>
> Key: ISPN-2772
> URL: https://issues.jboss.org/browse/ISPN-2772
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 5.2.0.Final
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Fix For: 5.3.0.Final
>
>
> This has already been done in the case of state transfer, where the distribution state transfer code is reused for replicated caches as well.
> The main reason behind this improvement is to simplify/reduce the code. Also there will be some additional benefits:
> - ATM in replicated mode, the JGroups coordinator always plays the role of main lock owner. The coordinator might get overwhelmed as it has to process the additional TxCompletionNotificationCommand on every transaction (direct consequence of being main lock owner). OTOH in distributed mode, the lock owner is spread between the cluster members.
> As an optimisation, on REPL mode, we can use multicasting (when on UDP) for message sending.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (ISPN-2772) Implement REPLICATED mode as a degenerated DISTRIBUTED mode (nowOwners>=clusterSize)
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2772?page=com.atlassian.jira.plugin.... ]
Adrian Nistor edited comment on ISPN-2772 at 2/1/13 5:13 AM:
-------------------------------------------------------------
Hey, this one sounds great! There are already too many issues related to ReplicationInterceptor and friends. It does not play well with asymmetric caches, namely if the jgroups coordinator is not a member of the cache then I doubt locking works at all. But this new approach will make all those issues obsolete :) For the sake of memory efficiency we can still use ReplicatedConsistentHash instead of a DefaultConsistentHash with a huge numOwners.
was (Author: anistor):
Hey, this one sounds great! There are already too many issues related to ReplicationInterceptor and friends. It does not play well with asymmetric caches, namely if the jgroups coordinator is not a member of the cache then I doubt locking works at all. But this new approach will make all those issues obsolete :)
> Implement REPLICATED mode as a degenerated DISTRIBUTED mode (nowOwners>=clusterSize)
> ------------------------------------------------------------------------------------
>
> Key: ISPN-2772
> URL: https://issues.jboss.org/browse/ISPN-2772
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 5.2.0.Final
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Fix For: 5.3.0.Final
>
>
> This has already been done in the case of state transfer, where the distribution state transfer code is reused for replicated caches as well.
> The main reason behind this improvement is to simplify/reduce the code. Also there will be some additional benefits:
> - ATM in replicated mode, the JGroups coordinator always plays the role of main lock owner. The coordinator might get overwhelmed as it has to process the additional TxCompletionNotificationCommand on every transaction (direct consequence of being main lock owner). OTOH in distributed mode, the lock owner is spread between the cluster members.
> As an optimisation, on REPL mode, we can use multicasting (when on UDP) for message sending.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (ISPN-2772) Implement REPLICATED mode as a degenerated DISTRIBUTED mode (nowOwners>=clusterSize)
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2772?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2772:
-------------------------------------
Hey, this one sounds great! There are already too many issues related to ReplicationInterceptor and friends. It does not play well with asymmetric caches, namely if the jgroups coordinator is not a member of the cache then I doubt locking works at all. But this new approach will make all those issues obsolete :)
> Implement REPLICATED mode as a degenerated DISTRIBUTED mode (nowOwners>=clusterSize)
> ------------------------------------------------------------------------------------
>
> Key: ISPN-2772
> URL: https://issues.jboss.org/browse/ISPN-2772
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 5.2.0.Final
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Fix For: 5.3.0.Final
>
>
> This has already been done in the case of state transfer, where the distribution state transfer code is reused for replicated caches as well.
> The main reason behind this improvement is to simplify/reduce the code. Also there will be some additional benefits:
> - ATM in replicated mode, the JGroups coordinator always plays the role of main lock owner. The coordinator might get overwhelmed as it has to process the additional TxCompletionNotificationCommand on every transaction (direct consequence of being main lock owner). OTOH in distributed mode, the lock owner is spread between the cluster members.
> As an optimisation, on REPL mode, we can use multicasting (when on UDP) for message sending.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months