hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ashutosh Chauhan (JIRA)" <>
Subject [jira] [Commented] (HIVE-3805) Resolve TODO in TUGIBasedProcessor
Date Sat, 15 Dec 2012 18:50:12 GMT


Ashutosh Chauhan commented on HIVE-3805:

If you look at hiveserver2 implementation over at HIVE-2935, it has an implementation of {{Plain}}
sasl server. Plain server means sasl server doesn't use kerberos (or any authentication mechanism)
for authenticating thrift client and at the same time client transfers end user identity to
server. Server just trusts client, since its unsecure mode anyways. This Sasl server is used
for thrift client and server transport in HiveServer2. That is much more cleaner approach
than the current implementation which is really hacky which does an rpc call to transfer ugi
(introduced in HIVE-2616 ), instead of transferring it at connection setup time. Though, current
hacky approach works, its a twisted design and harder to understand. If there is any interest
in wider adoption of transferring ugi for unsecure connection between thrift client and server,
we should use HS2 mechanism. Further, since HiveServer2 already uses that, we will have parity
in transport layer between HS2 client-server transport and metastore client-server transport.

> Resolve TODO in TUGIBasedProcessor
> ----------------------------------
>                 Key: HIVE-3805
>                 URL:
>             Project: Hive
>          Issue Type: Improvement
>          Components: Metastore
>    Affects Versions: 0.11
>            Reporter: Kevin Wilfong
>            Assignee: Kevin Wilfong
>         Attachments: HIVE-3805.1.patch.txt
> There's a TODO in TUGIBasedProcessor
> // TODO get rid of following reflection after THRIFT-1465 is fixed.
> Now that we have upgraded to Thrift 9 THRIFT-1465 is available.
> This will also fix an issue where fb303 counters cannot be collected if the TUGIBasedProcessor
is used.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message