| issue with progress view [message #323997] |
Tue, 15 January 2008 15:48  |
Eclipse User |
|
|
|
Originally posted by: mail.volker-wegert.de
Hi,
I'm seeing a strange issue with the progress view... I'm starting a series of
long-running background jobs (typically up to 3 minutes). All of these jobs
are instances of the same class. I only want one of these jobs to be run at a
time because they require the same resource and might cause trouble when run
in parallel threads. In order to get this done, I consulted the manual and did
something that may or may not be a good idea... Basically, my job class
implements ISchedulingRule and sets itself as its scheduling rule in the
constructor. The contains() implementation simply checks whether the parameter
is identical to the object itself (since my jobs can't be nested), and the
isConflicting() method checks whether the parameter is an instance of the job
class. While this works perfectly, the progress view behaves in a strange
way...
Let's assume I start 10 jobs. The first job will appear in the progress view
and start running, I can observe its progress. Another job will appear below
it in state "waiting" - but that's not necessarily the second one, it might
also be job number 4. The progress view never shows more than two entries over
the entire duration of this experiment. Now when job 1 is finished, it
disappears from the progress view and the next job starts. This is not
necessarily job 2 (I don't expect it to be), and it's not necessarily the one
that's left in the progress view (I don't expect this either). While I can see
that the job is running in the status bar, it doesn't appear in the progress
view - the view only contains job number 4 that is still waiting. Closing the
view and opening it again makes the job that is currently running appear with
at most one in state waiting below it - and the story commences all over
again.
Is this a bug worth reporting or did I do something terribly stupid? If so,
what could that be?
Thanks
Volker
--
* Volker Wegert * http://www.volker-wegert.de/contact *
* "Es gibt Unternehmen, die werden mit Konsequenz geführt. Konsequent in
* den Ruin." (Mittagsgast im "Da Mario" in Rotenburg)
*
|
|
|
| Re: issue with progress view [message #323999 is a reply to message #323997] |
Tue, 15 January 2008 18:12  |
| Eclipse User |
|
|
|
For those considering this, I've had a similar issue in 3.3: a job which
is sleeping in the progress view when the progress view opens will
change to show that it is running as soon as it starts, but will not
show the progress bar (it shows the stop button and the message, but no
progress bar). When the progress view is closed and opened again, the
job will then show the progress bar. Wasn't a problem in 3.2.
Marcel
Volker Wegert wrote:
> Hi,
>
> I'm seeing a strange issue with the progress view... I'm starting a series of
> long-running background jobs (typically up to 3 minutes). All of these jobs
> are instances of the same class. I only want one of these jobs to be run at a
> time because they require the same resource and might cause trouble when run
> in parallel threads. In order to get this done, I consulted the manual and did
> something that may or may not be a good idea... Basically, my job class
> implements ISchedulingRule and sets itself as its scheduling rule in the
> constructor. The contains() implementation simply checks whether the parameter
> is identical to the object itself (since my jobs can't be nested), and the
> isConflicting() method checks whether the parameter is an instance of the job
> class. While this works perfectly, the progress view behaves in a strange
> way...
>
> Let's assume I start 10 jobs. The first job will appear in the progress view
> and start running, I can observe its progress. Another job will appear below
> it in state "waiting" - but that's not necessarily the second one, it might
> also be job number 4. The progress view never shows more than two entries over
> the entire duration of this experiment. Now when job 1 is finished, it
> disappears from the progress view and the next job starts. This is not
> necessarily job 2 (I don't expect it to be), and it's not necessarily the one
> that's left in the progress view (I don't expect this either). While I can see
> that the job is running in the status bar, it doesn't appear in the progress
> view - the view only contains job number 4 that is still waiting. Closing the
> view and opening it again makes the job that is currently running appear with
> at most one in state waiting below it - and the story commences all over
> again.
>
> Is this a bug worth reporting or did I do something terribly stupid? If so,
> what could that be?
>
> Thanks
> Volker
>
|
|
|
| Re: issue with progress view [message #324010 is a reply to message #323999] |
Wed, 16 January 2008 06:39 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Guys,
If you can reproduce this with a relatively simple test case then it
sounds like a good bugzilla to open.
Marcel wrote:
> For those considering this, I've had a similar issue in 3.3: a job
> which is sleeping in the progress view when the progress view opens
> will change to show that it is running as soon as it starts, but will
> not show the progress bar (it shows the stop button and the message,
> but no progress bar). When the progress view is closed and opened
> again, the job will then show the progress bar. Wasn't a problem in 3.2.
>
> Marcel
>
> Volker Wegert wrote:
>> Hi,
>>
>> I'm seeing a strange issue with the progress view... I'm starting a
>> series of
>> long-running background jobs (typically up to 3 minutes). All of
>> these jobs
>> are instances of the same class. I only want one of these jobs to be
>> run at a
>> time because they require the same resource and might cause trouble
>> when run
>> in parallel threads. In order to get this done, I consulted the
>> manual and did
>> something that may or may not be a good idea... Basically, my job class
>> implements ISchedulingRule and sets itself as its scheduling rule in the
>> constructor. The contains() implementation simply checks whether the
>> parameter
>> is identical to the object itself (since my jobs can't be nested),
>> and the
>> isConflicting() method checks whether the parameter is an instance of
>> the job
>> class. While this works perfectly, the progress view behaves in a
>> strange
>> way...
>>
>> Let's assume I start 10 jobs. The first job will appear in the
>> progress view
>> and start running, I can observe its progress. Another job will
>> appear below
>> it in state "waiting" - but that's not necessarily the second one, it
>> might
>> also be job number 4. The progress view never shows more than two
>> entries over
>> the entire duration of this experiment. Now when job 1 is finished, it
>> disappears from the progress view and the next job starts. This is not
>> necessarily job 2 (I don't expect it to be), and it's not necessarily
>> the one
>> that's left in the progress view (I don't expect this either). While
>> I can see
>> that the job is running in the status bar, it doesn't appear in the
>> progress
>> view - the view only contains job number 4 that is still waiting.
>> Closing the
>> view and opening it again makes the job that is currently running
>> appear with
>> at most one in state waiting below it - and the story commences all over
>> again.
>> Is this a bug worth reporting or did I do something terribly stupid?
>> If so,
>> what could that be?
>>
>> Thanks
>> Volker
>>
|
|
|
| Re: issue with progress view [message #324033 is a reply to message #324010] |
Wed, 16 January 2008 16:13 |
| Eclipse User |
|
|
|
Originally posted by: mail.volker-wegert.de
Ed Merks <merks@ca.ibm.com> writes:
> If you can reproduce this with a relatively simple test case then it sounds
> like a good bugzilla to open.
Done - see bug 215568. This issue also appears with the most simple test case
I could imagine - let's see what the platform magicians make of it :-)
Volker
--
* Volker Wegert * http://www.volker-wegert.de/contact *
* "Letzten Endes kommt man drauf. Er ist krank!" (unbekannt)
*
*
|
|
|
Powered by
FUDForum. Page generated in 0.06837 seconds
Home