Pull to refresh

Comments 9

То что вы написали просто механизмы сериализации.
Да, это просто механизмы сериализации, а в thrift добавляется еще и клиент серверная реализация (транспорт)
UFO just landed and posted this here
Не только сериализация / десериализация, но еще и сам транспорт. В этой библиотеке уже реализованны, синхронный / асинхронный сервер, и клиент, в отличии от protobuf.
В свое время гуглил и не нашел ответа. На сколько православно создавать новый транспорт/протокол/клиента на каждый запрос? Можно ли переиспользовать компоненты и как у них с многопоточностью дела? У вас был какой-то опыт такого использования?
В примере, который я привел, как раз многопоточная реализация сервера, средствами thrift. А вот клиент — не потокобезопасен, но его не сложно допилить. Про новый клиент — на каждый запрос, не совсем понял, что вы имели ввиду.
Меня интересует клиент.

Вы пишете в методе main:
TTransport transport = new TFramedTransport(new TSocket("localhost", 9090));
TProtocol protocol = new TBinaryProtocol(transport);
final FastHandsService.Client client = new FastHandsService.Client(protocol);
...
transport.open();

client.put(...);


Вот интересно, если мне надо много раз пописать клиентом (client.put()), что из этих объявлений можно переиспользовать? Если да, то что можно запихать в пул? Что можно переиспользовать в многопоточной среде (client.put() делается из нескольких потоков)?
client.put — можете вызывать сколько угодно раз. До тех пор, пока не закрыли сессию transport.close();
А вот вызывать методы этого клиента из другого потока не получиться. Надо в каждом потоке создавать своего клиента (полностью делать то что у меня описанно в main)
Sign up to leave a comment.

Articles