As it turns out, for any given connection, whether it's database or Redis or whatever, you can have any number of queues associated with it. Let me show you. Let's go to our main Job here, and notice that it uses this trait called ShouldQueue. Alright, if we take a look, there's a handful of methods we can review. Now you're already familiar with delaying a job, but also take a look at this one, onQueue. Set the desired queue for a job. So this means, as an example, if you want all of your jobs to go on your default queue, but certain jobs to go on a different queue, maybe your emails queue or your fastlane queue, you can do that.

says, okay, we have a $5,000 order coming in for a celebrity or some big concert, you need to knock this out before anything else. Alright, well, even though you may have your orders or your own jobs you're working on, you've now been redirected over to this queue. You got to knock out this stack before you can go back to your other jobs. Make sense? So yeah, in that case, we have two different queues, but you can have any number of them. Okay, take a look here. We're going to go into config/queue.php. Now if we scroll down, we've been working with Redis, haven't we?

We're going to go into config/queue.php. Now if we scroll down, we've been working with Redis, haven't we? So you'll see again, the default queue is default, but again, you can name that anything you want. It's just a name for the stack. So let's try this. So we're going to go back to our routes/web.php file, and because any of our jobs use that Queueable trait, that means I could say, dispatch this on the queue, and we'll give it some name, whether it's emails or important or fast or high, use any terminology you want. Alright, so let's give this a shot.

it some name, whether it's emails or important or fast or high, use any terminology you want. Alright, so let's give this a shot. I'm going to boot up Horizon, and then we'll visit this in the browser. So let's refresh this page a couple times. Throw some jobs onto the queue, and now if I go to recent jobs, yeah, you'll see these have been thrown onto the high queue. However, if we were to switch back and we remove that, and then come back, throw a new job onto the queue, and if we switch back, if you don't specify which queue, it'll stick with the default. And again, that is defined in your config/queue.php file.

with the default. And again, that is defined in your config/queue.php file. But now there's still more to it. At the moment, we do have a default queue and a high queue, but there still isn't any logic that says the high queue is what we consider to be the priority queue, right? We haven't declared the difference between the two. So let me show you how to do this in a couple of ways, using the standard queue worker as well as configuring it with Laravel Horizon if you're using that. So I'm going to bring this back to what we had before, and then I'm going to run php artisan, and let's review the help for the queue:work command.

So I'm going to bring this back to what we had before, and then I'm going to run php artisan, and let's review the help for the queue:work command. OK, right here, the name of the queue is work. All right, php artisan queue:work, and let's start by saying, OK, you're only doing the default queue at the moment. All right, well, this means if I switch back and we give this a run, maybe a few times, if I switch back, you're not going to see anything happen. And just to be clear, though, if I go to Horizon Recent Jobs, yeah, you can see that we have thrown jobs onto the queue. But we're not currently working on the high queue.

thrown jobs onto the queue. But we're not currently working on the high queue. We're working on the default queue. So in fact, that means if I take a look at the logs for today, I'm not going to see anything here. And just to remind you, we're checking the log because in our example job, just to show that it's working, we are logging something to this file. So no matter how many times I run this, we throw the jobs onto the queue, but nobody's working the queue because the command specifies only worry about the default queue. So this means you could set up any number of workers.

but then a new job that's on the high queue comes through, maybe a password reset or something like that. This command says, all right, drop what you're doing. I want you to knock out that job that's on the high queue, and only when those are done can you go back and complete the default queue jobs. Okay, but next, let's close this out. We'll go back to Sublime. Let me now show you through Horizon. So if you go to your Horizon configuration file and we scroll down, let's see if we can find it.

So if you go to your Horizon configuration file and we scroll down, let's see if we can find it. All right, here are the various environments, as well as the settings for the queue worker. So I can see for local, it's going to use the Redis connection, and here is the queue it'll use, as well as the number of tries. Okay, so let's give it one more shot on our routes file. We're still going to dispatch this job on the high queue. However, when we run php artisan horizon, it's only listening to the default queue. So let's give this a shot, php artisan horizon, and then I do want you to see this. So let's open up the log and clear that out.

So let's give this a shot, php artisan horizon, and then I do want you to see this. So let's open up the log and clear that out. Okay, so we boot that up. We give this a couple runs, and again, if I go over to Horizon, Recent Jobs, here are the two page refreshes, but yeah, it's not being executed, so you won't see anything there. And again, that's because Horizon isn't listening to the high queue. Now we can tell it to do that, like so, and then if we give it another run, now it'll listen to both queues, and you can see it did knock out those two jobs that were waiting to be performed, and that's it.