Community
Participate
Working Groups
RC3 - set DEBUG=true in NewProgressViewer - in the debug statement in method NewProgressViewer.refresh(Object, boolean) add the argument "element" to the println. - launch Eclipse from workspace - in Job Factory enable "Reschedule" - press "Create jobs" Observe: after job has run for the first time, it disappears and never comes back. On the console you don't see any remove or add events, only refresh events and a single refreshAll that results in the removal of the job. I could live with the refresh (instead of add/remove) events, but the JobInfo passed as an argument is different between the first run and the second run of the job. This problem probably didn't showed up in the old progress viewer because at that time lots of refreshAll events were generated and ensured that the viewer was always in synch with the model.
bug #65992 is a consequence of this. It is probably less risky to use the workaround in #65992 than to fix this issue.
*** Bug 64235 has been marked as a duplicate of this bug. ***
The problem here is that we send the add when scheduled() is called. At this time the state of the job is Job.NONE so it will be filtered. On an aboutToRun you will get the refresh rather than the add unfiltered. I know you have a workaround for this but is Job.NONE the right state John?
Moving to John. We will revisit this post 3.0.
Just so I don't forget, here is why the state is NONE during a scheduled callback: - The state transition NONE->WAITING happens when a job is waited to the wait queue. - This transition used to be made before broadcasting the scheduled() event. - With a very fast job, this could mean that a job was queued, executed, and completed *before* the scheduled event completed (especially if another job change listener did non-trivial work). - The result was that a job change listener would sometimes get: ABOUT_TO_RUN RUNNING DONE SCHEDULED - This is an unexpected order of job change events. My "fix" was to broadcast the scheduled event before adding the job to the queue. The order of job changes events is now always reasonable and consistent, but the side-effect is that Job.getState() returns NONE from within the scheduled() event callback.
Andre and Tod: I am interested in making this change to ensure the state is WAITING when in the scheduled() event. This should make your life much easier in the progress view and other job listeners. Since we know how sensitive this code is, my plan is to release the fix in the first I-build after 3.1 M2. You might not need to make any code changes to handle this, but this gives us some time to iron out any wrinkles it might cause.
This is fine by me.
Fix released. Job state will always be WAITING immediately after scheduled() is called, including from within scheduled() job change listener callbacks. I ran all core tests on Windows and Linux, and did some sniff testing of the UI using the progress examples plugin on both platforms as well. I didn't expect this to matter much, especially since no job listeners in the platform seem to listen to the scheduled() callback at the moment anyway.
