If you are in the same JVM, you don't need to use the client/server
bridge. Note that the service client and the service implementation both
conform to the same interface.
>> 1) Which Protocol/Transport combination do you recommend for this
>>scenario ?
Your java "client" can directly use an instance of the service interface.
This will bypass serialization/deserialization costs entirely and does not
even involve the Protocol/Transport stack.
e.g. Psuedocode
TProtocol protocol = new TBinaryProtocol();
TTransport transport = new TSocket();
ServiceIf client = new ServiceClient(protocol, transport)
can just be:
ServiceIf client = new ServiceHandler(); // or grab shared instance of
your handler
>> 2) What is the overhead of client-server to as if it were a simple
>>"shortcut" (no IPC/RPC) ?
With the above, there is no overhead. If you use the loopback interface
you will pay serialization/deserialization costs on your requests.
>> 3) If there is considerable client-server bottleneck, is there
>>alternate ways of using Thrift IPC/RPC-less manner in Java?
Yep, as described above. Use the service handler object directly.
Cheers,
Mark
On 7/31/12 1:44 AM, "Tamás Varga" <Tamas.Varga@ericsson.com> wrote:
>Hi Thrifters,
>
>Assume an existing Thrift interface between C++ client and Java server.
>The requirement is to have the client also in Java, thus keeping Thrift
>interface seems reasonable for both C++ and Java clients. In case of
>Java client and server, however, both functionality is planned to be run
>in the same JVM because the customer expects more efficient communication
>(avoiding IPC). The questions:
>
>
>1) Which Protocol/Transport combination do you recommend for this
>scenario ?
>
>2) What is the overhead of client-server to as if it were a simple
>"shortcut" (no IPC/RPC) ?
>
>3) If there is considerable client-server bottleneck, is there
>alternate ways of using Thrift IPC/RPC-less manner in Java?
>
>Cheers
>Tamas Varga
>
>
>
|