You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Myrna van Lunteren <m....@gmail.com> on 2011/10/11 02:05:30 UTC
[VOTE] 10.8.2.2 release
I have prepared the next candidate for the 10.8.2.2 bug fix release.
It is now ready for testing.
The candidate lives at:
http://people.apache.org/~myrnavl/derby-10.8.2.2-RC3/
Please vote on whether to accept it as a Derby release.
The polls close at 12:00 pm (noon) San Francisco time on Monday,
October 24, 2011.
Please refer to the 10.8.2 wiki page to find information and log your
testing results:
http://wiki.apache.org/db-derby/DerbyTenEightTwoRelease.
Regards,
Myrna
Re: [VOTE] 10.8.2.2 release
Posted by Mamta Satoor <ms...@gmail.com>.
Hi Myrna,
Sorry for cluttering the voting thread with the details of the test
results. I have updated the RC3 wiki page with the information.
thanks,
Mamta
On Tue, Oct 11, 2011 at 3:30 PM, Myrna van Lunteren
<m....@gmail.com> wrote:
> On Tue, Oct 11, 2011 at 3:07 PM, Mamta Satoor <ms...@gmail.com> wrote:
>> I ran stress test for sequence generator and identity generator
>> (org.apache.derbyTesting.perf.clients.Runner. Added by DERBY-4565 and
>> DERBY-5445) to see how they will run with Rick's changes backed out
>> from 10.8 release. I ran both the tests multiple times and didn't run
>> into any lock time outs or sequence contention problems with either
>> one of them. The tests took an average of about 1mint49sec-2mins to
>> finish.
>>
>> I ran those tests on trunk again to compare the results with 10.8
>> release candidate runs. The sequence generation test on trunk on
>> multiple runs did not come across any errors. The identity column test
>> did run into lock timeouts and
>> it took more than double the time(compared to 10.8 release candidate) to finish.
>>
>> Mamta
>>
>>
> Thanks for running these experiments Mamta!
>
> Could you please copy this info onto the wiki page under 'other
> testing', for RC3?
>
> Myrna
>
Re: [VOTE] 10.8.2.2 release
Posted by Myrna van Lunteren <m....@gmail.com>.
On Tue, Oct 11, 2011 at 3:07 PM, Mamta Satoor <ms...@gmail.com> wrote:
> I ran stress test for sequence generator and identity generator
> (org.apache.derbyTesting.perf.clients.Runner. Added by DERBY-4565 and
> DERBY-5445) to see how they will run with Rick's changes backed out
> from 10.8 release. I ran both the tests multiple times and didn't run
> into any lock time outs or sequence contention problems with either
> one of them. The tests took an average of about 1mint49sec-2mins to
> finish.
>
> I ran those tests on trunk again to compare the results with 10.8
> release candidate runs. The sequence generation test on trunk on
> multiple runs did not come across any errors. The identity column test
> did run into lock timeouts and
> it took more than double the time(compared to 10.8 release candidate) to finish.
>
> Mamta
>
>
Thanks for running these experiments Mamta!
Could you please copy this info onto the wiki page under 'other
testing', for RC3?
Myrna
Re: [VOTE] 10.8.2.2 release
Posted by Mamta Satoor <ms...@gmail.com>.
I ran stress test for sequence generator and identity generator
(org.apache.derbyTesting.perf.clients.Runner. Added by DERBY-4565 and
DERBY-5445) to see how they will run with Rick's changes backed out
from 10.8 release. I ran both the tests multiple times and didn't run
into any lock time outs or sequence contention problems with either
one of them. The tests took an average of about 1mint49sec-2mins to
finish.
I ran those tests on trunk again to compare the results with 10.8
release candidate runs. The sequence generation test on trunk on
multiple runs did not come across any errors. The identity column test
did run into lock timeouts and
it took more than double the time(compared to 10.8 release candidate) to finish.
Mamta
On Tue, Oct 11, 2011 at 11:07 AM, Mamta Satoor <ms...@gmail.com> wrote:
> Hi Myrna,
>
> Thanks for spinning another release candidate. I downloaded the
> release and was able to do some very basic testing and it looked good.
> I will do more testing and report how that goes.
>
> thanks,
> Mamta
>
> On Tue, Oct 11, 2011 at 11:07 AM, Kim Haase <ca...@oracle.com> wrote:
>> I've checked over the documentation in the db-derby-10.8.2.2-bin.zip bundle
>> and confirmed that it's correct and up to date for this release. So from a
>> documentation perspective,
>>
>> +1
>>
>> Thanks for all your work, Myrna!
>>
>> Kim
>>
>> On 10/10/11 08:05 PM, Myrna van Lunteren wrote:
>>>
>>> I have prepared the next candidate for the 10.8.2.2 bug fix release.
>>> It is now ready for testing.
>>>
>>> The candidate lives at:
>>> http://people.apache.org/~myrnavl/derby-10.8.2.2-RC3/
>>>
>>> Please vote on whether to accept it as a Derby release.
>>>
>>> The polls close at 12:00 pm (noon) San Francisco time on Monday,
>>> October 24, 2011.
>>>
>>> Please refer to the 10.8.2 wiki page to find information and log your
>>> testing results:
>>> http://wiki.apache.org/db-derby/DerbyTenEightTwoRelease.
>>>
>>> Regards,
>>> Myrna
>>>
>>
>
Re: [VOTE] 10.8.2.2 release
Posted by Mamta Satoor <ms...@gmail.com>.
Hi Myrna,
Thanks for spinning another release candidate. I downloaded the
release and was able to do some very basic testing and it looked good.
I will do more testing and report how that goes.
thanks,
Mamta
On Tue, Oct 11, 2011 at 11:07 AM, Kim Haase <ca...@oracle.com> wrote:
> I've checked over the documentation in the db-derby-10.8.2.2-bin.zip bundle
> and confirmed that it's correct and up to date for this release. So from a
> documentation perspective,
>
> +1
>
> Thanks for all your work, Myrna!
>
> Kim
>
> On 10/10/11 08:05 PM, Myrna van Lunteren wrote:
>>
>> I have prepared the next candidate for the 10.8.2.2 bug fix release.
>> It is now ready for testing.
>>
>> The candidate lives at:
>> http://people.apache.org/~myrnavl/derby-10.8.2.2-RC3/
>>
>> Please vote on whether to accept it as a Derby release.
>>
>> The polls close at 12:00 pm (noon) San Francisco time on Monday,
>> October 24, 2011.
>>
>> Please refer to the 10.8.2 wiki page to find information and log your
>> testing results:
>> http://wiki.apache.org/db-derby/DerbyTenEightTwoRelease.
>>
>> Regards,
>> Myrna
>>
>
Re: [VOTE] 10.8.2.2 release
Posted by Kim Haase <ca...@oracle.com>.
I've checked over the documentation in the db-derby-10.8.2.2-bin.zip
bundle and confirmed that it's correct and up to date for this release.
So from a documentation perspective,
+1
Thanks for all your work, Myrna!
Kim
On 10/10/11 08:05 PM, Myrna van Lunteren wrote:
> I have prepared the next candidate for the 10.8.2.2 bug fix release.
> It is now ready for testing.
>
> The candidate lives at:
> http://people.apache.org/~myrnavl/derby-10.8.2.2-RC3/
>
> Please vote on whether to accept it as a Derby release.
>
> The polls close at 12:00 pm (noon) San Francisco time on Monday,
> October 24, 2011.
>
> Please refer to the 10.8.2 wiki page to find information and log your
> testing results:
> http://wiki.apache.org/db-derby/DerbyTenEightTwoRelease.
>
> Regards,
> Myrna
>
Re: [VOTE] 10.8.2.2 release
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Myrna van Lunteren <m....@gmail.com> writes:
> I have prepared the next candidate for the 10.8.2.2 bug fix release.
> It is now ready for testing.
>
> The candidate lives at:
> http://people.apache.org/~myrnavl/derby-10.8.2.2-RC3/
>
> Please vote on whether to accept it as a Derby release.
+1
--
Knut Anders
Re: [VOTE] 10.8.2.2 release
Posted by Kristian Waagan <kr...@oracle.com>.
On 11.10.11 02:05, Myrna van Lunteren wrote:
> I have prepared the next candidate for the 10.8.2.2 bug fix release.
> It is now ready for testing.
>
> The candidate lives at:
> http://people.apache.org/~myrnavl/derby-10.8.2.2-RC3/
>
> Please vote on whether to accept it as a Derby release.
+1
--
Kristian
>
> The polls close at 12:00 pm (noon) San Francisco time on Monday,
> October 24, 2011.
>
> Please refer to the 10.8.2 wiki page to find information and log your
> testing results:
> http://wiki.apache.org/db-derby/DerbyTenEightTwoRelease.
>
> Regards,
> Myrna
Re: [VOTE] 10.8.2.2 release
Posted by Tiago Espinha <ti...@espinhas.net>.
I got a chance to test this on Ubuntu x86 and got a clean run of suites.All.
+1 from me
Tiago
On Thu, Oct 20, 2011 at 9:21 PM, Kathey Marsden <kmarsdenderby@sbcglobal.net
> wrote:
> On 10/10/2011 5:05 PM, Myrna van Lunteren wrote:
>
>> I have prepared the next candidate for the 10.8.2.2 bug fix release.
>> It is now ready for testing.
>>
>> The candidate lives at:
>> http://people.apache.org/~**myrnavl/derby-10.8.2.2-RC3/<http://people.apache.org/~myrnavl/derby-10.8.2.2-RC3/>
>>
>> On RC2, I ran regression tests on z/OS IBM 1.6 and IBM 1.6 64 bit, did
> some ad hoc testing on IPv6 and some mixed client/server version testing.
> On RC3 I ran IBM 1.7 with z/OS. I see no show stopper issues with RC3 and
> think this is a very solid release. Thank you to all that contributed and
> Myrna for managing the release.
>
> +1
>
>
>
>
> +1
>
>
>
>
Re: [VOTE] 10.8.2.2 release
Posted by Kathey Marsden <km...@sbcglobal.net>.
On 10/10/2011 5:05 PM, Myrna van Lunteren wrote:
> I have prepared the next candidate for the 10.8.2.2 bug fix release.
> It is now ready for testing.
>
> The candidate lives at:
> http://people.apache.org/~myrnavl/derby-10.8.2.2-RC3/
>
On RC2, I ran regression tests on z/OS IBM 1.6 and IBM 1.6 64 bit, did
some ad hoc testing on IPv6 and some mixed client/server version
testing. On RC3 I ran IBM 1.7 with z/OS. I see no show stopper issues
with RC3 and think this is a very solid release. Thank you to all that
contributed and Myrna for managing the release.
+1
+1
Re: [VOTE] 10.8.2.2 release
Posted by Bryan Pendleton <bp...@gmail.com>.
> Please vote on whether to accept it as a Derby release.
+1
bryan
Re: [VOTE] 10.8.2.2 release
Posted by Mamta Satoor <ms...@gmail.com>.
+1. Yes, definitely more stable than the previous one. Thanks, Myrna.
On Thu, Oct 20, 2011 at 9:55 AM, Lily Wei <li...@gmail.com> wrote:
> +1 Really great work!
>
> Thanks,
> Lily
>
> On Oct 20, 2011, at 9:13 AM, Mike Matrigali <mi...@sbcglobal.net> wrote:
>
>> Myrna van Lunteren wrote:
>>> I have prepared the next candidate for the 10.8.2.2 bug fix release.
>>> It is now ready for testing.
>>> The candidate lives at:
>>> http://people.apache.org/~myrnavl/derby-10.8.2.2-RC3/
>>> Please vote on whether to accept it as a Derby release.
>>> The polls close at 12:00 pm (noon) San Francisco time on Monday,
>>> October 24, 2011.
>>> Please refer to the 10.8.2 wiki page to find information and log your
>>> testing results:
>>> http://wiki.apache.org/db-derby/DerbyTenEightTwoRelease.
>>> Regards,
>>> Myrna
>> Thanks for the work myrna. 10.8.2.2 looks to me like good improvement over the existing release, I think we should release it.
>>
>> +1
>
Re: [VOTE] 10.8.2.2 release
Posted by Lily Wei <li...@gmail.com>.
+1 Really great work!
Thanks,
Lily
On Oct 20, 2011, at 9:13 AM, Mike Matrigali <mi...@sbcglobal.net> wrote:
> Myrna van Lunteren wrote:
>> I have prepared the next candidate for the 10.8.2.2 bug fix release.
>> It is now ready for testing.
>> The candidate lives at:
>> http://people.apache.org/~myrnavl/derby-10.8.2.2-RC3/
>> Please vote on whether to accept it as a Derby release.
>> The polls close at 12:00 pm (noon) San Francisco time on Monday,
>> October 24, 2011.
>> Please refer to the 10.8.2 wiki page to find information and log your
>> testing results:
>> http://wiki.apache.org/db-derby/DerbyTenEightTwoRelease.
>> Regards,
>> Myrna
> Thanks for the work myrna. 10.8.2.2 looks to me like good improvement over the existing release, I think we should release it.
>
> +1
Re: [VOTE] 10.8.2.2 release
Posted by Myrna van Lunteren <m....@gmail.com>.
On Fri, Oct 21, 2011 at 12:41 PM, Mike Matrigali
<mi...@sbcglobal.net> wrote:
> Rick Hillegas wrote:
>>
>> -0
>>
>> I am tempted to vote -1 based on DERBY-5430. The 10.8.2 release candidates
>> produce a deadlock in NsTest. That deadlock was not seen in 10.8.1 or
>> earlier releases.
>
> If we had a reproducible case for DERBY-5430 I would agree, then we could at
> the very worst case binary search for the change in 10.8 that
> caused the issue. I've tried this but failed and see very inconsistent
> results using nstest. On exactly same codeline/machine/environment it
> will pop after 1 hour and then not after days. I have also reviewed all
> the changes in 10.8 since the previous release and can not come up with
> anything that looks likely to cause this kind of problem.
>>
>> However, I do not have any confidence in NsTest as a release barrier. This
>> test suffers from a number of defects which severely cripple its usefulness:
>>
>> 1) No-one seems to understand this test.
>>
>> 2) The test is not being run in its preferred configuration. The "Ns" in
>> NsTest means "Network Server" I think, but as far as I can see the test is
>> only being run embedded.
>
> I was around when this test was being developed. Originally I believe we
> were looking for a network specific test to add to embedded stress tests we
> had. But when we looked at what resulted there was nothing
> network specific about it, and in fact was found to be more stressful
> run in embedded mode. I agree if we had the resources we should run it
> in both modes (and maybe even alter its various parameters to change
> what it stresses). For instance I think it currently also only runs
> on encryped databases and thus does not stress other more "normal" paths.
>>
>> 3) The test produces reams of errors. I don't think we know how to strain
>> signal out of this noise. The sheer volume of errors suggests that the test
>> is badly written and that it does not model a sensible workload.
>
> I go back and forth on this. As a developer I believe if I wrote this
> test I would not have it act this way. But one original objective of the
> stress test was to stress unexpected paths not being tested by others.
>>
>> 4) The person who runs this test (Myrna) has lost confidence in its
>> ability to disclose regressions, as evidenced by the downgrading of the
>> urgency of DERBY-5430.
>>
>> I do not think that we should use NsTest as a release barrier again until
>> we address its defects.
>
> I think release managers should look at the result of this test and make
> their own determination. If many ASSERTS or other system errors (like
> DERBY-5422) or server crashes start coming from this test then it is giving
> good feedback. We would not have seen DERBY-5423 without this test, and I
> believe that would have been a severe problem for existing
> user applications.
>
> So I agree that nstest failing should not necessarily mean a release should
> be blocked. Unfortuntately it results need to be interpreted and
> a decision made by the community/release manager on if it should be block or
> not. It has shown up real bugs in the past that all other
> tests have missed so don't want to throw it out. It is to bad that it's
> signal to noise ratio is so large.
>>
>> Thanks,
>> -Rick
>>
>>
>>
>
>
I'm voting +1 to release 10.8.2.2.
I confirm that I did see the deadlock of DERBY-5430 with 10.8.2.2 - so
even after Rick's backing out the fix for DERBY-4377. I thought Rick
had also seen this in a build off the branch after the backing out?
Perhaps I misread the comments in DERBY-5430.
I decided to lower the priority of DERBY-5430 for 2 reasons:
- nstest is not a very consistent test for finding this issue.
I can only state that I've *not* seen DERBY-5430 in release cycles
before 10.8.2.2. (at least not 10.8.2.1 nor 10.7.1.1), which doesn't
mean it didn't exist.
(As an aside, note that I also did not see DERBY-5454 again with
10.8.2.2 (deadlock on select max) which I had expected to see...)
- a number of people have looked through all the changes and stated
none of them appear obvious for causing this issue.
After finishing up the release work, I will take some time to go on a
binary search and see if I can find if there was a check-in which
caused nstest with embedded to see this (/see this more easily,
assuming it existed before.) But this will be a very slow process,
might be a month or more.
Re nstest with Embedded vs. Network Server - for the past 4 releases
or so I've run nstest both ways - the embedded configuration on
windows and the network server configuration on a linux machine. I've
consistently logged the results on the platform testing page. The
Network Server test didn't show deadlocks, which is clearly stated in
DERBY-5430.
Myrna
Re: [VOTE] 10.8.2.2 release
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Rick Hillegas wrote:
> -0
>
> I am tempted to vote -1 based on DERBY-5430. The 10.8.2 release
> candidates produce a deadlock in NsTest. That deadlock was not seen in
> 10.8.1 or earlier releases.
If we had a reproducible case for DERBY-5430 I would agree, then we
could at the very worst case binary search for the change in 10.8 that
caused the issue. I've tried this but failed and see very inconsistent
results using nstest. On exactly same codeline/machine/environment it
will pop after 1 hour and then not after days. I have also reviewed all
the changes in 10.8 since the previous release and can not come up with
anything that looks likely to cause this kind of problem.
>
> However, I do not have any confidence in NsTest as a release barrier.
> This test suffers from a number of defects which severely cripple its
> usefulness:
>
> 1) No-one seems to understand this test.
>
> 2) The test is not being run in its preferred configuration. The "Ns" in
> NsTest means "Network Server" I think, but as far as I can see the test
> is only being run embedded.
I was around when this test was being developed. Originally I believe
we were looking for a network specific test to add to embedded stress
tests we had. But when we looked at what resulted there was nothing
network specific about it, and in fact was found to be more stressful
run in embedded mode. I agree if we had the resources we should run it
in both modes (and maybe even alter its various parameters to change
what it stresses). For instance I think it currently also only runs
on encryped databases and thus does not stress other more "normal" paths.
>
> 3) The test produces reams of errors. I don't think we know how to
> strain signal out of this noise. The sheer volume of errors suggests
> that the test is badly written and that it does not model a sensible
> workload.
I go back and forth on this. As a developer I believe if I wrote this
test I would not have it act this way. But one original objective of
the stress test was to stress unexpected paths not being tested by others.
>
> 4) The person who runs this test (Myrna) has lost confidence in its
> ability to disclose regressions, as evidenced by the downgrading of the
> urgency of DERBY-5430.
>
> I do not think that we should use NsTest as a release barrier again
> until we address its defects.
I think release managers should look at the result of this test and make
their own determination. If many ASSERTS or other system errors (like
DERBY-5422) or server crashes start coming from this test then it is
giving good feedback. We would not have seen DERBY-5423 without this
test, and I believe that would have been a severe problem for existing
user applications.
So I agree that nstest failing should not necessarily mean a release
should be blocked. Unfortuntately it results need to be interpreted and
a decision made by the community/release manager on if it should be
block or not. It has shown up real bugs in the past that all other
tests have missed so don't want to throw it out. It is to bad that it's
signal to noise ratio is so large.
>
> Thanks,
> -Rick
>
>
>
Re: [VOTE] 10.8.2.2 release
Posted by Rick Hillegas <ri...@oracle.com>.
-0
I am tempted to vote -1 based on DERBY-5430. The 10.8.2 release
candidates produce a deadlock in NsTest. That deadlock was not seen in
10.8.1 or earlier releases.
However, I do not have any confidence in NsTest as a release barrier.
This test suffers from a number of defects which severely cripple its
usefulness:
1) No-one seems to understand this test.
2) The test is not being run in its preferred configuration. The "Ns" in
NsTest means "Network Server" I think, but as far as I can see the test
is only being run embedded.
3) The test produces reams of errors. I don't think we know how to
strain signal out of this noise. The sheer volume of errors suggests
that the test is badly written and that it does not model a sensible
workload.
4) The person who runs this test (Myrna) has lost confidence in its
ability to disclose regressions, as evidenced by the downgrading of the
urgency of DERBY-5430.
I do not think that we should use NsTest as a release barrier again
until we address its defects.
Thanks,
-Rick
Re: [VOTE] 10.8.2.2 release
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Myrna van Lunteren wrote:
> I have prepared the next candidate for the 10.8.2.2 bug fix release.
> It is now ready for testing.
>
> The candidate lives at:
> http://people.apache.org/~myrnavl/derby-10.8.2.2-RC3/
>
> Please vote on whether to accept it as a Derby release.
>
> The polls close at 12:00 pm (noon) San Francisco time on Monday,
> October 24, 2011.
>
> Please refer to the 10.8.2 wiki page to find information and log your
> testing results:
> http://wiki.apache.org/db-derby/DerbyTenEightTwoRelease.
>
> Regards,
> Myrna
>
Thanks for the work myrna. 10.8.2.2 looks to me like good improvement
over the existing release, I think we should release it.
+1