Feature #91
Check how eAccelerator can be supported
| Status: | Closed | Start date: | ||
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assigned To: | Robert Lemke | % Done: | 100% |
|
| Category: | - | |||
| Target version: | - | Estimated time: | 0.00 hour | |
| PHP Version: | Complexity: | |||
| Has patch: |
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
- Suggested patch to solve this.
(828 Bytes)
patch_eaccelerator_issue91.txt
(898 Bytes)
History
#1 Updated by Robert Lemke over 7 years ago
- 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 7 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 about 7 years ago
- Estimated time set to 0.00
I'd suggest to just remove the try to disable caching and just die with an error message.
#4 Updated by Karsten Dambekalns about 7 years ago
- File issue-91.patch added
#5 Updated by Robert Lemke about 7 years ago
- Target version deleted (
1)
#6 Updated by Tim Eilers about 7 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 almost 7 years ago
- File patch_eaccelerator_issue91.txt added
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 almost 7 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.
- 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 6 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...