thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Duxbury (Commented) (JIRA)" <>
Subject [jira] [Commented] (THRIFT-66) Allow multiplexing multiple services over a single TCP connection
Date Fri, 13 Jan 2012 19:32:50 GMT


Bryan Duxbury commented on THRIFT-66:

I don't think it was ever 100% accepted that we wanted to add this additional complexity to
Thrift. Don't get me wrong, I can see how it would be useful, but it comes at a cost, and
none of the interested parties succeeded in championing through a change this significant.
> Allow multiplexing multiple services over a single TCP connection
> -----------------------------------------------------------------
>                 Key: THRIFT-66
>                 URL:
>             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:,,,
ReleaseWaitingReplyThreadsOnDisconnect.patch,,,,, Thrift Endpoints and Channels.vsd,,
> 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:!default.jspa
For more information on JIRA, see:


View raw message