Costin Manolache wrote: > I guess the better solutions are to either deal with this in the > servlet facade ( i.e. the HttpServletResponse impl ) - or to just > remove the cached fields from coyote Response. > > The second is harder - but the right one IMO, it's bad to have methods > in Response that don't do what people would expect them to do and > workaround in facade to deal with complexity. And we already have a > cache ( for converted int values ) in MessageBytes. > > I'm sure Remy would be happier with the first solution, and it's > simpler to implement. But I agree that we shouldn't add this to > Response. > > Costin
Given we are working around the cached fields in coyote response, I wanted to keep the work around as close to coyote response as possible. I agree removing the cached fields is the right way to go if we can. I did take a quick look at it but was concerned about possible performance impacts and wanted to get a better fix out sooner that I would have been able to otherwise. A related concern was a lack of a test case to check any performance impact. I'll put together a simple JMeter test for this. Given that we are concerned about request overhead, does the following test case sound reasonable? - simple servlet (approx 1K output) - explicitly set content length and type in servlet - JMeter test case that uses 50 concurrent threads to make 10000 requests - set min threads on the connector to >50 - measure average time per request Cheers, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
