Closed henrykuijpers closed 4 years ago
@henrykuijpers thanks for opening this issue. I tried to understand this and I think I did a mistake . As the reconfig_pre_aem
manifest has the parameter aem_jvm_jmxremote_port
but this Parameter actually does not get passed anywhere.
Therefore JMXRemote doesn't get activated or set in the start-env
when the reconfiguration is enabled, if I'm not mistaken.
As a result this is the only time when the JMX Remote gets enabled or activated
which than notifies the aem service to restart.
So the behaviour is actually correct it's just a mistake that the reconfig_pre_aem
manifest expects a parameter named aem_jvm_jmxremote_port
.
I hope this helps and clarifies it's a little bit ?
It does clarify a little bit. However, I think the way that the start-env etc are rewritten, is not correct. There seem to be a few loose ends, that (due to changes in the files), cause AEM to restart where it's not necessary.
I'm not sure if it's only the JMX that has to do with this.
Can you validate this with a provisioned instance, then run the reconfig? And then run it again? If the first reconfig doesn't actually change something, AEM doesn't have to restart, right? And the last reconfig (which for sure doesn't change anything) also shouldn't cause AEM to restart, right?
@henrykuijpers Thanks you're right I actually can reproduce it. My AEM sevice is getting refreshed as well. I'll do try to do a bit more debugging ...
Now this is very interesting ... these are the two events which are triggering a refresh of the AEM service which are:
2020-04-16 21:42:22 +1000 /Stage[main]/Aem_curator::Config_publish/File_line[publish: enable JMXRemote]/ensure (notice): created
2020-04-16 21:42:22 +1000 /Stage[main]/Aem_curator::Config_publish/File_line[publish: Add custom JVM OPTS settings]/ensure (notice): created
The reason why those two tasks are getting triggered in the first place is because we are resetting the file start-env
during the reconfiguration process https://github.com/shinesolutions/puppet-aem-curator/blob/master/manifests/config_publish.pp#L138-L151 ... therfor the start-env has changed and the tasks Set JVM memory opts
https://github.com/shinesolutions/puppet-aem-curator/blob/master/manifests/config_publish.pp#L179, enable JMXRemote
https://github.com/shinesolutions/puppet-aem-curator/blob/master/manifests/config_publish.pp#L189 & Add custom JVM OPTS settings
https://github.com/shinesolutions/puppet-aem-curator/blob/master/manifests/config_publish.pp#L189 will trigger a restart of the service ... I believe the only solution is to add another flag to enable/disable a reset of the binaries during the reconfiguration process.
@henrykuijpers The only possible solution I have here is to add a new enable flag. The default setting is == true
so make sure you pass the new parameter with false
. My tests so far were successfully which means the AEM Service wasn't restarted.
I'd like to dig a bit deeper and remove the whole customization with regards to start-env etc. I discussed with @cliffano about setting up a call to tackle this. I believe there should be no reason to do all this manually, this should be done with aem::config, but of course there's a reason this is not happening now?
For which use-case would you recommend aem::config
exactly ?
My initial plan to manage the AEM binaries was using the aem::config module but because aem::config
and our config manifests are creating the same directory crx-quickstart/install
I decided against it due to the lack of testing. I would give it another try though.
@henrykuijpers We've updated the logic of setting the JVM options for the AEM start-env, with puppet-aem-curator version 3.12.0.
We are now resetting the file everytime the AEM Component config manifest runs. This should fix the issue that AEM always restarts when updating the start-env.
Let us know if you are still experiencing any issues. I'll close this issue until than.
As you can see, the combination of the rewrite of the start-env script + enabling JMXRemote causes the AEM Service to be refreshed, therefore restarting AEM. This is not needed (no configuration was changed).
I believe an issue related to this was already addressed by @mbloch1986 in https://github.com/shinesolutions/puppet-aem-curator/issues/151 , but there could be an additional item to fix here.