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 2009/03/24 02:26:10 UTC

[VOTE] 10.5.1.0 release candidate

Please test and vote on the 10.5.1.0 release candidate, available at:

http://people.apache.org/~myrnavl/derby-10.5.1.0-RC1/

You can report platform testing results at:
http://wiki.apache.org/db-derby/TenFiveOnePlatformTesting

Other testing results can be reported at
http://wiki.apache.org/db-derby/DerbyTenFiveOneRelease

Polls will close Monday, April 13, 2009.

Regards,
Myrna

Re: [VOTE] 10.5.1.0 release candidate

Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Rick Hillegas <Ri...@Sun.COM> writes:

> Myrna van Lunteren wrote:
>> Please test and vote on the 10.5.1.0 release candidate, available at:
>>
>> http://people.apache.org/~myrnavl/derby-10.5.1.0-RC1/
>>
>> You can report platform testing results at:
>> http://wiki.apache.org/db-derby/TenFiveOnePlatformTesting
>>
>> Other testing results can be reported at
>> http://wiki.apache.org/db-derby/DerbyTenFiveOneRelease
>>
>> Polls will close Monday, April 13, 2009.
>>
>> Regards,
>> Myrna
>>   
> I have verified the signatures and md5 checksums.

I have verified that the corresponding zip and tar.gz files have
identical contents (same set of files and identical file contents) and
that it is possible to build Derby and the docs from the source
tarball. I've also tested that all of the sh scripts in the bin
distribution work (reported one small bug, DERBY-4117).

-- 
Knut Anders

Re: [VOTE] 10.5.1.0 release candidate

Posted by Rick Hillegas <Ri...@Sun.COM>.
Myrna van Lunteren wrote:
> Please test and vote on the 10.5.1.0 release candidate, available at:
>
> http://people.apache.org/~myrnavl/derby-10.5.1.0-RC1/
>
> You can report platform testing results at:
> http://wiki.apache.org/db-derby/TenFiveOnePlatformTesting
>
> Other testing results can be reported at
> http://wiki.apache.org/db-derby/DerbyTenFiveOneRelease
>
> Polls will close Monday, April 13, 2009.
>
> Regards,
> Myrna
>   
I have verified the signatures and md5 checksums.

Cheers,
-Rick

Re: [VOTE] 10.5.1.0 release candidate

Posted by Mike Matrigali <mi...@sbcglobal.net>.
Often just the stack trace for this kind of exception can help a lot, 
likely to be in derby.log if you still have it.

Kristian Waagan wrote:
> I have also seen an issue with multi-threaded inserts (25 threads 
> against the same table) and a subsequent table compress, but I have to 
> investigate further (I was unable to recover the stack trace, I just got 
> the error message).
> The table grew to around 20 GB, but the amount of data in it should be 
> far less (maybe around 2 GB, ten times less). When compressing, Derby 
> threw an IllegalArgumentException, saying "Illegal Capacity: XXX". This 
> can look as an overflow or a calculation error when sizing one of 
> Vector, ArrayList, or Hashtable.
> I'll try to reproduce and get more information.
> 
> 

Re: [VOTE] 10.5.1.0 release candidate

Posted by Myrna van Lunteren <m....@gmail.com>.
On Wed, Mar 25, 2009 at 9:54 AM, Knut Anders Hatlen <Kn...@sun.com> wrote:
> Kathey Marsden <km...@sbcglobal.net> writes:
>
>> Kristian Waagan wrote:
>>>
>>> If you plan to vote against the release if DERBY-4075 is
>>> outstanding, I think we need to lay a plan for it.
>> One thing to note is that the community can still make a release even
>> if I vote -1.  It is not a veto and some might say I am too
>> conservative about these things, but thanks for placing such
>> importance on my vote and this issue!
>>
>>> I've been running the test for weeks without seeing the issue. The
>>> largest database grew to 67 GB (plus 67 GB for the backup), another
>>> one grew to 32 GB.
>>> If we clearly communicate the environment where the problems have
>>> been seen, people would get the chance to start test runs of their
>>> own.
>>> After all, starting the test itself is very simple.
>>>
>>>
>> I tried it on my Windows XP box with IBM 1.6 and cutting the sleeps to
>> one tenth of their original setting,  but ran into out of space errors
>> after  9 hours.  I  plan to start playing with this again after my
>> buddy testing is complete.  It would be great if others could kick off
>> runs.
>
> I've started a run too with a modified Derby. I applied the patch from
> the bug description in DERBY-3393 to see if that could be related. No
> errors so far, but I'll keep it running.
>
> --
> Knut Anders
>

