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