Level 39
Have you restart your queue worker?
https://laravel.com/docs/9.x/queues#queue-workers-and-deployment
Apr 21, 2022
11
Level 8
FTP not working when called from the scheduler
I have a job that upload a file using ftp:
/**
* Create a new job instance.
*
* @return void
*/
public function __construct()
{
$this->customerCareFileRaw = Storage::disk('ftp')->get($this->getFile); // Need to add a try Catch
}
I'm getting an error, from the log file:
[2022-04-20 17:45:01] local.ERROR: Unable to connect to host ftp.freshtechcrm.com at port 21. {"exception":"[object] (League\Flysystem\Ftp\UnableToConnectToFtpHost(code: 0): Unable to connect to host ftp.freshtechcrm.com at port 21. at /var/www/html/vendor/league/fly>
But, when i run the job on the server using tinker works fine. What could be the difference of the scheduler running the job and tinker doing it? any ideas how to troubleshoot this?
Level 8
@sr57 I have the queue connection set to sync, i though it would not use a queue worker. I will reset the worker, and see what happens.
Level 39
sync does not use the queue
Level 8
@sr57 So restarting the queue will probably not solve the problem correct?
Level 39
Please try
Level 8
@sr57 It did work. I thought the queue worker was completely out when using sync.
Thanks for the help.
Level 39
Laravel doc is very good but there are some "shortcut" , in this case in the it's written queue workers but it 's 2 different things, workers to run jobs and queue to runs in a row, and sync just does not use queue but uses worker.
Level 8
This morning the process gave me the same error. Unable to connect. I have changed the time for the connection just in case the server is down just at that time, but i have little faith that will cure it. I have the filling that the scheduler is not loading something that Tinker does. I will see on Monday if the process actually run, and update the post.
Level 122
@dan3460 Sounds more like the connection is unreliable. Perhaps as a test, put it in a loop with a small delay and see if it works 100% or is hit and miss.
You might need to build a retry mechanism into the job
Level 39
Agree with @snapey a connection is never 100% sure, it's why you can set a retry number and a delay (--backoff option) to job setup.
It's easy to see, if the log msg occurred each time your job started, the (first) pb was "worker to be restarted"), if (now) the msg appears for some runs only, the pb is (now) "reliability" of the connection.
Level 8
Seems that the job run during the weekend. I'll keep monitoring for a couple of days. I will build a retry mechanism just in case. Thanks for the help.
Please or to participate in this conversation.