Obviously, DERBY-4075 is a great concern to me. I was of two minds
between holding off and spinning the release. But without a clear way
of reproducing this except on my 2 - and admittedly somewhat older -
machines, it's difficult, and usually no serious testing is done until
there is an RC.

I don't want to spin another release right now. Firstly I'd rather
everybody attack the RC with whatever testing can be found and I'll
kick off more tests and find more machines, and also it takes quite
some effort to spin the artifacts and I'd rather spend the time on
doing some more testing first.

So, I suggest we do our tests, say, for the next 2 weeks, then see
where we are and if we're ready for another RC at that time.

Opinions?

Myrna

Re: [VOTE] 10.5.1.0 release candidate

Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Kathey Marsden <km...@sbcglobal.net> writes:

> Kristian Waagan wrote:
>>
>> If you plan to vote against the release if DERBY-4075 is
>> outstanding, I think we need to lay a plan for it.
> One thing to note is that the community can still make a release even
> if I vote -1.  It is not a veto and some might say I am too
> conservative about these things, but thanks for placing such
> importance on my vote and this issue!
>
>> I've been running the test for weeks without seeing the issue. The
>> largest database grew to 67 GB (plus 67 GB for the backup), another
>> one grew to 32 GB.
>> If we clearly communicate the environment where the problems have
>> been seen, people would get the chance to start test runs of their
>> own.
>> After all, starting the test itself is very simple.
>>
>>
> I tried it on my Windows XP box with IBM 1.6 and cutting the sleeps to
> one tenth of their original setting,  but ran into out of space errors
> after  9 hours.  I  plan to start playing with this again after my
> buddy testing is complete.  It would be great if others could kick off
> runs. 

I've started a run too with a modified Derby. I applied the patch from
the bug description in DERBY-3393 to see if that could be related. No
errors so far, but I'll keep it running.

-- 
Knut Anders

Re: [VOTE] 10.5.1.0 release candidate

Posted by Kathey Marsden <km...@sbcglobal.net>.
Kristian Waagan wrote:
>
> If you plan to vote against the release if DERBY-4075 is outstanding, 
> I think we need to lay a plan for it.
One thing to note is that the community can still make a release even if 
I vote -1.  It is not a veto and some might say I am too conservative 
about these things, but thanks for placing such importance on my vote 
and this issue!

> I've been running the test for weeks without seeing the issue. The 
> largest database grew to 67 GB (plus 67 GB for the backup), another 
> one grew to 32 GB.
> If we clearly communicate the environment where the problems have been 
> seen, people would get the chance to start test runs of their own.
> After all, starting the test itself is very simple.
>
>
I tried it on my Windows XP box with IBM 1.6 and cutting the sleeps to 
one tenth of their original setting,  but ran into out of space errors 
after  9 hours.  I  plan to start playing with this again after my buddy 
testing is complete.  It would be great if others could kick off runs. 

 >I have also seen an issue with multi-threaded inserts (25 threads 
against the same table) and >a subsequent table compress
Thanks for identifying a new issue. I look forward to hearing more about 
it, particularly if it is a regression.

Kathey



Re: [VOTE] 10.5.1.0 release candidate

Posted by Kristian Waagan <Kr...@Sun.COM>.
Kathey Marsden wrote:
> Rick Hillegas wrote:
>> I think it's worth spinning a new release candidate for this problem. 
>> We might want to wait another day to see if people trip across other 
>> serious problems with the current RC.
>>
> I think we should wait more than a day.  I think it would be good to 
> get the first round of Buddy testing done.  I think I should be able 
> to finish update statistics by Friday.   Also we still have DERBY-4075 
> to contend with.  I plan to vote against the release if this issue  is 
> outstanding.

