You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Robert Muir <rc...@gmail.com> on 2011/06/23 22:18:13 UTC
[VOTE] release 3.3
Artifacts here:
http://s.apache.org/lusolr33rc0
working release notes here:
http://wiki.apache.org/lucene-java/ReleaseNote33
http://wiki.apache.org/solr/ReleaseNote33
I ran the automated release test script in
trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the
top level 50 times on windows.
Here is my +1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] release 3.3
Posted by Uwe Schindler <uw...@thetaphi.de>.
Here the patch to fix the test bug, it's really a test bug - found thanks to Java 5. It was even wrong to use length(), correct would be size() for both and only use the minimum of both as allocation strategy may not be equal.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Uwe Schindler [mailto:uwe@thetaphi.de]
> Sent: Friday, June 24, 2011 6:06 PM
> To: dev@lucene.apache.org
> Subject: RE: [VOTE] release 3.3
>
> OK, the bug is not a Java 5 bug, its just a different behavior in the BitSet impl
> between java 5 and java 6.
>
> Java 5's BitSet impl allocates for new BitSet(0) always at least one word, so
> size() differs from OpenBitSet. This makes the test fail.
>
> The fix is to code the test correctly by using Math.min(BitSet.length(),
> OpenBitSet.size()) as upper limit and not assume the allocation strategy of
> both bitsets is identical.
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
> > -----Original Message-----
> > From: Uwe Schindler [mailto:uwe@thetaphi.de]
> > Sent: Friday, June 24, 2011 5:33 PM
> > To: dev@lucene.apache.org
> > Subject: RE: [VOTE] release 3.3
> >
> > The bug is *not* fixed by replacing Long.numberOfLeadingZeros(word)
> > with BitUtils.nlz(word).
> >
> > So this is really strange. Also happens with -Xbatch.
> >
> > -----
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> >
> > > -----Original Message-----
> > > From: Uwe Schindler [mailto:uwe@thetaphi.de]
> > > Sent: Friday, June 24, 2011 5:20 PM
> > > To: dev@lucene.apache.org
> > > Subject: RE: [VOTE] release 3.3
> > >
> > > I assume the problem is the intrinsic, I will replace by the own
> > > hacker's delight impl (like we do everywhere else in OpenBitSet, why
> > > did we use the platform method here?) and try again....
> > >
> > > Uwe
> > >
> > > -----
> > > Uwe Schindler
> > > H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de
> > > eMail: uwe@thetaphi.de
> > >
> > >
> > > > -----Original Message-----
> > > > From: Robert Muir [mailto:rcmuir@gmail.com]
> > > > Sent: Friday, June 24, 2011 5:07 PM
> > > > To: dev@lucene.apache.org
> > > > Subject: Re: [VOTE] release 3.3
> > > >
> > > > Just some more info: i took away the seed and used -Dtests.iter=100
> > > > on this
> > > > test:
> > > >
> > > > JAVA5:
> > > > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
> > > > [junit] Tests run: 400, Failures: 0, Errors: 23, Time elapsed:
> > > > 21.793 sec
> > > >
> > > > JAVA6:
> > > > junit-sequential:
> > > > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
> > > > [junit] Tests run: 400, Failures: 0, Errors: 0, Time elapsed:
> > > > 19.719 sec
> > > >
> > > > so this test fails 23% of the time on java5.
> > > >
> > > > The reason we never caught it, is that java5 is unmaintained and we
> > > > cannot even test it in hudson... aka we cannot support this monster
> > > anymore!!!!
> > > >
> > > > On Fri, Jun 24, 2011 at 11:02 AM, Robert Muir <rc...@gmail.com>
> > wrote:
> > > > > On Fri, Jun 24, 2011 at 10:54 AM, Uwe Schindler <uw...@thetaphi.de>
> > > > wrote:
> > > > >> The OpenBitSet test is in all cases serious (vs. the skiplist
> > > > >> test is a test bug,
> > > > that true).
> > > > >>
> > > > >> The AIOOBE is caused inside OpenBitSet and that should never ever
> > > > happen, even if you use it incorrectly!
> > > > >
> > > > > Its not clear that its that serious, it only fails with java 5 for
> > > > > me (not java 6) :)
> > > > >
> > > > > Looks like a bug in java 5...
> > > > >
> > > >
> > > > --------------------------------------------------------------------
> > > > - 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
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
RE: [VOTE] release 3.3
Posted by Uwe Schindler <uw...@thetaphi.de>.
OK, the bug is not a Java 5 bug, its just a different behavior in the BitSet impl between java 5 and java 6.
Java 5's BitSet impl allocates for new BitSet(0) always at least one word, so size() differs from OpenBitSet. This makes the test fail.
The fix is to code the test correctly by using Math.min(BitSet.length(), OpenBitSet.size()) as upper limit and not assume the allocation strategy of both bitsets is identical.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Uwe Schindler [mailto:uwe@thetaphi.de]
> Sent: Friday, June 24, 2011 5:33 PM
> To: dev@lucene.apache.org
> Subject: RE: [VOTE] release 3.3
>
> The bug is *not* fixed by replacing Long.numberOfLeadingZeros(word) with
> BitUtils.nlz(word).
>
> So this is really strange. Also happens with -Xbatch.
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
> > -----Original Message-----
> > From: Uwe Schindler [mailto:uwe@thetaphi.de]
> > Sent: Friday, June 24, 2011 5:20 PM
> > To: dev@lucene.apache.org
> > Subject: RE: [VOTE] release 3.3
> >
> > I assume the problem is the intrinsic, I will replace by the own
> > hacker's delight impl (like we do everywhere else in OpenBitSet, why
> > did we use the platform method here?) and try again....
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> >
> > > -----Original Message-----
> > > From: Robert Muir [mailto:rcmuir@gmail.com]
> > > Sent: Friday, June 24, 2011 5:07 PM
> > > To: dev@lucene.apache.org
> > > Subject: Re: [VOTE] release 3.3
> > >
> > > Just some more info: i took away the seed and used -Dtests.iter=100
> > > on this
> > > test:
> > >
> > > JAVA5:
> > > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
> > > [junit] Tests run: 400, Failures: 0, Errors: 23, Time elapsed:
> > > 21.793 sec
> > >
> > > JAVA6:
> > > junit-sequential:
> > > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
> > > [junit] Tests run: 400, Failures: 0, Errors: 0, Time elapsed:
> > > 19.719 sec
> > >
> > > so this test fails 23% of the time on java5.
> > >
> > > The reason we never caught it, is that java5 is unmaintained and we
> > > cannot even test it in hudson... aka we cannot support this monster
> > anymore!!!!
> > >
> > > On Fri, Jun 24, 2011 at 11:02 AM, Robert Muir <rc...@gmail.com>
> wrote:
> > > > On Fri, Jun 24, 2011 at 10:54 AM, Uwe Schindler <uw...@thetaphi.de>
> > > wrote:
> > > >> The OpenBitSet test is in all cases serious (vs. the skiplist
> > > >> test is a test bug,
> > > that true).
> > > >>
> > > >> The AIOOBE is caused inside OpenBitSet and that should never ever
> > > happen, even if you use it incorrectly!
> > > >
> > > > Its not clear that its that serious, it only fails with java 5 for
> > > > me (not java 6) :)
> > > >
> > > > Looks like a bug in java 5...
> > > >
> > >
> > > --------------------------------------------------------------------
> > > - 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
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [VOTE] release 3.3
Posted by Yonik Seeley <yo...@lucidimagination.com>.
On Fri, Jun 24, 2011 at 1:35 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
> Hi Yonik, I wrote atestcase that checks how prevSetBit behaves, if I add you
> patch with optimization. It still had a bug, if the index is beyond last
> word but not at a multiple of bitsPerWord.
Ahh, right, good catch! You want to start at the last bit rather than
calculate the bit via MOD in that case.
> Your additional optimization with negative indexes is invalid,
Well, invalid if negative indexes are valid.
> because on
> negative indexes prevSetBit() must be negative. If we don’t do this, a
> typical loop like would AIOOBE:
>
> for (int i = bs.prevSetBit(0); i >= 0; i = bs.prevSetBit(i-1)) {
> // operate on index i here
> }
Yep, that makes sense to allow.
-Yonik
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] release 3.3
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi Yonik, I wrote atestcase that checks how prevSetBit behaves, if I add you
patch with optimization. It still had a bug, if the index is beyond last
word but not at a multiple of bitsPerWord. The following code is correct:
public int prevSetBit(int index) {
int i = index >> 6;
final int subIndex;
if (i >= wlen) {
i = wlen - 1;
if (i < 0) return -1;
subIndex = 0x3f; // last possible bit
} else {
if (i < 0) return -1;
subIndex = index & 0x3f; // index within the word
}
long word = (bits[i] << (63-subIndex)); // skip all the bits to the
left of index
if (word != 0) {
return (i << 6) + subIndex - Long.numberOfLeadingZeros(word); // See
LUCENE-3197
}
while (--i >= 0) {
word = bits[i];
if (word !=0 ) {
return (i << 6) + 63 - Long.numberOfLeadingZeros(word);
}
}
return -1;
}
Your additional optimization with negative indexes is invalid, because on
negative indexes prevSetBit() must be negative. If we dont do this, a
typical loop like would AIOOBE:
for (int i = bs.prevSetBit(0); i >= 0; i = bs.prevSetBit(i-1)) {
// operate on index i here
}
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: yseeley@gmail.com [mailto:yseeley@gmail.com] On Behalf Of Yonik
> Seeley
> Sent: Friday, June 24, 2011 6:29 PM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] release 3.3
>
> On Fri, Jun 24, 2011 at 12:14 PM, Yonik Seeley
<yo...@lucidimagination.com>
> wrote:
> > All that needs to be done is to move the negative index check to the
> > bottom (the first index<0 is not needed since we do a signed shift).
> >
> > public int prevSetBit(int index) {
> > int i = index>>6;
> > if (i >= wlen) {
> > i = wlen - 1;
> > }
> > if (i < 0) return -1;
> > final int subIndex = index & 0x3f; // index within the word
> > long word = (bits[i] << (63-subIndex)); // skip all the bits to
> > the left of index
>
> And a further minor optimization, if we assume that negative indexes are
not
> legal, is to move the (i<0) check inside the if (i>=wlen) block (and just
let a
> negative index passed by the user to cause a natural AIOOB).
>
> -Yonik
> http://www.lucidimagination.com
>
> ---------------------------------------------------------------------
> 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
RE: [VOTE] release 3.3
Posted by Uwe Schindler <uw...@thetaphi.de>.
Yonik,
You are the best. If you look at the test, its also broken somehow, because
it uses length vs. size() wrong (I already reopened the
https://issues.apache.org/jira/browse/LUCENE-3179 issue).
And please stop ranting about Java 5, it helped to find a bug in this impl,
its really broken as OpenBitSet always allows indexes >= size (except fast*
methods).
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: yseeley@gmail.com [mailto:yseeley@gmail.com] On Behalf Of Yonik
> Seeley
> Sent: Friday, June 24, 2011 6:29 PM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] release 3.3
>
> On Fri, Jun 24, 2011 at 12:14 PM, Yonik Seeley
<yo...@lucidimagination.com>
> wrote:
> > All that needs to be done is to move the negative index check to the
> > bottom (the first index<0 is not needed since we do a signed shift).
> >
> > public int prevSetBit(int index) {
> > int i = index>>6;
> > if (i >= wlen) {
> > i = wlen - 1;
> > }
> > if (i < 0) return -1;
> > final int subIndex = index & 0x3f; // index within the word
> > long word = (bits[i] << (63-subIndex)); // skip all the bits to
> > the left of index
>
> And a further minor optimization, if we assume that negative indexes are
not
> legal, is to move the (i<0) check inside the if (i>=wlen) block (and just
let a
> negative index passed by the user to cause a natural AIOOB).
>
> -Yonik
> http://www.lucidimagination.com
>
> ---------------------------------------------------------------------
> 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
Re: [VOTE] release 3.3
Posted by Yonik Seeley <yo...@lucidimagination.com>.
On Fri, Jun 24, 2011 at 12:14 PM, Yonik Seeley
<yo...@lucidimagination.com> wrote:
> All that needs to be done is to move the negative index check to the
> bottom (the first index<0 is not needed since we do a signed shift).
>
> public int prevSetBit(int index) {
> int i = index>>6;
> if (i >= wlen) {
> i = wlen - 1;
> }
> if (i < 0) return -1;
> final int subIndex = index & 0x3f; // index within the word
> long word = (bits[i] << (63-subIndex)); // skip all the bits to
> the left of index
And a further minor optimization, if we assume that negative indexes
are not legal, is to move the (i<0) check inside the if (i>=wlen)
block (and just let a negative index passed by the user to cause a
natural AIOOB).
-Yonik
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] release 3.3
Posted by Yonik Seeley <yo...@lucidimagination.com>.
I just took a quick peek at the prevBitSet, and the implementation
looks buggy (provided that it's legal for a user to pass an "i" that
may be greater than the largest bit ever set).
Here is the current code, which will cause an exception when wlen==0.
public int prevSetBit(int index) {
if (index < 0) {
return -1;
}
int i = index>>6;
if (i >= wlen) {
i = wlen - 1;
}
final int subIndex = index & 0x3f; // index within the word
long word = (bits[i] << (63-subIndex)); // skip all the bits to
the left of index
All that needs to be done is to move the negative index check to the
bottom (the first index<0 is not needed since we do a signed shift).
public int prevSetBit(int index) {
int i = index>>6;
if (i >= wlen) {
i = wlen - 1;
}
if (i < 0) return -1;
final int subIndex = index & 0x3f; // index within the word
long word = (bits[i] << (63-subIndex)); // skip all the bits to
the left of index
-Yonik
http://www.lucidimagination.com
On Fri, Jun 24, 2011 at 11:33 AM, Robert Muir <rc...@gmail.com> wrote:
> And -Xint and -client
>
> On Fri, Jun 24, 2011 at 11:32 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
>> The bug is *not* fixed by replacing Long.numberOfLeadingZeros(word) with BitUtils.nlz(word).
>>
>> So this is really strange. Also happens with -Xbatch.
>>
>> -----
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: uwe@thetaphi.de
>>
>>
>>> -----Original Message-----
>>> From: Uwe Schindler [mailto:uwe@thetaphi.de]
>>> Sent: Friday, June 24, 2011 5:20 PM
>>> To: dev@lucene.apache.org
>>> Subject: RE: [VOTE] release 3.3
>>>
>>> I assume the problem is the intrinsic, I will replace by the own hacker's
>>> delight impl (like we do everywhere else in OpenBitSet, why did we use the
>>> platform method here?) and try again....
>>>
>>> Uwe
>>>
>>> -----
>>> Uwe Schindler
>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>> http://www.thetaphi.de
>>> eMail: uwe@thetaphi.de
>>>
>>>
>>> > -----Original Message-----
>>> > From: Robert Muir [mailto:rcmuir@gmail.com]
>>> > Sent: Friday, June 24, 2011 5:07 PM
>>> > To: dev@lucene.apache.org
>>> > Subject: Re: [VOTE] release 3.3
>>> >
>>> > Just some more info: i took away the seed and used -Dtests.iter=100 on
>>> > this
>>> > test:
>>> >
>>> > JAVA5:
>>> > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
>>> > [junit] Tests run: 400, Failures: 0, Errors: 23, Time elapsed:
>>> > 21.793 sec
>>> >
>>> > JAVA6:
>>> > junit-sequential:
>>> > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
>>> > [junit] Tests run: 400, Failures: 0, Errors: 0, Time elapsed:
>>> > 19.719 sec
>>> >
>>> > so this test fails 23% of the time on java5.
>>> >
>>> > The reason we never caught it, is that java5 is unmaintained and we
>>> > cannot even test it in hudson... aka we cannot support this monster
>>> anymore!!!!
>>> >
>>> > On Fri, Jun 24, 2011 at 11:02 AM, Robert Muir <rc...@gmail.com> wrote:
>>> > > On Fri, Jun 24, 2011 at 10:54 AM, Uwe Schindler <uw...@thetaphi.de>
>>> > wrote:
>>> > >> The OpenBitSet test is in all cases serious (vs. the skiplist test
>>> > >> is a test bug,
>>> > that true).
>>> > >>
>>> > >> The AIOOBE is caused inside OpenBitSet and that should never ever
>>> > happen, even if you use it incorrectly!
>>> > >
>>> > > Its not clear that its that serious, it only fails with java 5 for
>>> > > me (not java 6) :)
>>> > >
>>> > > Looks like a bug in java 5...
>>> > >
>>> >
>>> > ---------------------------------------------------------------------
>>> > 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
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] release 3.3
Posted by Robert Muir <rc...@gmail.com>.
And -Xint and -client
On Fri, Jun 24, 2011 at 11:32 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> The bug is *not* fixed by replacing Long.numberOfLeadingZeros(word) with BitUtils.nlz(word).
>
> So this is really strange. Also happens with -Xbatch.
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: Uwe Schindler [mailto:uwe@thetaphi.de]
>> Sent: Friday, June 24, 2011 5:20 PM
>> To: dev@lucene.apache.org
>> Subject: RE: [VOTE] release 3.3
>>
>> I assume the problem is the intrinsic, I will replace by the own hacker's
>> delight impl (like we do everywhere else in OpenBitSet, why did we use the
>> platform method here?) and try again....
>>
>> Uwe
>>
>> -----
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: uwe@thetaphi.de
>>
>>
>> > -----Original Message-----
>> > From: Robert Muir [mailto:rcmuir@gmail.com]
>> > Sent: Friday, June 24, 2011 5:07 PM
>> > To: dev@lucene.apache.org
>> > Subject: Re: [VOTE] release 3.3
>> >
>> > Just some more info: i took away the seed and used -Dtests.iter=100 on
>> > this
>> > test:
>> >
>> > JAVA5:
>> > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
>> > [junit] Tests run: 400, Failures: 0, Errors: 23, Time elapsed:
>> > 21.793 sec
>> >
>> > JAVA6:
>> > junit-sequential:
>> > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
>> > [junit] Tests run: 400, Failures: 0, Errors: 0, Time elapsed:
>> > 19.719 sec
>> >
>> > so this test fails 23% of the time on java5.
>> >
>> > The reason we never caught it, is that java5 is unmaintained and we
>> > cannot even test it in hudson... aka we cannot support this monster
>> anymore!!!!
>> >
>> > On Fri, Jun 24, 2011 at 11:02 AM, Robert Muir <rc...@gmail.com> wrote:
>> > > On Fri, Jun 24, 2011 at 10:54 AM, Uwe Schindler <uw...@thetaphi.de>
>> > wrote:
>> > >> The OpenBitSet test is in all cases serious (vs. the skiplist test
>> > >> is a test bug,
>> > that true).
>> > >>
>> > >> The AIOOBE is caused inside OpenBitSet and that should never ever
>> > happen, even if you use it incorrectly!
>> > >
>> > > Its not clear that its that serious, it only fails with java 5 for
>> > > me (not java 6) :)
>> > >
>> > > Looks like a bug in java 5...
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > 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
>
>
>
> ---------------------------------------------------------------------
> 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
RE: [VOTE] release 3.3
Posted by Uwe Schindler <uw...@thetaphi.de>.
The bug is *not* fixed by replacing Long.numberOfLeadingZeros(word) with BitUtils.nlz(word).
So this is really strange. Also happens with -Xbatch.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Uwe Schindler [mailto:uwe@thetaphi.de]
> Sent: Friday, June 24, 2011 5:20 PM
> To: dev@lucene.apache.org
> Subject: RE: [VOTE] release 3.3
>
> I assume the problem is the intrinsic, I will replace by the own hacker's
> delight impl (like we do everywhere else in OpenBitSet, why did we use the
> platform method here?) and try again....
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
> > -----Original Message-----
> > From: Robert Muir [mailto:rcmuir@gmail.com]
> > Sent: Friday, June 24, 2011 5:07 PM
> > To: dev@lucene.apache.org
> > Subject: Re: [VOTE] release 3.3
> >
> > Just some more info: i took away the seed and used -Dtests.iter=100 on
> > this
> > test:
> >
> > JAVA5:
> > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
> > [junit] Tests run: 400, Failures: 0, Errors: 23, Time elapsed:
> > 21.793 sec
> >
> > JAVA6:
> > junit-sequential:
> > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
> > [junit] Tests run: 400, Failures: 0, Errors: 0, Time elapsed:
> > 19.719 sec
> >
> > so this test fails 23% of the time on java5.
> >
> > The reason we never caught it, is that java5 is unmaintained and we
> > cannot even test it in hudson... aka we cannot support this monster
> anymore!!!!
> >
> > On Fri, Jun 24, 2011 at 11:02 AM, Robert Muir <rc...@gmail.com> wrote:
> > > On Fri, Jun 24, 2011 at 10:54 AM, Uwe Schindler <uw...@thetaphi.de>
> > wrote:
> > >> The OpenBitSet test is in all cases serious (vs. the skiplist test
> > >> is a test bug,
> > that true).
> > >>
> > >> The AIOOBE is caused inside OpenBitSet and that should never ever
> > happen, even if you use it incorrectly!
> > >
> > > Its not clear that its that serious, it only fails with java 5 for
> > > me (not java 6) :)
> > >
> > > Looks like a bug in java 5...
> > >
> >
> > ---------------------------------------------------------------------
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] release 3.3
Posted by Uwe Schindler <uw...@thetaphi.de>.
I assume the problem is the intrinsic, I will replace by the own hacker's delight impl (like we do everywhere else in OpenBitSet, why did we use the platform method here?) and try again....
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Robert Muir [mailto:rcmuir@gmail.com]
> Sent: Friday, June 24, 2011 5:07 PM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] release 3.3
>
> Just some more info: i took away the seed and used -Dtests.iter=100 on this
> test:
>
> JAVA5:
> [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
> [junit] Tests run: 400, Failures: 0, Errors: 23, Time elapsed: 21.793 sec
>
> JAVA6:
> junit-sequential:
> [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
> [junit] Tests run: 400, Failures: 0, Errors: 0, Time elapsed: 19.719 sec
>
> so this test fails 23% of the time on java5.
>
> The reason we never caught it, is that java5 is unmaintained and we cannot
> even test it in hudson... aka we cannot support this monster anymore!!!!
>
> On Fri, Jun 24, 2011 at 11:02 AM, Robert Muir <rc...@gmail.com> wrote:
> > On Fri, Jun 24, 2011 at 10:54 AM, Uwe Schindler <uw...@thetaphi.de>
> wrote:
> >> The OpenBitSet test is in all cases serious (vs. the skiplist test is a test bug,
> that true).
> >>
> >> The AIOOBE is caused inside OpenBitSet and that should never ever
> happen, even if you use it incorrectly!
> >
> > Its not clear that its that serious, it only fails with java 5 for me
> > (not java 6) :)
> >
> > Looks like a bug in java 5...
> >
>
> ---------------------------------------------------------------------
> 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
Re: [VOTE] release 3.3
Posted by Robert Muir <rc...@gmail.com>.
Just some more info: i took away the seed and used -Dtests.iter=100 on
this test:
JAVA5:
[junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
[junit] Tests run: 400, Failures: 0, Errors: 23, Time elapsed: 21.793 sec
JAVA6:
junit-sequential:
[junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
[junit] Tests run: 400, Failures: 0, Errors: 0, Time elapsed: 19.719 sec
so this test fails 23% of the time on java5.
The reason we never caught it, is that java5 is unmaintained and we
cannot even test it in hudson... aka we cannot support this monster
anymore!!!!
On Fri, Jun 24, 2011 at 11:02 AM, Robert Muir <rc...@gmail.com> wrote:
> On Fri, Jun 24, 2011 at 10:54 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
>> The OpenBitSet test is in all cases serious (vs. the skiplist test is a test bug, that true).
>>
>> The AIOOBE is caused inside OpenBitSet and that should never ever happen, even if you use it incorrectly!
>
> Its not clear that its that serious, it only fails with java 5 for me
> (not java 6) :)
>
> Looks like a bug in java 5...
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] release 3.3
Posted by Robert Muir <rc...@gmail.com>.
On Fri, Jun 24, 2011 at 10:54 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> The OpenBitSet test is in all cases serious (vs. the skiplist test is a test bug, that true).
>
> The AIOOBE is caused inside OpenBitSet and that should never ever happen, even if you use it incorrectly!
Its not clear that its that serious, it only fails with java 5 for me
(not java 6) :)
Looks like a bug in java 5...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] release 3.3
Posted by Uwe Schindler <uw...@thetaphi.de>.
The OpenBitSet test is in all cases serious (vs. the skiplist test is a test bug, that true).
The AIOOBE is caused inside OpenBitSet and that should never ever happen, even if you use it incorrectly!
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Robert Muir [mailto:rcmuir@gmail.com]
> Sent: Friday, June 24, 2011 4:47 PM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] release 3.3
>
> This might be the cause of the test failures in the skiplist (I will investigate!).
>
> In general, not all tests are guaranteed to work correctly with tests.iter > 1,
> some tests have bugs!
>
> On Fri, Jun 24, 2011 at 10:45 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> > I forgot to mention, all tests of core were running 95 minutes using -
> Dtests.multiplier=100 and -Dtests.iter=100 !
> >
> > -----
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> >
> >> -----Original Message-----
> >> From: Uwe Schindler [mailto:uwe@thetaphi.de]
> >> Sent: Friday, June 24, 2011 4:44 PM
> >> To: dev@lucene.apache.org
> >> Subject: RE: [VOTE] release 3.3
> >> iter
> >> Hi,
> >>
> >> I run some smoke tests yesterday on the Lucene 2.9/3.0 release
> >> machine I used. The machine runs Java 1.5.0_22, Solaris x64, Opteron
> >> 16 cores. One of the tests was already fixed by Robert (I told him
> >> yesterday because it was always failing).
> >>
> >> The others are maybe serious, maybe not:
> >>
> >> [junit] Testsuite: org.apache.lucene.index.TestMultiLevelSkipList
> >> [junit] Testcase:
> >> testSimpleSkip(org.apache.lucene.index.TestMultiLevelSkipList):
> >> FAILED
> >> [junit] Wrong payload for the target 14: -106 expected:<14> but
> >> was:<-
> >> 106>
> >> [junit] junit.framework.AssertionFailedError: Wrong payload for
> >> the target
> >> 14: -106 expected:<14> but was:<-106>
> >> [junit] at
> >> org.apache.lucene.index.TestMultiLevelSkipList.checkSkipTo(TestMultiL
> >> evel
> >> SkipList.java:87)
> >> [junit] at
> >> org.apache.lucene.index.TestMultiLevelSkipList.testSimpleSkip(TestMul
> >> tiLev
> >> elSkipList.java:66)
> >> [junit] at
> >>
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(L
> >> uc
> >> eneTestCase.java:1272)
> >> [junit] at
> >>
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(L
> >> uc
> >> eneTestCase.java:1190)
> >>
> >> ...( 100 repetitions of same stack trace) and then about 100 times
> >> with different seeds:
> >>
> >> [junit] NOTE: reproduce with: ant test
> >> -Dtestcase=TestMultiLevelSkipList - Dtestmethod=testSimpleSkip -
> >> Dtests.seed=2861480580591035682:880958701285368932
> >>
> >> But it's not reproduceable, so maybe its only the repetition causing this!
> >>
> >> This one is very serious and easy to reproduce with every printed seed:
> >>
> >> [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
> >> [junit] Testcase:
> >> testSmall(org.apache.lucene.util.TestOpenBitSet): Caused an
> >> ERROR
> >> [junit] -1
> >> [junit] java.lang.ArrayIndexOutOfBoundsException: -1
> >> [junit] at
> >> org.apache.lucene.util.OpenBitSet.prevSetBit(OpenBitSet.java:671)
> >> [junit] at
> >> org.apache.lucene.util.TestOpenBitSet.doPrevSetBit(TestOpenBitSet.jav
> >> a:53
> >> )
> >> [junit] at
> >>
> org.apache.lucene.util.TestOpenBitSet.doRandomSets(TestOpenBitSet.java:
> >> 148)
> >> [junit] at
> >> org.apache.lucene.util.TestOpenBitSet.testSmall(TestOpenBitSet.java:1
> >> 92)
> >> [junit] at
> >>
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(L
> >> uc
> >> eneTestCase.java:1272)
> >> [junit] at
> >>
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(L
> >> uc
> >> eneTestCase.java:1190)
> >> [junit]
> >> [junit]
> >> [junit] Testcase:
> >> testSmall(org.apache.lucene.util.TestOpenBitSet): Caused an
> >> ERROR
> >> [junit] (null)
> >> [junit] java.lang.ArrayIndexOutOfBoundsException
> >> [junit]
> >> [junit]
> >> [junit] Testcase:
> >> testSmall(org.apache.lucene.util.TestOpenBitSet): Caused an
> >> ERROR
> >> [junit] (null)
> >> [junit] java.lang.ArrayIndexOutOfBoundsException
> >> [junit]
> >> [junit]
> >>
> >> ... following lots of times the (null) AIOOBE message...
> >>
> >> [junit] NOTE: reproduce with: ant test -Dtestcase=TestOpenBitSet
> >> - Dtestmethod=testSmall -Dtests.seed=-
> >> 4526826707499307278:4139930264431857886
> >>
> >> Again with different seeds. But not all 100 repetitions fail, so the
> >> ones mentioned should fail, but reproduceible.
> >>
> >>
> >> The good news: PANGAEA index works fine, no readVInt hotspot
> problems
> >> with Java 6! Thanks Robert for fixing in 3.1, but after changes in
> >> MMap they could have reappeared.
> >>
> >> So this release candidate is in my opinion broken! -1 to release.
> >>
> >> Uwe
> >>
> >> -----
> >> Uwe Schindler
> >> H.-H.-Meier-Allee 63, D-28213 Bremen
> >> http://www.thetaphi.de
> >> eMail: uwe@thetaphi.de
> >>
> >>
> >> > -----Original Message-----
> >> > From: Robert Muir [mailto:rcmuir@gmail.com]
> >> > Sent: Thursday, June 23, 2011 10:18 PM
> >> > To: dev@lucene.apache.org
> >> > Subject: [VOTE] release 3.3
> >> >
> >> > Artifacts here:
> >> >
> >> > http://s.apache.org/lusolr33rc0
> >> >
> >> > working release notes here:
> >> >
> >> > http://wiki.apache.org/lucene-java/ReleaseNote33
> >> > http://wiki.apache.org/solr/ReleaseNote33
> >> >
> >> > I ran the automated release test script in trunk/dev-
> >> > tools/scripts/smokeTestRelease.py, and ran 'ant test' at the top
> >> > level
> >> > 50 times on windows.
> >> > Here is my +1
> >> >
> >> > -------------------------------------------------------------------
> >> > -- 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
Re: [VOTE] release 3.3
Posted by Robert Muir <rc...@gmail.com>.
This might be the cause of the test failures in the skiplist (I will
investigate!).
In general, not all tests are guaranteed to work correctly with
tests.iter > 1, some tests have bugs!
On Fri, Jun 24, 2011 at 10:45 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> I forgot to mention, all tests of core were running 95 minutes using -Dtests.multiplier=100 and -Dtests.iter=100 !
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: Uwe Schindler [mailto:uwe@thetaphi.de]
>> Sent: Friday, June 24, 2011 4:44 PM
>> To: dev@lucene.apache.org
>> Subject: RE: [VOTE] release 3.3
>> iter
>> Hi,
>>
>> I run some smoke tests yesterday on the Lucene 2.9/3.0 release machine I
>> used. The machine runs Java 1.5.0_22, Solaris x64, Opteron 16 cores. One of
>> the tests was already fixed by Robert (I told him yesterday because it was
>> always failing).
>>
>> The others are maybe serious, maybe not:
>>
>> [junit] Testsuite: org.apache.lucene.index.TestMultiLevelSkipList
>> [junit] Testcase:
>> testSimpleSkip(org.apache.lucene.index.TestMultiLevelSkipList): FAILED
>> [junit] Wrong payload for the target 14: -106 expected:<14> but was:<-
>> 106>
>> [junit] junit.framework.AssertionFailedError: Wrong payload for the target
>> 14: -106 expected:<14> but was:<-106>
>> [junit] at
>> org.apache.lucene.index.TestMultiLevelSkipList.checkSkipTo(TestMultiLevel
>> SkipList.java:87)
>> [junit] at
>> org.apache.lucene.index.TestMultiLevelSkipList.testSimpleSkip(TestMultiLev
>> elSkipList.java:66)
>> [junit] at
>> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc
>> eneTestCase.java:1272)
>> [junit] at
>> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc
>> eneTestCase.java:1190)
>>
>> ...( 100 repetitions of same stack trace) and then about 100 times with
>> different seeds:
>>
>> [junit] NOTE: reproduce with: ant test -Dtestcase=TestMultiLevelSkipList -
>> Dtestmethod=testSimpleSkip -
>> Dtests.seed=2861480580591035682:880958701285368932
>>
>> But it's not reproduceable, so maybe its only the repetition causing this!
>>
>> This one is very serious and easy to reproduce with every printed seed:
>>
>> [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
>> [junit] Testcase: testSmall(org.apache.lucene.util.TestOpenBitSet): Caused
>> an ERROR
>> [junit] -1
>> [junit] java.lang.ArrayIndexOutOfBoundsException: -1
>> [junit] at
>> org.apache.lucene.util.OpenBitSet.prevSetBit(OpenBitSet.java:671)
>> [junit] at
>> org.apache.lucene.util.TestOpenBitSet.doPrevSetBit(TestOpenBitSet.java:53
>> )
>> [junit] at
>> org.apache.lucene.util.TestOpenBitSet.doRandomSets(TestOpenBitSet.java:
>> 148)
>> [junit] at
>> org.apache.lucene.util.TestOpenBitSet.testSmall(TestOpenBitSet.java:192)
>> [junit] at
>> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc
>> eneTestCase.java:1272)
>> [junit] at
>> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc
>> eneTestCase.java:1190)
>> [junit]
>> [junit]
>> [junit] Testcase: testSmall(org.apache.lucene.util.TestOpenBitSet): Caused
>> an ERROR
>> [junit] (null)
>> [junit] java.lang.ArrayIndexOutOfBoundsException
>> [junit]
>> [junit]
>> [junit] Testcase: testSmall(org.apache.lucene.util.TestOpenBitSet): Caused
>> an ERROR
>> [junit] (null)
>> [junit] java.lang.ArrayIndexOutOfBoundsException
>> [junit]
>> [junit]
>>
>> ... following lots of times the (null) AIOOBE message...
>>
>> [junit] NOTE: reproduce with: ant test -Dtestcase=TestOpenBitSet -
>> Dtestmethod=testSmall -Dtests.seed=-
>> 4526826707499307278:4139930264431857886
>>
>> Again with different seeds. But not all 100 repetitions fail, so the ones
>> mentioned should fail, but reproduceible.
>>
>>
>> The good news: PANGAEA index works fine, no readVInt hotspot problems
>> with Java 6! Thanks Robert for fixing in 3.1, but after changes in MMap they
>> could have reappeared.
>>
>> So this release candidate is in my opinion broken! -1 to release.
>>
>> Uwe
>>
>> -----
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: uwe@thetaphi.de
>>
>>
>> > -----Original Message-----
>> > From: Robert Muir [mailto:rcmuir@gmail.com]
>> > Sent: Thursday, June 23, 2011 10:18 PM
>> > To: dev@lucene.apache.org
>> > Subject: [VOTE] release 3.3
>> >
>> > Artifacts here:
>> >
>> > http://s.apache.org/lusolr33rc0
>> >
>> > working release notes here:
>> >
>> > http://wiki.apache.org/lucene-java/ReleaseNote33
>> > http://wiki.apache.org/solr/ReleaseNote33
>> >
>> > I ran the automated release test script in trunk/dev-
>> > tools/scripts/smokeTestRelease.py, and ran 'ant test' at the top level
>> > 50 times on windows.
>> > Here is my +1
>> >
>> > ---------------------------------------------------------------------
>> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] release 3.3
Posted by Uwe Schindler <uw...@thetaphi.de>.
I forgot to mention, all tests of core were running 95 minutes using -Dtests.multiplier=100 and -Dtests.iter=100 !
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Uwe Schindler [mailto:uwe@thetaphi.de]
> Sent: Friday, June 24, 2011 4:44 PM
> To: dev@lucene.apache.org
> Subject: RE: [VOTE] release 3.3
> iter
> Hi,
>
> I run some smoke tests yesterday on the Lucene 2.9/3.0 release machine I
> used. The machine runs Java 1.5.0_22, Solaris x64, Opteron 16 cores. One of
> the tests was already fixed by Robert (I told him yesterday because it was
> always failing).
>
> The others are maybe serious, maybe not:
>
> [junit] Testsuite: org.apache.lucene.index.TestMultiLevelSkipList
> [junit] Testcase:
> testSimpleSkip(org.apache.lucene.index.TestMultiLevelSkipList): FAILED
> [junit] Wrong payload for the target 14: -106 expected:<14> but was:<-
> 106>
> [junit] junit.framework.AssertionFailedError: Wrong payload for the target
> 14: -106 expected:<14> but was:<-106>
> [junit] at
> org.apache.lucene.index.TestMultiLevelSkipList.checkSkipTo(TestMultiLevel
> SkipList.java:87)
> [junit] at
> org.apache.lucene.index.TestMultiLevelSkipList.testSimpleSkip(TestMultiLev
> elSkipList.java:66)
> [junit] at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc
> eneTestCase.java:1272)
> [junit] at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc
> eneTestCase.java:1190)
>
> ...( 100 repetitions of same stack trace) and then about 100 times with
> different seeds:
>
> [junit] NOTE: reproduce with: ant test -Dtestcase=TestMultiLevelSkipList -
> Dtestmethod=testSimpleSkip -
> Dtests.seed=2861480580591035682:880958701285368932
>
> But it's not reproduceable, so maybe its only the repetition causing this!
>
> This one is very serious and easy to reproduce with every printed seed:
>
> [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
> [junit] Testcase: testSmall(org.apache.lucene.util.TestOpenBitSet): Caused
> an ERROR
> [junit] -1
> [junit] java.lang.ArrayIndexOutOfBoundsException: -1
> [junit] at
> org.apache.lucene.util.OpenBitSet.prevSetBit(OpenBitSet.java:671)
> [junit] at
> org.apache.lucene.util.TestOpenBitSet.doPrevSetBit(TestOpenBitSet.java:53
> )
> [junit] at
> org.apache.lucene.util.TestOpenBitSet.doRandomSets(TestOpenBitSet.java:
> 148)
> [junit] at
> org.apache.lucene.util.TestOpenBitSet.testSmall(TestOpenBitSet.java:192)
> [junit] at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc
> eneTestCase.java:1272)
> [junit] at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc
> eneTestCase.java:1190)
> [junit]
> [junit]
> [junit] Testcase: testSmall(org.apache.lucene.util.TestOpenBitSet): Caused
> an ERROR
> [junit] (null)
> [junit] java.lang.ArrayIndexOutOfBoundsException
> [junit]
> [junit]
> [junit] Testcase: testSmall(org.apache.lucene.util.TestOpenBitSet): Caused
> an ERROR
> [junit] (null)
> [junit] java.lang.ArrayIndexOutOfBoundsException
> [junit]
> [junit]
>
> ... following lots of times the (null) AIOOBE message...
>
> [junit] NOTE: reproduce with: ant test -Dtestcase=TestOpenBitSet -
> Dtestmethod=testSmall -Dtests.seed=-
> 4526826707499307278:4139930264431857886
>
> Again with different seeds. But not all 100 repetitions fail, so the ones
> mentioned should fail, but reproduceible.
>
>
> The good news: PANGAEA index works fine, no readVInt hotspot problems
> with Java 6! Thanks Robert for fixing in 3.1, but after changes in MMap they
> could have reappeared.
>
> So this release candidate is in my opinion broken! -1 to release.
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
> > -----Original Message-----
> > From: Robert Muir [mailto:rcmuir@gmail.com]
> > Sent: Thursday, June 23, 2011 10:18 PM
> > To: dev@lucene.apache.org
> > Subject: [VOTE] release 3.3
> >
> > Artifacts here:
> >
> > http://s.apache.org/lusolr33rc0
> >
> > working release notes here:
> >
> > http://wiki.apache.org/lucene-java/ReleaseNote33
> > http://wiki.apache.org/solr/ReleaseNote33
> >
> > I ran the automated release test script in trunk/dev-
> > tools/scripts/smokeTestRelease.py, and ran 'ant test' at the top level
> > 50 times on windows.
> > Here is my +1
> >
> > ---------------------------------------------------------------------
> > 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
Re: [VOTE] release 3.3
Posted by Robert Muir <rc...@gmail.com>.
On Fri, Jun 24, 2011 at 10:43 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
>
> So this release candidate is in my opinion broken! -1 to release.
>
just to respond, thank you for running all these tests!!!! however,
The multilevelskiplist thing is a test bug, the tests do not all
guarantee to support iter > 1,
this is an unsupported option for developers to easily 'beast' tests
but its not required.
However, for this test I fixed this by resetting its static counter:
+ public void setUp() throws Exception {
+ super.setUp();
+ PayloadFilter.count = 0;
+ }
The openbitset thing, is a bug in java 5... and this is not supported.
So I strongly disagree that the release candidate is broken!
Seems like the only thing broken is java5!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] release 3.3
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
I run some smoke tests yesterday on the Lucene 2.9/3.0 release machine I used. The machine runs Java 1.5.0_22, Solaris x64, Opteron 16 cores. One of the tests was already fixed by Robert (I told him yesterday because it was always failing).
The others are maybe serious, maybe not:
[junit] Testsuite: org.apache.lucene.index.TestMultiLevelSkipList
[junit] Testcase: testSimpleSkip(org.apache.lucene.index.TestMultiLevelSkipList): FAILED
[junit] Wrong payload for the target 14: -106 expected:<14> but was:<-106>
[junit] junit.framework.AssertionFailedError: Wrong payload for the target 14: -106 expected:<14> but was:<-106>
[junit] at org.apache.lucene.index.TestMultiLevelSkipList.checkSkipTo(TestMultiLevelSkipList.java:87)
[junit] at org.apache.lucene.index.TestMultiLevelSkipList.testSimpleSkip(TestMultiLevelSkipList.java:66)
[junit] at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1272)
[junit] at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1190)
...( 100 repetitions of same stack trace) and then about 100 times with different seeds:
[junit] NOTE: reproduce with: ant test -Dtestcase=TestMultiLevelSkipList -Dtestmethod=testSimpleSkip -Dtests.seed=2861480580591035682:880958701285368932
But it's not reproduceable, so maybe its only the repetition causing this!
This one is very serious and easy to reproduce with every printed seed:
[junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
[junit] Testcase: testSmall(org.apache.lucene.util.TestOpenBitSet): Caused an ERROR
[junit] -1
[junit] java.lang.ArrayIndexOutOfBoundsException: -1
[junit] at org.apache.lucene.util.OpenBitSet.prevSetBit(OpenBitSet.java:671)
[junit] at org.apache.lucene.util.TestOpenBitSet.doPrevSetBit(TestOpenBitSet.java:53)
[junit] at org.apache.lucene.util.TestOpenBitSet.doRandomSets(TestOpenBitSet.java:148)
[junit] at org.apache.lucene.util.TestOpenBitSet.testSmall(TestOpenBitSet.java:192)
[junit] at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1272)
[junit] at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1190)
[junit]
[junit]
[junit] Testcase: testSmall(org.apache.lucene.util.TestOpenBitSet): Caused an ERROR
[junit] (null)
[junit] java.lang.ArrayIndexOutOfBoundsException
[junit]
[junit]
[junit] Testcase: testSmall(org.apache.lucene.util.TestOpenBitSet): Caused an ERROR
[junit] (null)
[junit] java.lang.ArrayIndexOutOfBoundsException
[junit]
[junit]
... following lots of times the (null) AIOOBE message...
[junit] NOTE: reproduce with: ant test -Dtestcase=TestOpenBitSet -Dtestmethod=testSmall -Dtests.seed=-4526826707499307278:4139930264431857886
Again with different seeds. But not all 100 repetitions fail, so the ones mentioned should fail, but reproduceible.
The good news: PANGAEA index works fine, no readVInt hotspot problems with Java 6! Thanks Robert for fixing in 3.1, but after changes in MMap they could have reappeared.
So this release candidate is in my opinion broken! -1 to release.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Robert Muir [mailto:rcmuir@gmail.com]
> Sent: Thursday, June 23, 2011 10:18 PM
> To: dev@lucene.apache.org
> Subject: [VOTE] release 3.3
>
> Artifacts here:
>
> http://s.apache.org/lusolr33rc0
>
> working release notes here:
>
> http://wiki.apache.org/lucene-java/ReleaseNote33
> http://wiki.apache.org/solr/ReleaseNote33
>
> I ran the automated release test script in trunk/dev-
> tools/scripts/smokeTestRelease.py, and ran 'ant test' at the top level 50
> times on windows.
> Here is my +1
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] release 3.3
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
On Fri, Jun 24, 2011 at 1:48 AM, Robert Muir <rc...@gmail.com> wrote:
> Artifacts here:
>
> http://s.apache.org/lusolr33rc0
>
> working release notes here:
>
> http://wiki.apache.org/lucene-java/ReleaseNote33
> http://wiki.apache.org/solr/ReleaseNote33
>
>
Thanks for leading this release Robert.
I compared SolrJ's pom.xml with past releases and I noticed that since
v3.1.0, SolrJ has a dependency on lucene-core. I'm not sure why SolrJ needs
that dependency. Also in v3.1, SolrJ had a test dependency on
solr-test-framework but it was removed in v3.2.
I have been missing from the action since Solr v1.4 so I'm not sure if those
changes were intentional or mistakes.
--
Regards,
Shalin Shekhar Mangar.
Re: [VOTE] release 3.3
Posted by Tommaso Teofili <to...@gmail.com>.
+1
Tommaso
2011/6/23 Robert Muir <rc...@gmail.com>
> Artifacts here:
>
> http://s.apache.org/lusolr33rc0
>
> working release notes here:
>
> http://wiki.apache.org/lucene-java/ReleaseNote33
> http://wiki.apache.org/solr/ReleaseNote33
>
> I ran the automated release test script in
> trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the
> top level 50 times on windows.
> Here is my +1
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: [VOTE] release 3.3
Posted by Chris Male <ge...@gmail.com>.
+1
Thanks for pulling the release together Robert.
On Fri, Jun 24, 2011 at 9:33 AM, Michael McCandless <
lucene@mikemccandless.com> wrote:
> +1
>
> Smoke testing passed for me, except for the Java 1.5 only hang in
> TestDoubleBarrelLRUCache (LUCENE-3235) but I don't think that should
> block the release.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Thu, Jun 23, 2011 at 4:18 PM, Robert Muir <rc...@gmail.com> wrote:
> > Artifacts here:
> >
> > http://s.apache.org/lusolr33rc0
> >
> > working release notes here:
> >
> > http://wiki.apache.org/lucene-java/ReleaseNote33
> > http://wiki.apache.org/solr/ReleaseNote33
> >
> > I ran the automated release test script in
> > trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the
> > top level 50 times on windows.
> > Here is my +1
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Chris Male | Software Developer | JTeam BV.| www.jteam.nl
Re: [VOTE] release 3.3
Posted by Michael McCandless <lu...@mikemccandless.com>.
+1
Smoke testing passed for me, except for the Java 1.5 only hang in
TestDoubleBarrelLRUCache (LUCENE-3235) but I don't think that should
block the release.
Mike McCandless
http://blog.mikemccandless.com
On Thu, Jun 23, 2011 at 4:18 PM, Robert Muir <rc...@gmail.com> wrote:
> Artifacts here:
>
> http://s.apache.org/lusolr33rc0
>
> working release notes here:
>
> http://wiki.apache.org/lucene-java/ReleaseNote33
> http://wiki.apache.org/solr/ReleaseNote33
>
> I ran the automated release test script in
> trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the
> top level 50 times on windows.
> Here is my +1
>
> ---------------------------------------------------------------------
> 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
Re: [VOTE] release 3.3
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
Ok, thanks Robert. This is a trivial correction. I didn't find log4j
refs. anywhere under contrib/clustering (just to make sure), so I
think it won't break anything.
Dawid
On Fri, Jun 24, 2011 at 9:03 AM, Robert Muir <rc...@gmail.com> wrote:
> there is no code freeze anywhere... in my opinion, if you find little
> things to fix, just commit!!! (and backport also to
> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_3/)
>
> I named the RC with the revision number, if we decide to go with it
> anyway, we just use that rev for svn tagging.
> But if lots of good things are found/fixed, then 'svn update' + 'ant
> prepare-release' + sftp to create a second release candidate is no big
> deal.
>
> On Fri, Jun 24, 2011 at 2:55 AM, Dawid Weiss
> <da...@cs.put.poznan.pl> wrote:
>> Is there a code freeze on 3x or can I apply SOLR-2620 to it?
>>
>> Dawid
>>
>> On Fri, Jun 24, 2011 at 8:51 AM, Dawid Weiss
>> <da...@cs.put.poznan.pl> wrote:
>>> I checked the clustering contrib, went through the Solr example (on
>>> ubuntu). One thing I noticed:
>>>
>>> - we have duplicated log4j*.jar in the distribution; the one in
>>> clustering contrib is not needed, in fact, because we use slf4j for
>>> logging anyway (and this one is picked from the war's WEB-INF/lib.
>>> I'll file an issue to remove it.
>>>
>>> Dawid
>>>
>>> On Fri, Jun 24, 2011 at 8:15 AM, Steven A Rowe <sa...@syr.edu> wrote:
>>>> +1
>>>>
>>>> I did the following:
>>>>
>>>> - compared the Solr & Lucene binary .zip and .tgz archives' contents for any differences (other than line endings)
>>>> - skimmed Changes.html for generation problems
>>>> - looked at random pages from each module's javadocs
>>>> - ran the Lucene demo, indexed and searched
>>>> - ran the Solr example server, indexed and searched
>>>> - eyeballed all modules' Maven artifacts & sanity checked their POMs
>>>> - ran all tests from the Solr & Lucene source tarballs, separately
>>>>
>>>> Two non-release-blocking nits:
>>>>
>>>> 1. In the Solr source tarball, solr/example/README.txt recommends using the command "./post.sh *.xml" from solr/example/exampledocs/, but post.sh does not have executable permissions. In the binary tarball, however, post.sh has executable permissions.
>>>>
>>>> 2. I checked the source for references to older versions, and I found the following; I think these just point to a missing item in the release todo (post-branching), and should not block the release:
>>>>
>>>> ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/fr/FrenchStemFilter.java: @Deprecated // TODO remove in 3.2 (this is present twice in this file)
>>>>
>>>> ./lucene/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java: /** @deprecated remove all this test mode code in lucene 3.2! */
>>>>
>>>> ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/br/BrazilianAnalyzer.java: // TODO make this private in 3.1 (this is present twice in this file)
>>>>
>>>> ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java:/** Index all text files under a directory. See http://lucene.apache.org/java/3_1/demo.html. */
>>>>
>>>> ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java: + "See http://lucene.apache.org/java/3_1/demo.html for details.";
>>>>
>>>> Steve
>>>>
>>>>> -----Original Message-----
>>>>> From: Robert Muir [mailto:rcmuir@gmail.com]
>>>>> Sent: Thursday, June 23, 2011 4:18 PM
>>>>> To: dev@lucene.apache.org
>>>>> Subject: [VOTE] release 3.3
>>>>>
>>>>> Artifacts here:
>>>>>
>>>>> http://s.apache.org/lusolr33rc0
>>>>>
>>>>> working release notes here:
>>>>>
>>>>> http://wiki.apache.org/lucene-java/ReleaseNote33
>>>>> http://wiki.apache.org/solr/ReleaseNote33
>>>>>
>>>>> I ran the automated release test script in
>>>>> trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the
>>>>> top level 50 times on windows.
>>>>> Here is my +1
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] release 3.3
Posted by Robert Muir <rc...@gmail.com>.
there is no code freeze anywhere... in my opinion, if you find little
things to fix, just commit!!! (and backport also to
http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_3/)
I named the RC with the revision number, if we decide to go with it
anyway, we just use that rev for svn tagging.
But if lots of good things are found/fixed, then 'svn update' + 'ant
prepare-release' + sftp to create a second release candidate is no big
deal.
On Fri, Jun 24, 2011 at 2:55 AM, Dawid Weiss
<da...@cs.put.poznan.pl> wrote:
> Is there a code freeze on 3x or can I apply SOLR-2620 to it?
>
> Dawid
>
> On Fri, Jun 24, 2011 at 8:51 AM, Dawid Weiss
> <da...@cs.put.poznan.pl> wrote:
>> I checked the clustering contrib, went through the Solr example (on
>> ubuntu). One thing I noticed:
>>
>> - we have duplicated log4j*.jar in the distribution; the one in
>> clustering contrib is not needed, in fact, because we use slf4j for
>> logging anyway (and this one is picked from the war's WEB-INF/lib.
>> I'll file an issue to remove it.
>>
>> Dawid
>>
>> On Fri, Jun 24, 2011 at 8:15 AM, Steven A Rowe <sa...@syr.edu> wrote:
>>> +1
>>>
>>> I did the following:
>>>
>>> - compared the Solr & Lucene binary .zip and .tgz archives' contents for any differences (other than line endings)
>>> - skimmed Changes.html for generation problems
>>> - looked at random pages from each module's javadocs
>>> - ran the Lucene demo, indexed and searched
>>> - ran the Solr example server, indexed and searched
>>> - eyeballed all modules' Maven artifacts & sanity checked their POMs
>>> - ran all tests from the Solr & Lucene source tarballs, separately
>>>
>>> Two non-release-blocking nits:
>>>
>>> 1. In the Solr source tarball, solr/example/README.txt recommends using the command "./post.sh *.xml" from solr/example/exampledocs/, but post.sh does not have executable permissions. In the binary tarball, however, post.sh has executable permissions.
>>>
>>> 2. I checked the source for references to older versions, and I found the following; I think these just point to a missing item in the release todo (post-branching), and should not block the release:
>>>
>>> ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/fr/FrenchStemFilter.java: @Deprecated // TODO remove in 3.2 (this is present twice in this file)
>>>
>>> ./lucene/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java: /** @deprecated remove all this test mode code in lucene 3.2! */
>>>
>>> ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/br/BrazilianAnalyzer.java: // TODO make this private in 3.1 (this is present twice in this file)
>>>
>>> ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java:/** Index all text files under a directory. See http://lucene.apache.org/java/3_1/demo.html. */
>>>
>>> ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java: + "See http://lucene.apache.org/java/3_1/demo.html for details.";
>>>
>>> Steve
>>>
>>>> -----Original Message-----
>>>> From: Robert Muir [mailto:rcmuir@gmail.com]
>>>> Sent: Thursday, June 23, 2011 4:18 PM
>>>> To: dev@lucene.apache.org
>>>> Subject: [VOTE] release 3.3
>>>>
>>>> Artifacts here:
>>>>
>>>> http://s.apache.org/lusolr33rc0
>>>>
>>>> working release notes here:
>>>>
>>>> http://wiki.apache.org/lucene-java/ReleaseNote33
>>>> http://wiki.apache.org/solr/ReleaseNote33
>>>>
>>>> I ran the automated release test script in
>>>> trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the
>>>> top level 50 times on windows.
>>>> Here is my +1
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: [VOTE] release 3.3
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
Is there a code freeze on 3x or can I apply SOLR-2620 to it?
Dawid
On Fri, Jun 24, 2011 at 8:51 AM, Dawid Weiss
<da...@cs.put.poznan.pl> wrote:
> I checked the clustering contrib, went through the Solr example (on
> ubuntu). One thing I noticed:
>
> - we have duplicated log4j*.jar in the distribution; the one in
> clustering contrib is not needed, in fact, because we use slf4j for
> logging anyway (and this one is picked from the war's WEB-INF/lib.
> I'll file an issue to remove it.
>
> Dawid
>
> On Fri, Jun 24, 2011 at 8:15 AM, Steven A Rowe <sa...@syr.edu> wrote:
>> +1
>>
>> I did the following:
>>
>> - compared the Solr & Lucene binary .zip and .tgz archives' contents for any differences (other than line endings)
>> - skimmed Changes.html for generation problems
>> - looked at random pages from each module's javadocs
>> - ran the Lucene demo, indexed and searched
>> - ran the Solr example server, indexed and searched
>> - eyeballed all modules' Maven artifacts & sanity checked their POMs
>> - ran all tests from the Solr & Lucene source tarballs, separately
>>
>> Two non-release-blocking nits:
>>
>> 1. In the Solr source tarball, solr/example/README.txt recommends using the command "./post.sh *.xml" from solr/example/exampledocs/, but post.sh does not have executable permissions. In the binary tarball, however, post.sh has executable permissions.
>>
>> 2. I checked the source for references to older versions, and I found the following; I think these just point to a missing item in the release todo (post-branching), and should not block the release:
>>
>> ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/fr/FrenchStemFilter.java: @Deprecated // TODO remove in 3.2 (this is present twice in this file)
>>
>> ./lucene/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java: /** @deprecated remove all this test mode code in lucene 3.2! */
>>
>> ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/br/BrazilianAnalyzer.java: // TODO make this private in 3.1 (this is present twice in this file)
>>
>> ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java:/** Index all text files under a directory. See http://lucene.apache.org/java/3_1/demo.html. */
>>
>> ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java: + "See http://lucene.apache.org/java/3_1/demo.html for details.";
>>
>> Steve
>>
>>> -----Original Message-----
>>> From: Robert Muir [mailto:rcmuir@gmail.com]
>>> Sent: Thursday, June 23, 2011 4:18 PM
>>> To: dev@lucene.apache.org
>>> Subject: [VOTE] release 3.3
>>>
>>> Artifacts here:
>>>
>>> http://s.apache.org/lusolr33rc0
>>>
>>> working release notes here:
>>>
>>> http://wiki.apache.org/lucene-java/ReleaseNote33
>>> http://wiki.apache.org/solr/ReleaseNote33
>>>
>>> I ran the automated release test script in
>>> trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the
>>> top level 50 times on windows.
>>> Here is my +1
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] release 3.3
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
I checked the clustering contrib, went through the Solr example (on
ubuntu). One thing I noticed:
- we have duplicated log4j*.jar in the distribution; the one in
clustering contrib is not needed, in fact, because we use slf4j for
logging anyway (and this one is picked from the war's WEB-INF/lib.
I'll file an issue to remove it.
Dawid
On Fri, Jun 24, 2011 at 8:15 AM, Steven A Rowe <sa...@syr.edu> wrote:
> +1
>
> I did the following:
>
> - compared the Solr & Lucene binary .zip and .tgz archives' contents for any differences (other than line endings)
> - skimmed Changes.html for generation problems
> - looked at random pages from each module's javadocs
> - ran the Lucene demo, indexed and searched
> - ran the Solr example server, indexed and searched
> - eyeballed all modules' Maven artifacts & sanity checked their POMs
> - ran all tests from the Solr & Lucene source tarballs, separately
>
> Two non-release-blocking nits:
>
> 1. In the Solr source tarball, solr/example/README.txt recommends using the command "./post.sh *.xml" from solr/example/exampledocs/, but post.sh does not have executable permissions. In the binary tarball, however, post.sh has executable permissions.
>
> 2. I checked the source for references to older versions, and I found the following; I think these just point to a missing item in the release todo (post-branching), and should not block the release:
>
> ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/fr/FrenchStemFilter.java: @Deprecated // TODO remove in 3.2 (this is present twice in this file)
>
> ./lucene/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java: /** @deprecated remove all this test mode code in lucene 3.2! */
>
> ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/br/BrazilianAnalyzer.java: // TODO make this private in 3.1 (this is present twice in this file)
>
> ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java:/** Index all text files under a directory. See http://lucene.apache.org/java/3_1/demo.html. */
>
> ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java: + "See http://lucene.apache.org/java/3_1/demo.html for details.";
>
> Steve
>
>> -----Original Message-----
>> From: Robert Muir [mailto:rcmuir@gmail.com]
>> Sent: Thursday, June 23, 2011 4:18 PM
>> To: dev@lucene.apache.org
>> Subject: [VOTE] release 3.3
>>
>> Artifacts here:
>>
>> http://s.apache.org/lusolr33rc0
>>
>> working release notes here:
>>
>> http://wiki.apache.org/lucene-java/ReleaseNote33
>> http://wiki.apache.org/solr/ReleaseNote33
>>
>> I ran the automated release test script in
>> trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the
>> top level 50 times on windows.
>> Here is my +1
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] release 3.3
Posted by Robert Muir <rc...@gmail.com>.
On Fri, Jun 24, 2011 at 2:15 AM, Steven A Rowe <sa...@syr.edu> wrote:
> +1
>
> I did the following:
>
> - compared the Solr & Lucene binary .zip and .tgz archives' contents for any differences (other than line endings)
> - skimmed Changes.html for generation problems
> - looked at random pages from each module's javadocs
> - ran the Lucene demo, indexed and searched
> - ran the Solr example server, indexed and searched
> - eyeballed all modules' Maven artifacts & sanity checked their POMs
> - ran all tests from the Solr & Lucene source tarballs, separately
>
Thanks Steven, these look like good checks, and I think as much as
possible it would be great if we can add any of these to the
'smokeTestRelease.py' script in dev-tools/scripts (e.g. startup solr,
index the example docs and do a search).
I could also imagine sometime soon we might even want to have this
release-tester testing nightly builds or something, so we catch
problems continuously.
> Two non-release-blocking nits:
>
> 1. In the Solr source tarball, solr/example/README.txt recommends using the command "./post.sh *.xml" from solr/example/exampledocs/, but post.sh does not have executable permissions. In the binary tarball, however, post.sh has executable permissions.
>
> 2. I checked the source for references to older versions, and I found the following; I think these just point to a missing item in the release todo (post-branching), and should not block the release:
>
I took care of these: the deprecations are already nuked in trunk, and
I don't think we achieve a ton by nuking them in a 3.x minor release.
As far as the demo links, these were totally broken links, so i
replaced them with a description of what the thing is doing (seems
more useful)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] release 3.3
Posted by Steven A Rowe <sa...@syr.edu>.
+1
I did the following:
- compared the Solr & Lucene binary .zip and .tgz archives' contents for any differences (other than line endings)
- skimmed Changes.html for generation problems
- looked at random pages from each module's javadocs
- ran the Lucene demo, indexed and searched
- ran the Solr example server, indexed and searched
- eyeballed all modules' Maven artifacts & sanity checked their POMs
- ran all tests from the Solr & Lucene source tarballs, separately
Two non-release-blocking nits:
1. In the Solr source tarball, solr/example/README.txt recommends using the command "./post.sh *.xml" from solr/example/exampledocs/, but post.sh does not have executable permissions. In the binary tarball, however, post.sh has executable permissions.
2. I checked the source for references to older versions, and I found the following; I think these just point to a missing item in the release todo (post-branching), and should not block the release:
./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/fr/FrenchStemFilter.java: @Deprecated // TODO remove in 3.2 (this is present twice in this file)
./lucene/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java: /** @deprecated remove all this test mode code in lucene 3.2! */
./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/br/BrazilianAnalyzer.java: // TODO make this private in 3.1 (this is present twice in this file)
./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java:/** Index all text files under a directory. See http://lucene.apache.org/java/3_1/demo.html. */
./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java: + "See http://lucene.apache.org/java/3_1/demo.html for details.";
Steve
> -----Original Message-----
> From: Robert Muir [mailto:rcmuir@gmail.com]
> Sent: Thursday, June 23, 2011 4:18 PM
> To: dev@lucene.apache.org
> Subject: [VOTE] release 3.3
>
> Artifacts here:
>
> http://s.apache.org/lusolr33rc0
>
> working release notes here:
>
> http://wiki.apache.org/lucene-java/ReleaseNote33
> http://wiki.apache.org/solr/ReleaseNote33
>
> I ran the automated release test script in
> trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the
> top level 50 times on windows.
> Here is my +1