Bugzilla – Full Text Bug Listing
| Summary: | FTP Passive mode dead-lock | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Michael Valenta <Michael.Valenta> |
| Component: | Team | Assignee: | Michael Valenta <Michael.Valenta> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 2.0 | ||
| Target Milestone: | 2.0 F3 | ||
| Hardware: | Other | ||
| OS: | other | ||
| Whiteboard: | |||
|
Description
Michael Valenta
I got this again by placing a breakpoint deep in the finish code of the deploy wizard. The TimeoutOutputStream#waitUntilDone() seems to be stuck in a wait. The above only happens if the connection is blocked! Got deadlock again when getting a file in the sync view! After a brief investigation, it appears that the problem is due to the fact that a workspace operation is run in one thread but file transfers happen in another. Since the FTPClient accepts an IFile as a parameter, the create/setContents happens in another thread and this seesm to cause the deadlock. The solution is to refactor the FTPClient to either create/setContents in the callers thread or to return an input stream. Since the IRemoteResource#getContents requires a stream anyway, the second solution is desirable. Deadlock on file transfers has been fixed. Still need to check on original problem (deadlock on debug and blocking of connection using Norton Intenet). It turns out that it's not really dealock. The FTP client eats the exception on the failed connection in one thread and gets blocked waiting for a response from the server in another thread. Thankfully, the server eventually responds that the connection was never made (after about a minute). It's probably best to refactor the FTP requests to wait until the auxilary connection is established before junping in to read the responses in the main thread. post 2.0, unless you disagree I already have a fix for this and I believe it should go in. Fixed and verified by James |