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." >
