Community
Participate
Working Groups
Build Identifier: M20100909-0800 If a build or validation (especially Spring/XML/JSP) runs. Any user action issued, like save file will be blocked till the build finished. Then after the save the build/validation starts again. Which is a waste of time and bad UX. I typically using save after editing each file in case of an edit requires modification in multiple files. Reproducible: Always Steps to Reproduce: 1. Have a large project, which takes sufficiently long time to build. 2. While the build is in progress try to edit and save a file.
Basically, if change occurs during an active build, which would cause a new build to start. Like saving a file in the source path, or editing the classpath. The active build should be canceled, apply the change then start the build. Instead of waiting for the build to complete, which will be discarded immediately after the change gets applied, and blocking the user/developer progression with a uncloseable dialog.
(In reply to comment #1) > Basically, if change occurs during an active build, which would cause a new > build to start. Like saving a file in the source path, or editing the > classpath. The active build should be canceled, apply the change then start the > build. If a workspace change is attempted in another thread during build, then the build is immediately canceled today. However it is up to the individual builder that is running to react to this cancelation (via IncrementalProjectBuilder#isInterrupted). If the builder ignores the interrupt, then it will run to completion before the change can occur (such as file save). So, I suspect this bug is best directed at whoever defines the builder you are running. Is it primarly the Web Tools validators that are blocking you?
> If a workspace change is attempted in another thread during build, then the > build is immediately canceled today. However it is up to the individual builder > that is running to react to this cancelation (via > IncrementalProjectBuilder#isInterrupted). If the builder ignores the interrupt, > then it will run to completion before the change can occur (such as file save). > So, I suspect this bug is best directed at whoever defines the builder you are > running. Is it primarly the Web Tools validators that are blocking you? Although it is a web project, I had to disable almost all validation (with the exception of Spring beans, the builder is present for the JSP validation). Much of the JSP code is legacy, that simply unable to pass the validation. So it would be a wast of time validating them, besides I work on the lower layers. The setups is basic J2EE edition. It only has parts of STS and Spring IDE via update site + Checkestyle + Faceted Project Validation Builder. The project is loaded in 2 projects. One of the main application (4000 Java and 1600 configuration files, in 7 modules) and the other is the common module store (2000 Java files, in 40+ modules). (Using dependency management solution is officially not supported, so partitioning each modules as a separate project and managing a second dependency store by hand would be too problematic.) Recently I have was moved to 64bit OS, which allowed to increase PermGen to 512MB and xmx to 900MB this appears to have reduced the problem. Also I will try to remove the unneeded Validator from the builders list.
I have further information. It appears that it occurs if a build is in progress. While a workspace refresh is also in the task queue as well as the user operation.
Created attachment 198950 [details] Stacktrace I have manged to reproduce it please find the stack trace attached. Also it is affecting 3.7
(In reply to comment #2) > (In reply to comment #1) > Basically, if change occurs during an active > build, which would cause a new > build to start. Like saving a file in the > source path, or editing the > classpath. The active build should be > canceled, apply the change then start the > build. If a workspace change > is attempted in another thread during build, then the build is immediately > canceled today. However it is up to the individual builder that is running > to react to this cancelation (via IncrementalProjectBuilder#isInterrupted). > If the builder ignores the interrupt, then it will run to completion before > the change can occur (such as file save). So, I suspect this bug is best > directed at whoever defines the builder you are running. Is it primarly the > Web Tools validators that are blocking you? No, this is unacceptable. The UI should NEVER NEVER NEVER NEVER NEVER NEVER NEVER NEVER NEVER NEVER stop the user form EDITING or SAVING a file. NEVER EVER. The editing and saving functionality should ALWAYS IMMEDIATELY happen. If eclipse can't provide context senstive help or code completion, that's OK, but I should always be able to type text into an editor and save it. Whatever else is going on can wait, saving the users thoughts and changes should ALWAYS be more important thaan anything else the IDE is doing. If a file has to be checked out or fiddled with or whatever you can do that AFTER the changes are saved safely to the disk. Blocking user interactions is completely unacceptable. The UI should NEVER stop the user form EDITING or SAVING a file. The entire philosophy of eclipse should be that you edit files, and save things. Sometimes you do things with those saved and edited files, (like compile them or run them or deploy them or debug them) but those things you do should NEVER stop you from doing the basic edit and save functionality. The same is also true of navigation and search. You should always be able to search for text and you should always be able to perform simple file based navigation.
Maybe eclipse needs one thread for the rest of eclipse and one thread for text editing that never will wait on the rest of eclipse for anything ever. Instead of the current model where it is up to the plugin makers (or whoever) to develop their code in a properly threaded way. The UI implementation should defensively prevent any "thing" that is not part of the simple file "open <==> edit <==> file save" from interfearing with the blessed and sacred task of opening files, changng them and resaving them.
*** Bug 385108 has been marked as a duplicate of this bug. ***
*** Bug 410633 has been marked as a duplicate of this bug. ***
(In reply to John Arthorne from comment #2) > If a workspace change is attempted in another thread during build, then the > build is immediately canceled today. However it is up to the individual > builder that is running to react to this cancelation (via > IncrementalProjectBuilder#isInterrupted). If the builder ignores the > interrupt, then it will run to completion before the change can occur (such > as file save). If a builder doesn't use IncrementalProjectBuilder#isInterrupted (which is fine according to the documentation), then it is not possible for this builder to notice that an interrupt was requested. However, I think we could probably do better here if we call cancel() on the auto-build job when calling AutoBuildJob.setInterrupted(true). This way, if the builder called monitor.isCanceled(), it would notice that it's time to stop. The isCanceled method is a recommended way to check for cancellation inside long-running operations so we would get much better response even if an operation is not aware it is run as part of a build (which is quite common for many operations). What is interesting is that AutoBuildJob.canceled() is called after checking monitor.isCanceled() and it checks the interrupted state (called "implicit cancel" there), but it is not possible anywhere to interrupt the build in a way, that it will result in monitor.isCanceled() returning true. Therefore, it looks like an omission that interrupting a build doesn't call cancel() on the auto-build job.
There is an important difference between build interrupt and cancel. When a build is canceled, it typically handles this by discarding incremental build state and letting the next build be a full rebuild. This can be quite expensive in some projects. As a user I think I would rather wait for the 5 second incremental build to finish rather than cancel and result in a 30 second rebuild afterwards. The idea with interrupt is that a builder could more efficiently handle interrupt by saving its intermediate state and resuming on the next invocation. In practice this is hard to implement so the most common boundary is when we check for interrupt before/after calling each builder in the chain.
Created attachment 238867 [details] Patch proposal
(In reply to John Arthorne from comment #11) > There is an important difference between build interrupt and cancel. When a > build is canceled, it typically handles this by discarding incremental build > state and letting the next build be a full rebuild. You're probably right, but it sounds weird. I would assume that builders operate in a transactional manner, i.e. if a build is canceled, it discards everything done in this cycle, but the last incremental state remains valid. The old incremental state should be discarded as the last step of build only if new state is ready. > The idea with interrupt is that a builder could more efficiently handle > interrupt by saving its intermediate state and resuming on the next > invocation. In practice this is hard to implement so the most common > boundary is when we check for interrupt before/after calling each builder in > the chain. This explanation makes sense, but it means that a "good" builder is a builder that has many short-running operations that can be separated with IncrementalProjectBuilder#isInterrupted. If operations are long-running, then we will not be able to tell them to stop on interrupt.
For future reference: the difference between "interrupt" and "cancel" has been discussed in bug 89301 which contains some good discussion and details for arguments mentioned in comment 11. It seems that bug 206637 is a real blocker for Java builder.
(In reply to Szymon Ptaszkiewicz from comment #12) > Created attachment 238867 [details] > Patch proposal Szymon, could you please convert this to a Gerrit review, so that I can pull in the changes via Git and try it out?
(In reply to Lars Vogel from comment #15) > (In reply to Szymon Ptaszkiewicz from comment #12) > > Created attachment 238867 [details] > > Patch proposal > > Szymon, could you please convert this to a Gerrit review, so that I can pull > in the changes via Git and try it out? You can apply the patch using Team > Apply Patch... without Gerrit review. This patch is just a proof of concept not something that should be merged, so there is no value in converting it to Gerrit right now.
+1
(In reply to Raymond Auge from comment #17) > +1 Can you please explain what are you voting on?
As a developer myself I realize how frustrating it can be to have the efforts of many hours be trivialized and taken for granted. I also understand how every single second of time that I cannot work due to uncontrollable circumstance only exacerbates this frustration. So, I'm emphasizing my desire to see this bug solved and encouraging the developers by expressing that their efforts will be highly appreciated by me. Go Team! You are awesome!
(In reply to Raymond Auge from comment #19) Thanks for clarification.
+100, this is a *completely unacceptable* architecture. At least in the last decades. This is one of the main reasons I don't use eclipse as much as I used to. I'd rather use a text editor than a power tool that GETS IN THE WAY. (In reply to Greg Bishop from comment #6) > (In reply to comment #2) > > (In reply to comment #1) > > Basically, if change occurs during an active > > build, which would cause a new > > build to start. Like saving a file in the > > source path, or editing the > > classpath. The active build should be > > canceled, apply the change then start the > > build. > > If a workspace change > > is attempted in another thread during build, then the build is immediately > > canceled today. However it is up to the individual builder that is running > > to react to this cancelation (via IncrementalProjectBuilder#isInterrupted). > > If the builder ignores the interrupt, then it will run to completion before > > the change can occur (such as file save). So, I suspect this bug is best > > directed at whoever defines the builder you are running. Is it primarly the > > Web Tools validators that are blocking you? > > No, this is unacceptable. The UI should NEVER NEVER NEVER NEVER NEVER NEVER > NEVER NEVER NEVER NEVER stop the user form EDITING or SAVING a file. > NEVER EVER. The editing and saving functionality should ALWAYS IMMEDIATELY > happen. If eclipse can't provide context senstive help or code completion, > that's OK, but I should always be able to type text into an editor and save > it. Whatever else is going on can wait, saving the users thoughts and > changes should ALWAYS be more important thaan anything else the IDE is > doing. If a file has to be checked out or fiddled with or whatever you can > do that AFTER the changes are saved safely to the disk. Blocking user > interactions is completely unacceptable. > > The UI should NEVER stop the user form EDITING or SAVING a file. The entire > philosophy of eclipse should be that you edit files, and save things. > Sometimes you do things with those saved and edited files, (like compile > them or run them or deploy them or debug them) but those things you do > should NEVER stop you from doing the basic edit and save functionality. The > same is also true of navigation and search. You should always be able to > search for text and you should always be able to perform simple file based > navigation.
*** Bug 442489 has been marked as a duplicate of this bug. ***
*** Bug 451071 has been marked as a duplicate of this bug. ***
Due to a lot of projects and slow HDDs the complete refresh and build of our workspace takes about 20 - 30 minutes. In this time each developer is blocked and not able to work on with eclipse. Typical workflow is: Update repository (by perforce plug-in, couple of 1000 files) -> refresh Workspace -> Build Because many changes are done during the day, we have to do this process 2 or 3 times a day which costs a lot of time. For optimization I threw out every project I don't need directly, which highly increases the risk of killing the continous build. The build still takes 10 minutes. Newer machines with SSDs need about 5 minutes. This behaviour really blocks me and my colleagues in our daily work and I hope it will be changed.
I can't agree more that this is an unacceptable architecture and the fact that it has been like this for a long long time. Sometimes the only way you can close eclipse is by killing it which runs the risk of corrupting your workspace.
*** Bug 234744 has been marked as a duplicate of this bug. ***
Another example to trigger a big blocking build is to switch via Git to another branch with significant changes. For example, if I switch for platform UI to the maintenance branch the IDE is basically locked.
100% agree with "the UI should NEVER stop the user form EDITING or SAVING a file". Sometimes user need to save the work and close the editor "right now".
I don't see we have any proposal how to fix it and anyone who actually works on it, so moving out of 4.7 (too late) and not assigning to 4.8 (no plan and no owner yet). I see the problem daily, so if anyone has an idea how to fix this, please step in.
Surely a daily repro and no plan is not the way forward. Clearly there is a major architectural problem. Naively it would seem there is a background builder and a foregound editor/saver/... So whenever there is a background/foreground conflict the UI fereze should be replaced by: a) the background should conditionally suspend/abort or the foregound should retract in response to a confirmation dialog (Do you really want to save MANIFEST.MF and abort the build of the following projects ....?) b) the background should unconditionally suspend/abort to allow the foregound to progress (e.g a GIT branch change probably does not need a confirmer, because it should have invoked some proactive API to inform that platform that a given project list is about to be trashed inhibiting any builds related to those projects until GIT or the user performs a multi-project refresh) c) the conflict is a bug that should be fixed. The confirmation dialog from a) should allow an AERI report to be generated. If the architecture does not support this ...
I don't think the process for fixing this will be that hard. First, disable the locks from the JDT builder. Then write a bunch of unit tests that initiate workspace changes at times that were previously impossible. For example, modify something during a build, modify something while firing a resource delta, etc. Test all combinations of "something" = java file, external jar file, .project, IJavaProject settings, etc. Use semaphores to make sure your test is really doing the right asynchronous stuff at the right time. In each combination of change, verify that both a resource delta and a Java model delta are fired for the modified thing. In particular, we'd need to verify that if we modify something used by the compiler (like the input .java file) while it is being compiled and before compilation is finished, the file will be scheduled for recompilation later. Once we have a rich set of unit tests, we'll have greater confidence in the change. I suspect the change itself is probably going to be easy. It may be as simple as just changing the scheduling rule on JDT's builder, similar to what zorzella@ did to AutoBuildJob in this patch: https://bugs.eclipse.org/bugs/attachment.cgi?id=102774&action=diff
*** Bug 514808 has been marked as a duplicate of this bug. ***
*** Bug 565973 has been marked as a duplicate of this bug. ***
It seems that the supplied patch was not applied to the code base. Given my limited understanding of the cause of the issue, it seems to me that the patch would not solve the cause and the popup, but probably cause other issues that an interrupted build is actually canceled which is not what the architecture desires. Is there any other way to get some progress on this issue?
Created attachment 283869 [details] Eclipse blocking user Create new Java Package, wizards appears, try to provide input, ECLIPSE BLOCKS USER FROM DOING WORK.
https://github.com/eclipse-platform/eclipse.platform.ui/issues/472 Reopened this bug on GitHub so it gets some more attention hopefully.
Created attachment 289217 [details] Patch proposal
(In reply to Muhammad Arsalan from comment #39) > Created attachment 289217 [details] > Patch proposal Please create PR for https://github.com/eclipse-platform/eclipse.platform.ui/issues/472
