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
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 f
> From: Leo Sutic [mailto:[EMAIL PROTECTED]
>
> + 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: [EMAIL PROTECTED]
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
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]
>
> 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 ho
Leo Sutic wrote:
From: Berin Loritsch [mailto:[EMAIL PROTECTED]
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
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]
>
> 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 cas
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 perfo
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 tha
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:
Total time: 7 seconds
this is on an NTFS filesystem. I'll try and find more time for debu
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.MonitorTestCas
OK, then we'll stamp that with a "Works For Me".
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Leo Sutic wrote:
From: Berin Loritsch [mailto:[EMAIL PROTECTED]
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,
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]
>
> 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
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.
-
On Sat, 1 Mar 2003 14:57, Developer wrote:
> Done. I have built an FTPResource, to compliment the FileResource. I used
> the commons-net stuff. As soon as I get it cleaned up, and the junit tests
> verified, I'll submit it back to you.
kool!
> Question: Has anyone ever submitted a Windows FTP lis
e?
R-
-Original Message-
From: Peter Donald [mailto:[EMAIL PROTECTED]
Sent: Friday, February 28, 2003 6:03 PM
To: Avalon Developers List
Subject: Re: Excalibur monitor patches
Hi,
Could you download the latest Monitor version from CVS. The latest version
should already support LogEnable
Hi,
Could you download the latest Monitor version from CVS. The latest version
should already support LogEnabled and should work fine in Phoenix. If not
could you make the changes against the new versions of these classes?
On Mon, 24 Feb 2003 04:27, Developer wrote:
> My guess is you guys fight
18 matches
Mail list logo
