15
votes

Our current stack is Apache + Tomcat + MySQL, using ProxyPass AJP to fire requests from Apache to Tomcat. We also run PHP for Wordpress on the same sites, and so need working .htaccess files. In response to an annoying problem (see this Stack Overflow page), we're considering alternative stacks. Note that we generally quite like apache, but this problem is a show-stopper: if we can't fix it, we can't use Apache.

Alternatives include:

  • Tomcat alone
  • Glassfish (Java app server, forked from Tomcat)
  • Jetty (Java server)
  • Resin
  • LightTPD (lightweight HTTP server)
  • Nginx (lightweight HTTP server)

The way I see it, solutions fall into two camps: the pure Java camp, such as Glassfish; or the split camp such as our current Apache + Tomcat. We like the idea of a pure Java solution, since fewer moving parts should mean less to go wrong; but do any of them support PHP, .htaccess files, etc?

In theory we could do the split the other way - have a simple front end that proxies to Apache on only those bits that need those features - but in practice that would be 80% of requests.

What options do people suggest?

locked by HopelessN00b Dec 5 '14 at 3:53

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

Read more about locked posts here.

  • Would you mind elaborating your "annoying show-stopper problem" a bit more, or is it completely irrelevant? – mark Apr 30 '09 at 14:27
  • Follow the link to the StackOverflow page for more details. It's a bug where clients are delivered the wrong response - sometimes getting JS or CSS files instead of HTML ones, or just the wrong page entirely. We've tried pretty much everything within Apache and Tomcat we can think of. – Marcus Downing Apr 30 '09 at 15:57
7
votes

I strongly suspect your problem is related to AJP.

I was in a course with one of the main Tomcat developers a few weeks ago (he was running it), his advice was to avoid AJP and mod-JK etc, and stick to regular mod-proxy HTTP.

Reasons:

  1. It's by far the most mature and stable Tomcat connector.
  2. Neither AJP implementation has been consistently developed; both projects have suffered a bit of stop / start.
  3. NBIO does not result in any real world performance gain over blocking-IO, in this situation.

My advice, try using regular mod-proxy HTTP with your current setup. It's the least change for you and it will take you on to the most widely used and stable Tomcat deployment architecture.

/ Richy

5
votes

My current preferred stack is to use nginx as a replacement for Apache. Wherever necessary, php-fpm fills in the need for PHP. Such a setup has worked nicely for deploying apps such as Rails, Magento and SugarCRM.

4
votes

Glassfish will be more scalable than Tomcat because it uses Grizzly (NIO based). You don't have many options other than a variation of Tomcat, Jetty, or Glassfish because of the Java requirement. PHP can be run using Quercus, but it may be better to just deploy it using Nginx.

2
votes

There are PHP implementations on Java, The one I know (but haven't used) is this one. There is a blog post on how to install it on GlassFish (including WordPress), but I guess the installation on tomcat is the same. Regarding the .htaccess, you haven't written what exactly you have there, but if it is for URL rerwriting then there is the UrlRewriteFilter who does the same work with the same semantics.

  • The .htaccess files are mostly those generated by WordPress, so they contain a few simple RewriteRules – Marcus Downing Apr 30 '09 at 15:54
  • I guess the PHP will not support them, but it shouldn't be hard to have a process that reads them and passes the definitions to the filter. – David Rabinowitz Apr 30 '09 at 20:54
0
votes

Cherokee ? where is he ? http://www.cherokee-project.com/

Not the answer you're looking for? Browse other questions tagged or ask your own question.