Description of problem: IE9 on Windows 7 keeps using more and more RAM until it gets to the limit when RHEV-M starts displaying an error like this: number -2147024882: Not enough storage is available to complete this operation. Version-Release number of selected component (if applicable): RHEV-M 3.4 (reproduced on 3.4.0 and 3.4.2) Windows 7 x64 IE9 (reproduced on x32 and x64 versions) How reproducible: always Steps to Reproduce: 1. Open RHEV in IE9 on Windows7 x64 2. click on interface entries 3. monitor memory usage Actual results: Memory rises above 700 MB Error displayed in a pop-up: Error while executing action: A Request to the Server failed: (Error) description: Not enough storage is available to complete this operation. number: -2147024882: Not enough storage is available to complete this operation. Expected results: Memory usage is within reasonable amounts
@Alexander: your fix to bug 1114863 [1]: did it fix an issue that existed only in 3.5 (and not in 3.4)? or was the issue there in 3.4 already? [if the latter, this BZ can be marked as a duplicate of 1114863] [1] http://gerrit.ovirt.org/#/c/30768/
I don't think it is the same issue, bug 1114863 would really not allow you to do anything in the UI before running out of memory. Looking at the screenshot it seems that some interaction was possible before running out of memory. @Evgheni Can you reproduce the same issue on IE10 as well?
(In reply to Alexander Wels from comment #3) > I don't think it is the same issue, bug 1114863 would really not allow you > to do anything in the UI before running out of memory. Looking at the > screenshot it seems that some interaction was possible before running out of > memory. noticed the screen-shot just now, it looks like the same issue documented in bug 1077575 and bug 1079941. > > @Evgheni > Can you reproduce the same issue on IE10 as well? bug 1077575 is documenting the same issue on IE10; bug 1079941 is documenting this issue on IE11.
@Alexander: is there a chance that the "lazy-loading"-based improvements that you have worked on / working on right now will improve this situation?
I doubt it, at this point I am not sure what the problem is, I will need to investigate.
After doing some investigating I think we are being hit by the problem described by [1]. This is an issue with IE caching eval evaluations in case the same one happens again. As described in [2] this is by design and Microsoft won't fix it. So we have no option but not to use GWT-RPC which internally uses the eval method. We are in the process of removing GWT-RPC in favor of the REST api, which will partially be completed from 3.6. This should alleviate the memory increase somewhat until we can fully remove the GWT-RPC code. [1] http://code.google.com/p/google-web-toolkit/issues/detail?id=5736 [2] http://support.microsoft.com/kb/2572253
(In reply to Alexander Wels from comment #7) > After doing some investigating I think we are being hit by the problem > described by [1]. This is an issue with IE caching eval evaluations in case > the same one happens again. As described in [2] this is by design and > Microsoft won't fix it. So we have no option but not to use GWT-RPC which > internally uses the eval method. We are in the process of removing GWT-RPC > in favor of the REST api, which will partially be completed from 3.6. This > should alleviate the memory increase somewhat until we can fully remove the > GWT-RPC code. > > [1] http://code.google.com/p/google-web-toolkit/issues/detail?id=5736 > [2] http://support.microsoft.com/kb/2572253 Thanks, Alexander - we should re-test this in 3.6 when sufficient amount of GUI <-> backend communication has been migrated to the REST API (bug 1064533).
Can you ask the customer to try to reproduce this on 3.5.1? It should be fixed.
Hi Have tried with IE9 on v3.5.1. No longer getting out of memory errors. No getting "Error while executing action: A Request to the Server failed: Unable to evaluate payload" Thanks