I heard a rumor that the upcoming 8.3 architecture will no longer support “hot install/updates” on modules (Installing modules without restarting the Gateway). This is currently supported under the 8.1. Is this something the forum can confirm? If it is indeed the plan, is there any way to lobby to have the same functionality as in 8.1 for module install upgrades (ex. MQTT modules)?
1 Like
It's not a rumor, it's already done and implemented.
Modules can be staged for install/upgrade but it requires a gateway restart before it takes effect.
1 Like
Thanks for the response.
Are there plans to have modules install without a restart of the entire Gateway in the future? I think there are a lot of applications out there where Gateway restarts for module upgrades etc. would be very disruptive. Is there a particular rationale that I am missing with this approach in 8.3?
1 Like
I tried to make this case a year ago and was shot down. Don't hold your breath waiting for this functionality to come back.
1 Like
Any reason why this was done? I try to restart my gateway as infrequently as possible
It greatly simplifies classloader lifetime management, especially for jars that load native code.
It greatly simplifies module code to not have to account for circular dependencies on module unload.
It eliminates a whole host of long-standing unfixable bugs in internationalization (bundle utilities).
Probably more, but those are obvious to me as a module author.
1 Like
Yeah, so... basically this drastically simplifies the module system and eliminates an entire class of memory leak bugs that hot module loading allowed.
I know from a user perspective, if you used this, then you are pretty much losing a very tangible feature in exchange for something less tangible ("system stability and maintainability").
It wasn't a choice made lightly. I know all the squeaky wheels are about to jump in and tell me we're wrong, but we did talk to a lot of users about this, most people never upgrade/add/remove individual modules, and there's also a small contingency of users who believe that it's even an inappropriate thing to make possible in a production deployment (think about highly automated or mass deployment scenarios, with docker/k8, where you really want to be deploying a "known good" configuration and the behavior, within reason, shouldn't change).
There's a lot of work going into 8.3 and the next versions that are focused on foundational features, stability, and paying off tech debt. Kind of the answer to a thought experiment along the lines of "okay, we've made it 20 years... we have a 20 year old code base... how do we make it the next 20 years?".
5 Likes
I recall conceding to @Carl.Gould that the prospect of fast gateway restarts (enabled by this simplification) would moot my concerns. Where a restart is about as fast as redundancy fail-over. ~10 seconds or so.
3 Likes
Fast Gateway (re)start would be nice... wouldn't count on it for 8.3 though 
1 Like
8.3.x, perhaps?
(x <100) 
3 Likes
I guess this all makes sense, I just hate restarting my gateway even with a failover. Feels like I end up spending an hour remoting into all of my onlogic devices to refresh the connection
I started looking into it once... if I remember correctly, the tag system was a big hit, and then there was also a very pronounced and linear relationship to the number of projects you have. I think maybe something about there being a Jython ScriptManager and everything else associated with that, for each project.
I had a long discussion with Carl on that specific issue, and made some suggestions on parallelizing it that I think bounced off his shields. 
I guess that if we have a redundant Slave Gateway it shouldn't be a problem?