[JBoss JIRA] (ISPN-7961) Cross-site replication of functional commands
by Radim Vansa (JIRA)
Radim Vansa created ISPN-7961:
---------------------------------
Summary: Cross-site replication of functional commands
Key: ISPN-7961
URL: https://issues.jboss.org/browse/ISPN-7961
Project: Infinispan
Issue Type: Task
Components: Core, Cross-Site Replication
Affects Versions: 9.1.0.Alpha1
Reporter: Radim Vansa
Assignee: Radim Vansa
{{org.infinispan.xsite.AtomicMapBackupTest}} is failing because functional commands are not replicated over the cross-site link.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7960) TxInterceptor.verifyRemoteTransaction ignores partition handling
by Dan Berindei (JIRA)
Dan Berindei created ISPN-7960:
----------------------------------
Summary: TxInterceptor.verifyRemoteTransaction ignores partition handling
Key: ISPN-7960
URL: https://issues.jboss.org/browse/ISPN-7960
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.0.3.Final, 9.1.0.Beta1
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 9.1.0.Final
https://github.com/infinispan/infinispan/pull/5143 fixes the random test failures in {{PessimisticTxPartitionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition}}, but it uncovers another random failure in {{OptimisticTxPartitionAndMergeDuringCommitTest.testDegradedPartitionWithDiscard}}.
When partition handling is enabled, {{TransactionTable.cleanupLeaverTransactions()}} will not roll back transactions from leavers, instead it will keep them in limbo until it sees a stable cache topology (i.e. either until the cache's stable topology is updated, or until all the stable topology's members are re-added to the current topology). {{TxInterceptor.verifyRemoteTransaction()}} instead always rolls back the transaction if the originator is not in the cluster view, and when the originator tries to complete the transaction after the merge it gets an exception:
{noformat}
10:27:34,880 WARN (remote-thread-Test-NodeG-p46360-t6:[]) [NonTotalOrderTxPerCacheInboundInvocationHandler] ISPN000071: Caught exception when handling command VersionedCommitCommand{gtx=GlobalTx:Test-NodeE-10968:31983, cacheName='opt-cache', topologyId=16, updatedVersions={MagicKey#k1{168F/00552148/106@Test-NodeF-27031}=SimpleClusteredVersion{topologyId=13, version=2}, MagicKey#k2{1690/CCE79580/35@Test-NodeG-8587}=SimpleClusteredVersion{topologyId=13, version=2}}}
org.infinispan.commons.CacheException: ISPN000361: Cannot commit remote transaction GlobalTx:Test-NodeE-10968:31983 as it was already rolled back
at org.infinispan.commands.tx.CommitCommand.invalidRemoteTxReturnValue(CommitCommand.java:49) ~[classes/:?]
at org.infinispan.commands.tx.AbstractTransactionBoundaryCommand.invokeAsync(AbstractTransactionBoundaryCommand.java:98) ~[classes/:?]
{noformat}
The test splits actually tries to ensure that the {{CommitCommand}} is never executed on the owner before the split, only after the merge. But the {{DiscardFilter}} that it uses only blocks one invocation, and it lets the commit proceed when the originator retries:
{noformat}
10:27:34,394 DEBUG (jgroups-6,Test-NodeG-8587:[]) [BaseTxPartitionAndMergeTest] Ignoring command VersionedCommitCommand{gtx=GlobalTx:Test-NodeE-10968:31983, cacheName='opt-cache', topologyId=13, updatedVersions={MagicKey#k1{168F/00552148/106@Test-NodeF-27031}=SimpleClusteredVersion{topologyId=13, version=2}, MagicKey#k2{1690/CCE79580/35@Test-NodeG-8587}=SimpleClusteredVersion{topologyId=13, version=2}}}
10:27:34,416 DEBUG (transport-thread-Test-NodeE-p46282-t3:[Topology-opt-cache]) [LocalTopologyManagerImpl] Updating local topology for cache opt-cache: CacheTopology{id=14, rebalanceId=4, currentCH=DefaultConsistentHash{ns=256, owners = (4)[Test-NodeE-10968: 67+67, Test-NodeF-27031: 59+65, Test-NodeG-8587: 63+57, Test-NodeH-3978: 67+67]}, pendingCH=null, unionCH=null, phase=NO_REBALANCE, actualMembers=[Test-NodeE-10968, Test-NodeF-27031], persistentUUIDs=[72351dc9-f621-41df-896b-1dc2f26798f5, 61811c2f-4931-49e2-b395-4debd39f6ca1]}
10:27:34,442 TRACE (jgroups-6,Test-NodeE-10968:[]) [RpcManagerImpl] Response(s) to VersionedCommitCommand{gtx=GlobalTx:Test-NodeE-10968:31983, cacheName='opt-cache', topologyId=13, updatedVersions={MagicKey#k1{168F/00552148/106@Test-NodeF-27031}=SimpleClusteredVersion{topologyId=13, version=2}, MagicKey#k2{1690/CCE79580/35@Test-NodeG-8587}=SimpleClusteredVersion{topologyId=13, version=2}}} is {Test-NodeG-8587=CacheNotFoundResponse, Test-NodeF-27031=SuccessfulResponse(null)}
10:27:34,442 TRACE (jgroups-6,Test-NodeE-10968:[]) [TxDistributionInterceptor] We have a newer topology, ignoring responses and retrying
10:27:34,451 TRACE (jgroups-6,Test-NodeE-10968:[]) [RpcManagerImpl] Test-NodeE-10968 invoking VersionedCommitCommand{gtx=GlobalTx:Test-NodeE-10968:31983, cacheName='opt-cache', topologyId=14, updatedVersions={MagicKey#k1{168F/00552148/106@Test-NodeF-27031}=SimpleClusteredVersion{topologyId=13, version=2}, MagicKey#k2{1690/CCE79580/35@Test-NodeG-8587}=SimpleClusteredVersion{topologyId=13, version=2}}} to recipient list [Test-NodeF-27031, Test-NodeG-8587] with options RpcOptions{timeout=15000, unit=MILLISECONDS, deliverOrder=NONE, responseFilter=null, responseMode=SYNCHRONOUS_IGNORE_LEAVERS}
10:27:34,637 TRACE (remote-thread-Test-NodeG-p46360-t6:[]) [TxInterceptor] Replaying the transactions received as a result of state transfer VersionedPrepareCommand {modifications=[PutKeyValueCommand{key=MagicKey#k1{168F/00552148/106@Test-NodeF-27031}, value=final-value, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=null}, successful=true, topologyId=13}, PutKeyValueCommand{key=MagicKey#k2{1690/CCE79580/35@Test-NodeG-8587}, value=final-value, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=null}, successful=true, topologyId=13}], onePhaseCommit=false, retried=false, versionsSeen=null, gtx=GlobalTx:Test-NodeE-10968:31983, cacheName='opt-cache'}
10:27:34,661 TRACE (remote-thread-Test-NodeG-p46360-t6:[]) [TxInterceptor] Rolling back remote transaction GlobalTx:Test-NodeE-10968:31983 because either already completed (false) or originator no longer in the cluster (true).
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7960) TxInterceptor.verifyRemoteTransaction ignores partition handling
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7960?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-7960:
-------------------------------
Status: Open (was: New)
> TxInterceptor.verifyRemoteTransaction ignores partition handling
> ----------------------------------------------------------------
>
> Key: ISPN-7960
> URL: https://issues.jboss.org/browse/ISPN-7960
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Beta1, 9.0.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.1.0.Final
>
>
> https://github.com/infinispan/infinispan/pull/5143 fixes the random test failures in {{PessimisticTxPartitionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition}}, but it uncovers another random failure in {{OptimisticTxPartitionAndMergeDuringCommitTest.testDegradedPartitionWithDiscard}}.
> When partition handling is enabled, {{TransactionTable.cleanupLeaverTransactions()}} will not roll back transactions from leavers, instead it will keep them in limbo until it sees a stable cache topology (i.e. either until the cache's stable topology is updated, or until all the stable topology's members are re-added to the current topology). {{TxInterceptor.verifyRemoteTransaction()}} instead always rolls back the transaction if the originator is not in the cluster view, and when the originator tries to complete the transaction after the merge it gets an exception:
> {noformat}
> 10:27:34,880 WARN (remote-thread-Test-NodeG-p46360-t6:[]) [NonTotalOrderTxPerCacheInboundInvocationHandler] ISPN000071: Caught exception when handling command VersionedCommitCommand{gtx=GlobalTx:Test-NodeE-10968:31983, cacheName='opt-cache', topologyId=16, updatedVersions={MagicKey#k1{168F/00552148/106@Test-NodeF-27031}=SimpleClusteredVersion{topologyId=13, version=2}, MagicKey#k2{1690/CCE79580/35@Test-NodeG-8587}=SimpleClusteredVersion{topologyId=13, version=2}}}
> org.infinispan.commons.CacheException: ISPN000361: Cannot commit remote transaction GlobalTx:Test-NodeE-10968:31983 as it was already rolled back
> at org.infinispan.commands.tx.CommitCommand.invalidRemoteTxReturnValue(CommitCommand.java:49) ~[classes/:?]
> at org.infinispan.commands.tx.AbstractTransactionBoundaryCommand.invokeAsync(AbstractTransactionBoundaryCommand.java:98) ~[classes/:?]
> {noformat}
> The test splits actually tries to ensure that the {{CommitCommand}} is never executed on the owner before the split, only after the merge. But the {{DiscardFilter}} that it uses only blocks one invocation, and it lets the commit proceed when the originator retries:
> {noformat}
> 10:27:34,394 DEBUG (jgroups-6,Test-NodeG-8587:[]) [BaseTxPartitionAndMergeTest] Ignoring command VersionedCommitCommand{gtx=GlobalTx:Test-NodeE-10968:31983, cacheName='opt-cache', topologyId=13, updatedVersions={MagicKey#k1{168F/00552148/106@Test-NodeF-27031}=SimpleClusteredVersion{topologyId=13, version=2}, MagicKey#k2{1690/CCE79580/35@Test-NodeG-8587}=SimpleClusteredVersion{topologyId=13, version=2}}}
> 10:27:34,416 DEBUG (transport-thread-Test-NodeE-p46282-t3:[Topology-opt-cache]) [LocalTopologyManagerImpl] Updating local topology for cache opt-cache: CacheTopology{id=14, rebalanceId=4, currentCH=DefaultConsistentHash{ns=256, owners = (4)[Test-NodeE-10968: 67+67, Test-NodeF-27031: 59+65, Test-NodeG-8587: 63+57, Test-NodeH-3978: 67+67]}, pendingCH=null, unionCH=null, phase=NO_REBALANCE, actualMembers=[Test-NodeE-10968, Test-NodeF-27031], persistentUUIDs=[72351dc9-f621-41df-896b-1dc2f26798f5, 61811c2f-4931-49e2-b395-4debd39f6ca1]}
> 10:27:34,442 TRACE (jgroups-6,Test-NodeE-10968:[]) [RpcManagerImpl] Response(s) to VersionedCommitCommand{gtx=GlobalTx:Test-NodeE-10968:31983, cacheName='opt-cache', topologyId=13, updatedVersions={MagicKey#k1{168F/00552148/106@Test-NodeF-27031}=SimpleClusteredVersion{topologyId=13, version=2}, MagicKey#k2{1690/CCE79580/35@Test-NodeG-8587}=SimpleClusteredVersion{topologyId=13, version=2}}} is {Test-NodeG-8587=CacheNotFoundResponse, Test-NodeF-27031=SuccessfulResponse(null)}
> 10:27:34,442 TRACE (jgroups-6,Test-NodeE-10968:[]) [TxDistributionInterceptor] We have a newer topology, ignoring responses and retrying
> 10:27:34,451 TRACE (jgroups-6,Test-NodeE-10968:[]) [RpcManagerImpl] Test-NodeE-10968 invoking VersionedCommitCommand{gtx=GlobalTx:Test-NodeE-10968:31983, cacheName='opt-cache', topologyId=14, updatedVersions={MagicKey#k1{168F/00552148/106@Test-NodeF-27031}=SimpleClusteredVersion{topologyId=13, version=2}, MagicKey#k2{1690/CCE79580/35@Test-NodeG-8587}=SimpleClusteredVersion{topologyId=13, version=2}}} to recipient list [Test-NodeF-27031, Test-NodeG-8587] with options RpcOptions{timeout=15000, unit=MILLISECONDS, deliverOrder=NONE, responseFilter=null, responseMode=SYNCHRONOUS_IGNORE_LEAVERS}
> 10:27:34,637 TRACE (remote-thread-Test-NodeG-p46360-t6:[]) [TxInterceptor] Replaying the transactions received as a result of state transfer VersionedPrepareCommand {modifications=[PutKeyValueCommand{key=MagicKey#k1{168F/00552148/106@Test-NodeF-27031}, value=final-value, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=null}, successful=true, topologyId=13}, PutKeyValueCommand{key=MagicKey#k2{1690/CCE79580/35@Test-NodeG-8587}, value=final-value, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=null}, successful=true, topologyId=13}], onePhaseCommit=false, retried=false, versionsSeen=null, gtx=GlobalTx:Test-NodeE-10968:31983, cacheName='opt-cache'}
> 10:27:34,661 TRACE (remote-thread-Test-NodeG-p46360-t6:[]) [TxInterceptor] Rolling back remote transaction GlobalTx:Test-NodeE-10968:31983 because either already completed (false) or originator no longer in the cluster (true).
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-6997) PessimisticTxPartitionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6997?page=com.atlassian.jira.plugin.... ]
Dan Berindei edited comment on ISPN-6997 at 6/22/17 9:10 AM:
-------------------------------------------------------------
I started investigating this again when I stumbled across some new failures on the ISPN-6971 branch. My previous comment was only partially correct: the {{LockControlCommand}} is not delivered during the partition, but immediately before (or possibly in parallel) with the view message.
The reason is that {{UNICAST3}} connections are not closed immediately when the peer disappears from the view, and messages sent during the partition stay in the connection's send table and may be delivered after the merge. But the caller already got a {{CacheNotFoundResponse}} when the partition view got installed, so it committed the transaction locally with a {{PrepareCommand(1PC)}}. Crucially, the 1PC command is *not* sent to all the nodes that got the {{LockControlCommand}}, but only those that are still in the cluster. So the {{LockControlCommand}} is retransmitted after the merge, but the {{PrepareCommand(1PC)}}/{{RollbackCommand}} isn't, and the remote transaction is only cleaned up after the remote transaction timeout expires (60 seconds by default).
Bela added a [method in {{UNICAST3}}|https://issues.jboss.org/browse/JGRP-2194] to manually close a connection to a peer, but I've decided instead to change our code so that the targets of {{RollbackCommand}} and {{PrepareCommand}} include the targets of any previous {{LockControlCommand}}.
was (Author: dan.berindei):
I started investigating this again when I stumbled across some new failures on the ISPN-6997 branch. My previous comment was only partially correct: the {{LockControlCommand}} is not delivered during the partition, but immediately before (or possibly in parallel) with the view message.
The reason is that {{UNICAST3}} connections are not closed immediately when the peer disappears from the view, and messages sent during the partition stay in the connection's send table and may be delivered after the merge. But the caller already got a {{CacheNotFoundResponse}} when the partition view got installed, so it committed the transaction locally with a {{PrepareCommand(1PC)}}. Crucially, the 1PC command is *not* sent to all the nodes that got the {{LockControlCommand}}, but only those that are still in the cluster. So the {{LockControlCommand}} is retransmitted after the merge, but the {{PrepareCommand(1PC)}}/{{RollbackCommand}} isn't, and the remote transaction is only cleaned up after the remote transaction timeout expires (60 seconds by default).
Bela added a [method in {{UNICAST3}}|https://issues.jboss.org/browse/JGRP-2194] to manually close a connection to a peer, but I've decided instead to change our code so that the targets of {{RollbackCommand}} and {{PrepareCommand}} include the targets of any previous {{LockControlCommand}}.
> PessimisticTxPartitionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition random failures
> -----------------------------------------------------------------------------------------------
>
> Key: ISPN-6997
> URL: https://issues.jboss.org/browse/ISPN-6997
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 9.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.1.0.Final
>
>
> The test starts with a cluster of 4 nodes, and splits it in 2 partitions while a transaction is trying to lock a key. After the transaction fails, it checks that the transaction has been cleaned up properly.
> On one of the owners, {{transactionTable.cleanupLeaverTransactions}} is being called only before the split and after the merge, never with the list of members during the split. That means it never sees the transaction as an orphan, and doesn't remove it.
> {noformat}
> 15:16:18,893 TRACE (testng-PTPAMDRT:[]) [PTPAMDRT] Local tx=[], remote tx=[GlobalTx:PTPAMDRT-NodeI-3337:28616], for cache PTPAMDRT-NodeJ-27814
> 15:16:18,893 ERROR (testng-PTPAMDRT:[]) [TestSuiteProgress] Test failed: org.infinispan.partitionhandling.PTPAMDRT.testOriginatorIsolatedPartition
> java.lang.AssertionError: There are pending transactions!
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.8.8.jar:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:223) ~[test-classes/:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:519) ~[test-classes/:?]
> at org.infinispan.test.MultipleCacheManagersTest.assertNoTransactions(MultipleCacheManagersTest.java:794) ~[test-classes/:?]
> at org.infinispan.partitionhandling.BaseTxPartitionAndMergeTest.finalAsserts(BaseTxPartitionAndMergeTest.java:96) ~[test-classes/:?]
> at org.infinispan.partitionhandling.BasePessimisticTxPartitionAndMergeTest.doTest(BasePessimisticTxPartitionAndMergeTest.java:82) ~[test-classes/:?]
> at org.infinispan.partitionhandling.tionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition(PessimisticTxPartitionAndMergeDuringRuntimeTest.java:33) ~[test-classes/:?]
> {noformat}
> {{OptimisticTxPartitionAndMergeDuringCommitTest.testPrimaryOwnerIsolatedPartition}} has similar random failures.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7955) Hot Rod client needs to re-resolve topology addresses after failure to connect
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7955?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-7955:
---------------------------------------
Similar, but not quite the same [~sebastian.laskawiec]
> Hot Rod client needs to re-resolve topology addresses after failure to connect
> ------------------------------------------------------------------------------
>
> Key: ISPN-7955
> URL: https://issues.jboss.org/browse/ISPN-7955
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 8.2.6.Final, 8.1.7.Final, 9.1.0.Beta1, 9.0.3.Final
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
>
> The Hot Rod client resolves topology addresses on reception. In dynamic environments where server nodes can restart with different IPs (but maintaining their external hostname) this causes the client to fail to reconnect. The client should hold on to the original address and re-resolve it in case of failures.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7906) Infinispan Query DSL does not handle inheritance of properties/fields correctly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-7906?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-7906:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1463777
Bugzilla Update: Perform
> Infinispan Query DSL does not handle inheritance of properties/fields correctly
> -------------------------------------------------------------------------------
>
> Key: ISPN-7906
> URL: https://issues.jboss.org/browse/ISPN-7906
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 8.2.0.Final, 9.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 8.2.7.Final, 9.1.0.Beta1, 9.1.0.Final, 9.0.3.Final
>
>
> If 'age' property is a field declared in the parent class of 'Person' and you query it you will get:
> {code}
> org.infinispan.objectfilter.ParsingException: ISPN028501: The type org.infinispan.query.dsl.embedded.SingleClassDSLQueryTest$Person has no property named 'age'.
> at org.infinispan.objectfilter.impl.syntax.parser.QueryResolverDelegateImpl.normalizeProperty(QueryResolverDelegateImpl.java:191)
> at org.infinispan.objectfilter.impl.syntax.parser.QueryResolverDelegateImpl.normalizePropertyPathTerminus(QueryResolverDelegateImpl.java:185)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.pathedPropertyReference(QueryResolver.java:7736)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.propertyReferencePath(QueryResolver.java:7567)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.propertyReferenceExpression(QueryResolver.java:5689)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.valueExpressionPrimary(QueryResolver.java:5495)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.valueExpression(QueryResolver.java:5271)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.rowValueConstructor(QueryResolver.java:4490)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.predicate(QueryResolver.java:3458)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.searchCondition(QueryResolver.java:2979)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.whereClause(QueryResolver.java:655)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.querySpec(QueryResolver.java:510)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.queryStatement(QueryResolver.java:379)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.queryStatementSet(QueryResolver.java:292)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.statement(QueryResolver.java:220)
> at org.infinispan.objectfilter.impl.ql.QueryParser.resolve(QueryParser.java:81)
> at org.infinispan.objectfilter.impl.ql.QueryParser.parseQuery(QueryParser.java:69)
> at org.infinispan.objectfilter.impl.syntax.parser.IckleParser.parse(IckleParser.java:19)
> at org.infinispan.query.dsl.embedded.impl.QueryEngine.lambda$parse$1(QueryEngine.java:655)
> at org.infinispan.query.dsl.embedded.impl.QueryCache.lambda$get$0(QueryCache.java:79)
> at org.infinispan.cache.impl.TypeConverterDelegatingAdvancedCache.lambda$convertFunction$1(TypeConverterDelegatingAdvancedCache.java:103)
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at org.infinispan.cache.impl.AbstractDelegatingCache.computeIfAbsent(AbstractDelegatingCache.java:343)
> at org.infinispan.cache.impl.TypeConverterDelegatingAdvancedCache.computeIfAbsent(TypeConverterDelegatingAdvancedCache.java:163)
> at org.infinispan.query.dsl.embedded.impl.QueryCache.get(QueryCache.java:79)
> at org.infinispan.query.dsl.embedded.impl.QueryEngine.parse(QueryEngine.java:655)
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.<init>(DelegatingQuery.java:54)
> at org.infinispan.query.dsl.embedded.impl.EmbeddedQueryBuilder.build(EmbeddedQueryBuilder.java:32)
> at org.infinispan.query.dsl.impl.BaseCondition.build(BaseCondition.java:197)
> at org.infinispan.query.dsl.embedded.SingleClassDSLQueryTest.testInheritedField(SingleClassDSLQueryTest.java:88)
> at org.infinispan.query.dsl.embedded.NonIndexedSingleClassDSLQueryTest.testInheritedField(NonIndexedSingleClassDSLQueryTest.java:22)
> 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:498)
> 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.IDEARemoteTestNG.run(IDEARemoteTestNG.java:72)
> at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:127)
> {code}
> Similar failures occur for java-bean style properties.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months