Community
Participate
Working Groups
Following the discussions on bug #75541 and bug #89672 , the reason why the workspace isn't refreshed by default, is polling. This only applies for Linux users, anyways. The new 2.6.13 kernel has a new interface called inotify, which allows to watch files and directories. There were some arguments against famd, but I think using gamin / inotify should be considered. In case ecplise makes use of this, the default behaviour could be changed to automatical refresh the workspace. Cheers, Kevin
I am changing the title of this bug to only cover INotify support. Whether the feature is on by default is a different question, for which there are existing bug reports.
*** Bug 247241 has been marked as a duplicate of this bug. ***
By the way, there's a Java library for this http://jnotify.sourceforge.net (LGPL though).
I have recently written a plugin for just this feature. I actually use the new file watching in Java 7, so this plugin should also work for Windows/OSX users as well, but I haven't tested that. https://github.com/psxpaul/EclipseJava7Refresher Disclaimer- this is my first time writing an Eclipse plugin, as well as my first time using the Java 7 WatchService.
With large projects any file system changes are very expensive. In fact, Eclipse often becomes unresponsive when performing external git branch switches, hitting 100% CPU usage and requiring the IDE to be killed. (Note Egit refresh options are completely disabled.) If kernel inotify events were used I think the IDE would be much more responsive and fluid. Which component/module/bundle is responsible for the implementation behind General -> Workspace -> Refresh using native hooks or polling ? Perhaps I'd give a crack at implementing it.
(In reply to Raymond Auge from comment #5) > In fact, Eclipse often becomes unresponsive when performing external git > branch switches, hitting 100% CPU usage and requiring the IDE to be killed. > [...] > If kernel inotify events were used I think the IDE would be much more > responsive and fluid. If you see high and unexpected CPU usage requiring the IDE to be killed, please use [1] to file a bug. Long running operations should not happen in the UI thread, so if your Eclipse is unresponsive when a long running operation runs, then it is something different than lack of inotify support. [1] http://wiki.eclipse.org/How_to_report_a_deadlock
Any chance this will happen soon? I just tried enabling the refresh in Eclipse Luna, but there was a significant delay which seemed indicative of polling. I am using a modern Linux with inotify and I like to sometimes edit files outside Eclipse with vim. Please consider this a vote for the feature. Thanks to whoever is implementing it.
As of Eclipse 4.5, JDK 7+ is required on all supported platforms, which means java.nio.WatchService is universally available. Quoting WatchService documentation: "The implementation that observes events from the file system is intended to map directly on to the native file event notification facility where available, or to use a primitive mechanism, such as polling, when a native facility is not available." On Linux, WatchService is using INotify internally and works very well. I think it makes sense to switch to using java.nio.WatchService on all platforms that currently use polling.
(In reply to Rafal Krzewski from comment #8) > I think it makes sense to switch to using java.nio.WatchService on all > platforms that currently use polling. Would you be interested in providing a Gerrit review for this change?
(In reply to Rafal Krzewski from comment #8) > As of Eclipse 4.5, JDK 7+ is required on all supported platforms, which > means java.nio.WatchService is universally available. > > Quoting WatchService documentation: "The implementation that observes events > from the file system is intended to map directly on to the native file event > notification facility where available, or to use a primitive mechanism, such > as polling, when a native facility is not available." > > On Linux, WatchService is using INotify internally and works very well. > > I think it makes sense to switch to using java.nio.WatchService on all > platforms that currently use polling. We have some research on this topic [1]. The issue we've hint on Linux is that the number if watchers that can be registered is pretty limited with the default Linux settings (see the Troubleshooting section). This limit is very easy to reach for developers working with big projects (like PHP developers). [1] https://github.com/zendtech/studio-workspace-refresher
(In reply to Lars Vogel from comment #9) > Would you be interested in providing a Gerrit review for this change? Sure.
Changing the title to reflect that this is not only about inotify anymore. To sum up the current situation: - When auto-refresh is enable, it either uses contributed refresh monitors or fallback to a polling monitor. - The only refresh monitor contributed by the Eclipse platform is Windows specific. It uses native calls to Windows directory management functions [1] and wait functions [2] - Java 7+ provides an API to watch directory changes [3]. Implementation of this WatchService API is platform dependent. It uses inotify [4] on Linux and the same windows API as the Eclipse refresh monitor for Windows [5][6]. Apart from Solaris, Java WatchService API fallback to polling. In particular, on OS X, Java WatchService uses polling. As long as platform.resource now has Java 7 for BREE, having a WatchService implementation of a RefreshMonitor comparable to Paul's (comment #4) or Zend's (comment #10) makes sense. If the performance are better that the current Win32RefreshProvider, we could even nuke it and its native code. Otherwise, the WatchService could be limited to Linux only. Regarding OS X, Oracle does not seem to be willing to address the poor performance [7][8] they have with PollingWatchService [9]. Again, benchmarks should be done to compare the PollingMonitor and a WatchServiceRefreshMonitor using the PollingWatchService to determine whether OS X should go with the the new WatchService impl or stay with the current Eclipse polling. If we want to go further, a dedicated RefreshMonitor for OS X using native BSD kqueues [10] / FSEvents [11] can be done (see [12] for a WatchService like implementation for OS X using FSEvents). A last solution would be to rely on a cross-platform change monitor like fswatch [13]. A single native refresh provider implementation for all platforms would then be required and most of the platform specific quirks would be handled by the library. Unfortunately, the license of fswatch is GPL v3. I don't know any other open source one. So first thing is to be sure we don't break the performance on Windows. We need to compare the performance of the Win32RefreshMonitor and Java WatchService (on windows). What about using Zend's implementation (comment 10) to start? Of course, if the tests are in favor of the Win32RefreshMonitor, we could not tell whether it's Oracle's WindowsWatchService or the Zend's implementation of RefreshMonitor on top of WindowsWatchService which is slower. The results are reversed, then we know it's a big win. Any idea about benchmarks that should be gathered? memory consumption? time spend in run(IProgressMonitor) by activating DEBUG_AUTO_REFRESH? The test case would be a script that heavily modifies a file system tree (pseudo randomly with a given seed for reproducibility). This script will be run several times. Only the results of runs which had taken the same amount of time to modify the file system will be retained. Any comments? ideas? [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa363950(v=vs.85).aspx [2] https://msdn.microsoft.com/en-us/library/windows/desktop/ms687069(v=vs.85).aspx#multiple-objectwaitfunctions [3] https://docs.oracle.com/javase/8/docs/api/index.html?java/nio/file/WatchService.html [4] http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/solaris/native/sun/nio/fs/LinuxWatchService.c [5] http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/windows/classes/sun/nio/fs/WindowsWatchService.java [6] http://hg.openjdk.java.net/nio/nio/jdk/file/a11b4063024f/src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c#l1280 [7] http://stackoverflow.com/questions/9588737/is-java-7-watchservice-slow-for-anyone-else [8] Bug 480551 comment 14 [9] https://bugs.openjdk.java.net/browse/JDK-7133447 [10] https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/kqueue.2.html [11] https://developer.apple.com/library/mac/documentation/Darwin/Reference/FSEvents_Ref/index.html [12] https://github.com/gjoseph/BarbaryWatchService [13] https://github.com/emcrisostomo/fswatch
New Gerrit change created: https://git.eclipse.org/r/73007
I've submitted monitor implementation based on NIO/2 WatchService. It performs rather well (see below for limitations) and it mitigates the issue stated in comment #10. In the implementation described in comment #10, WatchKeys are never cancelled. It leads to inotify watches to never be released. You still need one watch per watched folder which can exceed max_user_watches but repeated deletion and creation of file tress (I'm looking at you "bin/" folder) does not leak any more watches. One thing that I'm not happy with this implementation is the poor performance of folders deletion within large workspaces. I have to browse all the registered paths to find the child paths of the folder being deleted to properly cancel the associated keys (see method keysToCancel in https://git.eclipse.org/r/#/c/73007/2/bundles/org.eclipse.core.resources/src/org/eclipse/core/internal/resources/refresh/nio2/Nio2RefreshMonitor.java). Any idea to improve this part is welcome. Another issue is the startup performance (again on large workspaces): the workspace has to be walked to register the paths against the watch service. I am thinking to use a ForkJoinPool but I've never used it to walk a file tree. Do you have any advice and/or known pitfalls to share? Please review this patch. As it has been repeated in previous comments, NIO/2 WatchService use polling on OS X. Despite I've contributed a fragment in this patch set to let OS X use this NIO/2 based implementation, it is less than optimal. I will now start to implement a native monitor for OS X using FSEvents.
In general, ForkJoinTasks shoulud not block their executor threads so it seems that it might be a poor fit for directory operations. However I did a quick spike [1] and it worked remarkably well: For example, scanning my complete home directory on my laptop (i5-2430M CPU @ 2.40GHz, OCZ-VERTEX2 SSD): Scanned 214817 directories in 23397ms Scan of an actual Eclipse workspace with a 1000 nested subdirectories takes roughly 1 second, so this is definitely workable. [1] https://gist.github.com/rkrzewski/8882d5381aa01a50864b1739554e2b5b
Thanks Rafal. I actually ended up with using JobGroup [1][2] because throttling was appealing to me. However, I used your advice to use a DirectoryStream instead of a FileVisitor to keep the number of opened file low (max = max number of threads). The patch set has been updated accordingly. [1] http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fcore%2Fruntime%2Fjobs%2FJobGroup.html [2] https://www.eclipsecon.org/na2015/sites/default/files/slides/Eclipsecon-Extending-Jobs-to-speed-up-Eclipse.pdf
New Gerrit change created: https://git.eclipse.org/r/74291
(In reply to Eclipse Genie from comment #17) > New Gerrit change created: https://git.eclipse.org/r/74291 This one is with an OS X native hook. It uses FSEvent. Please test and review :)
Is there anyone interested in testing and reviewing these two reviews?
(In reply to Mikaël Barbero from comment #19) > Is there anyone interested in testing and reviewing these two reviews? Yes! I'll do some testing of both patches in the next few days. I can do some reviewing of the patches but I'm not a committer on either projects.
@Mikaël I tried testing the patch (for Linux) using oracle-jdk8 and Ubuntu 14.04 (3.13.0-91-generic) and it doesn't seem to work for me (maybe my test bench?). Using a workspace with a project, I created some files in the folder (touch test{0..100}) and they didn't seem to refresh in the Project Explorer view. By debugging a bit I noticed that WatchServicePoller.run() was called but WatchServicePoller.handleEvent() was never called because watchKey@line 47 was always null. Any ideas why this is happening?
Thanks Patrik-Jeffrey for the testing. Could you please activate the auto-refresh debug options and paste the console output out here? (the options are org.eclipse.core.resources/debug=true and org.eclipse.core.resources/refresh=true). Thanks.
Created attachment 263026 [details] Console log shown when starting the Eclipse application
(In reply to Mikaël Barbero from comment #22) > Thanks Patrik-Jeffrey for the testing. Could you please activate the > auto-refresh debug options and paste the console output out here? (the > options are org.eclipse.core.resources/debug=true and > org.eclipse.core.resources/refresh=true). Thanks. I have attached the console log! And yes there does seem to be an issue when trying to register the service. Thanks
Thanks for the log. This error seems to happen when there is no more inotify handles available. Could you please print the results of the following commands: cat /proc/sys/fs/inotify/max_user_instances cat /proc/sys/fs/inotify/max_user_watches And try to increase these values with $ sudo sysctl fs.inotify.max_user_watches=30000 Thanks.
Here are the results from the commands: cat /proc/sys/fs/inotify/max_user_instances 182 cat /proc/sys/fs/inotify/max_user_watches 524288 which already is higher than 300 000. I tried putting 300000, 1000000 and 3000000 as max_user_watches and I still see the same problems in the logs. Thanks!
I've pushed a new patchset https://git.eclipse.org/r/#/c/73007/ that should fix the issue. Could you please give it a try?
Is there anyone from platform.resource available to review / merge these patches?
(assigning to me to avoid spamming, please add yourself to the cc list if your interested in following the bug).
With https://git.eclipse.org/r/#/c/73007/17 I was getting: !ENTRY org.eclipse.core.jobs 4 0 2017-02-13 12:15:43.966 !MESSAGE Monitor registrar !SUBENTRY 1 org.eclipse.core.jobs 4 2 2017-02-13 12:15:43.966 !MESSAGE An internal error occurred during: "Workspace Resource Registrar Job". !STACK 0 java.lang.IllegalArgumentException: Path component should be '/' at sun.nio.fs.UnixFileSystemProvider.checkUri(UnixFileSystemProvider.java:77) at sun.nio.fs.UnixFileSystemProvider.getFileSystem(UnixFileSystemProvider.java:92) at java.nio.file.FileSystems.getFileSystem(FileSystems.java:221) at org.eclipse.core.internal.resources.refresh.nio2.Nio2RefreshMonitor.getOrCreateWatchService(Nio2RefreshMonitor.java:205) at org.eclipse.core.internal.resources.refresh.nio2.RecursiveResourceRegistrarJob.register(RecursiveResourceRegistrarJob.java:119) at org.eclipse.core.internal.resources.refresh.nio2.RecursiveResourceRegistrarJob.run(RecursiveResourceRegistrarJob.java:71) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56) Now Eclipse doesn't even come up being stuck in !ENTRY org.eclipse.core.jobs 4 0 2017-02-13 12:15:43.966 !MESSAGE Monitor registrar !SUBENTRY 1 org.eclipse.core.jobs 4 2 2017-02-13 12:15:43.966 !MESSAGE An internal error occurred during: "Workspace Resource Registrar Job". !STACK 0 java.lang.IllegalArgumentException: Path component should be '/' at sun.nio.fs.UnixFileSystemProvider.checkUri(UnixFileSystemProvider.java:77) at sun.nio.fs.UnixFileSystemProvider.getFileSystem(UnixFileSystemProvider.java:92) at java.nio.file.FileSystems.getFileSystem(FileSystems.java:221) at org.eclipse.core.internal.resources.refresh.nio2.Nio2RefreshMonitor.getOrCreateWatchService(Nio2RefreshMonitor.java:205) at org.eclipse.core.internal.resources.refresh.nio2.RecursiveResourceRegistrarJob.register(RecursiveResourceRegistrarJob.java:119) at org.eclipse.core.internal.resources.refresh.nio2.RecursiveResourceRegistrarJob.run(RecursiveResourceRegistrarJob.java:71) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56) Now Eclipse doesn't even come up being stuck in RecursiveResourceRegistrarJob. !ENTRY org.eclipse.core.resources 2 0 2017-02-13 12:23:17.353 !MESSAGE Workspace initialization takes longer than usual. Thread ''Thread[Worker-1,5,main]'' is blocked until the initialization finishes. !SUBENTRY 1 org.eclipse.core.resources 1 0 2017-02-13 12:23:17.353 !MESSAGE Sample stacktrace of the blocked thread. !STACK 0 java.lang.Exception at org.eclipse.core.resources.ResourcesPlugin.logLongWorkspaceInitWarning(ResourcesPlugin.java:462) at org.eclipse.core.resources.ResourcesPlugin.getWorkspace(ResourcesPlugin.java:441) at org.eclipse.core.internal.localstore.FileStoreRoot.getManager(FileStoreRoot.java:69) at org.eclipse.core.internal.localstore.FileStoreRoot.computeURI(FileStoreRoot.java:97) at org.eclipse.core.internal.localstore.FileSystemResourceManager.locationURIFor(FileSystemResourceManager.java:814) at org.eclipse.core.internal.resources.Resource.getLocationURI(Resource.java:1089) at org.eclipse.core.internal.resources.refresh.nio2.RecursiveResourceRegistrarJob.register(RecursiveResourceRegistrarJob.java:115) at org.eclipse.core.internal.resources.refresh.nio2.RecursiveResourceRegistrarJob.run(RecursiveResourceRegistrarJob.java:71) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56) !SUBENTRY 1 org.eclipse.core.resources 1 0 2017-02-13 12:23:17.355 !MESSAGE Sample stacktrace of the initialization workspace job. !STACK 0 java.lang.Exception at java.lang.Object.wait(Native Method) at org.eclipse.core.internal.jobs.InternalJobGroup.doJoin(InternalJobGroup.java:312) at org.eclipse.core.internal.jobs.JobManager.join(JobManager.java:1052) at org.eclipse.core.internal.jobs.InternalJobGroup.join(InternalJobGroup.java:93) at org.eclipse.core.runtime.jobs.JobGroup.join(JobGroup.java:222) at org.eclipse.core.internal.resources.refresh.nio2.Nio2RefreshMonitor.monitor(Nio2RefreshMonitor.java:107) at org.eclipse.core.internal.resources.refresh.nio2.Nio2RefreshProvider.installMonitor(Nio2RefreshProvider.java:33) at org.eclipse.core.internal.refresh.MonitorManager.safeInstallMonitor(MonitorManager.java:265) at org.eclipse.core.internal.refresh.MonitorManager.monitor(MonitorManager.java:153) at org.eclipse.core.internal.refresh.MonitorManager.start(MonitorManager.java:285) at org.eclipse.core.internal.refresh.RefreshManager.manageAutoRefresh(RefreshManager.java:53) at org.eclipse.core.internal.refresh.RefreshManager.startup(RefreshManager.java:124) at org.eclipse.core.internal.resources.Workspace.startup(Workspace.java:2411) at org.eclipse.core.internal.resources.Workspace.open(Workspace.java:2156) at org.eclipse.core.resources.ResourcesPlugin$1.run(ResourcesPlugin.java:531) at org.eclipse.core.runtime.jobs.Job$2.run(Job.java:182) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56) !ENTRY org.eclipse.core.resources 2 0 2017-02-13 12:23:17.547 !MESSAGE Workspace initialization takes longer than usual. Thread ''Thread[main,6,main]'' is blocked until the initialization finishes. !SUBENTRY 1 org.eclipse.core.resources 1 0 2017-02-13 12:23:17.547 !MESSAGE Sample stacktrace of the blocked thread. !STACK 0 java.lang.Exception at org.eclipse.core.resources.ResourcesPlugin.logLongWorkspaceInitWarning(ResourcesPlugin.java:462) at org.eclipse.core.resources.ResourcesPlugin.getWorkspace(ResourcesPlugin.java:441) at org.eclipse.emf.ecore.plugin.EcorePlugin.getWorkspaceRoot(EcorePlugin.java:1131) at org.eclipse.emf.ecore.resource.impl.ExtensibleURIConverterImpl.<clinit>(ExtensibleURIConverterImpl.java:393) at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getURIConverter(ResourceSetImpl.java:499) at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:369) at org.eclipse.e4.ui.internal.workbench.ResourceHandler.getResource(ResourceHandler.java:286) at org.eclipse.e4.ui.internal.workbench.ResourceHandler.loadResource(ResourceHandler.java:262) at org.eclipse.e4.ui.internal.workbench.ResourceHandler.loadMostRecentModel(ResourceHandler.java:169) at org.eclipse.e4.ui.internal.workbench.swt.E4Application.loadApplicationModel(E4Application.java:378) at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:253) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:614) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:594) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590) at org.eclipse.equinox.launcher.Main.run(Main.java:1499) at org.eclipse.equinox.launcher.Main.main(Main.java:1472) !SUBENTRY 1 org.eclipse.core.resources 1 0 2017-02-13 12:23:17.548 !MESSAGE Sample stacktrace of the initialization workspace job. !STACK 0 java.lang.Exception at java.lang.Object.wait(Native Method) at org.eclipse.core.internal.jobs.InternalJobGroup.doJoin(InternalJobGroup.java:312) at org.eclipse.core.internal.jobs.JobManager.join(JobManager.java:1052) at org.eclipse.core.internal.jobs.InternalJobGroup.join(InternalJobGroup.java:93) at org.eclipse.core.runtime.jobs.JobGroup.join(JobGroup.java:222) at org.eclipse.core.internal.resources.refresh.nio2.Nio2RefreshMonitor.monitor(Nio2RefreshMonitor.java:107) at org.eclipse.core.internal.resources.refresh.nio2.Nio2RefreshProvider.installMonitor(Nio2RefreshProvider.java:33) at org.eclipse.core.internal.refresh.MonitorManager.safeInstallMonitor(MonitorManager.java:265) at org.eclipse.core.internal.refresh.MonitorManager.monitor(MonitorManager.java:153) at org.eclipse.core.internal.refresh.MonitorManager.start(MonitorManager.java:285) at org.eclipse.core.internal.refresh.RefreshManager.manageAutoRefresh(RefreshManager.java:53) at org.eclipse.core.internal.refresh.RefreshManager.startup(RefreshManager.java:124) at org.eclipse.core.internal.resources.Workspace.startup(Workspace.java:2411) at org.eclipse.core.internal.resources.Workspace.open(Workspace.java:2156) at org.eclipse.core.resources.ResourcesPlugin$1.run(ResourcesPlugin.java:531) at org.eclipse.core.runtime.jobs.Job$2.run(Job.java:182) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56) !ENTRY org.eclipse.core.resources 2 0 2017-02-13 12:23:37.357 !MESSAGE Workspace initialization takes longer than usual. Thread ''Thread[Worker-1,5,main]'' is blocked until the initialization finishes. !SUBENTRY 1 org.eclipse.core.resources 1 0 2017-02-13 12:23:37.357 !MESSAGE Sample stacktrace of the blocked thread. !STACK 0 java.lang.Exception at org.eclipse.core.resources.ResourcesPlugin.logLongWorkspaceInitWarning(ResourcesPlugin.java:462) at org.eclipse.core.resources.ResourcesPlugin.getWorkspace(ResourcesPlugin.java:441) at org.eclipse.core.internal.localstore.FileStoreRoot.getManager(FileStoreRoot.java:69) at org.eclipse.core.internal.localstore.FileStoreRoot.computeURI(FileStoreRoot.java:97) at org.eclipse.core.internal.localstore.FileSystemResourceManager.locationURIFor(FileSystemResourceManager.java:814) at org.eclipse.core.internal.resources.Resource.getLocationURI(Resource.java:1089) at org.eclipse.core.internal.resources.refresh.nio2.RecursiveResourceRegistrarJob.register(RecursiveResourceRegistrarJob.java:115) at org.eclipse.core.internal.resources.refresh.nio2.RecursiveResourceRegistrarJob.run(RecursiveResourceRegistrarJob.java:71) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56) !SUBENTRY 1 org.eclipse.core.resources 1 0 2017-02-13 12:23:37.357 !MESSAGE Sample stacktrace of the initialization workspace job. !STACK 0 java.lang.Exception at java.lang.Object.wait(Native Method) at org.eclipse.core.internal.jobs.InternalJobGroup.doJoin(InternalJobGroup.java:312) at org.eclipse.core.internal.jobs.JobManager.join(JobManager.java:1052) at org.eclipse.core.internal.jobs.InternalJobGroup.join(InternalJobGroup.java:93) at org.eclipse.core.runtime.jobs.JobGroup.join(JobGroup.java:222) at org.eclipse.core.internal.resources.refresh.nio2.Nio2RefreshMonitor.monitor(Nio2RefreshMonitor.java:107) at org.eclipse.core.internal.resources.refresh.nio2.Nio2RefreshProvider.installMonitor(Nio2RefreshProvider.java:33) at org.eclipse.core.internal.refresh.MonitorManager.safeInstallMonitor(MonitorManager.java:265) at org.eclipse.core.internal.refresh.MonitorManager.monitor(MonitorManager.java:153) at org.eclipse.core.internal.refresh.MonitorManager.start(MonitorManager.java:285) at org.eclipse.core.internal.refresh.RefreshManager.manageAutoRefresh(RefreshManager.java:53) at org.eclipse.core.internal.refresh.RefreshManager.startup(RefreshManager.java:124) at org.eclipse.core.internal.resources.Workspace.startup(Workspace.java:2411) at org.eclipse.core.internal.resources.Workspace.open(Workspace.java:2156) at org.eclipse.core.resources.ResourcesPlugin$1.run(ResourcesPlugin.java:531) at org.eclipse.core.runtime.jobs.Job$2.run(Job.java:182) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
Thanks for the feedbacks. Sorry about the issues, I should have mentioned that patchset 17 is still WIP. I've started to take into account the Resource filters but did not get the time to test the patches. I should be able to test it next week and fix the issue you've discovered.
I consider patchset 21 pretty stable. Please provide some testing / reviewing! Thanks!
How can I help testing this change? Are binaries with this change available in a CI system, or do I need to build them myself? Can you point me to relevant documentation?
(In reply to Rafal Krzewski from comment #33) > How can I help testing this change? Are binaries with this change available > in a CI system, or do I need to build them myself? Can you point me to > relevant documentation? The best way to go is to use Oomph to provision an Eclipse with the Platform/Resource [1] project and to checkout pathchset 21 in the workspace [2]. You will then be able to start an Eclipse runtime [3] with the patches where you can do your testing. [1] the process is similar to https://wiki.eclipse.org/Platform_UI/How_to_Contribute but instead of checking Platform/UI, you check Platform/Resource [2] https://wiki.eclipse.org/EGit/User_Guide#Fetching_a_change_from_a_Gerrit_Code_Review_Server [3] https://wiki.eclipse.org/FAQ_How_do_I_run_my_plug-in_in_another_instance_of_Eclipse%3F
Too late for 4.7.
(In reply to Dani Megert from comment #35) > Too late for 4.7. This missed 4.8. Too late for 4.9?
(In reply to Gunnar Wagenknecht from comment #36) > (In reply to Dani Megert from comment #35) > > Too late for 4.7. > > Too late for 4.9? Definitely.
This feature would be really nice. Do we need more testing or are we ready to merge?
Some more testing is required. Feel free to give as much feedback as you can. Thanks.
Maybe it's worth merging both patches as soon as possible for 4.15M1? That gives lots of time for beta users to test the nightlies and give more extensive feedback.
(In reply to Pierre-Yves B. from comment #40) > Maybe it's worth merging both patches as soon as possible for 4.15M1? That > gives lots of time for beta users to test the nightlies and give more > extensive feedback. See also bug 237344. If someone want drive this forward, and we agree that we could try to release something "experimental" we probably need (IMO): * rebased patches * new preferences to *disable* new refresh providers until *user* (or product preference) decides to enable them. I can offer testing on Linux, but I have no way to test Mac changes.
Any progress? I opened potential duplicate https://bugs.eclipse.org/bugs/show_bug.cgi?id=570794 How could I assist testing on MacOS (Big Sur).
(In reply to Andrey Loskutov from comment #41) > (In reply to Pierre-Yves B. from comment #40) > > Maybe it's worth merging both patches as soon as possible for 4.15M1? That > > gives lots of time for beta users to test the nightlies and give more > > extensive feedback. > > See also bug 237344. > > If someone want drive this forward, and we agree that we could try to > release something "experimental" we probably need (IMO): > > * rebased patches > * new preferences to *disable* new refresh providers until *user* (or > product preference) decides to enable them. > > I can offer testing on Linux, but I have no way to test Mac changes. I can test Mac changes, but it might be easier to get feedback if we have them installed but not enabled. That way they can be enabled to get feedback without requiring those users to compile/build/test the patches? It's too late for 4.19 but we could aim to get this in for 4.20?
