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

Bug 368715

Summary: RSEFileStoreImpl.openInputStream can use out of date cached remote file
Product: [Tools] Target Management Reporter: Alan Staves <alan.staves>
Component: RSEAssignee: dsdp.tm.rse-inbox <tm.rse-inbox>
Status: NEW --- QA Contact: Martin Oberhuber <mober.at+eclipse>
Severity: normal    
Priority: P3 CC: dmcknigh, petar.petrov
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Attachments:
Description Flags
Image showing the state of the cached remote file about to be used by openInputStream none

Description Alan Staves CLA 2012-01-16 10:04:59 EST 
Build Identifier: I20110613-1736

This is very hard to reliably reproduce and so far I have only been been able to reproduce it in the context of our usage of RSE but I believe it is a generic bug. 

The issue is that when we call RSEFileStoreImpl.openInputStream() it operates on the remote file returned by a call to getRemoteFileObject() which itself calls getCachedRemoteFile(). The JavaDoc for this latter call says "...attributes of this handle are never considered except for exists() checking" but this is not true as they are used in openInputStream(). 

In my debugging I have seen the remote file returned to openInputStream be already marked as a spirit whose associated DataElement has been deleted and its attributes nulled out which results in the CoreException at the end of openInputStream() being thrown like:

org.eclipse.core.runtime.CoreException: The file store does not exist: rse://SU11V1VC/home1/hub/staff/alans/alansTest/.project
	at org.eclipse.rse.internal.efs.RSEFileStoreImpl.openInputStream(RSEFileStoreImpl.java:690)
	at org.eclipse.rse.internal.efs.RSEFileStore.openInputStream(RSEFileStore.java:323) 

Comparing the implementation of RSEFileStoreImpl.openInputStream() with RSEFileStoreImpl.openOutputStream() the openOutputStream method clears the cache by calling cacheRemoteFile(null); as the first thing it does, whereas openInputStream does not, allowing it to operate on an out of date cached file.


Reproducible: Sometimes

Steps to Reproduce:
I have, as yet, been unable to reproduce using a vanilla Eclipse installation.

In our product this requires the creation of a purely remote project using an RSE connection.
Making changes to the project which cause the project to be refreshed will occasionally cause the exception mentioned in the details above to occur and the project to become unusable until Eclipse has been restarted.
Comment 1 David McKnight CLA 2012-01-18 10:25:42 EST 
This may be a result of changes for bug 291738.  Due to the high frequency of fetches driven by the platform project support, remote EFS performance can suffer.  To mitigate this, a means of reducing the number of queries was introduced based on a wait threshold.  The threshold defaults to 1000ms but this can be fine-tuned via the "rse_efs_fetch_wait_threshold" system property.  

You can try this by appending a line to the eclipse.ini file like this:

-Drse_efs_fetch_wait_threshold=200
Comment 2 Alan Staves CLA 2012-01-18 11:03:58 EST 
Thanks David but changing that setting doesn't make any difference in my situation.

In the case I'm seeing, the cached file is already several seconds old and so would already fail the threshold test and so reset the cache - but unfortunately openInputStream() doesn't call fetchInfo() so that test is never made. 

I have managed to implement a temporary workaround in our code which is to call fetchInfo() prior to openInputStream and that does prevent the bug.

I believe the issue is that in openInputStream() the call to getRemoteFileObject() will always return the cached remote file (providing the file subsytem is still connected) - without any checking of how recent it is. The attibutes of the returned remote file are then checked with remoteFile.isDirectory() and remoteFile.isFile() - but by the time this is happening the DataElement attributes have already been set to null so it isn't recognised as being a file and it falls through and throws the exception at the bottom of the method.

There are calls in openInputStream to cacheRemoteFile(null) but only inside the if (remoteFile.isFile()) rather than as the first line of the method (as is the case for mkdir() and openOuputStream()).
Comment 3 David McKnight CLA 2012-01-18 11:20:26 EST 
Does this happen only when using the DSTORE_SPIRIT_ON=true option or is that not a factor in this?  If you're not sure what that is, you can check the startup scripts (auth.pl and/or server.pl) to see whether it's set.
Comment 4 Alan Staves CLA 2012-01-18 12:27:33 EST 
Spirit mode was set to true and the cached remote file object returned was set to spirit (I'll attach an image I took of the variables view during one of my debug sessions).

I've just been trying to reproduce this problem with spirit mode set to false but I am currently unable to reproduce it at all (with spirit mode set to true or false). Unfortunately the problem is intermittent and the case I had which was failing 90% of the time is now working ok.
Comment 5 Alan Staves CLA 2012-01-18 12:28:46 EST 
Created attachment 209695 [details]
Image showing the state of the cached remote file about to be used by openInputStream
Comment 6 David McKnight CLA 2012-01-18 12:58:03 EST 
I suspect that this is an issue with spirit mode but, if you are ever able to reproduce the problem with spirit mode off, that theory could be ruled out.