QlikView April 2020 SR4 Issues

[Lora]

Hi

I recently upgraded our test and production QlikView environments to April 2020 SR4 (from April 2019 SR3?). Upgrades are normally very straight forward as you just run the scripts - the servers don't change.

Test went in with no errors (at least nothing we picked up on) but we ran into problems with production which we couldn't find else where - the Access Point would not open and was stuck on Loading Content. I did the usual fixes (checked the application pool, restarted IIS, cleared the cache) with no success.

Eventually it turned out that the error was in a mimic extension within a QlikView web config file (C:\Program Files\QlikView\Server\QlikViewClients\QlikViewAjax):

<staticContent>
<mimeMap mimeType="text/html" fileExtension=".qvpp"></mimeMap>
</staticContent>

We removed this tag and Access Point loaded. But here's the weird part, test contains this web config and the tag and works. 

The only difference, which we could see, is that test uses https://servername/qlikview  and production uses https://qlikview  (we basically remove the server in the URL and on the cert push the QlikView name through instead). It was decided that as they're set up differently this may have been the caused so I had one of our IIS chaps modify test so it now uses https://qlikview-test  in the hope we would get the same mime extension error. We did not. 

However we did then notice another error which we've been unable to resolve - just to put this out there, I have no idea if test had this error prior to the URL change. Basically, when the Access Point times out due to inactivity (e.g. you open a report and then do nothing for 10 mins) rather than QlikView just logging you back in and opening the report, which is what it used to do, you now get given an Internal Server Error 500. Once you get this, you need to come out of the report, back to the Access Point and reload the report that way. 

One work around would be to increase the timeout but we have it set because our users would enter a report and forget the tab was open. We have a finite amount of session CALs so we don't want to allow them to take a CAL in the morning and not give it back. Therefore, increasing the timeout, isn't so much a fix than a plaster over an issue. 

We've looked at our config files and we can't figure out why this is happening. We can only assume it was something which was wrong but used to work and now fails in the update that we took. Which means test always had this problem, we just didn't notice it as it only happens if you timeout due to inactivity. 

Any ideas or if you've had something similar would be appreciated. I know I've wedged both issues together but I'm not sure whether they're related or we've just been unlucky therefore I thought I should supply all the information regarding our upgrade. The error with the timeout is causing us a lot of grief as, even though it's a easy fix to come out the report and re-enter, or just to not leave an inactive QlikView report open, this is not always understood by the business and causing us to have issues raised to IT. 

Thanks

[Chip_Matejowsky]

Hi @Lora,

Suggest that you create a Qlik Support case for this issue - https://www.qlik.com/us/services/support

Best Regards

[Lora]

We have through our supplier but 2 weeks in and we've not received a solution. 

[Chip_Matejowsky]

Hi @Lora,

If possible can you provide a screen capture of the 500 internal server error?  Thanks.

Best Regards

[Lora]

Here you go. My colleagues and I all tried to recreate this error this afternoon to ensure it wasn't user or app related. We made changes to the Application Pool timeout (just in case) and all logged in, waited 30 mins and then clicked on different QVWs. The error then popped up.

If, on the Access Point, we clicked F5 and then clicked a QVW, the page opened without error. So it does appear to be a timeout on the Access Point. 

[Lora · Accepted solution]

For anyone with a similar issue. The problem turned out to be cookie time outs on the Access Point - not to be confused with the session time out on the QlikView reports themselves. 

We made 2 changes; one to the webserver config.xml file, modifying the SessionCookieTimeout field from 30 to 510 and then another on the IIS manager, configuring the site RoleManager cookie timeout to 8.5 hours (originally this was 0.5 hours). 

It could have been only 1 change was required but we did both of these and now the Access Point doesn't timeout if left for 10 mins.