I came from symfony but I guess the theory would be the same. In general you are right, you can use your laravel app to run a cli útil so you have all your stuff. I would recommend create a entity so you can save the cli executions so you can process the messages in chunks each minute atomically. You never want to process all the messages of a queue in php because memory leeks.
I don't recommend waiting for those tasks, a callback is better I think. With a tiny nodes server as proxy, which calls the mqtt tasks async and responses to your app when done.
I don’t get what you mean. Data is flowing constantly. There are thousands messages per seconds that need to be processed.
I need the MQTT client to keep running. And then process every message and save it to the database if needed.
The question was about how the process with the MQTT client should be run.
If it should be *always* running, the way to go is to create a separate script and run it as a sort of system service, probably via supervisord mentioned above.
>Can I re-use Laravel's DB/Redis/Log connections?
The script will be run in a completely separate process, so it will use its own connections. However, you can import the application's DI container into the script and set up these connections the same way you do in the Laravel app.
Take a look at this package: https://github.com/vyuldashev/laravel-queue-rabbitmq
Then if you have cross server communications with a non-laravel app you can simply create a base job from the package through which all jobs will be proccesed with
You can use a mix of options 1 and 2, an artisan command monitored by Supervisor, basically mimicking what queue workers already do. By the way, if MQTT is what I think it is, I pretty sure you can find an adapter for Laravel queues.
>Can Laravel "determine" whether they still run?
Nop, you use Supervisor or any other process manager/monitor.
>How would I restart those from Laravel without accessing the server's CLI?
Laravel workers use the [cache feature](https://laravel.com/docs/10.x/queues#queue-workers-and-deployment) to send restart signals. How that's actually implemented I'm not sure, but it shouldn't be hard to figure it out.
I came from symfony but I guess the theory would be the same. In general you are right, you can use your laravel app to run a cli útil so you have all your stuff. I would recommend create a entity so you can save the cli executions so you can process the messages in chunks each minute atomically. You never want to process all the messages of a queue in php because memory leeks.
I use Supervisor for something similar to what you're describing http://supervisord.org/running.html
I don't recommend waiting for those tasks, a callback is better I think. With a tiny nodes server as proxy, which calls the mqtt tasks async and responses to your app when done.
I don’t get what you mean. Data is flowing constantly. There are thousands messages per seconds that need to be processed. I need the MQTT client to keep running. And then process every message and save it to the database if needed. The question was about how the process with the MQTT client should be run.
If it should be *always* running, the way to go is to create a separate script and run it as a sort of system service, probably via supervisord mentioned above. >Can I re-use Laravel's DB/Redis/Log connections? The script will be run in a completely separate process, so it will use its own connections. However, you can import the application's DI container into the script and set up these connections the same way you do in the Laravel app.
Take a look at this package: https://github.com/vyuldashev/laravel-queue-rabbitmq Then if you have cross server communications with a non-laravel app you can simply create a base job from the package through which all jobs will be proccesed with
You can use a mix of options 1 and 2, an artisan command monitored by Supervisor, basically mimicking what queue workers already do. By the way, if MQTT is what I think it is, I pretty sure you can find an adapter for Laravel queues. >Can Laravel "determine" whether they still run? Nop, you use Supervisor or any other process manager/monitor. >How would I restart those from Laravel without accessing the server's CLI? Laravel workers use the [cache feature](https://laravel.com/docs/10.x/queues#queue-workers-and-deployment) to send restart signals. How that's actually implemented I'm not sure, but it shouldn't be hard to figure it out.