We recently migrated (manually) our Publisher tasks from QV9 to QV11 SR2. In the process we found what runs in QV9 does not necessarily run in QV11. We to experienced the failure referenced in this post. We have roughly 200 tasks that run daily and when we started our testing process we found that a major portion of our tasks were failing with this error. The solution turned out to be a mix of things. We had a large leap between versions and the first thing we did was to make sure tasks were not competing for the same source data. This did make things better but still did not resolve all of the failures.
The next thing we tried was reconfiguring our Virus scanner to ignore QVD and QVW files. We found some errors that indicated the QVW could not be opened because another process was using it. We have not seen this error since we made the change. This was also recommended by QT support.
Next on the recommendation from QT support we disabled the Parallel reload setting in the Setting.INI file. This file is located in C:\Windows\System32\config\systemprofile\AppData\Roaming\QlikTech\QlikViewBatch\. We added a line EnableParallelReload=0 under the [Settings 7] tag at the bottom. There is no need to restart any services after adding this, as the QVB process reads the Settings.ini every time a QVB process is launched. If there is a open QVB you will not be able to save the change so make sure there are no QVB'S running. QV9 was single threaded when connected to a data source while V11 is multi threaded. The interesting bit of information on this setting change is that disabling it did not seem to affect performance at all. This setting change did improve our failure rate but still did not solve all of our issues.
The next recommendation was to increase the Client Heap setting on the server. As you know QT recommends that you have 1 less QV engine enabled than you have processors or a max of 9. We have 16 processors and we could only enable 9. As a last resort we increased or Client heap setting as recommended and we have had no failures in the last 10 days.
I would suggest you discuss these settings with QT support and at a minimum makes sure you have a test environment to test before moving them into production. The SR2 release notes indicated this issue was fixed but it can be a complex issues based on how you utilize the resources of your QV Server/Publisher.
I hope thisinformation helps.
Information on Heap Setting from QT support:
Increase Desktop Heap Memory. Done via a Windows Registry change. Documented for another scenario in our reference manual "QlikView Server/Publisher" section "Simultaneous Tasks".
Desktop Memory Heap Registry change:
Change the registry setting:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows
Change the GDI and User handle max count in the registry to SharedSection=1024,20480,2048
%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows
SharedSection=1024,20480,2048 Windows=On SubSystemType=Windows
ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3
ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off
MaxRequestThreads=16
Default is 1024,3072,512 in x86 or 1024,20480,768 in x64
NOTE! The machine must be restarted after the change
* Desktop Heap exhaust. See links below for more info. With the workaround we will be able to avoid this problem.
http://support.microsoft.com/kb/126962/en-us
http://support.microsoft.com/kb/184802/en-us
Why are we having to do this?
We are creating the QVB engines as COM objects. There is a limitation from Microsoft when dealing with COM objects. COM is a fairly old technology and when Microsoft once set the limitations the machines were not as big as they are today (but has not bothered to increase this value).
Referring to this knowledge base article from Microsoft:
http://support.microsoft.com/kb/870655
What changed that makes this required?
After talking an old timer here; number of QVB engines must be determined for each machine since we never know what else is running on the machine.
The way to do this is to create many QVW files with scripts that has a never ending loop (=when running the reload task, the qvb will never close). Start one task at the time and check logs to see when the engine fails to create. Manually shut down the QVD tasks in Task Manager. Redo the test a couple of time to verify that the fails at the same number of tasks. (You might need to increase the number of possible QVD engines). Now you know the limit for this machine. Doing the registry change will increase this number.
@ I was trying to refresh the same application,not realizing the file may have been corrupt (because I could still open the QVW). I replaced it with a copy of the file, and bingo it works well..
