Improve DNN installer experience

[Timo-Breumelhof]

Description of problem

I have been installing extensions for a client on Azure with limited resources.
Although the obvious solution for this is to add more resources, the lack of feedback by the install process is a problem IMO.
DNN does not give any feedback if the install process fails due to a timeout (?)
I have also seen this on servers with enough resources but that were busy at the time, in general with packages of 4MB+ in size. I guess there's a timeout at the background, but there is no feedback you get as a user.

When you reload the page after some minutes (as nothing happens), it's uncertain if the extension installed or not and in some cases we even noticed that it seemed to be installed, but the dll in the bin was not the correct version.

Description of solution

IMO DNN should at least show a message if there is a timeout or maybe limit the install process to x minutes and show a fail message.
Ideal (although I realize this is not easy) would be if a user would get direct feedback of the install process steps.
That way it would also be easier to see what's going on.
FYI, Polydeploy has the exact same issue, it just stops without any notice.

Description of alternatives considered

none

Screenshots

[WillStrohl]

Thank you for reporting this. It's beginning to be something I'm also seeing more and more - and not just in the mutual environment we might be talking about here. It's also had a bunch of forum posts over the years.

[mitchelsellers]

This is a very interesting situation, and one that is a bit more specific and harder to catch from an Azure perspective.

Azure App Services have a hard-set limit of 230 seconds for a request, without any way to change that behavior. (https://learn.microsoft.com/en-us/answers/questions/839464/how-to-increase-api-timeout-on-azure-which-in-depl.html)

However, the way the transaction drops off is a bit hard to test/validate/report on from a DNN perspective

[WillStrohl]

I think an update that would go a long way for any DNN user would be a more detailed explanation of where/what happened, as Timo suggests.

Right now, there's a bullet list and even a veteran DNN administrator has a lot of troubleshooting ahead of them to figure out why in some cases.

The timeout issue, specifically, could or might be an iterative step after whatever happens with this Issue now, because it could be a different "value" or limit in various environments, and difficult to approach as Mitch sugggested.

[mitchelsellers]

I've tried to catch this myself a few times, the issue is that the connection is just "dropped," it doesn't actually end the request, and often times the server is still processing, meaning that the install COULD complete, or may not.

Its a very interesting failure pattern for sure, and a reason to ensure that modules that are notorious for heavy loads need to run ONLY on scaled environments.

[Timo-Breumelhof]

FYI, I also see this behavior on VPS not on azure where this 230sec limit should not exist.
Not sure why..

I'm just wondering if not making the user feedback dependent of the request could make this better.
So just triggering the install and use some kind of "ajax" like process to get feedback of the install status.
I think it might also be good if the extension installer process could write a log file so you can at least check where it ended and that could also be the basis for the feedback?

(FYI, I didn't check the code yet)

[WillStrohl]

Yes. More information is all we need for right now. Once we're able to at least log more details, then we can create a new issue later based on what we find, and further improve the module installer experience.

[Timo-Breumelhof]

BTW, i just tried this (hacky) workaround.
The open content install package is 11 MB and contains a lot of small files.
These are all in Resources.zip inside the package.
My guess is that unpacking these files takes longer than the 230 seconds limit on Azure.

So I created 7 separate installers all with only a part of the Resources.zip content and those do get installed without a timeout.
(although not in one go using PolyDeploy)

I first tested with 4 packages that failed then tried 5 etc.

I noticed that's it's not the size of the package, it's the number of files in the package I think..

[WillStrohl]

BTW, i just tried this (hacky) workaround. The open content install package is 11 MB and contains a lot of small files. These are all in Resources.zip inside the package. My guess is that unpacking these files takes longer than the 230 seconds limit on Azure.

So I created 7 separate installers all with only a part of the Resources.zip content and those do get installed without a timeout. (although not in one go using PolyDeploy)

I first tested with 4 packages that failed then tried 5 etc.

I noticed that's it's not the size of the package, it's the number of files in the package I think..

Oh, that's not ideal. If the files aren't installed during install/upgrade, they end up being orphaned files later when you uninstall a module. :(

[davidjrh]

Well, is not the Azure App Service limitation, is the Azure Load Balancer who drops off the connection after not sending any byte back for more than 230secs.

I've faced this in other projects by having a main thread that opens the "operation" in another sub-thread. If the sub-thread goes for more than 200sec, then the main thread starts to send back a byte that doen't break the response (i.e. if returning HTML or json, perhaps a char(20), if XML, then more tricky, because you must need to send the XML declaration at the very first part of the result).

With that approach, I've been able to run processes in Azure App Service for 15-20min. Not ideal, but is a workaround that could be implemented on the package installation.

Also, if you have more Azure pieces like an Azure Application Gateway, an API Management, another Azure Load balancer in the mix, remember to verify the connection timeout on all those parts, since the default timeout is 4 minutes as well (those can be easly increased on the Azure portal).

PS: currently, to avoid this situation, I ALWAYS scale up the hosting plan tier to a P2 or P3, and then scale in to the regular situation, the cost will be just some cents.

[mitchelsellers]

@davidjrh good point, thus the reason they stay open.

Scale up is the only real option right now for sure

[WillStrohl]

Well, that's the only option for an actual "fix." We can still potentially give at least a bit more information than a listing of things that might have happened. Right? :)

[Timo-Breumelhof]

Yes I agree.
BTW as stated before we have also seen the installer "hanging" on non Azure environments.

[Timo-Breumelhof]

I have exactly the same problem on a VPS (with enough resources) today.
I cannot install a 4 MB skin package, the installer just seems to stall.
So this is not an Azure only issues.

[Timo-Breumelhof]

BTW, the other client we have this issue with in Azure is on P3 and the install still "fails" a lot.
Well, actually, you have no idea if it succeeded or not as the process stopped..