When the job is fetched from the queue, there is a timeout registered using \Illuminate\Queue\Worker::registerTimeoutHandler in \Enqueue\LaravelQueue\Worker::onMessageReceived. But the timeout is not cleaned up when the job is processed. Using the \Enqueue\Consumption\Context\MessageResult event, we can clean the timeout set by pcntl_alarm in a similar way how it's done in the Laravel's worker.

RabbitMQ has persistent message functionality that has not been serviced. To use it, just add to your app/Jobs/SomeJob.php field $persistent = true. After that when you restart RabbitMQ message still be in a queue.

Hi there!

I've added support for autodiscovering the package. Read more about it here => https://medium.com/@taylorotwell/package-auto-discovery-in-laravel-5-5-ea9e3ab20518

Add extensions support, before there wasn't possibility to add Monitoring extension, therefore I did changes, because we needed it.

Usage:

• Create your own provider and extend EnqueueServiceProvider
• Add new extensions to extensions array
• Add your custom provider to providers config

Tested with our project and with monitoring extension everything works well.

Implementing this function allows for using new Laravel queue feature: queue:monitor

Without these changes, all queues are 0 size (from Enqueue\LaravelQueue\Queue)

We are getting queue size anyway with declareQueue. I am just storing it for size function override.

When using this library and if another queue driver is used, in class Worker when calling parent::demon the script must finish and we need to quit child method.

I'm currently unable to install enqueue/laravel-queue alongside enqueue/amqp-ext, as they have different dependency versions (enqueue/laravel-queue depends on enqueue/*:0.9, enqueue/amqp-ext on enqueue/*:0.10).

This pull request simply bumps the enqueue dependencies to match those of the others.

Advantages:

• Supports all Laravel native Worker features - pause, stop, kill, events and so on.
• Consume messages immediately as they arrive. Consume from multiple queues at once.
• Run fewer work processes - reduce memory usages.
• It uses long pulling whenever possible - results in zero CPU usages while idling.
• You can reuse any queue consumer extensions, for example monitor any transport.
• AMQP friendly.

Issue

When starting laravel worker using laravel-queue, this error is produced:

[2019-01-24 00:48:33] laravel.ERROR: Argument 1 passed to Enqueue\AmqpLib\AmqpContext::declareQueue() must implement interface Interop\Amqp\AmqpQueue, string given, called in /var/www/html/vendor/enqueue/laravel-queue/src/AmqpQueue.php on line 61 {"exception":"[object] (Symfony\\Component\\Debug\\Exception\\FatalThrowableError(code: 0): Argument 1 passed to Enqueue\\AmqpLib\\AmqpContext::declareQueue() must implement interface Interop\\Amqp\\AmqpQueue, string given, called in /var/www/html/vendor/enqueue/laravel-queue/src/AmqpQueue.php on line 61 at /var/www/html/vendor/enqueue/amqp-lib/AmqpContext.php:163)
[stacktrace]
#0 /var/www/html/vendor/enqueue/laravel-queue/src/AmqpQueue.php(61): Enqueue\\AmqpLib\\AmqpContext->declareQueue('wat')
#1 /var/www/html/vendor/enqueue/laravel-queue/src/AmqpQueue.php(47): Enqueue\\LaravelQueue\\AmqpQueue->declareQueue('wat')
#2 /var/www/html/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(247): Enqueue\\LaravelQueue\\AmqpQueue->pop('wat')

AmqpContext->declareQueue is expecting the Interop\Amqp\AmqpQueue retrieved on line 57; however, the queue name as a string is passed instead.

Fix

Pass $interopQueue to AmqpContext->declareQueue.

After recent Laravel update to version v9.42.0 - laravel/framework#45120 - worker stopped working due to worker's stop function being incompatible with parent.

Notes

Hello everyone, this PR isn't meant to be PR'ed right away (cfr. composer changes isn't something I want to merge back into the stack), it's a PoC for the use case where I want to listen to a Kafka topic that isn't a serialised PHP class. When configuring Kafka, the laravel container tries to create a job out of the job payload, but for topics that are just transferring data, this of course goes wrong.

My idea was to have a configuration for a "handler" class to handle this use case. I noticed in the Symfony documentation example there was a spot for a "client", but I don't see anything else wrt to how this interacts exactly with the framework. Assuming this "client" configuration entry serves the same purpose as this "handler" configuration, I'd be interested to see how I could configure it inside the queue.php config file.