On 10/3/11 1:58 PM, Myrna van Lunteren wrote:
On Mon, Oct 3, 2011 at 10:24 AM, Myrna van Lunteren
<[email protected]>  wrote:
On Fri, Sep 30, 2011 at 1:10 PM, Rick Hillegas<[email protected]>  wrote:
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


Thank you for the information Rick,

I think at this time I'd like for DERBY-4377 to be backed out.
Do you have time to tackle this task now?
Hi Myrna,

I think I can start tackling this on Thursday.

Regards,
-Rick
Myrna

Oh dear, I've muddled the numbers again.  I meant for DERBY-4437 to be
backed out of the 10.8 branch.

Myrna


Reply via email to