On May 25, 2011, at 7:33 PM, Per Knudsgaard <[email protected]> wrote:
> Hi, > > I am having a small problem with a small client/server application and I am > hoping for an easy answer :) > > The server is written in python, the client is c++ and I am using thrift > with a buffered transport. I have tried TSimpleServer and TThreadedServer > with the same behavior. The thrift version is 0.5.0. > > What I am trying to do is have the client send oneway updates to the server > on a regular basis. Some of the updates are large (700+ bytes) and some are > smaller (10-20 bytes). What I am seeing is the following: > > > 1. I kill the python server (kill -9...) > > 2. The next message throws an exception on the client. > > 3. The client drops the message (single message loss is ok) and marks > the connection as failed. > > 4. Next message will cause a the connection to be re-opened before > being sent. > > At this point, the server will not get any messages (the message from 4 > will disappear, further messages will be dropped). Neither the server nor > the client will produce any indication that there is a problem. > > Looking at a tcpdump, I find that when the connection is re-opened in 4, > the message from 2 is re-sent followed by the new message. Well, it looks > like the first ~500 bytes from the first message are sent and the rest > dropped (it is hard to tell exactly what is dropped since I am using a > BinaryProtocol). Adding some instrumentation to the generated thrift code > finds it blocking in a read call, waiting for half a megabyte of data. I > assume that means that the parser went off the tracks when it didn't get the > full message? > > Does any of this sound familiar? How much of the client should be > re-created when a connection fails? > > Thanks, > > -- Per. I'd recommend trying the latest thrift release, your issue may have been fixed already. If that doesn't work you might try the latest snapshot release or straight from source control (can't recall which source control thrift is using). Chris
