[
https://issues.apache.org/jira/browse/THRIFT-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Duxbury updated THRIFT-1429:
----------------------------------
Attachment: thrift-1429.patch
I just cooked this up, and it seems to enforce the transport factory on the
server-read side as well as on the server-write side. Feel like trying this out?
> The nonblocking servers is supposed to use TransportFactory to read the data
> ----------------------------------------------------------------------------
>
> Key: THRIFT-1429
> URL: https://issues.apache.org/jira/browse/THRIFT-1429
> Project: Thrift
> Issue Type: Bug
> Affects Versions: 0.7
> Reporter: Jerome Boulon
> Priority: Blocker
> Fix For: 0.9
>
> Attachments: thrift-1429.patch
>
>
> The nonblocking servers (TNonblockingServer) presume that you are using a
> framed transport and use that information to read the data as though it were
> framed. However, once it is loaded into memory, it is supposed to be wrapped
> up in the transport that the transport factory returns so that we can do
> post-processing.
> This does not seems to be the case anymore.
> Use case: Implement another transport on top of TFramedTransport
> For testing purposed I wrapped a TFramedTransport inside another
> TFramedTransport.
> On the client side:
> transport = new TFramedTransport(socket);
> TTransport transport2 = new TFramedTransport(transport);
> protocol = new TBinaryProtocol(transport2);
> transport2.open();
> service = new MyService.Client(protocol);
> long count = service.getCounter("My counter");
> On the server side:
> serverTransport = new TNonblockingServerSocket(port);
> processor = new MyService.Processor(new ServerIMPL());
> THsHaServer.Args options = new THsHaServer.Args(serverTransport);
> options.workerThreads(1);
> options.processor(processor);
> options.transportFactory(new TFramedTransport.Factory());
> server = new THsHaServer(options);
> I'm getting this exception:
> 2385 [pool-1-thread-1] WARN org.apache.thrift.server.TNonblockingServer -
> Exception while invoking!
> org.apache.thrift.transport.TTransportException: Cannot read. Remote side has
> closed. Tried to read 1 bytes, but only got 0 bytes. (This is often
> indicative of an internal error on the server side. Please check your server
> logs.)
> at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
> at
> org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:378)
> at
> org.apache.thrift.protocol.TBinaryProtocol.readByte(TBinaryProtocol.java:264)
> at
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:215)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:22)
> at
> org.apache.thrift.server.TNonblockingServer$FrameBuffer.invoke(TNonblockingServer.java:651)
> at org.apache.thrift.server.THsHaServer$Invocation.run(THsHaServer.java:201)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:680)
> private TTransport getInputTransport() {
> return new TMemoryInputTransport(buffer_.array());
> }
> Why the buffer is not wrapped by the transportFactory similarly to the
> getOutputTransport's method?
> This method looks suspicious to me but I'm not familiar with
> TNonblockingServer so ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
