You can clone with
No one assigned
If I enable xcache on my apache server, Predis throws the following error:
"Fatal error: Class 'Predis\CommunicationException' not found in..."
Is there a way to make it work with xcache?
THank you for your time.
Predis doesn't do anything fancy to load its files since it relies on the standard autoloading facility exposed by PHP, so I can't really think of a reason why it shouldn't work with XCache and considered that we use both daily, there's actually no reason beside a bug in the version of PHP or XCache being used.
You should complete the report with the operating system and the version of Apache, PHP, XCache and Predis being used in your environment. Are you using a .phar archive for Predis?
I am using the one-file version of Predis (not really my choice, the application I use Predis with is a bit rigid).
It should be noted this has been reproduced on two different machines.
PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch (cli) (built: Jun 13 2012 17:19:58)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with XCache v1.3.2, Copyright (c) 2005-2011, by mOo
Distributor ID: Ubuntu
Description: Ubuntu 12.04.1 LTS
Server version: Apache/2.2.22 (Ubuntu)
Server built: Feb 13 2012 01:51:50
Predis Client version is 0.7.4-dev
Thank you very much for your time.
I was finally able to reproduce your same error when using XCache, I'm not sure what the cause is but I'll investigate now that I can work on it myself.
Thank you! I suspect this has something to do with several namespaces in a single file as I have seen other applications having trouble with XCache and the single common point seems to be PHP namespaces. However, I may be wrong.
This one seems indeed a bug of XCache related to its caching engine: disabling the cache with xcache.cacher = off while leaving the extension loaded seems not to break PHP, but its pretty much pointless I'd say. Unfortunately this issues is still present in updated versions of XCache (like 3.0.1), and it's not like we can do anything about it on our end so I'm closing this issue. By the way, everything seems to work fine with APC.
xcache.cacher = off
Thank you for your feedback, I may try to submit a bug to XCache for this issue.
@adrienlabelle that would be great, I guess this will be easily reproducible for them since it appears to be triggered systematically. Could you post a link to the ticket if you manage to open a bug report on their issue tracker? Thanks.
@nrk : here is the XCache ticket: http://xcache.lighttpd.net/ticket/300
Thanks for pointing to the related ticket on the XCache tracker, @adrienlabelle!
there isn't enough information provided in the ticket. the reporter is not responding. can anyone else help to reproduce it?
I submitted a test case on the XCache ticket, sorry for the delay.
Just noticed the explanation for the error, I'll try to investigate a solution in the next few weeks but the script used to glue all the files is already quite complex and the one-big-file approach is deprecated anyway. Will post an update as soon as I have time to look into it. Thanks!