Hi Brian,
> -----Original Message-----
> From: Brian Murray [mailto:brian.c.murray@;vanderbilt.edu]
> Sent: 29 October 2002 15:19
> To: [EMAIL PROTECTED]
> Subject: Apparent Race Condition, revisited
>
> We've experienced a condition that seems to mirror the race condition
> that Frank Baxter reported last week. What we are seeing is the
setUp()
> method of test B starting before the tearDown() method of test A has
> completed. Attempts to narrow down the cause have been unsuccessful,
> apparently because, as Frank pointed out, logging and other debug
> methods slow things down to the point where the race condition doesn't
> occur.
>
> One thing that sets this particular suite of tests apart from others
is
> that the tearDown() method executes for a relatively long time. There
> is quite a bit of database cleanup going on and it can take 30 seconds
> or more. Vincent posted that "internally Cactus reads the whole
servlet
> response *before* calling again the server side to get the test
Result".
> Is it possible that tearDown() is taking so long that the servlet
> response is complete, but tearDown() is still running?
>
> For clarity, we're using Cactus 1.4.1 and running the tests through
> jUnit's Swing test runner.
>
> We can work around the problem by moving the database work into
> beginXXX() and endXXX methods, but would rather not have to since
a)this
> isn't the way we write non-cactus tests; and b)there are concerns
> (unproven and probably unfounded) about performance.
I think you may be right. It seems the problem is that the client side
read everything on the response socket but in some cases that may not
mean processing is finished on the server side (and thus the test result
is not set as it is the last step of the processing - it happens after
teardown()).
I dunno why but I thought I had implemented something that was
guaranteed to work whatever the duration it takes on the server side ...
Actually in the past I was setting a semaphore on the server side. For
some reason I have removed that some time ago (1.2 or 1.3 version)
because I thought I had a better implementation not needing a lock...
The problem is that I can't reproduce the bug and thus I am not sure it
is the problem. What container are you using and in what version?
Here's the test I have:
public void testLongProcess() throws Exception
{
ServletOutputStream os = response.getOutputStream();
os.print("<html><head><Long Process></head><body>");
os.flush();
// do some processing that takes a while ...
Thread.sleep(60000);
}
And still it works fine (I'm testing on Tomcat 4.1.10).
Could you try this test on your setup?
If we cannot figure out the reason, I'll reimplement the semaphore stuff
so that the second request waits until the lock is removed before
returning the test results. I'll put it in CVS and ask you to give it a
try.
Thanks
-Vincent
>
> Thanks,
> Brian
>
>
> --
> To unsubscribe, e-mail: <mailto:cactus-user-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:cactus-user-
> [EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:cactus-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:cactus-user-help@;jakarta.apache.org>
