!$!% derbyall

["David W. Van Couvering" <Da...@Sun.COM>]

<rant on>
Sorry, but it is so frustrating.  I started a derbyall run at 9 this 
morning, and it was still running this evening.  My CPU was at 100%, I 
could get barely any work done, and then my machine hung up, I had to 
reboot, and the way our harness works you have to start *completely from 
scratch* -- there is no way to start from the beginning.
</rant off>

If I weren't so busy trying to get some this i18n work completed I would 
do the work of defining a smaller MATS.

Instead I must sigh and restart the thing all over again.  Hopefully by 
tomorrow morning it will be completed.   I have two other patches in the 
queue waiting for machine resources so I can run derbyall for them as 
well...

David

Re: Patch for running RunSuite with a list of suites (was Re: !$!% derbyall)

[Andrew McIntyre <mc...@gmail.com>]

On 4/13/06, David W. Van Couvering <Da...@sun.com> wrote:
> Great, thanks.
>
> I'll try your patch out.  Is this something you'll commit if it works
> for you (and me)?

Sure. I think I'd rather call the new method adhocSuite instead of
overrideSuites, since that's more descriptive, and I've some other
minor mods to make before it goes in, but if it works out for you,
I'll commit.

andrew

Re: Patch for running RunSuite with a list of suites (was Re: !$!% derbyall)

["David W. Van Couvering" <Da...@Sun.COM>]

Great, thanks.

I'll try your patch out.  Is this something you'll commit if it works 
for you (and me)?

David

Andrew McIntyre wrote:
> On 4/13/06, David W. Van Couvering <Da...@sun.com> wrote:
> 
>>Can anyone tell me how I find out, if derbyall or any suite goes down
>>half-way through, what suites have run so far, and which ones have
>>passed and which ones have failed?
> 
> 
> In the directory where you were running the tests will be a file
> {suite}.sum, which contains a running list of all the tests that had
> run so far. you'll need to take a look at the order of the suites in
> derbyall to determine where you were, exactly. But just search for
> 'Failed' in the sum file and you'll find the diff of any failures that
> had already occurred.
> 
> andrew

Re: Patch for running RunSuite with a list of suites (was Re: !$!% derbyall)

[Andrew McIntyre <mc...@gmail.com>]

On 4/13/06, David W. Van Couvering <Da...@sun.com> wrote:
>
> Can anyone tell me how I find out, if derbyall or any suite goes down
> half-way through, what suites have run so far, and which ones have
> passed and which ones have failed?

In the directory where you were running the tests will be a file
{suite}.sum, which contains a running list of all the tests that had
run so far. you'll need to take a look at the order of the suites in
derbyall to determine where you were, exactly. But just search for
'Failed' in the sum file and you'll find the diff of any failures that
had already occurred.

andrew

Patch for running RunSuite with a list of suites (was Re: !$!% derbyall)

["David W. Van Couvering" <Da...@Sun.COM>]

This is great, Andrew, thanks!

Can anyone tell me how I find out, if derbyall or any suite goes down 
half-way through, what suites have run so far, and which ones have 
passed and which ones have failed?

Thanks,

David

Andrew McIntyre wrote:
> On 4/12/06, Andrew McIntyre <mc...@gmail.com> wrote:
> 
>>On 4/12/06, David W. Van Couvering <Da...@sun.com> wrote:
>>
>>><rant on>
>>>Sorry, but it is so frustrating.  I started a derbyall run at 9 this
>>>morning, and it was still running this evening.  My CPU was at 100%, I
>>>could get barely any work done, and then my machine hung up, I had to
>>>reboot, and the way our harness works you have to start *completely from
>>>scratch* -- there is no way to start from the beginning.
>>></rant off>
>>
>>I'm with you on that. I've always wanted to have RunSuite take a list
>>of suites, not just one.
> 
> 
> Rant and you shall recieve? Attached is a patch which does the above.
> It turned out to be a little more difficult than I thought, because
> the harness actually does some setup in getSuiteProperties (bad
> harness! bad!), so I couldn't just override the value of the suites
> field. But then again turned out to not be so bad, since
> getSuiteProperties already included functionality to load a suite
> definition from the current directory, so I just needed to write out a
> new adhoc suite definition.
> 
> In other news, RunSuite can read a suite definition from the current
> directory. Did anyone else know that? I didn't. Anyway, makes this
> patch sort of moot. But with the patch its even more direct, just
> enter the suites you want to run on the command line.
> 
> cheers,
> andrew

Re: !$!% derbyall

[Andrew McIntyre <mc...@gmail.com>]

