Alexis Moussine-Pouchkine wrote:
> thanks Prashanth, this is useful.
>
> Note that if monitoring is not enabled, the requests fail with an NPE
> (promoted build 55):
Doesn't seem to happen in the monitoring infra. Can I see your provider
class, is this checked in?
>
>> SEVERE: service exception
>> java.lang.NullPointerException
>> at
>> org.glassfish.admin.rest.provider.TreeNodeXmlProvider.xmlForPrimitiveValue(TreeNodeXmlProvider.java:168)
>>
>> at
>> org.glassfish.admin.rest.provider.TreeNodeXmlProvider.getAttributes(TreeNodeXmlProvider.java:118)
>>
>> at
>> org.glassfish.admin.rest.provider.TreeNodeXmlProvider.getXml(TreeNodeXmlProvider.java:95)
>>
>> at
>> org.glassfish.admin.rest.provider.TreeNodeXmlProvider.writeTo(TreeNodeXmlProvider.java:87)
>>
>> at
>> org.glassfish.admin.rest.provider.TreeNodeXmlProvider.writeTo(TreeNodeXmlProvider.java:61)
>>
>> at
>> com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:254)
>>
>> at
>> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:744)
>>
>> at
>> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:667)
>>
>> at
>> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:658)
>>
>> at
>> com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service(GrizzlyContainer.java:132)
>>
>> at
>> com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:165)
>>
>> at
>> com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
>>
>> at
>> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:208)
>>
>> at
>> com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:746)
>> at
>> com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:655)
>> at
>> com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:905)
>> at
>> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:161)
>>
>> at
>> com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:136)
>>
>> at
>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)
>>
>> at
>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)
>>
>> at
>> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
>>
>> at
>> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
>>
>> at
>> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
>>
>> at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>
>> at java.lang.Thread.run(Thread.java:637)
>
> An error message suggesting to turn on monitoring would be nice.
I agree, I need to understand at what point is this happening. If this
is in the ProbeProvider, the monitoring flag has nothing to do with this.
>
> Also, are core classes monitoring loaded prior to any call?
> I see several messages at startup (even without the javaagent option)
> which seem to have an impact on startup time.
The Providers are discovered by default during the module's startup. The
retrasformation of ProbeProvider (which is the only compute-intensive
operation) will only happen when there are listeners (StatsProviders)
registered and these statsProviders are registered when the
corresponding monitoring flag is turned on. So there is no overhead when
the monitoring is turned off. We do have the Monitoring startup class
which keeps discovering the providers as they come (even without the
javaagent), this is a required step and I dont think it effects the
startup time significantly.
>
> thanks,
> -Alexis
>
> On Jul 16, 2009, at 24:52, Prashanth Abbagani wrote:
>
>> Hello,
>>
>> The monitoring in V3 is now integrated and working with several stats
>> from various module showing up. See the instructions towards the end
>> to which explain on how to view these stats.
>>
>> Following are the features of monitoring that were accomplished
>> before the soft-code freeze deadline.
>> • Monitoring Probe Providers bundled by the module owners are
>> discovered automatically and processed so probes are being fired when
>> it visits module's code path
>> • Following is done with the monitoring StatsProviders which
>> listens to the probes and updates the statistics
>> • We process the statsProviders (annotations) for the stats
>> you have annotated to be exposed
>> • Exposing the stats through CLI (asadmin)
>> • Exposing the stats with REST
>> • GUI team is working on exposing these stats for some of the
>> critical modules
>> • Integrate with Gmbal to expose these stats as JMX/AMX MBeans
>> • We also are ensuring backward compatibility for all the V2
>> level stats
>> • Handling of config changes (from CLI,GUI or REST), so the
>> stats get enabled/disabled automatically
>> • We are using BTrace as our underlying infrastructure to do the
>> byte-code instrumentation of the provider classes so the probes are
>> fired and the registered listeners (StatsProviders) are called.
>> Steps to see the monitoring in action
>>
>> You will need the BTrace agent running. You will need to start the
>> server with the following agent option (See Issue 8706, you shouldn't
>> need this step once its fixed.)
>>
>> $>java
>> -javaagent:/space/GFV3_BLD/glassfishv3/glassfish/lib/monitor/btrace-agent.jar=dumpClasses=true,unsafe=true
>> -jar glassfishv3/glassfish/modules/glassfish.jar
>>
>> To see the monitoring stats, you will have to turn on monitoring for
>> the interested modules (see the attached script to turn them all to ON)
>>
>> There are various ways to see your stats,
>> • REST - http://localhost:4848/monitoring/domain
>> • asadmin - ./asadmin get --monitor=true "*"
>> • JMX/AMX - Use JConsole to connect to 'localhost:8686'
>>
>> Let us know if you run into any issues or if you have any questions.
>>
>> thanks
>> Prashanth
>>
>>
>> #!/bin/sh
>> ./asadmin set
>> configs.config.server-config.monitoring-service.module-monitoring-levels.connector-connection-pool=HIGH
>>
>> ./asadmin set
>> configs.config.server-config.monitoring-service.module-monitoring-levels.connector-service=HIGH
>>
>> ./asadmin set
>> configs.config.server-config.monitoring-service.module-monitoring-levels.ejb-container=HIGH
>>
>> ./asadmin set
>> configs.config.server-config.monitoring-service.module-monitoring-levels.http-service=HIGH
>>
>> ./asadmin set
>> configs.config.server-config.monitoring-service.module-monitoring-levels.jdbc-connection-pool=HIGH
>>
>> ./asadmin set
>> configs.config.server-config.monitoring-service.module-monitoring-levels.jms-service=HIGH
>>
>> ./asadmin set
>> configs.config.server-config.monitoring-service.module-monitoring-levels.jvm=HIGH
>>
>> ./asadmin set
>> configs.config.server-config.monitoring-service.module-monitoring-levels.orb=HIGH
>>
>> ./asadmin set
>> configs.config.server-config.monitoring-service.module-monitoring-levels.thread-pool=HIGH
>>
>> ./asadmin set
>> configs.config.server-config.monitoring-service.module-monitoring-levels.transaction-service=HIGH
>>
>> ./asadmin set
>> configs.config.server-config.monitoring-service.module-monitoring-levels.web-container=HIGH
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>