Reloading configuration without restart

[prymitive]

Right now any change in vassal config will cause its restart but some options could be changed without that, for example --max-requests or --cron. I guess that this would require big changes in options handling (like adding requires restart flag to option definition or so) and I don't really need it right away, but it would be great if uWSGI could eventually have such feature.

[akx]

This sounds like something that might extend the ManagementFlag interface? http://projects.unbit.it/uwsgi/wiki/ManagementFlag

(Yes, yes, I know, sorry -- ManagementFlag hasn't been ported to the new docs yet :D)

[unbit]

i think the whole management flag subsystem should be rewritten to support more (all ?) parameters.
Maybe the simplest choice is changing it to be more "string" based, so each re-configure packet could be a simple list of key-value items. The uwsgi_option flag field should take an additional flag marking ONTHEFLY options (the ones that could be changed without reload). After having such a system, implementing a config-update system should be extremely easy and fast.

Example:

{'max-requests':'1000', 'harakiri':'40'} => will update both max-requests and harakiri without taking down the instance

while

{'sockets':'/tmp/foobar'} => is not an onthefly option and it will be ignored

[prymitive]

Adding possibility to update all settings on-the-fly would require massive changes to whole code base, and forkish nature of uWSGI will make it tricky.
Example: caches are initialized in the master on startup and we can't change them after workers are forked since workers will have different configuration than master.

I've added it to 2.0 milestone, IMHO we should try to come up with a better solution for this during 2.0 development (when there is possibility to make backward incompatible changes if needed) and once there is a way of doing this in the core, we can start migrating options to it.

[unbit]

I think this will be pretty undoable without a complete rewrite, and, in addition to this, will make plugin development really complex (as you need to manage locking when reading options). Closing it, maybe some idea will popup in the future.