[JBoss JIRA] (ISPN-4570) Remove UFC from default JGroups configuration
by Dan Berindei (JIRA)
Dan Berindei created ISPN-4570:
----------------------------------
Summary: Remove UFC from default JGroups configuration
Key: ISPN-4570
URL: https://issues.jboss.org/browse/ISPN-4570
Project: Infinispan
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Configuration, Core, Server
Affects Versions: 7.0.0.Alpha5
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 7.0.0.Beta1
The UFC protocol is not needed when the protocol is TCP, and JGroups actually logs a warning on startup:
{noformat}
12:22:37,426 INFO (testng-ReplicationExceptionTest:) [UFC] UFC is not needed (and can be removed) as we're running on a TCP transport
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4551) RestStore parallel iteration fails for non-string keys if UTF-8 is not the default charset
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4551?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4551:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.0.0.Beta1
Resolution: Done
> RestStore parallel iteration fails for non-string keys if UTF-8 is not the default charset
> ------------------------------------------------------------------------------------------
>
> Key: ISPN-4551
> URL: https://issues.jboss.org/browse/ISPN-4551
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remote Protocols, Server
> Affects Versions: 7.0.0.Alpha5
> Reporter: Ion Savin
> Assignee: Ion Savin
> Fix For: 7.0.0.Beta1
>
>
> On systems where UTF-8 is not the default charset parallel iteration over non-string keys fails.
> Non-string keys are mapped to strings prefixed by \uFEFF when the entry is stored. The key is URL-encoded and the prefix is stored properly. The GET /cacheName (all keys) response however uses the system-default charset and if that's not UTF-8 the prefix cannot be mapped and ends up being "?".
> To reproduce set the charset to ISO-8859-1 and run RestStoreParallelIterationTest and you should see failures similar to this one:
> {noformat}
> [testng-RestStoreParallelIterationTest] Test testSequentialIteration(org.infinispan.persistence.rest.RestStoreParallelIterationTest) failed.
> 10:11:27,629 ERROR [org.infinispan.test.fwk.UnitTestTestNGListener] (testng-RestStoreParallelIterationTest) Test testSequentialIteration(org.infinispan.persistence.rest.RestStoreParallelIterationTest) failed.
> org.infinispan.persistence.spi.PersistenceException: ISPN022005: Error loading entries from remote server
> at org.infinispan.persistence.rest.RestStore.process(RestStore.java:295)
> at org.infinispan.persistence.ParallelIterationTest.runIterationTest(ParallelIterationTest.java:103)
> at org.infinispan.persistence.ParallelIterationTest.testSequentialIteration(ParallelIterationTest.java:64)
> 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.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: org.infinispan.persistence.spi.PersistenceException: Execution exception!
> at org.infinispan.persistence.rest.RestStore.process(RestStore.java:292)
> ... 22 more
> Caused by: java.util.concurrent.ExecutionException: java.lang.NullPointerException
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at org.infinispan.executors.ExecutorAllCompletionService.pollUntilEmpty(ExecutorAllCompletionService.java:48)
> at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:32)
> at org.infinispan.persistence.rest.RestStore.submitProcessTask(RestStore.java:304)
> at org.infinispan.persistence.rest.RestStore.process(RestStore.java:284)
> ... 22 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.persistence.ParallelIterationTest$2.processEntry(ParallelIterationTest.java:106)
> at org.infinispan.persistence.rest.RestStore$1.call(RestStore.java:314)
> at org.infinispan.persistence.rest.RestStore$1.call(RestStore.java:304)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> at java.util.concurrent.ExecutorCompletionService.submit(ExecutorCompletionService.java:181)
> at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:31)
> ... 24 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4317) Optimize server test suite
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4317?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño resolved ISPN-4317.
------------------------------------
Fix Version/s: 7.0.0.Beta1
Resolution: Done
> Optimize server test suite
> --------------------------
>
> Key: ISPN-4317
> URL: https://issues.jboss.org/browse/ISPN-4317
> Project: Infinispan
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Test Suite - Server
> Affects Versions: 7.0.0.Alpha4
> Reporter: Martin Gencur
> Assignee: Jakub Markos
> Fix For: 7.0.0.Beta1
>
>
> The goal is to make the test execution of server test suite shorter and minimize the number of maven profiles so that most of the tests run in a default profile.
> The first thing to do is to minimize the number of server restarts when running the test suite. This will require adding many different cache configurations to the same Infinispan subsystem.
> Also, look for other ways to minimize test execution time.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4545) Checkstyle line termination check should work on Windows
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4545?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4545:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.0.0.Beta1
Resolution: Done
> Checkstyle line termination check should work on Windows
> --------------------------------------------------------
>
> Key: ISPN-4545
> URL: https://issues.jboss.org/browse/ISPN-4545
> Project: Infinispan
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 7.0.0.Alpha5
> Reporter: Ion Savin
> Assignee: Ion Savin
> Fix For: 7.0.0.Beta1
>
>
> Currently it fails when running on Windows:
> [08:51:22][org.infinispan:infinispan-checkstyle] [INFO] --- maven-checkstyle-plugin:2.10:checkstyle (check-style) @ infinispan-checkstyle ---
> [08:51:25][org.infinispan:infinispan-checkstyle] [INFO] Starting audit...
> [08:51:25][org.infinispan:infinispan-checkstyle] C:\BuildAgent\work\masterjdk7\checkstyle\src\main\java\org\infinispan\checkstyle\checks\regexp\IllegalImport.java:67: Only one new line is allowed at the end of a file
> [08:51:25][org.infinispan:infinispan-checkstyle] C:\BuildAgent\work\masterjdk7\checkstyle\src\main\java\org\infinispan\checkstyle\filters\ExcludeTestPackages.java:40: Only one new line is allowed at the end of a file
> [08:51:25][org.infinispan:infinispan-checkstyle] C:\BuildAgent\work\masterjdk7\checkstyle\src\main\java\org\infinispan\checkstyle\filters\HeadersNoCopyrightCheck.java:35: Only one new line is allowed at the end of a file
> [08:51:25][org.infinispan:infinispan-checkstyle] Audit done.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4569) Inserting into cache with indexing fails for XA transactions
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4569?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-4569:
----------------------------------
Assignee: Dan Berindei (was: Sanne Grinovero)
> Inserting into cache with indexing fails for XA transactions
> ------------------------------------------------------------
>
> Key: ISPN-4569
> URL: https://issues.jboss.org/browse/ISPN-4569
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Embedded Querying, Transactions
> Affects Versions: 7.0.0.Alpha5
> Reporter: Radim Vansa
> Assignee: Dan Berindei
>
> If I setup XA transactions in {{ClusteredQueryDslConditionsTest}} using
> {code}
> cacheCfg.transaction().transactionMode(TransactionMode.TRANSACTIONAL).useSynchronization(false);
> {code}
> the test fails. The reason is in deadlock while updating {{ScopedKey}} in __cluster_registry_cache__ : It seems that on originator we create transaction with modified inserted key and the {{ScopedKey}} for inserted class, and send it in two prepare commands to the other node. In the {{ScopedKey}}-prepare, the lock is acquired, but the regular prepare on the other node does not see it (it is not committed yet) and also tries to update this {{ScopedKey}} in __cluster_registry_cache__ . This fails with lock timeout, as the commit is waiting on the regular prepare to finish.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4569) Inserting into cache with indexing fails for XA transactions
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4569?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-4569:
---------------------------------------
Thanks [~rvansa]. It looks like a core problem, we just use the ServiceRegistry and actually never control transactions nor do locking in Query: I'll reassign it to Dan.
> Inserting into cache with indexing fails for XA transactions
> ------------------------------------------------------------
>
> Key: ISPN-4569
> URL: https://issues.jboss.org/browse/ISPN-4569
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Embedded Querying, Transactions
> Affects Versions: 7.0.0.Alpha5
> Reporter: Radim Vansa
> Assignee: Sanne Grinovero
>
> If I setup XA transactions in {{ClusteredQueryDslConditionsTest}} using
> {code}
> cacheCfg.transaction().transactionMode(TransactionMode.TRANSACTIONAL).useSynchronization(false);
> {code}
> the test fails. The reason is in deadlock while updating {{ScopedKey}} in __cluster_registry_cache__ : It seems that on originator we create transaction with modified inserted key and the {{ScopedKey}} for inserted class, and send it in two prepare commands to the other node. In the {{ScopedKey}}-prepare, the lock is acquired, but the regular prepare on the other node does not see it (it is not committed yet) and also tries to update this {{ScopedKey}} in __cluster_registry_cache__ . This fails with lock timeout, as the commit is waiting on the regular prepare to finish.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-3796) ClusteredQueryDslConditionsTest fails randomly
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3796?page=com.atlassian.jira.plugin.... ]
Adrian Nistor resolved ISPN-3796.
---------------------------------
Resolution: Cannot Reproduce Bug
This was fixed long time ago as part of ISPN-3761
> ClusteredQueryDslConditionsTest fails randomly
> ----------------------------------------------
>
> Key: ISPN-3796
> URL: https://issues.jboss.org/browse/ISPN-3796
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Embedded Querying, Test Suite - Core
> Affects Versions: 6.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
>
> See stacktrace:
> {noformat}
> testSampleDomainQuery16(org.infinispan.query.dsl.embedded.ClusteredQueryDslConditionsTest) Time elapsed: 0.143 sec <<< FAILURE!
> org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ClusteredQueryDslConditionsTest-NodeDE-6251, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:41)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:362)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:521)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:281)
> at org.infinispan.query.indexmanager.InfinispanCommandsBackend.sendCommand(InfinispanCommandsBackend.java:87)
> at org.infinispan.query.indexmanager.InfinispanCommandsBackend.applyWork(InfinispanCommandsBackend.java:81)
> at org.infinispan.query.indexmanager.MasterSwitchDelegatingQueueProcessor.applyWork(MasterSwitchDelegatingQueueProcessor.java:53)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.performOperations(DirectoryBasedIndexManager.java:126)
> at org.hibernate.search.backend.impl.WorkQueuePerIndexSplitter.commitOperations(WorkQueuePerIndexSplitter.java:63)
> at org.hibernate.search.backend.impl.BatchedQueueingProcessor.performWorks(BatchedQueueingProcessor.java:99)
> at org.hibernate.search.backend.impl.TransactionalWorker.performWork(TransactionalWorker.java:105)
> at org.infinispan.query.backend.QueryInterceptor.performSearchWorks(QueryInterceptor.java:233)
> at org.infinispan.query.backend.QueryInterceptor.performSearchWork(QueryInterceptor.java:227)
> at org.infinispan.query.backend.QueryInterceptor.updateIndexes(QueryInterceptor.java:221)
> at org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(QueryInterceptor.java:518)
> at org.infinispan.query.backend.QueryInterceptor.visitPutKeyValueCommand(QueryInterceptor.java:164)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:45)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:214)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:136)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:327)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1296)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:869)
> at org.infinispan.CacheImpl.put(CacheImpl.java:861)
> at org.infinispan.CacheImpl.put(CacheImpl.java:1349)
> at org.infinispan.CacheImpl.put(CacheImpl.java:206)
> at org.infinispan.query.dsl.embedded.ClusteredQueryDslConditionsTest.testSampleDomainQuery16(ClusteredQueryDslConditionsTest.java:1059)
> 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: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.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> Caused by: org.hibernate.search.SearchException: Error applying updates to the Lucene index
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueProcessor.applyWork(LuceneBackendQueueProcessor.java:106)
> at org.infinispan.query.indexmanager.MasterSwitchDelegatingQueueProcessor.applyWork(MasterSwitchDelegatingQueueProcessor.java:49)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.performOperations(DirectoryBasedIndexManager.java:126)
> at org.infinispan.query.indexmanager.IndexUpdateCommand.perform(IndexUpdateCommand.java:53)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:50)
> at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:172)
> ... 3 more
> Caused by: java.lang.AssertionError: file _b.fdt does not exist
> at org.apache.lucene.index.IndexWriter.filesExist(IndexWriter.java:4492)
> at org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4543)
> at org.apache.lucene.index.IndexWriter.prepareCommit(IndexWriter.java:3414)
> at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3485)
> at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3467)
> at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3451)
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.commitIndexWriter(IndexWriterHolder.java:158)
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.commitIndexWriter(IndexWriterHolder.java:171)
> at org.hibernate.search.backend.impl.lucene.ExclusiveIndexWorkspaceImpl.afterTransactionApplied(ExclusiveIndexWorkspaceImpl.java:45)
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:124)
> 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.run(FutureTask.java:262)
> ... 3 more
> Results :
> Failed tests:
> ClusteredQueryDslConditionsTest.testSampleDomainQuery16:1059 » Remote ISPN0002...
> Tests run: 1036, Failures: 1, Errors: 0, Skipped: 0
> {noformat}
> Test fails very often on RHEL
> org.infinispan.query.dsl.embedded.ClusteredQueryDslConditionsTest.testSampleDomainQuery16
> here is trace log https://www.dropbox.com/s/yvrbs2i2tvh0wzz/ClusteredQueryDslConditionsTest...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4569) Inserting into cache with indexing fails for XA transactions
by Radim Vansa (JIRA)
Radim Vansa created ISPN-4569:
---------------------------------
Summary: Inserting into cache with indexing fails for XA transactions
Key: ISPN-4569
URL: https://issues.jboss.org/browse/ISPN-4569
Project: Infinispan
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Embedded Querying, Transactions
Affects Versions: 7.0.0.Alpha5
Reporter: Radim Vansa
Assignee: Sanne Grinovero
If I setup XA transactions in {{ClusteredQueryDslConditionsTest}} using
{code}
cacheCfg.transaction().transactionMode(TransactionMode.TRANSACTIONAL).useSynchronization(false);
{code}
the test fails. The reason is in deadlock while updating {{ScopedKey}} in __cluster_registry_cache__ : It seems that on originator we create transaction with modified inserted key and the {{ScopedKey}} for inserted class, and send it in two prepare commands to the other node. In the {{ScopedKey}}-prepare, the lock is acquired, but the regular prepare on the other node does not see it (it is not committed yet) and also tries to update this {{ScopedKey}} in __cluster_registry_cache__ . This fails with lock timeout, as the commit is waiting on the regular prepare to finish.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4503) Commands with topology id 0 are not properly ignored on joiners
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4503?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4503:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Commands with topology id 0 are not properly ignored on joiners
> ---------------------------------------------------------------
>
> Key: ISPN-4503
> URL: https://issues.jboss.org/browse/ISPN-4503
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core, State Transfer
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 7.0.0.Beta1
>
>
> InboundInvocationHandlerImpl is supposed to ignore commands sent with a topology id smaller than the first topology id in which the local node was a member. But there is a loophole when the command was sent with topology id 0.
> This is visible in StateTransferFunctionalTest, where the writing thread keeps the cpu busy and can delay the 2nd node joining for a long time (especially when run on a single core with {{taskset -c 0}}). For some reason, the PrepareCommands are sent only to the local node, while the TxCompletionNotificationCommands are sent to the entire cluster ({{null}}). When the 2nd node manages to join, it receives a lot of TxCompletionNotificationCommands and processing them delays the processing of the rebalance commands. Since the writes eventually block waiting for the new topology to be installed on the joiner, the delayed rebalance commands cause the write to time out.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months