[ 
https://issues.apache.org/jira/browse/LUCENE-6321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345048#comment-14345048
 ] 

Adrien Grand commented on LUCENE-6321:
--------------------------------------

bq. Another thing we could do instead would be a best effort check where we 
actually throw concurrentmodificationexception or something, that might be more 
interesting.

Right, I started working on that and it is actually quite easy to implement. 
The only thing I'm worried about is that it would only appear on the first time 
that you need an eviction. So if your cache has a capacity of eg. 10,000 
queries, it would take time before you notice the issue. And once it happens, 
all queries that insert entries into the cache would fail since no eviction 
could work anymore. So we probably need to also make queries a bit more 
defensive.

> Make oal.index.Term more defensive
> ----------------------------------
>
>                 Key: LUCENE-6321
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6321
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: Adrien Grand
>            Assignee: Adrien Grand
>            Priority: Minor
>         Attachments: LUCENE-6321.patch
>
>
> oal.index.Term has a Term(String field, BytesRef termBytes) constructor. Even 
> though it warns that the term bytes should not be reused, I'm wondering that 
> we should make it more defensive.
> {noformat}
>    * <p>WARNING: the provided BytesRef is not copied, but used directly.
>    * Therefore the bytes should not be modified after construction, for
>    * example, you should clone a copy by {@link BytesRef#deepCopyOf}
>    * rather than pass reused bytes from a TermsEnum.
> {noformat} 
> For example if you have term queries in your query cache and they are 
> modified in-place, it would have very bad consequences and would be hard to 
> diagnose.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to