[JBoss JIRA] (ISPN-6084) Continuous query should reject queries with orderBy
by Adrian Nistor (JIRA)
Adrian Nistor created ISPN-6084:
-----------------------------------
Summary: Continuous query should reject queries with orderBy
Key: ISPN-6084
URL: https://issues.jboss.org/browse/ISPN-6084
Project: Infinispan
Issue Type: Bug
Components: Embedded Querying, Remote Querying
Affects Versions: 8.0.2.Final
Reporter: Adrian Nistor
Assignee: Adrian Nistor
Fix For: 8.2.0.Beta1
Current behaviour it that orderBy is silently ignored. Disallowing this and throwing an exception would be preferable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (ISPN-6076) Errors when the same column is both a gouping column and an aggregation column
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-6076?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-6076:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3942
> Errors when the same column is both a gouping column and an aggregation column
> ------------------------------------------------------------------------------
>
> Key: ISPN-6076
> URL: https://issues.jboss.org/browse/ISPN-6076
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 8.0.2.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 8.2.0.Beta1, 8.2.0.Final
>
>
> This should not be allowed.
> {code}
> public void testGroupingAndAggregationOnSameField() {
> QueryFactory qf = getQueryFactory();
> Query q = qf.from(getModelFactory().getUserImplClass())
> .select(Expression.count("surname"), Expression.sum("addresses.number"))
> .groupBy("surname")
> .build();
> List<Object[]> list = q.list(); // throws ClassCastException
> }
> {code}
> {code}
> java.lang.ClassCastException: java.lang.String cannot be cast to org.infinispan.objectfilter.impl.aggregation.Counter
> at org.infinispan.objectfilter.impl.aggregation.CountAccumulator.merge(CountAccumulator.java:24)
> at org.infinispan.objectfilter.impl.aggregation.FieldAccumulator.merge(FieldAccumulator.java:42)
> at org.infinispan.objectfilter.impl.aggregation.Grouper.addRow(Grouper.java:133)
> at org.infinispan.query.dsl.embedded.impl.AggregatingQuery.getBaseIterator(AggregatingQuery.java:52)
> at org.infinispan.query.dsl.embedded.impl.HybridQuery$1.<init>(HybridQuery.java:47)
> at org.infinispan.query.dsl.embedded.impl.HybridQuery.getIterator(HybridQuery.java:45)
> at org.infinispan.query.dsl.embedded.impl.BaseEmbeddedQuery.listInternal(BaseEmbeddedQuery.java:65)
> at org.infinispan.query.dsl.embedded.impl.BaseEmbeddedQuery.list(BaseEmbeddedQuery.java:57)
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.list(DelegatingQuery.java:45)
> at org.infinispan.query.dsl.embedded.QueryDslConditionsTest.testEmbeddedSum(QueryDslConditionsTest.java:1959)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (ISPN-5727) Client Listener removal and shutdown problems
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5727?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5727:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1297930|https://bugzilla.redhat.com/show_bug.cgi?id=1297930] from ON_QA to VERIFIED
> Client Listener removal and shutdown problems
> ---------------------------------------------
>
> Key: ISPN-5727
> URL: https://issues.jboss.org/browse/ISPN-5727
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.0.0.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 8.1.0.Final, 8.0.2.Final
>
>
> There are a couple of problems related to client listener registration on the client:
> 1. When shutting down a remote cache manager to which client listeners have been added, even if the user does not remove them individually, stopping the remote cache manager should shutdown all client-side client listener threads. This is not the case right now.
> 2. When removing a client listener, the client listener thread needs to be stopped.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (ISPN-5955) FAIL_SILENTLY doesn't always prevent rollback with pessimistic transactions
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5955?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-5955:
------------------------------------
Acquiring remote locks with a {{ClusteredGetCommand}} and not always waiting for the response from the primary owner is very problematic anyway, so I think the best option would be to remove the {{acquireRemoteLock}} flag altogether. If we want to optimize in the future and acquire the lock + retrieve the value in a single RPC (which we don't do at this point), we must make sure we wait for the responses from all the owners.
> FAIL_SILENTLY doesn't always prevent rollback with pessimistic transactions
> ---------------------------------------------------------------------------
>
> Key: ISPN-5955
> URL: https://issues.jboss.org/browse/ISPN-5955
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.0.1.Final, 8.1.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 8.2.0.Beta1
>
>
> The {{FAIL_SILENTLY}} should "prevent a failing operation from affecting any ongoing JTA transactions", but sometimes this doesn't work properly.
> {{FlagsReplicationTest}} has a transaction using both {{FAIL_SILENTLY}} and {{SKIP_LOCKING}} in the same transaction:
> # A {{lock(FAIL_SILENTLY)(key)}} operation fails.
> Both on the primary owner and on the originator, PessimisticLockingInterceptor sends a TxCompletionNotificationCommand to all the nodes affected by the tx so far, to release the locks. This marks the transaction as completed, but doesn't mark it as rolled back.
> # A {{remove(SKIP_LOCKING)(key)}} operation should then succeed.
> But the operation will invoke a {{ClusteredGetCommand(key, acquireRemoteLock=true, SKIP_LOCKING)}} on both owners, which will in turn invoke locally a {{LockControlCommand(key, SKIP_LOCKING)}}.
> At this point, {{TxInterceptor}} sees that the transaction is already completed, and invokes a {{RollbackCommand}} to mark it as rolled back, then remove it from the transaction table. The command still succeeds.
> # The test then tries to commit the transaction. Usually, the {{PrepareCommand}} doesn't find the remote transaction in the transaction table, and it succeeds.
> But some of the time, because the {{ClusteredGetCommand}} command only uses the first response, the remote transaction is not removed from the transaction table by the time the {{PrepareCommand}} is executed on one of the owners.
> If that happens, the {{PrepareCommand}} executes with a remote transaction instance that's already marked for rollback, and fails when trying to put the key in the context.
> {noformat}
> 15:42:56,736 ERROR (remote-thread-NodeF-p1112-t5:GlobalTx:NodeG-6318:216) [InvocationContextInterceptor] ISPN000136: Error executing command LockControlCommand, writing keys []
> org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 0 milliseconds for key replication.FlagsReplicationTest and requestor GlobalTx:NodeG-6318:216. Lock is held by GlobalTx:NodeG-6318:215
> 15:42:56,802 TRACE (OOB-1,NodeF-64741:) [NonTotalOrderTxPerCacheInboundInvocationHandler] Calling perform() on ClusteredGetCommand{key=replication.FlagsReplicationTest, flags=[SKIP_LOCKING]}
> 15:42:56,803 TRACE (OOB-1,NodeF-64741:GlobalTx:NodeG-6318:216) [InvocationContextInterceptor] Invoked with command LockControlCommand{cache=dist, keys=[replication.FlagsReplicationTest], flags=[SKIP_LOCKING], unlock=false, gtx=GlobalTx:NodeG-6318:216} and InvocationContext [org.infinispan.context.impl.RemoteTxInvocationContext@75bf6da7]
> 15:42:56,822 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [InvocationContextInterceptor] Invoked with command PrepareCommand {modifications=[RemoveCommand{key=replication.FlagsReplicationTest, value=null, flags=[SKIP_LOCKING], valueMatcher=MATCH_ALWAYS}], onePhaseCommit=true, gtx=GlobalTx:NodeG-6318:216, cacheName='dist', topologyId=6} and InvocationContext [org.infinispan.context.impl.RemoteTxInvocationContext@75bf6da7]
> 15:42:56,832 TRACE (OOB-1,NodeF-64741:GlobalTx:NodeG-6318:216) [TxInterceptor] Rolling back remote transaction GlobalTx:NodeG-6318:216 because either already completed (true) or originator no longer in the cluster (false).
> 15:42:56,864 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [EntryFactoryImpl] Creating new entry for key replication.FlagsReplicationTest
> 15:42:56,864 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [BaseSequentialInvocationContext] Interceptor class org.infinispan.interceptors.EntryWrappingInterceptor threw exception org.infinispan.transaction.xa.InvalidTransactionException: This remote transaction GlobalTx:NodeG-6318:216 is already rolled back
> 15:42:56,873 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [TxInterceptor] invokeNextInterceptorAndVerifyTransaction :: originatorMissing=false, alreadyCompleted=true
> 15:42:56,873 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [TxInterceptor] Rolling back remote transaction GlobalTx:NodeG-6318:216 because either already completed (true) or originator no longer in the cluster (false).
> {noformat}
> Possible actions:
> * Never try to release locks from a {{LockControlCommand}}, wait for the {{RollbackCommand}} instead. This could cause problems if the primary owner dies, the transaction tries to lock the same entry again, and the backup owner that became primary wrongfully assumes that it is a proper owner.
> * Use a {{LockControlCommand(unlock=true)}} instead of a {{TxCompletionNotificationCommand}} to release the backup locks after an operation with {{FAIL_SILENTLY}} failed.
> * Don't set {{acquireRemoteLock=true}} when the {{SKIP_LOCKING}} flag has been set.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months