You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by Vitaly Funstein <vf...@gmail.com> on 2012/07/21 05:26:57 UTC
ReferenceManager.maybeRefreshBlocking() should not be declared
throwing InterruptedException
This probably belongs in the JIRA, and is related to
https://issues.apache.org/jira/browse/LUCENE-4025, but
java.util.Lock.lock() doesn't throw anything. I believe the author of the
change originally meant to use lockInterruptibly() inside but forgot to
adjust the method sig after changing it back to lock().
RE: ReferenceManager.maybeRefreshBlocking() should not be declared
throwing InterruptedException
Posted by Steven A Rowe <sa...@syr.edu>.
Hi Vitaly,
Info here should help you set up snapshot dependencies:
http://wiki.apache.org/lucene-java/NightlyBuilds
Steve
-----Original Message-----
From: Vitaly Funstein [mailto:vfunstein@gmail.com]
Sent: Saturday, July 21, 2012 9:22 PM
To: java-user@lucene.apache.org
Subject: Re: ReferenceManager.maybeRefreshBlocking() should not be declared throwing InterruptedException
Yeah, this is in 4.0-ALPHA. What should I updated my Maven dependency to
get the latest snapshots, instead - if that's where the fix is?
On Sat, Jul 21, 2012 at 4:16 AM, Michael McCandless <
lucene@mikemccandless.com> wrote:
> Thanks Vitaly.
>
> I think you are looking at an older 4.x/5.x version? We recently
> removed declaration of this (unchecked) exception... (LUCENE-4172).
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Fri, Jul 20, 2012 at 11:26 PM, Vitaly Funstein <vf...@gmail.com>
> wrote:
> > This probably belongs in the JIRA, and is related to
> > https://issues.apache.org/jira/browse/LUCENE-4025, but
> > java.util.Lock.lock() doesn't throw anything. I believe the author of the
> > change originally meant to use lockInterruptibly() inside but forgot to
> > adjust the method sig after changing it back to lock().
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: ReferenceManager.maybeRefreshBlocking() should not be declared
throwing InterruptedException
Posted by Vitaly Funstein <vf...@gmail.com>.
Yeah, this is in 4.0-ALPHA. What should I updated my Maven dependency to
get the latest snapshots, instead - if that's where the fix is?
On Sat, Jul 21, 2012 at 4:16 AM, Michael McCandless <
lucene@mikemccandless.com> wrote:
> Thanks Vitaly.
>
> I think you are looking at an older 4.x/5.x version? We recently
> removed declaration of this (unchecked) exception... (LUCENE-4172).
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Fri, Jul 20, 2012 at 11:26 PM, Vitaly Funstein <vf...@gmail.com>
> wrote:
> > This probably belongs in the JIRA, and is related to
> > https://issues.apache.org/jira/browse/LUCENE-4025, but
> > java.util.Lock.lock() doesn't throw anything. I believe the author of the
> > change originally meant to use lockInterruptibly() inside but forgot to
> > adjust the method sig after changing it back to lock().
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>
Re: ReferenceManager.maybeRefreshBlocking() should not be declared
throwing InterruptedException
Posted by Michael McCandless <lu...@mikemccandless.com>.
Thanks Vitaly.
I think you are looking at an older 4.x/5.x version? We recently
removed declaration of this (unchecked) exception... (LUCENE-4172).
Mike McCandless
http://blog.mikemccandless.com
On Fri, Jul 20, 2012 at 11:26 PM, Vitaly Funstein <vf...@gmail.com> wrote:
> This probably belongs in the JIRA, and is related to
> https://issues.apache.org/jira/browse/LUCENE-4025, but
> java.util.Lock.lock() doesn't throw anything. I believe the author of the
> change originally meant to use lockInterruptibly() inside but forgot to
> adjust the method sig after changing it back to lock().
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org