Hi Stefan,
On Wed, Aug 20, 2008 at 4:05 AM, Stefan Seelmann <[EMAIL PROTECTED]>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 ...
