You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ideally services would be crash first, since that is th easiest model to work with. but unfortunately this won't serve all the servers:
the store creates in-memory representations of the trees, which will take a bit of time to create, so for that service it is best to avoid restarts
the rpc server works as a reverse proxy, restarting the service would close all client connections, which is not great for end-user performance
the current version of the block producer contains only in-memory store of transactions, so restarts would cause issues, eventually this will be lifted, but we should probably avoid losing in-flight transactions if we can
because of the above, we should have a way of managing the servers without requiring restarts. there are multiple ways this can be implemented:
watch dog over the configuration files, so when the file is written, the server reloads the configuration and applies the changes
this is nice and has a neat interface, but it can become an issue for cases were the user introduces syntax errors to the file
a control socket. this can be a unix socket (file socket), or a proper networked socket.
this is a neat approach, usually the socket is hidden behind a CLI program. it can be useful for settings that should not be persisted
system signals. like sigusr1
this is great to integrate the servers with process monitors, works well with systemd and other tools, but we have limited number of signals
I don't think any of the options above are ideal, usually a mix of each gives the best results
The text was updated successfully, but these errors were encountered:
for file watching it seems the best option is notify, it is wildly used (see the docs). The only other option I found was watchman, but that requires an external service.
the only downside is that the api seems to be sync, so we should probably nave a file watching "service" running on a separate thread, sending events to the async tasks in tokia via channels. (note: we can make the service unnecessary by watching a single file, that would mean the configuration of all the services should fit in the same file)
Ideally services would be crash first, since that is th easiest model to work with. but unfortunately this won't serve all the servers:
because of the above, we should have a way of managing the servers without requiring restarts. there are multiple ways this can be implemented:
I don't think any of the options above are ideal, usually a mix of each gives the best results
The text was updated successfully, but these errors were encountered: