Matchday Advancement
The Controller's purpose is to automatically and periodically advance the matchday of all match rounds that have a proper configuration for the advancement.
In order to configure a match round for the advancement, the match round must fulfill the following criteria:
- all matches of the current matchday must be finished
- the matchday properties for the next matchday have been set (these can either be number or date based)
- there is at least one match in the future
- the property for the automatic advancement has been set to determine a periodic time at which the advancement will happen, e.g. each friday at 6 pm
If any of the criteria does not match the matchday won't be advanced any further. This can be the case at the end of the season of a match round.
Example Advancement 1 (constant time span)
Assume that we got a match round with the following matchday configuration:
| Current matchday start date | Current matchday end date | Next matchday start date | Next matchday end date |
|---|---|---|---|
| 01/01/2018 | 07/01/2018 |
When the controller advances the matchday for the first time we get the following result assuming that we got matches in the future:
| Current matchday start date | Current matchday end date | Next matchday start date | Next matchday end date |
|---|---|---|---|
| 01/01/2018 | 07/01/2018 | 08/01/2018 | 14/01/2018 |
Note that the time span of one week (7 days) will be retained for the new next matchday. Now we advance one more time:
| Current matchday start date | Current matchday end date | Next matchday start date | Next matchday end date |
|---|---|---|---|
| 08/01/2018 | 14/01/2018 | 15/01/2018 | 21/01/2018 |
The time span is still retained. If we assume that there are no more matches after the 21/01/2018 the next advancement will be the last:
| Current matchday start date | Current matchday end date | Next matchday start date | Next matchday end date |
|---|---|---|---|
| 15/01/2018 | 21/01/2018 |
As you can see, we still got a current matchday but no new next matchday because there are no more matches. This might be the case at the end of a season.
Example Advancement 2 (rotating time span)
If you don't want to advance the matchdays by a constant time span, you also have the possibility to choose two different time spans for the current and next matchdays which will then be rotated.
For this example we assume that you want to rotate the matchdays twice a week. Since a week has an uneven number of days we will end with two time spans of different length.
We start with the following matchday configuration:
| Current matchday start date | Current matchday end date | Next matchday start date | Next matchday end date |
|---|---|---|---|
| 01/01/2018 | 04/01/2018 | 05/01/2018 | 07/01/2018 |
Note that the current matchday has a time span of 4 days while the next matchday has a time span of 3 days. After the first advancement the matchday configuration will look like this:
| Current matchday start date | Current matchday end date | Next matchday start date | Next matchday end date |
|---|---|---|---|
| 05/01/2018 | 07/01/2018 | 08/01/2018 | 11/01/2018 |
Note that the former next matchday became the new current matchday. Therefore the new current matchday now has a time span of 3 days while the new next matchday has the time span of 4 days because the former current matchday also got this time span.
If we advance one more time the matchdays will rotate the time spans again:
| Current matchday start date | Current matchday end date | Next matchday start date | Next matchday end date |
|---|---|---|---|
| 08/01/2018 | 11/01/2018 | 12/01/2018 | 14/01/2018 |
Now the current matchday got its 4 days back and the next matchday its 3 days time span. This kind of rotation will always be kept with further advancement.
Installation
The application is distributed as an executable Spring Boot jar file.
Packaged along this jar is a small shell script to support the common Sophora style installation with an apps directory containing the extracted tar.gz file and a working directory containing logs and config directories. The shell script should be linked from the working directory and then used to start, stop, restart etc. the application.
When you install the TableStar Controller, it is recommended to use the following folder hierarchy:
cms-install-directory
apps
tablestar-controller-2.6.0
tablestar-controller.sh
...
tablestar-controller > Symbolic link to tablestar-controller-2.6.0
...
tablestar-controller
config
application.yml
logs
tablestar-controller.sh > Symbolic link to ../apps/tablestar-controller/tablestar-controller.sh
...This hierarchy is analogous to the directory structure of the Sophora Sophora Server.
Starting and Stopping
To start the TableStar Controller invoke the tablestar-controller.sh as follows:
> cd cms-install-directory/tablestar-controller
> ./tablestar-controller.sh startFor configuration details see the following sections.
To stop the TableStar Controller prompt the following:
> cd cms-install-directory/tablestar-controller
> ./tablestar-controller.sh stopConfiguration
To change the configuration, edit the application.yml file which is located in the config subdirectory of the TableStar Controller installation.
Effectively you will only provide the connection information to the Sophora Server as well as the port the TableStar Controller uses.
See example configuration below.
Setting JVM Arguments
JVM arguments may be passed to the application via the JAVA_OPTS environment variable. Additionally, VM arguments may be specified in application.yml under the vmargs key.
If present in application.yml, the value is required to be single-quoted according to the YAML specification as in the following example:
vmargs: '-Xmx4096m -Dproperty="some value"'Otherwise the application might not start properly.
