Обратные вызовы в арифметических функциях Thrift?

В Thrift можно использовать модификатор oneway для указания вызова как асинхронного.

По-видимому, невозможно определить обратный вызов, хотя он должен быть выполнен, когда выполнение функции завершено.

Кажется, что единственная возможность, которую я имею, - предоставить моему клиенту Thrift (PHP) некоторые "серверные" возможности, так что, когда тяжелые вычисления будут завершены на стороне сервера, я могу отправить уведомление об этом. Это означает, что у меня должен быть новый .thrift файл с новыми определениями, новыми службами и всем остальным, и что я должен сгенерировать php-серверный код с помощью Thrift.

Даже если это осуществимо, это выглядит для меня излишним, и мне интересно, есть ли более умный способ реализовать обратный вызов.

Ждем ваших отзывов, ребята.

Ответы

Ответ 1

Роберто, к сожалению, инфраструктура Thrift не имеет таких встроенных функций. В может быть несколько альтернатив, хотя, в зависимости от того, что вы хотите, чтобы ваш сеанс PHP-клиента выполнял в течение времени, которое вы обычно ожидали, когда компьютер с интенсивным вычислением Thrift будет отвечать (если бы вы не использовали oneway.)

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

С самого начала вы абсолютно правы, пытаясь избежать решения, которое вы пытаетесь избежать. Ваши клиентские сессии PHP не могут обслуживать интерфейс обратного вызова без блокировки (если вы еще не углубляете свою дыру, пытаясь использовать pcntl_fork или какой-либо другой PHP-ленточный носитель.

Самый простой и самый лучший способ - это два переключателя из управляемой событиями модели (я хочу получать уведомления о завершении работы сервера) для модели опроса > (Я периодически буду спрашивать с сервером, будет ли это сделано.) Существует несколько способов реализации модели опроса с несколькими вариантами реализации на сервере, а также на стороне клиента, например:

  • во время фазы :

    • сеанс клиента PHP выделяет уникальное значение job_id; сеанс затем делает асинхронный вызов oneway void compute(..., job_id) на вычислительно-интенсивный сервер Thrift,

    - или -

    • сеанс клиента PHP делает синхронный вызов job_id start_compute(...) на вычислительно-интенсивный сервер Thrift; сервер выделяет уникальное значение job_id, а затем запускает актуальную вычислительно-интенсивную задачу в отдельном потоке/процессе, сразу возвращаясь к сеансу клиента PHP с выделенным job_id

  • на этапе вычислений:

    • клиентский сеанс PHP периодически проверяет состояние вычислительно-интенсивного задания посредством синхронного вызова status get_status(job_id) на вычислительно-интенсивном сервере Thrift,

    - или -

    • клиентский сеанс PHP заканчивается сразу, чтобы освободить ценные ресурсы, передав браузеру job_id в браузер, а также поручив браузеру периодически проверять состояние трудоемкого задания job_id (например, через META REFRESH или с помощью запроса XHR (AJAX) от Javascript и т.д.); проверка браузера порождает короткий сеанс PHP-клиента, который выполняет синхронный вызов status get_status(job_id) на вычислительно-интенсивном сервере Thrift, завершая сразу же после пересылки статуса (в зависимости от того, что может быть) в браузере

Ответ 2

Я получил ответ на канал, отличный от Stack Overflow. Поскольку автор дал мне разрешение разместить здесь свой ответ, я подумал, что это может быть полезно кому-то еще в сообществе.

Эй, Роберт,

Да, это появилось на Apache списки ранее. Нет элегантного способа делать то, о чем вы просите Бережливость. Это принципиально не предназначен для двунаправленной передачи сообщений.

Вокруг этого есть хаки, такие как: - опрос на стороне клиента - вызов send_method(), ожидающий на стороне клиента, затем recv_method(), вместо метода() - заставить клиента также реализовать сервер Thrift

Но, очевидно, ни одно из них не верно двунаправленная передача сообщений. Мы пробовали сохранить интерфейсы Thrift как как можно проще и основной случай использования RPC, что означало оставляя некоторые вещи, подобные этому.

Возможно, вы не ответили надеясь на.

Приветствия, mcslee

Ответ 3

Вместо того, чтобы пытаться реализовать обратные вызовы с Thrift (то, что сделало бы протокол значительно более тяжелым, я думаю), я использую облегченную службу обмена сообщениями (STOMP - http://stomp.github.com), чтобы информировать клиента о асинхронных событиях.

Мой подход заключается в том, что клиент Thrift подписывается на определенный канал STOMP, а сервер Thrift будет отправлять сообщения на том же канале всякий раз, когда возникает асинхронное событие. Затем клиент может запросить сервер для получения дополнительной информации о событии.

Ответ 4

Ну Java имеет вызовы Asynchronus Message через ссылку Future Object. Это можно реализовать в модели RPC, используя Message Pack. Я не уверен, что PHP имеет что-то подобное.