[ https://jira.jboss.org/jira/browse/JBIDE-4740?page=com.atlassian.jira.plu... ] Denis Golovin updated JBIDE-4740: --------------------------------- Attachment: jconsole-memory.png -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-4740?page=com.atlassian.jira.plu... ] Vitali Yemialyanchyk commented on JBIDE-4740: --------------------------------------------- i find some problems - it should be fixed with my Monday updates. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-4740?page=com.atlassian.jira.plu... ] Max Rydahl Andersen commented on JBIDE-4740: -------------------------------------------- if the sessionfactory or console configuraiton doesn't get closed properly then it will leak. Thus in unit tests you have to close SF and make sure nothing refers to the console configuration afterwards. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-4740?page=com.atlassian.jira.plu... ] Vitali Yemialyanchyk commented on JBIDE-4740: --------------------------------------------- reproducible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-4740?page=com.atlassian.jira.plu... ] Vitali Yemialyanchyk commented on JBIDE-4740: --------------------------------------------- currently, I think this is internal eclipse "problem". My point is MappingTestsCore - is the most memory usage test. Internally MappingTestsCore is a basis to run: HbmExportExceptionTest, OpenSourceFileTest, OpenMappingFileTest, OpenMappingDiagramTest. I run these test separatly, I modify TestSet (comment other tests), so I get OpenSourceFileTest - first by memory usage, then OpenMappingFileTest and then OpenMappingDiagramTest. Why I think this is internal eclipse problem? All these tests open eclipse editors for different classes, currently we have 116 test executions here, 881 times different editors was opened and closed. I know what eclipse save open close history, so just close the editor is not enough to free all eclipse references. I do not know how possible to clean up eclipse. Anyone has propositions? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-4740?page=com.atlassian.jira.plu... ] Denis Golovin commented on JBIDE-4740: -------------------------------------- It seems to be a problem only for hiberante console editors or, as Max suggested, session factory. Tere is no such problems for example in VPE tests. Vpe tests are opening and closing tons of editors and there is no OutOfMemory exceptions. Looks like we need test suite that would test our stuff for memory leaks. That shouldn't be included in nightly tests because it could be pretty heavy and long. It should just open/close for example editors on different generated/stationary resources many times or for some period of time and there should be no OutOfMemory exceptions. Another approach have test at random create all types of projects, then open editors, close editors, delete projects and so on, to emulate real development process. I bet we'll have memory leak problems for such tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-4740?page=com.atlassian.jira.plu... ] Vitali Yemialyanchyk updated JBIDE-4740: ---------------------------------------- Fix Version/s: 3.1.0.M4 (was: 3.1.0.M3) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-4740?page=com.atlassian.jira.plu... ] Denis Golovin commented on JBIDE-4740: -------------------------------------- That's not a memory leak, but behavior of Display.asyncExec(Runnable). During JUnit Tests execution it just have no time to execute scheduled asyncExec runnables and the stack in a messages field and keep links on actually closed XML editors. That happens because editors uses anonymous classes for runnable and thus it contains reference to enclosing class. Right solution for that is makin editor aware of all its scheduled runnables and clean reference on editor in scheduled runnables if during editor closure. But that happens only during tests, which means tests should be adjusted. First of all editors should be closed after each test, not after all tests like it does now. Need to force clean up of async Runnables in display. First method run Display.readAndDispatch() several times. 80 times for my desktop reduced test time from 582 sec to 365 sec. and reduce consumed memory during the tests from 500M to 300M. Problem is that 80 is magic number that could be different for different computers. Another way invoke Display.runAsyncMessages(true) by reflection, in this case, tests time remains the same, but memory consumption changes the same way fro 500M to 300M. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-4740?page=com.atlassian.jira.plu... ] Dmitry Geraskov commented on JBIDE-4740: ---------------------------------------- Denis, who calls that Display.asyncExec(Runnable)? This runnable will be processed only when display quee will be empty as you have already mentioned. But Display.timerExec(int milliseconds, Runnable runnable) devoid of the drawback. It is not wait while quee will be empty. Could we use the method instead of asyncEcec? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-4740?page=com.atlassian.jira.plu... ] Vitali Yemialyanchyk resolved JBIDE-4740. ----------------------------------------- Resolution: Done Assignee: Denis Golovin (was: Vitali Yemialyanchyk) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-4740?page=com.atlassian.jira.plu... ] Denis Golovin commented on JBIDE-4740: -------------------------------------- I verified your fix, your fix is better. It didn't work for me when I tried the same approach with empty while with readAndDispatch call in condition, but now it works for me for some reason. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira