-
Notifications
You must be signed in to change notification settings - Fork 745
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Increased data provider timeout during install #2645
Increased data provider timeout during install #2645
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (Would prefer to delay this to next release)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed this when setting up the unit tests to run in DevOps. The main issue isn't it's timing out. The actual issue is the size and structure of the data file. It's 6750 lines of SQL that's expected to run at once in a single command (30s). If we split this up and add a few GO keywords. Dnn will split the file by GO's and run it in smaller sections which should improve performance quite a bit.
I'd much rather us fix the issue instead of just allowing the process to run up to 5 minutes.
This is also why we cannot install dnn on a small AppService instance in Azure. |
I implemented your suggestions @ohine. Can you check? |
I had to copy/paste the variable declarations in each batch for 2 reasons:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO there is no benefit combining indexes and system records in a single script.
we would gain flexibility, if we introduce a DotNetNuke.index.sqldataprovider file to prevent the timeout.
GO | ||
|
||
-- minimum date to set for all creted on last modified on columns |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am asking myself, what this comment means…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer to set these value only once on top of the script - there is a high risk of overlooking one of the occurrences. Would it be possible to restructure the script to have these values first before the first GO? Otherwise we should improve our system of DNN placeholders for SQL and provide it as additional variables for substitution e.g. {DefaultCreatedBy} etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well that's what I explained in my previous comment. These vars were originally defined at the beginning of the script, but that worked because there were no GO statements. I tried temp tables also, but didn't work either because temp tables don't survive the connection.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am asking myself, what this comment means…
Agreed. Removed
@dnnsoftware/approvers Can we assign this to the 9.3.2 milestone ? I also had a few customers with this issue, it does not happen on all servers though, but would be nice to include that in 9.3.2 if possible. |
This looks great, thanks for making the changes @daguiler |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me
Summary
The default 30 second timeout of the SQL data provider is often not enough during install and generates timeout errors.
This is now happening to me when using the /Install/Install.aspx page to refresh test environments. I can't say this has happened to me using the wizard though.
Screenshots
Here's what I see in the DotNetNuke.Data.log.resources file:
I tried to find a way to change the default command timeout in the connection string, but it's not possible. So this solution uses an existing overload of
ExecuteScript
which accepts a timeout.Setting a 5 minute timeout fixes the issue.