Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
Anonymous
Not applicable

QV12 network error please try again

Hello,

my company upgraded from QV10 to QV12(fresh install of 12 and then migration of documents, users...) two months ago and we have been getting this strange error occasionally since then.

Some basic details:

Everything works fine (reloads, access point...) and then all of a sudden users start reporting they cant access the access point.

I try to remote desktop to the server machine and there i see this message: Message from webpage Network error please try again

I click OK and then restart the QlikView Webserver service and then access point works again. Strange thing is that until i click OK all reloads are failing. It is particularly annoying when this error happens after working hours. Then all reloads in the evening and during the night have to be done in the morning which is a strain on the system.

Strange thing is that there are no clear cause for this to happen. Sometimes it happens during reload of some document, sometimes nothing is happening on the server at all. At one time i thought this was a windows issue, but this is just another virtual machine among 10 others and all of them have no network problems.

Some technical details:

We have x64 win 2012 R2 server virtual machine on Intel Xeon 2,4ghz , 8gb ram asigned

Only thing installed on it is QlikView v12.00 SR5 (QlikViewServer_x64 12.00.20400)

All prerequisites were met (.net) and installation went smoothly.

Our network consists of 2 parts. 1 network domain in Belgium and 1 network domain in Serbia and a tunnel between these networks.

If anyone has any idea why this happens, even from which side the problem could have come (win, qv server, corrupted document...)

any help would be much appreciated.

2 Solutions

Accepted Solutions
Anonymous
Not applicable
Author

Hi Maxim,

I forgot to update the post. Since i posted i was investigating and figured out a couple of things:

-We use RDP to access the virtual machine QV server is installed on and there we view management console using IE

-This popup message seems to be just the symptom. When the break happens management console is open and it is on status tab with automatic refresh of task list checked. So i figure that this is just IE popup for a refresh that failed due to network error. So the message is only displayed when the management console is open. Also reloads dont resume until we click OK but we started closing management console whenever we dont use it so reloads resume without OK but...

-When this break happens our RDP access to this virtual machine is severed. No one can RDP anymore until we open console in vSphere client and log on there. After that RDP is enabled again and only then reloads resume. (If this break happens after working hours no reloads until someone logs on using console). Webserver service still has to be restarted for access point to work (although it is in status running).

-When one of these breaks happens more are soon to folow. We restart the virtual machine server and then for some time breaks dont happen. And then it happens again and keeps happening and we restart again...and so on.

-We are in the middle of an experiment. We are first trying to exclude reloads as a possible cause. So we disabled all reloads for a period of 2 days. No breaks happened. Now we are trying to pinpoint reload source that could be causing the problem. We reload documents by QV reload engine and by windows sheduled tasks. So at this stage all reloads are swiched to scheduled tasks for the remainder of the week. Next week we will swich all to QV reload engine and compare the results.

Best regards,

Ivan

View solution in original post

Anonymous
Not applicable
Author

Hello,

forgot to update again. Well we have found, if not a solution than a workaround and our system is stable for now.

First: there was no difference reloading through reload engine or through scheduled task. Breaks still happened.

The closest thing we could find to a cause was the lack of system resources. We have tried to replicate the break and have noticed that there seems to be a memory leak somewhere. So we would RDP to the QV server, open task manager and look at the memory and CPU usage while we reload and edit documents(users from the whole company could still access documents from web server service running on that server but this testing was usually after working hours so few of them were active. So their contribution to resource spending was minimal). And we noticed that during the reloads CPU and memory usage spiked and memory usage increased by about 30-40 percent. And every time reload finished there was a little more memory used (cached) by QlikView application. So little by little memory used by QV increased and when it got to about 70 percent and reload got it to 99 percent - break happened! Similar thing happened with CPU usage. During reload CPU spiked to 99 percent briefly. If we did 2 reloads at the same time CPU would spike (memory also but CPU first so we identify it as a cause) - break happened! If reload was in progress and we had developer opened and were changing tabs or sorting data in document (using CPU) - break happened! So this is what we think is the cause...and in practice it showed plausible. So on Monday we restart the server and memory usage starts at 20 percent. Then on next Monday it gets to 70 percent and we are in danger zone. Usually Monday night or Tuesday morning break happens.

