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" <[EMAIL PROTECTED]> wrote: > Vincent Massol wrote: >>> -----Original Message----- >>> From: Christopher Lenz [mailto:[EMAIL PROTECTED] >>> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
