Community
Participate
Working Groups
Created attachment 79612 [details] full stackrace of the hanging ftp upload I tried to upload a file to a remote ftp site and the transfer got stuck in the main thread, which totally blocks the UI. After 10 minutes of waiting, I disable my network connection on windows to get a timeout on the socket (because I hate to kill eclipse, especially when I have unsaved changes). I was using 2.0.1.v20070816 of the ftp subsystem
Michael please check your configuration again, and attach a config log (from Help > About > Configuration Details, Copy & Paste) Your Thread Dump seems to indicate an old version of FTP -- Looking at the main thread, FTPService:line 717 should be in upload(), but in the version included with TM 2.0.1 this is in internalFetch()
Created attachment 79640 [details] my config log
Hm... your config seems to be at 2.0.1 RC2 level: org.eclipse.rse.services.files.ftp (2.0.1.v20070914) "RSE FTP Service" org.apache.commons.net (1.4.1.v200709121930) "Apache Jakarta Commons Net" This would mean, that the known FTP deadlock issues should have been resolved already (bug 192610, bug 199243 and bug 203306 on FTP; bug 202758 on commons net). You just don't have the most recent changes for encoding support, which should not influence stability of FTP. I notice from the thread dump that upload is called on the main thread; this should not happen, and I filed bug 205297 to get this fixed. Other than that, I cannot find a deadlock or programming error in the thread dump. It seems that during upload(), the OutputStream is simply blocked on write, and I don't know why that could happen; it should at least time out after some time. Javier can you check if you find anything suspicious, or what the timeout for write through commons net should be?
I am not complaining about the fact that the write hangs (this can always happen on unreliable networks), nor is there a deadlock, but communication via sockets should *never* happen in the main thread, because it can block the UI. Hanging UI is very annoying, even if there would be a timeout after a few minutes.....
Yes I agree that the Service should never be called on the UI, and I filed bug 205297 for it. Problem is that in the Service we cannot even tell whether we are on the UI thread or not!! One possibility to alleviate the problem even if bug 205297 were not fixed might be this - though I'm not sure if monitor.isCanceled() would work properly when everything is locked up in the dispatch thread: * Always spawn off a separate thread for upload or download, thereby also fixing bug 180965 to allow multiple parallel uploads/downloads * In the thread that was called from the outside, just update progress monitor and check for monitor.isCanceled(); do all that outside the FTP command mutex * If canceled, kill the upload thread (thereby avoiding hanging thread due to network i/o which is not checking for cancel).
I think that now as bug 205297 is fixed for TM 2.0.2, FTP should no longer be called on the dispatch thread so we can reduce severity and change target milestone back to 3.0.
Being able to cancel a hung ftp connection would be great!
Bulk update of target milestone
Bulk update of target milestones to 3.2
Bulk moving 3.3 deferred items to 3.3.1
