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