Hello! Thrift is still a dedicated client/server model environment where clients can request and servers reply. The easiest way to make it 2-way today is to open a connection both ways. If you don't have firewalls in the way then you can do this effectively. The more difficult and more correct way to do it would be to rewrite the transport layer to use endpoints in which each side can be a client and/or server for any number of services (using TMultiplexedProtocol on top of another protocol, like TBinaryProtocol). This design allows one end to be a "listener", one end to be an "initiator" (starts the connection), and after they connect they are equal peers with the ability to request or reply of each-other.
You can approximate asynchronous behavior by exclusively using "oneway" requests in your design. I'd suggest avoiding use of oneway requests with THttpProtocol varieties however as today there are some issues, since Http transport requires a response to be sent, and "oneway" dictates there is no reply, and most languages do not handle it well right now (there are open backlog issues for this). For a matrix of supported languages, protocols, transports, and server types, see the file LANGUAGES.md at the root of the github repository. Another idea I was toying with a while ago was to add a message bus transport to Thrift which would allow for things like reliable delivery and broadcast semantics but that also does not exist today. - Jim On Wed, May 15, 2019 at 1:05 AM John Dougrez-Lewis <jle...@lightblue.com> wrote: > > Hi, > > > > I was looking for a mechanism to be able to provide language-agnostic API > support to a hobby project I've been working on for some time. > > > > By following a trail of papers, books and references, I eventually came > across Apache Thrift and have found and started going through Randy > Abernethy's new book. > > > > > > Essentially what I was looking for was support for asynchronous calls, and > by extension, pub/sub and two way communication across and between multiple > languages over some channel, preferably IPC but in the worst case sockets. > > > > > > Having read the book, I can see that there is support for basic synchronous > RPC between a client and a server over a significant number of languages and > for just a very few languages, such as java, some element of support for > asynchronous callbacks, and otherwise one-way methods that do not provide > indication of subsequent failure. > > > > It appeared to me one way of extending bi-directional asynchronous support > would be to have the client to set itself up as a server for the server at > the other end to connect to, and then it would just be a question of > choreographing the setting up of a pair of RPC channels. > > > > An asynchronous call could be implemented by providing a synchronous method > that simply immediately returns a handle to the caller, and the server would > then continue to process the call request on a background threadpool thread > on the server, and the async result would then be signalled by a call from > the server back to the client on the 2nd channel with the handle providing a > context to lookup the result. > > > > Pub/sub would just then be multiple calls from the server back to the > client. > > > > The whole thing could sit on top of the existing unidirectional RPC > implementation and provide full asynchronous calls & pub/sub across *ALL* > supported languages at probably very little additional effort, with no > changes to the existing code. > > > > You could then have a framework that extended the existing IDL to include > decoration with attributes for async & pub/sub methods & in/out parameters. > > > > This extended IDL could then be pre-processed to generate client-server and > server-client service definitions in the existing base IDL language, > together with generating supporting glue code to compile to provide the > support for hooking up the channels between each side. > > > > I note that THRIFT-66 was raised 10 years ago, but it looks like the C# code > was never made available for release by Dell. > > > > I have some questions: > > > > 1) What is the current state of plans for this supporting this sort of > functionality? What issues have been encountered ? > > > > 2) Is there a document/spreadsheet somewhere showing a matrix of what > Transports and Protocols are supported for each language? > > > > > > Regards, > > > > John > > > > > > >
