Community
Participate
Working Groups
It's possible for views to hold onto old versions of IRemoteFile. By old, I mean these instances are not the same as the cached version in the RemoteFileSubSystem. One problem with this is that when a view containing an older version of an IRemoteFile gets refreshed, it's possible that, since it's not marked as stale, it invalid cached contents can be returned.
Created attachment 177150 [details] patch to use the latest remote file
Kevin, could you review this patch? Thanks.
Review +.
Created attachment 177235 [details] updated patch to also synchronize on the file It's also possible to two or more concurrent queries to be made on the same remote file. That can cause problems with the caching, so I've added a synchronize block on the remote file that is being queried to prevent a possible duplicate query.
Thanks for the review, Kevin. Could you also review the updated patch?
Review + for updated patch.
Thanks for the review. I've committed the change to cvs.
Reopening this to handle the case where a refresh is issued on a remote file that is not the cached file but the cached file is not stale. The original file is marked stale as a result of the refresh so the cached file should also be marked stale.
Created attachment 177336 [details] updated patch to make sure cached file is stale when original is stale
Sorry to bug you again, Kevin. Could you please take a look at this last modification? Thanks!
Looks good. Review +.
I've committed the update.
I'm concerned about the "synchronized" block since it calls out to unknown client code (ss.resolveFilterString, file.getContents, filterChildren). Assuming that such client code does a Display.syncExec() which for some reason ends up running into that query block again, this would deadlock. In general, large synchronized blocks calling out to foreign code should be avoided. Even assuming that there are multiple queries on the same file, I cannot quite see why this would be a problem (other than asking the same information twice, which should be acceptable). Can you remove the large synchronized block?
(In reply to comment #13) > I'm concerned about the "synchronized" block since it calls out to unknown > client code (ss.resolveFilterString, file.getContents, filterChildren). > > Assuming that such client code does a Display.syncExec() which for some reason > ends up running into that query block again, this would deadlock. In general, > large synchronized blocks calling out to foreign code should be avoided. > > Even assuming that there are multiple queries on the same file, I cannot quite > see why this would be a problem (other than asking the same information twice, > which should be acceptable). > > Can you remove the large synchronized block? I was hoping to avoid duplicate queries by synchronizing so that only one query gets through while others wait and return the cached results. Since we're late in the release cycle, I'll take out the synchronized block to mitigate any potential risk.
Thanks, I released for 3.2.1rc4.
Verified that this has been released to 3.3m3 as well.
