Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Agent registers to CMR

Gliffy
nameAgent 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
nameClass 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
nameAgent class loading (async mode)

Class sent to CMR

Gliffy
nameServer-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:

  1. sending to Agent (synchronous mode) or
  2. sending to queue Agent is reading from (asynchronous mode)

Missing from the activity diagram:

  • possible saving of the changed byte code to the disk
  • possible 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 (wink))

  • 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
nameAgent gets Instrumentation result from CMR queue

Environment or Profile changed on the UI

Agent in sync mode

Gliffy
nameCI changes (UI -> CMR)

  • Diagrams might be a slight different for the situation where Profile or Environment is deleted

Agent in async mode