[JBoss JIRA] (ISPN-3838) L1 entry added by ST when already invalidated
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3838?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3838:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1043434|https://bugzilla.redhat.com/show_bug.cgi?id=1043434] from MODIFIED to ON_QA
> L1 entry added by ST when already invalidated
> ---------------------------------------------
>
> Key: ISPN-3838
> URL: https://issues.jboss.org/browse/ISPN-3838
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Priority: Critical
> Labels: 620
> Fix For: 7.0.0.Alpha4, 7.0.0.Final
>
>
> Non-transactional cache with L1 enabled. Node A is losing ownership of an entry, the entry is not removed during ST but is going to L1.
> 1. ST builds the invalidation command, EntryWrapping interceptor starts committing all the entries
> 2. Write on primary owner (B) occurs
> 3. A gets the InvalidateL1Command, removes the ImmortalCacheEntry from data container (as it does not own the entry anymore)
> 4. The ST invalidation command commits the MortalCacheEntry with old value, storing it into the data container.
> Result: Outdated value is in L1 cache.
> As the entry is not locked during the ST, it can be committed as MortalCacheEntry only if it was not changed (removed and possibly then cached again with different value).
> (I understand that this wouldn't be easy to implement as the check is not to be executed in perform, but during the actual commit - and atomically in the container.)
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4216) Use IGNORE_RETURN_VALUES flag for inserting keys/values in M/R intermediate cache
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4216?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4216:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1096878|https://bugzilla.redhat.com/show_bug.cgi?id=1096878] from MODIFIED to ON_QA
> Use IGNORE_RETURN_VALUES flag for inserting keys/values in M/R intermediate cache
> ---------------------------------------------------------------------------------
>
> Key: ISPN-4216
> URL: https://issues.jboss.org/browse/ISPN-4216
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Execution and Map/Reduce
> Reporter: Vladimir Blagojevic
> Assignee: Vladimir Blagojevic
> Fix For: 7.0.0.Alpha4
>
>
> Whenever data gets inserted in intermediate cache unsafeReturnValues setting is ignored and previous value from cache is returned every time we do cache#put. We did not experience this slowdown before because we only inserted once per key in intermediate cache put. Now that we do partial batching and transfer of these keys/values, we really hit the wall there with multiple insertions. Adding IGNORE_RETURN_VALUES flag to put invocation is the key to resolve this issue.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-3894) SingleFileStore can optimize space usage by coalescing adjacent free entry blocks.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3894?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3894:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1096727|https://bugzilla.redhat.com/show_bug.cgi?id=1096727] from MODIFIED to ON_QA
> SingleFileStore can optimize space usage by coalescing adjacent free entry blocks.
> ----------------------------------------------------------------------------------
>
> Key: ISPN-3894
> URL: https://issues.jboss.org/browse/ISPN-3894
> Project: Infinispan
> Issue Type: Patch
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Final
> Environment: Oracle JDK 1.7, Windows Server 2008 R2
> Reporter: Rajesh Jangam
> Assignee: Dan Berindei
> Fix For: 7.0.0.Alpha4
>
> Attachments: CoalesceEntries.java
>
>
> This issue is related to issue ISPN-3877.
> Here we have a use case where the size of the entries gradually keeps on increasing and then finally those entries expire.
> 1. Smaller entries expire and new bigger entries start getting added
> 2. These new bigger entries will not fit into the free slots (entries) created due to the expiry of smaller entries.
> 3. Thus, these new bigger entries only get allocated at the end of the file resulting in growth of file size.
> The optimization proposed is to:
> 1. Coalesce/Combine adjacent free entries during the periodic purge cycle to create bigger/larger free entries.
> 2. While allocating from an existing free entry, check if the size of the free entry is more than required for the new request being allocated. If yes, then, split the free entry into two free entries:
> a. First part equal to the length being requested
> This is returned as a part of the allocation activity.
> b. Second part equal to the remainder of the space.
> This added back as a free entry to the freeList.
> Thus free space created due to expiry of smaller entries becomes available for consumption for the larger entries to some extent.
> This reduces file size of the store.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4137) Transaction executed multiple times due to forwarded CommitCommand
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4137?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4137:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1080313|https://bugzilla.redhat.com/show_bug.cgi?id=1080313] from MODIFIED to ON_QA
> Transaction executed multiple times due to forwarded CommitCommand
> ------------------------------------------------------------------
>
> Key: ISPN-4137
> URL: https://issues.jboss.org/browse/ISPN-4137
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer, Transactions
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 630betablocker
>
> When the {{StateTransferInterceptor}} forwards a CommitCommand for the new topology, multiple CommitCommands may be broadcast across the cluster. If the command (forwarded already from originator) times out, the transaction may be correctly finished by the first one and the application considers TX as succeeded (useSynchronizations=true), although one more Rollback is sent as well.
> Then, again in STI, when the CommitCommand arrives with higher topologyId than the one used for the first TX execution, another artificial Prepare (followed by the commit) is executed - see {{STI.visitCommitCommand}}.
> However, this execution may be delayed a lot and originator may have already executed another TX on the same entries. Then, this forwarded Commit will overwrite the already updated entries, causing inconsistency of data.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4240) Migrate one intermediate key/value per maxCollectorSize threshold
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4240?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4240:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1096467|https://bugzilla.redhat.com/show_bug.cgi?id=1096467] from MODIFIED to ON_QA
> Migrate one intermediate key/value per maxCollectorSize threshold
> -----------------------------------------------------------------
>
> Key: ISPN-4240
> URL: https://issues.jboss.org/browse/ISPN-4240
> Project: Infinispan
> Issue Type: Enhancement
> Components: Distributed Execution and Map/Reduce
> Reporter: Vladimir Blagojevic
> Assignee: Vladimir Blagojevic
> Fix For: 7.0.0.Alpha4
>
>
> When we hit the maxCollectorSize threshold, we remove all the values from the collector and we start transferring them into the intermediary cache. But the other mapper threads keep working, and event with large collector sizes, it's very likely that the collector will be full again before we finished sending the previous batch. So we could end up with a lot of threads trying to insert maxCollectorSize values in the intermediary cache in parallel, and a lot more intermediary values in memory on each mapper node than the user would expect.
> In order to alleviate this observed phenomena Dan proposed an idea to keep the maxCollectorSize threshold, but to only move a single key at a time from the collector to the intermediary cache when the threshold is hit (the least recently used one). That way, the other keys would have time to collect more values (or just run the combiner a few more times).
> This way we still transfer some intermediate keys/values during map/combine phase rather than all at once at the end of that phase thus alleviating possibility of OOM. At the end of map/combine phase all remaining keys/values are of course transferred. Application users can fine tune their requirements and a specific use case using maxCollectorSize threshold.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months