Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 149179

Summary: [ssh] SftpFileService should handle multiple parallel requests
Product: [Tools] Target Management Reporter: Martin Oberhuber <mober.at+eclipse>
Component: RSEAssignee: Martin Oberhuber <mober.at+eclipse>
Status: RESOLVED FIXED QA Contact: Martin Oberhuber <mober.at+eclipse>
Severity: minor    
Priority: P3    
Version: unspecified   
Target Milestone: 1.0   
Hardware: All   
OS: All   
Whiteboard:

Description Martin Oberhuber CLA 2006-06-29 11:58:51 EDT 
SftpFileService uses a single ChannelSftp to handle all directory retrieval and stat calls (for actual downloads, a new channel is always opened).

But multiple stat calls and directory retrievals can happen in parallel, e.g. when multiple files and directories are selected and the user chooses File>Refresh (or presses F5).

In this case, the main thread and multiple Workers try to access the SftpFileService at once, which leads to exceptions, tracebacks and basically undefined behavior of the Jsch ChannelSftp. The service currently tries to handle this gracefully by disconnecting the service and reconnecting it, but this is not really a good solution since it may - in some cases - destabilize the system.

A better approach would be to "lock" the ChannelSftp with each request such that requests are serialized. Problem with this approach is that we need to ensure that the Channel cannot be locked forever, and requests can be canceled.

Another possible approach would be to allocate a new ChannelSftp for each request, but that seems to be overkill.

In fact it looks like for the user, the problem only happens when the "main" thread is involved in the query. Not sure under what circumstances that happens, but it does happen sometimes. Set severity "minor" since it seems to happen very rarely only.
Comment 1 Martin Oberhuber CLA 2006-06-29 12:00:02 EDT 
Another possible approach would be to searialize all requests in the RSE UI already (see the comment on API in bug 149133).
Comment 2 Martin Oberhuber CLA 2006-08-10 12:13:55 EDT 
Fixed by adding a Mutex class to serialize queries where necessary.
The Mutex class is re-usable in all RSE.

Testing from the UI is difficult, because scheduling rules already serialize most queries. I only found that queries from the "main" thread are not being handled by the Job scheduler: opening lots of directories in quick succession, then dbl clicking on a few files to edit therefore led to using the Mutex (since the editor-open call is always on the main thread).

So from the UI, I only got max. 1 thread waiting in the Mutex. I guess that more waiting threads can only be forced programmatically, so we should add such a test to Unit tests once ready.
Comment 3 Martin Oberhuber CLA 2008-08-13 13:05:56 EDT 
[target cleanup] 1.0 M4 was the original target milestone for this bug