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" <[email protected]> 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 > > >
