Hi Anton,
There are a lot of reasons why enterprise level companies might choose resin to host their app. One reason I could think of right off is the necessity to run legacy apps written in java. But the main reason is speed. Resin kicks all other servers right off the page when it comes to performance. And yes, that includes apache. I used resin to host my java apps for years and never had an issue, but haven't ran it with php so I can't comment on it's implementation.
For what it's worth, if the issue is with resin's php implementation and the client wants to use resin for java, resin can run as an apache module so it's possible to use apache for static files, resin for java and the standard apache php module for php (and therefore drupal).
It would be worth figuring out with resin though, especially with all the performance problems drupal currently has.
Anton wrote:
On 04/12/2007, Tom Holmes Jr. tom@tomholmes.net wrote:
If no one from Drupal.org can tell me how to fix this ... there is NO WAY my employer is gonna use Drupal for an enterprise-wide stable CMS ....
Forgive me for bringing this up, but I noticed you were using Resin as a web server. Do these problems still happen on Apache with mod_php?
I seems a little 'un-enterprise' to run a complex app like Drupal on a platform that has received practically no real testing from the Drupal community and isn't listed on the system requirements http://drupal.org/requirements. Let alone testing of your chosen contrib modules on Resins PHP implementation. My experience on enterprise app deployment is that they are extremely conservative and won't go anywhere near situations like that.
Resin apparently involves all sorts of (to use PHP language) opcode caches, differing threading models, and JIT compilation etc. In their early days PHP opcode caches also caused (and still do to some extent) weird issues in complex apps that took time to shake out. Just like fast_cgi also produced some weirdness early on.
Unless these problems also appear on Apache (as the most mature way of running PHP), these could just be symptoms of a platform combination that still has some maturing to do - a process all the other platform combinations are in various stages of going through.
I certainly wouldn't be try running a standard Python or Ruby app on Jython or JRuby without expecting there might be issues. Not sure why a Java implementation of PHP would be any different.