[JBoss JIRA] (ISPN-2907) File size > Integer.MAX_VALUE crashes Lucene CacheLoader
by James Aley (JIRA)
[ https://issues.jboss.org/browse/ISPN-2907?page=com.atlassian.jira.plugin.... ]
James Aley updated ISPN-2907:
-----------------------------
Affects Version/s: 4.2.1.FINAL
> File size > Integer.MAX_VALUE crashes Lucene CacheLoader
> --------------------------------------------------------
>
> Key: ISPN-2907
> URL: https://issues.jboss.org/browse/ISPN-2907
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 4.2.1.FINAL
> Environment: Linux 3.7.10, Java 1.7.0_15
> Reporter: James Aley
> Assignee: Sanne Grinovero
>
> The Lucene CacheLoader can crash because of java.lang.NegativeArraySizeException caused by integer truncation when file sizes are over Integer.MAX_VALUE. We probably shouldn't cast the file length to int, to avoid this?
> Caused by: org.infinispan.loaders.CacheLoaderException: ISPN015008: IOException happened in the CacheLoader
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.load(DirectoryLoaderAdaptor.java:205)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.load(LuceneCacheLoader.java:75)
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:170)
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeededAndUpdateStats(CacheLoaderInterceptor.java:231)
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:112)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitGetKeyValueCommand(EntryWrappingInterceptor.java:126)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitGetKeyValueCommand(NonTransactionalLockingInterceptor.java:60)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:104)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:104)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:216)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:200)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:104)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:104)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> ... 51 more
> Caused by: java.lang.NegativeArraySizeException
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadIntern(DirectoryLoaderAdaptor.java:268)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.access$300(DirectoryLoaderAdaptor.java:49)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor$LoadVisitor.visit(DirectoryLoaderAdaptor.java:313)
> at org.infinispan.lucene.ChunkCacheKey.accept(ChunkCacheKey.java:92)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.load(DirectoryLoaderAdaptor.java:203)
> ... 81 more
--
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
13 years, 1 month
[JBoss JIRA] (ISPN-2907) File size > Integer.MAX_VALUE crashes Lucene CacheLoader
by James Aley (JIRA)
James Aley created ISPN-2907:
--------------------------------
Summary: File size > Integer.MAX_VALUE crashes Lucene CacheLoader
Key: ISPN-2907
URL: https://issues.jboss.org/browse/ISPN-2907
Project: Infinispan
Issue Type: Bug
Components: Lucene Directory
Environment: Linux 3.7.10, Java 1.7.0_15
Reporter: James Aley
Assignee: Sanne Grinovero
The Lucene CacheLoader can crash because of java.lang.NegativeArraySizeException caused by integer truncation when file sizes are over Integer.MAX_VALUE. We probably shouldn't cast the file length to int, to avoid this?
Caused by: org.infinispan.loaders.CacheLoaderException: ISPN015008: IOException happened in the CacheLoader
at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.load(DirectoryLoaderAdaptor.java:205)
at org.infinispan.lucene.cachestore.LuceneCacheLoader.load(LuceneCacheLoader.java:75)
at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:170)
at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeededAndUpdateStats(CacheLoaderInterceptor.java:231)
at org.infinispan.interceptors.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:112)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.EntryWrappingInterceptor.visitGetKeyValueCommand(EntryWrappingInterceptor.java:126)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitGetKeyValueCommand(NonTransactionalLockingInterceptor.java:60)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:104)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:104)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:216)
at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:200)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:104)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:104)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
... 51 more
Caused by: java.lang.NegativeArraySizeException
at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadIntern(DirectoryLoaderAdaptor.java:268)
at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.access$300(DirectoryLoaderAdaptor.java:49)
at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor$LoadVisitor.visit(DirectoryLoaderAdaptor.java:313)
at org.infinispan.lucene.ChunkCacheKey.accept(ChunkCacheKey.java:92)
at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.load(DirectoryLoaderAdaptor.java:203)
... 81 more
--
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
13 years, 1 month
[JBoss JIRA] (ISPN-2402) Cache operations or transactions should never fail with SuspectException
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2402?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2402:
--------------------------------
Labels: 5.2.x (was: )
> Cache operations or transactions should never fail with SuspectException
> ------------------------------------------------------------------------
>
> Key: ISPN-2402
> URL: https://issues.jboss.org/browse/ISPN-2402
> Project: Infinispan
> Issue Type: Task
> Components: RPC, State transfer
> Affects Versions: 5.2.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Labels: 5.2.x
> Fix For: 5.3.0.Beta1
>
> Attachments: vrstt.log
>
>
> This is an extension of ISPN-1896 of sorts, but for all the cache operations that are visible to the user.
> After a node leaves, the other nodes that have sent commands to that node should either ignore SuspectExceptions or, if not possible, they should retry the operation (e.g. if they didn't get any response back).
> For example, VersionReplStateTransferTest quite often on my machine with a SuspectException, because the versioned prepare command expects a response from the coordinator and the coordinator has just left.
--
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
13 years, 1 month
[JBoss JIRA] (ISPN-2504) WriteSkew check fails for entries which are inserted first time
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2504?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2504:
------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1711
> WriteSkew check fails for entries which are inserted first time
> ---------------------------------------------------------------
>
> Key: ISPN-2504
> URL: https://issues.jboss.org/browse/ISPN-2504
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.2.0.Beta3
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Fix For: 5.3.0.Final
>
>
> If optimistic locking and write skew check are configured and there are two concurrent transactions performing
> {code}
> read(key) -> null
> write(key, value)
> {code}
> one of them should fail (if both read {{null}}). However, both transaction succeed in this case. The reason is that that the {{VersionedPrepareCommand}} has {{null}} version for the key (because it was null) but in {{WriteSkewHelper.performWriteSkewCheckAndReturnNewVersions}} there is
> {code}
> EntryVersion versionSeen = prepareCommand.getVersionsSeen().get(k);
> if (versionSeen != null) entry.setVersion(versionSeen);
> {code}
> As the {{entry}} contains the version injected into context from {{dataContainer}} in {{EntryFactoryImpl.wrapInternalCacheEntryForPut}} lately during the {{VersionedPrepareCommand}} execution, and the version is not overwritten from the {{getVersionsSeen()}} value (as this is null), the performWriteSkewCheck does not report this entry as changed.
--
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
13 years, 1 month
[JBoss JIRA] (ISPN-2808) Make Infinispan use its own thread pool for sending messages in order to avoid thread deadlocks
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-2808?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-2808:
-----------------------------------
I've found out that the issue is not limited to non-transactional caches - When the tx starts before topology change and comes to nodes which are changing the topology, it resends the prepare command to all other nodes which have something to do with the transaction. With big txs (30 operations) almost all nodes might be affected, that means that we have up to cluster size * cluster size * stressor threads operations ongoing in the system, which can easily deplete the threadpool (and given ISPN-2905 these may keep blocking it).
> Make Infinispan use its own thread pool for sending messages in order to avoid thread deadlocks
> -----------------------------------------------------------------------------------------------
>
> Key: ISPN-2808
> URL: https://issues.jboss.org/browse/ISPN-2808
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Mircea Markus
> Assignee: Pedro Ruivo
> Fix For: 5.3.0.Beta1, 5.3.0.Final
>
>
> - when an OOB thread sends a sync request it blocks waiting on a sync in jgroups RequestCorrelator
> - it gets released by an another OOB thread when the remote node responds
> Now if all the OOB threads are blocked in sending, then there's no available OOB thread to unblock them even if responses from remote nodes have arrived - deadlock. In order to avoid this deadlock we can use a different thread pool for sending OOB messages.
> For a discussion around this please refer to: http://infinispan.markmail.org/search/#query:%20list%3Aorg.jboss.lists.in...
--
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
13 years, 1 month
[JBoss JIRA] (ISPN-2903) Manual eviction should not delete entry from cache store
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2903:
-----------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1710
> Manual eviction should not delete entry from cache store
> --------------------------------------------------------
>
> Key: ISPN-2903
> URL: https://issues.jboss.org/browse/ISPN-2903
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.2.3.Final
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: jdg6
> Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log
>
>
> Here's the scenario:
> Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7).
> 1. Create cache entry containing atomic map with 2 map entries on node1.
> 2. Passivate that cache entry on node2 via manual evict.
> 3. Modify 1 of the atomic map entries within the cache entry on node1.
> 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost.
> It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls.
--
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
13 years, 1 month
[JBoss JIRA] (ISPN-2906) SyncCacheListenerTest.testSyncTxRepl failing randomly
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2906?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2906:
-----------------------------------
Attachment: testSyncTxRepl-0.log
> SyncCacheListenerTest.testSyncTxRepl failing randomly
> -----------------------------------------------------
>
> Key: ISPN-2906
> URL: https://issues.jboss.org/browse/ISPN-2906
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: testsuite_stability
> Fix For: 5.3.0.Alpha1
>
> Attachments: testSyncTxRepl-0.log
>
>
> {code}testSyncTxRepl(org.infinispan.replication.SyncCacheListenerTest) Time elapsed: 0.04 sec <<< FAILURE!
> java.lang.AssertionError: "age" obtained from cache2 must be non-null
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24)
> at org.testng.AssertJUnit.assertNotNull(AssertJUnit.java:267)
> at org.infinispan.replication.SyncCacheListenerTest.testSyncTxRepl(SyncCacheListenerTest.java:99)
> 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
13 years, 1 month