Community
Participate
Working Groups
Steps to reproduce * start WTP with a fresh workspace * create tomcat 5.5 server * start the server from Servers view and wait for status to change to "started" * open Progress view and press "Remove All Finished Operations" Problem: Progress view shows finished "Starting Tomcat 5.5 Server @ localhost (Finished)" job and there is no way to get rid of it. See also bug 139155. This problem is caused by use of job IProgressMonitor in ...wst.server.core.internal.Server#synchronousStart. The monitor is passed to a new thread which calls IProgressMonitor.isCancell after the job has finished.
Created attachment 40551 [details] possible fix Unless I am missing something, there is no need to start separate "wait for timeout" thread. Attached patch implements similar timeout logic without extra thread, this ensures proper use of the progress monitor and solves the problem with zombi jobs in Progress view.
Although the thread probably isn't necessary, it does handle the case where a server hangs or is really slow in the start() launch configuration delegate, so I don't really want to remove it this close to 1.5. I've pulled the other bits of your solution out, tested, and applied it to HEAD.
Fix released to RC3.
I'm re-opening, for clarification, if not a more complete fix. Using RC3, I see the normal "finished" case work ok, BUT, if an error ooccurs, such as "port in use", the the job stays there .. in "finsihed" state, with is cancel X still active. If I presss 'x', it "cancels", but stays there forever? Is this remaining problem a symptom of bug 110805 or some other platform issue? Or, can we fix on our end? This is pretty easy to reproduce by installing a couple of servers, I did tomcat 5.0 and 5.5 ... starting one (progress all appears and disappears as expected) ... and then trying to start the other ... you can't because the ports are in use, but the progress indicator stays. Oh ... and as an asside ... why do these progress indicators take so much veritical space ... is that worth a seperate bug report? As message format issue?
Hi David, I can't reproduce on a "current" build (last week's I think) when the ports are in use. Anything else I might be doing differently? This sounds like just another instance of bug 110805. Since the job is already complete it explains why cancelling it doesn't do anything. Which vertical space are you talking about? In the Progress view? If so, this is an Eclipse UI issue that isn't tracked with any of the current bugs and you should open a new one against platform UI.
I see this problem with the latest "continuos" build as of this morning (1.5RC4-200605310507). Steps to reproduce 1. Start fresh workspace 2. Configure two JDKs (SUN and IBM Java5, for example) 3. Configure Tomcat 5.5 runtime using *non-default* JDK 4. Configure Tomcat Server 5. Remove the non-default JDK from "Installed JREs" 6. Start the Tomcat server Problem: Progress view shows "finished" job
(In reply to comment #2) > Although the thread probably isn't necessary, it does handle the case where a > server hangs or is really slow in the start() launch configuration delegate, so > I don't really want to remove it this close to 1.5. I've pulled the other bits > of your solution out, tested, and applied it to HEAD. > This extra thread does not seem to provide any benefits, at least not in its current implementation. Let me elaborate. There are three basic scenarios: server start (call to start(String,IProgressMonitor) to be specific) succeeded within timeout, server start failed within timeout and server start takes longer than timeout. The extra thread does not provide any benefits when start(String,IProgressMonitor) returns within timeout but it does create zombi job if start(...) fails with exception as you do not get serverChanged event in this case. I could imagine that an extra thread could be used to interrupt start(...) when it runs for too long, but current implementation only calls setServerState(IServer.STATE_STOPPED) which is not of much help. You can achieve similar functionality with special ProgressMonitorWithTimeout and this seems like a cleaner way to tell start(...) to quit.
David - In response to comment #4, yes this is a platform bug (Igor had opened bug 149857) where a Job will stick around in a useless state if you call isCanceled() on the progress monitor after the job has completed. We obviously don't need to call this after the job completes and it was just a function of the coding in WTP. The platform has fixed their part in 3.3, but I've finally been able to reproduce in WTP and track it down. (it was a timing issue; I just needed to setup different circumstances on my machine) Your scenario and Igor's end up calling isCanceled() in the same place, so one fix fixes both cases. I've released the fix for this to 1.5.1/2.0 and will release shortly. The Progress view and the UI is part of the platform - not sure why it takes so much space, but that would need to be covered in another bug.
Released for the next WTP 1.5.1 & 2.0 builds.
This is part of a "mass update" where bugs showing "fixed" between 7/1/2006 and 9/27/2006 are assumed fixed in WTP 1.5.1. feel free to change the target milestone if you know a more accurate setting.
Closing as resolved since 1.5.1. If this bug should not be closed, please reopen.
New Gerrit change created: https://git.eclipse.org/r/107829
New Gerrit change created: https://git.eclipse.org/r/107900
