preserve original instance configuration after server reboot (Windows Service)

[bjrmatos]

user was reporting (via email) that he started jsreport's windows service using:

node server install –-httpPort=4998

and server started on 4998 normally, but after a reboot the server was not using that port (i guess jsreport used the default port 5488). this is due to not preserving the original instance configuration when creating the windows service (we should check that custom args are preserved too).

i see two solutions for this:

• before creating the windows service, initialize a jsreport instance and read the configuration in there, then pass those configuration values as ENV vars to the windows service (also ensuring that custom args are being recognized by nssm), that will ensure that when restarting the service the initial configuration will be applied.

• pass new --config path/to/current-config arg to windows service (also ensuring that custom args are being recognized by nssm)

i prefer the first one because it ensures all exact configuration is applied (because it will have all config parsed by nconf)

[pofider]

Hm. Shouldn't we rather strictly demand the configuration to be in the configuration file in this case? I mean inform user that args and envs are not applied to the service and they should put all configs into configuration file.

Your first solution will kind of hide the config values somewhere. I'm not even sure how I would find out which configuration values are actually applied to the running windows service when maintaining it. I would prefer that it is explicit and clear to anyone what config the service runs. This means using the standard jsreport.config.json file.

[bjrmatos]

Your first solution will kind of hide the config values somewhere.

yes, that is true. my first thought was that it is better to apply everything exactly (even configuration that you pass in custom jsreport constructor with server side code).

Hm. Shouldn't we rather strictly demand the configuration to be in the configuration file in this case? I mean inform user that args and envs are not applied to the service and they should put all configs into configuration file.

i think that args are useful, you have port 5488 on your app config but you want your windows service on 5489 (maybe for having something up for testing), if we don't apply args you will have to edit your config file twice (to change it to 5489 and install windows service and then to go back to 5488).

also, the idea is to read standard config file and take the values in there and preserve those original values between reboots, right? meaning that on reboots we won't try to read the config file again and apply what is in there at the moment

[pofider]

also, the idea is to read standard config file and take the values in there and preserve those original values between reboots, right? meaning that on reboots we won't try to read the config file again and apply what is in there at the moment

No. The service on boot always load the currently present configuration file. We won't preserve the original config in some artificial place. It is what I would expect - I want to change the port, I look at the service location, open the config, edit the port and restart the service.

i think that args are useful

Ok. You convinced me. So lets pass also the args to the nssm. It seems winser has an API for it. It will be likely displayed in the properties of the service in the end. However I would personally recommend to use the config anyway.

[bjrmatos]

No. The service on boot always load the currently present configuration file.

sounds fine, i was just worried about the potential case where you use single jsreport.config.json, you always edit this file in dev and probably your windows service is like a production server, so when your machine reboots your dev config ends up in production server. the way i was seeing is that a windows service is like an executable with preconfigured options, no matter if you reboot or not when you start it up, it should preserve the configuration used when create it.

also, i think we can introduce an option to the win install command --production to automatically install the service with NODE_ENV=production right now it requires that your process has this env var defined, but that is not something obvious to discover.

[pofider]

It is common approach. Look at mongo for example. You have config file which is loaded by the windows service at the start. It is a task for release management to deploy the right config file to the production. I understand your point of view to a windows service. But the windows service is not used like that normally. Otherwise you would need to reinstall the service on each change. The common approach is change config and restart.

also, i think we can introduce an option to the win install command --production

Yes this could come. We need to do some analyzing about the differences between the dev and prod before. So far it brought only lot of confusion and questions to users and almost no benefits. However this deserves another topic. Until then I think users will use the single config file and they won't be interested in running the service in development vs production because there shouldn't be a big difference.

[bjrmatos]

It is common approach. Look at mongo for example. You have config file which is loaded by the windows service at the start. It is a task for release management to deploy the right config file to the production. I understand your point of view to a windows service. But the windows service is not used like that normally. Otherwise you would need to reinstall the service on each change. The common approach is change config and restart.

sure, i'm not a windows user for a long time 😃 so this look fine.

Yes this could come. We need to do some analyzing about the differences between the dev and prod before. So far it brought only lot of confusion and questions to users and almost no benefits. However this deserves another topic. Until then I think users will use the single config file and they won't be interested in running the service in development vs production because there shouldn't be a big difference.

👍