Hi Myrna,
Some comments inline...
On 9/30/11 11:57 AM, Myrna van Lunteren wrote:
On Fri, Sep 30, 2011 at 10:21 AM, Mike Matrigali
<[email protected]> wrote:
Rick Hillegas wrote:
On 9/29/11 6:22 PM, Myrna van Lunteren wrote:
Dear all,
I'm now officially cancelling the vote for 10.8.2.1 as a release
candidate.
The reasons are the issues which I updated to blocker:
DERBY-5430
DERBY-5422
Hi Myrna,
I believe these are both consequences of increasing the concurrency of
identity columns, that is, fallout from DERBY-4437. I am looking at
DERBY-5430 now. I intend to look at DERBY-5422 now that you have
demonstrated that it is not fixed by the patch for DERBY-5423.
I don't think I will be able to wrap up both bugs next week since I will
be busy at Java One. Here are some options to consider:
1) Back out the port of DERBY-4437 to 10.8 and continue debugging the
issues on the trunk. I am not confident that this will fix DERBY-5422. I
think that bug is triggered by the use of identity columns in NsTest and the
bug appears because identities now use the same preallocation logic as
sequences. It is likely that the bug is also triggered by the use of
sequences, and without more investigation I can't say whether the bug is
even new to 10.8.2.
Given the number of issues that have surfaced in this testing round related
to backport of identity enhancement I would lean toward backing out the
backport of 4437, cut a new release candidate and verify that nstest no
longer sees new issues. I believe even without 4437 the proposed release
would be a marked improvement for apache 10.8 users.
Concurrently work on the issues in trunk. And we can cut another 10.8
bug fix release down the line when we have had time to fix the issues and
run some long term stress testing to verify the identity behavior which will
affect many existing users.
From my reading of the code I agree with rick that the remaining issues are
not specific to identity and also affect sequences. So likely we
will want to backport fixes made to 10.8 for sequences. It may be
interesting to either add sequences to nstest or fork a copy that
substitutes them to verify that the issue is not particular to identity.
It would be also valuable if we could produce some tests that reproduce
the issues much more reliably than nstest.
2) Hope that someone else can pick up DERBY-5422 while I look at
DERBY-5430.
3) Wait a couple weeks for the next RC to give me time to fix both of
these bugs.
Thanks,
-Rick
Thanks for your input Rick, Mike.
I think Rick has come a long way in fixing a number of issues
resulting from DERBY-4377. And it appears to me that backing out
DERBY-4377 is also a considerable effort at this time? (I assume this
means we then need to back out also DERBY-5408, doc issue DERBY-5307
(do we loose the need for derby.language.preallocator property if we
back this out?), DERBY-5423? How about DERBY-4565?).
I think we would need to back out the following commits:
DERBY-4437 1141645: This is the master commit which ported most of the
10.9 changes to 10.8
DERBY-4437 1142052: This commit ported an upgrade test from 10.9 to
10.8. The test verifies the new identity behavior.
DERBY-5307 1141651: This commit ported documentation of the
derby.language.sequence.preallocator property from 10.9 docs to 10.8
docs. Note that the property still has meaning for sequences although
the property would be less capable after backing out 1141645.
DERBY-5408 1170178: This commit ported the localization fixes for the
2200H message from 10.9 to the 10.8 branch.
DERBY-5426 1174297: This commit ported some SequenceUpdater changes from
10.9 to the 10.8 branch. The changes improved the error reporting when
there was too much contention on an identity column.
I don't think that we need to back out the following work:
DERBY-5423: Nothing to do here. This issue was resolved because of the
work on DERBY-5426.
DERBY-4565: Nothing to do here. All of this work made it into 10.6.1.0.
Rick, do you think you could have a handle on DERBY-5430 say - within
a week? How much time/effort would backing out DERBY-4377 take?
I've made good progress today but I can't promise that I'll understand
the problem by the end of next week. Next week I will be busy at Java
One. I think it's likely I will understand what's broken by the end of
the following week.
If all goes well, it would take a day to back out DERBY-4437. If all
doesn't go well, it could take longer.
I don't think I will have time to adequately test an RC which is
produced during the week of Java One.
Thanks,
-Rick
I'm not happy to spin a release with only nstest to detect DERBY-5422.
Would a week more time give someone the opportunity to analyze the
problem and come up with a repro? Is there anyone interested/willing
to attempt a repro for either of these two issues?
Myrna
