#115 p4eclipse pegs CPU at 100% on Win XP

[mjl]

Using Eclipse 3.0 M9, I find that if I have p4eclipse
installed and a bunch of projects shared, then starting
eclipse will peg the performance meter at 100% CPU
usage and render the entire system unresponsive.

If I disable p4eclipse, the problem disappears upon
eclipse restart.

This is running on a Windows XP box.

[Mindreef]

Logged In: YES
user_id=1044509

I've been struggling with this one also for some time. I'm
attempting to narrow down the problem. It seems to be
related to either one of:

1. compiled files being generated into the project tree and it
keeping the addition manager very busy.

2. Being periodically connected with my laptop (loosing
connectivity to perforce)

I hope to provide more details as I discover them.

[mjl]

Logged In: YES
user_id=1048903

I don't build from within eclipse (our build system is too
weird) so there are no compiled files being generated into
the project tree.

My machine is permanently connected to the perforce server
over an 100 mbit intranet, so losing connectivity with
Perforce isn't an issue either.

Right now this problem prevents me (and a number of other
users in my company) from using p4eclipse at all unless we
back off to 3.0 M7.

[Mindreef]

Logged In: YES
user_id=1044509

I have traced this down further apparantly the
BackgroundUpdate Monitor thread
(BackgroundMonitorRunnable) is in a tight loop in the run
() method.

The Thread.sleep(...) in the run() loop seems to
immediately return (not sure if it is 'Interrupted' or not)

I can't readily recreate the scenario, but when I do see
100% cpu it is always in this loop. It also seems that the
eclipse is also 'copying resources' for the build at the
same time.

Hope this is of some help.

[mjl]

Logged In: YES
user_id=1048903

FWIW, we all have background update turned off. Does the
BackgroundUpdate monitor thread run even if background
updates are off?

[Mindreef]

Logged In: YES
user_id=1044509

I found out what is happening, for some reason (I can't
tell why yet) the value of
PerforceCorePlugin.backgroundUpdateInterval gets set to
0 causing the 100% cpu utilization.

Still needs a fix, but there is a workaround if you ever find
yourself in this situation...

return to the preferences for the update interval and
click 'Apply' reseting the value back, and the cpu
immediately drops back to normal.

[Mindreef]

Logged In: YES
user_id=1044509

In answer to aprevious question re: background updates
turned off...

Turning off background updates does not shutdown the
update thread (it probably should). It does the loop even
if background updates are disabled. Perhaps, it does less
work in each iteration, however when the
backgroundUpdateInterval goes to 0 it will cause 100%
utilization.

[mjl]

Logged In: YES
user_id=1048903

The workaround works great -- I'll pass it along to everyone
else internally who's being burned (so to speak) by this.

[Paddy Walsh]

Logged In: YES
user_id=1059133

I have had the same sort of problem. Using Eclipse 3.0 (build
200312182000) with Perforce plugin and two largish projects.
If I close one project then open the other it seems to go
into 'building workspace' mode and any attempt to do
anything results in a dialog saying locked while building
workspace. Unfortunately it never finishes and locks the
machine. It is event difficult to kill with task manager and in
the past I have had to just trun off the machine. This
happens all the time and now the only thing I can do to
overcome it is delete and recreate the project - a bit drastic
but otherwise it is unusable.

[bgm]

Logged In: YES
user_id=1152642

I did a quick cheesy fix and it seems to have stopped my
problem ( 20 minute startup times). I changed the file
net/sourceforge/perforce/core/internal/BackgroundUpdateRunnable.java
around line 115 from

Thread.sleep(PerforceCorePlugin.getPlugin().getBackgroundUpdateInterval()*1000);

to

int interval =
PerforceCorePlugin.getPlugin().getBackgroundUpdateInterval();
if ( interval == 0 )
{
interval = 120;
}
Thread.sleep(interval * 1000);

It only masks the problem. BTW, I think there is another
perforce plugin project by perforce.

[Fowlow]

Logged In: YES
user_id=1177535

A different workaround ...

if you switch to the Perforce Perspective,
the usage drops back to normal.