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.
