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: <mailto:cactus-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:cactus-user-help@;jakarta.apache.org>
