Community
Participate
Working Groups
While server in stopped state no automatic publish operation should occur. I am noticing an unpleasant slowdown while I am developing being caused by unwanted automatic publishing occuring while the runtime is in stopped state. This seems completely unecessary work for the server tab to be doing at that time. While the runtime is stopped the server tab should keep listening for workspace modification events but simply mark resources as dirty (but do no actual commiting to runtime). If this is all that is happening already (even though the task list states its publishing, then there must be something no quite right with it). Some of these slowdowns cause a simple file save in the workspace to take > 6 seconds (maybe JVM GC went on too) but on average under 1.5 seconds to complete. I would expect an implicit publish operation to occur before any runtime "Start" operation, so doing it while it work in stopped state is unwanted. The only workaround is to remove the project from the runtime instance (then I have to set it all back up again when I do want to test it).
This automatic publishing feels like it comes from .java files being saved and the builder generating the .class (during automatic building). Which leads me into another problem, while a workspace build inprogress the server tools should not immediatly try and commit the changes to the runtime as the .class resources are created. It should batch them up and when it gets the signal the build is over commit the whole batch (like a transaction). This may also stop the two fighting for CPU usage and speed up the entire set of operations as publishing is not continiously restarted for each single change. Another possible problem is that a workspace clean (done just before the build) has removed all our resources and commiting these changes into the server runtime (while its running is undesirable). I think an event is given to the server tools during a workspace build start/finish. So it does at least know is build is happening. My thoughts on this are: * When a build clean occurs, we never propagate these changes to the runtime though any automatic publish operation. Resource delete events during workspace clean are never commited through automatic publish opertions. * While build inprogress, server runtime in any state: Batch all resource change events and dont commit anything in realtime. This would allow all dependant project to be built up before server tools start looking for resources in them (currently I get publish failures due to no resources). * When build finish event occurs and server runtime started and automatic incremental publish enabled: commit the writes to the runtime (the only change here is that I dont think automatic publishing preferences are being accounted for) * When build finish event occurs and server runtime stopped: just keep remembering the resources are dirty and let the implicit publish during runtime start take care of commiting them, or a manual publish action (this is a change in behaviour this bug report mainly seeks to address)
Because of the massive regression in publishing speed, this issue causes each incremental build to take at least one full minute on my 2GHz machine and usually closer to 90 seconds. Also, the first incremental build kicks off two (2) "Staring server - Tomcat v5.5 Server @ localhost (Waiting)" tasks. These tasks stay in the waiting state indefinitely and don't go away when cancelled. Additional incremental builds do not respawn these tasks.
I'll be investigating this for 1.0.1. Comments so far: * Publish is not part of the automatic build cycle, it is a job that is automatically kicked off when resource changes within the web app appear. You can turn off automatic publishing in the Tomcat editor. * There is already a bug opened against jst.j2ee for the performance regression. * The extra jobs in the list are actually old jobs that have already completed. There is already a bug against the Eclipse platform to clean these up correctly.
Changes checked into HEAD to stop auto publishing (the job) from occuring when a server is stopped. Change detection and marking servers as dirty will continue as before. Code will be released once 1.0.1 builds start. Performance bug in jst.j2ee (sorry, don't have the # handy) has been thoroughly investigated and a fix should be released for it shortly as well.
Do you want me to open another bug report in connection with my Comment #1 if I do a Clean+Build with server started and automatic publishing enabled I get publish errors (on Unix) because the publish operation is trying to look for resources that have gone missing (due to the build). This problem was greater highlighted because the build and publish operations in RC5 fight for CPU time (due to J2EE regression and automatic 1 sec publish enabled). This basically exposed a longer time window for this type of error to occur and be seen. Fixing the J2EE regression will reduce the window of time for the problem to occur (but it wont fix the problem) the more complex your workspace the more chance you have of hitting the problem. This is why I'm throwing it in the air of a possible way to fix by stalling any publish operations over a workspace build which has the effect of batching up all modifications. I'm debating that no publish operation should occur while a workspace build is in progress (and maybe just think about vice-verca). Sorry to have bunged them all together but I had opened 4 reports on that one day and didn't want to seem a windger LOL. I don't believe the J2EE regression affects anything I've raised here, but understand Comment #2 mixed that in. The regression has been useful to highlight possible scalability issues with huge projects (just imagine if members() really did need to take some number of seconds to complete, purely because of the complexity of your projects). Thanks for the fix.
Hi Darryl, Yes, please open up another bug for any remaining problems. I don't like having lots of bugs open, but it is much preferrable than trying to track several problems via the same bug. Take a look at bug 102227 though - the current behaviour should be that publishing uses a workspace resource lock, so builds should not be occurring at the same time as publishing. If this is happening then there is definitely something odd happening here.
Released for next 1.0.1 build.
This bug was moved to 'closed' state, since it is so old its assumed fixed and no longer useful or need further attention. Feel free to re-open, or open a new bug, if this semi-automatic processing was done in error.
New Gerrit change created: https://git.eclipse.org/r/107640
