[support] Validation Error

Anton anton.list at gmail.com
Tue Dec 4 21:20:42 UTC 2007


On 05/12/2007, Tom Holmes Jr. <tom at tomholmes.net> wrote:
> I tried to provide as much information as possible and I am willing to
> provide more.  As I think I clearly stated ... I installed Drupal in two
> different environments:
> one where both resin/drupal/mysql are all on my laptop ... and the other
> environment where resin/drupal and mysql are separate servers.
> The former works ok, the latter does not ... that makes me think there
> is something else wrong and it's not resin.

Maybe. If the problem still cropped up on mod_php to a remote MySQL
server, then I'd agree Resin has been eliminated as a variable. The
reason I'm harping on about eliminating Resin is because it is a
VASTLY different environment to everything else. It isn't the fact
that the web server is written in Java (that is the minor bit) - it is
the fact that PHP itself is reimplemented in Java, and there are huge
differences between the way a JVM compiles/optimises/runs something
and natively compiled code runs.

There could be a subtle session problem with the php-mysql libraries
in Resin when using a remote mysql server - is that not plausible?
After all plently of hosting providers host Drupal on mod_php with
remote mysql servers.

I don't know if you've followed Jython or JRuby development, but
getting those environments to the point where most complex
applications or platforms work on them isn't trivial. And the
Jython/Jruby teams will always be shaking out the obscure corner case
issues that are exposed by new applications.

> But both you and Earnie seem to have this fixation that I did not test
> it out with Apache/PHP ... since this issue has been around since 4.73
> with users presumably using Apache/PHP ... I thought logically ... that
> it was irrelevant.

You still haven't pointed to the actual issue report. The main
candidate I manged to find (http://drupal.org/node/63990) that matches
your description has already been patched (in Drupal 5.x) for a couple
of months, and Drupal 5.3 has been released since then.

So I suspect you are talking about a different issue altogether. But
without you telling us what issue you are talking about we don't know.

> As I stated above ... I have tried to always provide as much information
> as I had, and I am willing to provide more if needed.
> Just ask me ...I did thoroughly explain what I did to do an install and
> what modules I installed.  And the fact that one system works and one
> does not
> with almost the same setup.  I also did turn off the caching as someone
> else mentioned ... and that did NOT fix the problem.

Great. That is useful. Unfortunately as far as I can tell you haven't
told us that before.

> I know you and Earnie want me to test this out with Apache/PHP ... and
> when I get the time today ... I will.
> If I get the same error ... then it's NOT ME!!!!!!

Exactly. Which is why we want to know that.

> But as I previously stated ... since this was happening with 4.x and has
> been a long time problem ... I presume past users had he problem with
> Apache/PHP.

You still haven't pointed out which problem you are talking about. As
I said before the same error message doesn't indicate the same
problem.

> But ... I will try with Apache/PHP though I think I will get the same
> issue ...

I hope so too - it will be far more easily fixed by the developers that way.

> and for all I know it's a problem with a contributed module
> ... I don't know.

I suspect it is a contrib mondule myself. Most contrib modules don't
get anywhere near the scrutiny and review that Drupal core gets.

> The one thing that is aggravating is when someone reports a problem,
> fixes it ... but then doesn't tell anyone how to fix it.

example?

> I see this question being asked a lot ... and have NOT YET seen anything
> anywhere in the Drupal Site .... in the bugs/issues area that this is
> even logged.

Well someone with the problem has to log it. What we are trying to do
is help you narrow down where to log it (eg the contrib module(s),
core, or even Resin).

> Instantly questioning why I would install this on Resin as opposed to
> Apache/PHP because that wasn't required ...
> in essence I felt like you were saying .... "well if you had done that
> ... it wouldn't have been a problem."

Not at all. Maybe it is my old sysadmin background, but when your job
is diagnosing and isolating problems in large hetrogenous software
stacks you see the importance of eliminating as many variables as
possible. Otherwise it is just futile guesswork.

I would actually prefer the problem be confirmed with mod_php. It will
get fixed quicker, and be one more step towards Resin being Drupal
ready (which is exciting).

I think Java development has shielded you somewhat from the platform
specific differences involved in other cross platform development
environments. And to be honest Resins PHP implemented in Java (while
really cool and exciting) is probably PHPs biggest divergence ever
from the platform the actual PHP project produces. It is a far bigger
change than that between different Java VMs, and you can't deny that
changing JVMs can cause problems with some applications.

It is extremely naive to expect it will be problem free. It will
mature and get better the same way APC, e-accellerator, fast-cgi, PHP
on IIS, lighthttp, nginx etc are all maturing and getting better.
Early adopters of those platforms have all gone through varying
amounts of the same pain you are.


> And if it's still a problem ... I am going to either A) fix it myself
> B) drop Drupal as being an insufficent enterprise-ready CMS system

Hell I wouldn't use PHP at all if I was a enterprise user :)

But sorry, one issue with 3rd party plugins when using an application
on an obscure unsupported and untested platform is effectively
meaningless when judging that applications enterprise readiness.

Lets face it enterprise software usually has very strict system
requirements for what is supported and enterprises are very anal about
sticking to those requirements.

Would something like Websphere be unready for the enterprise if your
Java web app ran into problems when you ran Websphere on some obscure
(but very fast) new JVM written in Lisp? I doubt IBM would give you
any support even if you proved the problem was with Websphere.

There are far more legitimate enterprise concerns with Drupal than this issue.

-- 
Cheers
Anton


More information about the support mailing list