[JBoss JIRA] (ISPN-5584) Support fine-grained write skew check for FineGrainedAtomicMap entries
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5584?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5584:
-----------------------------------
Fix Version/s: 9.0.0.Beta3
(was: 9.0.0.Beta2)
> Support fine-grained write skew check for FineGrainedAtomicMap entries
> ----------------------------------------------------------------------
>
> Key: ISPN-5584
> URL: https://issues.jboss.org/browse/ISPN-5584
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 8.0.0.Alpha2, 7.2.3.Final
> Reporter: Dan Berindei
> Fix For: 9.0.0.Beta3
>
>
> FineGrainedAtomicMap doesn't currently work with write skew check enabled.
> I was able to make it work by adding a special case for DeltaAwareCacheEntry in WriteSkewHelper, however the map has a single version, so the write skew check fails if any of the sub-keys were modified in parallel. With pessimistic locking, fine-grained maps allow the user to modify different sub-keys concurrently, we should allow the same with optimistic locking.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (ISPN-5614) Write performance regression after ISPN-5484
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5614?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5614:
-----------------------------------
Fix Version/s: 9.0.0.Beta3
(was: 9.0.0.Beta2)
> Write performance regression after ISPN-5484
> --------------------------------------------
>
> Key: ISPN-5614
> URL: https://issues.jboss.org/browse/ISPN-5614
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.0.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.0.0.Beta3
>
>
> Regression test shows a significant drop in throughput in the replicated and distributed write tests.
> This was after adjusting the internal thread pool settings in the JGroups configuration: with the default (min=5, max=20, queue=0), the distributed read test would fail to finish.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (ISPN-5642) Reduce contention in the RPC timeout handling
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5642?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5642:
-----------------------------------
Fix Version/s: 9.0.0.Beta3
(was: 9.0.0.Beta2)
> Reduce contention in the RPC timeout handling
> ---------------------------------------------
>
> Key: ISPN-5642
> URL: https://issues.jboss.org/browse/ISPN-5642
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 8.0.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Labels: help_wanted
> Fix For: 9.0.0.Beta3
>
>
> Most of the RPC timeout tasks are cancelled way before their timeout expires. This means the scheduler spends a lot of time reordering the elements of its DelayQueue.
> It should be possible to store the tasks with a long timeout (e.g. 1s) in a queue and only move them to the scheduler's priority queue when they have less than 1s to expiration (e.g. by a worker thread that runs every 0.5s)
> Storing all the tasks in a single queue may be impractical because the worker thread would have more and work to do as load increases and the RPCs take longer to finish, so a [hashed timing wheel|http://www.cse.wustl.edu/~cdgill/courses/cs6874/TimingWheels.ppt] may be needed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months