On Dec 15, 2008, at 6:15 PM, Mark Slee wrote:
Just want to point out that any system doing this should degrade
nicely to the case where there is no context at all. For instance:
MyServiceHandler msh;
msh.callSomeMethod();
One of the design points of Thrift was that the application handler
is supposed to be delightfully ignorant of the calling context, and
in fact when dealing locally you can bypass the entire transport/
protocol stack and just utilize a handler directly.
Well, this requirement doesn't make any sense if the method you're
calling, say 'authenticate' needs the context to implement access
control/logging etc. I'd say that calling context is fundamental for a
service, despite the fact that many handlers don't use it explicitly.
I guess this case could just return some kind of NoContext object
etc. But the larger point is that the general framework should not
make ANY assumptions about calling context. I'm fine with
introducing application-specific limitations (i.e. my service always
runs on TCP/IP and there's always a client with an IP), so long as
those abstractions don't run into the core.
One thing we can do is to have a compiler option (even with per method
IDL notation) to give user a choice to include calling context or not.
We can say calling context are available with only certain types of
transport etc.
__Luke
Cheers,
mcslee
-----Original Message-----
From: Vicaya [mailto:[email protected]] On Behalf Of Luke Lu
Sent: Monday, December 15, 2008 6:11 PM
To: [email protected]
Subject: Re: Accessing connection context in handlers
On Dec 15, 2008, at 5:24 PM, David Reiss wrote:
Adding a context parameter is possible, but I'm not in love with the
idea. We would have to either (a) include a dummy value in client
requests or (b) create different client and server interfaces, making
it more difficult to call handlers directly.
Well, I think that a connection context is useful for client
requests as well, e.g. to return the replica/proxy server info (ip,
proxy ip, cache settings etc), if the API is load balanced across a
bunch of servers or via a (CDN) proxy.
The way that I've thought of doing this before was replacing the
handler with a "handler factory" that could either return a fixed
pointer to the handler (equivalent to the current system) or allocate
a handler per request. Then, the server would call methods on the
handler before invoking the main method, allowing it to do
application-
specific processing of metadata.
Another way is to have the new interface with the connection context
(either as the first or last argument is fine) extends the existing
interface and their implementation would be calling its
corresponding interface with no connection context, which is
abstract like the current implementation.
connection context should be pretty cheap to create all things
considered, as in most cases, just an ip number is populated.
__Luke
--David
Bryan Duxbury wrote:
It's true that you can't do this today. It'd be a nice feature to
have, though, for sure. Anyone have a good idea of how we should go
about implementing this? Last parameter is always the context?
-Bryan
On Dec 15, 2008, at 5:05 PM, Luke Lu wrote:
I wanted to implement logging (and later ACL) for a thrift broker/
server. But I'm having trouble getting connection info (remote ip
address etc.) from server handlers. In other rpc alternatives, you
get this from a connection context passed in as an argument (e.g.,
Ice's Ice::Current).
I remember someone submitted a patch but I can't seem to find a
JIRA
ticket/patch for this. How else do people implement API specific
logging and access control? Help?
__Luke
P.S. Apology if this is a resend (I got no ack from the list
server,
but no post/response either.)
