Laravel Flysystem & Rackspace Загрузка CRON с ошибкой 401 при загрузке по запросу

Question

Наша система каждый час производит различные счета-фактуры и загружает их в облако. Также можно создать счет-фактуру по требованию, нажав кнопку на нашем интерфейсе.

При ручном запросе на создание указанного счета-фактуры он никогда не загружается. Что касается хрон генерироваться счета через некоторое время все загрузки завершится с:

Client error response 
[status code] 401 
[reason phrase] Unauthorized 
[url] https://storage101.dfw1.clouddrive.com/v1/MossoCloudFS_930575/ <...> .pdf" @ Guzzle\Http\Exception\BadResponseException->factory 

что должно означать, что маркер истек, который он, вероятно, есть. Значки Rackspace продолжаются 24 часа, но хранилище Laravel должно автоматически обновлять токен.

---

Теперь здесь некоторые интересные факты:

1) Каждый раз, когда наш код развернут с Capistrano маркер, кажется, чтобы получить обновилась и хрон загрузки снова работать в течение некоторого времени. Важно отметить, что каждый раз развертывание создает новую папку, похожую на эту /releases/201605190925, вытягивает код, устанавливает зависимости с нуля и, если все пойдет хорошо, символизирует эту папку с показателем Apache.

2) рабочие места Laravel получить обрабатываются на другом процессе, чем WWW-данных

3) Это трудно отследить, если после развертывания загрузка работает более 24 часов или нет. Я подозреваю, что иногда это работает больше, чем это. Но трудно отследить, так как не каждый час есть счета-фактуры, которые необходимо создать. Есть больше разработчиков, которые развертывают, чем только я и т. Д.

4) Когда cron терпит неудачу, и я получаю уведомление об отказе, я могу немедленно сдать и успешно сгенерировать счет-фактуру. После этого cron все еще терпит неудачу. Таким образом, похоже, что у этих двух экземпляров есть разные токены.

5) Кэш очистки с php artisan cache:clear, кажется, не имеет никакого влияния

6) Возможно, попробовал перезапустить службу Apache, но без результатов

Поскольку это продолжается уже в течение некоторого времени я испытал разные вещи и даже связались с Rackspace в какой-то момент, но они не могли найти ничего странного с их конца ... Напомнил мне просто поймать ошибку 401, обновить токен и повторить попытку. Но Laravel и Flysystem должны обрабатывать их где-то сами по себе.

Поскольку у кого-то еще нет подобных проблем с Flysystem или Laravel или Rackspace, я подозреваю, что это какая-то уникальная проблема с процессом cron. Я просто надеялся, что скоро у нас будет обновленная версия нашей системы, и проблема просто исчезнет. На данный момент он все еще находится в разработке и может занять еще один месяц.

---

Не думаю, что это связано с кодом, но в любом случае здесь линия загрузки:

Storage::put($folder . '/' . $filename, file_get_contents($filePath)); 

Вот наш конфиг:

'default' => 'rackspace', 

'disks' => [ 
    'rackspace' => [ 
     'driver' => 'rackspace', 
     'username' => ' ... ', 
     'key'  => ' ... ', 
     'container' => ' ... ', 
     'endpoint' => 'https://identity.api.rackspacecloud.com/v2.0/', 
     'region' => 'DFW', 
    ] 
] 

---

Любые мысли по этому вопросу будут оценены ,

Answer 1

Здесь я снова пытался найти решение проблемы почти через 2,5 месяца. И я думаю, что это действительно щелкнуло на этот раз, когда я перечитал обновление @Tommmm.

Итак, вы перезапустили рабочую очередь, и я начал думать о том, как я управлял своим руководителем/работниками.

php artisan queue:work database --daemon --sleep=10 tries=3

---

--daemon (как это было на самом деле хорошо объяснено в этом StackOverflow post by @the-shift-exchange)

В Laravel> = 4,2 была команда --daemon добавил. То, как он работает, просто просто запускает очереди напрямую, а не перезагружает всю структуру после обработки каждой очереди. Это необязательная команда, которая значительно снижает требования к памяти и процессору вашей очереди.

Важным моментом с командой --daemon является то, что при обновлении приложения вам необходимо специально перезапустить свою очередь с очередью: перезагрузить, иначе вы могли бы получить всевозможные странные ошибки, так как ваша очередь все равно будет иметь старый код в памяти.

---

Поскольку приложение никогда не загружается снова, я чувствую, что токен также не обновляется. Что касается остальной части приложения, он все еще обновляет токен и использует новый. Это объясняет, почему все действия на клике работали, и только фоновые задачи терпели неудачу. Что касается того, почему развертывание временно исправлено, наша проблема заключалась в том, что после каждого развертывания у нас было queue:restart.

Я совершенно уверен, что это так, и теперь есть две возможности для начала. Либо вы перезапустите своих работников через некоторое время (< 24h для Rackspace), либо вы не запускаете рабочих вместе с --daemon.

---

Edit:

Подтверждено, что добавление следующее Kernel.php перезапускает рабочих демона через каждые 6 часов.

$schedule->command('queue:restart')->cron('0 */6 * * *')

Answer 2

У меня была аналогичная проблема. Документация и частота ошибок кажутся довольно низкими для этой проблемы. Чтение здесь (https://github.com/rackspace/php-opencloud/issues/427) похоже, что искомый токен является основной причиной.

Рекомендация из приведенной выше ссылки, чтобы клиент повторной аутентификации с помощью

$client->authenticate(); 

Но, клиент похоронен под кучкой команд. Вы должны быть в состоянии получить доступ к основной клиент К сожалению, с помощью

Storage::disk('my-disk')->getDriver()->getAdapter()->getContainer()->getClient()->authenticate(); 

, я в конечном итоге с 35 завитка ошибка при попытке что (SSL_CONNECT_ERROR).

Существует метод

hasExpired() 

также доступны. Если вы столкнулись с той же ошибкой, вы можете объединить эту проверку с каким-то механизмом, чтобы перезапустить работу cron или работника. Хотя это, безусловно, далеко не идеальное решение, оно должно заставить вас работать и работать. Вы бы подумали, что это поведение будет поймано и обработано автоматически.

---

5/25 Update: Потратив еще несколько часов, пытаясь найти решение здесь, я бросил в полотенце и просто создал хрон, чтобы Перезапустите соответствующие рабочим каждые 12 часов. Предположительно, токен действителен в течение 24 часов (согласно HTTP 401 Fog::Storage::Rackspace::ServiceError), поэтому 12-часовое окно должно безопасно предотвратить ошибку. В то время как супер хаки, он сохраняет эту часть сайта и работает.