Apache thrift: client timeout issues

Question

I have some Apache Thrift (v.0.6.1) test application with perl-server and php-client.

The behaviour I cannot explain: If we call server-method with invalid argument we see the error in server-output, but php-client stays waiting the response infinitely.

Here are the sources of server:

sub new {
    my $classname = shift;
    my $self      = {};

    return bless($self,$classname);
}

sub DateToTimestamp
{
    my ($self, $date) = @_;
    my $result = CommonAPI::DateToTimestamp($date);
    return $result;
}

eval {
  my $handler       = new RPCHandler;
  my $processor     = new RPCPerformanceTest::RPCPerformanceTestProcessor($handler);
  my $serversocket  = new Thrift::ServerSocket(9091);
  my $forkingserver = new Thrift::ForkingServer($processor, $serversocket);
  print "Starting the server...\n";
  $forkingserver->serve();
  print "done.\n";
}; if ($@) {
  if ($@ =~ m/TException/ and exists $@->{message}) {
    my $message = $@->{message};
    my $code    = $@->{code};
    my $out     = $code . ':' . $message;
    die $out;
  } else {
    die $@;
  }
}

and client:

try {

    $socket = new TSocket($server_host, $server_port);

    $transport = new TBufferedTransport($socket, 1024, 1024);
    $protocol = new TBinaryProtocol($transport);

    $client = new RPCPerformanceTestClient($protocol);
    $transport->open();

    $start = microtime(true);

    $result = $client->DateToTimestamp('071/26/2011 01:23:45');

    var_dump($result);

} catch (Exception $e) {
    echo 'Exception: <b>' . $e->getMessage() . '</b>';
}

Why is this happening? Is it my fault? Is it expected behavour?

Answer 1

The Thrift PHP library is a bit broken. You need to manually set the timeouts Eg

  $socket = new TSocket('host', 9095);
  $socket->setSendTimeout(60000);
  $socket->setRecvTimeout(60000)

Answer 2

This happens often with protocols that do not supply message length: a client sends more data then the server expects and waits for the server to receive the data. The server receives some of the data, tries to parse it and fails. Now the server-side of the protocol is in errorneous state. If it continues to read the data, it may block. Most probably, the server-side has sent you some error response and is waiting at the same time for the client to receive the response, but that will never happen too.

This is my guess. The best strategy IMHO is to set a time-out for both client and server sockets.