[JBoss JIRA] (ISPN-5159) Make concurrent startup smooth
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5159?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5159:
----------------------------------
Status: Open (was: New)
> Make concurrent startup smooth
> ------------------------------
>
> Key: ISPN-5159
> URL: https://issues.jboss.org/browse/ISPN-5159
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 7.1.0.Beta1
> Reporter: Radim Vansa
> Assignee: Dan Berindei
>
> When starting many instances in parallel, it often happens that the node does not detect its neighborhood very well and this results in many subclusters, merging views etc.
> Merging two available partitions has undefined results (AFAIK). While we can expect that there are no requests to the cluster from the application ^1^, Infinispan itself uses some caches to store internal information (HotRod routing, Protobuf etc...). It would be better if the available-available merge would provide hooks for rebuilding this info.
> ^1^) Being able to start the cluster with reads/writes disabled and enable them only when the cache has expected number of members would be convenient, too.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (ISPN-5159) Make concurrent startup smooth
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5159?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-5159:
-------------------------------------
Assignee: Dan Berindei
> Make concurrent startup smooth
> ------------------------------
>
> Key: ISPN-5159
> URL: https://issues.jboss.org/browse/ISPN-5159
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 7.1.0.Beta1
> Reporter: Radim Vansa
> Assignee: Dan Berindei
>
> When starting many instances in parallel, it often happens that the node does not detect its neighborhood very well and this results in many subclusters, merging views etc.
> Merging two available partitions has undefined results (AFAIK). While we can expect that there are no requests to the cluster from the application ^1^, Infinispan itself uses some caches to store internal information (HotRod routing, Protobuf etc...). It would be better if the available-available merge would provide hooks for rebuilding this info.
> ^1^) Being able to start the cluster with reads/writes disabled and enable them only when the cache has expected number of members would be convenient, too.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (ISPN-2041) Provide putAll(map) and getAll(map) bulk operation on Cache and RemoteCache
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2041?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-2041:
-------------------------------------
Assignee: William Burns (was: Galder Zamarreño)
> Provide putAll(map) and getAll(map) bulk operation on Cache and RemoteCache
> ---------------------------------------------------------------------------
>
> Key: ISPN-2041
> URL: https://issues.jboss.org/browse/ISPN-2041
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 5.1.4.FINAL
> Reporter: susanin
> Assignee: William Burns
> Priority: Minor
> Fix For: 7.2.0.Final
>
>
> Currently Infinispan implements putAll(map) by means of looping over all entries and submitting them by means of put() one-by-one.
> This is very slow if you have a lot of synchronous updates to apply.
> It would be much more efficient, if a special bulk operation would be supported, so that all entries are sent to their respective replica nodes in one go. It would reduce the number of network roundtrips and related overhead and it would also make use of parallel execution, because some of the puts can be executed in parallel as they land on different nodes.
> Note: Hazelcast has this optimization. It often improves performance of bulk puts by at least a factor of 2 or 3, even if it is used between a client and Hazelcast server, i.e. a bulk operation is sent to a single grid node from a client and no parallelism can be used.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (ISPN-2183) Add the ability to fetch a set of keys at once (getAll)
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2183?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-2183:
----------------------------------
Labels: (was: 64QueryBlockers)
> Add the ability to fetch a set of keys at once (getAll)
> -------------------------------------------------------
>
> Key: ISPN-2183
> URL: https://issues.jboss.org/browse/ISPN-2183
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Mircea Markus
> Assignee: William Burns
> Priority: Minor
>
> When a transaction knows in advance about the set of keys it needs to read, this cache.getAll(k1,k2,..kn) method can bring a some performance improvement:
> 1. all the keys can be fetched from remote nodes in parallel
> 2. keys that map to the same node can be grouped and fetched in the same RPC request
>
> Note that 1. can be be achieved even at this time by using Cache.getAsync(K) method - that's not as elegant though as it requires the user to write the code the code that waits on the Future objects that are returned.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (ISPN-2183) Add the ability to fetch a set of keys at once (getAll)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2183?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-2183:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1198556
> Add the ability to fetch a set of keys at once (getAll)
> -------------------------------------------------------
>
> Key: ISPN-2183
> URL: https://issues.jboss.org/browse/ISPN-2183
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Mircea Markus
> Assignee: William Burns
> Priority: Minor
>
> When a transaction knows in advance about the set of keys it needs to read, this cache.getAll(k1,k2,..kn) method can bring a some performance improvement:
> 1. all the keys can be fetched from remote nodes in parallel
> 2. keys that map to the same node can be grouped and fetched in the same RPC request
>
> Note that 1. can be be achieved even at this time by using Cache.getAsync(K) method - that's not as elegant though as it requires the user to write the code the code that waits on the Future objects that are returned.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years