Waiting time measurements with reconfiguration fail randomly

Description

A model which uses a waiting time measurement point that should trigger self-adaptations does not simulate always. It reports an InvalidState that the waiting time calculator is missing. Debugging resulted in the insight, that the runtime model recorders are attached at simulation / reconfiguration process start time, but the waiting time calculator is created dynamically when the simulated component instance gets created. Sometime this randomly (depending on the model) might be simply later than the first logic. Overall, that bug is a result of architecture erosion: In the beginning simulizar always created the calculators on the fly, now there is some logic which seems to create some of them at simulation start time. As all models might change at runtime, only the latter version works reliably.

Environment

MacOS, Eclipse 2019-03

Windows, Palladio Drop (Oxygen)

Activity

Show:
Sebastian Krach
July 11, 2019, 2:47 PM

The problem most likely was introduced by the extended capabilities of the MonitorRepository. The problem occurs for measurements which are lazily initialized and have the property "Triggers Self Adaptations" set. The problem originates from the ahead-of-simulation initialization of the ProbeFrameworkDecorators which realize the functionality of the MonitorRepository ProcessingTypes (e.g. FeedThrough). We discussed a number of "quick" fixes for the problem:

1) Delay the initialization of the Measurement Processors. Therefore, basically realize the same behavior as before for the different measurement processors. For the FeedThrough case this would actually be restoring the behavior of before. This could be achieved by attaching some listener to the CalculatorFactory (similar to how Recorders are instantiated right now) and instantiate the measurement processing once the respective Calculator is created. (Quickest fix)

2) Initialize the runtime simulation objects ahead of simulation time. Particularly, create all SimulatedBasicComponentInstances and, thereby, initialize all of the lazily initialized probes and calculators. We still need to support lazy initialization as new component instances might appear through reconfigurations. These new instances are not critical, as the MonitorRepository at simulation start is not capable of specifying a measurement of these entities. (Still, i would not think this is a good option)

Nevertheless, I think the problem should be addressed more generally. The underlying cause (which was also present before the MonitoringRepository extension) IMHO is the distribution of this instrumentation related functionality over different code areas (AbstractProbeFrameworkListener, ProbeFrameworkListenerDecorators, ResourceEnvironmentInitialization, Component instance constructor). In the spirit of a clean decoupling of simulation and measurement I imagine a single instrumentation routine to which the different measurement capabilities provide initialization logic through an extension point. For that we would also need a concept of how to specify measurements for entities which are not present in the model at the beginning of th e simulation.

I think we could sensibly discuss the topic of a proper instrumentation concept at our upcoming Palladio Dev Meeting.

Floriment Klinaku
July 4, 2019, 12:26 PM

An example to exercise the described issue is recently added to the examples repo https://github.com/PalladioSimulator/Palladio-Example-Models under the name The Connected Heating Example.

Fixed

Assignee

Sebastian Krach

Reporter

Steffen Becker

Requirement Category

Functional