Thanks Mike. Kind Regards,
On Tue, May 27, 2014 at 10:13 PM, Mike Riley <[email protected]> wrote: > Why bother having different ports? Wouldn't each instance just handle the > same types of requests? There is nothing preventing you from load > balancing thrift servers the same way you would balance any other service, > such as HTTP traffic. You could put mongrel or whatever your balancer of > choice is in between the client and server instances and have it distribute > requests between them the same way you would with any TCP/IP based traffic. > Request/response is still the basic model for a thrift request, there > generally isn't too much magic taking place at the transport level that > will prevent traditional load balancers from slotting into place, even in > the case of async / nonblocking requests. > > > On Tue, May 27, 2014 at 3:03 PM, Phillip Simbwa <[email protected]> wrote: > >> And on some unrelated note; is it possible to load balance on multiple >> server instances for scalability? >> >> Think of it like; >> >> server1 -- port 9090 >> server2 -- port 9091 >> server3 -- port 9092 >> server4 -- port 9093 >> >> And each of the server apps is running as a TThreadedServer. >> >> Now with multiple server apps running, I hope to serve more concurrent >> client requests per second. >> >> How can I go about the load balancing? >> >> Has anyone done something like that? >> >> >> >> On Tue, May 27, 2014 at 9:55 PM, Phillip Simbwa <[email protected]> wrote: >> > @Mike: >> > Will definitely consider implementing that. >> > >> > Thanks Aaron and Mike for your help. >> > >> > Really appreciate it. >> > >> > >> > On Tue, May 27, 2014 at 9:39 PM, Mike Riley <[email protected]> >> wrote: >> >> This is probably the single most common error that anyone will see when >> >> they try to set up thrift, it usually means that your server is >> outputting >> >> something other than the output generated by thrift, and particularly in >> >> the case of PHP, it's most commonly just an error, warning or notice >> that >> >> gets emmitted and not handled elsewhere, hence output along with the >> rest >> >> of your thrift bytes. The client sees this as nonsense and freaks out. >> >> >> >> The best way to debug this is: >> >> >> >> set display_errors=0 >> >> install your own error handler for the more serious problems that logs >> them >> >> somewhere, but doesn't output them >> >> catch all exceptions thrown during the duration of your thrift RPC call >> and >> >> throw them back over the wire using some kind of generic extension to >> >> TException so that the client can interpret them >> >> >> >> you should be able to diagnose the problem using a combination of your >> >> error logs and inspecting any thrown exceptions client side >> >> >> >> >> >> >> >> On Tue, May 27, 2014 at 2:31 PM, Phillip Simbwa <[email protected]> >> wrote: >> >> >> >>> @Aaron: >> >>> >> >>> Thanks for your quick response. >> >>> >> >>> Let me look into that and see.. >> >>> >> >>> Thanks >> >>> >> >>> >> >>> On Tue, May 27, 2014 at 8:07 PM, Aaron Mefford <[email protected]> >> wrote: >> >>> > Have you verified that the Protocol and Transport on each end are the >> >>> same? >> >>> > Are you using a client with the same generated stubs, or is the >> client in >> >>> > another language? >> >>> > >> >>> > It looks like the server was expecting to read more bytes than it was >> >>> sent. >> >>> > This would seem to point to some difference in expectations between >> the >> >>> > client and the server. For instance, if the client were using the >> >>> compact >> >>> > binary protocol it would be sending fewer bytes than would be >> expected by >> >>> > the standard binary protocol. >> >>> > >> >>> > I am by no means an expert in Thrift or PHP but wanted to offer my >> >>> > observations in case they happen to help you find your problem. >> >>> > >> >>> > >> >>> > On 5/27/14, 11:00 AM, Phillip Simbwa wrote: >> >>> >> >> >>> >> Greetings, >> >>> >> >> >>> >> I think the thrift-0.9.1 php libs have a bug somewhere. I seem to >> get >> >>> >> this when I try to read the returned values from a client RPC call. >> >>> >> >> >>> >> >> >>> >> 2014/05/27 18:56:54 [error] 8129#0: *9 FastCGI sent in stderr: "PHP >> >>> >> message: PHP Fatal error: Uncaught exception >> >>> >> 'Thrift\Exception\TTransportException' with message 'TSocket: timed >> >>> >> out reading 4 bytes from localhost:9090' in >> >>> >> >> /usr/local/src/thrift-0.9.1/lib/php/lib/Thrift/Transport/TSocket.php:274 >> >>> >> Stack trace: >> >>> >> #0 >> >>> >> >> >>> >> /usr/local/src/thrift-0.9.1/lib/php/lib/Thrift/Transport/TTransport.php(74): >> >>> >> Thrift\Transport\TSocket->read(4) >> >>> >> #1 >> >>> >> >> >>> >> /usr/local/src/thrift-0.9.1/lib/php/lib/Thrift/Transport/TBufferedTransport.php(113): >> >>> >> Thrift\Transport\TTransport->readAll(4) >> >>> >> #2 >> >>> >> >> >>> >> /usr/local/src/thrift-0.9.1/lib/php/lib/Thrift/Protocol/TBinaryProtocol.php(305): >> >>> >> Thrift\Transport\TBufferedTransport->readAll(4) >> >>> >> #3 >> >>> >> >> >>> >> /usr/local/src/thrift-0.9.1/lib/php/lib/Thrift/Protocol/TBinaryProtocol.php(197): >> >>> >> Thrift\Protocol\TBinaryProtocol->readI32(NULL) >> >>> >> #4 /srv/www/vhosts/async/lib/v1/php/gen-php/wiadSysAPIv1.php(114): >> >>> >> Thrift\Protocol\TBinaryProtocol->readMessageBegin(NULL, 0, 0) >> >>> >> #5 /srv/www/vhosts/async/lib/v1/php/gen-php/wiadSysAPIv1.php(82): >> >>> >> wiadSysAPIv1Client->recv_createUser() >> >>> >> >> >>> >> >> >>> >> And my .thrift file looks like this: >> >>> >> >> >>> >> struct useraccount { >> >>> >> 1:i64 uid, >> >>> >> 2:string owner, >> >>> >> 3:string email, >> >>> >> 4:string passwd, >> >>> >> 5:i32 enabled, >> >>> >> 6:i32 deleted, >> >>> >> 7:i32 gid, >> >>> >> 8:string creator >> >>> >> } >> >>> >> >> >>> >> struct auditf { >> >>> >> 1:string schema, >> >>> >> 2:string table, >> >>> >> 3:i64 uid, >> >>> >> 4:i64 gid, >> >>> >> 5:string account, >> >>> >> 6:string ip, >> >>> >> 7:string qtype, >> >>> >> 8:string vafter, >> >>> >> 9:string vbefore, >> >>> >> 10:string detail >> >>> >> } >> >>> >> >> >>> >> service wiadSysAPIv1 { >> >>> >> i32 ping(), >> >>> >> string createUser(1:auditf af, 2:useraccount u) >> >>> >> } >> >>> >> >> >>> >> >> >>> >> Can someone advise on how I can get around this? >> >>> >> >> >>> >> >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> - Phillip. >> >>> >> >>> "Aoccdrnig to rscheearch at an Elingsh uinervtisy, it deosn't mttaer in >> >>> waht >> >>> oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the >> frist >> >>> and lsat ltteer are in the rghit pclae. >> >>> The rset can be a toatl mses and >> >>> you can sitll raed it wouthit a porbelm. Tihs is bcuseae we do not raed >> >>> ervey lteter by it slef but the wrod as a wlohe and the biran fguiers >> it >> >>> out aynawy." >> >>> >> > >> > >> > >> > -- >> > - Phillip. >> > >> > "Aoccdrnig to rscheearch at an Elingsh uinervtisy, it deosn't mttaer in >> waht >> > oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the >> frist >> > and lsat ltteer are in the rghit pclae. >> > The rset can be a toatl mses and >> > you can sitll raed it wouthit a porbelm. Tihs is bcuseae we do not raed >> > ervey lteter by it slef but the wrod as a wlohe and the biran fguiers it >> > out aynawy." >> >> >> >> -- >> - Phillip. >> >> "Aoccdrnig to rscheearch at an Elingsh uinervtisy, it deosn't mttaer in >> waht >> oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist >> and lsat ltteer are in the rghit pclae. >> The rset can be a toatl mses and >> you can sitll raed it wouthit a porbelm. Tihs is bcuseae we do not raed >> ervey lteter by it slef but the wrod as a wlohe and the biran fguiers it >> out aynawy." >> -- - Phillip. "Aoccdrnig to rscheearch at an Elingsh uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist and lsat ltteer are in the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit a porbelm. Tihs is bcuseae we do not raed ervey lteter by it slef but the wrod as a wlohe and the biran fguiers it out aynawy."
