[
https://issues.apache.org/jira/browse/THRIFT-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13637733#comment-13637733
]
Randy Abernethy commented on THRIFT-1915:
-----------------------------------------
I think bidirectional communications support is an important feature that
should be addressed as a standalone Jira.
In regard to Roger’s comment, perhaps 563 could be given a transparent fast
mode. Anytime the service string is 4 bytes or less it could be used as an i32
key. Thus if you want fast operations all you need do is keep your service IDs
4 chars or less. When the TMultiplexedProtocol sees a service ID <= 4 chars it
uses a message that begins with the separator followed by the 4 byte key and
then the normal “name” payload.
The TMultiplexedProcessor in this scenario would check byte 0 for the
separator, if found it would take the fast code path, no parsing just extract
the key and call through to the correct service. Should be as fast as the byte
solution. Longer service names would be processed as they are now. Calls
without a separator could invoke a default service. This would give us fast,
flexible and backward compatible in one package.However it works, I think a
fast key lookup would be nice.
Repurposing one of the Protocol version bytes seems problematic. It entangles
the multiplexing concern with the otherwise encapsulated operations of the
Protocol. It is really a message routing issue and plugging it into the message
name seems pretty logical. Onthe pragmatic side, there may be protocols out
there that implement TProtocol but have no spare bytes to use. For example, the
JSON Protocol Version is a text based number, could work, but starts getting
strange. The compact protocol has a one byte ID and a one byte Version packed
with the message type, leaving no obvious way to hook in the channel byte.
> Multiplexing Services
> ---------------------
>
> Key: THRIFT-1915
> URL: https://issues.apache.org/jira/browse/THRIFT-1915
> Project: Thrift
> Issue Type: Improvement
> Components: AS3 - Library, Build Process, C glib - Library, C# -
> Library, C++ - Library, Cocoa - Library, Compiler (General), D - Library,
> Delphi - Library, Deployment, Documentation, Erlang - Library, Go - Library,
> Haskell - Library, Java - Library, JavaME - Library, JavaScript - Library,
> Node.js - Library, OCaml - Library, Perl - Library, PHP - Library, Python -
> Library, Ruby - Library, Smalltalk - Library, Test Suite, Tutorial, Website
> Affects Versions: 1.0
> Reporter: Roger Meier
> Priority: Blocker
>
> This is the parent Topic for the 1.0 release to introduce *Multiplex
> Services* with Apache Thrift.
> We need sub tasks here to manage language support, test suite, documentation
> & co.
> e.g. integrate Multiplex Services into cross language test suite THRIFT-847
> via test/test.sh
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