On 4/12/06, Andrew McIntyre <mc...@gmail.com> wrote:
> On 4/12/06, David W. Van Couvering <Da...@sun.com> wrote:
> > <rant on>
> > Sorry, but it is so frustrating.  I started a derbyall run at 9 this
> > morning, and it was still running this evening.  My CPU was at 100%, I
> > could get barely any work done, and then my machine hung up, I had to
> > reboot, and the way our harness works you have to start *completely from
> > scratch* -- there is no way to start from the beginning.
> > </rant off>
>
> I'm with you on that. I've always wanted to have RunSuite take a list
> of suites, not just one.

Rant and you shall recieve? Attached is a patch which does the above.
It turned out to be a little more difficult than I thought, because
the harness actually does some setup in getSuiteProperties (bad
harness! bad!), so I couldn't just override the value of the suites
field. But then again turned out to not be so bad, since
getSuiteProperties already included functionality to load a suite
definition from the current directory, so I just needed to write out a
new adhoc suite definition.

In other news, RunSuite can read a suite definition from the current
directory. Did anyone else know that? I didn't. Anyway, makes this
patch sort of moot. But with the patch its even more direct, just
enter the suites you want to run on the command line.

cheers,
andrew

Re: !$!% derbyall

[Andrew McIntyre <mc...@gmail.com>]

On 4/12/06, David W. Van Couvering <Da...@sun.com> wrote:
> <rant on>
> Sorry, but it is so frustrating.  I started a derbyall run at 9 this
> morning, and it was still running this evening.  My CPU was at 100%, I
> could get barely any work done, and then my machine hung up, I had to
> reboot, and the way our harness works you have to start *completely from
> scratch* -- there is no way to start from the beginning.
> </rant off>

I'm with you on that. I've always wanted to have RunSuite take a list
of suites, not just one. Then, if e.g. derbyall bites in somewhere in
the middle you can just pass it the remaining suites to rerun. And it
would be nice if it could take an ad-hoc suite as an argument from a
properties file or even directly from the command line. Or an
exclude-subsuites property to selectively skip certain subsuites of an
already existing suite.

The first option above should be fairly easy, the others not so much.

andrew

Re: !$!% derbyall

[Kathey Marsden <km...@sbcglobal.net>]

A couple of thoughts on this.

1) I find frequent defragmentation is helpful in moving things along.
2) I was noticing in porting DERBY-614 that big.sql runs in derbyall 
with network server but not embedded.
    I first thought we should run that in embedded, but then started
thinking that actually running it in network server, does run it in
embedded.  A lot of the sql tests we run twice like this, once in
embedded and once in network server, where just the network server run
would provide all the coverage we need.  Just something to consider for
the MATS suite.

Kathey

Re: !$!% derbyall

["David W. Van Couvering" <Da...@Sun.COM>]

I usually do run derbynetclientmats.  But sometimes I adjust message 
text to make it more generic/have it make more sense for both client and 
engine.  And sometimes the message text is just plain wrong or 
confusing.  So this affects the embedded tests.

David

Daniel John Debrunner wrote:
> David W. Van Couvering wrote:
> 
>><rant on>
>>Sorry, but it is so frustrating.  I started a derbyall run at 9 this
>>morning, and it was still running this evening.  My CPU was at 100%, I
>>could get barely any work done, and then my machine hung up, I had to
>>reboot, and the way our harness works you have to start *completely from
>>scratch* -- there is no way to start from the beginning.
>></rant off>
>>
>>If I weren't so busy trying to get some this i18n work completed I would
>>do the work of defining a smaller MATS.
>>
> 
> 
> If you are doing client i18n work then why are you running derbyall?
> 
> Why not just run derbynetclientmats?
> 
> Dan.
> 

Re: !$!% derbyall

[Daniel John Debrunner <dj...@apache.org>]

David W. Van Couvering wrote:
> <rant on>
> Sorry, but it is so frustrating.  I started a derbyall run at 9 this
> morning, and it was still running this evening.  My CPU was at 100%, I
> could get barely any work done, and then my machine hung up, I had to
> reboot, and the way our harness works you have to start *completely from
> scratch* -- there is no way to start from the beginning.
> </rant off>
> 
> If I weren't so busy trying to get some this i18n work completed I would
> do the work of defining a smaller MATS.
> 

If you are doing client i18n work then why are you running derbyall?

Why not just run derbynetclientmats?

Dan.

Re: !$!% derbyall

[Mike Matrigali <mi...@sbcglobal.net>]

David W. Van Couvering wrote:
> Thanks for your tips and concern, all.
> 
> Mike: I remember that it used to take me four hours a few weeks ago, and 
> I didn't have these CPU issues, but this latest run broke all records. 
> My laptop is pretty good -- I upgraded specifically so I could run 
> derbyall on it and keep working, but for some reason yesterday it was 
> just killing me.
I see now from other comments that comparing to 10.1 is not very useful,
I'll keep an eye out next time I run against trunk.  I usually run over
night, so in the past I haven't really noticed.

