[
https://issues.apache.org/jira/browse/HDFS-12134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Clampffer updated HDFS-12134:
-----------------------------------
Attachment: HDFS-12134.HDFS-8707.000.patch
First pass at this work. Don't have kerberized CI tests so I'm going to get
some burn in on some code that can do concurrent SASL calls in a way that
causes issues. Does include some basic unit tests.
2 parts to this:
-Add a LockManager that can take pluggable locks from a user, or default to a
basic one derived from std::mutex. Right now it only includes a GSSAPI mutex
but more can be added if we want locking around config file access and things
like that.
-Wrap all calls into Cyrus SASL and GSasl APIs with lock guards to prevent
concurrent access. Docs (or lack of docs) for both libraries seem to defer to
looking at the implementation about which bits are thread safe so all calls are
protected for now. I think in most cases it's library initialization and sasl
context initialization that are unsafe but the other calls shouldn't block and
I'd rather err on the side of caution here.
Generally the process-wide mutex is acquired once per sasl API call and
released right away. The only exception to this is GSasl initialization and
cleanup does two calls and it made sense to do them as an atomic operation.
And reviews or feedback is welcome. Eventually we need to get rid of the GSasl
engine due to license conflicts (ASF vs GPL) but this didn't seem like the
place to do it.
> libhdfs++: Add a synchronization interface for the GSSAPI
> ---------------------------------------------------------
>
> Key: HDFS-12134
> URL: https://issues.apache.org/jira/browse/HDFS-12134
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs-client
> Reporter: James Clampffer
> Assignee: James Clampffer
> Attachments: HDFS-12134.HDFS-8707.000.patch
>
>
> Bits of the GSSAPI that Cyrus Sasl uses aren't thread safe. There needs to
> be a way for a client application to share a lock with this library in order
> to prevent race conditions. It can be done using event callbacks through the
> C API but we can provide something more robust (RAII) in the C++ API.
> Proposed client supplied lock, pretty much the C++17 lockable concept. Use a
> default if one isn't provided. This would be scoped at the process level
> since it's unlikely that multiple instances of libgssapi unless someone puts
> some effort in with dlopen/dlsym.
> {code}
> class LockProvider
> {
> virtual ~LockProvider() {}
> // allow client application to deny access to the lock
> virtual bool try_lock() = 0;
> virtual void unlock() = 0;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
