thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Stanley <m...@mikestanley.org>
Subject Re: Proxy Thrift call
Date Thu, 06 Jun 2013 16:43:50 GMT
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 <ben.craig@ni.com> 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 <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