Thanks Randy. That was helpful. Regards,
Gaurav Sakhardande | Software Engineer | Platform Solutions [email protected] | Cell : +91 9552027729 Persistent Systems Ltd. | Hinjewadi, Pune - 411 057 | Partners in Innovation | www.persistentsys.com ________________________________________ From: Randy Abernethy [[email protected]] Sent: Friday, May 17, 2013 4:14 PM To: Gaurav Sakhardande Subject: Re: Exact use of TMemoryBuffer in real-time environments Hello Gaurav, Yes I think TIOStreamTransport is a good fit for you. You will need to set up a pair of java.io.PipedInputStream/java.io.PipedOutputStream objects to actually provide the stream buffers. Simple example of the transport setup below. Best, Randy import java.io.IOException; import java.io.PipedInputStream; import java.io.PipedOutputStream; import org.apache.thrift.TException; import org.apache.thrift.protocol.TBinaryProtocol; import org.apache.thrift.protocol.TProtocol; import org.apache.thrift.transport.TIOStreamTransport; public class JavaApplication5 { static class SquareServer implements Runnable { private TProtocol proto; public SquareServer(TProtocol p) throws TException { proto = p; } @Override public void run() { try { int i = proto.readI32(); proto.writeI32(i * i); } catch (TException ex) { } } } public static void main(String[] args) throws IOException, TException { //Client ==> Server PipedOutputStream CliOut = new PipedOutputStream(); PipedInputStream SvrIn = new PipedInputStream(CliOut); //Server ==> Client PipedOutputStream SvrOut = new PipedOutputStream(); PipedInputStream CliIn = new PipedInputStream(SvrOut); //Client Transport & Protocol TIOStreamTransport cliTrans = new TIOStreamTransport(CliIn, CliOut); TBinaryProtocol cliProto = new TBinaryProtocol(cliTrans); //Server Transport & Protocol TIOStreamTransport svrTrans = new TIOStreamTransport(SvrIn, SvrOut); TBinaryProtocol svrProto = new TBinaryProtocol(svrTrans); //Start a simple protocol server on a background thread and test // roundtrip TIOStreamTransport SquareServer svr = new SquareServer(svrProto); Thread thread = new Thread(svr); thread.start(); cliProto.writeI32(2); System.out.println(cliProto.readI32()); } } On 5/15/2013 10:06 PM, Gaurav Sakhardande wrote: > Hi Randy, > > Thanks for a prompt reply! > > In the current scenario, we have RESTful web services exposed through api.war > and api.war communicates to server.war using Thrift (THttpClient through the > Thrift generated Client code). > > Since we now want to combine these 2 wars, we have created a jar of all > classes in server.war and added this jar to the classpath of api.war. Hence, > api.war can directly use the Thrift server code to call the business logic. > However, we want to make this configurable so that, in future the user is > free to switch to 2 wars. > > The type of implementation of TTransport seems to be the deciding the > deployment approach. Does TIOStreamTransport still seem to be a valid > alternative? > > Will surely try it and get back to you. > > Thanks again! > > > Regards, > > Gaurav Sakhardande | Software Engineer | Platform Solutions > [email protected] | Cell : +91 9552027729 > Persistent Systems Ltd. | Hinjewadi, Pune - 411 057 | Partners in Innovation | > www.persistentsys.com > > -----Original Message----- > From: Randy Abernethy [mailto:[email protected]] > Sent: Wednesday, May 15, 2013 9:41 PM > To: [email protected] > Subject: Re: Exact use of TMemoryBuffer in real-time environments > > Hello Gaurav, > > To provide a better response I would need to know what the server side looks > like but I can guess at a few issues you may be facing. > > The Java TMemoryBuffer is a bit different mechanically from THttpClient. > The THttpClient reads from a java.io.InputStream which will block the calling > thread until bytes are available. Many servers depend on this behavior. > > TMemoryBuffer reads internally from a byte array and will generate an error > if there are no bytes available. The first thing most servers do upon > connecting with a client is attempt to read which, rather than blocking, will > fail in this case. This will likely put the server off and it will ignore the > client from that point forward. > > Also TMemoryBuffer writes keep appending to the buffer and reads also advance > through the buffer. TMemoryBuffer writes attempt to grow the internal buffer > when it is not large enough. There is no natural mechanism to reset the > write/read position to the beginning meaning you will ultimately run out of > memory unless you manually intervene and reset the buffer. > > A TIOStreamTransport is probably what you want. You will need to setup one > for the client and one for the server, using perhaps opposite ends of > PipedInputStream/PipedOutputStream pairs for the stream objects. > > Cheers, > Randy > > > > On 5/15/2013 6:29 AM, Gaurav Sakhardande wrote: >> Hi, >> >> I have a project scenario in which there are two wars communicating using >> thrift. >> >> Thrift code is auto-generated in Java on Windows 7 which creates a >> service SampleService.java >> >> The relevant code block is as follows : >> >> THttpClient thc = new THttpClient(WAR2Url, httpClent); >> thc.setCustomHeader("Connection", "keep-alive"); >> >> TProtocol protocol = new TBinaryProtocol(thc); >> >> SampleService.Client client = new >> SampleService.Client(protocol); >> >> As you can observe, finally the Thrift generated client is used for >> communication. >> >> Now, the new requirements define that the two WARs be merged into one. >> >> The approach that we thought of is changing the code to the following to >> prevent too many code changes and still keep interoperability for using HTTP >> if required later : >> >> TTransport tt = new TMemoryBuffer(1024); >> >> TProtocol protocol = new TBinaryProtocol(tt); >> >> SampleService.Client client = new >> SampleService.Client(protocol); >> >> However, though the data seems to be written to the buffer, it does not seem >> to be read properly. Also, we wonder how efficient it would be to use this >> in real time environments where the load on the server would be large. >> >> We are open for any other way that this can be implemented. Any help would >> be really appreciated. >> >> Thanks a lot! >> >> >> Regards, >> >> Gaurav Sakhardande | Software Engineer | Platform Solutions >> [email protected]<mailto:gaurav_sakhardande@persiste >> nt.co.in> | Cell : +91 9552027729 Persistent Systems Ltd. | Hinjewadi, >> Pune - 411 057 | Partners in Innovation | www.persistentsys.com >> >> >> DISCLAIMER >> ========== >> This e-mail may contain privileged and confidential information which is the >> property of Persistent Systems Ltd. It is intended only for the use of the >> individual or entity to which it is addressed. If you are not the intended >> recipient, you are not authorized to read, retain, copy, print, distribute >> or use this message. If you have received this communication in error, >> please notify the sender and delete all copies of this message. Persistent >> Systems Ltd. does not accept any liability for virus infected mails. >> > > -- > Randy Abernethy > Managing Partner, RX-M, LLC > [email protected] > Cell: +1-415-624-6447 > San Francisco: +1-415-800-2922 > Tokyo: +81-50-5532-8040 > www.rx-m.com > @rxmllc > > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is the > property of Persistent Systems Ltd. It is intended only for the use of the > individual or entity to which it is addressed. If you are not the intended > recipient, you are not authorized to read, retain, copy, print, distribute or > use this message. If you have received this communication in error, please > notify the sender and delete all copies of this message. Persistent Systems > Ltd. does not accept any liability for virus infected mails. -- Randy Abernethy Managing Partner, RX-M, LLC [email protected] Cell: +1-415-624-6447 San Francisco: +1-415-800-2922 Tokyo: +81-50-5532-8040 www.rx-m.com @rxmllc DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.
