Index Excecution Server

[net-cscience-raphael]

This is not a great idea, since it starts something that is again threaded. So you have control of threads within threads, this will get messy and unpredictable really quickly.

Well fundamentally, this is exactly what needs to happen. The thread handling the HTTP request hands this to another thread that handles the extraction asynchronously. Since this is potentially long running, we must provide APIs to poll the state of this.

However, I think there's two things that must be changed (fundamentally):

* `ExecutionServer` should be a singleton for an instance of `vitrivr-server `

* `ExecutionServer` should provide methods to execute extraction / query pipeline synchronously and asynchronously.

* The implementation details on how asynchronous processing should be internal to `ExecutionServer`. I'd suggest a shared, bound thread pool / execution service.

I would argue that an API handler should never explicitly spawn new threads. If we have an execution server singleton, the handler should enqueue the job with it. It is then up to the execution environment to deal with it to the best of its abilities given the available resources. Of course, at some point, new threads will need to be spawned, but that is not the job of the API handler.

The Commit 3bd8db9 changes the ExecutionServer as a Singleton for each instance of a schema.
On instantiate a execution thread gets started and a new extraction can be added with val uuid = schema.getExecutionServer().enqueueIndexJob(pipeline). Further one can get the status of a job with val status = schema.getExecutionServer().isPending(id)

[lucaro]

I think this is a much better direction. However, the number of simultaneous extractions you can support is a function of your computing resources and not one of the number of independent schemas. In the limit, if you were to have a large number of schemas, adding to each of them simultaneously would again cause the same issues. I'd, therefore, singleton (if that's a verb) it even further and just have one. That mechanism is then free to schedule jobs however it likes, maybe even multiple at the same time if resources allow for it (and one actually wants to go through the trouble of building a proper scheduling mechanism for this).