Closed halaei closed 7 years ago
Horizon needs to do some work that's why it extends Laravel's RedisQueue, technically if you source dive it you'll learn what you need to build support for other drivers, but for now there are no plans to support on other drivers, but feel free to open a PR.
I would plan for something like this:
Laravel\Horizon\RedisQueue
with a HorizonQueue
class that is a wrapper for every possible queue driver. It may extend from Illuminate\Queue\Queue
while implementing Illuminate\Contracts\Queue\Queue
and having a property, namely $queue, of type Illuminate\Queue\Queue
- using composition.pushRaw()
from Illuminate\Contracts\Queue\Queue
and change the visibility of all the implementation of this function in the current drivers to protected.Illuminate\Queue\QueueManager
with a HorizonQueueManager
with this resolve()
implementation:
protected function resolve($name)
{
return new HorizonQueue($parent->resolve($name));
}
Illuminate\Contracts\Queue\Queue
and implement it in other queue drivers.Maybe its will be a feature
Horizon uses redis to collect metrics, so you'll need redis anyways so maybe using redis for queue as well makes sense.
I am using redis for queue, but via a slightly different queue driver. I made Horizon work with my custom driver anyway.
Just my 2 cents.
I used Redis at first for Queue's but noticed that since Redis is not built inherently as a Queue system its much easier to run into issues that may affect the quality of your Jobs. I ended up personally moving to SQS after trying all the different drivers as it seemed the most stable in my applications.
That being said I do still use Redis for cache/sessions, so adding in horizon metrics is no problem if that remains a requirement.
If I get free time I may look into making a PR but will probably take me a lot of time to get it together.
@jordanramstad I'm really interested in the SQS / Database driver for the jobs as well, even if that means to continue using redis for metrics (as I'm using it for my own metrics as well).
If you feel like starting a PR, I'd more than happy to help.
Whoops i just wasted 5 hours thinking i could use this with a database driver
@jordanramstad Did you start this? Like you we still use redis for cache/sessions but certainly SQS for managing queue (EB worker tiers added bonus too!)
@MPJHorner No, I have looked into the codebase a bit but from what I can see so far it might be quite a bit of work and a rather large PR (mainly due to the amount of code I need to understand first). I have managed so far without horizon so unless I find it becomes a requirement I can't justify the time I would need to spend on it just yet.
Since most other laravel packages seem to incorporate drivers at the start and this one does not, I would assume there is valid reasoning behind it.
FYI, I created a Database driver in #421 Not a PR, just a gist yet.
A quick question here: considering that Vapor comes with built-in SQS setup for queues, does it mean Horizon has SQS driver now?
A quick question here: considering that Vapor comes with built-in SQS setup for queues, does it mean Horizon has SQS driver now?
+1 👍
Vapor itself handles the queuing to using Horizon with Vapor doesn't really makes sense.
Does Vapor provide a dashboard similar to Horizon?
Does Vapor provide a dashboard similar to Horizon?
Take a look at the brand new https://github.com/laravel/vapor-ui
I know the vapor-ui package is deprecated but this seems to fetch metrics from SQS instead of Redis. Wouldn't this still be a good basis to create an additional SQS driver for Horizon?
It seems there is not a good UI for monitor Laravel jobs on SQS except having to resort to CloudWatch or something like Grafana.
I see there is a
Laravel\Horizon\RedisQueue
class extendingIlluminate\Queue\RedisQueue
. I have also my own extension ofIlluminate\Queue\RedisQueue
that works exactly like the base class except the way it pops jobs out of the queue. What is the best way to have my own queue driver supported by horizon?