thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Craig <ben.cr...@ni.com>
Subject Re: Proxy Thrift call
Date Thu, 06 Jun 2013 15:52:22 GMT
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 <glenn.pierce@carnegosystems.com>
To:     user@thrift.apache.org, 
Date:   06/06/2013 10:47 AM
Subject:        Re: Proxy Thrift call
Sent by:        glennpierce.work@gmail.com



On 6 June 2013 16:20, Henrique Mendonça <henrique@apache.org> 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 <glenn.pierce@carnegosystems.com> 
wrote:
>
>> On 6 June 2013 12:02, Henrique Mendonça <henrique@apache.org> 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 <glenn.pierce@carnegosystems.com>
>> 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 <mike@mikestanley.org> 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" <
>> glenn.pierce@carnegosystems.com>
>> >> > 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
>> >> >>
>> >>
>>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message