[
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
