no more hot restart?

Poster	Content
pjr nk4um Moderator Posts: 756	<div>Runlevels are not exactly the same as nix. They are simply an arbitrary integer value and offer a way to group modules together and have them load/unload at the same time. Typically the core system modules live at runlevel 3 and below. Apps, transports, tests etc live at 5 and above.<br/><br/>Incidentally there is another way to start and stop a module - you can use the new deployment editor tool...<br/><br/>http://localhost:1068/tools/deployment/<br/><br/>Click on the name of the module and then toggle "enabled".<br/><br/>P.</div> 2009-12-31T12:53:06.000ZDecember 31, 2009 12:53 Runlevels are not exactly the same as nix. They are simply an arbitrary integer value and offer a way to group modules together and have them load/unload at the same time. Typically the core system modules live at runlevel 3 and below. Apps, transports, tests etc live at 5 and above. Incidentally there is another way to start and stop a module - you can use the new deployment editor tool... http://localhost:1068/tools/deployment/ Click on the name of the module and then toggle "enabled". P.
jrogers nk4um User Posts: 101	<div>I understand how runlevels could work, but there are a few problems with that. <br/><br/>The obvious one is that they are undocumented. There''s no hint that you should set a runlevel on your module, let alone guidance suggesting what that level should be. (I shouldn''t use runlevel 6, on my linux box that means reboot!)<br/><br/>Second, it''s a broad brush for a narrow problem. If I change the runlevel that could affect many other unrelated modules.<br/><br/>Besides, in a dynamic system it makes more sense to have things be dynamic by default and have a way to turn that off rather than the other way around. The additional overhead would be negligible, especially if the dynamic monitoring was restricted to just the module.xml file and not all class files which is more sensible anyway (if you monitor all class files then you could conceivably do a hot restart before your build has finished, and it would be easy enough to add a rule to your Makefile to touch module.xml after the build finishes to trigger the restart).<br/><br/>For now tho, I''ll be careful to make sure all my modules are <dynamic/>.</div> 2009-12-30T22:30:48.000ZDecember 30, 2009 22:30 I understand how runlevels could work, but there are a few problems with that. The obvious one is that they are undocumented. There''s no hint that you should set a runlevel on your module, let alone guidance suggesting what that level should be. (I shouldn''t use runlevel 6, on my linux box that means reboot!) Second, it''s a broad brush for a narrow problem. If I change the runlevel that could affect many other unrelated modules. Besides, in a dynamic system it makes more sense to have things be dynamic by default and have a way to turn that off rather than the other way around. The additional overhead would be negligible, especially if the dynamic monitoring was restricted to just the module.xml file and not all class files which is more sensible anyway (if you monitor all class files then you could conceivably do a hot restart before your build has finished, and it would be easy enough to add a rule to your Makefile to touch module.xml after the build finishes to trigger the restart). For now tho, I''ll be careful to make sure all my modules are <dynamic/>.
pjr nk4um Moderator Posts: 756	<div>Could be - but that''s where runlevels come in. If you have declared your module with a runlevel then you can unload it by lowering the runlevel, reload it by raising the runlevel - this is just like nix runlevel''s for daemons.<br/><br/>You can set the runlevel in the kernel config <br/><br/>http://localhost:1060/tools/kernelconfig<br/><br/>All these settings are dynamic and applied immediately on hitting "Save".<br/><br/>Hope this helps.<br/><br/>P.</div> 2009-12-30T21:44:42.000ZDecember 30, 2009 21:44 Could be - but that''s where runlevels come in. If you have declared your module with a runlevel then you can unload it by lowering the runlevel, reload it by raising the runlevel - this is just like nix runlevel''s for daemons. You can set the runlevel in the kernel config http://localhost:1060/tools/kernelconfig All these settings are dynamic and applied immediately on hitting "Save". Hope this helps. P.
jrogers nk4um User Posts: 101	<div>This explains a piece of awkward behavior that I tripped across by accident: if you do not specify that your module is dynamic, then there is no way to reload it without rebooting.<br/><br/>It would make more sense to make all modules dynamic, at least for file-based ones. If someone really needs a non-dynamic module they could make it into a jar.<br/><br/>The full reboot is a nice addition (I had implemented something similar with my nk3 startup script), as it gives you a reasonable chance to recover from permgen or linkage errors.</div> 2009-12-30T21:38:21.000ZDecember 30, 2009 21:38awkward This explains a piece of awkward behavior that I tripped across by accident: if you do not specify that your module is dynamic, then there is no way to reload it without rebooting. It would make more sense to make all modules dynamic, at least for file-based ones. If someone really needs a non-dynamic module they could make it into a jar. The full reboot is a nice addition (I had implemented something similar with my nk3 startup script), as it gives you a reasonable chance to recover from permgen or linkage errors.
pjr nk4um Moderator Posts: 756	<div>Hi Jeff - good question.<br/><br/>You''re right there is no longer any need to shutdown the kernel with the old style hot-restart (nor NK3''s full reset with a cold-restart). In NK4 all modules (actually spaces) are dynamically affiliated all the time.<br/><br/>So when a new module is added or removed from the system the kernel pauses, the spacial relations are worked out and if necessary only the minimum set of spaces related to the change are recommissioned.<br/><br/>When a module is marked as <dynamic> it is monitored for changes - to both the module.xml and any Java class files - if a change is detected the module is recommissioned (plus all related spaces).<br/><br/>Effectively NK3''s hot-restart is now much finer grained in NK4, with the same net effect of allowing transports to stay live whilst the system is reconfigured, but with the minimal possible change and shortest delay to production operation time.<br/><br/>FYI the reboot option is now a complete JVM reboot (tear down to the outer boot shell script) - its there just in case you need it.<br/><br/>One of the less obvious things about NK4''s true dynamic spaces is that they are now very lightweight and can actually be programatically constructed. The dynamic import pattern (where a space can import itself upwards into a higher level space) and the HTTPBridge (where a new space containing the HTTP state is constructed and inserted into the superstack for every HTTP event) are examples of this. We expect there will be many spin-out tools that exploit this new dimension as people start to push the architectural patterns.<br/><br/>Peter</div> 2009-12-30T20:56:51.000ZDecember 30, 2009 20:56 Hi Jeff - good question. You''re right there is no longer any need to shutdown the kernel with the old style hot-restart (nor NK3''s full reset with a cold-restart). In NK4 all modules (actually spaces) are dynamically affiliated all the time. So when a new module is added or removed from the system the kernel pauses, the spacial relations are worked out and if necessary only the minimum set of spaces related to the change are recommissioned. When a module is marked as <dynamic> it is monitored for changes - to both the module.xml and any Java class files - if a change is detected the module is recommissioned (plus all related spaces). Effectively NK3''s hot-restart is now much finer grained in NK4, with the same net effect of allowing transports to stay live whilst the system is reconfigured, but with the minimal possible change and shortest delay to production operation time. FYI the reboot option is now a complete JVM reboot (tear down to the outer boot shell script) - its there just in case you need it. One of the less obvious things about NK4''s true dynamic spaces is that they are now very lightweight and can actually be programatically constructed. The dynamic import pattern (where a space can import itself upwards into a higher level space) and the HTTPBridge (where a new space containing the HTTP state is constructed and inserted into the superstack for every HTTP event) are examples of this. We expect there will be many spin-out tools that exploit this new dimension as people start to push the architectural patterns. Peter
jrogers nk4um User Posts: 101	<div>I''m starting to explore nk4 and it looks like there is no more hot and cold restart, just "reboot". Did I miss something?<br/><br/>The benefit of a hot restart (as I understood it) was that transports would not be reloaded (unless they changed), so from the outside serving of requests would just appear to slow down for a moment, not get errors.</div> 2009-12-30T20:21:07.000ZDecember 30, 2009 20:21no more hot restart? I''m starting to explore nk4 and it looks like there is no more hot and cold restart, just "reboot". Did I miss something? The benefit of a hot restart (as I understood it) was that transports would not be reloaded (unless they changed), so from the outside serving of requests would just appear to slow down for a moment, not get errors.

