liuxun created ZEPPELIN-3613:

             Summary: Cluster Session module design
                 Key: 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. 

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

Reply via email to