PCM Development/Palladio Coding Session/20190806 Developer Meeting

Organizational

Location: FZI Karlsruhe
Start: 10:30am

Attendees

Jörg (FZI)
Floriment (US)
Markus (US)
Steffen (US)
Dominik (KIT)
Sandro (KIT)
Yves (KIT)
Martina (FZI)
Max (FZI)
Sebastian (FZI)
Stephan (FZI)

Agenda

11:00 - 12:30

SimuLizar 2 (Floriment/Steffen/Martina)
- Concepts
- Timeline
Consolidation of queue simulations
Future of EventSim

12:30 - 13:30

Lunch Break (MRI)

13:30 - 14:45

New build infrastructure
Bug tracking in Github?
JIRA not actively used
Reactivate Confluence?

14:45 - 16:45

Measurements in SimuLizar
- SIMULIZAR-98
- Wildcard-Measuring Points
- Multidimensional measurements (Jörg)
Common logging framework for Palladio
- SIMULIZAR-97
- specific fixes for this problem exist but we might aim for a more general solution
Discussion about open SimuLizar pull request

16:45 - 17:15

Maintenance of graphical editors
- collect missing stuff in Sirius editors
- future maintainer?
How to deal with open JIRA issues?

Minutes

Simulizar 2.0

SimuLizar workshop for creating SimuLizar from scratch but still reuse existing stuff like SimuCom framework
SimuCom framework is already agnostic to thread stuff
SimuCom framework can be reused
- behavior of blocking/unblocking already designed to be exchangable
- make this behavior changable by clients via API
- not many methods that have to be implemented
- put a layer on top that hides the hacks to the users and allows keeping SimuCom framework as it is
Presentation of changes done in Mosaic project
- Make entire simulation event-based not processed-based
- Blocking thread for simulation process removed, switched to pure event simulation
- Current state looks like hack at the layer between Simulizar and SimuCom framework (e.g. empty life cycle)
data stored in thread local variables have to be externalized
Workload creators will break because of these changes but this won't be a big issue
Plan: reuse concepts of EventSim (like being highly customizable, decoupled)
- at any point where you have to move the process forward, there should be an extensible registry of movements
- same holds true for behaviors
initial design looks good and should work out
open task: what to reuse from existing Simulizar code?
- you cannot use existing interpreters
- reusable: reconfiguration stuff (but includes assumption that there is a process, might have to be changed)
no timeline yet
- patch for interfaces and fixes for bugs, will be a pull request on Github
- next step: write version that can simulate simple example to test all concepts (no student thesis)

Future of EventSim
- Status
  - compiles but does not work
  - not using QUAL but R (major effort but there might be a way of doing this)
- Features only available in EventSim
  - simulating database transactions
    - we assume that this can be integrated into future Simulizar
  - IntBIIS only integrated into EventSim
    - uses old version of EventSim
    - not properly separated
- Stakeholders
  - Philip: PhD project
  - Sandro: Case Study but can use other simulator as well
- Dicision: Drop support for EventSim and spent all effort in new Simulizar
  - use knowledge from EventSim to create new Simulizar
  - TODO: Add deprecation tag to EventSim / wiki page

Consolidation queue simulations
- simulations
  - Dominik: abstraction for data streaming operations, keeps collection of arrived data packages, outputs them (e.g. windows), application on top of message brokers
    - use stack frames, safe additional meta data
  - Jörg: link-layer-simulation of queueing networks (e.g. RabbitMQ), have rough implementation of broker behavior, more like end-to-end communication
- possible common topic: requirements regarding properties of messages
- what people have stakes in queue simulations?
  - people of Bosch
  - Mosaic project (Floriment, Martina)
- TODO: find concrete example and discuss shared interests
  - starting points to get to know work
    - case study from work of Dominik and Manuel
    - connected heating model created to illustrate the measurements bug
  - Dominik will set up a meeting

Build Infrastructure

Issue tracking
- arguments against JIRA / in favor of Github
  - performance
  - maintenance
  - better integration of bots in Github
- arguments in favor of JIRA
  - state of the art (at least in industry) issue tracking system
  - long history of issues
  - strong guidance in creating issues
Decision: Reevaluate question if
- Atlassian charges us money
- Hardware costs / requirements increase / performance decreases

Split Palladio stuff and public wiki stuff
- is beneficial in general
- do the migration in three steps: categorize information, split information into separate wikis, optional: migrate to new platform
- TODO: Ask Erik about how to do that and how much effort this could take / whether a student could do most of the work

Simulizar

SIMULIZAR-98
- Fix 1: Delay initialization (favored, low effort)
- Fix 2: Initialize all measurements ahead of simulation (higher effort because you have to create all component instances before simulation)
- Definition of measurements is quite limited because all model elements have to be present
- It would be beneficial to have a more flexible way of defining measurements
- measurements are initialiized in multiple locations (e.g. simulation entity (in constructor))
- events for creating and destroying simulation entities could be used to react on that instead of putting the responsibility to simulation entities
  - instrucmentation could take place outside
- Decision: Sebastian tries to implement fix 1 within considerable time
- General issue still in it
- should we reuse SimuCom framework or use a new implementation
  - code code be really improved
  - no other supported simulator is using it, so we should not aim for compatibility at all costs
  - rewriting will require more man power than we have available
  - rewritten simulator will not have as many features as existing simulator
  - rewriting not feasible, especially not by students
  - instead: use SimuCom framework as it is and put an API layer on top of it

multidimensional measurements
- instead of creating a linear string, have the concept of multiple dimensions
- wildcards only affect defined dimensions and are therefore typed
- all measurements have to have same type in oder to make aggregation work
- implementation should not be too complex
- could be a student project
- TODO Jörg: prepare task description for student thesis and share it with US

SIMULIZAR-97
- logging used to inform users about what's going on
- apache log4j used for that
- custom logic to redirect output to eclilpse console
- problem: log4j not designed for environment with multiple class loaders (like OSGi environment)
- possible quick fix: copy config of plugin to extending plugin
- suggestion: OSGi logging facility, slf4j implementation to redirect to other logger
  - configuration can be done through configuration admin
  - still, a custom appender has to be written to redirect to the Eclipse console
- using a central log4j factory is possible but requires several code changes
- quick fix: implement singleton using enum at the workflow engine and use centralized factory
- long term: let a student try different solutions

Deletion of IModelAccess
- TODO Max: push changes
- TODO Steffen: Have a look after changes have been pushed and comment with error message

Maintenance

Graphical editors
- find missing Sirius features in a session at the next research retreat (maybe on Monday)
- managing maintainer approach
Open JIRA issues
- discuss open issues in concall (e.g. announce that we are talking about issues of project X, Y)
- discuss all issues in dev meetings