You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Andi Vajda <va...@osafoundation.org> on 2008/07/17 16:54:02 UTC
IndexReader.acquire()/release() ?
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: IndexReader.acquire()/release() ?
Posted by Mark Miller <ma...@gmail.com>.
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 then 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: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: IndexReader.acquire()/release() ?
Posted by Andi Vajda <va...@osafoundation.org>.
On Fri, 18 Jul 2008, 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?
Agreed. I was very pleased to find incRef() and decRef() already
implemented. My patch just makes these methods with an ensureOpen() check.
> 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.
Ok, I'll file the bug with the patch the proper way then.
Thanks !
Andi..
>
> 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: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: IndexReader.acquire()/release() ?
Posted by Andi Vajda <va...@osafoundation.org>.
On Fri, 18 Jul 2008, Yonik Seeley wrote:
> Although I do wonder if incRef() and decRef() aren't more suitable
> names. Just make those methods public, which the caveat that one
> should not call them on a closed reader. They are expert level APIs
> after all.
That would work just as well. The acquire() and release() methods were
intended to do exactly that (and check that the index is still open).
Andi..
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: IndexReader.acquire()/release() ?
Posted by Michael McCandless <lu...@mikemccandless.com>.
Yonik Seeley wrote:
> Although I do wonder if incRef() and decRef() aren't more suitable
> names. Just make those methods public, which the caveat that one
> should not call them on a closed reader. They are expert level APIs
> after all.
+1
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: IndexReader.acquire()/release() ?
Posted by Yonik Seeley <yo...@apache.org>.
Although I do wonder if incRef() and decRef() aren't more suitable
names. Just make those methods public, which the caveat that one
should not call them on a closed reader. They are expert level APIs
after all.
On Fri, Jul 18, 2008 at 4:45 PM, Yonik Seeley <yo...@apache.org> wrote:
> On Fri, Jul 18, 2008 at 4:23 PM, Mark Miller <ma...@gmail.com> wrote:
>> but there is still something I don't like about that API...
>
> Perhaps that it's just a piece of the puzzle? It's doesn't seem
> sufficient by itself to allow multiple threads to easily share a
> reader. But it does seem like it could be a useful "expert level"
> component to enable an API that would allow that.
>
> -Yonik
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: IndexReader.acquire()/release() ?
Posted by Yonik Seeley <yo...@apache.org>.
On Fri, Jul 18, 2008 at 4:23 PM, Mark Miller <ma...@gmail.com> wrote:
> but there is still something I don't like about that API...
Perhaps that it's just a piece of the puzzle? It's doesn't seem
sufficient by itself to allow multiple threads to easily share a
reader. But it does seem like it could be a useful "expert level"
component to enable an API that would allow that.
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: IndexReader.acquire()/release() ?
Posted by Mark Miller <ma...@gmail.com>.
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: java-dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: IndexReader.acquire()/release() ?
Posted by Michael McCandless <lu...@mikemccandless.com>.
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: java-dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: IndexReader.acquire()/release() ?
Posted by Mark Miller <ma...@gmail.com>.
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: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: IndexReader.acquire()/release() ?
Posted by Michael McCandless <lu...@mikemccandless.com>.
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: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: IndexReader.acquire()/release() ?
Posted by Mark Miller <ma...@gmail.com>.
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: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org