You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Glenn Pierce <gl...@carnegosystems.com> on 2013/06/05 13:31:09 UTC
Proxy Thrift call
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
Re: Proxy Thrift call
Posted by Henrique Mendonça <he...@apache.org>.
well, you got loads of ideas from everyone already, but as you saying that
you don't need the same port, can't you use a standard port forwarding,
e.g. from your firewall?
Best,
Henrique
On 6 June 2013 17:46, Glenn Pierce <gl...@carnegosystems.com> wrote:
> On 6 June 2013 16:20, Henrique Mendonça <he...@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 <gl...@carnegosystems.com>
> wrote:
> >
> >> On 6 June 2013 12:02, Henrique Mendonça <he...@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 <gl...@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 <mi...@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
> >> >> >>
> >> >>
> >>
>
Re: Proxy Thrift call
Posted by Glenn Pierce <gl...@carnegosystems.com>.
Thanks for this. I think this should work rather well.
On 6 June 2013 17:43, Mike Stanley <mi...@mikestanley.org> 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 <be...@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 <gl...@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 <he...@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 <gl...@carnegosystems.com>
>> wrote:
>> >
>> >> On 6 June 2013 12:02, Henrique Mendonça <he...@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 <gl...@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 <mi...@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
>> >> >> >>
>> >> >>
>> >>
>>
>>
Re: Proxy Thrift call
Posted by Mike Stanley <mi...@mikestanley.org>.
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 <be...@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 <gl...@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 <he...@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 <gl...@carnegosystems.com>
> wrote:
> >
> >> On 6 June 2013 12:02, Henrique Mendonça <he...@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 <gl...@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 <mi...@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
> >> >> >>
> >> >>
> >>
>
>
Re: Proxy Thrift call
Posted by Ben Craig <be...@ni.com>.
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 <gl...@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 <he...@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 <gl...@carnegosystems.com>
wrote:
>
>> On 6 June 2013 12:02, Henrique Mendonça <he...@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 <gl...@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 <mi...@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
>> >> >>
>> >>
>>
Re: Proxy Thrift call
Posted by Glenn Pierce <gl...@carnegosystems.com>.
On 6 June 2013 16:20, Henrique Mendonça <he...@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 <gl...@carnegosystems.com> wrote:
>
>> On 6 June 2013 12:02, Henrique Mendonça <he...@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 <gl...@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 <mi...@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
>> >> >>
>> >>
>>
Re: Proxy Thrift call
Posted by Henrique Mendonça <he...@apache.org>.
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 <gl...@carnegosystems.com> wrote:
> On 6 June 2013 12:02, Henrique Mendonça <he...@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 <gl...@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 <mi...@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
> >> >>
> >>
>
Re: Proxy Thrift call
Posted by Glenn Pierce <gl...@carnegosystems.com>.
On 6 June 2013 12:02, Henrique Mendonça <he...@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 <gl...@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 <mi...@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" <gl...@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
>> >>
>>
Re: Proxy Thrift call
Posted by Henrique Mendonça <he...@apache.org>.
Hi Glenn,
Are your clients all implementations of the same service?
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 <gl...@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 <mi...@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" <gl...@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
> >>
>
Re: Proxy Thrift call
Posted by Glenn Pierce <gl...@carnegosystems.com>.
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 <mi...@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" <gl...@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
>>
Re: Proxy Thrift call
Posted by Mike Stanley <mi...@mikestanley.org>.
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" <gl...@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
>