pjr

nk4um Moderator

Posts: 756

December 31, 2009 12:53

Runlevels are not exactly the same as *nix. They are simply an arbitrary integer value and offer a way to group modules together and have them load/unload at the same time. Typically the core system modules live at runlevel 3 and below. Apps, transports, tests etc live at 5 and above.

Incidentally there is another way to start and stop a module - you can use the new deployment editor tool...

http://localhost:1068/tools/deployment/

Click on the name of the module and then toggle "enabled".

P.

jrogers

nk4um User

Posts: 101

<div>I understand how runlevels could work, but there are a few problems with that.  The obvious one is that they are undocumented.  There''s no hint that you should set a runlevel on your module, let alone guidance suggesting what that level should be.    (I shouldn''t use runlevel 6, on my linux box that means reboot!) Second, it''s a broad brush for a narrow problem.  If I change the runlevel that could affect many other unrelated modules. Besides, in a dynamic system it makes more sense to have things be dynamic by default and have a way to turn that off rather than the other way around.  The additional overhead would be negligible, especially if the dynamic monitoring was restricted to just the module.xml file and not all class files which is more sensible anyway (if you monitor all class files then you could conceivably do a hot restart before your build has finished, and it would be easy enough to add a  rule to your Makefile to touch module.xml after the build finishes to trigger the restart). For now tho, I''ll be careful to make sure all my modules are &lt;dynamic/&gt;.</div>

