[JBoss JIRA] (ISPN-5564) AsyncCacheWriter stop() and clear() should not wait for space in the modifications queue
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5564?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-5564:
------------------------------------
[~kblees] The fix is now integrated, but I'm wondering if this really matters for {{stop()}}. The cache is shutting down, so it's not issuing any more modifications, and {{stop()}} must wait for the processors to empty the queue and process all the modifications anyway.
> AsyncCacheWriter stop() and clear() should not wait for space in the modifications queue
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-5564
> URL: https://issues.jboss.org/browse/ISPN-5564
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Karsten Blees
> Fix For: 8.0.0.Beta1, 7.2.4.Final
>
>
> AsyncCacheWriter.clear() invalidates all enqueued changes rather than adding more changes to the queue. Thus, clear should not wait if the queue is full.
> AsyncCacheWriter.stop() should also take effect immediately (i.e. set the stopped flag *without* waiting if the queue is full).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 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 updated ISPN-5562:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1235143
> 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)
9 years, 6 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 updated ISPN-5559:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1235140
> "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)
9 years, 6 months
[JBoss JIRA] (ISPN-5572) Exposed JMX MBeans should be separate components
by Dan Berindei (JIRA)
Dan Berindei created ISPN-5572:
----------------------------------
Summary: Exposed JMX MBeans should be separate components
Key: ISPN-5572
URL: https://issues.jboss.org/browse/ISPN-5572
Project: Infinispan
Issue Type: Task
Components: Core
Affects Versions: 7.2.3.Final, 8.0.0.Alpha2
Reporter: Dan Berindei
Fix For: 8.0.0.Final
We currently expose internal components as JMX MBeans, and that makes our JMX "API" very unstructured. The exposed MBeans should be separate components, and the only concern in their interfaces should be ease of use.
One example of JMX getting in the way of refactoring is {{CacheMgmtInterceptor}}. The interceptor chain is dynamic, so it should be possible to insert the interceptor only when statistics are enabled. But because the {{statisticsEnabled}} attribute is on the interceptor itself, that becomes a lot trickier, and we had to introduce a separate configuration attribute that disables statistics permanently (ISPN-5542).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months