В Thrift можно использовать модификатор oneway , чтобы указать вызов как асинхронный .
По-видимому, невозможно определить обратный вызов , хотя он должен быть выполнен, когда выполнение функции завершено.
Кажется, что единственная возможность, которую я имею, – предоставить моему Thrift client ( PHP ) некоторые «серверные» возможности, так что, когда тяжелые вычисления будут завершены на стороне сервера, я могу отправить ему уведомление. Это означает, что у меня должен быть новый .thrift-файл с новыми определениями, новыми службами и всем остальным и что я должен сгенерировать php-серверный код с Thrift.
Даже если это осуществимо, это выглядит для меня излишним, и мне интересно, есть ли более умный способ реализовать обратный вызов.
Ждем от вас отзывов, ребята.
Роберто, к сожалению, инфраструктура Thrift не имеет таких встроенных функций. Однако может быть несколько альтернатив , в зависимости от того, что вы хотите, чтобы ваш сеанс PHP-клиента выполнял в то время, когда вы, как правило, ждали, когда компьютер с интенсивным вычислением будет отвечать (если бы вы не использовали его в oneway ).
Я могу только представить себе, что пока вы находитесь в ситуации, когда, закодировав веб-приложение, где пользователь (или несколько пользователей параллельно) может каждый запускать вычислительно-интенсивную задачу, вы хотели бы предоставить некоторую обратную связь упомянутым пользователям в то время как упомянутые задачи сворачиваются.
С самого начала вы абсолютно правы, пытаясь избежать решения, которое вы пытаетесь избежать. Ваши сеансы PHP-клиента не могут обслуживать интерфейс обратного вызова без блокировки (если вы еще не углубляете свое отверстие, пытаясь использовать pcntl_fork или какую-либо другую ленточную ленту PHP ).
Самый простой и самый лучший путь от этого – это два перехода от модели, управляемой событиями ( я хочу получить уведомление о завершении работы сервера ) модели опроса ( я периодически буду запрашивать с сервера, будет ли это сделано ). Существует несколько способов реализации модели опроса с несколькими вариантами реализации на сервере, а также на стороне клиента, например:
во время фазы вызова :
job_id ; сеанс затем делает асинхронный oneway вызов void compute(..., job_id) на вычислительно-интенсивный сервер Thrift, — или —
job_id start_compute(...) для вычислительно-интенсивного сервера Thrift; сервер выделяет уникальное значение job_id , а затем job_id актуальную вычислительно-интенсивную задачу в отдельном потоке / процессе, возвращая сразу на сеанс клиента PHP с выделенным job_id во время фазы вычисления :
status get_status(job_id) с синхронным status get_status(job_id) на вычислительно-интенсивный сервер Thrift, — или —
job_id в браузер, а также поручил браузеру периодически проверять состояние трудоемкой работы job_id (например, через META REFRESH или через XHR (AJAX) от Javascript и т. Д.); проверка браузера порождает короткий сеанс PHP-клиента, который выполняет синхронный status get_status(job_id) вызова на вычислительно-интенсивный сервер Thrift, завершая сразу же после пересылки статуса (в зависимости от того, что может быть) в браузере Я получил ответ на канал, отличный от Stack Overflow. Поскольку автор дал мне разрешение опубликовать здесь свой ответ, я подумал, что это может быть полезно кому-то еще в сообществе.
Эй, Роберт,
Да, это уже появилось в списках Apache. Нет элегантного способа сделать то, о чем вы просите с Thrift. Это принципиально не предназначено для двунаправленной передачи сообщений.
В нем есть хаки, такие как: – опрос на стороне клиента – вызов send_method (), ожидающий на стороне клиента, затем recv_method (), а не только метод () – заставляющий клиента также реализовать сервер Thrift
Но, очевидно, ни один из них не является истинным двунаправленным обменом сообщениями. Мы попытались максимально упростить интерфейсы Thrift и сфокусировались на основном использовании RPC, что означало оставить некоторые вещи вроде этого.
Наверное, не тот ответ, на который вы надеялись.
Привет, mcslee
Вместо того, чтобы пытаться реализовать обратные вызовы с Thrift (то, что сделало бы протокол значительно более тяжелым, я думаю), я использую облегченную службу обмена сообщениями (STOMP – http://stomp.github.com ), чтобы информировать клиента о асинхронных событиях.
Мой подход заключается в том, что клиент Thrift подписывается на определенный канал STOMP, и сервер Thrift будет отправлять сообщения на том же канале всякий раз, когда происходит асинхронное событие. Затем клиент может запросить сервер для дополнительной информации о событии.
Ну, в Java есть сообщения Asynchronus Message через ссылку Future Object. Это может быть реализовано в модели RPC с использованием пакета сообщений . Я не уверен, что PHP имеет нечто подобное.