12:25 p.m.
[
https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin....
]
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)
3249
days inactive
3249
days old
infinispan-issues@lists.jboss.org
0 comments
1 participants
participants (1)
-
Sanne Grinovero (JIRA)