[JBoss JIRA] (ISPN-10230) Remove org.infinispan.atomic implementations and MergeOnStore
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10230?page=com.atlassian.jira.plugin... ]
Dan Berindei commented on ISPN-10230:
-------------------------------------
I wish we had deprecated them at some point before removing them... this way they're not documented in the user guide, but we didn't tell users who know about them that we're going to remove them either. Are you still using them [~pferraro] and [~sannegrinovero]?
> Remove org.infinispan.atomic implementations and MergeOnStore
> -------------------------------------------------------------
>
> Key: ISPN-10230
> URL: https://issues.jboss.org/browse/ISPN-10230
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 10.0.0.Beta3
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> We should remove AtomicMap and FineGrainedAtomicMap as their implementation requires several workarounds that make parts of the codebase very fragile. As AtomicMaps and AtomicMapLookup are not documented in the user guide, the fallout from this should be minimal.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (ISPN-10232) PersistenceManagerImpl stop waits forever for active publishers to finish
by Dan Berindei (Jira)
Dan Berindei created ISPN-10232:
-----------------------------------
Summary: PersistenceManagerImpl stop waits forever for active publishers to finish
Key: ISPN-10232
URL: https://issues.jboss.org/browse/ISPN-10232
Project: Infinispan
Issue Type: Enhancement
Components: Core
Affects Versions: 9.4.13.Final, 10.0.0.Beta3
Reporter: Dan Berindei
Assignee: Will Burns
Fix For: 10.0.0.Final
{{PersistenceManagerImpl.stop()}} acquires all the permits of {{publisherSemaphore}} to make sure there is no ongoing iteration. But there is no timeout, so if the application is slowly going through all the entries in a huge cache it could block cache stop for a very long time.
What's more, when a publisher finishes, the stop thread and other threads trying to start a new publisher have the same priority, and if the new publisher acquires a permit stop will have to wait for it to finish.
We should limit the amount of time we wait for iterations to finish, similar to how {{TransactionTable}} only waits for ongoing transactions to finish for {{transaction.cacheStopTimeout}} millis. Ideally we would move {{cacheStopTimeout}} out of the transaction configuration and use it everywhere we could wait for user threads to finish doing their work before stopping.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months