It is possible, but as far as I can tell you need to use one service in your thrift file, it won't work with multiple services. See Joel Meyer's example for a bi-directional Thrift application at https://github.com/JoelPM/BidiThrift
Caveat: I could not get his example to work using HTTP, only with normal TCP. -Shaun On Sun, Jan 15, 2012 at 4:09 PM, Nevo Hed (Commented) (JIRA) < [email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/THRIFT-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13186617#comment-13186617] > > Nevo Hed commented on THRIFT-66: > -------------------------------- > > You can use rpc ... We try to be somewhat Async for scalability > On Sunday, January 15, 2012, Pedro Algarvio (Commented) (JIRA) < > > https://issues.apache.org/jira/browse/THRIFT-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13186525#comment-13186525 > ] > Erlang - Library, Java - Library, Perl - Library, Python - Library, Ruby - > Library > MultiplexTestServerMain.java, ReleaseWaitingReplyThreadsOnDisconnect.patch, > SharedImpl.java, TMultiplexServer.java, TMultiplexServer.py, > TSimpleMultiplexServer.java, Thrift Endpoints and Channels.vsd, > ThriftCSharpEndpointsChannels.zip, ThriftMultiplexInvocationHandler.java > port. If an application has many services many ports have to be opened. > This is cumbersome because: > remembering the port numbers is difficult > to maintain to many connections: at least one to each port > client and the server. > are resolved: > with a (new) {{SERVICE_SELECTION}} message. It is not necessary to modify > or wrap the response. No changes are needed to the generated classes. Only > a new type of server is introduced, and an invocation handler for a dynamic > proxy around the {{Client}} classes of services is provided for the client > side. The implementation does not handle communication errors (invalid > data, timeouts, etc.) yet. > administrators: > https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa > > > > Allow multiplexing multiple services over a single TCP connection > > ----------------------------------------------------------------- > > > > Key: THRIFT-66 > > URL: https://issues.apache.org/jira/browse/THRIFT-66 > > Project: Thrift > > Issue Type: New Feature > > Components: C# - Library, C++ - Library, Cocoa - Library, > Erlang - Library, Java - Library, Perl - Library, Python - Library, Ruby - > Library > > Reporter: Johan Stuyts > > Priority: Trivial > > Attachments: CalculatorImpl.java, MultiplexTestClientMain.java, > MultiplexTestServerMain.java, ReleaseWaitingReplyThreadsOnDisconnect.patch, > SharedImpl.java, TMultiplexServer.java, TMultiplexServer.py, > TSimpleMultiplexServer.java, Thrift Endpoints and Channels.vsd, > ThriftCSharpEndpointsChannels.zip, ThriftMultiplexInvocationHandler.java > > > > > > The current {{TServer}} implementations expose a single service on a > port. If an application has many services many ports have to be opened. > This is cumbersome because: > > - you have to document which service is available on which port, and > remembering the port numbers is difficult > > - to prevent the overhead of connection setup on each call, a client has > to maintain to many connections: at least one to each port > > - it requires opening many ports on a firewall if one is between the > client and the server. > > By multiplexing multiple services on a single port the problems above > are resolved: > > - instead of a port number a symbolic name can be assigned to a service > > - a client can maintain a small pool of connections to a single port > > - only one port has to be opened on the firewall > > The attached Java implementation simply wraps a normal {{CALL}} message > with a (new) {{SERVICE_SELECTION}} message. It is not necessary to modify > or wrap the response. No changes are needed to the generated classes. Only > a new type of server is introduced, and an invocation handler for a dynamic > proxy around the {{Client}} classes of services is provided for the client > side. The implementation does not handle communication errors (invalid > data, timeouts, etc.) yet. > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators: > https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa > For more information on JIRA, see: http://www.atlassian.com/software/jira > > >
