Thanks for this. I think this should work rather well.
On 6 June 2013 17:43, Mike Stanley <[email protected]> wrote: > may I suggest an alternative approach - a separate thrift service for each > smaller service, and a service registry for clients to locate/discover the > smaller services. rather than proxy, the registry would be used by > clients to lookup and get redirected to the smaller service. the service > registry abstraction gives deployment flexibility for each independent > service too. > > of course, I don't have the full picture, but I cannot help to think that a > central-registry solves the "clients needing to know where each small > service is", and also prevents the "proxy bottleneck" situation. > > > > > > On Thu, Jun 6, 2013 at 11:52 AM, Ben Craig <[email protected]> wrote: > >> Sine the methods are different, the best you would be forced to do at >> least partial de-serialization and serialization. The processor / >> dispatcher has to look at the method enough to know that this is >> "method1", and the forwarding code would need to rewrite that portion to >> say "method4". >> >> >> >> From: Glenn Pierce <[email protected]> >> To: [email protected], >> Date: 06/06/2013 10:47 AM >> Subject: Re: Proxy Thrift call >> Sent by: [email protected] >> >> >> >> On 6 June 2013 16:20, Henrique Mendonça <[email protected]> wrote: >> > hm... ok, that looks more like a delegation pattern, or façade as you >> said >> > before, simple application code then, methods from server1 calling the >> next >> > server. Not a very good performance since you'll need to deserialize the >> > messages and re-serialize it again, but it's not too bad unless you're >> > doing millions of requests per second ;) >> > >> >> Yeah may be the easiest way. >> Thought there may be a way to just forward on with de-serializing etc >> >> >> > but you should check out the new multiplexer too: >> > https://issues.apache.org/jira/browse/THRIFT-563 >> > then you need a different thrift service for each server and a central >> > multiplexer server >> >> Yeah I read that code. Unfortunately the server implementations are >> all implemented on the same >> host port which isn't necessarily so in my case. >> Though it may give me ideas for reimplementing some of the lower level >> abstractions. >> >> Thanks >> >> >> >> > >> > >> > On 6 June 2013 17:00, Glenn Pierce <[email protected]> >> wrote: >> > >> >> On 6 June 2013 12:02, Henrique Mendonça <[email protected]> wrote: >> >> > Hi Glenn, >> >> > Are your clients all implementations of the same service? >> >> >> >> No they would be the same service. >> >> >> >> The main server with have say the following interface >> >> >> >> void method1(); >> >> void method2(); >> >> void method3(); >> >> >> >> >> >> I would like another server to implement and provide >> >> >> >> void method4(); >> >> void method5(); >> >> void method6(); >> >> >> >> >> >> So I would like a scheme where the first main server provides 1 2 and >> >> 3 and proxies calls for 4,5,6 >> >> >> >> so the interface would be >> >> >> >> >> >> void method1(); >> >> void method2(); >> >> void method3(); >> >> void method4(); -> server2.method4(); >> >> void method5(); -> server2.method5(); >> >> void method6(); -> server2.method6(); >> >> >> >> >> >> > Just a quick thought, but I think you can write a ProxyTransport for >> your >> >> > server, which will take one or more clients as parameter. This client >> >> will >> >> > have to be also a ProxyClient, that again won't need a protocol to >> >> > function. >> >> > Then it will simply forward the messages to that given client, which >> will >> >> > be already connected to a single server. The problem will be that >> it'll >> >> > have to actively wait for the proxy client's response so you'll end >> up >> >> with >> >> > loads of open threads on your proxy server. >> >> > I hope it helps a bit ;) >> >> > >> >> > Best, >> >> > Henrique >> >> > >> >> > >> >> > On 6 June 2013 11:44, Glenn Pierce <[email protected]> >> >> wrote: >> >> > >> >> >> I'm not really looking for load balancing or any advanced routing. >> >> >> I guess its really to aid in a the design pattern of my app. >> >> >> My application consists on many small servers (plugins) and one main >> >> >> thrift interface server. >> >> >> So far these server have not had to talk to clients directly until >> now. >> >> >> >> >> >> I would like to provide a Thrift interface for one subserver but I >> >> >> don''t want clients to know about about all >> >> >> these small servers. The main server should provide a facade >> interface >> >> >> that simply forwards >> >> >> calls to the the correct server. >> >> >> >> >> >> >> >> >> On 5 June 2013 21:49, Mike Stanley <[email protected]> wrote: >> >> >> > I'm not entirely clear how much "intelligent routing" you want to >> do >> >> and >> >> >> > how much call context you want to incorporate into your routing. >> For >> >> >> > basic routing/load balancing, you should be able to use any TCP >> proxy. >> >> >> We >> >> >> > route all our TCP thrift calls through Amazon's Load Balancer. we >> >> just >> >> >> > needed to bump the client connection timeout slightly to >> compensate >> >> (by >> >> >> > default, the client library we were using had a very short >> connection >> >> >> > timeout). >> >> >> > >> >> >> > anything beyond this, I'd imagine you are venturing into >> application >> >> >> > specific layers. >> >> >> > >> >> >> > i'm just guessing though as I haven't done anything but proxy. and >> >> >> given >> >> >> > service per-port we are able to get as flexible as we need to in >> our >> >> >> > deployment architecture. >> >> >> > >> >> >> > i'd be curious to know more about what you are thinking of doing. >> >> >> > >> >> >> > >> >> >> > On Jun 5, 2013 7:32 AM, "Glenn Pierce" < >> >> [email protected]> >> >> >> > wrote: >> >> >> > >> >> >> >> Hi can anyone think of a way to proxy a a thrift call. >> >> >> >> >> >> >> >> Essentially what I want is for client calls on a "master" server >> to >> >> >> >> forward the request on to other designated servers. >> >> >> >> >> >> >> >> I was thinking of overriding >> >> >> >> >> >> >> >> Transport and Server to forward certain calls on. >> >> >> >> >> >> >> >> I guess I would have to override protocol as well to get the name >> >> of >> >> >> >> the method (to see if it requires forwarding) >> >> >> >> >> >> >> >> Can anyone see problems with this approach ? Are there better >> ways ? >> >> >> >> >> >> >> >> Thanks >> >> >> >> >> >> >> >> >> >> >>
