[support] Validation Error

[sander-martijn]

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 at 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.
>