Discussions SS & ISE

Agent startup

Minimum initialization mode
1. Only contain parts that are related to creating the initial connection to the CMR
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)
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 can connect to the CMR)
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.
CMR sends initial information to the agent called AgentConfiguration
1. Based on the environment
2. Agent-ID
3. Configurations like sensors, strategies
Full initialization mode
~~Process all classes that were loaded while the agent was not fully initialized~~

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
Calculate hashcode for the class
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.
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)
Always give back the original bytecode! The new bytecode will be asynchronously instrumented on the server and send back to the agent.

Redefine class based on the given class
Update RSC on the hook
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.
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.
Log output for the user? "XXX classes have been instrumented"

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