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 Frank Baxter <fr...@baxres.org> on 2002/10/21 21:16:03 UTC
Apparent race condition in Cactus?
I'm using Cactus and I'm running into a strange problem. About half the
time, my tests fail, and it appears to be caused by GET_RESULT being
invoked before the results are saved to the context.
From the server log:
...
02:39:27,096 [HttpProcessor[8080][3]] DEBUG
ache.cactus.ServiceEnumeration - <equals([GET_RESULTS])
02:39:27,096 [HttpProcessor[8080][3]] DEBUG
ache.cactus.ServiceEnumeration - >equals = [true]02:39:27,096
[HttpProcessor[8080][3]] DEBUG s.server.AbstractWebTestCaller -
Test Result = [null]
02:39:27,130 [HttpProcessor[8080][4]] DEBUG
s.server.AbstractWebTestCaller - Test result : [Test ok]
02:39:27,131 [HttpProcessor[8080][4]] DEBUG
s.server.AbstractWebTestCaller - Result saved in context scope
...
From the client log:
...
02:39:27,091 [main] DEBUG httpclient.HttpConnection -
HttpConnection.write(byte[])
02:39:27,091 [main] INFO httpclient.wire - >> "GET
/test/ServletRedirector?Cactus_Service=GET_RESULTS HTTP/1.1
"
02:39:27,091 [main] DEBUG httpclient.HttpMethod -
HttpMethodBase.writeRequestHeaders(HttpState,HttpConnection)
02:39:27,091 [main] DEBUG httpclient.HttpConnection -
HttpConnection.write(byte[])
02:39:27,091 [main] INFO httpclient.wire - >>
"Host: localhost
"
02:39:27,092 [main] DEBUG httpclient.HttpConnection -
HttpConnection.write(byte[])
02:39:27,092 [main] INFO httpclient.wire - >>
"User-Agent: Jakarta HTTP Client/2.0.0a1
"
02:39:27,092 [main] DEBUG httpclient.HttpConnection -
HttpConnection.write(byte[])
02:39:27,092 [main] INFO httpclient.wire - >>
"Content-type: application/x-www-form-urlencoded
"
02:39:27,092 [main] DEBUG httpclient.HttpConnection -
HttpConnection.writeLine()
02:39:27,092 [main] INFO httpclient.wire - >> \r\n
02:39:27,108 [main] DEBUG httpclient.HttpMethod -
HttpMethodBase.readResponse(HttpState,HttpConnection)
02:39:27,108 [main] DEBUG httpclient.HttpMethod -
HttpMethodBase.readStatusLine(HttpState,HttpConnection)
02:39:27,108 [main] DEBUG httpclient.HttpConnection -
HttpConnection.readLine()
02:39:27,109 [main] INFO httpclient.wire - <<
"HTTP/1.1 500 Internal Server Error" [\r\n]
...
02:39:27,115 [main] INFO httpclient.wire - <<
"<html><head><title>Apache Tomcat/4.1.12 - Error
report</title><STYLE><!--H1{font-family :
sans-serif,Arial,Tahoma;color : white;background-color : #0086b2;}
H3{font-family : sans-serif,Arial,Tahoma;color :
white;background-color : #0086b2;} BODY{font-family :
sans-serif,Arial,Tahoma;color : black;background-color : white;}
B{color : white;background-color : #0086b2;} HR{color : #0086b2;}
--></STYLE> </head><body><h1>HTTP Status 500 - Internal Server
Error</h1><HR size="1" noshade><p><b>type</b> Exception
report</p><p><b>message</b> <u>Internal Server
Error</u></p><p><b>description</b> <u>The server encountered an
internal error (Internal Server Error) that prevented it from
fulfilling this request.</u></p><p><b>exception</b>
<pre>java.lang.NullPointerException
at
org.apache.cactus.server.AbstractWebTestCaller.doGetResults(AbstractWebTestCaller.java:196)
at
org.apache.cactus.server.AbstractWebTestController.dispatch87_handleRequest(AbstractWebTestController.java;org/apache/cactus/util/log/LogAspect.aj(1k):131)
...
It appears that one server thread is trying to get the results (thread
3) before the other (thread 4) has posted them. The times that the
tests work, I notice from the logs that the client sent the GET_RESULTS
request a few ms after the results were already posted:
From the server.log:
03:08:13,388 [HttpProcessor[8080][4]] DEBUG
s.server.AbstractWebTestCaller - Test result : [Test ok]
03:08:13,388 [HttpProcessor[8080][4]] DEBUG
s.server.AbstractWebTestCaller - Result saved in context scope
From the client.log:
03:08:13,424 [main] INFO httpclient.wire - >> "GET
/test/ServletRedirector?Cactus_Service=GET_RESULTS HTTP/1.1
"
03:08:13,425 [main] DEBUG httpclient.HttpMethod -
HttpMethodBase.writeRequestHeaders
I'm not doing anything too different than the examples. The only real
difference is that my Servlet inherits from a class in the Barracuda
framework, so I pass the request/response into a different method:
public void testDailySchedule()
{
try
{
OCSGateway servlet = new OCSGateway();
servlet.init(config);
servlet.handleDefault(request, response);
theLog.debug("CHECKING SESSION!!!!");
assertNotNull(session);
theLog.debug("Mode: " + session.getAttribute(OCS.MODE));
theLog.debug("Date: " + session.getAttribute(OCS.DATE));
theLog.debug("Schd: " + session.getAttribute(OCS.SCHEDULE));
theLog.debug("DONE WITH TEST!!!!");
}
catch (Exception e)
{
theLog.error("Unable to complete request:", e);
fail(e.getMessage());
}
}
I also tried "servlet.service(request, response)", but the results were
the same.
BTW, when I turn on full debug, it works more often. It took a looping
script 49 tries to finally get it to fail so I could include the full
debug at the top of the message.
I'm running the tests from Ant using Tomcat 4.1.12 with Cactus
1.3-1.4.1. Any ideas would be greatly appreciated!
Thank you,
Frank
RE: About Cactus and Quality Assurance
Posted by Vincent Massol <vm...@octo.com>.
Vikas,
Most of the weaknesses are mentioned on that page:
http://jakarta.apache.org/cactus/mockobjects.html
More specifically, I would say:
- it is not a generic framework in the sense that it needs specific
development for each API. If tomorrow you wanted to unit test OJB
components (or CORBA servant), cactus would not help you for example.
- setup is not easy if you're not familiar with container
setup/classloaders. However, this is an area that the Cactus team is
addressing right now. We are concentrating a lot on the Cactus front end
to make it seamless for end users: Maven plugin (already functional),
Eclipse plugin (work in progress), Jetty seamless integration, Cactus
application (not there yet).
- as a user that gives you one more strategy (in-container testing) to
choose from and thus you have define what strategy you want to use on a
given project: when are you going to use JUnit and Mock Objects, when
are you going to use Cactus. Are you going to use standalone HttpUnit or
not, etc. Hopefully, this is currently maturing and we see more and more
where each one fits in the puzzle. There are also books in progress
(including one I am writing) that should help.
But the best persons to answer your question are the other Cactus users!
Let's hear what they have to say! :-)
Cheers,
-Vincent
> -----Original Message-----
> From: Vikas Malla [mailto:malla6um@yahoo.co.in]
> Sent: 24 October 2002 19:03
> To: Cactus Users List
> Subject: RE: About Cactus and Quality Assurance
>
>
> Vincent,
>
> What do you think are the real weaknesses of cactus(if any... :-) )?
and
> how do you think they can be resolved ?
>
> Thanks.
> Vincent Massol <vm...@octo.com> wrote:
>
> > -----Original Message-----
> > From: Marco Barcella [mailto:barcella@appiancorp.com]
> > Sent: 24 October 2002 01:36
> > To: Cactus Users List
> > Subject: About Cactus and Quality Assurance
> >
> > Hi,
> > I would really like to ask the following two things:
> > 1) I am using cactus for unit testing. When should the testing start
> in
> > the process of developing some code (beginning, end), in order to
have
> the
> > best Quality Assurance in the shortest time? And also how to
integrate
> > the testing with the development? Any ideas or links would be
greatly
> > appreciated.
>
> The best is to do test-first development. Write your unit test first
> (before the code they test). Run the test: they will fail. Write the
> code. One by one the tests will turn from red to green.
>
> Why is it good?
> - because you get better tests (retrofitting tests to match code is
> always a best effort)
> - because you can then skip the detailed design phase as it is done in
> the unit tests. The unit tests also acts as design documentation.
> - because you will find that, as a result your code under tests is
> better written
>
> > 2) Considering to extend Cactus for functional testing, what, other
> than
> > HttpUnit,
> > could/should I integrate? What are the fundamental limits I will
> > encounter?
> > Thanks a lot,
> > Marco
>
> Cool! HttpUnit is already integrated but for checking results only. Do
> you mean you would like to extend Cactus to use it for sending
requests,
> too (as part of a Web conversation)?
>
> It is definitely possible and I would be happy to help you and offer
> support for that.
>
> I don't see any fundamental issue (especially as I am happy to let you
> modify Cactus internals to make it more pluggable!).
>
> Before choosing the tools to use for that you need to tell us what you
> have in mind for functional testing. What would be a typical scenario?
>
> Thanks
> -Vincent
>
> >
> >
> >
> > --
> > To unsubscribe, e-mail: > unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: > help@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
> Post your ad on Yahoo! India Autos.Check out the used Maruti, Fiat and
> Ford models on sale now.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: About Cactus and Quality Assurance
Posted by Vikas Malla <ma...@yahoo.co.in>.
Vincent,
What do you think are the real weaknesses of cactus(if any... :-) )? and how do you think they can be resolved ?
Thanks.
Vincent Massol <vm...@octo.com> wrote:
> -----Original Message-----
> From: Marco Barcella [mailto:barcella@appiancorp.com]
> Sent: 24 October 2002 01:36
> To: Cactus Users List
> Subject: About Cactus and Quality Assurance
>
> Hi,
> I would really like to ask the following two things:
> 1) I am using cactus for unit testing. When should the testing start
in
> the process of developing some code (beginning, end), in order to have
the
> best Quality Assurance in the shortest time? And also how to integrate
> the testing with the development? Any ideas or links would be greatly
> appreciated.
The best is to do test-first development. Write your unit test first
(before the code they test). Run the test: they will fail. Write the
code. One by one the tests will turn from red to green.
Why is it good?
- because you get better tests (retrofitting tests to match code is
always a best effort)
- because you can then skip the detailed design phase as it is done in
the unit tests. The unit tests also acts as design documentation.
- because you will find that, as a result your code under tests is
better written
> 2) Considering to extend Cactus for functional testing, what, other
than
> HttpUnit,
> could/should I integrate? What are the fundamental limits I will
> encounter?
> Thanks a lot,
> Marco
Cool! HttpUnit is already integrated but for checking results only. Do
you mean you would like to extend Cactus to use it for sending requests,
too (as part of a Web conversation)?
It is definitely possible and I would be happy to help you and offer
support for that.
I don't see any fundamental issue (especially as I am happy to let you
modify Cactus internals to make it more pluggable!).
Before choosing the tools to use for that you need to tell us what you
have in mind for functional testing. What would be a typical scenario?
Thanks
-Vincent
>
>
>
> --
> To unsubscribe, e-mail: > unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: > help@jakarta.apache.org>
--
To unsubscribe, e-mail:
For additional commands, e-mail:
Post your ad on Yahoo! India Autos.Check out the used Maruti, Fiat and Ford models on sale now.
RE: About Cactus and Quality Assurance
Posted by Marco Barcella <ba...@appiancorp.com>.
Thanks a lot,
I think your email was very helpful for me, I will be
even more specific:
1) Using Ant, and running 10 tests in one build.xml,
how can I complete all of them, even if the third one
(for example) fails. Right now, since I don't catch
the exceptions the build fails and the following tests
are not run.
2) I am thinking about this functional test:
I click on a link and then I submit a form, then
I go and click on a second link and check if the
result of that form submission is in the state and
is correct. I would like to do this in one single test
as the two requests (first and second link) are related.
What is the best way to do it and extend the concept to
multiple requests in series?
Thanks a lot,
Marco
<>-----Original Message-----
<>From: Vincent Massol [mailto:vmassol@octo.com]
<>Sent: Thursday, October 24, 2002 8:51 AM
<>To: 'Cactus Users List'
<>Subject: RE: About Cactus and Quality Assurance
<>
<>
<>
<>
<>> -----Original Message-----
<>> From: Marco Barcella [mailto:barcella@appiancorp.com]
<>> Sent: 24 October 2002 01:36
<>> To: Cactus Users List
<>> Subject: About Cactus and Quality Assurance
<>>
<>> Hi,
<>> I would really like to ask the following two things:
<>> 1) I am using cactus for unit testing. When should the testing start
<>in
<>> the process of developing some code (beginning, end), in order to have
<>the
<>> best Quality Assurance in the shortest time? And also how to integrate
<>> the testing with the development? Any ideas or links would be greatly
<>> appreciated.
<>
<>The best is to do test-first development. Write your unit test first
<>(before the code they test). Run the test: they will fail. Write the
<>code. One by one the tests will turn from red to green.
<>
<>Why is it good?
<>- because you get better tests (retrofitting tests to match code is
<>always a best effort)
<>- because you can then skip the detailed design phase as it is done in
<>the unit tests. The unit tests also acts as design documentation.
<>- because you will find that, as a result your code under tests is
<>better written
<>
<>> 2) Considering to extend Cactus for functional testing, what, other
<>than
<>> HttpUnit,
<>> could/should I integrate? What are the fundamental limits I will
<>> encounter?
<>> Thanks a lot,
<>> Marco
<>
<>Cool! HttpUnit is already integrated but for checking results only. Do
<>you mean you would like to extend Cactus to use it for sending requests,
<>too (as part of a Web conversation)?
<>
<>It is definitely possible and I would be happy to help you and offer
<>support for that.
<>
<>I don't see any fundamental issue (especially as I am happy to let you
<>modify Cactus internals to make it more pluggable!).
<>
<>Before choosing the tools to use for that you need to tell us what you
<>have in mind for functional testing. What would be a typical scenario?
<>
<>Thanks
<>-Vincent
<>
<>>
<>>
<>>
<>> --
<>> 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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: About Cactus and Quality Assurance
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Marco Barcella [mailto:barcella@appiancorp.com]
> Sent: 24 October 2002 01:36
> To: Cactus Users List
> Subject: About Cactus and Quality Assurance
>
> Hi,
> I would really like to ask the following two things:
> 1) I am using cactus for unit testing. When should the testing start
in
> the process of developing some code (beginning, end), in order to have
the
> best Quality Assurance in the shortest time? And also how to integrate
> the testing with the development? Any ideas or links would be greatly
> appreciated.
The best is to do test-first development. Write your unit test first
(before the code they test). Run the test: they will fail. Write the
code. One by one the tests will turn from red to green.
Why is it good?
- because you get better tests (retrofitting tests to match code is
always a best effort)
- because you can then skip the detailed design phase as it is done in
the unit tests. The unit tests also acts as design documentation.
- because you will find that, as a result your code under tests is
better written
> 2) Considering to extend Cactus for functional testing, what, other
than
> HttpUnit,
> could/should I integrate? What are the fundamental limits I will
> encounter?
> Thanks a lot,
> Marco
Cool! HttpUnit is already integrated but for checking results only. Do
you mean you would like to extend Cactus to use it for sending requests,
too (as part of a Web conversation)?
It is definitely possible and I would be happy to help you and offer
support for that.
I don't see any fundamental issue (especially as I am happy to let you
modify Cactus internals to make it more pluggable!).
Before choosing the tools to use for that you need to tell us what you
have in mind for functional testing. What would be a typical scenario?
Thanks
-Vincent
>
>
>
> --
> 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>
About Cactus and Quality Assurance
Posted by Marco Barcella <ba...@appiancorp.com>.
Hi,
I would really like to ask the following two things:
1) I am using cactus for unit testing. When should the testing start in
the process of developing some code (beginning, end), in order to have the
best Quality Assurance in the shortest time? And also how to integrate
the testing with the development? Any ideas or links would be greatly
appreciated.
2) Considering to extend Cactus for functional testing, what, other than
HttpUnit,
could/should I integrate? What are the fundamental limits I will encounter?
Thanks a lot,
Marco
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Apparent race condition in Cactus?
Posted by Frank Baxter <fr...@baxres.org>.
It does appear that Ant runs the tests concurrently. Vincent, I tossed
your test case in with mine and it worked fine. One thing I did notice
is that your result completed messages were interspersed with the
results from my test suite. When I ran them together, both ran fine. I
also ran your test case by itself, 50 times from a command line loop and
it worked great.
As another test, I looped the TestSampleServlet test case from the
Cactus distribution. It ran 150 times without a problem before I
finally killed it.
I then tried isolating my test case by itself - just one test case with
a single test function, and it still failed. Last month I moved our
servlet from Enhydra to Tomcat, but we still include some of the enhydra
jar files (we use a portion of the server called DODS). That, and the
fact that it is a fairly large servlet is about the only differences I
can think of right now.
I thought that possibly this was just slowing things down enough to
cause the race condition to trigger. So I added a sleep in the doGet
method of the SampleServlet. This still didn't make a difference, and
the test ran many times without an error.
The move to Tomcat and my experience with Cactus are all fairly new,
it's possible I made a mistake somewhere during the integration.
However, the fact that it works 50% of the time with debug off, and 95%
of the time when debug is on, really leaves me at a loss.
Vincent and Nick, I really appreciate your help. I'm going to continue
to play with this, but if you have any more ideas, let me know.
Thanks very much,
Frank
Nicholas Lesiecki wrote:
>Actually, "concurrent" tests can happen easily with Ant's junit task. Why?
>Under JDK 1.4 you must run with fork="true". Fork starts a new JVM for each
>test case. So you can have multiple JVMs running concurrently. At least I
>think so... That may be a misdiagnosis of how I'm getting concurrent
>behavior, but its my best guess.
>
>Anyway, the upshot is that I'm also getting concurrency errors--and doing
>"manual synchronization" (wait()'ing in setUp until another instance of the
>same test case removes a semaphore from application scope) solves them.
>
>So I'm not sure whether ant needs fixing, or Cactus. This issue with Cactus
>dates back to 1.1 (when I first pointed it out). Vincent correctly pointed
>out that the error would be rare. Sure enough it was a year or so before I
>encountered it. I don't think it's been reported by anyone but you Frank.
>
>Are you trying to run a concurrent test? If so, what's the proposed
>utility/benefit? Your answer may determine which code needs patching.
>
>Cheers,
>nick
>
>
>
>>-----Original Message-----
>>From: Vincent Massol [mailto:vmassol@octo.com]
>>Sent: Monday, October 21, 2002 2:47 PM
>>To: 'Cactus Users List'
>>Cc: frank@baxres.org
>>Subject: RE: Apparent race condition in Cactus?
>>
>>
>>Hi Frank,
>>
>>Interesting problem... and a very thorough report! :-)
>>
>>Normally this should not happen as internally Cactus reads the whole
>>servlet response *before* calling again the server side to get the test
>>result. This, in order to prevent such a race condition ...
>>
>>There is one limitation in the current Cactus version: only one test can
>>be run at a time. You're not running concurrent tests, are you?
>>
>>The problem with these kinds of errors is that it is difficult to
>>reproduce.
>>
>>I have written a new test case (see attached file) that I have tried
>>running from 100 times to 500 times and it never failed. I am on Windows
>>XP with Tomcat 4.1.12.
>>
>>As you can see from the test case, there are several kind of tests,
>>including some prohibited creation of threads...
>>
>>Can you try to run it on your side and tell me if you get some errors?
>>
>>Thanks
>>-Vincent
>>
>>
>>
>>>-----Original Message-----
>>>From: Frank Baxter [mailto:frank@baxres.org]
>>>Sent: 21 October 2002 20:16
>>>To: cactus-user@jakarta.apache.org
>>>Subject: Apparent race condition in Cactus?
>>>
>>>I'm using Cactus and I'm running into a strange problem. About half
>>>
>>>
>>the
>>
>>
>>>time, my tests fail, and it appears to be caused by GET_RESULT being
>>>invoked before the results are saved to the context.
>>>
>>> From the server log:
>>>
>>> ...
>>> 02:39:27,096 [HttpProcessor[8080][3]] DEBUG
>>> ache.cactus.ServiceEnumeration - <equals([GET_RESULTS])
>>> 02:39:27,096 [HttpProcessor[8080][3]] DEBUG
>>> ache.cactus.ServiceEnumeration - >equals = [true]02:39:27,096
>>> [HttpProcessor[8080][3]] DEBUG s.server.AbstractWebTestCaller -
>>> Test Result = [null]
>>> 02:39:27,130 [HttpProcessor[8080][4]] DEBUG
>>> s.server.AbstractWebTestCaller - Test result : [Test ok]
>>> 02:39:27,131 [HttpProcessor[8080][4]] DEBUG
>>> s.server.AbstractWebTestCaller - Result saved in context scope
>>> ...
>>>
>>>
>>> From the client log:
>>>
>>> ...
>>> 02:39:27,091 [main] DEBUG httpclient.HttpConnection -
>>> HttpConnection.write(byte[])
>>> 02:39:27,091 [main] INFO httpclient.wire - >>
>>>
>>>
>>"GET
>>
>>
>>> /test/ServletRedirector?Cactus_Service=GET_RESULTS HTTP/1.1
>>> "
>>> 02:39:27,091 [main] DEBUG httpclient.HttpMethod -
>>> HttpMethodBase.writeRequestHeaders(HttpState,HttpConnection)
>>> 02:39:27,091 [main] DEBUG httpclient.HttpConnection -
>>> HttpConnection.write(byte[])
>>> 02:39:27,091 [main] INFO httpclient.wire - >>
>>> "Host: localhost
>>> "
>>> 02:39:27,092 [main] DEBUG httpclient.HttpConnection -
>>> HttpConnection.write(byte[])
>>> 02:39:27,092 [main] INFO httpclient.wire - >>
>>> "User-Agent: Jakarta HTTP Client/2.0.0a1
>>> "
>>> 02:39:27,092 [main] DEBUG httpclient.HttpConnection -
>>> HttpConnection.write(byte[])
>>> 02:39:27,092 [main] INFO httpclient.wire - >>
>>> "Content-type: application/x-www-form-urlencoded
>>> "
>>> 02:39:27,092 [main] DEBUG httpclient.HttpConnection -
>>> HttpConnection.writeLine()
>>> 02:39:27,092 [main] INFO httpclient.wire - >>
>>>
>>>
>>\r\n
>>
>>
>>> 02:39:27,108 [main] DEBUG httpclient.HttpMethod -
>>> HttpMethodBase.readResponse(HttpState,HttpConnection)
>>> 02:39:27,108 [main] DEBUG httpclient.HttpMethod -
>>> HttpMethodBase.readStatusLine(HttpState,HttpConnection)
>>> 02:39:27,108 [main] DEBUG httpclient.HttpConnection -
>>> HttpConnection.readLine()
>>> 02:39:27,109 [main] INFO httpclient.wire - <<
>>> "HTTP/1.1 500 Internal Server Error" [\r\n]
>>>
>>> ...
>>>
>>> 02:39:27,115 [main] INFO httpclient.wire - <<
>>> "<html><head><title>Apache Tomcat/4.1.12 - Error
>>> report</title><STYLE><!--H1{font-family :
>>> sans-serif,Arial,Tahoma;color : white;background-color : #0086b2;}
>>> H3{font-family : sans-serif,Arial,Tahoma;color :
>>> white;background-color : #0086b2;} BODY{font-family :
>>> sans-serif,Arial,Tahoma;color : black;background-color : white;}
>>> B{color : white;background-color : #0086b2;} HR{color : #0086b2;}
>>> --></STYLE> </head><body><h1>HTTP Status 500 - Internal Server
>>> Error</h1><HR size="1" noshade><p><b>type</b> Exception
>>> report</p><p><b>message</b> <u>Internal Server
>>> Error</u></p><p><b>description</b> <u>The server encountered an
>>> internal error (Internal Server Error) that prevented it from
>>> fulfilling this request.</u></p><p><b>exception</b>
>>> <pre>java.lang.NullPointerException
>>> at
>>>
>>>
>>>
>>>
>>org.apache.cactus.server.AbstractWebTestCaller.doGetResults(AbstractWebT
>>es
>>
>>
>>>tCaller.java:196)
>>> at
>>>
>>>
>>>
>>>
>>org.apache.cactus.server.AbstractWebTestController.dispatch87_handleRequ
>>es
>>
>>
>>t(AbstractWebTestController.java;org/apache/cactus/util/log/LogAspect.aj
>>(1
>>
>>
>>>k):131)
>>>
>>> ...
>>>
>>>It appears that one server thread is trying to get the results (thread
>>>3) before the other (thread 4) has posted them. The times that the
>>>tests work, I notice from the logs that the client sent the
>>>
>>>
>>GET_RESULTS
>>
>>
>>>request a few ms after the results were already posted:
>>>
>>> From the server.log:
>>>
>>> 03:08:13,388 [HttpProcessor[8080][4]] DEBUG
>>> s.server.AbstractWebTestCaller - Test result : [Test ok]
>>> 03:08:13,388 [HttpProcessor[8080][4]] DEBUG
>>> s.server.AbstractWebTestCaller - Result saved in context scope
>>>
>>> From the client.log:
>>>
>>> 03:08:13,424 [main] INFO httpclient.wire - >>
>>>
>>>
>>"GET
>>
>>
>>> /test/ServletRedirector?Cactus_Service=GET_RESULTS HTTP/1.1
>>> "
>>> 03:08:13,425 [main] DEBUG httpclient.HttpMethod -
>>> HttpMethodBase.writeRequestHeaders
>>>
>>>
>>>I'm not doing anything too different than the examples. The only real
>>>difference is that my Servlet inherits from a class in the Barracuda
>>>framework, so I pass the request/response into a different method:
>>>
>>> public void testDailySchedule()
>>> {
>>> try
>>> {
>>> OCSGateway servlet = new OCSGateway();
>>>
>>> servlet.init(config);
>>> servlet.handleDefault(request, response);
>>>
>>> theLog.debug("CHECKING SESSION!!!!");
>>> assertNotNull(session);
>>> theLog.debug("Mode: " + session.getAttribute(OCS.MODE));
>>> theLog.debug("Date: " + session.getAttribute(OCS.DATE));
>>> theLog.debug("Schd: " + session.getAttribute(OCS.SCHEDULE));
>>>
>>> theLog.debug("DONE WITH TEST!!!!");
>>> }
>>> catch (Exception e)
>>> {
>>> theLog.error("Unable to complete request:", e);
>>> fail(e.getMessage());
>>> }
>>> }
>>>
>>>I also tried "servlet.service(request, response)", but the results
>>>
>>>
>>were
>>
>>
>>>the same.
>>>
>>>BTW, when I turn on full debug, it works more often. It took a
>>>
>>>
>>looping
>>
>>
>>>script 49 tries to finally get it to fail so I could include the full
>>>debug at the top of the message.
>>>
>>>I'm running the tests from Ant using Tomcat 4.1.12 with Cactus
>>>1.3-1.4.1. Any ideas would be greatly appreciated!
>>>
>>>Thank you,
>>>
>>>Frank
>>>
>>>
>>
>>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
RE: Apparent race condition in Cactus?
Posted by Nicholas Lesiecki <ni...@eblox.com>.
Actually, "concurrent" tests can happen easily with Ant's junit task. Why?
Under JDK 1.4 you must run with fork="true". Fork starts a new JVM for each
test case. So you can have multiple JVMs running concurrently. At least I
think so... That may be a misdiagnosis of how I'm getting concurrent
behavior, but its my best guess.
Anyway, the upshot is that I'm also getting concurrency errors--and doing
"manual synchronization" (wait()'ing in setUp until another instance of the
same test case removes a semaphore from application scope) solves them.
So I'm not sure whether ant needs fixing, or Cactus. This issue with Cactus
dates back to 1.1 (when I first pointed it out). Vincent correctly pointed
out that the error would be rare. Sure enough it was a year or so before I
encountered it. I don't think it's been reported by anyone but you Frank.
Are you trying to run a concurrent test? If so, what's the proposed
utility/benefit? Your answer may determine which code needs patching.
Cheers,
nick
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@octo.com]
> Sent: Monday, October 21, 2002 2:47 PM
> To: 'Cactus Users List'
> Cc: frank@baxres.org
> Subject: RE: Apparent race condition in Cactus?
>
>
> Hi Frank,
>
> Interesting problem... and a very thorough report! :-)
>
> Normally this should not happen as internally Cactus reads the whole
> servlet response *before* calling again the server side to get the test
> result. This, in order to prevent such a race condition ...
>
> There is one limitation in the current Cactus version: only one test can
> be run at a time. You're not running concurrent tests, are you?
>
> The problem with these kinds of errors is that it is difficult to
> reproduce.
>
> I have written a new test case (see attached file) that I have tried
> running from 100 times to 500 times and it never failed. I am on Windows
> XP with Tomcat 4.1.12.
>
> As you can see from the test case, there are several kind of tests,
> including some prohibited creation of threads...
>
> Can you try to run it on your side and tell me if you get some errors?
>
> Thanks
> -Vincent
>
> > -----Original Message-----
> > From: Frank Baxter [mailto:frank@baxres.org]
> > Sent: 21 October 2002 20:16
> > To: cactus-user@jakarta.apache.org
> > Subject: Apparent race condition in Cactus?
> >
> > I'm using Cactus and I'm running into a strange problem. About half
> the
> > time, my tests fail, and it appears to be caused by GET_RESULT being
> > invoked before the results are saved to the context.
> >
> > From the server log:
> >
> > ...
> > 02:39:27,096 [HttpProcessor[8080][3]] DEBUG
> > ache.cactus.ServiceEnumeration - <equals([GET_RESULTS])
> > 02:39:27,096 [HttpProcessor[8080][3]] DEBUG
> > ache.cactus.ServiceEnumeration - >equals = [true]02:39:27,096
> > [HttpProcessor[8080][3]] DEBUG s.server.AbstractWebTestCaller -
> > Test Result = [null]
> > 02:39:27,130 [HttpProcessor[8080][4]] DEBUG
> > s.server.AbstractWebTestCaller - Test result : [Test ok]
> > 02:39:27,131 [HttpProcessor[8080][4]] DEBUG
> > s.server.AbstractWebTestCaller - Result saved in context scope
> > ...
> >
> >
> > From the client log:
> >
> > ...
> > 02:39:27,091 [main] DEBUG httpclient.HttpConnection -
> > HttpConnection.write(byte[])
> > 02:39:27,091 [main] INFO httpclient.wire - >>
> "GET
> > /test/ServletRedirector?Cactus_Service=GET_RESULTS HTTP/1.1
> > "
> > 02:39:27,091 [main] DEBUG httpclient.HttpMethod -
> > HttpMethodBase.writeRequestHeaders(HttpState,HttpConnection)
> > 02:39:27,091 [main] DEBUG httpclient.HttpConnection -
> > HttpConnection.write(byte[])
> > 02:39:27,091 [main] INFO httpclient.wire - >>
> > "Host: localhost
> > "
> > 02:39:27,092 [main] DEBUG httpclient.HttpConnection -
> > HttpConnection.write(byte[])
> > 02:39:27,092 [main] INFO httpclient.wire - >>
> > "User-Agent: Jakarta HTTP Client/2.0.0a1
> > "
> > 02:39:27,092 [main] DEBUG httpclient.HttpConnection -
> > HttpConnection.write(byte[])
> > 02:39:27,092 [main] INFO httpclient.wire - >>
> > "Content-type: application/x-www-form-urlencoded
> > "
> > 02:39:27,092 [main] DEBUG httpclient.HttpConnection -
> > HttpConnection.writeLine()
> > 02:39:27,092 [main] INFO httpclient.wire - >>
> \r\n
> > 02:39:27,108 [main] DEBUG httpclient.HttpMethod -
> > HttpMethodBase.readResponse(HttpState,HttpConnection)
> > 02:39:27,108 [main] DEBUG httpclient.HttpMethod -
> > HttpMethodBase.readStatusLine(HttpState,HttpConnection)
> > 02:39:27,108 [main] DEBUG httpclient.HttpConnection -
> > HttpConnection.readLine()
> > 02:39:27,109 [main] INFO httpclient.wire - <<
> > "HTTP/1.1 500 Internal Server Error" [\r\n]
> >
> > ...
> >
> > 02:39:27,115 [main] INFO httpclient.wire - <<
> > "<html><head><title>Apache Tomcat/4.1.12 - Error
> > report</title><STYLE><!--H1{font-family :
> > sans-serif,Arial,Tahoma;color : white;background-color : #0086b2;}
> > H3{font-family : sans-serif,Arial,Tahoma;color :
> > white;background-color : #0086b2;} BODY{font-family :
> > sans-serif,Arial,Tahoma;color : black;background-color : white;}
> > B{color : white;background-color : #0086b2;} HR{color : #0086b2;}
> > --></STYLE> </head><body><h1>HTTP Status 500 - Internal Server
> > Error</h1><HR size="1" noshade><p><b>type</b> Exception
> > report</p><p><b>message</b> <u>Internal Server
> > Error</u></p><p><b>description</b> <u>The server encountered an
> > internal error (Internal Server Error) that prevented it from
> > fulfilling this request.</u></p><p><b>exception</b>
> > <pre>java.lang.NullPointerException
> > at
> >
> >
> org.apache.cactus.server.AbstractWebTestCaller.doGetResults(AbstractWebT
> es
> > tCaller.java:196)
> > at
> >
> >
> org.apache.cactus.server.AbstractWebTestController.dispatch87_handleRequ
> es
> >
> t(AbstractWebTestController.java;org/apache/cactus/util/log/LogAspect.aj
> (1
> > k):131)
> >
> > ...
> >
> > It appears that one server thread is trying to get the results (thread
> > 3) before the other (thread 4) has posted them. The times that the
> > tests work, I notice from the logs that the client sent the
> GET_RESULTS
> > request a few ms after the results were already posted:
> >
> > From the server.log:
> >
> > 03:08:13,388 [HttpProcessor[8080][4]] DEBUG
> > s.server.AbstractWebTestCaller - Test result : [Test ok]
> > 03:08:13,388 [HttpProcessor[8080][4]] DEBUG
> > s.server.AbstractWebTestCaller - Result saved in context scope
> >
> > From the client.log:
> >
> > 03:08:13,424 [main] INFO httpclient.wire - >>
> "GET
> > /test/ServletRedirector?Cactus_Service=GET_RESULTS HTTP/1.1
> > "
> > 03:08:13,425 [main] DEBUG httpclient.HttpMethod -
> > HttpMethodBase.writeRequestHeaders
> >
> >
> > I'm not doing anything too different than the examples. The only real
> > difference is that my Servlet inherits from a class in the Barracuda
> > framework, so I pass the request/response into a different method:
> >
> > public void testDailySchedule()
> > {
> > try
> > {
> > OCSGateway servlet = new OCSGateway();
> >
> > servlet.init(config);
> > servlet.handleDefault(request, response);
> >
> > theLog.debug("CHECKING SESSION!!!!");
> > assertNotNull(session);
> > theLog.debug("Mode: " + session.getAttribute(OCS.MODE));
> > theLog.debug("Date: " + session.getAttribute(OCS.DATE));
> > theLog.debug("Schd: " + session.getAttribute(OCS.SCHEDULE));
> >
> > theLog.debug("DONE WITH TEST!!!!");
> > }
> > catch (Exception e)
> > {
> > theLog.error("Unable to complete request:", e);
> > fail(e.getMessage());
> > }
> > }
> >
> > I also tried "servlet.service(request, response)", but the results
> were
> > the same.
> >
> > BTW, when I turn on full debug, it works more often. It took a
> looping
> > script 49 tries to finally get it to fail so I could include the full
> > debug at the top of the message.
> >
> > I'm running the tests from Ant using Tomcat 4.1.12 with Cactus
> > 1.3-1.4.1. Any ideas would be greatly appreciated!
> >
> > Thank you,
> >
> > Frank
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Apparent race condition in Cactus?
Posted by Vincent Massol <vm...@octo.com>.
Hi Frank,
Interesting problem... and a very thorough report! :-)
Normally this should not happen as internally Cactus reads the whole
servlet response *before* calling again the server side to get the test
result. This, in order to prevent such a race condition ...
There is one limitation in the current Cactus version: only one test can
be run at a time. You're not running concurrent tests, are you?
The problem with these kinds of errors is that it is difficult to
reproduce.
I have written a new test case (see attached file) that I have tried
running from 100 times to 500 times and it never failed. I am on Windows
XP with Tomcat 4.1.12.
As you can see from the test case, there are several kind of tests,
including some prohibited creation of threads...
Can you try to run it on your side and tell me if you get some errors?
Thanks
-Vincent
> -----Original Message-----
> From: Frank Baxter [mailto:frank@baxres.org]
> Sent: 21 October 2002 20:16
> To: cactus-user@jakarta.apache.org
> Subject: Apparent race condition in Cactus?
>
> I'm using Cactus and I'm running into a strange problem. About half
the
> time, my tests fail, and it appears to be caused by GET_RESULT being
> invoked before the results are saved to the context.
>
> From the server log:
>
> ...
> 02:39:27,096 [HttpProcessor[8080][3]] DEBUG
> ache.cactus.ServiceEnumeration - <equals([GET_RESULTS])
> 02:39:27,096 [HttpProcessor[8080][3]] DEBUG
> ache.cactus.ServiceEnumeration - >equals = [true]02:39:27,096
> [HttpProcessor[8080][3]] DEBUG s.server.AbstractWebTestCaller -
> Test Result = [null]
> 02:39:27,130 [HttpProcessor[8080][4]] DEBUG
> s.server.AbstractWebTestCaller - Test result : [Test ok]
> 02:39:27,131 [HttpProcessor[8080][4]] DEBUG
> s.server.AbstractWebTestCaller - Result saved in context scope
> ...
>
>
> From the client log:
>
> ...
> 02:39:27,091 [main] DEBUG httpclient.HttpConnection -
> HttpConnection.write(byte[])
> 02:39:27,091 [main] INFO httpclient.wire - >>
"GET
> /test/ServletRedirector?Cactus_Service=GET_RESULTS HTTP/1.1
> "
> 02:39:27,091 [main] DEBUG httpclient.HttpMethod -
> HttpMethodBase.writeRequestHeaders(HttpState,HttpConnection)
> 02:39:27,091 [main] DEBUG httpclient.HttpConnection -
> HttpConnection.write(byte[])
> 02:39:27,091 [main] INFO httpclient.wire - >>
> "Host: localhost
> "
> 02:39:27,092 [main] DEBUG httpclient.HttpConnection -
> HttpConnection.write(byte[])
> 02:39:27,092 [main] INFO httpclient.wire - >>
> "User-Agent: Jakarta HTTP Client/2.0.0a1
> "
> 02:39:27,092 [main] DEBUG httpclient.HttpConnection -
> HttpConnection.write(byte[])
> 02:39:27,092 [main] INFO httpclient.wire - >>
> "Content-type: application/x-www-form-urlencoded
> "
> 02:39:27,092 [main] DEBUG httpclient.HttpConnection -
> HttpConnection.writeLine()
> 02:39:27,092 [main] INFO httpclient.wire - >>
\r\n
> 02:39:27,108 [main] DEBUG httpclient.HttpMethod -
> HttpMethodBase.readResponse(HttpState,HttpConnection)
> 02:39:27,108 [main] DEBUG httpclient.HttpMethod -
> HttpMethodBase.readStatusLine(HttpState,HttpConnection)
> 02:39:27,108 [main] DEBUG httpclient.HttpConnection -
> HttpConnection.readLine()
> 02:39:27,109 [main] INFO httpclient.wire - <<
> "HTTP/1.1 500 Internal Server Error" [\r\n]
>
> ...
>
> 02:39:27,115 [main] INFO httpclient.wire - <<
> "<html><head><title>Apache Tomcat/4.1.12 - Error
> report</title><STYLE><!--H1{font-family :
> sans-serif,Arial,Tahoma;color : white;background-color : #0086b2;}
> H3{font-family : sans-serif,Arial,Tahoma;color :
> white;background-color : #0086b2;} BODY{font-family :
> sans-serif,Arial,Tahoma;color : black;background-color : white;}
> B{color : white;background-color : #0086b2;} HR{color : #0086b2;}
> --></STYLE> </head><body><h1>HTTP Status 500 - Internal Server
> Error</h1><HR size="1" noshade><p><b>type</b> Exception
> report</p><p><b>message</b> <u>Internal Server
> Error</u></p><p><b>description</b> <u>The server encountered an
> internal error (Internal Server Error) that prevented it from
> fulfilling this request.</u></p><p><b>exception</b>
> <pre>java.lang.NullPointerException
> at
>
>
org.apache.cactus.server.AbstractWebTestCaller.doGetResults(AbstractWebT
es
> tCaller.java:196)
> at
>
>
org.apache.cactus.server.AbstractWebTestController.dispatch87_handleRequ
es
>
t(AbstractWebTestController.java;org/apache/cactus/util/log/LogAspect.aj
(1
> k):131)
>
> ...
>
> It appears that one server thread is trying to get the results (thread
> 3) before the other (thread 4) has posted them. The times that the
> tests work, I notice from the logs that the client sent the
GET_RESULTS
> request a few ms after the results were already posted:
>
> From the server.log:
>
> 03:08:13,388 [HttpProcessor[8080][4]] DEBUG
> s.server.AbstractWebTestCaller - Test result : [Test ok]
> 03:08:13,388 [HttpProcessor[8080][4]] DEBUG
> s.server.AbstractWebTestCaller - Result saved in context scope
>
> From the client.log:
>
> 03:08:13,424 [main] INFO httpclient.wire - >>
"GET
> /test/ServletRedirector?Cactus_Service=GET_RESULTS HTTP/1.1
> "
> 03:08:13,425 [main] DEBUG httpclient.HttpMethod -
> HttpMethodBase.writeRequestHeaders
>
>
> I'm not doing anything too different than the examples. The only real
> difference is that my Servlet inherits from a class in the Barracuda
> framework, so I pass the request/response into a different method:
>
> public void testDailySchedule()
> {
> try
> {
> OCSGateway servlet = new OCSGateway();
>
> servlet.init(config);
> servlet.handleDefault(request, response);
>
> theLog.debug("CHECKING SESSION!!!!");
> assertNotNull(session);
> theLog.debug("Mode: " + session.getAttribute(OCS.MODE));
> theLog.debug("Date: " + session.getAttribute(OCS.DATE));
> theLog.debug("Schd: " + session.getAttribute(OCS.SCHEDULE));
>
> theLog.debug("DONE WITH TEST!!!!");
> }
> catch (Exception e)
> {
> theLog.error("Unable to complete request:", e);
> fail(e.getMessage());
> }
> }
>
> I also tried "servlet.service(request, response)", but the results
were
> the same.
>
> BTW, when I turn on full debug, it works more often. It took a
looping
> script 49 tries to finally get it to fail so I could include the full
> debug at the top of the message.
>
> I'm running the tests from Ant using Tomcat 4.1.12 with Cactus
> 1.3-1.4.1. Any ideas would be greatly appreciated!
>
> Thank you,
>
> Frank