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 ;)
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 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 > >> >> > >> >
