Developer forum

Hi Jeppe,

I was often in Igor's situation. And in a lot of cases, as a developer, I cannot access the IIS instance to recycle the ApplicationPool. And this also happens for some of the DW cloud-hosted solutions. In the past we solved it by fake editing the web.config file, forcing the application to reload. But that's not an elegant solution.
And the need for an application restart/reload can have various reasons, not just the refresh of the database values.

That's why I support Igor's request to have some option available in the back-end for handling application recycle.

Thank you,

Adrian 

Hi Adrian,

This is a symptom of something else. That the use of this feature is as wide-spread as it seems to be indicates to me that there's something else very wrong, but it's not clear to me what that is. I would have assumed it was clearing of caches -- which we want to support in a better way -- after manual changes to the database -- which, on the other hand, is not recommended -- but you specify that you need to restart the application for "various reasons". This sounds really bad to me. It seems that restarting the app was used as something of a band-aid. I'd prefer to fix the underlying reasons why is necessary to do rather than just re-introduce the nuclear option, but we need to know about those other situations so we can see how we can implement something to mitigate those issues.

From a practical and technical point of view, it cannot be implemented so it works consistently without having direct access to the hosting environment.

For hosting in IIS, we might be able to get away with it, but since the feature requires some external assemblies to interact with IIS, we would not want to distribute them with the app package -- I'm not even sure those assemblies have been updated to run on .NET Core/.NET 7. It could be distributed as a separate package in the AppStore, but you would have to make sure to uninstall that package if you ever move hosting away from IIS.

For containerized hosting, we would need access to the orchestration platform in order to restart the container/pod. That is most likely never going to happen -- especially if the hosting environment is managed in an external or self-hosted cloud like Azure, AWS or K3s.

In the case that the app is running directly from a command line, it is probably running locally and restarting it would be simple to do outside the app itself.

For all the reasons listed above, I do not expect that we're bringing the feature back for DW10.

- Jeppe

It is not realistic that we can work without doing direct SQL queries to server during the integration setup. A common scenario for recycle the app pool would be:

A developer has setup an import. They see after running the import in the interface that the import went wrong. The quickest way to start over would be to delete the data and start over. Deleting the data from the interface would take too much time. Deleting the data from the intgration would take too much time. So a direct SQL query is the way to go. When we run that, I have notifced that the interface does not respond until a cache has been cleared. Instead of learning which cache to clear, clicking the recycle button was always the easiest and fastest option to get the interface to syncronize with what is in the database.

I am not arguing we need the recycle feature back, I just need an easy and reliable way to force DW to sync with the database. A kill all cache button would be perfect for debugging. When we are live - not so much maybe. If we need to learn which cache is responsible for what, we need some sort of documentation or information about how it works so that we can learn. 

> I just need an easy and reliable way to force DW to sync with the database

This is the way I'd much rather go in as well.

- Jeppe

Hi guys,

I agree with Igor on all accounts.

@Jeppe I will be blunt about the need to recycle. Very often (at least in DW9) we HAD to recycle because of the application behavior. Sometimes it just crashes for whatever reason. And recycling would very often solve it. Think about the reloading of the GlobalSettings file, for example.

I can understand that DW10 is a different animal altogether, and I agree that maybe we don't need an actual IIS or Container recycle in the sense of the DW9 but rather an application reload.

Maybe this makes more sense.

Thank you,

Adrian

> I can understand that DW10 is a different animal altogether, and I agree that maybe we don't need an actual IIS or Container recycle in the sense of the DW9 but rather an application reload.

This is exactly my point. I'm not arguing about the existance of the button in DW9. That's a moot point as it already exists. I'm advocating that we rethink the concept for DW10. Identify the root causes and implement solutions for those instead of treating the symptoms.

- Jeppe

Hi Jeppe,

I agree. How do we proceed? We report every case where we would need some sort of refresh/recycle/update?

Will you guys think about the possible scenarios?

Thank you,
Adrian

We will probably start by trying to find the problematic places, but if you know of some, other than the ones mentioned in this thread already, please add them.

- Jeppe

We aggregate stock from a number of bins and hten update the EcomStockUnit and Stock on the product and StockUnit tables respectively. We do this via SQL as the LS integration does not consolidate stock, but rather gets it from a single shop/location.

However, once we have update the stock, we have to stop and start teh Azure Web App in order to refresh the product stock display. - it takes a good few minutes to restart this beast.

Even if we use the clear caches availabe it doesn't seem to update the stock - only a restart.

DW 9.15.8

Hi All,

A scenario's that I have been seeing is during deployment of new versions of Swift: I have experienced that deploying via FTP to the DW cloud results in files being locked, to solve this I either use app_offline.htm or fiddle with applicaiton pool resets. Here it would probably be even better to be able to shut down the app, then deploy, and then start. What a better DW10 solution could be I'm not sure.

Cheers,

Justin