You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Michael McCandless <lu...@mikemccandless.com> on 2009/10/28 12:53:44 UTC
Thread.interrupt()
As a followon to LUCENE-1573, we had stated that in 3.0 instead of
throwing RuntimeException when a Thread inside Lucene is interrupted,
we would throw InterruptedException.
Do we want to do this? Technically I think it's the right thing to
do, but, I started to implement it and found that it basically results
in nearly every API now throwing InterruptedException (just like
IOException).
Thoughts?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Thread.interrupt()
Posted by Yonik Seeley <yo...@lucidimagination.com>.
On Wed, Oct 28, 2009 at 7:53 AM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> As a followon to LUCENE-1573, we had stated that in 3.0 instead of
> throwing RuntimeException when a Thread inside Lucene is interrupted,
> we would throw InterruptedException.
>
> Do we want to do this? Technically I think it's the right thing to
> do, but, I started to implement it and found that it basically results
> in nearly every API now throwing InterruptedException (just like
> IOException).
>
> Thoughts?
One should not get an interrupted exception unless one specifically
interrupts the thread with the IndexWriter.
For the casual user, it doesn't seem useful to burden them with
InterruptedException, esp since they would normally not be able to
deal with it in a satisfactory manner anyway.
For an advanced user having a specific exception type could be
useful... so InterruptedRuntimeException? Or should it be a subclass
of IOException so it will be handled by the catch blocks already in
the users code?
-Yonik
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Thread.interrupt()
Posted by Michael McCandless <lu...@mikemccandless.com>.
I don't think this is really an IOException? IOException should be
for things IO related... eg your disk filled up, something's wrong
with the filesystem, permissions are wrong, etc.
Whereas this exception is trying to tell you "hey, you interrupted me,
so, I stopped".
Also, I don't think it's good to have existing IOException handlers
handle this, upon upgrading to 3.0: we are now wrapping the
InterruptedException in a RuntimeException, so if we change that to a
new class that subclasses IOException instead, it's a subtle break in
back-compat. Though I'd imagine not many apps are relying on getting
a RuntimeException upon interrupting Lucene...
Mike
On Wed, Oct 28, 2009 at 8:55 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> In this case (unchecked ex), we could have done that in 2.9, too :-)
>
> I would prefer IOException so normal handlers would catch it and stop
> indexing with a standard IO error (it is in fact an IOError, because
> IndexWriter is not able to complete the merge). If somebody ignores a
> IOException, it's his fault and his code will not work correctly.
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: Michael McCandless [mailto:lucene@mikemccandless.com]
>> Sent: Wednesday, October 28, 2009 1:48 PM
>> To: java-dev@lucene.apache.org
>> Subject: Re: Thread.interrupt()
>>
>> OK, I agree we shouldn't burden people with another checked exception.
>>
>> But we should differentiate it, so our own exception, subclassing
>> either RuntimeException or IOException sounds good.
>>
>> I think I'd prefer subclassing RuntimeException so that existing
>> handlers do not in fact suppress it. If you are advanced enough to be
>> calling Thread.interrupt (or using Futures, which can call
>> Thread.interrupt), then you should be able to handle the resulting
>> unchecked exception?
>>
>> Mike
>>
>> On Wed, Oct 28, 2009 at 8:37 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
>> > I have seen this yesterday, too (when coming around the assert
>> > Thread.holdsLock()), but I would not do that. How about defining a
>> subclass
>> > of RuntimeException like InterruptedRuntimeException, so it does not
>> need to
>> > be declared, but one could still catch it.
>> >
>> > Normally an interrupt inside Lucene would normally break a lot, so it is
>> not
>> > done alone with catching it in user code? InterruptedException is only
>> > useful if you want to really control coexistence of threads or break IO
>> > operations, but I would not recommend to interrupt any foreign thread
>> not
>> > part of your code (like a merging thread). If this was done by someone,
>> we
>> > are fine with throwing a fatal error in the indexer. Maybe make it a
>> > subclass of IOException (because the indexing IO is interrupted)?
>> >
>> > Uwe
>> >
>> > -----
>> > Uwe Schindler
>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>> > http://www.thetaphi.de
>> > eMail: uwe@thetaphi.de
>> >
>> >> -----Original Message-----
>> >> From: Michael McCandless [mailto:lucene@mikemccandless.com]
>> >> Sent: Wednesday, October 28, 2009 12:54 PM
>> >> To: java-dev@lucene.apache.org
>> >> Subject: Thread.interrupt()
>> >>
>> >> As a followon to LUCENE-1573, we had stated that in 3.0 instead of
>> >> throwing RuntimeException when a Thread inside Lucene is interrupted,
>> >> we would throw InterruptedException.
>> >>
>> >> Do we want to do this? Technically I think it's the right thing to
>> >> do, but, I started to implement it and found that it basically results
>> >> in nearly every API now throwing InterruptedException (just like
>> >> IOException).
>> >>
>> >> Thoughts?
>> >>
>> >> Mike
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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: Thread.interrupt()
Posted by Uwe Schindler <uw...@thetaphi.de>.
In this case (unchecked ex), we could have done that in 2.9, too :-)
I would prefer IOException so normal handlers would catch it and stop
indexing with a standard IO error (it is in fact an IOError, because
IndexWriter is not able to complete the merge). If somebody ignores a
IOException, it's his fault and his code will not work correctly.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Wednesday, October 28, 2009 1:48 PM
> To: java-dev@lucene.apache.org
> Subject: Re: Thread.interrupt()
>
> OK, I agree we shouldn't burden people with another checked exception.
>
> But we should differentiate it, so our own exception, subclassing
> either RuntimeException or IOException sounds good.
>
> I think I'd prefer subclassing RuntimeException so that existing
> handlers do not in fact suppress it. If you are advanced enough to be
> calling Thread.interrupt (or using Futures, which can call
> Thread.interrupt), then you should be able to handle the resulting
> unchecked exception?
>
> Mike
>
> On Wed, Oct 28, 2009 at 8:37 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> > I have seen this yesterday, too (when coming around the assert
> > Thread.holdsLock()), but I would not do that. How about defining a
> subclass
> > of RuntimeException like InterruptedRuntimeException, so it does not
> need to
> > be declared, but one could still catch it.
> >
> > Normally an interrupt inside Lucene would normally break a lot, so it is
> not
> > done alone with catching it in user code? InterruptedException is only
> > useful if you want to really control coexistence of threads or break IO
> > operations, but I would not recommend to interrupt any foreign thread
> not
> > part of your code (like a merging thread). If this was done by someone,
> we
> > are fine with throwing a fatal error in the indexer. Maybe make it a
> > subclass of IOException (because the indexing IO is interrupted)?
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> >> -----Original Message-----
> >> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> >> Sent: Wednesday, October 28, 2009 12:54 PM
> >> To: java-dev@lucene.apache.org
> >> Subject: Thread.interrupt()
> >>
> >> As a followon to LUCENE-1573, we had stated that in 3.0 instead of
> >> throwing RuntimeException when a Thread inside Lucene is interrupted,
> >> we would throw InterruptedException.
> >>
> >> Do we want to do this? Technically I think it's the right thing to
> >> do, but, I started to implement it and found that it basically results
> >> in nearly every API now throwing InterruptedException (just like
> >> IOException).
> >>
> >> Thoughts?
> >>
> >> Mike
> >>
> >> ---------------------------------------------------------------------
> >> 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: Thread.interrupt()
Posted by Michael McCandless <lu...@mikemccandless.com>.
OK, I agree we shouldn't burden people with another checked exception.
But we should differentiate it, so our own exception, subclassing
either RuntimeException or IOException sounds good.
I think I'd prefer subclassing RuntimeException so that existing
handlers do not in fact suppress it. If you are advanced enough to be
calling Thread.interrupt (or using Futures, which can call
Thread.interrupt), then you should be able to handle the resulting
unchecked exception?
Mike
On Wed, Oct 28, 2009 at 8:37 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> I have seen this yesterday, too (when coming around the assert
> Thread.holdsLock()), but I would not do that. How about defining a subclass
> of RuntimeException like InterruptedRuntimeException, so it does not need to
> be declared, but one could still catch it.
>
> Normally an interrupt inside Lucene would normally break a lot, so it is not
> done alone with catching it in user code? InterruptedException is only
> useful if you want to really control coexistence of threads or break IO
> operations, but I would not recommend to interrupt any foreign thread not
> part of your code (like a merging thread). If this was done by someone, we
> are fine with throwing a fatal error in the indexer. Maybe make it a
> subclass of IOException (because the indexing IO is interrupted)?
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>> -----Original Message-----
>> From: Michael McCandless [mailto:lucene@mikemccandless.com]
>> Sent: Wednesday, October 28, 2009 12:54 PM
>> To: java-dev@lucene.apache.org
>> Subject: Thread.interrupt()
>>
>> As a followon to LUCENE-1573, we had stated that in 3.0 instead of
>> throwing RuntimeException when a Thread inside Lucene is interrupted,
>> we would throw InterruptedException.
>>
>> Do we want to do this? Technically I think it's the right thing to
>> do, but, I started to implement it and found that it basically results
>> in nearly every API now throwing InterruptedException (just like
>> IOException).
>>
>> Thoughts?
>>
>> Mike
>>
>> ---------------------------------------------------------------------
>> 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: Thread.interrupt()
Posted by Uwe Schindler <uw...@thetaphi.de>.
I have seen this yesterday, too (when coming around the assert
Thread.holdsLock()), but I would not do that. How about defining a subclass
of RuntimeException like InterruptedRuntimeException, so it does not need to
be declared, but one could still catch it.
Normally an interrupt inside Lucene would normally break a lot, so it is not
done alone with catching it in user code? InterruptedException is only
useful if you want to really control coexistence of threads or break IO
operations, but I would not recommend to interrupt any foreign thread not
part of your code (like a merging thread). If this was done by someone, we
are fine with throwing a fatal error in the indexer. Maybe make it a
subclass of IOException (because the indexing IO is interrupted)?
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Wednesday, October 28, 2009 12:54 PM
> To: java-dev@lucene.apache.org
> Subject: Thread.interrupt()
>
> As a followon to LUCENE-1573, we had stated that in 3.0 instead of
> throwing RuntimeException when a Thread inside Lucene is interrupted,
> we would throw InterruptedException.
>
> Do we want to do this? Technically I think it's the right thing to
> do, but, I started to implement it and found that it basically results
> in nearly every API now throwing InterruptedException (just like
> IOException).
>
> Thoughts?
>
> Mike
>
> ---------------------------------------------------------------------
> 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