Yeah, not arguing that, it certainly would be optional.
Marked expert sounds fine I suppose. And maybe a note reminding that you
better release in a finally block...
Your the authority, and at this point im just going to defer...but there
is still something I don't like about that API...
Michael McCandless wrote:
I don't think you'd be required to call acquire / release? ... the
normal open, use reader, close would still be the dominant usage.
I think this new API would be marked expert, would be optional, and
would typically be used in applications that need to share an
IndexReader in multiple places (or threads) for an unpredictable
amount of time.
Mike
Mark Miller wrote:
I think I would buy this if the ref counting was somehow internal and
worked with the current API - but as an add on that requires that you
remember to call acquire and release? It just seems messy ... The
current ref counting is not exposed to the user.
- Mark
Michael McCandless wrote:
The counter argument here is: the ref counting that IndexReader
already implements is a precise match to this use case. Why
re-create the same logic above?
Lots of things (be they MultiSearchers or application's threads)
need to share access to a single IndexReader such that the reader
cannot be closed until all things have released their references.
Mike
Mark Miller wrote:
Hey Andi,
I think that the best way of dealing with this, as there is little
downside and it avoids further complicating IndexReader, is to
build your reference counting around the IndexReader class rather
than within it.
- Mark
Andi Vajda wrote:
I'd like to propose a patch for IndexReader but before I file a
proper bug
and attach the (simple) patch, I want to check here if my approach
is the
right one.
I have a server where a bunch of threads are handling search
requests. I
have a another process that updates the index used by the search
server and
that asks the searcher server to reopen its index reader after the
updates
completed.
When I reopen() the index reader, I also close the old one (if the
reopen()
yielded a new instance). This causes problems for the other
threads that
are currently in the middle of a search request.
I'd like to propose the addition of two methods, acquire() and
release() (see below), that increment/decrement the ref count that
IndexReader instances currently maintain for related purposes.
That ref count prevents the index reader from being actually
closed until it reaches zero.
My server's search threads, thus acquiring and releasing the index
reader can be sure that the index reader they're currently using
is good until they're done with the current request, ie, until
they release() it.
Is this the right way to go about this ?
Thanks !
Andi..
public synchronized void acquire()
throws AlreadyClosedException
{
ensureOpen();
incRef();
}
public synchronized void release()
throws AlreadyClosedException, IOException
{
ensureOpen();
decRef();
}
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]