High CPU on JSF auto-complete

[jboden]

Hi,

I see this behavior with Jboss tools and WTP JSF. When I go to autocomplete a jsf tag like value="#{bean.method}" it finds the list of beans very quickly. But when I hit ctrl-space after the period (bean.) it takes about 15 seconds with 100% cpu to pull up the list of methods.

But it's not just the first time. It does this every time like it won't cache something.

Does anyone have an idea of what to look for? I don't really have that many public methods, maybe 30 or so... I created a small bean and it finishes much faster. Any ideas what might be causing my existing beans to be so slow or any settings we can try?

Thanks!

[akazakov]

Is it jsp or xhtml? Just to check if WTP cause the problem could you create any xhtml and check some EL in text node since in that case only JBoss Tools auto compition will work.

[jboden]

I tried the same thing with a plain eclipse 3.4, no plugins and saw the same thing. So it looks like it's from WTP. Any ideas what it might be doing?

[maxandersen]

that WTP haven't indexed the methods yet ?

Anything in the error log ?

[jboden]

nothing at all in the eclipse error log (show view -> error log)

I would expect the first time to be slow, then cache the methods index. But it's acting as if it doesn't do that. Is there any type of debug option I can run to determine what it's doing? I saw this before on a very old jboss dev studio, then some patch fixed it, can't remember what it was.

Thanks for your help!

[peterj]

Try taking a few thread dumps during the 100% CPU time, that might help pinpoint the code causing this issue.

[jboden]

I hesitate to even respond because I just don't know where to go, but it would be nice to have WTP work. I am wondering what I have that is so special that others don't have. The mouse-over shows the method details, F3 works to jump to the bean code, it's just the ctrl-space after the period when searching for the bean methods. Funny thing is, now one of my jspx files does complete quickly.

But I used visualvm to grab some thread dumps and am including 5 below...just from the codeassist begin. Not sure where to go from here. It looks like the interesting things are in main. With visualvm running, it takes about 1 minute for eclipse to return and cpu to go normal.

It's almost always doing file IO. Any ideas of where to go from here?

Thanks!

"main" prio=6 tid=0x00957800 nid=0x450 runnable [0x00a3d000..0x00a3fe5c]
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at org.eclipse.core.internal.filesystem.local.LocalFile.openInputStream(LocalFile.java:356)
at org.eclipse.core.internal.localstore.FileSystemResourceManager.read(FileSystemResourceManager.java:642)
at org.eclipse.core.internal.resources.File.getContents(File.java:298)
at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsCharArray(Util.java:1140)
at org.eclipse.jdt.internal.core.CompilationUnit.getContents(CompilationUnit.java:635)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.getSource(SourceTypeConverter.java:612)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convertAnnotations(SourceTypeConverter.java:580)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convert(SourceTypeConverter.java:460)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convert(SourceTypeConverter.java:155)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.buildCompilationUnit(SourceTypeConverter.java:93)
at org.eclipse.jdt.internal.codeassist.impl.Engine.accept(Engine.java:83)


"main" prio=6 tid=0x00957800 nid=0x450 runnable [0x00a3d000..0x00a3fe5c]
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.close0(Native Method)
at java.io.FileInputStream.close(FileInputStream.java:259)
at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsCharArray(Util.java:1150)
at org.eclipse.jdt.internal.core.CompilationUnit.getContents(CompilationUnit.java:635)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.getSource(SourceTypeConverter.java:612)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convertAnnotations(SourceTypeConverter.java:580)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convert(SourceTypeConverter.java:460)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convert(SourceTypeConverter.java:155)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.buildCompilationUnit(SourceTypeConverter.java:93)
at org.eclipse.jdt.internal.codeassist.impl.Engine.accept(Engine.java:83)





"main" prio=6 tid=0x00957800 nid=0x450 runnable [0x00a3d000..0x00a3fe5c]
java.lang.Thread.State: RUNNABLE
at sun.nio.cs.SingleByteDecoder.decodeArrayLoop(SingleByteDecoder.java:53)
at sun.nio.cs.SingleByteDecoder.decodeLoop(SingleByteDecoder.java:83)
at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:544)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:298)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
- locked <0x30b71880> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsCharArray(Util.java:409)
at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsCharArray(Util.java:1145)
at org.eclipse.jdt.internal.core.CompilationUnit.getContents(CompilationUnit.java:635)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.getSource(SourceTypeConverter.java:612)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convertAnnotations(SourceTypeConverter.java:580)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convert(SourceTypeConverter.java:460)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convert(SourceTypeConverter.java:155)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.buildCompilationUnit(SourceTypeConverter.java:93)
at org.eclipse.jdt.internal.codeassist.impl.Engine.accept(Engine.java:83)



main" prio=6 tid=0x00957800 nid=0x450 runnable [0x00a3d000..0x00a3fe5c]
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:199)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
- locked <0x310e67d0> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsCharArray(Util.java:409)
at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsCharArray(Util.java:1145)
at org.eclipse.jdt.internal.core.CompilationUnit.getContents(CompilationUnit.java:635)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.getSource(SourceTypeConverter.java:612)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convertAnnotations(SourceTypeConverter.java:580)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convert(SourceTypeConverter.java:460)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convert(SourceTypeConverter.java:155)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.buildCompilationUnit(SourceTypeConverter.java:93)
at org.eclipse.jdt.internal.codeassist.impl.Engine.accept(Engine.java:83)





"main" prio=6 tid=0x00957800 nid=0x450 runnable [0x00a3d000..0x00a3fe5c]
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.close0(Native Method)
at java.io.FileInputStream.close(FileInputStream.java:259)
at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsCharArray(Util.java:1150)
at org.eclipse.jdt.internal.core.CompilationUnit.getContents(CompilationUnit.java:635)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.getSource(SourceTypeConverter.java:612)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convertAnnotations(SourceTypeConverter.java:580)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convert(SourceTypeConverter.java:460)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convert(SourceTypeConverter.java:155)
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.buildCompilationUnit(SourceTypeConverter.java:93)
at org.eclipse.jdt.internal.codeassist.impl.Engine.accept(Engine.java:83)

[maxandersen]

the thread dumps doesn't reveal much.

Any chance you can isolate this to a minimal project which we can import and try import and thus reproduce the problem ?

if not, maybe try use jing or similar to do a screencast to show what is going on ?

[jboden]

Thanks Max for your help,

I took your idea and stated a new project with one bean and one JSF page. As expected, it worked quickly. I then copied my 25 beans and 25 jsf pages, and added faces-config.xml entries. It then went back to 100% cpu.

Not sure if that's a valid test with all of the compile error present from just dropping in class files without the spring configs and related classes.

As far as screen shot, I simply hit Ctrl-Space and everything freezes.

At this point I think I'll have to punt and assume it's something in my project. If anyone has thoughts on what might do that, I appreciate your thoughts. Too many public methods, public or static vars in the beans? Anything Spring-related?

I'm including persistence beans into my faces beans as properties in faces-config.xml. <property-name> and . The one JSF bean that does respond quickly does not have these references, but it's also newly created. Not sure if that would matter or not.

Any thoughts would be great and we'll just live with it until future releases or faster hardware. :-)

Thanks!

It sounds like it's specific to my project.

[jboden]

Strangely enough, I went back to eclipse 3.3 with jboss richfaces vpe / jboss tools core 2.1.1 GA and it works great like it used to. First time a brief delay to compile, then fast all around. That will teach me to upgrade. :-)