Yes, you're right. That's definitely possible, and it sounds like that's probably what is happening here.
I was referring to was the fact that persistent sockets are never shared across separate apache processes (in the OS sense), so the pfsockopen() call should only return a socket that's done being used by the last page request. I was wrongly assuming the last page request properly completed use of the socket. If the client side experiences a read timeout, it'll close up making it possible for a subsequent request to get that same socket later, and then the server response will come back. The right fix for this is to build proper sequence-id validation into the PHP client code. We actually do send a unique sequence id with each RPC request that should be echoed back by the server, but currently we're not tracking state in the client to match these. Cheers, Mark -----Original Message----- From: Todd Lipcon [mailto:[email protected]] Sent: Thursday, January 14, 2010 9:12 PM To: [email protected] Subject: Re: PHP Client fails to read correct return values from the Java Service On Thu, Jan 14, 2010 at 6:36 PM, Mark Slee <[email protected]> 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:[email protected]] > Sent: Tuesday, January 05, 2010 12:02 AM > To: [email protected] > 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 >
