[infinispan-issues] [JBoss JIRA] (ISPN-3795) QueryInterceptor incorrectly relies on the return value of a RemoveCommand

[Sanne Grinovero (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406523#comment-13406523 ] 

Sanne Grinovero edited comment on ISPN-3795 at 5/15/17 1:24 PM:
----------------------------------------------------------------

{quote}Sanne Grinovero just curious, how bad would it be if tracked the types in the cache and every update would purge the key from all the indexes? {quote}

First off to be correct we really need to know which type is being deleted; enumerating all the types isn't enough.

>From a performance perspective, on the Lucene index a single delete (purge) operation is about one order of magnitude slower than a write, so we actually try to work hard to avoid issuing any unnecessary delete operations. Also a delete operation needs strict ordering towards other operations so there are costs in parallel scalability as well.

So issuing an unnecessary delete on all indexes is not adviseable but your suggestion is valid if we could know which index needs the one and only delete operation deterministically.
I guess if Infinispan could fetch the type rather than the actual whole value we could avoid some payload transfers, but it's still something that we'd need to be able to disable as e.g. dynamic sharding allows index selection based on some attribute of the actual value.

Given the other comments, +1 to allow Query to *ignore* _IGNORE_RETURN_VALUE_ *however* the performance of batch loading an empty grid would collapse. Please still allow some way to get that loaded fast..


was (Author: sannegrinovero):
{quote}Sanne Grinovero just curious, how bad would it be if tracked the types in the cache and every update would purge the key from all the indexes? {quote}

First off to be correct we really need to know which type is being deleted; enumerating all the types isn't enough.

>From a performance perspective, on the Lucene index a single delete (purge) operation is about one order of magnitude slower than a write, so we actually try to work hard to avoid issuing any unnecessary delete operations. Also a delete operation needs strict ordering towards other operations so there are costs in parallel scalability as well.

So issuing an unnecessary delete on all indexes is not adviseable but your suggestion is valid if we could know index needs it deterministically. I guess if Infinispan could fetch the type rather than the actual whole value we could avoid some payload transfers, but it's still something that we'd need to be able to disable as e.g. dynamic sharding allows index selection based on some attribute of the actual value.

Given the other comments, +1 to allow Query to *ignore* _IGNORE_RETURN_VALUE_ *however* the performance of batch loading an empty grid would collapse. Please still allow some way to get that loaded fast..

> 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)