functionality to abort running executions

[bolandka]

Very useful e.g. when a sleep-deprived Kata starts a bootstrapping algorithm with threshold 0.0... Or a non-sleep-deprived evil non-Kata does similar things.

Desirable:

1. being able to "delete" a running execution via swagger
2. having automatized mechanisms to kill processes that exceed some specified processing time / memory usage / whatever

Opens up some other questions:

• how to make sure a person may only disrupt his own executions? Do we want to require users to login before using? Or some other mechanism? ...

[kba]

Some comments by the not-sleep-deprived-anymore @kba:

• Strongly against auth. I can see that we might need it, but then we should stop and discuss this thoroughly and implement something that is sustainable. Auth schemes that work within a User interface and the REST API (and the backend?), the modelling of users and permissions etc. take time to plan and implement.
• From the infolis-web perspective, the functionality would be very thin: Handle some HTTP requests by the user on an execution and
  • signal to the backend that it should poll the new execution state or
  • signal execution and new state to the backend

In any case, some effort hast to be invested in the threadPool managing the executions on the backend to handle state updates, e.g. pausing/restoring/aborting threads.

Not hard, but tedious to test and catch all edge cases and make it work in a Servlet container.

I'd propose that we go about this in three steps:

1. Implement and test execution state changes on the backend
2. Implement a service endpoint on the backend (e.g. PATCH on /infoLink-1.0/infolis-web/execute) to expose this functionality
3. Create an external-facing webservice to update the state of an execution or reuse the RESTful semantics
4. Create either a client library (might be a good use case for the JS client) or a cronjob or similar that polls /api/monitor, retrieves status information via /api/execution/:id (such as When was the last time the log got updated? or the memory footprint which the backend would need to post).

Anyway, I think 2) and 3) are easy to implement (needs minor discussions on the protocol), 1) needs a lot of testing and 4) can be as simple or as complicated as necessary.