You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Gaurav Sakhardande <ga...@persistent.co.in> on 2013/05/15 15:29:34 UTC
Exact use of TMemoryBuffer in real-time environments
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
gaurav_sakhardande@persistent.co.in<ma...@persistent.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.
RE: Exact use of TMemoryBuffer in real-time environments
Posted by Gaurav Sakhardande <ga...@persistent.co.in>.
Thanks Randy. That was helpful.
Regards,
Gaurav Sakhardande | Software Engineer | Platform Solutions
gaurav_sakhardande@persistent.co.in | Cell : +91 9552027729
Persistent Systems Ltd. | Hinjewadi, Pune - 411 057 | Partners in Innovation |
www.persistentsys.com
________________________________________
From: Randy Abernethy [Randy.Abernethy@rx-m.com]
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
> gaurav_sakhardande@persistent.co.in | Cell : +91 9552027729
> Persistent Systems Ltd. | Hinjewadi, Pune - 411 057 | Partners in Innovation |
> www.persistentsys.com
>
> -----Original Message-----
> From: Randy Abernethy [mailto:Randy.Abernethy@rx-m.com]
> Sent: Wednesday, May 15, 2013 9:41 PM
> To: user@thrift.apache.org
> 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
>> gaurav_sakhardande@persistent.co.in<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
> randy.abernethy@rx-m.com
> 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
randy.abernethy@rx-m.com
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.
RE: Exact use of TMemoryBuffer in real-time environments
Posted by Gaurav Sakhardande <ga...@persistent.co.in>.
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
gaurav_sakhardande@persistent.co.in | Cell : +91 9552027729
Persistent Systems Ltd. | Hinjewadi, Pune - 411 057 | Partners in Innovation |
www.persistentsys.com
-----Original Message-----
From: Randy Abernethy [mailto:Randy.Abernethy@rx-m.com]
Sent: Wednesday, May 15, 2013 9:41 PM
To: user@thrift.apache.org
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
> gaurav_sakhardande@persistent.co.in<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
randy.abernethy@rx-m.com
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.
Re: Exact use of TMemoryBuffer in real-time environments
Posted by Randy Abernethy <Ra...@rx-m.com>.
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
> gaurav_sakhardande@persistent.co.in<ma...@persistent.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
randy.abernethy@rx-m.com
Cell: +1-415-624-6447
San Francisco: +1-415-800-2922
Tokyo: +81-50-5532-8040
www.rx-m.com
@rxmllc