Our solution(workaround): Of course adding more resources helps, but management decided against that(although we tested it and it helps). Next thing we did is changed a default setting in management console: System tab->QlikView Servers->Performance tab Working Set options set to 50 low and 70 high(as i understand this limits memory caching of QV app). I wanted to decrease it further but this seems sufficient for now. Lastly (since the above helped but didn't remove the breaks completely) we scheduled a server reset every Sunday night so that every Monday memory usage starts at 20 percent. Also we never reload 2 documents at the same time.

So now we have a working server although it is reseted every week. Without reset it now lasts about 3 weeks before break happens.

Now we are working on optimizing our QV documents making them smaller and doing as little calculating as possible (letting the oracle DB do the calculations, procedures instead of mappings...) because i think this too is the cause of high CPU and memory usage during reloads and when that is done we will probably suspend the server resets and try again. I also think memory leak is real and it is caused by V12 QV (in V10 we had no problems) and maybe some patch in the future will address it.

Hope this helps.

Best Regards,

Ivan

View solution in original post

6 Replies
maksim_senin
Partner - Creator III
Partner - Creator III

Hi Ivan,

Does it only happen in the QV Management Console?

Best regards,

Maxim

Anonymous
Not applicable
Author

Hi Maxim,

I forgot to update the post. Since i posted i was investigating and figured out a couple of things:

-We use RDP to access the virtual machine QV server is installed on and there we view management console using IE

-This popup message seems to be just the symptom. When the break happens management console is open and it is on status tab with automatic refresh of task list checked. So i figure that this is just IE popup for a refresh that failed due to network error. So the message is only displayed when the management console is open. Also reloads dont resume until we click OK but we started closing management console whenever we dont use it so reloads resume without OK but...

-When this break happens our RDP access to this virtual machine is severed. No one can RDP anymore until we open console in vSphere client and log on there. After that RDP is enabled again and only then reloads resume. (If this break happens after working hours no reloads until someone logs on using console). Webserver service still has to be restarted for access point to work (although it is in status running).

-When one of these breaks happens more are soon to folow. We restart the virtual machine server and then for some time breaks dont happen. And then it happens again and keeps happening and we restart again...and so on.

-We are in the middle of an experiment. We are first trying to exclude reloads as a possible cause. So we disabled all reloads for a period of 2 days. No breaks happened. Now we are trying to pinpoint reload source that could be causing the problem. We reload documents by QV reload engine and by windows sheduled tasks. So at this stage all reloads are swiched to scheduled tasks for the remainder of the week. Next week we will swich all to QV reload engine and compare the results.

Best regards,

Ivan

Not applicable
Author

Hi ,

any update about the error. I have the same baut with QV 12.1

regards

Anonymous
Not applicable
Author

Hello,

forgot to update again. Well we have found, if not a solution than a workaround and our system is stable for now.

First: there was no difference reloading through reload engine or through scheduled task. Breaks still happened.

The closest thing we could find to a cause was the lack of system resources. We have tried to replicate the break and have noticed that there seems to be a memory leak somewhere. So we would RDP to the QV server, open task manager and look at the memory and CPU usage while we reload and edit documents(users from the whole company could still access documents from web server service running on that server but this testing was usually after working hours so few of them were active. So their contribution to resource spending was minimal). And we noticed that during the reloads CPU and memory usage spiked and memory usage increased by about 30-40 percent. And every time reload finished there was a little more memory used (cached) by QlikView application. So little by little memory used by QV increased and when it got to about 70 percent and reload got it to 99 percent - break happened! Similar thing happened with CPU usage. During reload CPU spiked to 99 percent briefly. If we did 2 reloads at the same time CPU would spike (memory also but CPU first so we identify it as a cause) - break happened! If reload was in progress and we had developer opened and were changing tabs or sorting data in document (using CPU) - break happened! So this is what we think is the cause...and in practice it showed plausible. So on Monday we restart the server and memory usage starts at 20 percent. Then on next Monday it gets to 70 percent and we are in danger zone. Usually Monday night or Tuesday morning break happens.

Our solution(workaround): Of course adding more resources helps, but management decided against that(although we tested it and it helps). Next thing we did is changed a default setting in management console: System tab->QlikView Servers->Performance tab Working Set options set to 50 low and 70 high(as i understand this limits memory caching of QV app). I wanted to decrease it further but this seems sufficient for now. Lastly (since the above helped but didn't remove the breaks completely) we scheduled a server reset every Sunday night so that every Monday memory usage starts at 20 percent. Also we never reload 2 documents at the same time.

So now we have a working server although it is reseted every week. Without reset it now lasts about 3 weeks before break happens.

Now we are working on optimizing our QV documents making them smaller and doing as little calculating as possible (letting the oracle DB do the calculations, procedures instead of mappings...) because i think this too is the cause of high CPU and memory usage during reloads and when that is done we will probably suspend the server resets and try again. I also think memory leak is real and it is caused by V12 QV (in V10 we had no problems) and maybe some patch in the future will address it.

Hope this helps.

Best Regards,

Ivan

hariprasadqv
Creator III
Creator III

Hi Ivan,

Did you found any solution(except workaround) for this?

Thanks,

Hari

Jacoline
Contributor
Contributor

Hi All,

It seems as if the interference is caused by the Task Scheduler, as these only appeared once I did an automated Service restart at night before the reloads should start.  

I think it would be resolved when you disable your tasks for one day in Task Scheduler.