[infinispan-issues] [JBoss JIRA] (ISPN-3795) QueryInterceptor incorrectly relies on the return value of a RemoveCommand
Gustavo Fernandes (JIRA)
issues at jboss.org
Mon May 15 04:49:00 EDT 2017
[ https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406103#comment-13406103 ]
Gustavo Fernandes commented on ISPN-3795:
-----------------------------------------
[~rvansa] Twofold:
* ClusteredQueries, where each node indexes "LOCAL" entries, in its own non-shared local index. During query time the ClusteredQuery API allows to broadcast a query to all nodes, aggregating the results to return to the user.
* Shared Index: most widely used, index is shared by all nodes and Index.LOCAL allows to index the entry only once.
For both cases above, though, we don't necessarily need Index.LOCAL; we can use Index.PRIMARY_OWNER that the effect will be the same, actually more efficiently: we don't need to fetch values remotely from non-owner.
So I think we could get rid of Index.LOCAL, and put the QI after the EWI that the context would always be available
> QueryInterceptor incorrectly relies on the return value of a RemoveCommand
> --------------------------------------------------------------------------
>
> Key: ISPN-3795
> URL: https://issues.jboss.org/browse/ISPN-3795
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Gustavo Fernandes
>
> QueryInterceptor uses the return value from RemoveCommand/ReplaceCommand to remove the value from the index.
> But both RemoveCommand and ReplaceCommand have a variant with an expected value parameter, and this variant return a boolean value instead of the removed/replaced value. In that case, the previous value won't be removed from the index.
> QueryInterceptor should probably use the previous value from the context entries to update the index instead.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
More information about the infinispan-issues
mailing list