tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Lawrence Murphy <ga...@teledyn.com>
Subject Re: troubleshooting getPathInfo in jsp files
Date Wed, 15 Dec 2010 16:40:55 GMT
On Wed, Dec 15, 2010 at 11:29 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:

>
> A high-volume real-time environment where on-the-fly JSP compilation is
> allowed and ad-hoc insertion of new dynamic content is allowed? Sounds
> like madness.
>

yes it is.  such is the real world.  we deal in sports news, about 20-40 xml
documents per second inbound to an xsl process that requires various utility
services such as timezone conversions, with two orders of magnitude outbound
publishings of the results which require various authentication rules.
 Being live human-generated data, we are required to be fleet of foot, and
if it goes down, or even slows down, the fantasy sports people start to lose
big money.

it is improvisational, absolutely.


> May I ask what the problem is with sticking with Resin and/or Jetty? As
> much as I like Tomcat myself... why are you considering switching?


Resin will only work on single CPU although it will use all the cores of
that CPU; to work with multiple CPU we could license the pro version, but
the cost for us is prohibitive.  Everything was fine working on quad-core
servers, however we now have a good case to move to amazon cloud-hosted
services for scaling reasons, however AWS servers appear as 1-core multi-CPU
machines, at best dual core, which makes a highly multithreaded java app
pretty much useless.

the sysstat clearly shows that Caucho is enforcing that single-CPU rule, it
is not inherent in java, and mpstat proves that other servlet containers
will use all available cores.  So the hunt was on for an affordable
alternative.  We had begun with Jetty but had to abandon it years ago as it
was expensive to maintain and did not perform well under extreme loads
typical of certain sports events (playoffs, olympics etc) although I may
revisit it if tomcat does not work out.

the idea was floated to fork Tomcat to insert our own parsing rule on the
servlet-mapping, and I may also investigate that; my worry is creating a
maintenance nightmare where upgrades become risky, however it may turn out
that the other containers also do servlet-mapping in this way and we'd be
forced to use a modified TC.

>

-- 
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message