On Wed, Dec 15, 2010 at 11:29 AM, Christopher Schultz < ch...@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*
