Hello Mark,
I tried disabling the persistent connections and it worked fine without any
problem, however this time I've faced a serious connection overhead in a few
moments.
Here's the sample server code; I've just taken it from the tutorial.
try {
CounterHandler handler = new CounterHandler();
CounterService.Processor processor = new CounterService.Processor(handler);
TServerTransport serverTransport;
serverTransport = new TServerSocket(8888);
TServer server = new TThreadPoolServer(processor, serverTransport);
logger.info("Starting the server...");
server.serve();
} catch (TTransportException e) {
}
Where CounterHandler implements CounterService.Iface
public class CounterHandler implements CounterService.Iface {
.
.
public String increment(long auctionId) throws TException {
CounterWorker worker = CounterWorker.getInstance(); //Singleton
Worker
long count = worker.increment(auctionId, 1); //increment the
counter of the id by one
logger.info("increment("+auctionId + "):" + count + "\t[csize:"
+ worker.counterSize() +
",isize:"+worker.incrementSize()+"][call:" + callCount + "]");
return String.valueOf(count);
}
...
what basically CounterWorker's "long increment(long id, long increment)"
method does is, execute two simple update and select queries on MySQL by
making use of connection pooling.
The problem is the fact that, I'm just calling the increment method from the
PHP Client, and somehow the returning result belongs to a different id from
the provided one.
I fear the problem occurs after several timeouts on client side.
Thanks for your helps and comments,
Utku
On Fri, Jan 15, 2010 at 7:12 AM, Todd Lipcon <[email protected]> wrote:
> 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
> >
>
