[
https://issues.apache.org/jira/browse/THRIFT-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13938483#comment-13938483
]
Derek Schenk commented on THRIFT-435:
-------------------------------------
Looking to find a resolution to this issue as a possible way to implement call
auditing for the handlers. I need access to the calling transport to get the
remote address, but I'm not able to use the TServerEventHandler because when
using TThreadedSelectorServer the underlying transport is a
TMemoryInputTransport instead of the original socket.
I was planning to put together a possible Java patch for this, and was
wondering if a ThreadLocal would be an acceptable way to handle this.
For example, in AbstractNonblockingServer, in the invoke() method, just before
calling processorFactory_.getProcessor(inTrans_).process(inProt_, outProt_); a
call could be made to a ThreadLocal (i.e. ThriftContext) which would set the
values for (context_, inTrans_, outTrans_, inProt_, outProt_, trans_). These
values would be cleared in a finally block added to the current try/catch to
ensure that they are always unset ( or even the entire thread local cleared).
This would provide a non-invasive way to get access to all of the underlying
information, without requiring changes to any of the processors or IDL. This
would also provide a way to get information from the beginContext and
processContext calls into the processor without needing the static maps and
other methods that have been suggested.
Is this a viable option?
> Connection context information within TProcessor implementations
> ----------------------------------------------------------------
>
> Key: THRIFT-435
> URL: https://issues.apache.org/jira/browse/THRIFT-435
> Project: Thrift
> Issue Type: New Feature
> Reporter: Todd Lipcon
>
> It would be nice if there were a way to get some TServer-level context
> information from within a service implementation. Specifically, I'd like to
> be able to get the remote IP/port for a couple of different use cases.
> I'm not sure exactly where the hook point for this is... will take some
> investigation to find the right amount of abstraction.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
