lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1720) TimeLimitedIndexReader and associated utility class
Date Mon, 15 Feb 2010 14:59:28 GMT

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

Shai Erera commented on LUCENE-1720:
------------------------------------

Ok, it looks like ConcurrentHashMap cannot be used by ATM because of its TimeoutThread. When
the thread checks the map and iterates on its elements, we need to lock the map completely
because otherwise we can hit a case where the thread pulled an entry for inspection, and then
the thread which is monitored calls stop(), but the timeout thread won't know that any might
wrongly mark that thread as a timeout activity thread ...
Since checkForTimeout does not need to obtain any lock, and the synchronization happens on
start/stop/isProjected and TimeoutThread, I'm not sure how important is it to use CHM.

Another thing, CHM allows you to specify the concurrency level, which is essentially the number
of threads you know are going to 'change' the map (put or remove). If you don't know that,
and default to clevel=1, it means only one thread is expected to change the map, which in
ATM's case would yield to <0 benefit, since all the threads (which their number we don't
know up front) change the map ... of course we can guess, or try to, but ...

Anyway, I'm putting that aside for now, and moving no to adding more tests to TestTimeLimitingReader.

bq. getWrappedReader
Mark, the exception in the tests is thrown from SegmentReader.getOnlySegmentReader. I think
if we add this method to FilterIndexReader only and in getOnlySegmentReader we add this code:
{code}
if (reader instanceof FilterIndexReader) {
  return getOnlySegmentReader(((FilterIndexReader) reader).getWrappedReader());
}
{code}
It should work? This can be done in this issue I think as it doesn't break back-compat and
exposes a reasonable method where it should be. What do you think?

> TimeLimitedIndexReader and associated utility class
> ---------------------------------------------------
>
>                 Key: LUCENE-1720
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1720
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: Index
>            Reporter: Mark Harwood
>            Assignee: Mark Harwood
>            Priority: Minor
>         Attachments: ActivityTimedOutException.java, ActivityTimeMonitor.java, ActivityTimeMonitor.java,
ActivityTimeMonitor.java, Lucene-1720.patch, Lucene-1720.patch, LUCENE-1720.patch, TestTimeLimitedIndexReader.java,
TestTimeLimitedIndexReader.java, TimeLimitedIndexReader.java, TimeLimitedIndexReader.java
>
>
> An alternative to TimeLimitedCollector that has the following advantages:
> 1) Any reader activity can be time-limited rather than just single searches e.g. the
document retrieve phase.
> 2) Times out faster (i.e. runaway queries such as fuzzies detected quickly before last
"collect" stage of query processing)
> Uses new utility timeout class that is independent of IndexReader.
> Initial contribution includes a performance test class but not had time as yet to work
up a formal Junit test.
> TimeLimitedIndexReader is coded as JDK1.5 but can easily be undone.

-- 
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message