lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: [VOTE] Lucene and Solr 3.1 release candidate
Date Tue, 08 Mar 2011 13:23:15 GMT
I think we already have code that maps exceptions to IOException ones. But
IAE is not catched. If Maps e.g. BufferUnderflowException to EOFException.
Maybe we should map all RuntimeExceptions inside the read/seek methods to
wrapped IOExceptions?

 

This is a bug that existed in MMap since the beginning, we fixed some of
them (the EOF case, because its needed even by Lucene internally). I don't
know how to proceed. Can you open an issue? I will be glad to fix it, but
not sure if we should need to fix it in the 3.1 branch as the bug already
existed (yes, I know MMap was not a default in 3.0).

 

Uwe

 

-----

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

 <http://www.thetaphi.de/> http://www.thetaphi.de

eMail: uwe@thetaphi.de

 

From: Shai Erera [mailto:serera@gmail.com] 
Sent: Tuesday, March 08, 2011 2:12 PM
To: dev@lucene.apache.org
Subject: Re: [VOTE] Lucene and Solr 3.1 release candidate

 

I found another problem.

Maybe something changed in the logic of FSDirectory.open(), but now when I
run some tests over my code, I see that if MMapDirectory is chosen and an
attempt to seek to an incorrect position is made, IllegalArgumentException
is thrown, instead of IOE. This breaks my code which catches IOE and handle
it.

While I can modify my code to also catch IAE, I wonder if it's ok that
MMapDir throws such an exception instead of IOE. It's actually thrown from
ByteBuffer, however the caller, which holds a reference to a Directory, does
not know if the underlying impl is MMapDir, LinuxFSDir etc.

Should we fix it on the new branch and go for a second RC?

Shai

On Tue, Mar 8, 2011 at 9:19 AM, Shai Erera <serera@gmail.com> wrote:

I found what seems to be a "glitch" in StopFilter's ctors -- the boolean
'enablePosInc' was removed from the ctors and users now have to use the
setter instead. However, the ctors do default to 'true' if the passed in
Version is onOrAfter(29).

All of FilteringTokenFilter sub-classes include the enablePosIncr in their
ctors, including FilteringTF itself. Therefore I assume the parameter was
mistakenly dropped from StopFilter's ctors. Also, the @deprecated text
doesn't mention how should I enable/disable it, and reading the source code
doesn't help either, since the setter/getter are in FilteringTF.

Also, LengthFilter has a deprecated ctor, but the class was added on Nov 16
and I don't see it in 3.0.3. So perhaps we can remove that ctor (and add a
@since tag to the class)?

I don't know if these two warrant a new RC but I think they are important to
fix.

Shai

 

On Mon, Mar 7, 2011 at 5:52 PM, Smiley, David W. <dsmiley@mitre.org> wrote:

So https://issues.apache.org/jira/browse/SOLR-2405 didn't make it in
yesterday (apparently it didn't)? :-(  Darn... maybe I shouldn't have waited
for a committer to agree with the issue. I would have had it in Saturday.

~ David Smiley

On Mar 7, 2011, at 1:32 AM, Robert Muir wrote:

> Hi all,
>
> I have posted a release candidate for both Lucene 3.1 and Solr 3.1,
> both from revision 1078688 of
> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/
> Thanks for all your help! Please test them and give your votes, the
> tentative release date for both versions is Sunday, March 13th, 2011.
> Only votes from Lucene PMC are binding, but everyone is welcome to
> check the release candidates and voice their approval or disapproval.
> The vote passes if at least three binding +1 votes are cast.
>
> The release candidates are produced in parallel because in 2010 we
> merged the development of Lucene and Solr in order to produce higher
> quality releases. While we voted to reserve the right to release
> Lucene by itself, in my opinion we should definitely try to avoid this
> unless absolutely necessary, as it would ultimately cause more work
> and complication: instead it would be far easier to just fix whatever
> issues are discovered and respin both releases again.
>
> Because of this, I ask that you cast a single vote to cover both
> releases. If the vote succeeds, both sets of artifacts can go their
> separate ways to the different websites.
>
> Artifacts are located here: http://s.apache.org/solrcene31rc0
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

 

 


Mime
View raw message