On 05/12/2007, Tom Holmes Jr. tom@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.