[JBoss JIRA] (ISPN-2788) NullPointerException appears in case passing null as an exclusion list to LuceneCacheLoader.loadAllKeys()
by Anna Manukyan (JIRA)
Anna Manukyan created ISPN-2788:
-----------------------------------
Summary: NullPointerException appears in case passing null as an exclusion list to LuceneCacheLoader.loadAllKeys()
Key: ISPN-2788
URL: https://issues.jboss.org/browse/ISPN-2788
Project: Infinispan
Issue Type: Bug
Components: Lucene Directory
Affects Versions: 5.2.0.Final
Reporter: Anna Manukyan
Assignee: Sanne Grinovero
NullPointerException is thrown in case of passing null as a keyExclusionList to LuceneCacheLoader.loadAllKeys() method.
The log is:
{code}
java.lang.NullPointerException
at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadSomeKeys(DirectoryLoaderAdaptor.java:108)
at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadAllKeys(DirectoryLoaderAdaptor.java:174)
at org.infinispan.lucene.cachestore.LuceneCacheLoader.loadAllKeys(LuceneCacheLoader.java:126)
at org.infinispan.lucene.cacheloader.LuceneCacheLoaderTest.testLoadAllKeysWithNullExclusion(LuceneCacheLoaderTest.java:263)
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:601)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
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:334)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{code}
--
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, 3 months
[JBoss JIRA] (ISPN-2726) Sporadic NPE in KeyAffinityServiceImpl
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2726?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2726:
--------------------------------
Fix Version/s: 5.2.1
> Sporadic NPE in KeyAffinityServiceImpl
> --------------------------------------
>
> Key: ISPN-2726
> URL: https://issues.jboss.org/browse/ISPN-2726
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.0.CR1
> Reporter: Thomas Fromm
> Assignee: Mircea Markus
> Fix For: 5.2.1, 5.3.0.Final
>
>
> The NPE appears not often, unfortunality with enabled TRACE logging, it never appears :-( I'll keep trying to get TRACEs.
> Exception in thread "pool-70-thread-1" java.lang.NullPointerException
> at org.infinispan.affinity.KeyAffinityServiceImpl.getAddressForKey(KeyAffinityServiceImpl.java:347)
> at org.infinispan.affinity.KeyAffinityServiceImpl.access$700(KeyAffinityServiceImpl.java:59)
> at org.infinispan.affinity.KeyAffinityServiceImpl$KeyGeneratorWorker.generateKeys(KeyAffinityServiceImpl.java:270)
> at org.infinispan.affinity.KeyAffinityServiceImpl$KeyGeneratorWorker.run(KeyAffinityServiceImpl.java:242)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
--
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, 3 months
[JBoss JIRA] (ISPN-2719) Tx complete notification and prepare crossing leads to failed transaction
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2719?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2719:
-------------------------------------
[~galderz][~dan.berindei] The tx completion notification is only sent *after* the prepare is finished, there must be something else there. Logs should help.
> Tx complete notification and prepare crossing leads to failed transaction
> -------------------------------------------------------------------------
>
> Key: ISPN-2719
> URL: https://issues.jboss.org/browse/ISPN-2719
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.2.0.CR2
> Reporter: Galder Zamarreño
> Assignee: Mircea Markus
> Priority: Critical
> Fix For: 5.2.1, 5.3.0.Final
>
> Attachments: testRemoteCacheListener-5.log
>
>
> {code}testRemoteCacheListener(org.infinispan.replication.SyncCacheListenerTest) Time elapsed: 0.059 sec <<< FAILURE!
> org.infinispan.CacheException: Could not commit implicit transaction
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1159)
> at org.infinispan.CacheImpl.removeInternal(CacheImpl.java:310)
> at org.infinispan.CacheImpl.remove(CacheImpl.java:304)
> at org.infinispan.CacheImpl.remove(CacheImpl.java:298)
> at org.infinispan.replication.SyncCacheListenerTest.testRemoteCacheListener(SyncCacheListenerTest.java:113)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> 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:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:680)
> Caused by: javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1177)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1156)
> ... 25 more{code}
--
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, 3 months
[JBoss JIRA] (ISPN-2782) Query on the cache with Invalidation mode fails
by Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-2782?page=com.atlassian.jira.plugin.... ]
Anna Manukyan updated ISPN-2782:
--------------------------------
Affects Version/s: 5.2.0.Final
> Query on the cache with Invalidation mode fails
> -----------------------------------------------
>
> Key: ISPN-2782
> URL: https://issues.jboss.org/browse/ISPN-2782
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 5.2.0.Final
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Attachments: ClusteredInvalidationCacheTest.java
>
>
> Assume that we have 2 nodes. node1 contains data entries, node2 doesn't.
> When configuring cache in the following way:
> {code}
> ConfigurationBuilder cacheCfg = getDefaultClusteredCacheConfig(CacheMode.INVALIDATION_SYNC, false);
> cacheCfg.indexing()
> .enable()
> .indexLocalOnly(true)
> .addProperty("default.directory_provider", "infinispan")
> .addProperty("default.indexmanager", "org.infinispan.query.indexmanager.InfinispanIndexManager")
> .addProperty("lucene_version", "LUCENE_CURRENT")
> .addProperty("default.exclusive_index_use", "false");
> List<Cache<String, Person>> caches = createClusteredCaches(2, cacheCfg);
> {code}
> And running query on node1 cache, the following exception appears:
> {code}
> org.hibernate.search.SearchException: Unable to reopen IndexReader
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider$PerDirectoryLatestReader.refreshAndGet(SharingBufferReaderProvider.java:253)
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider.openIndexReader(SharingBufferReaderProvider.java:85)
> at org.hibernate.search.reader.impl.MultiReaderFactory.openReader(MultiReaderFactory.java:49)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:612)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:511)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.queryEntityInfos(HSQueryImpl.java:249)
> at org.infinispan.query.impl.CacheQueryImpl.list(CacheQueryImpl.java:170)
> at org.infinispan.query.blackbox.ClusteredInvalidationCacheTest.testSimple(ClusteredInvalidationCacheTest.java:126)
> 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:601)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> 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:334)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
> at org.testng.SuiteRunner.run(SuiteRunner.java:240)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1198)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1123)
> at org.testng.TestNG.run(TestNG.java:1031)
> 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:111)
> 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:601)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: org.apache.lucene.index.IndexNotFoundException: no segments* file found in InfinispanDirectory{indexName='person'}: files: []
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:667)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
> at org.apache.lucene.index.SegmentInfos.readCurrentVersion(SegmentInfos.java:483)
> at org.apache.lucene.index.DirectoryReader.isCurrent(DirectoryReader.java:891)
> at org.apache.lucene.index.DirectoryReader.doOpenNoWriter(DirectoryReader.java:455)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:434)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:375)
> at org.apache.lucene.index.IndexReader.openIfChanged(IndexReader.java:508)
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider$PerDirectoryLatestReader.refreshAndGet(SharingBufferReaderProvider.java:250)
> ... 37 more
> {code}
> Additionally, in case if "default.exclusive_index_use" property is set to true or just not set (default is true), then the additionally this exception appears:
> {code}
> 2013-01-31 17:28:51,850 ERROR [LogErrorHandler] (Hibernate Search: Index updates queue processor for index person-1) HSEARCH000058: Exception occurred org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@467110d4
> Primary Failure:
> Entity org.infinispan.query.test.Person Id S:BigGoat Work Type org.hibernate.search.backend.UpdateLuceneWork
> org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@467110d4
> at org.apache.lucene.store.Lock.obtain(Lock.java:84)
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1098)
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.createNewIndexWriter(IndexWriterHolder.java:148)
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.getIndexWriter(IndexWriterHolder.java:115)
> at org.hibernate.search.backend.impl.lucene.AbstractWorkspaceImpl.getIndexWriter(AbstractWorkspaceImpl.java:117)
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:99)
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.run(LuceneBackendQueueTask.java:67)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2013-01-31 17:28:51,852 ERROR [LuceneBackendQueueTask] (Hibernate Search: Index updates queue processor for index person-1) HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync!
> 2013-01-31 17:28:52,857 ERROR [LogErrorHandler] (Hibernate Search: Index updates queue processor for index person-1) HSEARCH000058: Exception occurred org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@467110d4
> Primary Failure:
> Entity org.infinispan.query.test.Person Id S:MiniGoat Work Type org.hibernate.search.backend.UpdateLuceneWork
> org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@467110d4
> at org.apache.lucene.store.Lock.obtain(Lock.java:84)
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1098)
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.createNewIndexWriter(IndexWriterHolder.java:148)
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.getIndexWriter(IndexWriterHolder.java:115)
> at org.hibernate.search.backend.impl.lucene.AbstractWorkspaceImpl.getIndexWriter(AbstractWorkspaceImpl.java:117)
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:99)
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.run(LuceneBackendQueueTask.java:67)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2013-01-31 17:28:52,858 ERROR [LuceneBackendQueueTask] (Hibernate Search: Index updates queue processor for index person-1) HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync!
> {code}
> You can find the tests attached.
--
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, 3 months
[JBoss JIRA] (ISPN-2781) NPE in AbstractTopologyAwareEncoder1x
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2781?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2781:
--------------------------------
Assignee: Galder Zamarreño (was: Tristan Tarrant)
> NPE in AbstractTopologyAwareEncoder1x
> -------------------------------------
>
> Key: ISPN-2781
> URL: https://issues.jboss.org/browse/ISPN-2781
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 5.2.0.CR3
> Reporter: Michal Linhard
> Assignee: Galder Zamarreño
> Fix For: 5.2.1, 5.3.0.Final
>
>
> got this in an elasticity test (32nodes)
> {code}
> 06:23:20,660 ERROR [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-151) ISPN005009: Unexpected error before any request parameters read: java.lang.NullPointerException
> at org.infinispan.server.hotrod.AbstractTopologyAwareEncoder1x$$anonfun$writeHashTopologyUpdate11$3.apply(AbstractTopologyAwareEncoder1x.scala:102) [infinispan-server-hotrod-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.server.hotrod.AbstractTopologyAwareEncoder1x$$anonfun$writeHashTopologyUpdate11$3.apply(AbstractTopologyAwareEncoder1x.scala:101) [infinispan-server-hotrod-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
> at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:47)
> at org.infinispan.server.hotrod.AbstractTopologyAwareEncoder1x.writeHashTopologyUpdate11(AbstractTopologyAwareEncoder1x.scala:101) [infinispan-server-hotrod-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.server.hotrod.AbstractTopologyAwareEncoder1x.writeHashTopologyUpdate(AbstractTopologyAwareEncoder1x.scala:52) [infinispan-server-hotrod-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.server.hotrod.AbstractEncoder1x.writeHeader(AbstractEncoder1x.scala:63) [infinispan-server-hotrod-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.server.hotrod.HotRodEncoder.encode(HotRodEncoder.scala:63) [infinispan-server-hotrod-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.jboss.netty.handler.codec.oneone.OneToOneEncoder.doEncode(OneToOneEncoder.java:66) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:59) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.Channels.write(Channels.java:704) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.Channels.write(Channels.java:671) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:248) [netty-3.6.1.Final.jar:]
> at org.infinispan.server.core.AbstractProtocolDecoder.writeResponse(AbstractProtocolDecoder.scala:179) [infinispan-server-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.server.hotrod.HotRodDecoder.customDecodeHeader(HotRodDecoder.scala:157) [infinispan-server-hotrod-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeHeader(AbstractProtocolDecoder.scala:105) [infinispan-server-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:70) [infinispan-server-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:47) [infinispan-server-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:500) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435) [netty-3.6.1.Final.jar:]
> at org.infinispan.server.core.AbstractProtocolDecoder.messageReceived(AbstractProtocolDecoder.scala:387) [infinispan-server-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:313) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [netty-3.6.1.Final.jar:]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> {code}
--
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, 3 months
[JBoss JIRA] (ISPN-2783) Query on Invalidation cache fails in case of non-InfinispanDirectoryProvider
by Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-2783?page=com.atlassian.jira.plugin.... ]
Anna Manukyan updated ISPN-2783:
--------------------------------
Affects Version/s: 5.2.0.Final
> Query on Invalidation cache fails in case of non-InfinispanDirectoryProvider
> ----------------------------------------------------------------------------
>
> Key: ISPN-2783
> URL: https://issues.jboss.org/browse/ISPN-2783
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 5.2.0.Final
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Fix For: 5.2.1, 5.3.0.Final
>
> Attachments: ClusteredInvalidationCacheTest.java
>
>
> Assume that node1 contains entries, node2 doesn't. And assume, that the cache on both nodes is configured as:
> {code}
> ConfigurationBuilder cacheCfg = getDefaultClusteredCacheConfig(CacheMode.INVALIDATION_SYNC, false);
> cacheCfg.indexing()
> .enable()
> .indexLocalOnly(true)
> .addProperty("default.directory_provider", "ram")
> .addProperty("lucene_version", "LUCENE_CURRENT") ;
>
> List<Cache<String, Person>> caches = createClusteredCaches(2, cacheCfg);
> {code}
> If I'm running the query on node1, then the query proceeds properly.
> If I'm running the query on node2, then I'm getting the following exception:
> {code}
> org.hibernate.search.SearchException: There are no mapped entities. Don't forget to add @Indexed to at least one class.
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:534)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:511)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.queryEntityInfos(HSQueryImpl.java:249)
> at org.infinispan.query.impl.CacheQueryImpl.list(CacheQueryImpl.java:170)
> at org.infinispan.query.blackbox.ClusteredInvalidationCacheTest.testSimple(ClusteredInvalidationCacheTest.java:119)
> {code}
> You can find the test attached.
--
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, 3 months
[JBoss JIRA] (ISPN-2786) ThreadLocal memory leak in Tomcat
by Johann Burkard (JIRA)
[ https://issues.jboss.org/browse/ISPN-2786?page=com.atlassian.jira.plugin.... ]
Johann Burkard commented on ISPN-2786:
--------------------------------------
Tomcat has a {{ThreadLocalLeakPreventionListener}} that prints non-cleared ThreadLocals during application un-deployment.
In other words, if you deploy an app that leaks Threads in Tomcat, you'll notice during shutdown, re- or un-deployment.
Not sure if nulling ThreadLocals will help. The magic method is {{ThreadLocal#remove()}}.
> ThreadLocal memory leak in Tomcat
> ---------------------------------
>
> Key: ISPN-2786
> URL: https://issues.jboss.org/browse/ISPN-2786
> Project: Infinispan
> Issue Type: Bug
> Components: Marshalling, Transactions
> Affects Versions: 5.1.8.Final
> Reporter: Johann Burkard
> Assignee: Galder Zamarreño
> Labels: leak, local, memory, thread, threadlocal
>
> Just started an app using Infinispan 5.1.8.Final on Tomcat and got a few ThreadLocal problems during un-deployment:
> (Shortened)
> {code}
> key=org.jboss.marshalling.UTFUtils.BytesHolder
> value=org.jboss.marshalling.UTFUtils$BytesHolder@697a1686
> key=java.lang.ThreadLocal@36ed5ba6
> value=org.infinispan.context.SingleKeyNonTxInvocationContext{flags=null}
> key=org.infinispan.marshall.jboss.AbstractJBossMarshaller$1
> value=org.infinispan.marshall.jboss.AbstractJBossMarshaller$1@75f10df7
> value=org.infinispan.marshall.jboss.AbstractJBossMarshaller.PerThreadInstanceHolder
> {code}
> I do call {{DefaultCacheManager#shutdown()}} during un-deployment. :)
> Thanks
--
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, 3 months
[JBoss JIRA] (ISPN-2781) NPE in AbstractTopologyAwareEncoder1x
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2781?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2781:
--------------------------------
Fix Version/s: 5.2.1
5.3.0.Final
> NPE in AbstractTopologyAwareEncoder1x
> -------------------------------------
>
> Key: ISPN-2781
> URL: https://issues.jboss.org/browse/ISPN-2781
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 5.2.0.CR3
> Reporter: Michal Linhard
> Assignee: Tristan Tarrant
> Fix For: 5.2.1, 5.3.0.Final
>
>
> got this in an elasticity test (32nodes)
> {code}
> 06:23:20,660 ERROR [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-151) ISPN005009: Unexpected error before any request parameters read: java.lang.NullPointerException
> at org.infinispan.server.hotrod.AbstractTopologyAwareEncoder1x$$anonfun$writeHashTopologyUpdate11$3.apply(AbstractTopologyAwareEncoder1x.scala:102) [infinispan-server-hotrod-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.server.hotrod.AbstractTopologyAwareEncoder1x$$anonfun$writeHashTopologyUpdate11$3.apply(AbstractTopologyAwareEncoder1x.scala:101) [infinispan-server-hotrod-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
> at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:47)
> at org.infinispan.server.hotrod.AbstractTopologyAwareEncoder1x.writeHashTopologyUpdate11(AbstractTopologyAwareEncoder1x.scala:101) [infinispan-server-hotrod-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.server.hotrod.AbstractTopologyAwareEncoder1x.writeHashTopologyUpdate(AbstractTopologyAwareEncoder1x.scala:52) [infinispan-server-hotrod-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.server.hotrod.AbstractEncoder1x.writeHeader(AbstractEncoder1x.scala:63) [infinispan-server-hotrod-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.server.hotrod.HotRodEncoder.encode(HotRodEncoder.scala:63) [infinispan-server-hotrod-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.jboss.netty.handler.codec.oneone.OneToOneEncoder.doEncode(OneToOneEncoder.java:66) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:59) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.Channels.write(Channels.java:704) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.Channels.write(Channels.java:671) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:248) [netty-3.6.1.Final.jar:]
> at org.infinispan.server.core.AbstractProtocolDecoder.writeResponse(AbstractProtocolDecoder.scala:179) [infinispan-server-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.server.hotrod.HotRodDecoder.customDecodeHeader(HotRodDecoder.scala:157) [infinispan-server-hotrod-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeHeader(AbstractProtocolDecoder.scala:105) [infinispan-server-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:70) [infinispan-server-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:47) [infinispan-server-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:500) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435) [netty-3.6.1.Final.jar:]
> at org.infinispan.server.core.AbstractProtocolDecoder.messageReceived(AbstractProtocolDecoder.scala:387) [infinispan-server-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:313) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88) [netty-3.6.1.Final.jar:]
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [netty-3.6.1.Final.jar:]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> {code}
--
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, 3 months
[JBoss JIRA] (ISPN-2783) Query on Invalidation cache fails in case of non-InfinispanDirectoryProvider
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2783?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2783:
--------------------------------
Fix Version/s: 5.2.1
5.3.0.Final
> Query on Invalidation cache fails in case of non-InfinispanDirectoryProvider
> ----------------------------------------------------------------------------
>
> Key: ISPN-2783
> URL: https://issues.jboss.org/browse/ISPN-2783
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Fix For: 5.2.1, 5.3.0.Final
>
> Attachments: ClusteredInvalidationCacheTest.java
>
>
> Assume that node1 contains entries, node2 doesn't. And assume, that the cache on both nodes is configured as:
> {code}
> ConfigurationBuilder cacheCfg = getDefaultClusteredCacheConfig(CacheMode.INVALIDATION_SYNC, false);
> cacheCfg.indexing()
> .enable()
> .indexLocalOnly(true)
> .addProperty("default.directory_provider", "ram")
> .addProperty("lucene_version", "LUCENE_CURRENT") ;
>
> List<Cache<String, Person>> caches = createClusteredCaches(2, cacheCfg);
> {code}
> If I'm running the query on node1, then the query proceeds properly.
> If I'm running the query on node2, then I'm getting the following exception:
> {code}
> org.hibernate.search.SearchException: There are no mapped entities. Don't forget to add @Indexed to at least one class.
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:534)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:511)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.queryEntityInfos(HSQueryImpl.java:249)
> at org.infinispan.query.impl.CacheQueryImpl.list(CacheQueryImpl.java:170)
> at org.infinispan.query.blackbox.ClusteredInvalidationCacheTest.testSimple(ClusteredInvalidationCacheTest.java:119)
> {code}
> You can find the test attached.
--
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, 3 months