[jira] [Closed] (THRIFT-1429) The nonblocking servers is supposed to use TransportFactory to read the data

["Jake Farrell (Closed) (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jake Farrell closed THRIFT-1429.
--------------------------------

    Resolution: Fixed
      Assignee: Bryan Duxbury

Committed
                
> 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
>            Assignee: Bryan Duxbury
>            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