[
https://issues.apache.org/jira/browse/HBASE-13397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-13397:
-----------------------------------
Attachment: HBASE-13397-0.98.patch
This cleanup applies to 0.98 also.
It's a nice idea and I pushed it there too so we aren't wasting cycles
maintaining an unneeded threadlocal and so we won't take a blind turn down
RequestContext at some point given it's been removed from later versions.
(Sometimes contributors start with a patch against 0.98.)
The changes are to private interfaces except one change to RpcServer.Call,
where RpcServer is a LimitedPrivate/Evolving interface with coprocessor and
Phoenix audiences.
Over in Phoenix there is only one place (a test, PhoenixIndexRpcSchedulerTest)
that uses the RpcServer.Call constructor so I've left the old constructor in
place with a deprecation tag and Javadoc indicating it shouldn't be used.
Therefore there are no source or binary compatibility issues resulting from the
change. The test is just mocking Calls so is not affected.
0.98 tests pass with the change applied.
> Purge duplicate rpc request thread local
> ----------------------------------------
>
> Key: HBASE-13397
> URL: https://issues.apache.org/jira/browse/HBASE-13397
> Project: HBase
> Issue Type: Bug
> Components: rpc
> Reporter: stack
> Assignee: stack
> Fix For: 2.0.0, 1.1.0, 0.98.13
>
> Attachments: 13397.txt, HBASE-13397-0.98.patch
>
>
> Serverside, in a few locations, code wants access to RPC context to get user
> and remote client address. A thread local makes it so this info is accessible
> anywhere on the processing chain.
> Turns out we have this mechanism twice (noticed by our Matteo). This patch
> purges one of the thread locals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
