> -----Original Message----- > From: Nicholas Lesiecki [mailto:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
