[
https://issues.apache.org/jira/browse/THRIFT-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809122#comment-13809122
]
Jens Geyer edited comment on THRIFT-2243 at 10/30/13 2:14 PM:
--------------------------------------------------------------
Again, if you use TFramedTransport on one side, the other side must use it as
well. TFramedTransport adds a 4-byte header containing the total message
length. If the client sends a framed message, the server must be able to decode
that, otherwise it will not work.
I'm not sure but you seem to think, that a server implementation
(TSimpleServer, TNonblockingServer) and a transport (TBufferedTransport,
TFramedTransport) are comparable to each other, which is wrong. The transport
is the means which transports the data back and forth. The server
implementation is about how the incoming messages are processed. The
TWhateverServer implementations are all completely agnostic to protocol and
transport stack.
was (Author: jensg):
Again, if you use TFramedTransport on one side, the other side must use it as
well. TFramedTransport adds a 4-byte header containing the total message
length. If the client sends a framed message, the server must be able to decode
that, otherwise it will not work.
I'm not sure but you seem to thin, that a server implementation (TSimpleServer,
TNonblockingServer) and a transport (TBufferedTransport, TFramedTransport) are
comparable to each other, which is wrong. The transport is the means which
transports the data back and forth. The server implementation is about how the
incoming messages are processed. The TWhateverServer implementations are all
completely agnostic to protocol and transport stack.
> TNonblockingServer in thrift crashes when TFramedTransport opens
> ----------------------------------------------------------------
>
> Key: THRIFT-2243
> URL: https://issues.apache.org/jira/browse/THRIFT-2243
> Project: Thrift
> Issue Type: Bug
> Affects Versions: 0.8, 0.9.1
> Environment: Ubuntu 12.04
> Reporter: julien greard
> Priority: Blocker
>
> This bug is also a question on StackOverflow, the code extracts are easier to
> read here :
> http://stackoverflow.com/questions/19586340/tnonblockingserver-in-thrift-crashes-when-tframedtransport-opens
> I've been trying to implement a thrift server in C++ to communicate with a
> Python client.
> here is my code:
> C++ server:
>
> shared_ptr<ThriftHandler> _handler (new myHandler());
> shared_ptr<TProcessor> _processor (new myService(_handler));
> shared_ptr<TProtocolFactory> _protocolFactory (new
> TBinaryProtocolFactory());
> shared_ptr<ThreadManager> _threadManager =
> ThreadManager::newSimpleThreadManager(15);
> shared_ptr<PosixThreadFactory> _threadFactory(new PosixThreadFactory());
> _threadManager->threadFactory(_threadFactory);
> _threadManager->start();
> shared_ptr<TNonblockingServer> _server(new TNonblockingServer(_processor,
> _protocolFactory, 9090 ,_threadManager));;
> _server->serve();
> Python Client code:
> transport = TSocket.TSocket(host, port)
> transport = TTransport.TFramedTransport(transport)
> protocol = TBinaryProtocol.TBinaryProtocol(transport)
> client = MyService.Client(protocol)
> transport.open()
> log.info("connection success!")
> When I start the server and then the client, I get the following:
> On the client side (Python):
> ./myPythonExec.py
> connection success!
> socket.error: [Errno 104] Connection reset by peer
> On the server side (c++):
> assertion " 0 " failed
> 0 0x00007ffff0942425 in __GI_raise (sig=<optimized out>) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> 1 0x00007ffff0945b8b in __GI_abort () at abort.c:91
> 2 0x00007ffff093b0ee in __assert_fail_base (fmt=<optimized out>,
> assertion=0x7ffff1438f1a "0",
> file=0x7ffff1439298 "src/server/TNonblockingServer.cpp", line=<optimized
> out>, function=<optimized out>) at assert.c:94
> 3 0x00007ffff093b192 in __GI___assert_fail (assertion=0x7ffff1438f1a
> "0", file=0x7ffff1439298 "src/server/TNonblockingServer.cpp",
> line=558, function=0x7ffff1439c60 "void
> apache::thrift::server::TNonblockingServer::TConnection::workSocket()") at
> assert.c:103
> 4 0x00007ffff14336e4 in
> apache::thrift::server::TNonblockingServer::TConnection::workSocket
> (this=0x7fffc0004ac0)
> at src/server/TNonblockingServer.cpp:558
> 5 0x00007ffff11ed94c in event_base_loop () from
> /usr/lib/libevent-2.0.so.5
> I've tested this bug on thrift 0.8.0 and 0.9.1
> It works perfectly when using a TSimpleServer on C++ and a TBufferedTransport
> on the client side
--
This message was sent by Atlassian JIRA
(v6.1#6144)
