[
https://issues.apache.org/jira/browse/THRIFT-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808528#comment-13808528
]
Jens Geyer commented on THRIFT-2243:
------------------------------------
{quote}
It works perfectly when using a TSimpleServer on C++ and a TBufferedTransport
on the client side
{quote}
Wait, what? Could it be that you made the same mistake?
It#s recommended to use the same protocol stack on both client and server. If
you use a framed transport on one side, you have to use it on the other side as
well. If the server does not use framed, then the client must not use framed as
well.
It works with buffered because you are lucky. Ok, here's the technical
explanation: Framed writes another 4 bytes in from of the message, while
buffered does not do this. In other words, buffered does not change the
message, but framed does. But that's an implementation detail.
Sorry, have not seen that earlier. But I had just the same issue on SO again.
If that solves the issue please close the ticket.
> 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)
