search

tietang / javamelody

Automatically exported from code.google.com/p/javamelody
0 stars 1 forks source link

Slow GUI with JBoss EAP 6.2 #406

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1.Using JBoss EAP 6.2 with Javamelody 1.50
2.Go to the javamelody GUI
3.Wait 16 seconds for loading (1 to 2 seconds with EAP 6.1), on another Server 
I have to wait over 60 seconds (before 1 to 3 seconds).

What is the expected output? What do you see instead?

It should be faster ;)

What version of the product are you using? On what application server, JDK,
operating system?

JDK 1.6, Javamelody 1.50.0, JBoss EAP 6.2

Please provide any additional information below.

This is a part of the stacktrace during GUI generation which could be the 
problem:
"ajp-/127.0.0.1:8159-6" daemon prio=5 BLOCKED
    net.bull.javamelody.TomcatInformations.buildTomcatInformationsList(TomcatInformations.java:102)
    net.bull.javamelody.JavaInformations.<init>(JavaInformations.java:142)
    net.bull.javamelody.Collector.collectLocalContextWithoutErrors(Collector.java:293)
    net.bull.javamelody.HtmlController.doHtml(HtmlController.java:88)
    net.bull.javamelody.MonitoringController.doCompressedHtml(MonitoringController.java:238)
    net.bull.javamelody.MonitoringController.doReportCore(MonitoringController.java:195)
    net.bull.javamelody.MonitoringController.doReport(MonitoringController.java:183)
    net.bull.javamelody.MonitoringController.doActionIfNeededAndReport(MonitoringController.java:141)
    net.bull.javamelody.MonitoringFilter.doMonitoring(MonitoringFilter.java:342)
    net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:172)

"javamelody pmtools-mig" daemon prio=5 RUNNABLE
    org.jboss.as.domain.management.access.ApplicationClassificationConfigResourceDefinition$ApplicationTypeConfigResource.getModel(ApplicationClassificationConfigResourceDefinition.java:160)
    org.jboss.as.controller.OperationContextImpl.createTargetAttribute(OperationContextImpl.java:935)
    org.jboss.as.controller.OperationContextImpl.authorizeResource(OperationContextImpl.java:916)
    org.jboss.as.controller.OperationContextImpl.authorizeResource(OperationContextImpl.java:105)
    org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler$CheckResourceAccessHandler.execute(ReadResourceDescriptionHandler.java:408)
    org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:601)
    org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:479)
    org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:283)
    org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:278)
    org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:231)
    org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:137)
    org.jboss.as.jmx.model.ResourceAccessControlUtil.getResourceAccess(ResourceAccessControlUtil.java:85)
    org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:48)
    org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:59)
    org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:59)
    org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:59)
    org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:59)
    org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:59)
    org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:41)
    org.jboss.as.jmx.model.ModelControllerMBeanHelper.queryNames(ModelControllerMBeanHelper.java:158)
    org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.queryNames(ModelControllerMBeanServerPlugin.java:172)
    org.jboss.as.jmx.PluggableMBeanServerImpl.queryNames(PluggableMBeanServerImpl.java:851)
    net.bull.javamelody.MBeans.getTomcatThreadPools(MBeans.java:77)
    net.bull.javamelody.TomcatInformations.initMBeans(TomcatInformations.java:136)
    net.bull.javamelody.TomcatInformations.buildTomcatInformationsList(TomcatInformations.java:103)
    net.bull.javamelody.JavaInformations.<init>(JavaInformations.java:142)
    net.bull.javamelody.Collector.collectLocalContextWithoutErrors(Collector.java:293)
    net.bull.javamelody.FilterContext$CollectTimerTask.run(FilterContext.java:56)
    java.util.TimerThread.mainLoop(Timer.java:555)
    java.util.TimerThread.run(Timer.java:505)

Original issue reported on code.google.com by robertlo...@gmail.com on 7 May 2014 at 1:47

GoogleCodeExporter commented 9 years ago 
I reproduce the issue (5 seconds and not 16 seconds or 60 seconds, but 
reproduced anyway).
The cause is that some values from Tomcat threads and processors are read in 
MBeans. Those Tomcat MBeans are read by names: "*:type=ThreadPool,*" and 
"*:type=GlobalRequestProcessor,*". But for an unknown reason, JBoss EAP 6.2 has 
changed the names of the Tomcat MBeans, so Tomcat MBeans are never found.

So, for JBoss EAP 6.2, it is needed to remember when Tomcat MBeans are not 
found, even if JBoss still uses the Tomcat container.

Original comment by evernat@free.fr on 9 Jun 2014 at 3:21

GoogleCodeExporter commented 9 years ago 
This is fixed in trunk (revision 3816) and ready for the next release (1.52).
Thanks for the issue.

If you need a snapshot before the next release, the javamelody.jar file should 
be available in continuous integration in 24h from now:
https://javamelody.ci.cloudbees.com/job/javamelody%20ant/

Original comment by evernat@free.fr on 9 Jun 2014 at 4:18