Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #366170 +++ We have an issue that blocks processing of an application. It turns out that the job manager does not activate (run) a scheduled job after the specified time, even more it never starts it at all. We traced it down to the job scheduling framework in JobManager. That made it possible to create a hello world example. Just open it in a workspace and launch the products/hello.product The hello world is attached and does the following: Main: schedule job A Main: schedule job C A: schedule job B and join on it B: do sleep until a stop flag is set to true. C: set the stop flag Even more, all jobs scheduled after A (has started running) are never run and awakened. Therefore i added some info jobs that just say hello. In order to not wait forever, i added a sleep 2000 after which it breaks up waiting in the main thread. When calling IJobManager.resume at that point, it magically awakenes all ready-to-run jobs and runs them. But the javadoc says that calling resume() does nothing when the job manager is active. Expected behaviour: I expect that whenever scheduling a Job say schedule(200) it is run after 200 ms +/- some acceptable delay. Never running it is breaking the concept of having parallel jobs in a system.
Backporting fix to 3.7.2 stream.
Created attachment 209474 [details] Patch
The old code was: if (manager.sleepHint() <= 0) jobQueued(); This means: if there is a job ready to run right now, ensure there is a worker thread available The new code is: if (manager.sleepHint() < InternalJob.T_INFINITE) jobQueued(); This means: if there is any job ready to run now or at any time in the future, ensure there is a worker thread available
http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?h=R3_7_maintenance&id=5515735b0a465f748f45aaf50ed90d2cae24b85d Released.
Hi John, we are observing strange JUnit test failures which I think *could* be related to the job manager and this bug in particular. Unfortunately it is hard to provide stripped down test case. What we do is to test internal message dispatching job. Test generates events in a loop and test is checking each time if the messages were dispatched properly. Dispatching should be done in a job. This works in 99.9% of the tests, but sometimes *randomly* fail. I've did VM snapshots on fail and found that the job which was re-scheduled during the test was always in the SLEEPING state. We have this scenario: Main (Eclipse test framework): workbench.getProgressService().busyCursorWhile () schedule(0) job A and join on it A (Test job): re-schedules (with timeout of 10ms) the job B in the loop do Thread.sleep(few seconds) each time and fail if job B is NOT done after each sleep B: dispatch events until internal message queue is not empty Observation: sometimes job B is never executed, staying in SLEEPING state. We see this with both 3.5.1, 3.7.1 and 3.7.2 Eclipse versions on RHEL 5.3 Linux/Sun 1.6 VM 64 bit. As the scenario we have is similar (join + sleep + schedule(time)), I've expected seeing the problem resolved in 3.7.2, but this is not the case. Could it be that there is still some special cases left where Job manager does not activate (run) scheduled jobs?
