You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Michael McCandless (JIRA)" <ji...@apache.org> on 2010/07/05 14:36:52 UTC
[jira] Created: (LUCENE-2527) FieldCache.getTermsIndex should cache
fasterButMoreRAM=true|false to the same cache key
FieldCache.getTermsIndex should cache fasterButMoreRAM=true|false to the same cache key
---------------------------------------------------------------------------------------
Key: LUCENE-2527
URL: https://issues.apache.org/jira/browse/LUCENE-2527
Project: Lucene - Java
Issue Type: Bug
Affects Versions: 4.0
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 4.0
When we cutover FieldCache to use shared byte[] blocks, we added the boolean fasterButMoreRAM option, so you could tradeoff time/space.
It defaults to true.
The thinking is that an expert user, who wants to use false, could pre-populate FieldCache by loading the field with false, and then later when sorting on that field it'd use that same entry.
But there's a bug -- when sorting, it then loads a 2nd entry with "true". This is because the Entry.custom in FieldCache participates in equals/hashCode.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] Commented: (LUCENE-2527) FieldCache.getTermsIndex should
cache fasterButMoreRAM=true|false to the same cache key
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914386#action_12914386 ]
Michael McCandless commented on LUCENE-2527:
--------------------------------------------
I wonder if the pending improvements to FieldCache will handle preventing this FC insanity?
> FieldCache.getTermsIndex should cache fasterButMoreRAM=true|false to the same cache key
> ---------------------------------------------------------------------------------------
>
> Key: LUCENE-2527
> URL: https://issues.apache.org/jira/browse/LUCENE-2527
> Project: Lucene - Java
> Issue Type: Bug
> Components: Search
> Affects Versions: 4.0
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 4.0
>
>
> When we cutover FieldCache to use shared byte[] blocks, we added the boolean fasterButMoreRAM option, so you could tradeoff time/space.
> It defaults to true.
> The thinking is that an expert user, who wants to use false, could pre-populate FieldCache by loading the field with false, and then later when sorting on that field it'd use that same entry.
> But there's a bug -- when sorting, it then loads a 2nd entry with "true". This is because the Entry.custom in FieldCache participates in equals/hashCode.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] Commented: (LUCENE-2527) FieldCache.getTermsIndex should
cache fasterButMoreRAM=true|false to the same cache key
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915058#action_12915058 ]
Ryan McKinley commented on LUCENE-2527:
---------------------------------------
Yes, LUCENE-2649 puts fasterButMoreRAM= true or false in the same entry. Whatever is called first is what gets used (without warning)
One option is to 'upgrade' the cache value -- but I'm not sure which one is the upgrade. Perhaps the last one that you ask for? If that is the case, would we need another option that says "I would like it fasterButMoreRAM unless you already have it cached different"
I think documenting that the setting needs to be used consistently is good. If we have an error stream, then this would be an appropriate place to log an error/warning.
> FieldCache.getTermsIndex should cache fasterButMoreRAM=true|false to the same cache key
> ---------------------------------------------------------------------------------------
>
> Key: LUCENE-2527
> URL: https://issues.apache.org/jira/browse/LUCENE-2527
> Project: Lucene - Java
> Issue Type: Bug
> Components: Search
> Affects Versions: 4.0
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 4.0
>
>
> When we cutover FieldCache to use shared byte[] blocks, we added the boolean fasterButMoreRAM option, so you could tradeoff time/space.
> It defaults to true.
> The thinking is that an expert user, who wants to use false, could pre-populate FieldCache by loading the field with false, and then later when sorting on that field it'd use that same entry.
> But there's a bug -- when sorting, it then loads a 2nd entry with "true". This is because the Entry.custom in FieldCache participates in equals/hashCode.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] Commented: (LUCENE-2527) FieldCache.getTermsIndex should
cache fasterButMoreRAM=true|false to the same cache key
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914990#action_12914990 ]
Michael McCandless commented on LUCENE-2527:
--------------------------------------------
I believe LUCENE-2649 has fixed this, in that you will no longer get a double entry, and so whoever first populates this key "wins".
I think this is the right policy (vs a 2nd requires upgrading to fasterButMoreRAM=true, in place).
So I think all we should do here is add a test case that asserts that you don't get a double entry.
> FieldCache.getTermsIndex should cache fasterButMoreRAM=true|false to the same cache key
> ---------------------------------------------------------------------------------------
>
> Key: LUCENE-2527
> URL: https://issues.apache.org/jira/browse/LUCENE-2527
> Project: Lucene - Java
> Issue Type: Bug
> Components: Search
> Affects Versions: 4.0
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 4.0
>
>
> When we cutover FieldCache to use shared byte[] blocks, we added the boolean fasterButMoreRAM option, so you could tradeoff time/space.
> It defaults to true.
> The thinking is that an expert user, who wants to use false, could pre-populate FieldCache by loading the field with false, and then later when sorting on that field it'd use that same entry.
> But there's a bug -- when sorting, it then loads a 2nd entry with "true". This is because the Entry.custom in FieldCache participates in equals/hashCode.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] Updated: (LUCENE-2527) FieldCache.getTermsIndex should cache
fasterButMoreRAM=true|false to the same cache key
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Muir updated LUCENE-2527:
--------------------------------
Component/s: Search
> FieldCache.getTermsIndex should cache fasterButMoreRAM=true|false to the same cache key
> ---------------------------------------------------------------------------------------
>
> Key: LUCENE-2527
> URL: https://issues.apache.org/jira/browse/LUCENE-2527
> Project: Lucene - Java
> Issue Type: Bug
> Components: Search
> Affects Versions: 4.0
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 4.0
>
>
> When we cutover FieldCache to use shared byte[] blocks, we added the boolean fasterButMoreRAM option, so you could tradeoff time/space.
> It defaults to true.
> The thinking is that an expert user, who wants to use false, could pre-populate FieldCache by loading the field with false, and then later when sorting on that field it'd use that same entry.
> But there's a bug -- when sorting, it then loads a 2nd entry with "true". This is because the Entry.custom in FieldCache participates in equals/hashCode.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org