thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Re: PHP Client fails to read correct return values from the Java Service
Date Fri, 15 Jan 2010 05:12:15 GMT
On Thu, Jan 14, 2010 at 6:36 PM, Mark Slee <mslee@facebook.com> wrote:

> Would need more info to debug this. Do you mind sharing more of your server
> implementation code? The client code looks fine to me. I'm not really clear
> on how you'd get the result of an old call when you're using a new socket
> each time, unless there is a bug with PHP's underlying persistent socket
> implementation leaving old data in the socket buffer (I've never seen this
> before, and it seems like it would create major problems if this could ever
> happen -- I would have assumed that pfsockopen() would always reset the recv
> buffer).
>
>
Isn't it impossible/racey for PHP to guarantee this? That is to say, it can
*think* the buffer's clear, then hand off the socket to the client, and then
the packets arrive.

-Todd


> Can you try running this without using PHP persistent sockets? See if it
> fixes the issue to open/close a new socket every time?
>
> -----Original Message-----
> From: Utku Can Top├žu [mailto:utku@topcu.gen.tr]
> Sent: Tuesday, January 05, 2010 12:02 AM
> To: thrift-user@incubator.apache.org
> Subject: PHP Client fails to read correct return values from the Java
> Service
>
> Dear Thrift users and Developers,
>
> I've written a simple service which has the following thrift definition:
>
> service CounterService {
>        string increment(1:i64 itemId),
>        string getCount(1:i64 itemId),
> }
>
> In our system, we're using PHP as the client and Java as the Server,
> Following the sample client and server stub examples included in the
> tutorial package, I haven't made any big differences in both the Client and
> Server code (and of course never touched the auto-generated code);
>
> The Java Server makes use of the following simple stub:
>
> --Server.java--
> CounterHandler handler = new CounterHandler();
> CounterService.Processor processor = new CounterService.Processor(handler);
> TServerTransport serverTransport;
> serverTransport = new TServerSocket(8888);
> server = new TThreadPoolServer(processor, serverTransport);
> ---
>
> The CounterHandler implements CounterService.Iface
>
> In the PHP Client code I have,
>
> --Client.php--
> $server = '192.168.1.64';
> $socket = new TSocket($server, 8888, TRUE); //Using persistent connection
> to
> the Java Service
> $transport = new TBufferedTransport($socket, 1024, 1024);
> $protocol = new TBinaryProtocol($transport);
> $client = new CounterServiceClient($protocol);
> $transport->open();
> $jcount = $client->increment($auctionId);
> $transport->close();
> ---
>
> The problem is the fact that; under our production load (1500 persistent
> socket connections from 7 PHP clients, about a total of  300 requests per
> second), the PHP Client fails to get the correct increment(id) value from
> the Buffer, it somehow gets previous replies from the Server.
>
> I'm logging the Java Server transactions, the Java Server seems to work
> fine; I'm suspecting that the problem occurs because of the PHP client
> libraries.
>
> We are running PHP in lighttpd and fastcgi btw.
>
> Any comments on solving the problem is welcome.
>
> Regards,
> Utku
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message