Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 317469

Summary: Updating JSP/javascript index taking all cpu/RAM ...
Product: [WebTools] WTP Source Editing Reporter: Jean Couillaud <carm>
Component: jst.jspAssignee: jst.jsp <jst.jsp-inbox>
Status: RESOLVED FIXED QA Contact: Nitin Dahyabhai <thatnitind>
Severity: major    
Priority: P3 CC: carm, ccc, nsand.dev, schlosna
Version: 3.2Keywords: needinfo
Target Milestone: 3.3.1   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Jean Couillaud CLA 2010-06-21 10:57:19 EDT
Build Identifier: 20100521-0446

In the jobs view, I see that there is a job called Updating JSP index and sometimes an other one titled UPdaing javascript index.
They are taking 100% cpu and most of the RAMand take ages to complete although I hav few jsps (< 100)
I am going crazy with this thing. Each time I save a jsp, the interface freezes for long minutes before it's completed ... This is a huge issue ...
I do not remember having such an issue with previous releases of the wtp ...
I have disabled the jsp validators, and most other validators, hoping it would help but I got no luck .. it's still indexing ...

Is there a way to disable it for good ?

Reproducible: Always
Comment 1 Jean Couillaud CLA 2010-06-22 05:58:13 EDT
I have further informations:

It's not 100% predictable. When I update a single file, sometimes, it re-indexes no file, one jsp file, several, all jsp files ... it depends, even when modifying the same file over and over and doing the same single modification (adding/removing a space)
I have disabled all validators, with no more results.

Since it takes a long time to do that, it clashes with the save/compile process:
If I save the same file again while it's re-indexing it (following last save), which can last up to 1 minute, it fails compiling, telling there is a lock on the jsp file.
So, besides taking a lot of CPU, it also prevents me from continuing even if the computer was still responsive.

If it stays the same, I'll have to go back permanently to galileo ... At the moment, helios is just completly unusable.

I have tested with Galileo, it is re-indexing jsp files regularly but it's by far faster, completly unnoticable. So this is definitly a new performance defect (regression ?).
Comment 2 Nick Sandonato CLA 2010-06-24 14:37:36 EDT
Hello,

There is no way to disable indexing.

Bug 315978 may be related to this performance issue. We have several large workspaces ourselves that we use to test, but have not come across anything like this yet. By definition, I do not think this counts as a critical bug because there are not crashes/loss of data/severe memory leaks.

If you could, would it be possible to get some stack dumps to see where a lot of the CPU is being eaten up?

Thanks.
Comment 3 Nick Sandonato CLA 2010-06-24 17:27:39 EDT
Hi Jean,

Would you mind adding "-DpersistJSPTranslations=false" (without the quotes) at the end of your eclipse.ini file and start Eclipse to see if this might help with CPU usage?
Comment 4 Jean Couillaud CLA 2010-06-25 03:40:08 EDT
@Nick: Bug 315978 might well be related to my issue. I have not checked if there was a great number of potential name clashes and I unfortunatly have little time now for further investigations. The patch is scheduled to be included in 3.6.1 and not 3.6. this is unfortunate ...

As for testing with the additional parameter, I'll try that as soon as I can but it has been brought to my attention that I already have spent too much time testing a milestone version of eclipse during work time. Therefore, I am not sure when I will have some spare time to do that. (I ve switched back to using Galileo on the same workspace and it works like a charm)

I would have loved to dig into some stack dump, unfortunatly, it seems to me my current computer is far from what is needed in terms of performance to do that quickly enough.

I add originally filed it as critical since helios is, on my computer and with my workspace, simply unusable. This issue IS critical from MY point of view (and by eclipse's definition of "critical").
Comment 5 Nick Sandonato CLA 2011-01-19 12:31:01 EST
(In reply to comment #4)
> @Nick: Bug 315978 might well be related to my issue. I have not checked if
> there was a great number of potential name clashes and I unfortunatly have
> little time now for further investigations. The patch is scheduled to be
> included in 3.6.1 and not 3.6. this is unfortunate ...
> 
> As for testing with the additional parameter, I'll try that as soon as I can
> but it has been brought to my attention that I already have spent too much time
> testing a milestone version of eclipse during work time. Therefore, I am not
> sure when I will have some spare time to do that. (I ve switched back to using
> Galileo on the same workspace and it works like a charm)
> 
> I would have loved to dig into some stack dump, unfortunatly, it seems to me my
> current computer is far from what is needed in terms of performance to do that
> quickly enough.
> 
> I add originally filed it as critical since helios is, on my computer and with
> my workspace, simply unusable. This issue IS critical from MY point of view
> (and by eclipse's definition of "critical").

Hi Jean,

I know it's been some time since we last conversed. I was wondering if you had any luck with Helios SR1. Additionally, in SR2 we've refactored the JSP Indexer to hopefully perform a little more efficiently.
Comment 6 Nick Sandonato CLA 2011-03-09 14:52:26 EST
Hi, Jean. Now the Helios SR2 was out, I was wondering if you had a chance to see if performance has improved. Thanks.
Comment 7 Nick Sandonato CLA 2011-06-03 14:59:07 EDT
Hi, Jean. Have you noticed any improvements? Thanks.
Comment 8 Nick Sandonato CLA 2011-07-08 14:03:53 EDT
Resolving for now. As mentioned in comment #5, we've made things a little more efficient. If work still needs to be done, this can be re-opened and we can explore stack dumps or any other data that might help.
Comment 9 Jean Couillaud CLA 2011-07-11 09:44:41 EDT
Hi Nick,

It's been a long time since we last conversed indeed.
Unfortunatly, briefly after my first post, I was given some very different attributions and I have not had the opportunity to test the new jsp indexer.
Thanks for your time, though.