1. Introducing ability to reload microgateway for new config without … #42
Conversation
vk4u
commented
Sep 12, 2016
vk4u
commented
- Introducing ability to reload microgateway for new config without dropping messages.
- Used a node module called naught to achieve this.
- After this change, microgateway will always be starting in cluster mode and as a daemon.
- Owing to this there are 3 new commands added. Status, Reload, Stop.
…dropping messages. 2. Used a node module called naught to achieve this. 3. After this change, microgateway will always be starting in cluster mode and as a daemon. 4. Owing to this there are 3 new commands added. Status, Reload, Stop.
|
Kevin, |
| .option('-e, --env <env>', 'the environment') | ||
| .option('-k, --key <key>', 'key for authenticating with Edge') | ||
| .option('-s, --secret <secret>', 'secret for authenticating with Edge') | ||
| .option('-p, --processes <processes>', 'number of processes to start, defaults to # of cores') |
There was a problem hiding this comment.
@vk4u Why do we need to know the number of processes on reload? I would think we want to reload config on all processes. What happens if one were to pass in a smaller number than what was used on start?
There was a problem hiding this comment.
@kevinswiber Its an optional attribute. If one needs to bring up a different number of workers (may be more or less than the original number of workers) for any reasons, they can use this option. If left alone, original number of workers will be brought up.
|
@vk4u These changes will probably get rolled into a 2.1.0 release along with the changes coming for apigee/microgateway-core#9. It would be spectacular to get tests working before the minor release, but we can address that post-merge. |
|
@vk4u From the naught2 README:
This is problematic. Looking at the documentation, it appears that edgemicro currently supports Windows. Breaking Windows compatibility would be a pretty big bummer. Is there a way to offer this in a way that's cross-platform? |
|
@kevinswiber I did have a look at that. Naught was only possible to use from command line. I forked that and added the capability to call it from node. I think the restriction was given by the author to act on signals like SIGHUP and SIGTERM for non-daemon based bootup for server. For us we are always starting the process as a daemon and have dedicated scripts for reload and stop. Ideally, We should not have any problems. However, i have not tested on Windows, as i dont have one ;) Let me test it on windows and confirm this. Having said that im not sure if the current version of Microgateway works in Windows. If you can confirm that is works, ill test it for Windows and make necessary changes if anything is needed. |
| } | ||
| } | ||
| }); | ||
| run.start(options); |
There was a problem hiding this comment.
Why was the callback removed here?
| 'remove-old-ipc': 'true', | ||
| 'node-args': '' | ||
| }; | ||
| naught.start(naught_options, 'start.js', JSON.stringify(args)); |
There was a problem hiding this comment.
Sorry about the review open / review close stuff. Clearly I don't know what I'm doing with the new feature.
Error: Cannot find module '/Users/kevin/start.js'
at Function.Module._resolveFilename (module.js:440:15)
at Function.Module._load (module.js:388:25)
at Module.runMain (module.js:575:10)
at run (bootstrap_node.js:352:7)
at startup (bootstrap_node.js:144:9)
at bootstrap_node.js:467:3
module.js:442
throw err;
|
@vk4u Should this be reloading on HUP signals sent to the master process? I can't seem to get that to work. |
| agentConfig(argsJson, function (e) { | ||
| if (e) { | ||
| console.error('edge micro failed to start', e); | ||
| return; |
There was a problem hiding this comment.
@vk4u Can you add a process.exit(1) here?
|
BTW, isn't that PR re-adding another kind of |
Hey, @asnowfix. I wasn't involved with microgateway during the 1.x phase, but I believe this is different. This proposed change would allow the microgateway process to spawn multiple worker processes for handling incoming requests. A reload command should trigger the master process to start cycling workers, pending disconnect of existing traffic handling operations. This is how NGINX works today, IIRC. The number of worker processes is configurable. This should run just fine in Docker and should be deployable in a way that the master process is PID 1 in the container. Ideally, we'd be able to run @vk4u can likely do a better job answering these questions, as he's the one responsible for these changes. :) |
