namanmishra91 commented on a change in pull request #235: [LIVY-666] Support 
named interpreter groups
URL: https://github.com/apache/incubator-livy/pull/235#discussion_r328922002
 
 

 ##########
 File path: repl/src/main/scala/org/apache/livy/repl/Session.scala
 ##########
 @@ -91,29 +95,42 @@ class Session(
     entries.sc().sc
   }
 
-  private[repl] def interpreter(kind: Kind): Option[Interpreter] = 
interpGroup.synchronized {
-    if (interpGroup.contains(kind)) {
-      Some(interpGroup(kind))
+  private[repl] def interpreter(kind: Kind, interpreterGroupKey: String =
+   DEFAULT_INTERPRETER_GROUP_KEY): Option[Interpreter] =
+   sessionsMap.synchronized {
+    val key = if (interpreterGroupKey == null) {
+      DEFAULT_INTERPRETER_GROUP_KEY
     } else {
-      try {
-        require(entries != null,
-          "SparkEntries should not be null when lazily initialize other 
interpreters.")
-
-        val interp = kind match {
-          case Spark =>
-            // This should never be touched here.
-            throw new IllegalStateException("SparkInterpreter should not be 
lazily created.")
-          case PySpark => PythonInterpreter(sparkConf, entries)
-          case SparkR => SparkRInterpreter(sparkConf, entries)
-          case SQL => new SQLInterpreter(sparkConf, livyConf, entries)
+      interpreterGroupKey
+    }
+    var intpGroupOpt = sessionsMap.get(key)
+    if (intpGroupOpt == None) {
+      sessionsMap.put(key, new mutable.HashMap[Kind, Interpreter])
+    }
+
+    val intpGroup = sessionsMap.get(key).get
+    intpGroup.synchronized {
+      if (intpGroup.contains(kind)) {
+        Some(intpGroup(kind))
+      } else {
+        try {
+          require(entries != null,
+            "SparkEntries should not be null when lazily initialize other 
interpreters.")
+
+          val interp = kind match {
 
 Review comment:
   @yiheng The intent is to share a session and have multiple 
namespaces/contexts. Since the namespace is defined at the interpreter level, 
one can always use another interpreter group for having a different context. Is 
there any specific use case in which we would want multiple interpreters of a 
`Kind` within an interpreter group?  

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Reply via email to