Re-instrumentation on configuration change via CI

Owned by ise (Unlicensed)
Last updated: Apr 24, 2015
3 min read

This page describes the problems and challenges in realizing the correct re-instrumentation of the class cache when the configuration is updated on the UI/CMR via the Configuration interface.

CI change types

There are different changes that are possible on the Configuration interface. The table below describes how those can influence one agent's class cache regarding the instrumentation points.

 AddedModifiedDeleted
ProfileNo influence. Adding new profile can not change the state of the instrumentation points in the class cache because newly created profile is bounded to no environment, thus no agent is using it in the moment of creation.Set of Method sensor assignments (MSA) and Exception sensor assignments (ESA) can be added or removed. New assignments should be used in search for new instrumentation points, while removed ones should serve for removing instrumentation points.All Method sensor assignments (MSA) and Exception sensor assignments (ESA) in the profile are removed. Instrumentation points are removed only.
EnvironmentIt can occur that by new environment adding and current mappings Agent is assigned new environment or mapping for that Agent become not valid anymore. Thus we can call this situation as possible environment change.By modification only influence is if new profiles are linked or un-linked to the Environment. Basically, same process applies as for the Profile modification, cause in fact we end up with set of added and removed MSA/ESA.If agent is bounded to the deleted environment, all instrumentation points should be removed. This situation can also lead to the fact that one of the Environment becomes valid for an agent (mapping pointed to 2, now it's 1, so valid), so it also leads to possible environment change.
Mappings

In case of mapping any change is basically the same. It results in possibility that agent:

  • has same environment as before
  • has new environment
  • has no environment any more

In first case no change is needed. For other cases all instrumentation points must be removed first and if new environment is assigned to the agent additionally re-instrument with new environment.

Altogether, related to instrumentation points, following actions might be performed:

  • Remove all instrumentation points
  • Remove set of instrumentation points based on removed MSA/ESA
  • Add set of instrumentation points based on added MSA/ESA

The biggest problem is with the changing of whole environment or losing the environment.. Changes via UI can be quite often and maybe full check after each change is a bit of overhead. Maybe we need to set some boundaries on when do we perform such full re-instrumentation.

However, when agent sends it class, if we already know the class we expect that the instrumentation points are valid. But, what if environment is changed when the agent is still running, how will we inform the agent that the complete configuration changed, meaning there might be new sensors active, ect. 

Tracking of which MSA/ESA influenced the instrumentation point

To be able to correctly remove instrumentation points based on the MSA/ESA we need a way to track which assignment influenced the instrumentation point. This is not easy, as instrumentation point can come as a result of more MSA/ESA. Furthermore, assignments are spread in different profiles (for example we can even have two same assignment in different profiles).

Possible solutions:

  • Instrumentation points knows what assignments are influencing - several problems
    • we can not have a simple set as same assignments can be in different profiles, thus we need additional "key" (profile id or assignment id or simple count)
    • properties of the assignments (like context capturing, etc) would have to be recalculated on the removal of one assignment
    • good thing is that we could move all logic to the RSCs, so we can have smth like add/remove assignment
    • bad thing is that this increases the size of the RSC in the memory
    • problematic to deal with the id of the sensors and properties
  • Keep instrumentation points in assignments
    • this somehow feels now being good reletaed to the design
    • difficulty to synchronize with changes via UI, because we care never getting the same instance
  • Keep no track
    • when assignment is removed, find all methods/classes influenced by this assignment, delete instrumentation points and re-analyze with the complete configuration
    • no additional space to hold the MSA/ESA
    • bit of overhead, but good if we can only reset directly the methods that where influenced
    • no worry for the parameters and sensor ids, they will always be reseted
  • Something else?!?