Discussion : Wait for installer state to be ok before continuing.#110
Discussion : Wait for installer state to be ok before continuing.#110zipkid wants to merge 2 commits into
Conversation
|
This might fix #82 as well. |
zipkid
force-pushed
the
feature/wait_for_install_ok
branch
from
f29031d to
8375759
Compare
| require 'net/http' | ||
| retries ||= @resource[:retries] | ||
| retry_timeout = @resource[:retry_timeout] | ||
| host = 'http://localhost:4502' |
There was a problem hiding this comment.
The fixed port '4502' should come from the "port" parameter -> see build_cfg method
There was a problem hiding this comment.
True, but for that i needed to modify the 'build_client' function, which i did not want to do for this PR. It is mainly intended as a discussion entry-point and definitely not as a final clean-code PR.
|
@bstopp , I have updated the .rubocop.yaml -> 'TargetRubyVersion: 2.2'. |
|
Do you have a use case or manifest set that shows this occurring? What is causing the AEM restart, a puppet change or a user initiated change? What is being experienced right now? A number of subsequent failures? I am pretty certain i know what the issue is, and this won't solve it; the system already does a check with retries here when the resource is encountered by Puppet for applying. I was pretty sure i opened a ticket somewhere on the underlying issue; if i find it, i'll link it. |
|
Hi @bstopp, An exact example of what we have observed is the following: In our setup we have a clean AEM 6.3 installation, followed by a Service Pack 1 and Cumulative Fix Pack 2 package installation. When we do a clean install, we have observed that the CFP is often (but not always) only partially installed. When going to the package manager, a substantial number of the sub-packages are still in an uninstalled state. To try and make the package installations more robust, we are trying to add a more reliable check on the installation state. This check is based on the Sling OSGi Installer JMX MBean which is mentioned in the following AEM Gem: In the mean while I have also learned that the following end-point provides similar information, though it is documented nowhere, and googling for it seems to return no Adobe search hits at all. /crx/packmgr/installstatus.jsp I've decompiled the code, and it does a very simple check on the ActiveResourceCount attribute of the Sling OSGi Installer JMX MBean being '0' or not. I hope this clarifies the necessity for these changes, if not I can provide more info. Fyi, there are still a issues to tackle or think about.
|
|
@bstopp any input on this? |
|
Can you confirm this wasn't fixed with v3.0.0? |
5 participants
We often see the crx installer fail because AEM is restarting or in any other way not able to handle the necessary queries/commands.
This adds a 'wait for ok to install state' in the crx installer provider.
This type of 'wait' may also be needed in the other providers but possibly without/with another check than the 'Sling+OSGi+Installer.json' .
This code is certainly not good to be merged but we would like to discuss where/how this could be done to ensure clean puppet runs.
Maybe this should be part of https://github.com/bstopp/crx-packmgr-api-client-gem, but that is generated from https://github.com/bstopp/swagger-aem, which i don't know how to work with.