Обратные вызовы в экономии асинхронные функции?
В Экономии возможно использовать односторонний модификатор для определения вызова как асинхронного.
По-видимому, не возможно определить обратный вызов, тем не менее, чтобы быть выполненным, когда выполнение функции завершается.
Кажется, что единственная возможность, которую я имею, состоит в том, чтобы дать моему клиенту Экономии (PHP) некоторые возможности "сервера", так, чтобы, когда тяжелое вычисление завершается на стороне сервера, я мог отправить уведомление ему. Это означает, что у меня должен быть новый .thrift файл, с новыми определениями, новыми сервисами и всем остальные и что я должен генерировать php-серверный-код с Экономией.
Даже если это выполнимо, это похоже на излишество мне, и я задаюсь вопросом, существует ли более умный способ реализовать обратный вызов.
Ожидая к некоторой обратной связи от Вас, парней.
2 ответа
Роберто, к сожалению, во фреймворке Thrift нет таких встроенных функций. Там может быть несколько альтернатив , однако, в зависимости от того, что вы хотите, чтобы ваш сеанс PHP-клиента выполнял в течение времени, которое вы обычно ожидали бы ответа от ресурсоемкого сервера Thrift (если бы вы не использовали в одну сторону .)
На данный момент я могу только представить, что вы находитесь в ситуации, когда, закодировав веб-приложение, пользователь (или несколько пользователей одновременно) может запускать ресурсоемкую задачу. , вы хотели бы дать указанным пользователям обратную связь, пока указанные задачи выполняются.
С самого начала вы абсолютно правы, пытаясь избежать решения, которого пытаетесь избежать. Ваши сеансы PHP-клиента не могут обслуживать интерфейс обратного вызова без блокировки (если только вы не выкопаете дыру еще глубже, пытаясь использовать pcntl_fork или какой-либо другой средство поддержки потоковой передачи PHP .)
Самый простой и лучший выход, IMHO, - два переключения из модели, управляемой событиями ( Я хочу получать уведомление, когда сервер завершит работу ) к модели опроса ( Я буду периодически запрашивать у сервера, выполнено ли это .) Существует несколько способов реализации модели опроса с несколькими вариантами реализации как на сервере, так и на стороне клиента, например:
во время фазы вызова :
- клиентский сеанс PHP выделяет уникальное значение
job_id; затем сеанс выполняет асинхронныйодностороннийвызовvoid compute (..., job_id)на ресурсоемкий сервер Thrift,
- или -
- PHP клиентский сеанс выполняет синхронный вызов
job_id start_compute (...)на ресурсоемкий экономичный сервер; сервер выделяет уникальное значениеjob_id, затем порождает фактическую вычислительно-интенсивную задачу в отдельном потоке / процессе, сразу же возвращаясь к сеансу клиента PHP с выделеннымjob_id
- клиентский сеанс PHP выделяет уникальное значение
в течение этап вычислений :
- сеанс клиента PHP переходит к периодической проверке состояния ресурсоемкого задания с помощью вызова синхронного
status get_status (job_id)к ресурсоемкому вычислению Сервер сбережений,
- или -
- сеанс PHP-клиента завершается сразу же, чтобы освободить драгоценные ресурсы, после передачи
job_idбраузеру и указания браузеру периодически проверьте состояние ресурсоемкого заданияjob_id(например, черезMETA REFRESHили через запрос XHR (AJAX) из Javascript и т. д.)); проверка браузера порождает короткий сеанс PHP-клиента, который выполняет вызов синхронногоstatus get_status (job_id)на ресурсоемкий сервер Thrift, который завершается сразу после пересылки статуса (в зависимости от того, какой он может быть) на браузер
- сеанс клиента PHP переходит к периодической проверке состояния ресурсоемкого задания с помощью вызова синхронного
Я получил ответ на канале, отличном от Stack Overflow. Поскольку автор дал мне разрешение разместить здесь свой ответ, я подумал, что он может быть полезен кому-то еще в сообществе.
Привет, Роберт,
Да, это уже упоминалось в списках апачей раньше. Нет элегантного способа делать то, о чем вы просите, с Thrift. Он принципиально не предназначен для двунаправленного обмена сообщениями.
Здесь есть хаки, такие как: - опрос на стороне клиента - вызов send_method (), ожидание на стороне клиента, затем recv_method (), вместо of just method () - заставляет клиента также реализовывать сервер Thrift
Но очевидно, что ни один из них не является истинным двунаправленным обменом сообщениями. Мы постарались сделать интерфейсы Thrift максимально простыми и сосредоточились на основном сценарии использования RPC, что означало оставить некоторые вещи вроде этого из.
Вероятно, это не тот ответ, на который вы надеялись.
Ура, mcslee