> -----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]
