Agent registers to CMR
Gliffy |
---|
name | Agent registration to CMR |
---|
|
- When Agent configuration is created new use time-stamp of creation for the Agent Configuration last update time.
Class loaded on Agent
Synchronous sending mode
Gliffy |
---|
name | Class loaded on Agent (sync mode) |
---|
|
- No need to mark class as being sending in the cache, cause cache only knows about classes that should not be sent
Asynchronous sending mode
Gliffy |
---|
name | Agent class loading (async mode) |
---|
|
Class sent to CMR
Gliffy |
---|
name | Server-side instrumentation activity diagram |
---|
|
Based on the synchronous or asynchronous mode invoked, sending of instrumentation points at the end of the activity is in fact:
- sending to Agent (synchronous mode) or
- sending to queue Agent is reading from (asynchronous mode)
Missing from the activity diagram:
possible saving of the changed byte code to the diskpossible sending of the additional byte-code for classes that need to be updated
Questions / Remarks: (Clear this after discussion and add to decisions or what ever chapter )
- What if an interface is added that would affect the instrumentation of already loaded classes? (your second point above?)
- When nothing is changed we can return null and not send the bytecode again
- I think the saving of bytecode to disc must be added to this chart right away
- Below path (so new class), how would we added methods Ids before we know if we have instrumentations points?
Agent receives InstrumentationResult from CMR (asynchronous mode)
Gliffy |
---|
name | Agent gets Instrumentation result from CMR queue |
---|
|
Environment or Profile changed on the UI
Agent in sync mode
Gliffy |
---|
name | CI changes (UI -> CMR) |
---|
|
- Diagrams might be a slight different for the situation where Profile or Environment is deleted
Agent in async mode