I'm opening this to track a discussion we had tonight after I uncovered some issues at @bigcommerce earlier tonight while looking at our use of Resque.
It looks like for the past 12 months we've actually been using Predis for Resque since we began using Redis Sentinel in our environment. We currently configure Predis using Resque::setBackend with a callable. Predis is compatible with all of the Redis usage in php-resque.
The motivation for this change (as a default in php-resque) is that Predis is better supported, tested, and maintained. I also discovered while working on updating one of our development environments to match our production usage today the issues documented in https://github.com/chrisboulton/php-resque-scheduler/commit/f1a5596f81269809a53a7858355600e226990a9b, which we'd just not experienced because we've been using Predis everywhere.
After these changes, I hope to cut a new stable release. I also intend to bundle php-resque-scheduler in.
I'm opening this to track a discussion we had tonight after I uncovered some issues at @bigcommerce earlier tonight while looking at our use of Resque.
It looks like for the past 12 months we've actually been using Predis for Resque since we began using Redis Sentinel in our environment. We currently configure Predis using
Resque::setBackendwith a callable. Predis is compatible with all of the Redis usage in php-resque.The motivation for this change (as a default in php-resque) is that Predis is better supported, tested, and maintained. I also discovered while working on updating one of our development environments to match our production usage today the issues documented in https://github.com/chrisboulton/php-resque-scheduler/commit/f1a5596f81269809a53a7858355600e226990a9b, which we'd just not experienced because we've been using Predis everywhere.
After these changes, I hope to cut a new stable release. I also intend to bundle php-resque-scheduler in.