You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by Nicholas Lesiecki <nd...@yahoo.com> on 2003/11/02 17:39:39 UTC
Re: Use HTTP header instead of unique ID?
OK, so we have several tensions we need to resolve. Our basic requirements
are:
1) The execution of a servlet-based test case must be allowed to pass a text
response back to the client for inspection and verification.
2) The test case must be able to retrieve its results from the server,
including a verbose exception stack-trace.
Some auxiliary concerns that we want to satisfy:
A) Cactus should not require the creation of a session to do its job. (I
seem to remember that someone had a server which artificially limited
session creation.)
B) handling load-balancers gracefully
C) handling concurrent test execution and preventing bugs caused by stale
test results left in a commonly-scoped application variable
The solutions proposed so far are:
I) Store the test results in the session
II) Return the test results in a header
III) Store the test results in a uniquely keyed application scoped variable
I've been working on Solution III, but passing back the unique key in a
header.(*) It's OK, but somewhat complicated. It also does not solve the
load balancing problem.
Solution I seems intuitive since sessions are the standard way of
correlating information across client requests. This also solves the problem
of load balancing if we omit any load balancers that do not guarantee that
multiple requests from the same client will hit the same session. (This
seems like a safe omission to me). However, II requires the creation of a
session, which violates auxiliary requirement A.
II has the nice feature of requiring only one request/response cycle and
thereby eliminating the (somewhat confusing) two-request model. It solves
the load balancer problem and the no-session problem. The only issue is that
it may disturb the ability of some users to fiddle with the response during
their test. (We could not commit the headers to the client until we had
generated the test result). I have no feeling for how disruptive this would
be to users. Certainly it would involve profound changes to Cactus, but ones
that would leave the code cleaner.
I think II is my favorite if we can work around the problem of committing
the response early. Perhaps a poll of the users list might help us gather
this information?
Cheers,
Nick
* I thought this might lead to trouble with the headers already being
committed, but I suppose if I added the cactus header before the test got to
it...
On 10/19/03 7:14 AM, "Christopher Lenz" <cm...@gmx.de> wrote:
> Vincent Massol wrote:
>>> -----Original Message-----
>>> From: Christopher Lenz [mailto:cmlenz@gmx.de]
>>> Sent: 18 October 2003 21:55
>>> To: Cactus Developers List
>>> Subject: Re: Use HTTP header instead of unique ID?
>>>
>>> Vincent Massol wrote:
>>>> Nick has started a unique id generator to support execution of
>>>> concurrent cactus tests. However, there might be a better solution:
>>>> return the test result in an HTTP header in the same HTTP response.
>>>>
>>>> There might be issues with this solution. I think that I had some
>> doubts
>>>> about this in the past but I can't recall any good reason right
>> now...
>>>> :-)
>>>
>>> How would we pass an exception thrown on the server side back to the
>>> client? That's really the only reason I see why we have two requests
>>> currently.
>>
>> What is the problem of passing the exception in a header? It is a
>> string.
>
> But the exception includes a stack trace, which is pretty long, and
> includes newlines that need to be escaped. I.e. it's not something you'd
> put in a header normally.
>
> More importantly, there's the problem of *when* the exception header is
> added to the response. If the error occurs when the response headers
> have already been committed, we have a serious problem, because there's
> no way to pass the exception back to the client.
>
>>>> If it works, it will solve several issues:
>>>> - prevent 2 HTTP requests which will be faster
>
> BTW, our primary speed problem is that these 2 requests are also 2
> connections. The keepalive plan-item should help a lot here.
>
>>>> - support use cases where people using cactus have a load balancer
>> (the
>>>> second request to get the test result is balanced on another server)
>>>
>>> If two requests are made with the same session, they should get
>>> processed by the same server (a spec requirement IIRC). So we could
>> also
>>> maintain the session (if created) between the two requests.
>>
>> That would only work with sticky load balancers but we don't want to
>> assume anything.
>
> AFAIK that's a basic assumption of the servlet spec.
>
> Given the requirement that we don't want to require the creation of
> sessions, and assuming that it is impossible to switch to a
> single-request model (see above): wouldn't the problem with clustering
> also be solved by assigning a unique ID with every test? I think it would.
>
> -chris
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: Running cactus test from web-browser with custom parameters
Posted by Ivan Kaschenko <om...@tut.by>.
Hi Vincent,
I've been thinking of an approach of using system properties as configurable
parameters. This is hardly regular because of low parameter localization. I
mean that if you want use some system properties as user name or passsword -
there're no problems! There're global parameters and must be accessible from
anywhere by any aplication. But in the example I'd given I showed how
_local_ parameters should be specified. The only test knows about what
optional parameters may be passed!
Let me clarify an example (my recent one is rather abstract, I think).
Imagine, you should write Cactus test to test some action from
web-page.There's no matter how it is mapped between each other. Just think
it's done. Let such test be full text search over database by a keyword
specified by user on the web-page. If you hardcode this keyword within a
test via
req.addParameter("keywords", "cactus");
.. it will not be configurable. So, you test is strongly _deterministic_.
Whenever you launch it, it will bring the same result. As for automated
testing of whole application, it is acceptable. But I try to promote the
idea of customizing tests in order to increase their flexibility.
Now imagine you may launch test not only by default (internally declared)
keyword but also by keyword you specify in the address bar of your browser
(or in another way). At least, it excludes the need to recompile and
redeploy the entire application. If keyword is absent, default is used.
Cactus faq contains a question of how possible to parametrize tests. Among
the answers there's also (apart from System.getProperty()) utilization of
cactus.properties file where optional parameters are specified. I reckon
that such globalization of local parameters is irregular.
> An interesting idea. You have to remember that calling cactus tests from
> a web browser is just one way of doing it. There are lots of other front
> ends: Ant, Maven, Eclipse, manually from command line, etc. Thus the
> solution must be able to work for all these situations.
There's a redirection occurs after test lauhcned. The idea is to transfer
all the custom parameters to destination servlet without a modification.
Currently they are lost. To simplify implementation, raw query string (which
is passed to TestRunner and by which test is lauhched) is enough to pass to
test request in destination servlet.
What do you think about test customization now?
Greetings,
Ivan.
----- Original Message -----
From: "Vincent Massol" <vm...@pivolis.com>
To: "'Cactus Developers List'" <ca...@jakarta.apache.org>
Sent: Monday, November 10, 2003 12:02 PM
Subject: RE: Running cactus test from web-browser with custom parameters
> Hi Ivan,
>
> An interesting idea. You have to remember that calling cactus tests from
> a web browser is just one way of doing it. There are lots of other front
> ends: Ant, Maven, Eclipse, manually from command line, etc. Thus the
> solution must be able to work for all these situations.
>
> ATM, there are already ways to pass parameters to a cactus test case.
> Here's how you can currently do it:
>
> public void beginXXXX(WebRequest req)
> {
> req.addParameter("param1", System.getProperty("param1"));
> [...]
> }
>
> Thus, I believe the best solution would be to modify the Cactus
> ServletTestRunner class so that it adds all the HTTP parameters as
> System properties. That will allow your test case to retrieve these
> properties as shown above.
>
> It has the advantage that you'll also be able to use the other front
> ends for your test and it'll still work (provided you also configure the
> other front ends to pass these parameters).
>
> Would that do it for you?
>
> Thanks
> -Vincent
>
> > -----Original Message-----
> > From: Ivan Kaschenko [mailto:om600@tut.by]
> > Sent: 10 November 2003 09:56
> > To: Cactus Developers List
> > Subject: Running cactus test from web-browser with custom parameters
> >
> > Hi, guys!
> >
> > I have a question but couldn't find a proper location to place it in.
> > Would
> > you be so kind to skim it though and, maybe, give me some links where
> I
> > can
> > get information I need?
> >
> > As specified in Cactus documentation, running test from web-browser
> must
> > be
> > performed as follows:
> >
> > http://server:port/webapp/ServletTestRunner?suite=testcasename
> >
> > It would be extremely convinient to parametrize tests from such
> requests.
> > I
> > mean adding parameters list in a way as http GET request syntax
> specifies:
> >
> >
> http://server:port/webapp/ServletTestRunner?suite=testcasename¶m1=va
> lu
> > e1
> > ¶m2=value2 etc.
> >
> > Optional parameters are custom ones and must be passes to request
> (within
> > test) without any modification. They must be accessible via
> > WebRequest.getParameter(String) call. Default value must be provided.
> For
> > example:
> >
> > public void beginXXX(WebRequest theRequest) throws Exception {
> > String param1 = theRequest.getParameter("search_keyword");
> > if (param1 == null)
> > theRequest.addParameter("search_keyword", "Cactus");
> > [...]
> > }
> >
> > General benefit is test parametrization which doesn't require
> recompiling
> > and redeploying web-application (you understand it may be
> time-consuming).
> >
> > Greetings,
> > Ivan.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Running cactus test from web-browser with custom parameters
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Ivan,
An interesting idea. You have to remember that calling cactus tests from
a web browser is just one way of doing it. There are lots of other front
ends: Ant, Maven, Eclipse, manually from command line, etc. Thus the
solution must be able to work for all these situations.
ATM, there are already ways to pass parameters to a cactus test case.
Here's how you can currently do it:
public void beginXXXX(WebRequest req)
{
req.addParameter("param1", System.getProperty("param1"));
[...]
}
Thus, I believe the best solution would be to modify the Cactus
ServletTestRunner class so that it adds all the HTTP parameters as
System properties. That will allow your test case to retrieve these
properties as shown above.
It has the advantage that you'll also be able to use the other front
ends for your test and it'll still work (provided you also configure the
other front ends to pass these parameters).
Would that do it for you?
Thanks
-Vincent
> -----Original Message-----
> From: Ivan Kaschenko [mailto:om600@tut.by]
> Sent: 10 November 2003 09:56
> To: Cactus Developers List
> Subject: Running cactus test from web-browser with custom parameters
>
> Hi, guys!
>
> I have a question but couldn't find a proper location to place it in.
> Would
> you be so kind to skim it though and, maybe, give me some links where
I
> can
> get information I need?
>
> As specified in Cactus documentation, running test from web-browser
must
> be
> performed as follows:
>
> http://server:port/webapp/ServletTestRunner?suite=testcasename
>
> It would be extremely convinient to parametrize tests from such
requests.
> I
> mean adding parameters list in a way as http GET request syntax
specifies:
>
>
http://server:port/webapp/ServletTestRunner?suite=testcasename¶m1=va
lu
> e1
> ¶m2=value2 etc.
>
> Optional parameters are custom ones and must be passes to request
(within
> test) without any modification. They must be accessible via
> WebRequest.getParameter(String) call. Default value must be provided.
For
> example:
>
> public void beginXXX(WebRequest theRequest) throws Exception {
> String param1 = theRequest.getParameter("search_keyword");
> if (param1 == null)
> theRequest.addParameter("search_keyword", "Cactus");
> [...]
> }
>
> General benefit is test parametrization which doesn't require
recompiling
> and redeploying web-application (you understand it may be
time-consuming).
>
> Greetings,
> Ivan.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Running cactus test from web-browser with custom parameters
Posted by Ivan Kaschenko <om...@tut.by>.
Hi, guys!
I have a question but couldn't find a proper location to place it in. Would
you be so kind to skim it though and, maybe, give me some links where I can
get information I need?
As specified in Cactus documentation, running test from web-browser must be
performed as follows:
http://server:port/webapp/ServletTestRunner?suite=testcasename
It would be extremely convinient to parametrize tests from such requests. I
mean adding parameters list in a way as http GET request syntax specifies:
http://server:port/webapp/ServletTestRunner?suite=testcasename¶m1=value1
¶m2=value2 etc.
Optional parameters are custom ones and must be passes to request (within
test) without any modification. They must be accessible via
WebRequest.getParameter(String) call. Default value must be provided. For
example:
public void beginXXX(WebRequest theRequest) throws Exception {
String param1 = theRequest.getParameter("search_keyword");
if (param1 == null)
theRequest.addParameter("search_keyword", "Cactus");
[...]
}
General benefit is test parametrization which doesn't require recompiling
and redeploying web-application (you understand it may be time-consuming).
Greetings,
Ivan.
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: Use HTTP header instead of unique ID?
Posted by Christopher Lenz <cm...@gmx.de>.
Hi Nick,
Nicholas Lesiecki wrote:
> Sorry for another long response cycle, I wanted to get some time to digest
> the several emails on the topic.
>
> To reiterate, since I'm still holding the ball on implementing this:
>
> The proposed solution is to store the test results in application scope
> under a test-unique key. (And document Cactus's inability to work with load
> balancers--which Vincent has already done).
>
> I agree that load balancers should not have any bearing on the code under
> test. It's often easy to bypass them by sending your requests directly to
> one of the nodes in a cluster (at least it is where I work). Was there an
> open bug for this issue that we should close?
>
> Finally, I realize I was being confusing in my original email, I talked
> about headers in two different contexts:
>
> 1) Vincent's (now discarded) solution
> 2) The unique key solution
>
> I have been trying to get the Cactus code on the server to generate the
> unique id of the test results and then pass it back to the client in a
> header before running the test. Since the redirector generates the ids, its
> easier to make them unique to a given test.
>
> Here is the series of events I envision:
> When the redirector receives the initial request, it will
> 1) generate a unique id
>
> 2) add the unique id as a header to the http response object
> a) by adding the unique-id header before the test runs, the client cannot
> commit the response before the unique-id header is added
>
> 3) run the test (and send the response to the client)
>
> 4) store the test results in application scope under the unique key
>
> The cactus client would then
> 1) parse the unique id header
>
> 2) generate a second request for the test results, passing the unique id as
> a parameter
>
> The redirector would then
> 1) retrieve the results from app scope based using the key that the client
> passed as a parameter
>
> 2) send these results to the client
>
> Does this seem possible or have I overlooked a problem?
This sounds rather quite IMHO. I'd prefer a cookie though (instead of a
response-header and a query-string-parameter), as this is a perfect
usage scenario for cookies AFAICT.
--
Christopher Lenz
/=/ cmlenz at gmx.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: Use HTTP header instead of unique ID?
Posted by Nicholas Lesiecki <nd...@yahoo.com>.
Sorry for another long response cycle, I wanted to get some time to digest
the several emails on the topic.
To reiterate, since I'm still holding the ball on implementing this:
The proposed solution is to store the test results in application scope
under a test-unique key. (And document Cactus's inability to work with load
balancers--which Vincent has already done).
I agree that load balancers should not have any bearing on the code under
test. It's often easy to bypass them by sending your requests directly to
one of the nodes in a cluster (at least it is where I work). Was there an
open bug for this issue that we should close?
Finally, I realize I was being confusing in my original email, I talked
about headers in two different contexts:
1) Vincent's (now discarded) solution
2) The unique key solution
I have been trying to get the Cactus code on the server to generate the
unique id of the test results and then pass it back to the client in a
header before running the test. Since the redirector generates the ids, its
easier to make them unique to a given test.
Here is the series of events I envision:
When the redirector receives the initial request, it will
1) generate a unique id
2) add the unique id as a header to the http response object
a) by adding the unique-id header before the test runs, the client cannot
commit the response before the unique-id header is added
3) run the test (and send the response to the client)
4) store the test results in application scope under the unique key
The cactus client would then
1) parse the unique id header
2) generate a second request for the test results, passing the unique id as
a parameter
The redirector would then
1) retrieve the results from app scope based using the key that the client
passed as a parameter
2) send these results to the client
Does this seem possible or have I overlooked a problem?
Cheers
nick
On 11/2/03 12:01 PM, "Vincent Massol" <vm...@pivolis.com> wrote:
>
>
>> -----Original Message-----
>> From: Christopher Lenz [mailto:cmlenz@gmx.de]
>> Sent: 02 November 2003 19:36
>> To: Cactus Developers List
>> Subject: Re: Use HTTP header instead of unique ID?
>>
>> Vincent Massol wrote:
>>> To summarize, we have 2 possible solutions:
>>>
>>> Solution 1:
>>> - 2 requests
>>> - test result stored in application scope under a unique key
>>> - limitation: does not work with load balancer, even with
>>> session-affinity load balancer
>>>
>>> Solution 2:
>>> - 2 requests
>>> - test result stored in session scope under a unique key
>>> - limitation: code that expects (request.getSession(false) == null)
>>> cannot be tested!
>>
>> Hmm, I wonder if it would be possible to change our RequestWrapper to
>> behave differently depending on whether the session was created by
>> Cactus or by the test code. Might get rather involved though.
>>
>>> - advantage to solution 1: works with session-affinity load balancer
>>> (but not with dumb load balancers).
>>>
>>> Thus solution 1 seems better to me (although not perfect). This is
> the
>>> current solution (apart from the unique key which can be implemented
>>> relatively easily).
>>
>> First, I wonder whether the load-balancer scenario is actually
> important
>> to Cactus. Isn't this similar to the HTTP/SSL discussion we had
> recently?
>
> Yep. I believe it's the same. It's completely transparent for the code
> under test.
>
>>
>> [Note that I haven't really put much thought into this, neither have I
>> really worked with load-balanced environments yet, so this may be
>> totally off ;-) ]
>>
>> Anyway, I think it would be possible to use sessions to store the test
>> results, *if*:
>> - we'd provide a configuration parameter to explicitly enable
> implicit
>> session creation by Cactus
>> - our request wrapper would hide the session if it was created by
>> Cactus only for storing the test results
>> - we'd automatically invalidate any session created this way after
> the
>> second request, so that the server doesn't need to hold on to one
>> session per test (only timing them out after half an hour or so)
>> The code for actually storing and retrieving the test results could be
>> rather simple by simply always looking first in session scope and
>> falling back to application scope.
>
> Yeah that *may* work (would need to be tested). However, I believe the
> added complexity (configuration and code) is not worth the trouble. I
> find Cactus internals to be already complex enough ;-)
>
>>
>> This would be some work though, and it would be much simpler to simply
>> say "Cactus currently doesn't work in clustered environments" :-).
>
> Yep. I believe we should add this to the FAQ. I'm adding it.
>
> -Vincent
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Use HTTP header instead of unique ID?
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 02 November 2003 19:36
> To: Cactus Developers List
> Subject: Re: Use HTTP header instead of unique ID?
>
> Vincent Massol wrote:
> > To summarize, we have 2 possible solutions:
> >
> > Solution 1:
> > - 2 requests
> > - test result stored in application scope under a unique key
> > - limitation: does not work with load balancer, even with
> > session-affinity load balancer
> >
> > Solution 2:
> > - 2 requests
> > - test result stored in session scope under a unique key
> > - limitation: code that expects (request.getSession(false) == null)
> > cannot be tested!
>
> Hmm, I wonder if it would be possible to change our RequestWrapper to
> behave differently depending on whether the session was created by
> Cactus or by the test code. Might get rather involved though.
>
> > - advantage to solution 1: works with session-affinity load balancer
> > (but not with dumb load balancers).
> >
> > Thus solution 1 seems better to me (although not perfect). This is
the
> > current solution (apart from the unique key which can be implemented
> > relatively easily).
>
> First, I wonder whether the load-balancer scenario is actually
important
> to Cactus. Isn't this similar to the HTTP/SSL discussion we had
recently?
Yep. I believe it's the same. It's completely transparent for the code
under test.
>
> [Note that I haven't really put much thought into this, neither have I
> really worked with load-balanced environments yet, so this may be
> totally off ;-) ]
>
> Anyway, I think it would be possible to use sessions to store the test
> results, *if*:
> - we'd provide a configuration parameter to explicitly enable
implicit
> session creation by Cactus
> - our request wrapper would hide the session if it was created by
> Cactus only for storing the test results
> - we'd automatically invalidate any session created this way after
the
> second request, so that the server doesn't need to hold on to one
> session per test (only timing them out after half an hour or so)
> The code for actually storing and retrieving the test results could be
> rather simple by simply always looking first in session scope and
> falling back to application scope.
Yeah that *may* work (would need to be tested). However, I believe the
added complexity (configuration and code) is not worth the trouble. I
find Cactus internals to be already complex enough ;-)
>
> This would be some work though, and it would be much simpler to simply
> say "Cactus currently doesn't work in clustered environments" :-).
Yep. I believe we should add this to the FAQ. I'm adding it.
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: Use HTTP header instead of unique ID?
Posted by Christopher Lenz <cm...@gmx.de>.
Vincent Massol wrote:
> To summarize, we have 2 possible solutions:
>
> Solution 1:
> - 2 requests
> - test result stored in application scope under a unique key
> - limitation: does not work with load balancer, even with
> session-affinity load balancer
>
> Solution 2:
> - 2 requests
> - test result stored in session scope under a unique key
> - limitation: code that expects (request.getSession(false) == null)
> cannot be tested!
Hmm, I wonder if it would be possible to change our RequestWrapper to
behave differently depending on whether the session was created by
Cactus or by the test code. Might get rather involved though.
> - advantage to solution 1: works with session-affinity load balancer
> (but not with dumb load balancers).
>
> Thus solution 1 seems better to me (although not perfect). This is the
> current solution (apart from the unique key which can be implemented
> relatively easily).
First, I wonder whether the load-balancer scenario is actually important
to Cactus. Isn't this similar to the HTTP/SSL discussion we had recently?
[Note that I haven't really put much thought into this, neither have I
really worked with load-balanced environments yet, so this may be
totally off ;-) ]
Anyway, I think it would be possible to use sessions to store the test
results, *if*:
- we'd provide a configuration parameter to explicitly enable implicit
session creation by Cactus
- our request wrapper would hide the session if it was created by
Cactus only for storing the test results
- we'd automatically invalidate any session created this way after the
second request, so that the server doesn't need to hold on to one
session per test (only timing them out after half an hour or so)
The code for actually storing and retrieving the test results could be
rather simple by simply always looking first in session scope and
falling back to application scope.
This would be some work though, and it would be much simpler to simply
say "Cactus currently doesn't work in clustered environments" :-).
-chris
--
Christopher Lenz
/=/ cmlenz at gmx.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Use HTTP header instead of unique ID?
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Nicholas Lesiecki [mailto:ndlesiecki@yahoo.com]
> Sent: 02 November 2003 17:40
> To: Cactus Developers List
> Subject: Re: Use HTTP header instead of unique ID?
>
> OK, so we have several tensions we need to resolve. Our basic
requirements
> are:
>
> 1) The execution of a servlet-based test case must be allowed to pass
a
> text
> response back to the client for inspection and verification.
> 2) The test case must be able to retrieve its results from the server,
> including a verbose exception stack-trace.
The stack trace is text so this is not a requirement. The only
requirement is: pass some text which could possible be larger than 2KB
(not sure this is trye). I'm mentioning 2KB because if I remember
correctly that's the limit for a cookie.
>
> Some auxiliary concerns that we want to satisfy:
>
> A) Cactus should not require the creation of a session to do its job.
(I
> seem to remember that someone had a server which artificially limited
> session creation.)
This is currently true... Test results are stored in application
context.
> B) handling load-balancers gracefully
> C) handling concurrent test execution and preventing bugs caused by
stale
> test results left in a commonly-scoped application variable
>
> The solutions proposed so far are:
> I) Store the test results in the session
> II) Return the test results in a header
Or cookie BTW.
This will not work as Chris pointed out. When I made that proposal, I
had forgotten what the main issue was but he has explained it: the
header has to be written *before* the test is finished on the server
side...
In the past, I had tried a variation which was to add a special magic
string in the http response, at the end of the stream. I was putting the
test result after that magical string. However it did not work too
well... I had some issue on some servers with multi-mime types I think
(can't recall exactly).
> III) Store the test results in a uniquely keyed application scoped
> variable
Yep, this is the current implementation (except the unique id part which
is easy to do - I mean no technical problem).
>
> I've been working on Solution III, but passing back the unique key in
a
> header.(*) It's OK, but somewhat complicated. It also does not solve
the
> load balancing problem.
Why wouldn't is solve the load balancing? There's only a single HTTP
request, no?
>
> Solution I seems intuitive since sessions are the standard way of
> correlating information across client requests. This also solves the
> problem
> of load balancing if we omit any load balancers that do not guarantee
that
> multiple requests from the same client will hit the same session.
(This
> seems like a safe omission to me).
I've seen lots of load balancer that are NOT configured for session
affinity. We could say that they are not supported though.
> However, II requires the creation of a
> session, which violates auxiliary requirement A.
I don't understand. Solution II only has a single HTTP request. Why
would you need an HTTP session for?
>
> II has the nice feature of requiring only one request/response cycle
and
> thereby eliminating the (somewhat confusing) two-request model. It
solves
> the load balancer problem and the no-session problem. The only issue
is
> that
> it may disturb the ability of some users to fiddle with the response
> during
> their test. (We could not commit the headers to the client until we
had
> generated the test result). I have no feeling for how disruptive this
> would
> be to users. Certainly it would involve profound changes to Cactus,
but
> ones
> that would leave the code cleaner.
How do we control the fact that the server should not commit the
response before the test is finished? AFAIK, it's not possible.
>
> I think II is my favorite if we can work around the problem of
committing
> the response early. Perhaps a poll of the users list might help us
gather
> this information?
AFAIK, there's no solution. I've tried this solution about 2 years ago
and I could not find a solution. I had forgotten the problem, which is
why I posted the "header proposal" but as I've said, I agree with Chris
that it wouldn't work.
>
> Cheers,
> Nick
>
> * I thought this might lead to trouble with the headers already being
> committed, but I suppose if I added the cactus header before the test
got
> to
> it...
How do you know the result of the test before it is finished? :-)
[snip]
To summarize, we have 2 possible solutions:
Solution 1:
- 2 requests
- test result stored in application scope under a unique key
- limitation: does not work with load balancer, even with
session-affinity load balancer
Solution 2:
- 2 requests
- test result stored in session scope under a unique key
- limitation: code that expects (request.getSession(false) == null)
cannot be tested!
- advantage to solution 1: works with session-affinity load balancer
(but not with dumb load balancers).
Thus solution 1 seems better to me (although not perfect). This is the
current solution (apart from the unique key which can be implemented
relatively easily).
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org