Re: !$!% derbyall

["David W. Van Couvering" <Da...@Sun.COM>]

Thanks, Dyre, good info.

I was running with 393331

I'll try nice, I was surprised to find it available on Cygwin.

David

Dyre.Tjeldvoll@Sun.COM wrote:
> "David W. Van Couvering" <Da...@Sun.COM> writes:
> 
> 
>>Thanks for your tips and concern, all.
>>
>>Mike: I remember that it used to take me four hours a few weeks ago, and 
>>I didn't have these CPU issues, but this latest run broke all records. 
>>My laptop is pretty good -- I upgraded specifically so I could run 
>>derbyall on it and keep working, but for some reason yesterday it was 
>>just killing me.
> 
> 
> Do you happen to know the exact revision you were running?
> 
> From
> http://www.multinet.no/~solberg/public/Apache/Derby/index.html/derbyall_history.html
> 
> it looks like r392019 and r392564 took a long time, up to 2.5
> times the baseline on some platforms.
> 
> A general observation is that the running time seems to increase with
> the number of failures.
> 
> I try to run derbyall with nice. It usually doesn't take much longer,
> AND my machine is usable, even during stress.multi.
> 

Re: !$!% derbyall

[Dy...@Sun.COM]

"David W. Van Couvering" <Da...@Sun.COM> writes:

> Thanks for your tips and concern, all.
>
> Mike: I remember that it used to take me four hours a few weeks ago, and 
> I didn't have these CPU issues, but this latest run broke all records. 
> My laptop is pretty good -- I upgraded specifically so I could run 
> derbyall on it and keep working, but for some reason yesterday it was 
> just killing me.

Do you happen to know the exact revision you were running?

From
http://www.multinet.no/~solberg/public/Apache/Derby/index.html/derbyall_history.html

it looks like r392019 and r392564 took a long time, up to 2.5
times the baseline on some platforms.

A general observation is that the running time seems to increase with
the number of failures.

I try to run derbyall with nice. It usually doesn't take much longer,
AND my machine is usable, even during stress.multi.

-- 
dt

Re: !$!% derbyall

["David W. Van Couvering" <Da...@Sun.COM>]

Thanks for your tips and concern, all.

Mike: I remember that it used to take me four hours a few weeks ago, and 
I didn't have these CPU issues, but this latest run broke all records. 
My laptop is pretty good -- I upgraded specifically so I could run 
derbyall on it and keep working, but for some reason yesterday it was 
just killing me.

When I ran Task Manager, it showed java.exe taking up 80-90% of CPU, and 
when certain tests ran (stress.multi) it went up to 100%.

Kathey: I run Disk Defragmenter every day... (except yesterday, as I was 
already in trouble before it kicked off automatically, so I killed it)

[PC Information]
OS Version                    Microsoft Windows XP Professional 
5.1.2600   Service Pack 2
CPU                           Intel(R) Pentium(R) M processor 2.00GHz
Memory                        2048MB RAM
Hard Disk Capacity            60,011,642,880 [Byte]   55.890 [GB]
Hard Disk Free Space Capacity 29,242,060,800 [Byte]   27.234 [GB]
IDE Device 1                  HTS726060M9AT00
(I got this disk particularly because it was reasonably fast)

David

Mike Matrigali wrote:
> 
> 
> David W. Van Couvering wrote:
> 
>> <rant on>
>> Sorry, but it is so frustrating.  I started a derbyall run at 9 this 
>> morning, and it was still running this evening.  My CPU was at 100%, I 
>> could get barely any work done, and then my machine hung up, I had to 
> 
> 
> Out of curiosity what are the specs on the machine you are running.
> I run on a 2 year old laptop, running XP - 1700 mhz, sane build.  My 
> latest run against sun jvm 1.4.2 against 10.1 was 4 hours - and I hardly 
> ever see 100% cpu (I realize trunk has more tests, just don't have those
> results handy).  It is likely insane build will run faster.
> 
> 

Re: !$!% derbyall

[Mike Matrigali <mi...@sbcglobal.net>]

David W. Van Couvering wrote:
> <rant on>
> Sorry, but it is so frustrating.  I started a derbyall run at 9 this 
> morning, and it was still running this evening.  My CPU was at 100%, I 
> could get barely any work done, and then my machine hung up, I had to 

