Session Manager

• creation
  • Provide a single point of entry into the system. It returns a unique session identifier.
• destruction
  • Given the unique session id it release all resources attached to the specified id. Integrate with the security manager in order to manage the credentials (?!), any process can initiate a destruction as long as it qualify to the security requirements.
• query
  • Multiple query functions, or parameterized query functions to obtains:
    • list of existing sessions
    • list of attributes associated with a specified sessions. This include existing/running plugins/agents or streams.
• maintenance
  • Changing the plugins/agents associated to the session (e.g. dynamically loading new components).
• attach
  • Attach to a previously created session (require the session id). How many front-ends can be attached to a session simultaneously is still a question.
• detach
  • Detach from an attached session. The session became persistent, i.e. it continue to live independently of the front-end.
• merging
  • completely forbidden. VERBOTEN !!!

Notes from Jan 8 ORNL Meeting (Rich and Darius)

Dynamic Processes

• Adding (and removing) agents from existing session
  • Assumptions:
    • A session exists with a FE and agents
    • An agent exists which is is either connected to this infrastructure instance, or is not connected to any instance
    • If the agent is not connected, then the FE (or something in the STCI) knows (where to find out, e.g., from the user or scheduler) where the agent is located
  • What happens once the agent has been added to the stream?
    • Can it be added to an existing stream?
      • No: a new stream must be created including the old agents and the new agent. E.g., for I/O forwarding, this means that everything has to be switched over at all agents
      • Yes: Where is it added? If we have a predefined stream (e.g., binary stream) the internal stream topology may have to be rearranged to accommodate the new agent.
        • We need to look out for race conditions. Make sure the "add agent" command doesn't overtake messages.
• Merging two sessions
  • Assumptions
    • We have two distinct sessions
    • Merging produces a third sessions containing the union of agents.
  • how do sessions find out about each other?

Front-end detach/attach

• For the first cut:
  • when the front-end detaches the streams connected to the front-end can either be stalled (stop forwarding messages) or they can drop the messages
  • Controller has persistence for infrastructure library
    • Persistent data at controller and front-end must be consistent (e.g., info on streams connecting to front-end)
  • If the front-end is disconnected because of a fault, the FE should be able to reconnect and pick up where it left off. Though some data in transit on streams may have been lost.
  • Controller should have enough information on the state of the session that another FE can be connected and pick up where the previous one left off

Multiple Front-Ends

Questions

• What does this mean?
  • One front-end mirrors the other front-end. E.g.:
    • A user using one FE demonstrates a debugging session to another user using the other FE
  • Each front-end works independently. E.g.,
    • Each FE is looking at different sets of performance/profiling data from the same application. Each FE has its own streams and controls them independently.
• How much of this is the responsibility of STCI?
  • Mirroring is too high level for STCI. What would it mean to mirror a stream?
    • Data coming on a stream goes to each FE
    • But the FEs don't see the requests going from an FE to the agents, only the response from the agent.
      • FE0 says "set brkpt at node.c:10". Agent replies "OK". What does FE1 know about what happened?
  • Having independent FEs seems to work better
    • But can you have two people debugging the same code independently? (sure but do you want to?)

*