liuxun created ZEPPELIN-3613:
--------------------------------
Summary: Cluster Session module design
Key: ZEPPELIN-3613
URL: https://issues.apache.org/jira/browse/ZEPPELIN-3613
Project: Zeppelin
Issue Type: Sub-task
Components: zeppelin-server
Affects Versions: 0.9.0
Reporter: liuxun
Fix For: 0.9.0
h3. Since the Interpreter process in Zeppelin is a resident process, the
Zeppelin-Server service natively saves the runtime environment of the user,
Note, and the Thrift remote connection of the corresponding interpreter process
through the Session, but in a distributed environment, you It is not possible
to determine which Zeppelin-Server service the user will log in to through the
domain name, so the Zeppelin-Server service must be able to support users who
are still on the A server to continue to use it in the B server. For this
reason, we have two implementations:
# Cluster unified cache Session
The Session created in each Zeppelin-Server service is stored in a unified
manner through Cluster MetaData, and the session information is obtained from
Cluster MetaData regardless of which Zeppelin-Server service the user logs in.
Advantages and Disadvantages: The code size is large, and it is complicated to
synchronize the session state logic in each server. The metadata stored in
Cluster MetaData is also more;
# Rebuild Session
The user who originally uses the A server will have the user's session. When
the user logs in to the B server, the Zeppelin-Server service of the B server
re-establishes the user in the B server according to the user and the Note
information combined with the Interpreter metadata in the Cluster MetaData.
Session
Advantages and Disadvantages: The code implementation is relatively simple, and
there is no need to synchronize the session state in each server. The process
of rebuilding the Session is very fast and simple;
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
