Remy Maucherat wrote:
Here are some new proposals.
2) Bug 26010. Doh, '_' is a useful character in URIs. Big mistake from
me :-( I plan to use the '#' character instead, which is not useable in
a URI.
3) New connector shutdown. There is a problem with the current Tomcat
shutdown order. It work
In general, I agree that general benchmarks are useless and can be
slanted towards any alternative you choose.
Also I agree that Tomcat generally seems to perform quite well and reliably.
--
Jess Holle
Peter Lin wrote:
As usual, these types of comparisons aren't really useful or even desirable.
Remy Maucherat wrote:
Jess Holle wrote:
Any and all performance improvements would be greatly appreciated.
For those who have not seen it, Sun is touting their "SunONE is
better performed / more scalable than Apache 2 + Tomcat" benchmark.
While Tomcat and mod_jk[2]'s sole goal is not to scale
As usual, these types of comparisons aren't really useful or even desirable. I
remember there used to be a benchmark JSR, but it was with drawn. one of these days, a
standard set of web and ejb benchmark apps should be created. that way, instead of the
usual simple jsp tests, the performance m
Jess Holle wrote:
Any and all performance improvements would be greatly appreciated.
For those who have not seen it, Sun is touting their "SunONE is better
performed / more scalable than Apache 2 + Tomcat" benchmark. While
Tomcat and mod_jk[2]'s sole goal is not to scale and perform every bit
> I'm not sure if it should happen in TC 5.0.x or 5.1.x but I'd like to
> investigate in multicast magic for topology determination.
>
> If javagroups had been ASF compatible, I could have some code for that,
> but seems we should do it by hand or via an ASF compatible license tool.
>
> The goal
Remy Maucherat a écrit :
Here are some new proposals.
1) Optimization of the session implementation.
The session is not a thread safe object. In Tomcat, the session
implementation is partially thread safe for some reason (this has been
like that since Tomcat 4.0, AFAIK). As a result, we can rem
Remy Maucherat wrote:
Here are some new proposals.
1) Optimization of the session implementation.
The session is not a thread safe object. In Tomcat, the session
implementation is partially thread safe for some reason (this has been
like that since Tomcat 4.0, AFAIK). As a result, we can remove
Here are some new proposals.
1) Optimization of the session implementation.
The session is not a thread safe object. In Tomcat, the session
implementation is partially thread safe for some reason (this has been
like that since Tomcat 4.0, AFAIK). As a result, we can remove some
synchronization.
