We are running version purge manually in AEM repository occasionaly. When this is being done, the segment store size grows exponentially. So is there way to stop version purge activity from the backend (server) or front end (UI) inbetween? Because I see only the Start button in the version purge console and not a Stop/Kill button and I'm assuming restarting the AEM instance is the only way to kill version purge activity which should not be an ideal case. Please share your inputs.
Related
I had a catalog of version 1.0.0
I made changes to the catalog with the same version, rancher still shows the old catalog.
I have read that it is because Rancher's caching mechanism.
Ok, I then incremented the version to 1.0.1
Rancher still shows the old one.
Then made increment to 1.0.2, 1.0.4 ..etc. Still the old one.
How to force Rancher to use the real catalog instead of showing some old one??
How to clear calatog cache?
rancher v2.4.3
edit: the only solution currently is to increment version in bigger steps like 1.1.x
Here is what I have found:
Rancher doesnt provide any information about the Catalog cache or any kind of possbility to reset it.But it seems it clears the cache for the catalog once the corresponding repository deleted from the Catalog page.
Clearing the cache:
Delete the helm repository then wait the clear-cache mechanism to take effect. It takes ~1 min. Then readd the repository and it seems to work.
Whether the new catalog is in effect can be checked in the Preview section on the App Launch/Upgrade Form.
To be more specific:
The caches are stored here (at least in case of dockerized Rancher):
/var/lib/rancher/management-state/catalog-cache
So -after the deletion- once you see the corresponding cache folder has been removed you are good to go.
We have a setup where Rancher-2.5.9 is used. In this Deleting a repository is not needed. A catalog refresh works fine (select the catalog, choose the menu option, and click on refresh). I can see the new version pushed a few minute back are available in the dropdown.
But unfortunately the same is not working on another setup where rancher-2.6.3 exists. Need to debug more and see if the issue is there in the setup or in the rancher version.
So we need to provision (add the jms extension/subsystem/configurations to standalone.xml) the JMS subsystem in wildfly when starting the server if it's not already provisioned and that needs to happen automatically. We have an application written in java and we chose to provision the jms subsystem with wildfly's cli java api and that is executed when our application starts deploying. The thing is we need to provision the jms subsystem and use it in the same application.
Problem is, when we add the needed configurations in standalone.xml with wildfly's cli java api, the server requires a reload but we can't reload it because our app is already deploying, it tries to use the defined queues and fails because... Well, the subsystem is not active yet. On next server restart everything is ok but as you can guess in a production environment this is unacceptable. Is there any solution to this? I've tried adding a reload cli command in the end of the batch that creates the jms subsystem and it starts reloading the server but the deployment doesn't stop and exceptions start flying left and right.
Also the whole idea of reloading the server from the app while the app is deploying seems kinda wrong to me.
Thanks in advance.
Solution:
Well the solution in the end was an easy one, we just had to add a reload step in the batch operation that adds the jms subsystem. The problem was that we had a set of async operation that all fired off when the app was deployed so i just had to make sure none of them started until i can check for the messaging subsystem and reload wildfly if necessary. That way I'm not interrupting any async tasks forcefully.
You need to select appropriate profile i.e full or full-ha while starting server only. If you do this there will not be need to add JMS subsystem.
If you want to go with your approach only, add dependency of queue in
application. It will not start deploying until and unless queue is bound to server.
we need to perform reload operation when we add new subsystem, if you dont want to perform reload operation then I will suggest you to start server in 'admin-only' mode. When we start server in 'admin-only' mode then it open only management port(9990/9999). Configure messaging subsystem through CLI command reload server instance. Hope it helps..!!
As shown on the screen capture below: On page reload my webapp's required resources are fetched from service worker, but it still takes 1.42 for anything to render on the page. What i was expecting, on all reloads of the page the items cached by the service worker should render instantly.
Is it something I'm missing?
The files may not be cached and the installation of the Service Worker failed.
Its possible that there are files that failed to be downloaded, so it won't be considered as installed. As discussed on the Install a Service Worker page, having a long list of files can increase the chances of a caching failure, leading to the service worker not getting installed.
I have a product that runs a service
And if an msi upgrade starts
Which first turns off the service
So it can be replaced
Then if the user manually cancels the upgrade from the MSI
Or it rolls back on its own due to a failure
Then is it possible to turn the service back on from the MSI?
If the upgrade's RemoveExistingProducts action is inside the transaction between InstallInitialize and InstallFinalize then it should all just work. For example, if you have the REP action immediately after InstallInitialize, then that old product gets removed and then the new product installs. If the install of the new product fails or is canceled then that REP also rolls back and reinstalls the old product. In the case of services, that means it will start the old service if that's what the install of the older product does. So if you're starting/stopping services with the standard MSI actions there shouldn't be a problem.
There are all kinds of assumptions here because, for example, your old install and new upgrade might be full of custom actions that don't have rollback equivalents, or install CAs that don't work for some reason when the older product is installed from a rollback, or services that don't shut down properly etc. A specific problem you may see would need a log to investigate.
If the user cancels during the uninstall of the old version, it's the same thing. There's still a transaction that rolls back and re-installs that old product and fails the upgrade. That will restart the service if that's what the install does. There's all kinds of ways in which this could fail too, such as CAs that don't do rollback, or an install that assumes the UI is always run. So it all just works if you let it.
I'm working with Google App Engine in Eclipse w/ JSP pages in Windows 7.
I already have an app deployed and working, but I am unable to make changes to it for some reason.
If I make changes and debug locally, my localhost page is showing the changes that I implement.
While I am not getting any errors in the deployment, the same changes that work on my local debug are no longer showing up, so I can't update my app.
I thought updating the version number might help, but I had no luck with this.
Any ideas? Thanks.
Are you deploying the same version (as specified in appengine-web.xml) as the default version that is running on your app? If not, you'll have to access your new deployment at http://newversion.appname.appspot.com, or change your default version in app engine to your newly deployed version.
I have had the same problems too, especially when the changes concerned the static pages. Some little things to check:
If you have set an expiration date in your app.yaml, your browser cache could be holding the file.
If it’s specific to the online contents, it could be an intermediary cache (such as a squid server) serving the outdated contents, in which case you’d have to flush the cache to get the new version.
You could start by checking the log on the GAE console to see if the request is received by the server, that would help you debug.
Another trick, if you’re being served an outdated version of http://yourapp.appspot.com/index, try and pass a dummy argument to force the browser to update the version, for instance : http://yourapp.appspot.com/index?p=1