[JBoss JIRA] (ISPN-5101) Handle database restart
by yaniv oren (JIRA)
yaniv oren created ISPN-5101:
--------------------------------
Summary: Handle database restart
Key: ISPN-5101
URL: https://issues.jboss.org/browse/ISPN-5101
Project: Infinispan
Issue Type: Bug
Components: Lucene Directory
Affects Versions: 7.0.0.Alpha4
Environment: database: postgress, using hibernate search with infinispan&lucene
Reporter: yaniv oren
similar to https://issues.jboss.org/browse/ISPN-1680
scenario:
restarting database during application run.
expected:
App recovery.
Actual:
Received error:
..
Caused by: org.hibernate.search.exception.SearchException: Unable to reopen IndexReader
at org.hibernate.search.indexes.impl.SharingBufferReaderProvider$PerDirectoryLatestReader.refreshAndGet(SharingBufferReaderProvider.java:241) ~[hibernate-search-engine-5.0.0.Alpha4.jar:5.0.0.Alpha4]
at org.hibernate.search.indexes.impl.SharingBufferReaderProvider.openIndexReader(SharingBufferReaderProvider.java:72) ~[hibernate-search-engine-5.0.0.Alpha4.jar:5.0.0.Alpha4]
at org.hibernate.search.indexes.impl.SharingBufferReaderProvider.openIndexReader(SharingBufferReaderProvider.java:34) ~[hibernate-search-engine-5.0.0.Alpha4.jar:5.0.0.Alpha4]
at org.hibernate.search.reader.impl.MultiReaderFactory.openReader(MultiReaderFactory.java:36) ~[hibernate-search-engine-5.0.0.Alpha4.jar:5.0.0.Alpha4]
at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:617) ~[hibernate-search-engine-5.0.0.Alpha4.jar:5.0.0.Alpha4]
at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:517) ~[hibernate-search-engine-5.0.0.Alpha4.jar:5.0.0.Alpha4]
at org.hibernate.search.query.engine.impl.HSQueryImpl.queryEntityInfos(HSQueryImpl.java:251) ~[hibernate-search-engine-5.0.0.Alpha4.jar:5.0.0.Alpha4]
at org.hibernate.search.query.hibernate.impl.FullTextQueryImpl.list(FullTextQueryImpl.java:198) ~[hibernate-search-orm-5.0.0.Alpha4.jar:5.0.0.Alpha4]
at com.fivoosh.services.dao.AuctionDAOImpl.search(AuctionDAOImpl.java:194) ~[bin/:na]
...
Caused by: java.io.IOException: Read past EOF
at org.infinispan.lucene.impl.SingleChunkIndexInput.readByte(SingleChunkIndexInput.java:54) ~[infinispan-lucene-directory-7.0.0.Alpha4.jar:7.0.0.Alpha4]
at org.apache.lucene.store.BufferedChecksumIndexInput.readByte(BufferedChecksumIndexInput.java:41) ~[lucene-core-4.8.1.jar:4.8.1 1594670 - rmuir - 2014-05-14 19:22:52]
at org.apache.lucene.store.DataInput.readInt(DataInput.java:96) ~[lucene-core-4.8.1.jar:4.8.1 1594670 - rmuir - 2014-05-14 19:22:52]
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:331) ~[lucene-core-4.8.1.jar:4.8.1 1594670 - rmuir - 2014-05-14 19:22:52]
at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:416) ~[lucene-core-4.8.1.jar:4.8.1 1594670 - rmuir - 2014-05-14 19:22:52]
at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:864) ~[lucene-core-4.8.1.jar:4.8.1 1594670 - rmuir - 2014-05-14 19:22:52]
at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:710) ~[lucene-core-4.8.1.jar:4.8.1 1594670 - rmuir - 2014-05-14 19:22:52]
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:412) ~[lucene-core-4.8.1.jar:4.8.1 1594670 - rmuir - 2014-05-14 19:22:52]
at org.apache.lucene.index.StandardDirectoryReader.isCurrent(StandardDirectoryReader.java:347) ~[lucene-core-4.8.1.jar:4.8.1 1594670 - rmuir - 2014-05-14 19:22:52]
at org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:301) ~[lucene-core-4.8.1.jar:4.8.1 1594670 - rmuir - 2014-05-14 19:22:52]
at org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:264) ~[lucene-core-4.8.1.jar:4.8.1 1594670 - rmuir - 2014-05-14 19:22:52]
at org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:252) ~[lucene-core-4.8.1.jar:4.8.1 1594670 - rmuir - 2014-05-14 19:22:52]
at org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:171) ~[lucene-core-4.8.1.jar:4.8.1 1594670 - rmuir - 2014-05-14 19:22:52]
at org.hibernate.search.indexes.impl.SharingBufferReaderProvider$PerDirectoryLatestReader.refreshAndGet(SharingBufferReaderProvider.java:238) ~[hibernate-search-engine-5.0.0.Alpha4.jar:5.0.0.Alpha4]
... 121 common frames omitted
...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-4801) ConcurrentModificationException on the FileListCacheValue
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4801?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4801:
-----------------------------------------------
Roman Macor <rmacor(a)redhat.com> changed the Status of [bug 1166028|https://bugzilla.redhat.com/show_bug.cgi?id=1166028] from ON_QA to VERIFIED
> ConcurrentModificationException on the FileListCacheValue
> ---------------------------------------------------------
>
> Key: ISPN-4801
> URL: https://issues.jboss.org/browse/ISPN-4801
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 7.0.0.Beta2
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Critical
> Fix For: 7.0.0.CR1
>
>
> Since ISPN-4692 that made FileListCacheValue DeltaAware, the following is happening when running {{org.infinispan.lucene.profiling.PerformanceCompareStressTest}}:
> {code}
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:922)
> at java.util.HashMap$KeyIterator.next(HashMap.java:956)
> at java.util.AbstractCollection.toArray(AbstractCollection.java:195)
> at org.infinispan.lucene.impl.FileListCacheValue.toArray(FileListCacheValue.java:109)
> at org.infinispan.lucene.impl.FileListOperations.listFilenames(FileListOperations.java:101)
> at org.infinispan.lucene.impl.DirectoryImplementor.list(DirectoryImplementor.java:56)
> at org.infinispan.lucene.impl.DirectoryLuceneV4.listAll(DirectoryLuceneV4.java:123)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:759)
> {code}
> The problem is that the deltas are not being applied in a thread safe manner
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-4692) Optimize externalizer for FileListCacheValue
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4692?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4692:
-----------------------------------------------
Roman Macor <rmacor(a)redhat.com> changed the Status of [bug 1166028|https://bugzilla.redhat.com/show_bug.cgi?id=1166028] from ON_QA to VERIFIED
> Optimize externalizer for FileListCacheValue
> --------------------------------------------
>
> Key: ISPN-4692
> URL: https://issues.jboss.org/browse/ISPN-4692
> Project: Infinispan
> Issue Type: Enhancement
> Components: Lucene Directory
> Reporter: Sanne Grinovero
> Assignee: Gustavo Fernandes
> Fix For: 7.0.0.CR1
>
>
> There are two possible improvements to be applied to the Externalizer strategy applied by FileListCacheValue.
> - Each String is being encoded (and decoded) in UTF8 format, which is expensive. We should explore alternative encodings to String - at least for the wire format.
> - This is an ideal case for Delta operations: on each modification just one entry of the map is added / removed, but the whole HashMap is being transferred at each write.
> I'm not sure how we can combine the Delta interface with custom Externalizers, so that will need to be explored.
> We might want to avoid storing it as a value and resort to custom RPC commands to transfer the needed bits only, but we don't want to reimplement state transfer and CacheStore storage.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-4746) NPE when preloading cache with DeltaAware values
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4746?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4746:
-----------------------------------------------
Roman Macor <rmacor(a)redhat.com> changed the Status of [bug 1166028|https://bugzilla.redhat.com/show_bug.cgi?id=1166028] from ON_QA to VERIFIED
> NPE when preloading cache with DeltaAware values
> ------------------------------------------------
>
> Key: ISPN-4746
> URL: https://issues.jboss.org/browse/ISPN-4746
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.2.Final, 7.0.0.Beta2
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 7.0.0.CR1, 7.0.0.Final
>
>
> {code:java}
> public class DeltaAwarePreloadTest extends MultipleCacheManagersTest {
> private static final int CLUSTER_SIZE = 1;
> @Override
> protected void createCacheManagers() throws Throwable {
> ConfigurationBuilder c = getDefaultClusteredCacheConfig(CacheMode.DIST_SYNC, false);
> c.persistence().addStore(new DummyInMemoryStoreConfigurationBuilder(c.persistence()).storeName(getClass().getSimpleName())).preload(true);
> createCluster(c, CLUSTER_SIZE);
> waitForClusterToForm();
> }
> @Test
> public void testPreloadOnStart() throws PersistenceException {
> Cache<Object, Object> cache = caches().get(0);
> cache.put(1, new TestDeltaAware());
> cache.stop();
> cache.start();
> }
> }
> {code}
> During preload, the {{NonTxDistributionInterceptor}} decides that is requires values from previous owners and tries to check if the local node is the primary owner. At this point, the WriteCH is null since no topology was ever updated. Here's the stacktrace:
> {code}
> Caused by: org.infinispan.persistence.spi.PersistenceException: Unable to preload!
> at org.infinispan.persistence.manager.PersistenceManagerImpl.preloadKey(PersistenceManagerImpl.java:620)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.access$000(PersistenceManagerImpl.java:70)
> at org.infinispan.persistence.manager.PersistenceManagerImpl$1.processEntry(PersistenceManagerImpl.java:228)
> at org.infinispan.persistence.dummy.DummyInMemoryStore.process(DummyInMemoryStore.java:165)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:220)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> ... 37 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.distribution.impl.DistributionManagerImpl.getWriteConsistentHash(DistributionManagerImpl.java:115)
> at org.infinispan.distribution.impl.DistributionManagerImpl.getConsistentHash(DistributionManagerImpl.java:105)
> at org.infinispan.distribution.impl.DistributionManagerImpl.getPrimaryLocation(DistributionManagerImpl.java:95)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$DistributionLogic.localNodeIsPrimaryOwner(ClusteringDependentLogic.java:395)
> at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.remoteGetBeforeWrite(NonTxDistributionInterceptor.java:131)
> at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.handleNonTxWriteCommand(BaseDistributionInterceptor.java:195)
> at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitPutKeyValueCommand(NonTxDistributionInterceptor.java:72)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.DistCacheWriterInterceptor.visitPutKeyValueCommand(DistCacheWriterInterceptor.java:72)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitPutKeyValueCommand(CacheLoaderInterceptor.java:113)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:376)
> at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:464)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-5001) NPE on preload with tx caches containing DeltaAware values
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5001?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5001:
-----------------------------------------------
Roman Macor <rmacor(a)redhat.com> changed the Status of [bug 1166028|https://bugzilla.redhat.com/show_bug.cgi?id=1166028] from ON_QA to VERIFIED
> NPE on preload with tx caches containing DeltaAware values
> ----------------------------------------------------------
>
> Key: ISPN-5001
> URL: https://issues.jboss.org/browse/ISPN-5001
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.0.0.Final, 7.0.2.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 7.1.0.Alpha1
>
>
> A similar bug was fixed for non-tx caches on ISPN-4746
> To reproduce the issue, change the {{DeltaAwarePreloadTest}} to use transactional cache.
> Error:
> {code}
> org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:813)
> at org.infinispan.distribution.DeltaAwarePreloadTest.testPreloadOnStart(DeltaAwarePreloadTest.java:38)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:343)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305)
> at org.testng.SuiteRunner.run(SuiteRunner.java:254)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
> at org.testng.TestNG.run(TestNG.java:1057)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
> at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
> at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:125)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> Caused by: org.infinispan.persistence.spi.PersistenceException: Unable to preload!
> at org.infinispan.persistence.manager.PersistenceManagerImpl.preloadKey(PersistenceManagerImpl.java:633)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.access$000(PersistenceManagerImpl.java:70)
> at org.infinispan.persistence.manager.PersistenceManagerImpl$1.processEntry(PersistenceManagerImpl.java:232)
> at org.infinispan.persistence.dummy.DummyInMemoryStore.process(DummyInMemoryStore.java:165)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:224)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> ... 37 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.distribution.impl.DistributionManagerImpl.getReadConsistentHash(DistributionManagerImpl.java:110)
> at org.infinispan.interceptors.distribution.TxDistributionInterceptor.remoteGet(TxDistributionInterceptor.java:319)
> at org.infinispan.interceptors.distribution.TxDistributionInterceptor.remoteGetBeforeWrite(TxDistributionInterceptor.java:311)
> at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:269)
> at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitPutKeyValueCommand(TxDistributionInterceptor.java:105)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-5088) Deleted entries from (FineGrained)AtomicMap reappear in subsequent transaction
by Emmanuel Bernard (JIRA)
[ https://issues.jboss.org/browse/ISPN-5088?page=com.atlassian.jira.plugin.... ]
Emmanuel Bernard edited comment on ISPN-5088 at 12/18/14 7:45 AM:
------------------------------------------------------------------
I don't know why and how but our Hibernate OGM usage (which I thought was synthesized with the test Sanne pushed) was working fine in ISPN 6 and was failing in ISPN 7. So something changed :)
was (Author: epbernard):
I don't to why and how but our Hibernate OGM usage (which I thought was synthesized with the test Sanne pushed) was working fine in ISPN 6 and was failing in ISPN 7. So something changed :)
> Deleted entries from (FineGrained)AtomicMap reappear in subsequent transaction
> ------------------------------------------------------------------------------
>
> Key: ISPN-5088
> URL: https://issues.jboss.org/browse/ISPN-5088
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.0.2.Final
> Reporter: Sanne Grinovero
> Assignee: William Burns
> Priority: Critical
> Labels: for_OGM
> Attachments: Testcase-ISPN-5088.patch
>
>
> After a {{FineGrainedAtomicMap}} containing some data is deleted in a transaction, but then in the same transaction it's re-created, the next transaction will be able to read the original data which it contained.
> Some pseudocode:
> {code}tx1.start();
> am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true );
> am.put(k1, v1);
> tx1.commit()
> tx2.start();
> am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true );
> am.put(k3, v3);
> AtomicMapLookup.removeAtomicMap( cache, cacheKey );
> am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true );
> am.put(k2,v2);
> tx2.commit()
> tx3.start();
> am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true );
> am.contains(k1) == false; // FAILS!
> tx3.commit();{code}
> Also applies apparently to a normal AtomicMap if using DIST_SYNC.
> I'm attaching a full test, which results in:
> {noformat}
> Failed tests:
> RepeatableReadFineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> FineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> DistFineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> DistRepeatableReadFineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> DistRepeatableReadAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> DistAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> Tests run: 5636, Failures: 6, Errors: 0, Skipped: 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-5100) Failover without @ClientCacheFailover fails with NPE in Hot Rod client
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-5100:
--------------------------------------
Summary: Failover without @ClientCacheFailover fails with NPE in Hot Rod client
Key: ISPN-5100
URL: https://issues.jboss.org/browse/ISPN-5100
Project: Infinispan
Issue Type: Bug
Components: Remote Protocols
Affects Versions: 7.1.0.Alpha1, 7.0.2.Final
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 7.1.0.Beta1, 7.1.0.Final
Hot Rod client raises a NullPointerException if a failover happens but the client listener has no @ClientCacheFailover callbacks defined.
{code}
java.lang.NullPointerException
at org.infinispan.client.hotrod.event.ClientListenerNotifier.invokeFailoverEvent(ClientListenerNotifier.java:108)
at org.infinispan.client.hotrod.event.ClientListenerNotifier.failoverClientListeners(ClientListenerNotifier.java:94)
at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.updateServers(TcpTransportFactory.java:330)
at org.infinispan.client.hotrod.impl.protocol.Codec20.readNewTopologyAndHash(Codec20.java:390)
at org.infinispan.client.hotrod.impl.protocol.Codec20.readNewTopologyIfPresent(Codec20.java:357)
at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:104)
at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:97)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-5088) Deleted entries from (FineGrained)AtomicMap reappear in subsequent transaction
by Emmanuel Bernard (JIRA)
[ https://issues.jboss.org/browse/ISPN-5088?page=com.atlassian.jira.plugin.... ]
Emmanuel Bernard commented on ISPN-5088:
----------------------------------------
I don't to why and how but our Hibernate OGM usage (which I thought was synthesized with the test Sanne pushed) was working fine in ISPN 6 and was failing in ISPN 7. So something changed :)
> Deleted entries from (FineGrained)AtomicMap reappear in subsequent transaction
> ------------------------------------------------------------------------------
>
> Key: ISPN-5088
> URL: https://issues.jboss.org/browse/ISPN-5088
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.0.2.Final
> Reporter: Sanne Grinovero
> Assignee: William Burns
> Priority: Critical
> Labels: for_OGM
> Attachments: Testcase-ISPN-5088.patch
>
>
> After a {{FineGrainedAtomicMap}} containing some data is deleted in a transaction, but then in the same transaction it's re-created, the next transaction will be able to read the original data which it contained.
> Some pseudocode:
> {code}tx1.start();
> am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true );
> am.put(k1, v1);
> tx1.commit()
> tx2.start();
> am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true );
> am.put(k3, v3);
> AtomicMapLookup.removeAtomicMap( cache, cacheKey );
> am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true );
> am.put(k2,v2);
> tx2.commit()
> tx3.start();
> am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true );
> am.contains(k1) == false; // FAILS!
> tx3.commit();{code}
> Also applies apparently to a normal AtomicMap if using DIST_SYNC.
> I'm attaching a full test, which results in:
> {noformat}
> Failed tests:
> RepeatableReadFineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> FineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> DistFineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> DistRepeatableReadFineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> DistRepeatableReadAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> DistAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> Tests run: 5636, Failures: 6, Errors: 0, Skipped: 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months