TeeTime issueshttps://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues2018-02-26T14:02:50+01:00https://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/363Add marker interface for producers2018-02-26T14:02:50+01:00Christian WulfAdd marker interface for producersUseful for the testing framework. Allows to detect a producer at compile-time so that we can write ``test(producer).start();``. We should validate that ``has producer interface <=> has no input ports``.Useful for the testing framework. Allows to detect a producer at compile-time so that we can write ``test(producer).start();``. We should validate that ``has producer interface <=> has no input ports``.Christian WulfChristian Wulfhttps://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/351Add new Java 9 hint for spin waits2017-10-20T21:05:00+02:00Christian WulfAdd new Java 9 hint for spin waitssee JEP 285: Spin-Wait Hints (http://openjdk.java.net/jeps/285)see JEP 285: Spin-Wait Hints (http://openjdk.java.net/jeps/285)https://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/345Speed up the scheduling of stateless stages2017-08-15T11:20:26+02:00Christian WulfSpeed up the scheduling of stateless stagesIdea:
The instance of a stateless stage could be executed by multiple threads at the same time.
Current Problems:
- The user must still indicate whether the ordering should be preserved. However, we could set the default to "preserve or...Idea:
The instance of a stateless stage could be executed by multiple threads at the same time.
Current Problems:
- The user must still indicate whether the ordering should be preserved. However, we could set the default to "preserve ordering".
- Each thread must reserve or copy its required number of input elements. For this purpose, such a stateless stage must consume a **fixed** number of elements per execution.
- What should happen with unprocessed input elements if an error occurs?Christian WulfChristian Wulfhttps://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/343Use an atomic bit vector to represent non-empty stage levels2017-08-15T12:40:10+02:00Christian WulfUse an atomic bit vector to represent non-empty stage levelsRequirements:
- arbitrary vector length (not only 32 or 64 bits)
- low synchronization overhead (e.g., by using compare and set)Requirements:
- arbitrary vector length (not only 32 or 64 bits)
- low synchronization overhead (e.g., by using compare and set)Christian WulfChristian Wulfhttps://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/338Add method CompositeStage.declareActive()2017-08-01T21:30:45+02:00Christian WulfAdd method CompositeStage.declareActive()Currently, a composite stage can be set active by setting one or more of its substages active:
```java
wc.getInputPort().getOwningStage().declareActive();
```
We should also add ``declareActive()`` to ``CompositeStage``. The stage devel...Currently, a composite stage can be set active by setting one or more of its substages active:
```java
wc.getInputPort().getOwningStage().declareActive();
```
We should also add ``declareActive()`` to ``CompositeStage``. The stage developer can then decide what ``declareActive()`` should mean for the particular composite stage.Version 3.0Christian WulfChristian Wulfhttps://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/335Automatically determine a reasonable capacity in TaskQueue2017-12-22T10:32:01+01:00Christian WulfAutomatically determine a reasonable capacity in TaskQueueChristian WulfChristian Wulfhttps://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/328Reconsider Default Distributor Strategy2017-05-04T16:06:18+02:00Sören HenningReconsider Default Distributor StrategyCurrently, the default strategy for Distributor is a round robin strategy. However, from a user perspective this strategy can lead to errors, which are hard to find, if I expect that my elements are passed to all connected stages.
My su...Currently, the default strategy for Distributor is a round robin strategy. However, from a user perspective this strategy can lead to errors, which are hard to find, if I expect that my elements are passed to all connected stages.
My suggestion is to redefine the default behavior of the Distributor either as using the `CopyByReferenceStrategy` as default or do not give a default strategy (i.e., a constructor without a parameter).https://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/316Further Features for the Configuration Builder2017-03-13T14:28:23+01:00Sören HenningFurther Features for the Configuration Builder* Support for distribution/merging
* `.distribute(strategy)` and `.merge(strategy)`
* Introduction of a composite stage builder
* both builders are more or less equal, but have different return types (`Configuration` or `CompositeSta...* Support for distribution/merging
* `.distribute(strategy)` and `.merge(strategy)`
* Introduction of a composite stage builder
* both builders are more or less equal, but have different return types (`Configuration` or `CompositeStage`)
* possible solution: Write one single builder which is type parameterized
* (`CompositeStageBuilder<T extends CompositeStage`)
* get builder by static `CompositeStage.builder()` or `Configuration.builder()` respectively
* `.toActive(stage)` and `.endActive(stage)` methods that connect the stage and additionally set it activehttps://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/312State of producers does not need to be volatile2017-03-24T08:07:41+01:00Christian WulfState of producers does not need to be volatileVersion 3.0Christian WulfChristian Wulfhttps://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/309Read exception message from properties file2017-01-21T08:36:09+01:00Christian WulfRead exception message from properties file```java
code:
new Exception( exceptionMessages.get(1002, args) )
file.properties:
1002 = SourcePort may not be null {<arg0>} {<arg1>}
``````java
code:
new Exception( exceptionMessages.get(1002, args) )
file.properties:
1002 = SourcePort may not be null {<arg0>} {<arg1>}
```https://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/308Taskfarm Stage: optimize task distribution2017-01-19T10:11:45+01:00Christian WulfTaskfarm Stage: optimize task distributione.g., by using a hash function returning a hash representing the index of the output port
- over the input task
- over the size of the output ports
- over the "activity" of the output portse.g., by using a hash function returning a hash representing the index of the output port
- over the input task
- over the size of the output ports
- over the "activity" of the output portshttps://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/307Taskfarm Stage: pin each worker to a separate core2017-01-19T10:08:49+01:00Christian WulfTaskfarm Stage: pin each worker to a separate corehttps://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/301TeeTime Logging should not be set to Trace by default2016-12-11T15:41:08+01:00Nils Christian EhmkeTeeTime Logging should not be set to Trace by defaultCurrently the TeeTime logging is set to Trace by default. This is in my opinion rather unusual. I recommend to set the default logging to warn for releases.
(Version is 2.1)Currently the TeeTime logging is set to Trace by default. This is in my opinion rather unusual. I recommend to set the default logging to warn for releases.
(Version is 2.1)Christian WulfChristian Wulfhttps://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/298ClassNameRegistryCreationFilter should optionally throw exception2016-10-03T12:11:23+02:00Nils Christian EhmkeClassNameRegistryCreationFilter should optionally throw exceptionWhen the ClassNameRegistryCreationFilter currently cannot find the directory or the mapping file, it logs an error and then returns. However, this behaviour makes it difficult to find out whether the import of a monitoring log was succes...When the ClassNameRegistryCreationFilter currently cannot find the directory or the mapping file, it logs an error and then returns. However, this behaviour makes it difficult to find out whether the import of a monitoring log was successful or not. Instead, the filter (and consequently the Dir2RecordsFilter as well) should provide a property or a constructor flag to switch the behaviour to: throw an actual exception in case of an error. This would lead to an ExecutionException thrown by the Execution, which then could be handled by the application.
(Version is 2.1)Christian WulfChristian Wulfhttps://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/294Execute merger in one of the previous thread2016-08-04T12:58:53+02:00Christian WulfExecute merger in one of the previous threadSo far, the merge must always be executed in a separated thread. We should consider to change this behavior either especially for the merger or even in general. An alternative behavior could use an additional thread for another stage and...So far, the merge must always be executed in a separated thread. We should consider to change this behavior either especially for the merger or even in general. An alternative behavior could use an additional thread for another stage and avoid a busy-waiting of the merger.Christian WulfChristian Wulfhttps://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/215Merge classes A0-A42016-02-22T14:28:10+01:00Nelson Tavares de SousaMerge classes A0-A4In order to avoid multiple traversing through the config we need to merge those classes.In order to avoid multiple traversing through the config we need to merge those classes.Version 2.1https://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/212Optimize MultipleInstanceOfFilter2015-07-30T15:45:25+02:00Nelson Tavares de SousaOptimize MultipleInstanceOfFilterFor every match, add the element to the Map with the corresponding port. (Kind of a caching technique)For every match, add the element to the Map with the corresponding port. (Kind of a caching technique)https://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/190Refactor internal and external API for ports2015-09-30T13:28:24+02:00Christian WulfRefactor internal and external API for ports**Current situation:**
- direct manipulation of input ports and output ports possible because internal array is published
**Requirements:**
- use a List interface
- iterate as fast as with arrays
**Solution proposal:**
```java
...**Current situation:**
- direct manipulation of input ports and output ports possible because internal array is published
**Requirements:**
- use a List interface
- iterate as fast as with arrays
**Solution proposal:**
```java
interface PortList<T, P extends AbstractPort<T>> {
int size();
void each(Consumer<T> consumer); // iterates all elements starting at 0
void each(Consumer<T> consumer, int startIndex); // iterates all elements starting at startIndex; really necessary?
P next(Next next);
boolean hasAnyOpenPort();
}
interface DynamicPortList<T, P extends AbstractPort<T>> extends PortList<T, P> {
/** returns the new index of the given port */
int add(P port);
void remove(int index);
}
interface Next {
int nextIndex(); // returns the next index to be used
}
```
- Next for ``RoundRobinStrategy`` and ``RemovePortAction``Christian WulfChristian Wulfhttps://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/186Refactor onSignal()2016-02-22T14:28:10+01:00Christian WulfRefactor onSignal()**Current Situation:**
A producer in ``RunnableProducerStage`` is signaled via
```this.stage.onSignal(new InitializingSignal(), null);```
calling
```void onSignal(ISignal signal, InputPort<?> inputPort);```
- Since a produ...**Current Situation:**
A producer in ``RunnableProducerStage`` is signaled via
```this.stage.onSignal(new InitializingSignal(), null);```
calling
```void onSignal(ISignal signal, InputPort<?> inputPort);```
- Since a producer does not have any input port, ``null`` needs to be passed.
This could be confusing.
- Moreover, a producer never receives a signal from an input port, but directly from its environment.
This could be confusing for stage developers.
**Solution:**
Perhaps, a producer should have another method ``triggerSignal`` or ``sendSignal``.
Furthermore, ``onSignal`` should be removed or refactored.
It should not contain an input port as parameter.Version 2.1https://git.se.informatik.uni-kiel.de/teetime/teetime/-/issues/184Improve check for "all input ports are closed"2016-02-22T14:18:59+01:00Christian WulfImprove check for "all input ports are closed"**Current situation:**
```java
for (InputPort<?> inputPort : inputPorts) {
if (!inputPort.isClosed()) {
return;
}
}
```
**Solution A:**
Use a bit set: each input port is represented by one digit.
A 1 means opened...**Current situation:**
```java
for (InputPort<?> inputPort : inputPorts) {
if (!inputPort.isClosed()) {
return;
}
}
```
**Solution A:**
Use a bit set: each input port is represented by one digit.
A 1 means opened, a 0 means closed.
If the bit set is 0, all input ports are closed.
Advantages:
- A single check for 0
Disadvantages:
- Allows "only" 32 (using an int) oder 64 (using a long) input ports. In a few years, where a 128-core is common, this limitation could be a problem.
**Solution B:**
Use two lists for ports: one for opened ports and one for closed ports.
Advantages:
- A single size check for 0
- Allows an arbitrary number of ports
- Allows to be used for iterating over opened ports, too
Disadvantages:
- iterating over all ports with one loop is not possible anymore (do we iterate over closed ports at all?)
**Solution C:**
Use a counter for opened ports.
Advantages:
- A single check for 0
- Allows an arbitrary number of ports
Disadvantages:
- iterating over all open ports is inefficient since the port list contains opened and closed ports
Version 2.1Christian WulfChristian Wulf