[JBoss JIRA] (ISPN-5600) Optimize transactions on multiple caches
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-5600?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-5600:
-----------------------------------
I was looking to this for a while and started prototyping, but I've found that I would break interceptors that handle Prepare/Commit/Rollback commands since I would have to send them through the stack twice, and the code would get quite messy, too. I think that this cannot be implemented until we get explicit interceptor stack, that means 9.0 at best :-(
> Optimize transactions on multiple caches
> ----------------------------------------
>
> Key: ISPN-5600
> URL: https://issues.jboss.org/browse/ISPN-5600
> Project: Infinispan
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 8.0.0.Alpha2
> Reporter: Radim Vansa
>
> NON_XA transactions that span multiple caches are registered as multiple synchronizations, and these synchronizations are often processed sequentially ^1^; therefore, we send synchronous PrepareCommand for each cache and then CommitCommand for each cache as well, delaying the commit by these round-trips.
> Since the targets for different caches may differ, we still need to send the RPCs separately, but in parallel. Therefore, there should be one uber-synchronization for all caches that use NON_XA mode (and maybe something similar with XA). I believe that using single synchronization could save some allocations, too.
> ^1^ Not sure if full-fledged JTA implementations do that; JTA spec does not say anything about the order of synchronizations and whether these should be processed in parallel.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (ISPN-5559) "AsyncCacheWriter is dead!" errors cause deadlock or unbounded use of memory
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5559?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5559:
-----------------------------------------------
Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1235140|https://bugzilla.redhat.com/show_bug.cgi?id=1235140] from NEW to MODIFIED
> "AsyncCacheWriter is dead!" errors cause deadlock or unbounded use of memory
> ----------------------------------------------------------------------------
>
> Key: ISPN-5559
> URL: https://issues.jboss.org/browse/ISPN-5559
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Loaders and Stores
> Affects Versions: 5.3.0.Final, 6.0.0.Final, 7.0.0.Final
> Reporter: Karsten Blees
> Fix For: 8.0.0.Beta1, 7.2.4.Final
>
>
> Caused by a relatively small AsyncStore shutdownTimeout (default 25s) in conjunction with large queue sizes or slow back-end stores.
> With assertions enabled, the coordinator thread will exit with AssertionError and the AsyncStore will deadlock, as no more changes are beeing processed.
> With assertions disabled, the coordinator thread will allocate an unbounded number of AsyncStoreProcessors. If AsyncStoreProcessors were multithreaded (see ISPN-3532), this would cause loss of data (due to older changes overwriting newer changes in the back-end store).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (ISPN-5562) AsyncCacheWriter should write all data to the back-end store before shutting down
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5562?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5562:
-----------------------------------------------
Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1235143|https://bugzilla.redhat.com/show_bug.cgi?id=1235143] from NEW to MODIFIED
> AsyncCacheWriter should write all data to the back-end store before shutting down
> ---------------------------------------------------------------------------------
>
> Key: ISPN-5562
> URL: https://issues.jboss.org/browse/ISPN-5562
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.2.0.Final, 6.0.0.Final, 7.0.0.Final
> Reporter: Karsten Blees
> Fix For: 8.0.0.Beta1, 7.2.4.Final
>
>
> There is a chance that AsyncCacheWriter may stop before writing all midifications to the back-end store. This can primarily happen when writing the same keys in rapid succession. The coordinator thread will move these modifications to the head state (because of conflicts with tail), which is not checked before shutdown.
> There are two other minor race conditions if stop() is called concurrently to write() or clear() - these cannot happen in practice because PassivationManager is stopped before PersistenceManager:
> 1. AsyncStoreCoordinator checks State.stopped and State.modifications.isEmpty() without holding the readLock(). This is not reliable because a concurrent write() or remove() may still add to the modifications map.
> 2. clear() just replaces the head state, without copying the stopped flag that may have been set by a concurrent stop().
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months