Community
Participate
Working Groups
I20080903 As shown in bug 244979, IProject.open(int) can take a long time because it is trying to refresh the entire source tree. We need a way to tell this operation to open the project without refreshing it. Refresh can be done later by the client if needed.
Note the "BACKGROUND_REFRESH" refresh flag can be used to push the refresh into a background job so it should not be blocking anyone. Since we don't track changes on closed projects, refreshing is needed to catch any changes that happened while the project was closed.
Actually, what would be really needed, is a REFRESH_ON_FIRST_USE flag. It would not refresh the project's tree on open, but the first use of members() would refresh (at depth 1) before returning the children.
(In reply to comment #2) > Actually, what would be really needed, is a REFRESH_ON_FIRST_USE flag. It would > not refresh the project's tree on open, but the first use of members() would > refresh (at depth 1) before returning the children. Looking at bug 244979, BACKGROUND_REFRESH would fix the issue. Why is it not enough? What would be the difference (from your point of view) between running the refreshing job and calling members() somewhere later?
Yes BACKGROUND_REFRESH would fix bug 244979, but it would introduce a new issue: if one asks for the members() of one of the node in the project's tree and the background job has not finished, then it will return an empty (or a not accurate) list of children.
See bug 248068, comment 14, why we can't refresh inside of members() method. I can see two solutions for the case from comment 4. 1) Join to ResourcesPlugin#FAMILY_MANUAL_REFRESH before calling members(). 2) Use IResource#isSynchronized to check whether the tree is in-sync and call members(), if true. Solution 2) is more expensive, so 1) seems to be preferred.
Thanks. 1) is not an option since it would have to wait for all the project to be refreshed which is exactly the issue with bug 244979. 2) can I call refresh(DEPTH_ONE) is isSynchronized(DEPTH_ONE) returns false but the background refresh is still running?
(In reply to comment #6) > 2) can I call refresh(DEPTH_ONE) is isSynchronized(DEPTH_ONE) returns false but > the background refresh is still running? > You would have to run refresh(DEPTH_ONE) in a separate thread (job). Then in some cases, isSynchronized will return false and refresh will be still in progress. If both run in the same thread, the thread will exit refresh(DEPTH_ONE) when the operation is done.
Just to be clear, if a client calls IResource#refreshLocal, the method does not return until the workspace is back in sync - there is nothing in the background here.
We have an IBM product in beta right now whose primary use case is remote development via EFS, using the RSE EFS provider. On startup, all the user's EFS projects are closed (which is a separate issue). This means that they must manually go an open all of their projects. This then invokes a deep refresh of the project. On a 3000 file project, this typically takes 5 minutes or more even on a LAN connection to the server. The users find this unacceptable. For us, it's not a matter of there simply being an API to allow opening with a background refresh, we actually want there to be an option in the IDE to specify that the default Open action for the project should not do a refresh. We could potentially replace the Open action with our own using capabilities, but given the project is not open, there is no way for us to query project natures, and hence we could only make an action that showed up for any kind of project, which is not really playing nicely with others.
Maybe I'm missing something, but it seems that the refresh is triggered by InitRemoteEditJob, not Open Project operation. I haven't looked at it closer though.
(In reply to comment #9) > We have an IBM product in beta right now whose primary use case is remote > development via EFS, using the RSE EFS provider. > > On startup, all the user's EFS projects are closed (which is a separate issue). > This means that they must manually go an open all of their projects. This then > invokes a deep refresh of the project. Chris, on I20100129-1300 with RSE EFS it seems to work as you expect. I have some projects located in RSE EFS, after Eclipse restart they are closed. When I open them, refresh is not triggered. I have to trigger a refresh manually, if I want to pick up changes made in RSE EFS while the project was closed. I made a fix in this area (during 3.5) and it might help. Anyway, Chris could you please check that 3.6 IBuild works fine for you?
(In reply to comment #11) > I made a fix in this area (during 3.5) and it might help. Anyway, Chris could > you please check that 3.6 IBuild works fine for you? It is a fix for Bug 266907 released in 3.5. I can confirm that this fix solves Chris' issue in 3.5 and 3.6. Eclipse 3.4, 3.4.1 and 3.4.2 behave as Chris described.
This seems related to bug 301563, although I do not quite understand what the original submitter's needs were (and why this is still open). There are basically 2 cases to consider: (a) project had been open in the same workspace before. A cycle of close-project, quit-eclipse, restart, open-project should not perform a refresh but re-use the (potentially outdated) refresh info. In my understanding, this had failed for Chris on EFS/RSE, but has been fixed by Szymon for Eclipse 3.5m7 and now it's working as expected (no unexpected refresh on project-open if the project was open before). (b) project had never been open in this workspace before, so it is essentially a project import. Today, Eclipse is only capable of doing a "deep" refresh since otherwise nothing at all is known about the project's resources. The refresh can happen in foreground or in background. Bug 301563 is going to add a feature which allows restoring persisted refresh information on project import, such that the project-open is fast and comparable to case (a). Jerome, what are you trying to accomplish? Would bug 301563 help, or are you looking for an option to IProject#open which restricts the refresh on project import to only a certain number of levels (with more levels to be discovered later, in an unintrusive way)? (In reply to comment #1) > Note the "BACKGROUND_REFRESH" refresh flag can be used to push the > refresh into a background job so it should not be blocking anyone. On very large, slow file systems, people do experience the refresh as impeding their work, even if it happens in background -- this is why we're investing in bug 301563.
(In reply to comment #13) We are in a case between a) and b). The project already exists and has already been refreshed at least once. The user creates a link folder to a very large source tree. In this case, we don't want the refresh to happen right away, but let the user decide when to refresh it. I'm not sure why I asked this feature to be available on IProject.open() though. I guess what we really need is to be able to create the linked folder without populating its tree.
(In reply to comment #14) Sounds like the "linked folder refresh" should be a separate bug, then. Although it may be related to this one... since, when you created your linked folder and then import the project into a different workspace, you might also want to have only the project refreshed but not the stuff under the linked folder, right? To me, this sounds like your linked folder should have a special property ("refresh me lazily"). Which is what bug 244979 is about. There are items on your file system which you'd want to have accessible from the resource system, but not always refreshed. You'll need to mark up those items.
(In reply to comment #14) > I guess what we really need is to be able to create the linked folder without > populating its tree. So this is actually a duplicate of bug 244979. (In reply to comment #13) As you noticed (a) is not an issue anymore. For (b), bug 301563 would help. We could also consider refreshing to some level (lazy refresh), but Bug 244979 is to discuss it. We could mark it a duplicate of bug 244979. On the other hand we could leave it as a reminder that lazy refresh should be available for project opening too.
I think the core design question to answer is, who may decide what should be refreshed lazily. a) Is the "lazy refresh" a property of some resources? b) Or may the client of a project open or create-link decide that he's not yet interested in all content? c) Or maybe both? In my understanding, Bug 244979 only deals with (a) whereas b and c are not yet represented as separate bugs.
(In reply to comment #17) So let's keep this one to track b), i.e. not refreshing content (part or all) on project open, link creation and other operations that trigger a refresh. I think that the dependency to Bug 244979 should be removed now. Actually we can refresh to some level using IResource#refreshLocal(int depth, IProgressMonitor monitor). However this cannot be parameterized for operations like project open.
I am no longer involved in Platform Core development.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
