quinta-feira, 1 de maio de 2008

Threaddumps em Java e como reportar bugs do NetBeans

Um recurso muito interessante do Java é o Threaddump. Em algumas situações, pode ser interessante saber o quê cada thread está executando (ou o que não está executando, se está esperando ;) ), e isto é possível através do comando:

kill -3

Importante: se você mandar -9, killa mesmo!

O output será algo assim:

Full thread dump Java HotSpot(TM) Client VM (1.5.0_13-119 mixed mode, sharing):

"JSP Parsing" daemon prio=1 tid=0x42c04100 nid=0x94c600 in
Object.wait() [0xb383d000..0xb383dd90]
at java.lang.Object.wait(Native Method)
- waiting on <0x0f3dbdc0> (a org.openide.windows.CloneableOpenSupport$Listener)
at java.lang.Object.wait(Object.java:474)
at org.openide.text.CloneableEdit
orSupport.openDocumentImpl(CloneableEditorSupport.java:744)
at org.openide.text.CloneableEdit
orSupport.openDocumentCheckIOE(CloneableEditorSupport.java:715)
at org.openide.text.CloneableEdit
orSupport.getDocument(CloneableEditorSupport.java:788)
- locked <0x0f3dbdc0> (a org.openide.windows.CloneableO
penSupport$Listener)
at org.openide.text.CloneableEdit
orSupport.getInputStream(CloneableEditorSupport.java:1349)
at org.netbeans.modules.web
.jspparser.ParserServletContext.getEditorInputStream(ParserServletContext.java:363)
at org.netbeans.modules.web
.jspparser.ParserServletContext.getResourceAsStream(ParserServletContext.java:326)
at org.apache.jasper.JspCompilati
onContext.getResourceAsStream(JspCompilationContext.java:304)
at org.apache.jasper.compiler
.JspUtil.getInputStream(JspUtil.java:890)
at org.apache.jasper.xmlparser
.XMLEncodingDetector.getEncoding(XMLEncodingDetector.java:127)
at org.apache.jasper.compiler
.ParserController.determineSyntaxAndEncoding(ParserController.java:360)
at org.apache.jasper.compiler
.ParserController.doParse(ParserController.java:194)
at org.apache.jasper.compiler
.ParserController.parse(ParserController.java:140)
at org.apache.jasper.compiler
.Parser.processIncludeDirective(Parser.java:374)
at org.apache.jasper.compiler
.Parser.parseIncludeDirective(Parser.java:411)
at org.apache.jasper.compiler
.Parser.parseDirective(Parser.java:554)
at org.apache.jasper.compiler
.Parser.parseElements(Parser.java:1626)
at org.apache.jasper.compiler
.Parser.parseBody(Parser.java:1880)
at org.apache.jasper.compiler
.Parser.parseOptionalBody(Parser.java:1139)
at org.apache.jasper.compiler
.Parser.parseCustomTag(Parser.java:1450)
at org.apache.jasper.compiler
.Parser.parseElements(Parser.java:1649)
at org.apache.jasper.compiler
.Parser.parse(Parser.java:165)
at org.apache.jasper.compiler
.ParserController.doParse(ParserController.java:223)
at org.apache.jasper.compiler
.ParserController.parse(ParserController.java:124)
at org.apache.jasper.compiler
.GetParseData.parse(GetParseData.java:164)
at org.netbeans.modules.web
.jspparser_ext.WebAppParseSupport$1.run(WebAppParseSupport.java:482)

"Inactive RequestProcessor thread [Was:Default RequestProcessor/null]"
daemon prio=1 tid=0x010f8e60 nid=0x91c000 in Object.wait()
[0xb8262000..0xb8262d90]
at java.lang.Object.wait(Native Method)
at org.openide.util.RequestProces
sor$Processor.run(RequestProcessor.java:939)
- locked <0x0ef58008> (a java.lang.Object)
... e por aí vai

Este output será feito no console que iniciou a aplicação, então se você utilizou um atalho do sistema para iniciar e não tiver o console, tente ver no seu sistema onde isto será escrito (no Mac, utilize o Console).
Isto pode ajudar muito desenvolvedor a achar onde está o gargalo de uma aplicação.

Aí que entra como reportar bugs do NetBeans, e foi como descobri a existência dos threaddumps.
Ao reportar um bug, e este sendo de lentidão ou travamento, sempre que possível inclua o threaddump do netbeans.