Долгосрочные задачи в Thrift

Question

Я планирую использовать Apache Thrift, но некоторые вызовы будут долго выполняться/блокироваться, но по-прежнему требуют возвращаемого значения, которое традиционно будет возвращаться через обратный вызов.

Я понимаю, что Thrift does not support callbacks (изменилось?), Поэтому я думаю о том, что функция просто блокируется до тех пор, пока не будет возвращен ответ. Это будет нормально? Будет ли Thrift жаловаться (время ожидания), если запрос RPC занимает слишком много времени?

Говорят, что Thrift не предназначался для двунаправленной связи, но это должно быть достаточно легко сделать с гнездом.

Контекст: Я использую Thrift или IPC между двумя процессами локально, поэтому на сервере не будет огромной нагрузки, облегчающей любую проблему, что длительные HTTP-запросы будут перегружать сервер.

У меня отсутствует решение, предоставляемое чем-то еще?

Answer 1

Я понимаю, что Бережливость не поддерживает обратные вызовы (это изменилось?)

Нет (не поддерживается), и нет (не изменилось).

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

Да, если вы хотите придерживаться стиля RPC, чтобы делать что-либо или технически ограничены в этом отношении.

, так что я думаю о том, чтобы функция просто блокировалась до ответа . Это будет нормально?

Длинные звонки - это совершенно законное решение. Разумеется, даже опрос может быть вариантом, если вы не наводняете сервер вызовами. Зависит от того, что означает «длинный».

Будет ли тратить жалобу (таймаут), если запрос RPC занимает слишком много времени?

Вы всегда можете инициировать новый запрос после того, как соединение упало.

Говорят, что Thrift не предназначался для двунаправленной связи , но это должно быть достаточно легко сделать с гнездом.

В локальной установке, имеющей оба конца, действующие в качестве клиента и сервер действительно возможно, и, возможно, лучший вариант в вашем случае.

Напротив, это намного сложнее сделать через interblag. Поэтому, если у вас есть сильные планы по расширению вашего решения позже в таком сценарии, это может создать дополнительные головные боли, чтобы переписать решение bidi в длительные вызовы. Если это не так, вы можете спокойно проигнорировать этот абзац.