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)