Out of curiosity what are the specs on the machine you are running.
I run on a 2 year old laptop, running XP - 1700 mhz, sane build.  My 
latest run against sun jvm 1.4.2 against 10.1 was 4 hours - and I hardly 
ever see 100% cpu (I realize trunk has more tests, just don't have those
results handy).  It is likely insane build will run faster.

Re: !$!% derbyall

[Satheesh Bandaram <sa...@Sourcery.Org>]

Rick Hillegas wrote:

>
> 2) I seem to recall that, earlier this year, optimizer modifications
> bloated up the the per-query running time.
>
I second Army's note... I would like to see specifics if true. The only
known problem after original Army's fixes is with NIST test taking much
longer, for which Army submitted a fix sometime ago. I checked in the
fix into trunk yesterday. If anyone know any specific performance
regressions, I would like to know about them.

Satheesh

> -Rick
>
> David W. Van Couvering wrote:
>
>> <rant on>
>> Sorry, but it is so frustrating.  I started a derbyall run at 9 this
>> morning, and it was still running this evening.  My CPU was at 100%,
>> I could get barely any work done, and then my machine hung up, I had
>> to reboot, and the way our harness works you have to start
>> *completely from scratch* -- there is no way to start from the
>> beginning.
>> </rant off>
>>
>> If I weren't so busy trying to get some this i18n work completed I
>> would do the work of defining a smaller MATS.
>>
>> Instead I must sigh and restart the thing all over again.  Hopefully
>> by tomorrow morning it will be completed.   I have two other patches
>> in the queue waiting for machine resources so I can run derbyall for
>> them as well...
>>
>> David
>
>
>
>
>

Re: !$!% derbyall

[Rick Hillegas <Ri...@Sun.COM>]

Hi Army,

This is probably the issue I was referring to. If it's resolved, that's 
great.

Thanks,
-Rick

Army wrote:

> Rick Hillegas wrote:
>
>> 2) I seem to recall that, earlier this year, optimizer modifications 
>> bloated up the the per-query running time.
>
>
> Ummm...I think I'm the only one who has made optimizer modifications 
> this year, so I guess that's a reference to me.  Are you thinking 
> about any changes in particular?
>
> So far as I know, derbyall was taking just as long after each of my 
> changes as it was before, with the exception of the nist suite 
> slow-down that Ole pointed out (which has, I *think*, been resolved?) 
> and some (expected) extra time for the extra test cases that I've added.
>
> I'm not denying this, but it'd be great if you could give the specific 
> Jira issues and/or test results that are the basis of this statement.  
> If we're seeing significant slow-down because of my optimizer changes, 
> then a) something is probably wrong, and b) I wish someone would have 
> said something sooner...
>
> Army
>

Re: !$!% derbyall

[Army <qo...@gmail.com>]

Rick Hillegas wrote:
> 2) I seem to recall that, earlier this year, optimizer modifications 
> bloated up the the per-query running time.

Ummm...I think I'm the only one who has made optimizer modifications this year, 
so I guess that's a reference to me.  Are you thinking about any changes in 
particular?

So far as I know, derbyall was taking just as long after each of my changes as 
it was before, with the exception of the nist suite slow-down that Ole pointed 
out (which has, I *think*, been resolved?) and some (expected) extra time for 
the extra test cases that I've added.

I'm not denying this, but it'd be great if you could give the specific Jira 
issues and/or test results that are the basis of this statement.  If we're 
seeing significant slow-down because of my optimizer changes, then a) something 
is probably wrong, and b) I wish someone would have said something sooner...

Army

Re: !$!% derbyall

[Rick Hillegas <Ri...@Sun.COM>]

On my similalry configured machine, debyall takes about half a day to 
run. This contrasts with its behavior last July, when it took maybe 3-4 
hours. It's my impression that derbyall takes significantly longer to 
run this week than it did last week. Here are my unscientific musings:

1) On my machine, I notice that tests take significantly longer if I run 
them under the SecurityManager.
2) I seem to recall that, earlier this year, optimizer modifications 
bloated up the the per-query running time.

-Rick

David W. Van Couvering wrote:

> <rant on>
> Sorry, but it is so frustrating.  I started a derbyall run at 9 this 
> morning, and it was still running this evening.  My CPU was at 100%, I 
> could get barely any work done, and then my machine hung up, I had to 
> reboot, and the way our harness works you have to start *completely 
> from scratch* -- there is no way to start from the beginning.
> </rant off>
>
> If I weren't so busy trying to get some this i18n work completed I 
> would do the work of defining a smaller MATS.
>
> Instead I must sigh and restart the thing all over again.  Hopefully 
> by tomorrow morning it will be completed.   I have two other patches 
> in the queue waiting for machine resources so I can run derbyall for 
> them as well...
>
> David