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: u...@thetaphi.de From: Shai Erera [mailto:ser...@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 <ser...@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. <dsmi...@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-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
