{"issue":{"title":"Pub/Sub option?","created_at":"2011-12-20T02:25:42Z","user":{"login":"RVN-BR","id":1218902,"url":"https://api.github.com/users/RVN-BR","avatar_url":"https://secure.gravatar.com/avatar/e33af81d39f14364d23b04a622ce8594?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"e33af81d39f14364d23b04a622ce8594"},"milestone":null,"labels":[],"updated_at":"2011-12-24T00:17:25Z","state":"open","id":2608657,"closed_at":null,"html_url":"https://github.com/chrisboulton/php-resque/issues/31","pull_request":{"patch_url":null,"html_url":null,"diff_url":null},"body":"Hi,\r\n\r\nHas anyone tried getting a pub/sub queue working under resque?  any comment?\r\n\r\nI have one feature that i need to add to my app that calls a webservice for another application we interface.  Nonetheless, i need this to be done as quickly as possible, currently using resque using the normal 5 second interval is a bit laggy...  1 second interval would probably ok, nonetheless i think it may be overkill to run the queue across a cluster of server iterating every second, etc, without any activity? (not all the time there will be things on the queue)...\r\n\r\nThe other option will be to just tie these particular webservice calls to the user-activated script (kinda not-elegant because if the webservice does lag at all we will have a laggy interface as well as laggy functionality...)\r\n\r\nAnyways, any suggestions about this?  I do suppose that if I put the workers throughout 10 or so servers, and maybe a few workers per server, eventually the lag will be quite small?  But still, there will be a ton of hits on Redis, wouldnt a pub/sub mechanism be somewhat better?\r\n\r\nthanks for ideas/feedbak","number":31,"url":"https://api.github.com/repos/chrisboulton/php-resque/issues/31","comments":5,"assignee":null},"comment":{"created_at":"2011-12-24T00:17:25Z","user":{"login":"andrewjshults","id":175454,"url":"https://api.github.com/users/andrewjshults","avatar_url":"https://secure.gravatar.com/avatar/3e7813758deb7d6fa5cb8f3e9e6fce21?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"3e7813758deb7d6fa5cb8f3e9e6fce21"},"updated_at":"2011-12-24T00:17:25Z","id":3265780,"body":"I think the two issue threads are getting a bit crossed. Where I'm at now is primarily a PHP place as well (at least on the frontend) so I like to keep that aspect unified. There are two main issues I have with resque (these are related to both the Ruby version as well as the PHP port, although I'm currently just doing work on the PHP port).\r\n1) Jobs can be lost without any indication (I'm more concerned with the without any indication than the lost job part for my uses)\r\n2) Reliance on polling when Redis provides a nice built in Pub/Sub mechanism (this is mostly for my own learning/enjoyment since I know that the polling mechanism actually works quite well even with high volumes as long as you distribute enough workers)\r\n\r\nBoth of these would be forks (the two issues are orthogonal so I'd work on them in separate branches) off of Chris' port. I'm just starting to play around with both so no timeframe on either, but the goal would be to make transitioning to either transparent. I'll definitely push things up as I get them working so that you can check them out.\r\n\r\nI was referring to the Ruby admin part, since I quite like the Sinatra framework and since none of the admin side was ported to PHP, I'd likely extend the admin interface of the Ruby version of Resque rather than built up a new version from scratch in PHP.","url":"https://api.github.com/repos/chrisboulton/php-resque/issues/comments/3265780"},"action":"created"}