If you plan to vote against the release if DERBY-4075 is outstanding, I 
think we need to lay a plan for it.
I've been running the test for weeks without seeing the issue. The 
largest database grew to 67 GB (plus 67 GB for the backup), another one 
grew to 32 GB.
If we clearly communicate the environment where the problems have been 
seen, people would get the chance to start test runs of their own.
After all, starting the test itself is very simple.


I have also seen an issue with multi-threaded inserts (25 threads 
against the same table) and a subsequent table compress, but I have to 
investigate further (I was unable to recover the stack trace, I just got 
the error message).
The table grew to around 20 GB, but the amount of data in it should be 
far less (maybe around 2 GB, ten times less). When compressing, Derby 
threw an IllegalArgumentException, saying "Illegal Capacity: XXX". This 
can look as an overflow or a calculation error when sizing one of 
Vector, ArrayList, or Hashtable.
I'll try to reproduce and get more information.


-- 
Kristian

> Speaking of buddy testing, we still have some features unassigned.
> http://wiki.apache.org/db-derby/TenFiveOneBuddyTesting
> Students, buddy testing is a great way to start contributing to the 
> community and requires little set up.  You just need to update the 
> Wiki, download the release candidate and do some ad hoc testing of  
> the feature and documentation.
>
> Kathey
>


Re: [VOTE] 10.5.1.0 release candidate

Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas wrote: 
> I think it's worth spinning a new release candidate for this problem. 
> We might want to wait another day to see if people trip across other 
> serious problems with the current RC.
>
I think we should wait more than a day.  I think it would be good to get 
the first round of Buddy testing done.  I think I should be able to 
finish update statistics by Friday.   Also we still have DERBY-4075 to 
contend with.  I plan to vote against the release if this issue  is 
outstanding.

Speaking of buddy testing, we still have some features unassigned.
http://wiki.apache.org/db-derby/TenFiveOneBuddyTesting
Students, buddy testing is a great way to start contributing to the 
community and requires little set up.  You just need to update the Wiki, 
download the release candidate and do some ad hoc testing of  the 
feature and documentation.

Kathey


Re: [VOTE] 10.5.1.0 release candidate

Posted by Rick Hillegas <Ri...@Sun.COM>.
Kristian Waagan wrote:
> Myrna van Lunteren wrote:
>> Please test and vote on the 10.5.1.0 release candidate, available at:
>>   
>
> Knut Magne Solem has tested the in-memory back end on Windows, and 
> found a bug that makes it impossible to use on Windows.
> See comment on DERBY-646.
>
> I'll be looking into this today, and hopefully have a patch ready at 
> the end of the day. I have even managed to get hold of a Windows test 
> machine :)
> My opinion is that it would be unfortunate to release 10.5 with a new 
> feature that doesn't work on Windows, even if the feature is 
> experimental.
I think it's worth spinning a new release candidate for this problem. We 
might want to wait another day to see if people trip across other 
serious problems with the current RC.

Thanks,
-Rick
>
> Other options;
> o do nothing, let non-Windows users test/use the in-memory back end
> o pull the feature out (still requires building a new release candidate)
>
>


Re: [VOTE] 10.5.1.0 release candidate

Posted by Kristian Waagan <Kr...@Sun.COM>.
Myrna van Lunteren wrote:
> Please test and vote on the 10.5.1.0 release candidate, available at:
>   

Knut Magne Solem has tested the in-memory back end on Windows, and found 
a bug that makes it impossible to use on Windows.
See comment on DERBY-646.

I'll be looking into this today, and hopefully have a patch ready at the 
end of the day. I have even managed to get hold of a Windows test machine :)
My opinion is that it would be unfortunate to release 10.5 with a new 
feature that doesn't work on Windows, even if the feature is experimental.

Other options;
 o do nothing, let non-Windows users test/use the in-memory back end
 o pull the feature out (still requires building a new release candidate)


-- 
Kristian

> http://people.apache.org/~myrnavl/derby-10.5.1.0-RC1/
>
> You can report platform testing results at:
> http://wiki.apache.org/db-derby/TenFiveOnePlatformTesting
>
> Other testing results can be reported at
> http://wiki.apache.org/db-derby/DerbyTenFiveOneRelease
>
> Polls will close Monday, April 13, 2009.
>
> Regards,
> Myrna
>