Community
Participate
Working Groups
Update Manager puts up a modal dialog "Searching for updates:" ... and then proceeds to hang. I was searching for new updates, there appeared to be network problems so after a long time I pressed the cancel button but it was ignored. This is using M5. This is a pretty bad bug becauase the only way to recover is to KILL the eclipse process. I'll attach the stack trace.
Created attachment 3552 [details] stack trace I included this stack trace to show where the workbench was hung.
*** This bug has been marked as a duplicate of 18598 ***
I read through bug 18598, and while it is certainly strongly related to this bug, I don't see it as an exact duplicate. For this bug a modal dialog is being locked, which locks up the entire workbench. At least the modal dialog needs to be freed, even if that means leaking a connection. If the modal dialog isn't freed than the only alternative is to KILL the process which is a lot more drastic than leaking a connection.
Gary, all these bugs are about the same problem: we don't have sufficient control over the connection to be able to cancel if it is frozen. JDK 1.4.1 seems to be better in this regard because its timeout is shorter. When you press 'Cancel', the cancel bit is set on the progress monitor, but our code cannot get to it because the 'openConnection' methods blocks. We would need to spawn a thread that checks the 'cancel' state and somehow kills the connection. We are not happy with the lack of control in java.net.
I am resolving this as a duplicate again because although this particular problem is worse because it is in the dialog, the cause in all cases is the same. *** This bug has been marked as a duplicate of 18598 ***
It just looked like the other bug wasn't being fixed, and that part of the discussion was about how we didn't want to leak connections. While that might be the right answer for the general case, it is not the right answer for this case.
Regardless of the discussion, we will either allow frozen connections to be canceled (by dispatching a monitoring thread that can disconnect the connection) or not. If we do, it will fix all the defects marked as duplicates. We will not try to address each defect separately.
