directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [ApacheDS] Recommendations for implementing search time limits
Date Wed, 20 Aug 2008 16:44:10 GMT
Hi Stefan,

On Wed, Aug 20, 2008 at 4:05 AM, Stefan Seelmann <seelmann@apache.org>wrote:

> Hi Alex,
>
> I would recommend to pass a monitor object to those cursors and
> evaluation loops:
>
> public interface Monitor
> {
>    public boolean isCanceled();
>    public void cancel( String cause );
>    public void cancel( Exception cause );
>    public Exception getCause();
>    ...
> }
>

This is an interesting idea.  I'm just thinking this might be redundant
though because we already have a isClosed(), close(), and close(Exception)
on the Cursor interface.  Wondering if there's some benefits I am not
seeing.


>
> An implementation SearchLimitMonitor could be constructed with the
> search time limit and its isCanceled() method then checks if the time
> limit is exceeded. Additional it could have a method cancel() that
> could be called by a timer thread, if there is such an requirement in
> the future.
>
> In the cursors then just check the Monitor.isCanceled(), instead of
> compararing the time limit parameters directly. Using this pattern we
> are more flexible, we could change the strategy to cancel the search
> request by changing the implementation of the monitor.
>

The problem I'm suspecting with using this that we have to pass this monitor
down into the Cursors in nesting.

Alex


>
>
> > Hi all,
> >
> > I have an interesting situation to deal with while trying to find a way
> to implement search time limits.  I'm a bit perplexed on how best to
> implement this and so any suggestions are great.  Here's a quick breakdown
> of the problem.
> >
> > Search requests must adhere to search time limits.  The request is used
> to build a system of nested Cursors and evaluators similar in structure to
> the search filter.  The final Cursor produced will return candidates
> accepted by the filter expression.  Cursors can be advanced using first(),
> last(), next(), and previous() methods.  While advancing a loop performs
> evaluations to find the first, last, next or previous candidate matching the
> filter.  Those entries not matching the filter a not returned.  It's a bit
> more complex than this but this trivial view is sufficient to discuss the
> problem.
> >
> > So we have to stop searching after some time limit.  Previously before
> the bigbang we used to just check the time limits high up in the code (in
> the search handler) after getting each candidate.  This did not always work
> so well because sometimes with very large directories and poor search
> filters it would take a while to find the next candidate to return so we
> would overshoot the time limit.   The problem is primarily due to these
> evaluation loops in the Cursor while trying to advance to a candidate.
>  While in this loop, going over entries that do not match, there is no way
> for the Cursor to detect that time is up.
> >
> > There are a few ways I thought we can solve this problem.  First these
> loops will have to check if the time is up between iterations either
> directly or indirectly through some parameter.  It would be nice if the
> Cursor can detect this on it's own but tunnelling the size limits deep down
> through this system of nested Cursors during construction is a real PITA.  I
> was thinking of using the closed/open state of the Cursor to naturally halt
> these loops.  This should happen anyway.  The only problem is another thread
> is needed in the SearchHandler to close the Cursor when time limits are
> exceeded.
> >
> > I talked to Emmanuel about this on IM and he preferred the approach where
> a Cursor is passed the time limits and handles timing out on it's own.  I'm
> not too keen on this idea because a Cursor by it's nature is not and may not
> be time limited.  However it does need to respond to being closed
> appropriately even while one thread is advancing it.  I think Emmanuel
> rightfully so dislikes the idea of having a timer thread (really a
> schedulable executor of tasks for closing search Cursors) in the search
> handler.  Don't know if others see a better option here or if one way is
> more preferrable than the other.
> >
> > Thoughts?
> >
> > Alex
> >
> > --
> > Microsoft gives you Windows, Linux gives you the whole house ...
>



-- 
Microsoft gives you Windows, Linux gives you the whole house ...

Mime
View raw message