[JBoss JIRA] (ISPN-6137) ScriptMetadataTest.testBrokenParameters fails since the logging range changes
by Dan Berindei (JIRA)
Dan Berindei created ISPN-6137:
----------------------------------
Summary: ScriptMetadataTest.testBrokenParameters fails since the logging range changes
Key: ISPN-6137
URL: https://issues.jboss.org/browse/ISPN-6137
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Server
Affects Versions: 8.2.0.Beta1
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 8.2.0.CR1
The ISPN-6123 fix changed the logging ids for the scripting module, breaking `ScriptMetadataTest.testBrokenParameters`:
{noformat}
The exception was thrown with the wrong message: expected "^ISPN021011.*" but got "ISPN026011: Script parameters must be declared using the array notation, e.g. [a,b,c]"
at org.testng.internal.Invoker.handleInvocationResults(Invoker.java:1481)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:754)
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:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: ISPN026011: Script parameters must be declared using the array notation, e.g. [a,b,c]
at org.infinispan.scripting.impl.ScriptMetadataParser.unarray(ScriptMetadataParser.java:99)
at org.infinispan.scripting.impl.ScriptMetadataParser.parse(ScriptMetadataParser.java:56)
at org.infinispan.scripting.ScriptMetadataTest.testBrokenParameters(ScriptMetadataTest.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
... 14 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ISPN-6047) Deadlock when a prepare command is retried
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6047?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-6047:
-----------------------------------
This is weird [~dan.berindei]. {{txA}} should never wait for {{txB}}. see [https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...]
> Deadlock when a prepare command is retried
> ------------------------------------------
>
> Key: ISPN-6047
> URL: https://issues.jboss.org/browse/ISPN-6047
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Fix For: 8.2.0.CR1
>
>
> Looks like the ISPN-5623 fix went too far, and now I found a test failure with the opposite behaviour:
> 1. Remote prepare for {{txA}} acquires lock {{K}}
> 2. Remote prepare for {{txB}} blocks waiting for lock {{K}}
> 3. The topology changes, and the {{txA}} prepare is retried
> 4. The {{txA}} prepare times out, because it waits for pending transaction {{txB}} to finish.
> So we have to make {{txA}} somehow know that it already has the lock after it received an {{UnsureResponse}} for the prepare command, and skip waiting for pending transactions.
> I found the problem in a random failure of {{DistributedFourNodesMapReduceTest}} on a local branch, but I'm not sure if my local changes (making SyncCHF the default CH factory) made it more likely.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ISPN-6136) OptimisticLockingTxClusterExtendedStatisticLogicTest random failures with SyncConsistentHashFactory
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6136?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6136:
-------------------------------
Status: Open (was: New)
> OptimisticLockingTxClusterExtendedStatisticLogicTest random failures with SyncConsistentHashFactory
> ---------------------------------------------------------------------------------------------------
>
> Key: ISPN-6136
> URL: https://issues.jboss.org/browse/ISPN-6136
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.2.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.2.0.CR1
>
>
> {{OptimisticLockingTxClusterExtendedStatisticLogicTest}}, like {{PessimisticLockingTxClusterExtendedStatisticLogicTest}}, requires the coordinator to own the test key, and that is no longer guaranteed since {{SyncConsistentHashFactory}} became the default CH factory.
> The {{ISPN-4851}} commit included a fix for {{PessimisticLockingTxClusterExtendedStatisticLogicTest}}, and {{OptimisticLockingTxClusterExtendedStatisticLogicTest}} needs a similar fix.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ISPN-6136) OptimisticLockingTxClusterExtendedStatisticLogicTest random failures with SyncConsistentHashFactory
by Dan Berindei (JIRA)
Dan Berindei created ISPN-6136:
----------------------------------
Summary: OptimisticLockingTxClusterExtendedStatisticLogicTest random failures with SyncConsistentHashFactory
Key: ISPN-6136
URL: https://issues.jboss.org/browse/ISPN-6136
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Core
Affects Versions: 8.2.0.Beta1
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 8.2.0.CR1
{{OptimisticLockingTxClusterExtendedStatisticLogicTest}}, like {{PessimisticLockingTxClusterExtendedStatisticLogicTest}}, requires the coordinator to own the test key, and that is no longer guaranteed since {{SyncConsistentHashFactory}} became the default CH factory.
The {{ISPN-4851}} commit included a fix for {{PessimisticLockingTxClusterExtendedStatisticLogicTest}}, and {{OptimisticLockingTxClusterExtendedStatisticLogicTest}} needs a similar fix.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months