@BENderIsGr8te you ARE great! Thanks again, buddy!

@BENderIsGr8te I understand what you say in the post marked as the answer, but I don't agree:

Push queues were very easy to set up, you didn't need to run any commands, have a queue listener or set up a supervisor; just a single route with Queue::marshall. Not all of us use something like Forge.

Iron.io push queues also have support for failed jobs and retries.

Testing push queues was easy as well, I used https://ngrok.com/ to make a tunnel to my local website, a single command to open the tunnel and that's it.

To me, it was an easier entry point to queues, able to be used in any server (even traditional ones). Having push queues out of the box in Laravel didn't hurt anybody.

:(

@JohnRivs couldn't have said it better myself. Trying to switch to Beanstalkd and it's just annoying. Accidentally emailed a bunch of beta testers last night with a test alert because I forgot to restart the queue worker after pushing new code that was supposed to only send to me.

Issues like that never happen with Iron, it simply sends the data back to the server for processing - nothing to keep track of, restart, etc.

I get it. But as I originally stated it was just my 2 cents. I've been using this system for a few months with no issues.

@JohnRivs @opheliadesign In Laravel 5.1 seems the push queue documentation is gone.

I want to use Job class in 5.1 since it could serialize model, guess it could be passed as parameter to the push queue

class SendReminderEmail extends Job implements SelfHandling, ShouldQueue { use InteractsWithQueue, SerializesModels;

protected $user;

/**
 * Create a new job instance.
 *
 * @param  User  $user
 * @return void
 */
public function __construct(User $user)
{
    $this->user = $user;
}

/**
 * Execute the job.
 *
 * @param  Mailer  $mailer
 * @return void
 */
public function handle(Mailer $mailer)
{
    $mailer->send('emails.reminder', ['user' => $this->user], function ($m) {
        //
    });

    $this->user->reminders()->create(...);
}

}

and call $job = (new SendReminderEmail($user))->onQueue('emails'); $this->dispatch($job); to work with the nice marshal? I did not see the 5.1 doc talks about it at all about how to make Job and marshal work together with the serialized info of model in the message and call back to the job for processing

Route::post('queue/receive', function() { return Queue::marshal(); });

I just want to post a job and wait for call back from Iron.IO to the job

It's not only gone from the docs, but also from the core of the framework.

ok seems i have to build it myself for push queue

One gotcha with Forge users and local queues: Since forge runs a deployment script when you push new code, you need to edit the deployment script on your site under the Apps tab and add php artisan queue:restart so that each time you push new code the queue/s are refreshed with latest code. The docs state this, but it's easy to miss.

Push Queue also now available at AWS SQS, I think it's the best and fastest way for anyone to start using Queue without the need of any Queue application running at the background, its like the queue application act as a service for good scalability.

Like me, I run my application on AWS Elastic Beanstalk, to setup Beanstalkd or other application isn't a simple thing, luckily now SQS started to support Push Queue and the Elastic Beanstalk worker tier seems to agree on how push Queue is more appropriate. But the bad thing about this that Laravel suddenly remove it when AWS started to support it, kinda funny.

I think Taylor need to think on less playing with server architecture for the framework.

Would love to see Queue::marshal() again in the framework. Especially because since AWS SQS natively supports push queues with AWS Elastic Beanstalk.

Just here to express my support for adding push queue handling back into the core. I am not using Forge due to security needs, but I don't have the budget for a full-time veteran server admin. So I have no idea how to troubleshoot mysterious random breakdowns in the artisan queue workers under supervisord, or how to keep beanstalkd running through deployments. Seems like ironMQ push queues would be perfect for my situation.