[LIVY-752][THRIFT] Fix implementation of limits on connections.

## What changes were proposed in this pull request?

`LivyThriftSessionManager` keeps a `ConcurrentHashMap[String, AtomicLong]` named `connectionsCount` to track the number of connections per user, etc. The `incrementConnectionsCount` and `decrementConnectionsCount` methods in `LivyThriftSessionManager` check that `connectionsCount` does not contain a key (instead of contains the key) before getting the value and incrementing or decrementing the count (leading to a `NullPointerException`). Even accounting for the incorrect condition, they do not use the `ConcurrentHashMap` correctly. There is a race -- a thread can get a count, find that it's within a limit, create a new session and then increment the count, while in the meantime, another thread could have incremented the count and so the limit is now actually exceeded.

We increment all relevant counts optimistically before creating a new session, check if any limits are violated, and if so, decrement all incremented counts.

## How was this patch tested?

Tested by deploying the change on a cluster and setting livy.server.thrift.limit.connections.per.user. Verified that the number of connections reaches but does not exceed the limit.
Also, added basic unit tests that connection limits are enforced.

Author: Wing Yew Poon <wypoon@cloudera.com>

Closes #284 from wypoon/LIVY-752.
3 files changed
tree: b2dbfcb79433d70c0e27c65fff34d35cfe7b0326
  1. .github/
  2. api/
  3. assembly/
  4. bin/
  5. client-common/
  6. client-http/
  7. conf/
  8. core/
  9. coverage/
  10. dev/
  11. docs/
  12. examples/
  13. integration-test/
  14. python-api/
  15. repl/
  16. rsc/
  17. scala/
  18. scala-api/
  19. server/
  20. test-lib/
  21. thriftserver/
  22. .gitignore
  23. .rat-excludes
  24. .travis.yml
  25. checkstyle-suppressions.xml
  26. checkstyle.xml
  27. DISCLAIMER
  28. LICENSE
  29. NOTICE
  30. pom.xml
  31. README.md
  32. scalastyle.xml
README.md

Apache Livy

Build Status

Apache Livy is an open source REST interface for interacting with Apache Spark from anywhere. It supports executing snippets of code or programs in a Spark context that runs locally or in Apache Hadoop YARN.

  • Interactive Scala, Python and R shells
  • Batch submissions in Scala, Java, Python
  • Multiple users can share the same server (impersonation support)
  • Can be used for submitting jobs from anywhere with REST
  • Does not require any code change to your programs

Pull requests are welcomed! But before you begin, please check out the Contributing section on the Community page of our website.

Online Documentation

Guides and documentation on getting started using Livy, example code snippets, and Livy API documentation can be found at livy.incubator.apache.org.

Before Building Livy

To build Livy, you will need:

Debian/Ubuntu:

  • mvn (from maven package or maven3 tarball)
  • openjdk-8-jdk (or Oracle JDK 8)
  • Python 2.7+
  • R 3.x

Redhat/CentOS:

  • mvn (from maven package or maven3 tarball)
  • java-1.8.0-openjdk (or Oracle JDK 8)
  • Python 2.7+
  • R 3.x

MacOS:

  • Xcode command line tools
  • Oracle's JDK 1.8
  • Maven (Homebrew)
  • Python 2.7+
  • R 3.x

Required python packages for building Livy:

  • cloudpickle
  • requests
  • requests-kerberos
  • flake8
  • flaky
  • pytest

To run Livy, you will also need a Spark installation. You can get Spark releases at https://spark.apache.org/downloads.html.

Livy requires Spark 2.2+. You can switch to a different version of Spark by setting the SPARK_HOME environment variable in the Livy server process, without needing to rebuild Livy.

Building Livy

Livy is built using Apache Maven. To check out and build Livy, run:

git clone https://github.com/apache/incubator-livy.git
cd incubator-livy
mvn package

By default Livy is built against Apache Spark 2.2.0, but the version of Spark used when running Livy does not need to match the version used to build Livy. Livy internally handles the differences between different Spark versions.

The Livy package itself does not contain a Spark distribution. It will work with any supported version of Spark without needing to rebuild.