Feature #91

Check how eAccelerator can be supported

Added by Robert Lemke over 11 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Should have
Assignee:
Category:
-
Target version:
-
Start date:
Due date:
% Done:

100%

Estimated time:
0.00 h
PHP Version:
Has patch:
Complexity:

Description

Currently eAccelerator causes problems because annotations are not cached. Also some other weird behaviour occurred which I didn't check any further.

For now caching is disabled if eAccelerator is detected, but it would be nice to find some way to support it.

issue-91.patch View - Suggested patch to solve this. (828 Bytes) Karsten Dambekalns, 2008-05-10 22:42

patch_eaccelerator_issue91.txt View (898 Bytes) Tim Eilers, 2008-08-04 21:26

History

#1 Updated by Robert Lemke over 11 years ago

(In r419)
  • Framework: If eAccelerator is detect, the framework won't die anymore but rather disable caching. I haven't / couldn't test this however, but theoretically it should work. This addresses #91 - refer to that ticket for more information.

#2 Updated by Tim Eilers over 11 years ago

I activated eAccelerator on a test vhost on my linux system. While calling flow3 i got this error:

Warning: This script isn't in the allowed_admin_path setting! in /var/www/xxxxx/FLOW3/Packages/FLOW3/Classes/T3_FLOW3.php on line 137 Warning: This script isn't in the allowed_admin_path setting! in /var/www/xxxxx/FLOW3/Packages/FLOW3/Classes/T3_FLOW3.php on line 138

This message is clear: To use the functions you specified, the script has to be in the admin path defined in php.ini. I think in most cases it isn't possible or makes sense to put the flow3 framework into the admin path.

I don't know a good solution for that. Perhaps you could throw out a message that you are searching for a developer who makes a research for the eaccelerator problems? ;)

#3 Updated by Karsten Dambekalns over 11 years ago

  • Estimated time set to 0.00 h

I'd suggest to just remove the try to disable caching and just die with an error message.

#5 Updated by Robert Lemke about 11 years ago

  • Target version deleted (1)

#6 Updated by Tim Eilers about 11 years ago

r1064 adresses this topic.

If i find time and no one does it earlier i will contact the eaccelerator developers (f.e. by their mailing list) to find out, if and how it is possible to determine if the compile flag "--with-eaccelerator-doc-comment-inclusion" was used or not.

(See mailing list discussion)

#7 Updated by Tim Eilers about 11 years ago

The attached patch checks if the getDocComment method of PHP's ReflectionClass gives any Output. If yes, we can assume that the "--with-eaccelerator-doc-comment-inclusion" was used. If not, it was surely not used.
I basically tested this by compiling eaccelerator with that option and without. It worked here.

Please have a look at it.

#8 Updated by Karsten Dambekalns about 11 years ago

Some update. I just tried todays eAccelerator SVN with PHP 5.3.0alpha1, and did not have success:

With the eAccelerator enabled as PHP extension:
  • the production context died with a segfault.
  • after disabling the optimizer, the development context showed the default view.
With the eAccelerator enabled as Zend extension:
  • production context still was as dead as a dead parrot.
  • development context complained about some cache identifier already being registered - but that wasn't reproducable, subsequent requests just died with a segfault.

Currently it seems as if there is a truckload of issues, hopefully those are rooted in both PHP and eAccelerator (as used by me) were development code...

#9 Updated by Karsten Dambekalns over 10 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

FLOW3 checks for the ability to reflect doc comments and bails out if this isn't possible. This is all we can do, making sure any accelerator works with the PHP version we need is not our job.

Using APC shows there are accelerators that run just fine with PHP 5.3.0alpha3...

Also available in: Atom PDF