December 30, 2009 22:30

I understand how runlevels could work, but there are a few problems with that.

The obvious one is that they are undocumented. There''s no hint that you should set a runlevel on your module, let alone guidance suggesting what that level should be. (I shouldn''t use runlevel 6, on my linux box that means reboot!)

Second, it''s a broad brush for a narrow problem. If I change the runlevel that could affect many other unrelated modules.

Besides, in a dynamic system it makes more sense to have things be dynamic by default and have a way to turn that off rather than the other way around. The additional overhead would be negligible, especially if the dynamic monitoring was restricted to just the module.xml file and not all class files which is more sensible anyway (if you monitor all class files then you could conceivably do a hot restart before your build has finished, and it would be easy enough to add a rule to your Makefile to touch module.xml after the build finishes to trigger the restart).

For now tho, I''ll be careful to make sure all my modules are <dynamic/>.

pjr

nk4um Moderator

Posts: 756

December 30, 2009 21:44

Could be - but that''s where runlevels come in. If you have declared your module with a runlevel then you can unload it by lowering the runlevel, reload it by raising the runlevel - this is just like *nix runlevel''s for daemons.

You can set the runlevel in the kernel config

http://localhost:1060/tools/kernelconfig

All these settings are dynamic and applied immediately on hitting "Save".

Hope this helps.

P.

jrogers

nk4um User

Posts: 101

December 30, 2009 21:38awkward

This explains a piece of awkward behavior that I tripped across by accident: if you do not specify that your module is dynamic, then there is no way to reload it without rebooting.

It would make more sense to make all modules dynamic, at least for file-based ones. If someone really needs a non-dynamic module they could make it into a jar.

The full reboot is a nice addition (I had implemented something similar with my nk3 startup script), as it gives you a reasonable chance to recover from permgen or linkage errors.

pjr

nk4um Moderator

Posts: 756

<div>Hi Jeff - good question. You''re right there is no longer any need to shutdown the kernel with the old style hot-restart (nor NK3''s full reset with a cold-restart).  In NK4 all modules (actually spaces) are dynamically affiliated all the time. So when a new module is added or removed from the system the kernel pauses, the spacial relations are worked out and if necessary only the minimum set of spaces related to the change are recommissioned. When a module is marked as &lt;dynamic&gt; it is monitored for changes - to both the module.xml and any Java class files - if a change is detected the module is recommissioned (plus all related spaces). Effectively NK3''s hot-restart is now much finer grained in NK4, with the same net effect of allowing transports to stay live whilst the system is reconfigured, but with the minimal possible change and shortest delay to production operation time. FYI the reboot option is now a complete JVM reboot (tear down to the outer boot shell script) - its there just in case you need it. One of the less obvious things about NK4''s true dynamic spaces is that they are now very lightweight and can actually be programatically constructed. The dynamic import pattern (where a space can import itself upwards into a higher level space) and the HTTPBridge (where a new space containing the HTTP state is constructed and inserted into the superstack for every HTTP event) are examples of this.  We expect there will be many spin-out tools that exploit this new dimension as people start to push the architectural patterns. Peter</div>

December 30, 2009 20:56

Hi Jeff - good question.

You''re right there is no longer any need to shutdown the kernel with the old style hot-restart (nor NK3''s full reset with a cold-restart). In NK4 all modules (actually spaces) are dynamically affiliated all the time.

So when a new module is added or removed from the system the kernel pauses, the spacial relations are worked out and if necessary only the minimum set of spaces related to the change are recommissioned.

When a module is marked as <dynamic> it is monitored for changes - to both the module.xml and any Java class files - if a change is detected the module is recommissioned (plus all related spaces).

Effectively NK3''s hot-restart is now much finer grained in NK4, with the same net effect of allowing transports to stay live whilst the system is reconfigured, but with the minimal possible change and shortest delay to production operation time.

FYI the reboot option is now a complete JVM reboot (tear down to the outer boot shell script) - its there just in case you need it.

One of the less obvious things about NK4''s true dynamic spaces is that they are now very lightweight and can actually be programatically constructed. The dynamic import pattern (where a space can import itself upwards into a higher level space) and the HTTPBridge (where a new space containing the HTTP state is constructed and inserted into the superstack for every HTTP event) are examples of this. We expect there will be many spin-out tools that exploit this new dimension as people start to push the architectural patterns.

Peter

jrogers

nk4um User

Posts: 101

December 30, 2009 20:21no more hot restart?

I''m starting to explore nk4 and it looks like there is no more hot and cold restart, just "reboot". Did I miss something?

The benefit of a hot restart (as I understood it) was that transports would not be reloaded (unless they changed), so from the outside serving of requests would just appear to slow down for a moment, not get errors.