Discussions SS & ISE

Agent startup

1. Minimum initialization mode
   1. Only contain parts that are related to creating the initial connection to the CMR
2. Agent tries to connect to CMR registration service.
   1. Adress of the CMR is defined by JVM parameters
   2. Agent provides its name (also given by JVM parameters)
3. If connection is not possible, agent stays in minimum initialization mode (1) and keeps trying to connect to the CMR fails hard, application continues to run..

Agent initialization

1. (Agent can connect to the CMR)
2. CMR find environment for the agent
   1. Environment is found by mapping table consisting of agent IP and name.
   2. If no environment is found, CMR and Agent log the problem and agent stop trying. Only restarting the agent will start over the process.
3. CMR sends initial information to the agent called AgentConfiguration
   1. Based on the environment
   2. Agent-ID
   3. Configurations like sensors, strategies
4. Full initialization mode
5. Process all classes that were loaded while the agent was not fully initialized

Connection to CMR breaks

1. Agent is in disconnected mode
2. Agent collects all classes that are loaded and safe the name of them
3. When connection is attained again process all classes

Process loaded classes

1. Perform everything in another thread from the loading one - in fact create a job in an executor or so 
   1. saves us loading time
   2. batch send is possible
   3. we should log in the agent that the instrumentation is not done on the loading, but a bit later
2. Calculate hashcode for the class
3. Figure out if this class needs to be sent to the server
   1. Cache on the agent allows to quickly find the solution
   2. Three possible options: needs to be instrumented, does not need to be instrumented, new class
   3. We agreed that we currently do not keep the bytecode of the instrumented classes on the agent.
   4. Thus we only need to store the hashes of classes that should not be sent.
4. If necessary send bytecode to the server
   1. Add the hash of the class to the list of hashes NEVER to be send. This is because we need to differentiate between classes that need instrumentation and unknown ones that do not need instrumentation
   2. (When we get back the bytecode with instrumentation we remove this class again as we are sure that this class is necessary for instrumentation)
5. Always give back the original bytecode! The new bytecode will be asynchronously instrumented on the server and send back to the agent.

Process "bytecode resend" request (batch possible)

1. Agent updates cache to mark this class to be instrumented/send
2. Load bytecode from JVM (open)
3. Send bytecode to the CMR

Process "Redefine" request (batch possible)

1. Redefine class based on the given class
2. Update RSC on the hook
3. If the bytecode is marked as original, mark this class in the cache as "not needed for instrumentation", meaning ensure that this entry is within the list of hashes not to be send.
4. If the bytecode is marked as non original, verify that cache has this class as "needed for instrumentation", meaning remove the entry from the list of hashes not to be send.
5. Log output for the user? "XXX classes have been instrumented"

Update environment (instrumentation configuration)

1. Enduser on the UI updates the configuration (environment)
2. Update the AgentConfiguration for all agents using this environment
3. Run the changed environment against the class cache again. Class cache returns changed entities:
   1. "Bytecode resend" request: Class that was not instrumented before:
      1. Tell the agent to send the bytecode for this class again. (The class will undergo normal parsing & instrumentation process and the result will be returned to the agent.)
   2. "Redefine" request: Class that was instrumented before:
      1. Load original bytecode from cache in the CMR
      2. Run the instrumenter on this bytecode and send the bytecode to the agent. Mark if it is original bytecode.

Discussions PB, SS & ISE

• Synchronous or asynchronous mode optional for user 
• Agent needs to know for each class hash a class loader it runs on
• Can agent load byte code
  • check if agent can know that somehow prior to sending original byte code
  • if so CMR should also store this byte code
• Problem with after-us updated byte code
  • we can not update classes that have additionally changed byte code after us
  • this problem must be analyzed
  • at least to know what byte code has been additionally changed
  • check with app servers and test
    
    

The agent perspective