Java client and server in the same JVM

[Tamás Varga <Ta...@ericsson.com>]

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

Re: Java client and server in the same JVM

[Mark Slee <ms...@fb.com>]

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" <Ta...@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
>
>
>