Mailing-List: contact dev-help@thrift.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@thrift.apache.org
Date: Fri, 13 Jan 2012 19:32:50 +0000 (UTC)
From: "Bryan Duxbury (Commented) (JIRA)" <jira@apache.org>
To: dev@thrift.apache.org
Message-ID: 
 <107609220.38742.1326483170401.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (THRIFT-66) Allow multiplexing multiple services
 over a single TCP connection
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/THRIFT-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185786#comment-13185786 ] 

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: 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