Allow loading new tilesets without restarting server about mbtileserver HOT 6 CLOSED

Another approach would be to respond to OS signals and restart based on those:
https://stackoverflow.com/questions/18106749/golang-catch-signals

For example, use HUP signal to trigger a reload of tilesets, without taking the server all the way down and back up.

One of the issues with a filewatcher approach is that files may not be fully ready when they are first detected on the filesystem, either due to copy in progress, or tile generation in progress.

from mbtileserver.

Here is an unpolished idea how to implement this now that we have the handlers package.

What if *mbtiles.ServiceSet did not have a Handler()method but would implement the http.Handler interface itself and muxes each request in the ServeHTTP method. Then we could dynamically check on the registered *mbtiles.DBs and route accordingly. And, as aimed for, we could even add more DBs while the webserver is already listening. Of course we would need to protect ServiceSet.tilesets with a mutex. Also the performance might be a tiny bit worse then using a dedicated and pre-filled *http.ServeMux (just a guess, benchmarks would be needed to be sure).

I reckon there are not many consumers of handlers in its current form, yet (maybe I am still the only one), so having a breaking API change is probably not a problem.

from mbtileserver.

@fawick what event would trigger adding more once the server is running? A file watcher detecting a change, an API call, or something else?

from mbtileserver.

In general, I think the answer depends on the needs of the users of the package handlers because from the outside a call to ServiceSet.AddDBOnPath would load the new tileset at runtime. For convenience, we could refactor filepath.Walk over a given directory into an own exported method so it does not need to be reimplemented on the outside. (That method could also remove any mbtiles.DBs, that are gone in the meantime).

Specific to the mbtileserver main, we could delegate the decision to the user, too, and have command line switches that trigger either the installation of an HTTP API endpoint, or the installation of a file watcher, or both. My point here is that all of this is outside of handlers.

from mbtileserver.

The new concurrent map in Go 1.9 should give us what we need for managing concurrency: https://golang.org/doc/go1.9#sync-map. No need for a separate library.

from mbtileserver.

Resolved by #69

from mbtileserver.