[JBoss JIRA] (ISPN-962) Entries not committed w/ DistLockingInterceptor and L1 caching disabled.
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-962?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-962:
-------------------------------
Priority: Critical (was: Major)
> Entries not committed w/ DistLockingInterceptor and L1 caching disabled.
> ------------------------------------------------------------------------
>
> Key: ISPN-962
> URL: https://issues.jboss.org/browse/ISPN-962
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Locking and Concurrency
> Affects Versions: 4.2.0.Final
> Reporter: Shane Johnson
> Assignee: William Burns
> Priority: Critical
> Labels: Invalidation, Rehash
> Fix For: 6.0.0.Final
>
>
> If you choose to disable the L1 cache (enabled=false AND onRehash=false) in distributed mode, the DistLockingInterceptor will NOT commit any invalidations due to a rehash back to the data container.
> The problem is in the commitEntry method.
> boolean doCommit = true;
> if (!dm.isLocal(entry.getKey())) {
> if (configuration.isL1CacheEnabled()) {
> dm.transformForL1(entry);
> } else {
> doCommit = false;
> }
> }
> if (doCommit)
> entry.commit(dataContainer);
> else
> entry.rollback();
> For most commands, dm.isLocal returns TRUE and so the execution proceeds to commit. However, invalidation commands are unique in that they are executed on a remote node even though that node is NOT the owner of the entry. For that reason, the dm.isLocal returns FALSE and the execution proceeds to the L1 cache enabled check. If the L1 cache is disabled, the execution proceeds to set doCommit to false and rollback the invalidation.
> We have temporarily fixed this by updating the else block to check and see if the entry has been removed. If it has not, we set doCommit to false like it does now. Otherwise, we set it to true.
> To be honest, that was a safeguard in case we are missing something. I'm still not sure why we would ever want to set doCommit to false just because the L1 cache has been disabled. However, this change has fixed our problem with entries not being deleted from the original owners on a rehash.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (ISPN-962) Entries not committed w/ DistLockingInterceptor and L1 caching disabled.
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-962?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-962:
-------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.Alpha1)
> Entries not committed w/ DistLockingInterceptor and L1 caching disabled.
> ------------------------------------------------------------------------
>
> Key: ISPN-962
> URL: https://issues.jboss.org/browse/ISPN-962
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Locking and Concurrency
> Affects Versions: 4.2.0.Final
> Reporter: Shane Johnson
> Assignee: Dan Berindei
> Labels: Invalidation, Rehash
> Fix For: 6.0.0.Final
>
>
> If you choose to disable the L1 cache (enabled=false AND onRehash=false) in distributed mode, the DistLockingInterceptor will NOT commit any invalidations due to a rehash back to the data container.
> The problem is in the commitEntry method.
> boolean doCommit = true;
> if (!dm.isLocal(entry.getKey())) {
> if (configuration.isL1CacheEnabled()) {
> dm.transformForL1(entry);
> } else {
> doCommit = false;
> }
> }
> if (doCommit)
> entry.commit(dataContainer);
> else
> entry.rollback();
> For most commands, dm.isLocal returns TRUE and so the execution proceeds to commit. However, invalidation commands are unique in that they are executed on a remote node even though that node is NOT the owner of the entry. For that reason, the dm.isLocal returns FALSE and the execution proceeds to the L1 cache enabled check. If the L1 cache is disabled, the execution proceeds to set doCommit to false and rollback the invalidation.
> We have temporarily fixed this by updating the else block to check and see if the entry has been removed. If it has not, we set doCommit to false like it does now. Otherwise, we set it to true.
> To be honest, that was a safeguard in case we are missing something. I'm still not sure why we would ever want to set doCommit to false just because the L1 cache has been disabled. However, this change has fixed our problem with entries not being deleted from the original owners on a rehash.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (ISPN-962) Entries not committed w/ DistLockingInterceptor and L1 caching disabled.
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-962?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-962:
-------------------------------
Assignee: William Burns (was: Dan Berindei)
> Entries not committed w/ DistLockingInterceptor and L1 caching disabled.
> ------------------------------------------------------------------------
>
> Key: ISPN-962
> URL: https://issues.jboss.org/browse/ISPN-962
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Locking and Concurrency
> Affects Versions: 4.2.0.Final
> Reporter: Shane Johnson
> Assignee: William Burns
> Labels: Invalidation, Rehash
> Fix For: 6.0.0.Final
>
>
> If you choose to disable the L1 cache (enabled=false AND onRehash=false) in distributed mode, the DistLockingInterceptor will NOT commit any invalidations due to a rehash back to the data container.
> The problem is in the commitEntry method.
> boolean doCommit = true;
> if (!dm.isLocal(entry.getKey())) {
> if (configuration.isL1CacheEnabled()) {
> dm.transformForL1(entry);
> } else {
> doCommit = false;
> }
> }
> if (doCommit)
> entry.commit(dataContainer);
> else
> entry.rollback();
> For most commands, dm.isLocal returns TRUE and so the execution proceeds to commit. However, invalidation commands are unique in that they are executed on a remote node even though that node is NOT the owner of the entry. For that reason, the dm.isLocal returns FALSE and the execution proceeds to the L1 cache enabled check. If the L1 cache is disabled, the execution proceeds to set doCommit to false and rollback the invalidation.
> We have temporarily fixed this by updating the else block to check and see if the entry has been removed. If it has not, we set doCommit to false like it does now. Otherwise, we set it to true.
> To be honest, that was a safeguard in case we are missing something. I'm still not sure why we would ever want to set doCommit to false just because the L1 cache has been disabled. However, this change has fixed our problem with entries not being deleted from the original owners on a rehash.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (ISPN-2418) CLONE - Cache restart doesn't work properly
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2418?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2418:
--------------------------------
Fix Version/s: (was: 5.1.9.Final)
> CLONE - Cache restart doesn't work properly
> -------------------------------------------
>
> Key: ISPN-2418
> URL: https://issues.jboss.org/browse/ISPN-2418
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 5.1.7.Final, 5.2.0.Alpha3
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: jdg6
> Fix For: 6.0.0.Final
>
>
> Copied from ISPN-2297:
> {quote}
> If a cache is stopped via {{Cache.stop()}} it will still be returned by {{DefaultCacheManager.getCache()}}. Cache {{start()}} and {{stop()}} are not synchronized in any way, so a {{start()}} call may return before the cache was properly started - just because another thread is in the process of starting it.
> Also, the documentation of {{EmbeddedCacheManager.getCache()}} should say that it will start the cache only if it doesn't exist yet - if the cache is stopped it will return the cache as it was. Alternatively we could change the behaviour of {{getCache()}} to always start the cache.
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (ISPN-3283) Can't deploy application with infinispan 5.3.0.SNAPSHOT on EAP server
by Vitalii Chepeliuk (JIRA)
Vitalii Chepeliuk created ISPN-3283:
---------------------------------------
Summary: Can't deploy application with infinispan 5.3.0.SNAPSHOT on EAP server
Key: ISPN-3283
URL: https://issues.jboss.org/browse/ISPN-3283
Project: Infinispan
Issue Type: Bug
Components: Core API
Affects Versions: 5.3.0.Final
Reporter: Vitalii Chepeliuk
Assignee: Mircea Markus
When application with infinispan-5.3.0 is deployed on EAP server(jboss-eap-6.1.0.ER8), exception is thrown
[java] 11:09:08,520 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 13) MSC000001: Failed to start service jboss.persistenceunit."testable.war#hib2Lc": org.jboss.msc.service.StartException in service jboss.persistenceunit."testable.war#hib2Lc": javax.persistence.PersistenceException: [PersistenceUnit: hib2Lc] Unable to build EntityManagerFactory
[java] at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:103)
[java] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
[java] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
[java] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
[java] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
[java] Caused by: javax.persistence.PersistenceException: [PersistenceUnit: hib2Lc] Unable to build EntityManagerFactory
[java] at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:930)
[java] at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:904)
[java] at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:92)
[java] at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:200)
[java] at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.access$600(PersistenceUnitServiceImpl.java:57)
[java] at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:99)
[java] ... 4 more
[java] Caused by: org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.spi.CacheImplementor]
[java] at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:186)
[java] at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:150)
[java] at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
[java] at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:264)
[java] at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1750)
[java] at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:94)
[java] at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:920)
[java] ... 9 more
[java] Caused by: org.hibernate.cache.CacheException: Unable to start region factory
[java] at org.hibernate.cache.infinispan.InfinispanRegionFactory.start(InfinispanRegionFactory.java:323)
[java] at org.hibernate.internal.CacheImpl.<init>(CacheImpl.java:70)
[java] at org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:40)
[java] at org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:35)
[java] at org.hibernate.service.internal.SessionFactoryServiceRegistryImpl.initiateService(SessionFactoryServiceRegistryImpl.java:91)
[java] at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:176)
[java] ... 15 more
[java] Caused by: java.lang.IllegalArgumentException: Root element for infinispan already registered
[java] at org.jboss.staxmapper.XMLMapperImpl.registerRootElement(XMLMapperImpl.java:44) [staxmapper-1.1.0.Final-redhat-2.jar:1.1.0.Final-redhat-2]
[java] at org.infinispan.configuration.parsing.ParserRegistry.<init>(ParserRegistry.java:54)
[java] at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:353)
[java] at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:326)
[java] at org.hibernate.cache.infinispan.InfinispanRegionFactory.createCacheManager(InfinispanRegionFactory.java:387)
[java] at org.hibernate.cache.infinispan.InfinispanRegionFactory.start(InfinispanRegionFactory.java:308)
[java] ... 20 more
[java] 11:09:08,733 ERROR [org.jboss.as.server] (management-handler-thread - 2) JBAS015870: Deploy of deployment "testable.war" was rolled back with the following failure message:
[java] {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"testable.war#hib2Lc\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"testable.war#hib2Lc\": javax.persistence.PersistenceException: [PersistenceUnit: hib2Lc] Unable to build EntityManagerFactory
[java] Caused by: javax.persistence.PersistenceException: [PersistenceUnit: hib2Lc] Unable to build EntityManagerFactory
[java] Caused by: org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.spi.CacheImplementor]
[java] Caused by: org.hibernate.cache.CacheException: Unable to start region factory
[java] Caused by: java.lang.IllegalArgumentException: Root element for infinispan already registered"}}
WAR file is created by arquillian library and contains
WebArchive war = ShrinkWrap.create(WebArchive.class, "<warName>")
.addPackages(true, new String[]{"<package with tests>"})
.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml")
.addAsLibraries(
new File("target/test-libs/jboss-marshalling.jar"),
new File("target/test-libs/jboss-marshalling-river.jar"),
new File("target/test-libs/infinispan-core.jar"), << <version.infinispan>5.3.0-SNAPSHOT</version.infinispan>
new File("target/test-libs/hibernate-core.jar"), << <version.hibernate>4.1.6.Final</version.hibernate>
new File("target/test-libs/hibernate-commons-annotations.jar"),
new File("target/test-libs/hibernate-jpa-2.0-api.jar"),
new File("target/test-libs/javassist.jar"),
new File("target/test-libs/jboss-annotations-ejb3.jar"),
new File("target/test-libs/hibernate-infinispan.jar")); << <version.hibernate>4.1.6.Final</version.hibernate>
return war;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (ISPN-2103) Concurrent access after removal of an AtomicMap should NOT result in an IllegalStateException when accessed by other threads
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2103?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2103:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.Alpha1)
> Concurrent access after removal of an AtomicMap should NOT result in an IllegalStateException when accessed by other threads
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2103
> URL: https://issues.jboss.org/browse/ISPN-2103
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 5.1.5.FINAL
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 6.0.0.Final
>
>
> ISPN-1121 introduces an IllegalStateException that is being thrown from AtomicMap methods once the map handle has become stale (ie. removed from cache). In case of concurrent access, the exception is thrown to all threads not just to the thread that performed the removal. This was fine-ish in older versions of Infinispan before introduction of optimistic and pessimistic locking but it should be reconsidered now because:
> 1. It interferes/overlaps with transaction isolation. We should rely on the selected locking scheme (OL/PL) to detect conflicts between transactions and report the problem accordingly. Especially if the stale map is used just for reading - this should be allowed to work rather than stop it.
> 2. This exception is pretty disruptive and awkward to handle. All methods of an AtomicMap can result in this exception and the current thread has to be prepared for handling it if other threads remove the map. Not much transaction isolation.
> 3. Since the TreeCache is backed by AtomicMap nearly all Tree API can throw this.
> The proposed fix consists of:
> 1. removing AtomicHashMap.removed flag and AtomicHashMap.markRemoved() method.
> 2. revising AtomicHashMapProxy.assertValid() method to check only if the map is null (ie. removed) but no longer use the removed flag.
> 3. revising ReadCommittedEntry.commit() method to no longer call markRemoved() method.
> The consequences of these changes are:
> 1. Any further access to a stale map results in IllegalStateException ONLY in the thread that performed the removal. This thread 'knows' the map is stale so it is fine to punish it. Other threads remain unaffected until lock acquisition or commit is performed (depending on locking model).
> 2. Other threads can continue to use the previously obtained map handle for reads without danger of getting an exception.
> 3. If a write operation is done on the map, the results depend on the locking model:
> 3.1 optimistic locking + write skew check: a WriteSkewException will stop the commit during prepare
> 3.2 optimistic locking, no write skew check: the write is committed and the work of the transaction that removed the map is overwritten. The map is effectively revived.
> 3.3 pessimistic locking: same as 3.2
> Please note 3.2 and 3.3 work the same as for normal values (not atomic maps).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (ISPN-3184) The DELTA_WRITE flag should force a remote get during state transfer
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3184?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3184:
--------------------------------
Affects Version/s: 5.3.0.Final
> The DELTA_WRITE flag should force a remote get during state transfer
> --------------------------------------------------------------------
>
> Key: ISPN-3184
> URL: https://issues.jboss.org/browse/ISPN-3184
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.3.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 6.0.0.Final
>
>
> AtomicHashMap and FineGrainedAtomicHashMap, as well as custom DeltaAware implementations, use PutKeyValueCommands with the DELTA_WRITE flag to execute incremental updates. These commands need the previous value of the entry in order to work.
> If a node is joining and it receives a PutKeyValueCommand with the DELTA_WRITE flag before it has received the value of the affected key, it should do a remote get to retrieve the previous value and apply the change on top of that value, just like we do for conditional commands. Not doing so leads to data loss.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (ISPN-3184) The DELTA_WRITE flag should force a remote get during state transfer
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3184?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3184:
--------------------------------
Priority: Critical (was: Major)
> The DELTA_WRITE flag should force a remote get during state transfer
> --------------------------------------------------------------------
>
> Key: ISPN-3184
> URL: https://issues.jboss.org/browse/ISPN-3184
> Project: Infinispan
> Issue Type: Bug
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 6.0.0.Final
>
>
> AtomicHashMap and FineGrainedAtomicHashMap, as well as custom DeltaAware implementations, use PutKeyValueCommands with the DELTA_WRITE flag to execute incremental updates. These commands need the previous value of the entry in order to work.
> If a node is joining and it receives a PutKeyValueCommand with the DELTA_WRITE flag before it has received the value of the affected key, it should do a remote get to retrieve the previous value and apply the change on top of that value, just like we do for conditional commands. Not doing so leads to data loss.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months