You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-user@jakarta.apache.org by Brian Murray <br...@vanderbilt.edu> on 2002/10/29 16:19:29 UTC

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.

Thanks,
Brian


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Apparent Race Condition, revisited

Posted by Vincent Massol <vm...@octo.com>.
Hi Brian,

> -----Original Message-----
> From: Brian Murray [mailto:brian.c.murray@vanderbilt.edu]
> Sent: 29 October 2002 15:19
> To: cactus-user@jakarta.apache.org
> 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-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:cactus-user-
> help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>