• Sub-task
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 0.9.0
    • 0.9.0
    • zeppelin-server


      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:

      1. 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;

      2. 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;




            liuxun323 Xun Liu
            liuxun323 Xun Liu
            1 Vote for this issue
            2 Start watching this issue