You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2003/03/25 19:41:23 UTC
Excalibur-Monitor
There were some reports that the testcases failed. I'm unable to
duplicate that.
Could someone check/arbitrate?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur-Monitor
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
> OK - I just had an idea:
>
> Or maybe it is delayed ten seconds or so.
>
> Just a quick poll:
>
> + I run the tests on W2K, and it works.
> + Berin, you ran W2K if I remember correctly - and it works.
> + GUMP runs on some UNIX derivative and it fails.
> + Leo Simons, you run Linux, yes? It fails for you.
>
> So could this be the result of impl differences between UNIX/Linux/Win
> JVMs?
Yep.
You know what? We might need to use a MockResource that mimicks
the FileResource--but doesn't use the filesystem. That way the
change would be instantaneous.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur-Monitor
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
> OK - I just had an idea:
> Just a quick poll:
>
> + I run the tests on W2K, and it works.
> + Berin, you ran W2K if I remember correctly - and it works.
> + GUMP runs on some UNIX derivative and it fails.
> + Leo Simons, you run Linux, yes? It fails for you.
>
> So could this be the result of impl differences between UNIX/Linux/Win
> JVMs?
Try it now. I removed the whole FileSystem equation so it should
pass with flying colors.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Excalibur-Monitor
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> + GUMP runs on some UNIX derivative and it fails.
My bad. The GUMP compilation fails - not the testcases (never
gets that far).
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Excalibur-Monitor
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
OK - I just had an idea:
FileResource looks like this:
public class FileResource
extends StreamResource
{
private final File m_file;
...
/**
* Determines the last time this resource was modified
*/
public long lastModified()
{
return m_file.lastModified();
}
...
}
Now, what if the m_file.lastModified() doesn't go to the filesystem to
get the last modified date when called, but the info is cached in the
m_file object? Then it would return the same value all the time.
Or maybe it is delayed ten seconds or so.
Just a quick poll:
+ I run the tests on W2K, and it works.
+ Berin, you ran W2K if I remember correctly - and it works.
+ GUMP runs on some UNIX derivative and it fails.
+ Leo Simons, you run Linux, yes? It fails for you.
So could this be the result of impl differences between UNIX/Linux/Win
JVMs?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Excalibur-Monitor
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Please advise.
I'm just guessing right now, but I'd subclass the monitor so I
could force a resource check sweep if the first non-forced
failed, or do some other synchronization between monitor and
test runner.
> Oh, BTW, don't need to get hostile.
That wasn't my intention. Sorry.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur-Monitor
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>Your processor might be able to handle the load 100 times
>>over, but the disk drive has physically moving parts that can
>>only move so fast.
>
>
> Look people, GUMP blows up on that one. End of discussion.
>
> We have a bug, or at least a use case where the monitor algorithms
> aren't working properly.
I have struggled on how to write that testcase so that we prove
the functionality works--but also in a heavily loaded environment.
If you have any ideas on how to do it, do it. I am offering
explanations as to the *cause* of the problem--so you can come up
with a better solution than I have. What you see is as smart as
I could get on that particular testcase. Do we remove the test,
and make it a question mark if it really does what is advertised,
or do we make the test last up to 10 minutes (hopefully disk
activity will have died down by then), or what?
Please advise. Oh, BTW, don't need to get hostile.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Excalibur-Monitor
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Your processor might be able to handle the load 100 times
> over, but the disk drive has physically moving parts that can
> only move so fast.
Look people, GUMP blows up on that one. End of discussion.
We have a bug, or at least a use case where the monitor algorithms
aren't working properly.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur-Monitor
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> Berin Loritsch wrote:
>
>> Times where it was failing to respond in a reasonable time coincided
>> with heavy disk access--which includes memory swapping and build times.
>
>
> hmm. I have an athlon XP 1800, with 512MB DDR333, jdk1.4.1, UDMA133
> 7200RPM disk, and pretty much tweaked for performance, running almost
> nothing but the test, and it still fails. I wonder what's wrong :D
Keep in mind that unless you are running SCSI, disk access is not only
controlled by the main processor--it can only go one direction at a
time. If you are doing a bunch of bulk writes (which you can't control
from Java--it's an OS thing), you have to wait until those writes are
done before you can read.
Your processor might be able to handle the load 100 times over, but
the disk drive has physically moving parts that can only move so
fast.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur-Monitor
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> The problem is that we have one thread that modifies the file, while the
> active monitor is poling it. If the monitor doesn't detect the change
> within ~1-10 seconds (I can't remember what it was set to), then the
> assertion fails.
>
> The problem I had when writing this test is that in accordance with
> Murphy's law, the monitor would notice the change after the timeout.
> We could wait indefinitely, but then what happens if it is legitimately
> broken?
>
> Times where it was failing to respond in a reasonable time coincided
> with heavy disk access--which includes memory swapping and build times.
hmm. I have an athlon XP 1800, with 512MB DDR333, jdk1.4.1, UDMA133
7200RPM disk, and pretty much tweaked for performance, running almost
nothing but the test, and it still fails. I wonder what's wrong :D
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur-Monitor
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> besides the current GUMP problem (which yes, I created by having gump
> try and run the tests, and will fix),
> http://cvs.apache.org/builds/gump/latest/excalibur-monitor.html
>
> I get:
>
> test:
<snip/>
> Total time: 7 seconds
>
> this is on an NTFS filesystem. I'll try and find more time for debugging
> it.
The problem is that we have one thread that modifies the file, while the
active monitor is poling it. If the monitor doesn't detect the change
within ~1-10 seconds (I can't remember what it was set to), then the
assertion fails.
The problem I had when writing this test is that in accordance with
Murphy's law, the monitor would notice the change after the timeout.
We could wait indefinitely, but then what happens if it is legitimately
broken?
Times where it was failing to respond in a reasonable time coincided
with heavy disk access--which includes memory swapping and build times.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur-Monitor
Posted by Leo Simons <le...@apache.org>.
besides the current GUMP problem (which yes, I created by having gump
try and run the tests, and will fix),
http://cvs.apache.org/builds/gump/latest/excalibur-monitor.html
I get:
test:
[echo] Performing Unit Tests
[junit] Running
org.apache.avalon.excalibur.monitor.test.MonitorTestCase
[junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 3,734 sec
[junit] Testsuite:
org.apache.avalon.excalibur.monitor.test.MonitorTestCase
[junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 3,734 sec
[junit] ------------- Standard Output ---------------
[junit] INFO 2003-03-26 21:14:22.171 [MonitorTestCase
] ():
<title>Monitor Tests</title>
[junit] <para>
[junit] This series of tests excersize the different
monitors provid
ed by
[junit] Excalibur. The configuration is specified in the
file locat
ed in
[junit]
<parameter>jakarta-avalon-excalibur/src/scratchpad/org/apach
e/avalon/excalibur/monitor/test/MonitorTest.xtext</parameter>.
[junit] You may edit the test to customize the settings.
[junit] </para>
[junit] ------------- ---------------- ---------------
[junit] Testcase: testActiveMonitor took 2,031 sec
[junit] FAILED
[junit] File not changed
[junit] junit.framework.AssertionFailedError: File not changed
[junit] at
org.apache.avalon.excalibur.monitor.test.MonitorTestCase.chec
kForModification(MonitorTestCase.java:238)
[junit] at
org.apache.avalon.excalibur.monitor.test.MonitorTestCase.inte
rnalTestProcedure(MonitorTestCase.java:170)
[junit] at
org.apache.avalon.excalibur.monitor.test.MonitorTestCase.test
ActiveMonitor(MonitorTestCase.java:95)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces
sorImpl.java:39)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
hodAccessorImpl.java:25)
[junit] at
org.apache.avalon.excalibur.testcase.ExcaliburTestCase.run(Ex
caliburTestCase.java:445)
[junit] Testcase: testActiveMonitorTestcase: testPassiveMonitor
took 1,031 s
ec
BUILD FAILED
file:E:/home/lsimons/Documents/cvs/avalon-excalibur/monitor/build.xml:193:
Test
org.apache.avalon.excalibur.monitor.test.MonitorTestCase failed
Total time: 7 seconds
this is on an NTFS filesystem. I'll try and find more time for debugging it.
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Excalibur-Monitor
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
OK, then we'll stamp that with a "Works For Me".
> From: Berin Loritsch [mailto:bloritsch@apache.org]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur-Monitor
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>There is a testcase that works with timing. If the timing is
>>off which can happen if the server is loaded, then it can
>>cause that testcase to fail.
>
>
> Berin,
>
> when you prepare the next iteration of these components before release,
> could you run the monitor testcases? If it works for both of us, I think
> we have enough basis to claim "works for me" and move on.
It worked for me the last time.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Excalibur-Monitor
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> There is a testcase that works with timing. If the timing is
> off which can happen if the server is loaded, then it can
> cause that testcase to fail.
Berin,
when you prepare the next iteration of these components before release,
could you run the monitor testcases? If it works for both of us, I think
we have enough basis to claim "works for me" and move on.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur-Monitor
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
> There were some reports that the testcases failed. I'm unable to
> duplicate that.
>
> Could someone check/arbitrate?
There is a testcase that works with timing. If the timing is off
which can happen if the server is loaded, then it can cause that
testcase to fail.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org