Re: suspendProcessing() and dispose() memory leak
Thomas DeWeese wrote: I think I have a solution to this bug. Hi Lukasz, Lukasz Matuszczak wrote: Thank you very much, Thomas, your solution seems to work. Good Glad to hear it. One question on this, what events should be sent? when suspend and resume are called in close proximity (i.e. before the runnable thread actually suspends). Right now no thread events get sent (just like if you call resume when the thread is already running). I think when we call suspend or resume we should always get managerSuspended and managerResumed events respectively, even if they are called in close proximity I think it's a little misleading to send a managerSuspended event when the manager is still running don't you? Even in the past if you called 'resume' when it was already running no event would be fired. So the answer isn't quite as obvious as one might think. (unless the manager fails). Does it work this way in a current solution? No, currently if the runnable queue doesn't actually stop before you call resume it will not send either of the events. What I will probably try and do is have it send a resumed event (which could be considered a failed event for the suspend request). This is a little tricky to do right. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suspendProcessing() and dispose() memory leak
Thomas DeWeese wrote: I think when we call suspend or resume we should always get managerSuspended and managerResumed events respectively, even if they are called in close proximity I think it's a little misleading to send a managerSuspended event when the manager is still running don't you? Even in the past if you called 'resume' when it was already running no event would be fired. So the answer isn't quite as obvious as one might think. Either way, proper documentation should save the day. E.g., with the current behavior the API for suspend() and resume() should say that they are requests to suspend/resume the update manager, and that multiple requests can get consolidated, and that the listener events are reports of what actually happened, etc. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suspendProcessing() and dispose() memory leak
Hi Lukasz, Lukasz Matuszczak wrote: I am still fighting with dispose() problems, and I discovered something, which I consider a bug (it appears in 1.5.1 release and in a latest version from CVS head). The problem is when I call method suspendProcessing() followed by dispose() on JSVGCanvas object, the JSVGCanvas won't be collected by garbage collector. This is somehow connected with UpdateManager ant its RunnableQueue, I think. This is tied to the following bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=30189 I think I have a solution to this bug. This makes it clear why suspend/dispose isn't shutting down the UpdateManager Thread properly, but I am unsure why this would prevent GC (this is also troubling). My fix for the suspend/resume race condition does allow the Canvas to go to GC. One question on this, what events should be sent? when suspend and resume are called in close proximity (i.e. before the runnable thread actually suspends). Right now no thread events get sent (just like if you call resume when the thread is already running). You may ask why i call dispose() after suspendProcessing() (why not only dispose()). The answer is that I have my own queue of events in my application, and sometimes I get a request to deactivate the SVG screen (suspendProcessing), and soon after that to close it (close). I handle these events one after another (of course AWT in event dispatch thread). Sure, this is an expected usecase. Thanks for the good test case. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suspendProcessing() and dispose() memory leak
Sorry for HTML. Lukasz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
