{"action":"created","issue":{"url":"https://api.github.com/repos/concrete5/concrete5/issues/3087","labels_url":"https://api.github.com/repos/concrete5/concrete5/issues/3087/labels{/name}","comments_url":"https://api.github.com/repos/concrete5/concrete5/issues/3087/comments","events_url":"https://api.github.com/repos/concrete5/concrete5/issues/3087/events","html_url":"https://github.com/concrete5/concrete5/issues/3087","id":114671255,"number":3087,"title":"Changing the Queue Library to Laravel","user":{"login":"Mnkras","id":212649,"avatar_url":"https://avatars.githubusercontent.com/u/212649?v=3","gravatar_id":"","url":"https://api.github.com/users/Mnkras","html_url":"https://github.com/Mnkras","followers_url":"https://api.github.com/users/Mnkras/followers","following_url":"https://api.github.com/users/Mnkras/following{/other_user}","gists_url":"https://api.github.com/users/Mnkras/gists{/gist_id}","starred_url":"https://api.github.com/users/Mnkras/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Mnkras/subscriptions","organizations_url":"https://api.github.com/users/Mnkras/orgs","repos_url":"https://api.github.com/users/Mnkras/repos","events_url":"https://api.github.com/users/Mnkras/events{/privacy}","received_events_url":"https://api.github.com/users/Mnkras/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2015-11-02T19:52:29Z","updated_at":"2015-11-06T05:50:32Z","closed_at":null,"body":"Currently we use Zend queue for all of our queue related shenanigans. All it really supports is FIFO and a few adapters (that I don't thing we expose in any useful way).\r\n\r\nI would like to propose moving to Laravel Queues. (depending on what PHP version we end up going with, either http://laravel.com/docs/4.2/queues or http://laravel.com/docs/5.0/queues).\r\n\r\nThere are several reasons for this,\r\n\r\nIn our current queue, if something fails, it fails permanently, and we don't tell anyone. Laravel allows jobs to retry, and if it goes past a set number of failures it goes into a failed_jobs table. This is especially important with emails.\r\n\r\nZend queue does support adapters, but Laravel supports more, and more is better... right?\r\nI really want to be able to allow users to choose their adapters, like Amazon SQS. By default, it would default to a database queue like we have now.\r\n\r\nI know that this may add some dependencies, but I think it would be worth it.\r\n\r\nOnce we have a stable queue system, I would propose moving certain things, like sending emails, or other things that could be long-running (like file operations).\r\n\r\nThoughts?\r\n"},"comment":{"url":"https://api.github.com/repos/concrete5/concrete5/issues/comments/154305310","html_url":"https://github.com/concrete5/concrete5/issues/3087#issuecomment-154305310","issue_url":"https://api.github.com/repos/concrete5/concrete5/issues/3087","id":154305310,"user":{"login":"Remo","id":129864,"avatar_url":"https://avatars.githubusercontent.com/u/129864?v=3","gravatar_id":"","url":"https://api.github.com/users/Remo","html_url":"https://github.com/Remo","followers_url":"https://api.github.com/users/Remo/followers","following_url":"https://api.github.com/users/Remo/following{/other_user}","gists_url":"https://api.github.com/users/Remo/gists{/gist_id}","starred_url":"https://api.github.com/users/Remo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Remo/subscriptions","organizations_url":"https://api.github.com/users/Remo/orgs","repos_url":"https://api.github.com/users/Remo/repos","events_url":"https://api.github.com/users/Remo/events{/privacy}","received_events_url":"https://api.github.com/users/Remo/received_events","type":"User","site_admin":false},"created_at":"2015-11-06T05:50:32Z","updated_at":"2015-11-06T05:50:32Z","body":"> That is very true, but I foresee an async queue being used for more than just email, as an example, moving files from one storage location to another en-masse is not possible right now, with our current chucked queue, if 1 file fails, the queue will not go further no matter how many times you run it.\r\n\r\nAgreed\r\n\r\n> I have 2 reasons why I was looking into having an async queue along with failure/retry tracking,\r\n1. The email server stopped responding, which killed page-loading on any page that tried to send an email.\r\n\r\nThat part could be handled by a package, no big downside here.\r\n\r\n2. When c5 fails to send an email, it fails permanently with no way to resend/retry. (This bit me when an email acct password was changed, had a few days of emails that I couldn't re-send and had to go through c5's log table >.<)\r\n\r\nThat part could be handled by a package, no big downside here.\r\n\r\n> We could make it as a package, but I feel the benefit of having it in the core would out-weigh the extra weight added. Also, having support for enterprisely features out of the box can be a nice incentive for c5.\r\n\r\nI agree, enterprise level sites will require such functionality pretty quickly. I'd say more than half of my laravel projects use beanstalk. \r\n\r\nI guess someone will have to make a decision here and that's probably not me ;-)\r\n"}}