[GLASSFISH-18953] Unable to start Cluster Instances when using JDK-7 on RHEL 5 Created: 27/Jul/12  Updated: 13/May/13

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: jp2011 Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Oracle Glassfish 3.1.2.2
RHEL 5
JDK 7u4


Tags: JDK-7, JDK7, RHEL

 Description   

After upgrading from GF 3.1.2 to 3.1.2.2 on DAS, removing cluster instances and recreating them, the instances will not start using JDK 7. The following exception is seen:

<snip>

[#|2012-07-27T09:04:36.428-0400|WARNING|oracle-glassfish3.1.2|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin.cluster|_ThreadID=1570;_ThreadName=Thread-2;|Could not start instance Instance1 on node QA-Node-1 (btsqa01dfw.bot.testnet.rim.net).: Command ' /home/glassfish/glassfish3/glassfish/bin/asadmin --_auxinput - --interactive=false start-local-instance --node QA-Node-1 --sync normal Instance1' failed on node QA-Node-1 (<removed>): Waiting for Instance1 to start ......Error starting instance Instance1.
The server exited prematurely with exit code 1.
Before it died, it produced the following output:

Launching GlassFish on Felix platform
Completed shutdown of GlassFish runtime
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: java.lang.RuntimeException: javax.management.MBeanRegistrationException: Exception thrown in preRegister method
at java.lang.management.ManagementFactory.addMXBean(ManagementFactory.java:824)
at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:481)
at org.glassfish.admin.monitor.MonitoringBootstrap.setStatsProviderManagerDelegate(MonitoringBootstrap.java:227)
at org.glassfish.admin.monitor.MonitoringBootstrap.enableMonitoringForProbeProviders(MonitoringBootstrap.java:634)
at org.glassfish.admin.monitor.MonitoringBootstrap.postConstruct(MonitoringBootstrap.java:176)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:229)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:145)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:136)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:69)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
... 6 more
Caused by: javax.management.MBeanRegistrationException: Exception thrown in preRegister method
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.throwMBeanRegistrationException(DefaultMBeanServerInterceptor.java:993)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.preRegister(DefaultMBeanServerInterceptor.java:1009)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:919)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:512)
at com.sun.enterprise.v3.admin.DynamicInterceptor.registerMBean(DynamicInterceptor.java:472)
at java.lang.management.ManagementFactory$2.run(ManagementFactory.java:819)
at java.lang.management.ManagementFactory$2.run(ManagementFactory.java:815)
at java.security.AccessController.doPrivileged(Native Method)
at java.lang.management.ManagementFactory.addMXBean(ManagementFactory.java:815)
... 23 more
Caused by: javax.management.InstanceAlreadyExistsException: MXBean already registered with name java.lang:type=GarbageCollector,name=PS Scavenge
at com.sun.jmx.mbeanserver.MXBeanLookup.addReference(MXBeanLookup.java:151)
at com.sun.jmx.mbeanserver.MXBeanSupport.register(MXBeanSupport.java:160)
at javax.management.StandardMBean.preRegister(StandardMBean.java:1075)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.preRegister(DefaultMBeanServerInterceptor.java:1007)
... 32 more

Command start-local-instance failed.: To complete this operation run the following command locally on host <removed> from the GlassFish install location /home/glassfish/glassfish3:

bin/asadmin start-local-instance --node QA-Node-1 --sync normal Instance1|#]

[#|2012-07-27T09:04:36.434-0400|SEVERE|oracle-glassfish3.1.2|org.glassfish.admingui|_ThreadID=1567;_ThreadName=Thread-2;|RestResponse.getResponse() gives FAILURE. endpoint = 'https://localhost:4848/management/domain/servers/server/Instance1/start-instance'; attrs = '{}'|#]

[#|2012-07-27T09:04:36.435-0400|SEVERE|oracle-glassfish3.1.2|org.glassfish.admingui|_ThreadID=1567;_ThreadName=Thread-2;|Error in instanceAction ;
endpoint=https://localhost:4848/management/domain/servers/server/Instance1/start-instance;attrsMap=null|#]

</snip>

After downgrading java to JDK 6, everything works correctly. It should be noted that this behaviour is seen for the following JDK versions: 1.7.0_02, 1.7.0_03, 1.7.0_04, 1.7.0_05



 Comments   
Comment by kneecha [ 09/Aug/12 ]

I am having the same issue using 1.7.0_04-b20. The stack trace is basically the same except the GarbageCollector, name is different:

Caused by: javax.management.InstanceAlreadyExistsException: MXBean already registered with name java.lang:type=GarbageCollector,name=ParNew

Comment by skgaju [ 24/Aug/12 ]

workaround remove the jvm-option from all server/clusters configs
NOT from DAS config
-Djavax.management.builder.initial=com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder

Fix for this issue

bash-2.05b# svn diff src/main/java/com/sun/enterprise/admin/servermgmt/V2ToV3ConfigUpgrade.java
Index: src/main/java/com/sun/enterprise/admin/servermgmt/V2ToV3ConfigUpgrade.java
===================================================================
— src/main/java/com/sun/enterprise/admin/servermgmt/V2ToV3ConfigUpgrade.java (revision 5906)
+++ src/main/java/com/sun/enterprise/admin/servermgmt/V2ToV3ConfigUpgrade.java (working copy)
@@ -152,6 +152,7 @@
"-XX:LogFile",
};

+
// these are added to all configs
private static final String[] ADD_LIST = new String[] {
"-XX:+UnlockDiagnosticVMOptions",
@@ -169,14 +170,14 @@
"-Dfelix.fileinstall.bundles.startTransient=true",
"-Dfelix.fileinstall.disableConfigSave=false",
"-Dfelix.fileinstall.log.level=2",

  • "-Djavax.management.builder.initial=com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder",
    "-Dorg.glassfish.web.rfc2109_cookie_names_enforced=false",
    "-Djava.ext.dirs=$ {com.sun.aas.javaRoot}/lib/ext${path.separator}${com.sun.aas.javaRoot}

    /jre/lib/ext$

    {path.separator}

    $

    {com.sun.aas.instanceRoot}

    /lib/ext",
    };

// these are added to DAS only
private static final String[] ADD_LIST_DAS = new String[]

{ - "-Dosgi.shell.telnet.port=6666" + "-Dosgi.shell.telnet.port=6666", + "-Djavax.management.builder.initial=com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder" }

;

Comment by manuel_b [ 13/May/13 ]

I am also encountering this issue after upgrading our cluster nodes from Java 6 to Java 7:

..
Caused by: javax.management.InstanceAlreadyExistsException: MXBean already registered with name java.lang:type=GarbageCollector,name=Copy
at com.sun.jmx.mbeanserver.MXBeanLookup.addReference(MXBeanLookup.java:151)
at com.sun.jmx.mbeanserver.MXBeanSupport.register(MXBeanSupport.java:160)
...

I will remove the mentioned jvm property from the node configuration.

Works! Thanks for the hints here.





[GLASSFISH-14389] [BLOCKING] asadmin -m * and asadmin --monitor=true * is not working as it mention on the online --help. Created: 03/Nov/10  Updated: 18/Feb/13

Status: Reopened
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: future release

Type: Bug Priority: Critical
Reporter: Homer Yau Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
depends on GLASSFISH-14461 Extra "server." in monitoring output ... Resolved
Issuezilla Id: 14,389
Tags: added-devtest

 Description   

"asadmin -m *" and "asadmin --monitor=true *" is not working as it mention on
the online --help.

I have created a cluster instance for monitoring test and turn it to "HIGH".

-bash-3.2$ asadmin list -m *
Command list executed successfully.

-bash-3.2$ asadmin list -m=true *
Command list executed successfully.

You could see what online help says, I think it confuse user.
It says the " ./asadmin list * " to see all the monitoring element.

-bash-3.2$ asadmin list --help

User need to know the element start point and need to able to list.
The following command works.

-bash-3.2$ asadmin list -m=true monitoring-server.*
-bash-3.2$ asadmin list -m monitoring-server.*
monitoring-server :
monitoring-server.server
monitoring-server.server.applications
monitoring-server.server.applications.__default-web-module
monitoring-server.server.applications.__default-web-module.server
monitoring-server.server.applications.__default-web-module.server.default
monitoring-server.server.applications.__default-web-module.server.jsp
monitoring-server.server.applications.standalonewebmod1
monitoring-server.server.applications.standalonewebmod1.server
monitoring-server.server.applications.standalonewebmod1.server.default
monitoring-server.server.applications.standalonewebmod1.server.jsp
monitoring-server.server.applications.standalonewebmod1.server.standalonewebmod1_Servlet1
monitoring-server.server.applications.standalonewebmod1.server.standalonewebmod1_Servlet2
monitoring-server.server.applications.standalonewebmod2
monitoring-server.server.applications.standalonewebmod2.server
monitoring-server.server.applications.standalonewebmod2.server.ErrorServlet
monitoring-server.server.applications.standalonewebmod2.server.ReceiveBytes
monitoring-server.server.applications.standalonewebmod2.server.SecureServlet
monitoring-server.server.applications.standalonewebmod2.server.SendBytes
monitoring-server.server.applications.standalonewebmod2.server.default
monitoring-server.server.applications.standalonewebmod2.server.jsp
monitoring-server.server.applications.standalonewebmod2.server.standalonewebmod2_Servlet1
monitoring-server.server.applications.standalonewebmod2.server.standalonewebmod2_Servlet2
monitoring-server.server.applications.webapp1
monitoring-server.server.applications.webapp1.webapp1webmod1\.war
monitoring-server.server.applications.webapp1.webapp1webmod1\.war.server
monitoring-server.server.applications.webapp1.webapp1webmod1\.war.server.default
monitoring-server.server.applications.webapp1.webapp1webmod1\.war.server.jsp
monitoring-server.server.applications.webapp1.webapp1webmod1\.war.server.webapp1webmod1_Servlet1
monitoring-server.server.applications.webapp1.webapp1webmod1\.war.server.webapp1webmod1_Servlet2
monitoring-server.server.applications.webapp1.webapp1webmod2\.war
monitoring-server.server.applications.webapp1.webapp1webmod2\.war.server
monitoring-server.server.applications.webapp1.webapp1webmod2\.war.server.default
monitoring-server.server.applications.webapp1.webapp1webmod2\.war.server.jsp
monitoring-server.server.applications.webapp1.webapp1webmod2\.war.server.webapp1webmod2_Servlet1
monitoring-server.server.applications.webapp1.webapp1webmod2\.war.server.webapp1webmod2_Servlet2
monitoring-server.server.applications.webapp2
monitoring-server.server.applications.webapp2.webapp2webmod1\.war
monitoring-server.server.applications.webapp2.webapp2webmod1\.war.server
monitoring-server.server.applications.webapp2.webapp2webmod1\.war.server.default
monitoring-server.server.applications.webapp2.webapp2webmod1\.war.server.jsp
monitoring-server.server.applications.webapp2.webapp2webmod1\.war.server.webapp2webmod1_Servlet1
monitoring-server.server.applications.webapp2.webapp2webmod1\.war.server.webapp2webmod1_Servlet2
monitoring-server.server.applications.webapp2.webapp2webmod2\.war
monitoring-server.server.applications.webapp2.webapp2webmod2\.war.server
monitoring-server.server.applications.webapp2.webapp2webmod2\.war.server.default
monitoring-server.server.applications.webapp2.webapp2webmod2\.war.server.jsp
monitoring-server.server.applications.webapp2.webapp2webmod2\.war.server.webapp2webmod2_Servlet1
monitoring-server.server.applications.webapp2.webapp2webmod2\.war.server.webapp2webmod2_Servlet2
monitoring-server.server.web
monitoring-server.server.web.jsp
monitoring-server.server.web.request
monitoring-server.server.web.servlet
monitoring-server.server.web.session

Command list executed successfully.



 Comments   
Comment by Nazrul [ 03/Nov/10 ]

This is blocking tests execution for monitoring.

Comment by Byron Nevins [ 03/Nov/10 ]

I'm guessing that it is behaving exactly the same as V3 final release – in
which case it will be a big deal...

Comment by Byron Nevins [ 05/Nov/10 ]

"I have created a cluster instance for monitoring test and turn it to "HIGH"."

What does the above mean? How about simply copying & pasting the actual
commands you ran?

Comment by Byron Nevins [ 05/Nov/10 ]

What did you set to high?

Comment by Byron Nevins [ 05/Nov/10 ]

Output from 3.0.1

C:\glassfishv3\glassfish\bin>asadmin list -m "*"
server
server.applications
server.applications.AuthAdmin
server.applications.AuthAdmin.server
server.applications.AuthAdmin.server.AuthCreationManager
server.applications.AuthAdmin.server.AuthManager
server.applications.AuthAdmin.server.AuthUpdateManager
server.applications.AuthAdmin.server.Registrar
server.applications.AuthAdmin.server.Signup
server.applications.AuthAdmin.server.default
server.applications.AuthAdmin.server.jsp
server.applications.__default-web-module
server.applications.__default-web-module.server
server.applications.__default-web-module.server.default
server.applications.__default-web-module.server.jsp
server.http-service
server.http-service.__asadmin
server.http-service.__asadmin.request
server.http-service.server
server.http-service.server.request
server.jvm
server.jvm.class-loading-system
server.jvm.compilation-system
server.jvm.garbage-collectors
server.jvm.garbage-collectors.Copy
server.jvm.garbage-collectors.MarkSweepCompact
server.jvm.memory
server.jvm.operating-system
server.jvm.runtime
server.jvm.thread-system
server.jvm.thread-system.thread-10
server.jvm.thread-system.thread-12
server.jvm.thread-system.thread-13
server.jvm.thread-system.thread-14
server.jvm.thread-system.thread-15
server.jvm.thread-system.thread-16
server.jvm.thread-system.thread-18
server.jvm.thread-system.thread-2
server.jvm.thread-system.thread-20
server.jvm.thread-system.thread-22
server.jvm.thread-system.thread-23
server.jvm.thread-system.thread-24
server.jvm.thread-system.thread-3
server.jvm.thread-system.thread-30
server.jvm.thread-system.thread-31
server.jvm.thread-system.thread-32
server.jvm.thread-system.thread-33
server.jvm.thread-system.thread-34
server.jvm.thread-system.thread-35
server.jvm.thread-system.thread-36
server.jvm.thread-system.thread-37
server.jvm.thread-system.thread-38
server.jvm.thread-system.thread-39
server.jvm.thread-system.thread-4
server.jvm.thread-system.thread-40
server.jvm.thread-system.thread-41
server.jvm.thread-system.thread-42
server.jvm.thread-system.thread-43
server.jvm.thread-system.thread-44
server.jvm.thread-system.thread-45
server.jvm.thread-system.thread-46
server.jvm.thread-system.thread-47
server.jvm.thread-system.thread-49
server.jvm.thread-system.thread-5
server.jvm.thread-system.thread-9
server.network
server.network.admin-listener
server.network.admin-listener.connection-queue
server.network.admin-listener.file-cache
server.network.admin-listener.keep-alive
server.network.admin-listener.thread-pool
server.network.http-listener-1
server.network.http-listener-1.connection-queue
server.network.http-listener-1.file-cache
server.network.http-listener-1.keep-alive
server.network.http-listener-1.thread-pool
server.network.http-listener-2
server.network.http-listener-2.connection-queue
server.network.http-listener-2.file-cache
server.network.http-listener-2.keep-alive
server.network.http-listener-2.thread-pool
server.security
server.security.web
server.transaction-service
server.web
server.web.jsp
server.web.request
server.web.servlet
server.web.session

Command list executed successfully.

Comment by Byron Nevins [ 05/Nov/10 ]

Homer -
I know what you do NOT want it to do.

What do you WANT it to do?

====================================================

I can see exactly why you are getting the results you documented. Vijay
programmed it three months ago to do this:

Take the arg. and parse out everything before the first dot. If there is no dot
– then take the entire string. That is the server name
Then call that server and run the get command on it...

So say you give these args:

server.* --> name of server == "server"

  • --> name of remote server == "*" !!!

============

So in your case it contacts the server named "", sees that "" is not running
and returns nothing.

=========================

Comment by Byron Nevins [ 05/Nov/10 ]

I get no output from:

asadmin list -m monitoring-server.*

I'm guessing that monitoring-server is the name of a server instance you created?
Why am I guessing?

Comment by Byron Nevins [ 05/Nov/10 ]

I have no instructions on WHAT EXACTLY it should do.
I will implement solution #3 if I don't hear back soon...

asadmin list -m "*"

to do

What it does right now is very brain-dead. It blindly assumes that "*" is the
name of a server instance. So obviously that should change. But change to what?

(1) Assume the user wants a list of everything for DAS and every running server
instance. Call every instance and stick all the outputs into one big list

(2) Fail with an error saying something like "You must specify a server"

(3) *Assume* that if there is no server name that the user wants output from
DAS.

I like (3) – it knits together with 3.0.1 output the best.

Comment by Byron Nevins [ 05/Nov/10 ]

Here is how V2 handles 'get -m "*"'

case 1 – only DAS is running

C:\glassfish\bin>asadmin list -m "*"
server
server.applications
server.applications.WSTXServices
server.applications.__JWSappclients
server.applications.__JWSappclients.sys\.war
server.applications.__default-web-module
server.applications.adminapp
server.applications.admingui
server.connector-service
server.http-service
server.http-service.server
server.jms-service
server.jvm
server.orb
server.orb.connection-managers
server.resources
server.thread-pools

case 2: DAS and i1 are running

C:\glassfish\bin>asadmin list -m "*"
i1
i1.applications
i1.applications.WSTXServices
i1.applications.__JWSappclients
i1.applications.__JWSappclients.sys\.war
i1.applications.__default-web-module
i1.connector-service
i1.http-service
i1.http-service.server
i1.jms-service
i1.jvm
i1.orb
i1.orb.connection-managers
i1.resources
i1.thread-pools
server
server.applications
server.applications.WSTXServices
server.applications.__JWSappclients
server.applications.__JWSappclients.sys\.war
server.applications.__default-web-module
server.applications.adminapp
server.applications.admingui
server.connector-service
server.http-service
server.http-service.server
server.jms-service
server.jvm
server.orb
server.orb.connection-managers
server.resources
server.thread-pools

Comment by Byron Nevins [ 07/Nov/10 ]

Notice how the output is:

monitoring-server.server.applications

In V2 it would have been:

monitoring-server.applications

    • blocking bug created for this – 14461
Comment by Byron Nevins [ 07/Nov/10 ]

There used to be 5 lines of code figuring out what part of the "pattern" is
really the regular expression pattern and what part is the target. And handling
defaults, etc.

Now there is ~~ 300 lines of code doing this. It needs massive, but rapid,
testing by Homer informally at a console. E.g. here are a bunch of commands
that should all do what you would hope they would do

You have a cluster c1 with 2 instances c1i1, c1i2 and 2 stand-alone instance i1,i2

asadmin get -m "*" – get EVERYTHING from EVERY instance and DAS
asadmin get -m "server.*" - get everything from DAS
asadmin get -m "c1.*" get everything from c1i1 and c1i2
asadmin get -m "c1i1.*" get everything from c1i1
asadmin get -m "c1i1.server.*" exactly like above. ignore the "server."
asadmin get -m "." – just like ""

And on and on and on – you'll think of more!
asadmin get -m "
asadmin get -m "
asadmin get -m "

Comment by Byron Nevins [ 07/Nov/10 ]

There are 2 parts to this bug – get and list
get is now fixed.
list is next to be fixed.

Homer – get is ready for your testing!

C:\gf\v3\core\kernel>svn commit -F ..\qqq
Sending kernel\src\main\java\com\sun\enterprise\v3\admin\GetCommand.java
Sending
kernel\src\main\java\com\sun\enterprise\v3\admin\LocalStrings.properties
Adding
kernel\src\main\java\com\sun\enterprise\v3\admin\MonitoringReporter.java
Transmitting file data ...
Committed revision 42545.

Comment by Byron Nevins [ 10/Nov/10 ]

List is done now too.

Finis!

Comment by Tom Mueller [ 03/May/12 ]

Reopening this issue because the admin devtests are failing (sometimes) when the test that was written for this issue is enabled.

It appears that this is related to retrieving monitoring data from remote instances.





[GLASSFISH-20611] JAX-RS Resources Are Not Monitored Created: 06/Jun/13  Updated: 06/Jun/13

Status: Open
Project: glassfish
Component/s: jax-rs, monitoring
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: abien Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: fishcat

 Description   

Monitoring of plain JAX-RS resources does not work. JAX-RS resources do not even appear with "HIGH" monitoring level.






[GLASSFISH-11115] dtrace shouldn't list hidden probes Created: 20/Nov/09  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: V3
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: sankarpn Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC


Issuezilla Id: 11,115
Status Whiteboard:

3.1-exclude v3_exclude

Tags: ee7ri_cleanup_deferred

 Description   

Filing this as per this email conversation.

Sankar,

Can you please file a bug to track this.

thanks
Prashanth

Byron Nevins wrote:
> Agreed – yes a bug. Significant amount of work to fix it – i.e. the code
that uses ASM to generate classes at runtime for DTrace have to be changed to
not produce those hidden methods. We should report it for 3.1
>
> I already have a fix for the case where the entire ProbeProvider is all hidden
(totally ignore the entire class) – but Jerome did not approve it for post HCF
checkin.
>
>
> Prashanth Abbagani wrote:
>
>> Thats a bug, showing something to the user which doesn't work.
>>
>>
>> Byron Nevins wrote:
>>
>>> Ironically, dtrace will list all hidden probes. The will never fire into
DTrace at runtime though...
>>>
>>>
>>> Marina Vatkina wrote:
>>>
>>>> Prashanth Abbagani wrote:
>>>>
>>>>> Marina Vatkina wrote:
>>>>>
>>>>>> Prashanth Abbagani wrote:
>>>>>>
>>>>>>> I guess almost all the time, the toString() is useless for the user when
we expose the complex types. Imagine what a Throwable.toString() would mean to
them when they are sitting in front of a console. For this reason, its better to
restrict the probes to expose only the types that make sense (Primitive and
Strings).
>>>>>>>
>>>>>>> This is not the same for javascript client though, as the user can
programmatically make sense of that object.
>>>>>>
>>>>>>
>>>>>>
>>>>>> How would a javascript user know about the probes if list-probes doesn't
list them?
>>>>>
>>>>>
>>>>> The restriction of probes to be kept hidden if they are not of type
primitive, is due to the DTrace user. I am making it clear that it has no
restrictions with other clients.
>>>>
>>>>
>>>> So it's a bug that list-probes doesn't list probes mark as hidden. Is it?
>>>>
>>>>>
>>>>>>
>>>>>> thanks,
>>>>>> -marina
>>>>>>
>>>>>>>
>>>>>>> Mahesh Kannan wrote:
>>>>>>>
>>>>>>>> Interesting, then why do we have this hidden attribute?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> --Mahesh
>>>>>>>>
>>>>>>>>
>>>>>>>> Byron Nevins wrote:
>>>>>>>>
>>>>>>>>> I keep hearing that and it is /not true/. The DTrace code in
Flashlight handles any and all types.
>>>>>>>>> Of course if the class does not bother implementing toString() – a
useless String will be produced...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Marina Vatkina wrote:
>>>>>>>>>
>>>>>>>>>> Were they working? Mahesh made them hidden because dtrace can't
handle their param types (Method and Throwable).
>>>>>>>>>>
>>>>>>>>>> It also doesn't seem right not to list probes if dtrace can't handle
them.
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>> -marina
>>>>>>>>>>
>>>>>>>>>> Sankar Neelakandan wrote:
>>>>>>>>>>
>>>>>>>>>>> What happened to these probes ?. I no loner see it in list-probes
or dtrace -l.
>>>>>>>>>>> However when I register it through scripting client the probes are
fired. But not through dtrace script.
>>>>>>>>>>> Is there any changes went into these probes ?.
>>>>>>>>>>>
>>>>>>>>>>> glassfish:ejb:bean:methodEndEvent
>>>>>>>>>>> glassfish:ejb:bean:methodStartEvent
>>>>>>>>>>>
>>>>>>>>>>>
count=84,probe=glassfish:ejb:bean:methodStartEvent,appName=82487359949242370,modName=ejbsfapp1,ejbName=ejbsfapp1ejbmod1_jar,method=SFApp1EJB1
>>>>>>>>>>>
>>>>>>>>>>>
count=212,probe=glassfish:ejb:bean:methodEndEvent,appName=ejbsfapp1,modName=ejbsfapp1ejbmod1_jar,ejbName=SFApp1EJB1,exception=null,method=public
abstract
examples.monitoring.ejbapps.stateful.ejbsfapp1.ejbsfapp1ejbmod1.SFApp1EJB1
examples.monitoring.ejbapps.stateful.ejbsfapp1.
>>>>>>>>>>> ejbsfapp1ejbmod1.SFApp1EJB1Home.create(java.lang.String) throws
javax.ejb.CreateException,java.rmi.RemoteException
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> –
>>>>>>>>> Byron Nevins - Sun Microsystems, Inc.
>>>>>>>>> Home: 650-359-1290
>>>>>>>>> Cell: 650-784-4123
>>>>>>>>> Sierra: 209-295-2188
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



 Comments   
Comment by dochez [ 20/Nov/09 ]

btrace is not a supported feature of v3.

Comment by kumara [ 07/Dec/09 ]

Setting target release for unresolved issues submitted on v3 release to the next release. Not changing
issues submitted on v2.x release because they might not apply to v3.next release.

Comment by Nazrul [ 14/May/10 ]

-> Byron

Comment by Tom Mueller [ 18/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issue was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-15167] Unable to step through Flashlight Framework (probes infrastructure) code with Netbeans debugger Created: 14/Dec/10  Updated: 05/Apr/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Jennifer Chou Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude

 Description   

Set a break point in Flashlight Framework code and try to step through. It will crash.
It would be nice to be able to step through for debugging issues like
http://monaco.sfbay.sun.com/detail.jsf?cr=7004360



 Comments   
Comment by Nazrul [ 20/Dec/10 ]

Excluding from 3.1 count

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-10406] LOW level implementation Created: 19/Oct/09  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Nazrul Assignee: Jennifer Chou
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Duplicate
is duplicated by GLASSFISH-14937 Monitoring Stats for Applications and... Resolved
Issuezilla Id: 10,406
Status Whiteboard:

v3_exclude

Tags: ee7ri_cleanup_deferred

 Description   

[Tracking Bug]

Support for monitoring level LOW has been introduced in the framework. Please
take a look at how/if this has been used by the GFv3 modules.

We need to have basic monitoring of the server at LOW level such that it can be
left at LOW level for a while to diagnose a problem in production environment.
In other words, runtime performance impact of LOW level should be negligible
(1-3%).



 Comments   
Comment by Nazrul [ 20/Oct/09 ]

Getting help from Jennifer

Comment by Nazrul [ 22/Oct/09 ]

Please identify the statistics that are available at the LOW level.
Also verify dynamic reconfiguration implementation (OFF->LOW, LOW-HIGH, LOW->OFF).

Comment by Jennifer Chou [ 27/Oct/09 ]

In v2: HIGH


web-container same as LOW
jvm same as LOW, plus thread-## (ThreadInfo)
http-service same as LOW
ejb-container same as LOW, plus bean-mtehods
orb same as LOW
transaction-service same as LOW
thread-pool same as LOW
connector-connection-pool ?
connector-service ?
jdbc-connection-pool ?
jms-service ?

Should v3 be the same behavior as v2?

I'll first add the jvm stats except thread info at the LOW level (same as v2).

Comment by Jennifer Chou [ 28/Oct/09 ]

Committed fix for LOW level impl for jvm. Statistic is collected at both the
LOW and HIGH level for jvm. Additionally, thread info statistics is collected
at the HIGH level. This is the same behavior as v2.

Comment by Jennifer Chou [ 02/Nov/09 ]

Will look at other modules to support LOW in the next release.

Comment by Jennifer Chou [ 28/Oct/10 ]
      • Issue 12358 has been marked as a duplicate of this issue. ***
Comment by Chris Kasso [ 08/Dec/10 ]

Clearing Fix Version (3.1_ms7) since the issue has been excluded from 3.1.

Comment by Tom Mueller [ 18/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issue was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-11308] Need addition support for XML Probe Providers Created: 13/Dec/09  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: abbagani Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 11,308
Status Whiteboard:

3.1-exclude

Tags: ee7ri_cleanup_deferred

 Description   

Need additional monitoring infrsastructure support for ProbeProviders written in
XML. Should be able to insert the Probe in a method, towards the end of the
method, at any line number or when the method throws an exception. Currently it
only inserts at the beginning of the method.



 Comments   
Comment by Nazrul [ 14/May/10 ]

-> Byron

Comment by Tom Mueller [ 18/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issue was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-13904] Ability to register same stats provider with multiple monitoring names at the same time Created: 09/Oct/10  Updated: 05/Apr/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Jagadish Assignee: Jennifer Chou
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 13,904

 Description   

Please refer the issue 11256 where there is a need to have same statistics of
connector-connection-pool to be shown via two monitoring dotted names.
ie.,
statistics shown via :
server.resources.<CON-POOL-NAME>.*

also need to be shown as

server.connector-service.<RA-NAME>.<CON-POOL-NAME>.*
or
server.jms-service.connection-factories.<CON_FACTORY_NAME>.*
[for JMS pools]

For 3.1, I have fixed it (issue 11256) by registering two instances of
stats-provider.
It would be helpful if we could have this support from the monitoring framework
itself.
Hence raising this RFE.



 Comments   
Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-13867] implement a Probe[Sniffer|Deployer] pair Created: 07/Oct/10  Updated: 13/Dec/10

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: vince kraemer Assignee: vince kraemer
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 13,867

 Description   

see issue 13277 for info about the particulars






[GLASSFISH-13130] Allow attaching btrace scripts to server Created: 26/Aug/10  Updated: 05/Apr/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-13720 parallel issue for btrace Open
Issuezilla Id: 13,130

 Description   

Currently although GF uses btrace for its monitoring implementation, it does not
expose it to end users. In fact, the btrace agent is started in noServer mode to
avoid security risks, so one can't use btrace client to connect to server. See
[1]. At the very least, we should start the agent in server mode when debugging
is ON. We can also add a new module (not part of default distribution), which
exposes btrace to end users in one or more of the following ways:

a) have a configurable watched directory for btrace scripts,
b) have an asadmin command to attach a btrace script.

[1]
http://weblogs.java.net/blog/jjviana/archive/2010/07/14/using-btrace-glassfish-v3



 Comments   
Comment by Sanjeeb Sahoo [ 23/Mar/11 ]

I have no idea why this bug was still owned by me. Reassigning to module owner for further action.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-13781] asadmin monitor command : missing support for various values for "--type" Created: 04/Oct/10  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: v3.0.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Jagadish Assignee: Jennifer Chou
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
depends on GLASSFISH-14191 Learn Monitoring Closed
Issuezilla Id: 13,781
Tags: ee7ri_cleanup_deferred

 Description   

asadmin "monitor" CLI command :
In v3.0 and 3.1, we do not support all values of "--type" compared to v2.x :

List of valid values for --type in v2.x
http://docs.sun.com/app/docs/doc/820-4332/monitor-1?l=en&a=view

List of valid values for --type in v3
http://docs.sun.com/app/docs/doc/820-7701/monitor-1?l=en&a=view



 Comments   
Comment by Byron Nevins [ 25/Oct/10 ]

I looked into it.

The asadmin command has hard-coded support for 4 types:

webmodule
httplistener
servlet
jvm

Meantime the backend has ONLY these 4 types implemented as Contracts.

I.e. the types are determined by classes in the habitat that implement
MonitorContract.

The design is brittle. If you add a new type in the backend – then you also
have to remember to add code to support it in asadmin.

This will be a LOT of work to fix. Probably 1-2 weeks.

Comment by Byron Nevins [ 26/Oct/10 ]

Feature Creep. This is a feature that was not implemented in 3.0
Deferring to 3.2

Comment by Nazrul [ 28/Oct/10 ]

Lets look at this

Comment by Byron Nevins [ 10/Nov/10 ]

This command was practically not implemented for 3.0

Not only are there only 4 supported types. Look at the HUGE difference in output:

V3.X
cli monitor --type httplistener
ec mt pt rc
0 0 0.00 0
0 0 0.00 0
0 0 0.00 0
0 0 0.00 0
0 0 0.00 0

==========================
V2.1
~/v2/glassfish/bin>asadmin monitor --type httplistener --filter http-listener-1
server
HTTP Listener Monitoring: http-listener-1
br bs c200 c2xx c302 c304 c3xx c400 c401 c403 c404 c4xx c503 c5xx coc co
ctc ctb ec moc mst mt mtm mst pt rc
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2 0 0 0 5 5 0 2 0 0
0 6908 1 1 0 6 6 0 0 0 2 2 0 0 1 0
2 0 2 1 5 5 9 2 32 9
0 6908 1 1 0 6 6 0 0 0 2 2 0 0 0 0
2 0 2 1 5 5 9 2 32 9
0 6908 1 1 0 6 6 0 0 0 2 2 0 0 0 0
2 0 2 1 5 5 9 2 32 9
0 6908 1 1 0 6 6 0 0 0 2 2 0 0 0 0
2 0 2 1 5 5 9 2 32 9
0 6908 1 1 0 6 6 0 0 0 2 2 0 0 0 0
2 0 2 1 5 5 9 2 32 9
0 6908 1 1 0 6 6 0 0 0 2 2 0 0 0 0
2 0 2 1 5 5 9 2 32 9
0 6908 1 1 0 6 6 0 0 0 2 2 0 0 0 0
2 0 2 1 5 5 9 2 32 9
0 6908 1 1 0 6 6 0 0 0 2 2 0 0 0 0
2 0 2 1 5 5 9 2 32 9

Comment by Byron Nevins [ 10/Nov/10 ]

This command was practically not implemented for 3.0

Not only are there only 4 supported types. Look at the HUGE difference in output:

V3.X
cli monitor --type httplistener
ec mt pt rc
0 0 0.00 0
0 0 0.00 0
0 0 0.00 0
0 0 0.00 0
0 0 0.00 0

==========================
V2.1
~/v2/glassfish/bin>asadmin monitor --type httplistener --filter http-listener-1
server
HTTP Listener Monitoring: http-listener-1
br bs c200 c2xx c302 c304 c3xx c400 c401 c403 c404 c4xx c503 c5xx coc co
ctc ctb ec moc mst mt mtm mst pt rc
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2 0 0 0 5 5 0 2 0 0
0 6908 1 1 0 6 6 0 0 0 2 2 0 0 1 0
2 0 2 1 5 5 9 2 32 9
0 6908 1 1 0 6 6 0 0 0 2 2 0 0 0 0
2 0 2 1 5 5 9 2 32 9
0 6908 1 1 0 6 6 0 0 0 2 2 0 0 0 0
2 0 2 1 5 5 9 2 32 9
0 6908 1 1 0 6 6 0 0 0 2 2 0 0 0 0
2 0 2 1 5 5 9 2 32 9
0 6908 1 1 0 6 6 0 0 0 2 2 0 0 0 0
2 0 2 1 5 5 9 2 32 9
0 6908 1 1 0 6 6 0 0 0 2 2 0 0 0 0
2 0 2 1 5 5 9 2 32 9
0 6908 1 1 0 6 6 0 0 0 2 2 0 0 0 0
2 0 2 1 5 5 9 2 32 9
0 6908 1 1 0 6 6 0 0 0 2 2 0 0 0 0
2 0 2 1 5 5 9 2 32 9

Comment by Byron Nevins [ 10/Nov/10 ]

There are four and only four classes that implement the MonitorContract in 3.1

asadmin _get-habitat-info MonitorContract
C:\gf\v3\core\kernel>asadmin _get-habitat-info MonitorContract

                      • List of all services for contract named like MonitorContract
                        **************

-----------------------------
Inhabitant-Metadata:
class=org.glassfish.web.admin.monitor.statistics.WebModuleVirtualServerStatsImpl,index=org.glassfish.admin.monitor.cli.MonitorContract
Inhabitant-Metadata:
class=org.glassfish.web.admin.monitor.statistics.HTTPListenerStatsImpl,index=org.glassfish.admin.monitor.cli.MonitorContract
Inhabitant-Metadata:
class=org.glassfish.web.admin.monitor.statistics.AltServletStatsImpl,index=org.glassfish.admin.monitor.cli.MonitorContract
Inhabitant-Metadata:
class=org.glassfish.admin.monitor.jvm.statistics.JVMStatsImpl,index=org.glassfish.admin.monitor.cli.MonitorContract

Command _get-habitat-info executed successfully.

Comment by Byron Nevins [ 10/Nov/10 ]

There are four and only four classes that implement the MonitorContract in 3.1

asadmin _get-habitat-info MonitorContract
C:\gf\v3\core\kernel>asadmin _get-habitat-info MonitorContract

                      • List of all services for contract named like MonitorContract
                        **************

-----------------------------
Inhabitant-Metadata:
class=org.glassfish.web.admin.monitor.statistics.WebModuleVirtualServerStatsImpl,index=org.glassfish.admin.monitor.cli.MonitorContract
Inhabitant-Metadata:
class=org.glassfish.web.admin.monitor.statistics.HTTPListenerStatsImpl,index=org.glassfish.admin.monitor.cli.MonitorContract
Inhabitant-Metadata:
class=org.glassfish.web.admin.monitor.statistics.AltServletStatsImpl,index=org.glassfish.admin.monitor.cli.MonitorContract
Inhabitant-Metadata:
class=org.glassfish.admin.monitor.jvm.statistics.JVMStatsImpl,index=org.glassfish.admin.monitor.cli.MonitorContract

Command _get-habitat-info executed successfully.

Comment by Byron Nevins [ 10/Nov/10 ]

changing to P3 for now. It is NOT a 3.1 bug. This wasn't implemented in V3.0

This will probably have to wait for a future release but I'll keep it around for
another week or so in case there is more time to look at it.

Comment by Byron Nevins [ 05/Dec/10 ]

This isn't really a bug per se. It was unimplemented in 3.0 and remained unimplemented in 3.1

Comment by Byron Nevins [ 03/May/11 ]

getting help from jennifer

Comment by Tom Mueller [ 18/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issue was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-12175] "Count" and description not i18ned Created: 08/Jun/10  Updated: 09/Dec/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: v3.0.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: simonfojtu Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: PNG File gfv3_b19_es_06.png    
Issuezilla Id: 12,175
Status Whiteboard:

3.1-exclude

Tags: 3_1-exclude, 3_1_2-exclude

 Description   

How to reproduce:

Login Glassfish, Click Enterprise Server->Monitor->Server

Column "Value" and "Description" is in english for l10n locales (EN, DE, FR).

Version: gfv3u1 b19



 Comments   
Comment by simonfojtu [ 08/Jun/10 ]

Created an attachment (id=4414)
screenshot

Comment by gmurr [ 07/Oct/10 ]

Please reassign if this is not the correct subcomponent.
The strings are hard coded in
transaction/jta/src/main/java/com/sun/enterprise/transaction/monitoring/TransactionServiceStatsProvider.java

Comment by Byron Nevins [ 07/Oct/10 ]

reassign to owner

Comment by marina vatkina [ 07/Oct/10 ]

It's not i18-end in all statistic providers





[GLASSFISH-8889] Support for multiple probe provider names for common statistics needed Created: 26/Jul/09  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Shalini Assignee: Jennifer Chou
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 8,889
Status Whiteboard:

3.1-exclude v3_exclude

Tags: ee7ri_cleanup_deferred

 Description   

The JDBC and Connector Connection pool have same number of statistics, that
implies same logic for updating the statistics. There is no way as of now to
provide multiple probe provider names in the monitoring infrastructure. Because
of this, there would be lot of redundant code.

Something like

@ProbeProvider(providerName="glassfish",
moduleName="jdbc-connection-pool,connector-connection-pool")

or

@ProbeProviders{
@ProveProvider(providerName="glassfish", moduleName="jdbc-connection-pool"),
@ProveProvider(providerName="glassfish", moduleName="connector-connection-pool")
}

should solve the problem.



 Comments   
Comment by abbagani [ 11/Sep/09 ]

P2->P3 - the alternative is already used to implement the functionality.

Comment by Nazrul [ 28/Sep/09 ]

Will consider fixing this if there is time in this release. Otherwise, we will
look at it next release.

Comment by Byron Nevins [ 06/Oct/10 ]

Possibly...

Comment by Byron Nevins [ 05/Dec/10 ]

Did not make it into 3.1

Comment by Byron Nevins [ 25/Mar/11 ]

I don't understand what you want. If this is still an issue please go into much more detail.

Comment by Shalini [ 27/Mar/11 ]

As of now we have 2 stats providers : JdbcConnPoolStatsProvider and ConnectorConnPoolStatsProvider with AMXMetadata types "jdbc-connection-pool-mon" and "connector-connection-pool-mon" respectively. The statistics exposed by both these providers are the same. They are duplicate statistic providers with the same content. There should be a way to put the content in the same provider class. This is to avoid redundancy.

Comment by Shalini [ 06/Apr/11 ]

Assigning to the monitoring team

Comment by Byron Nevins [ 03/May/11 ]

Getting help from Jennifer.

Comment by Tom Mueller [ 18/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issue was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-15590] Regular Expression Checking not working for calculated values Created: 17/Jan/11  Updated: 18/Feb/13

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Byron Nevins Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_1-exclude, 3_1_1-scrubbed, 3_1_x-exclude

 Description   

D:\gf\v3\core\kernel>asadmin get -m server.applications.x.y\.z.server.jsp.servicetime-coun*
No monitoring data to report.

D:\gf\v3\core\kernel>asadmin get -m server.applications.x.y\.z.server.jsp.servicetime-count
server.applications.x\.y\.z.server.jsp.servicetime-count = 0

=======
The first command ought to work.



 Comments   
Comment by Byron Nevins [ 17/Jan/11 ]

Another example:
========================
D:\gf\v3\core\kernel>asadmin get -m server.applications.x.y.z.server.jsp.servicetime*

server.applications.x\.y\.z.server.jsp.dotted-name =
// lots of output removed //

============
D:\gf\v3\core\kernel>asadmin get m server.applications.x.y.z.server.jsp.servicetime*
No monitoring data to report.

Comment by Byron Nevins [ 22/Mar/11 ]

As you can see – the internal code is NOT looking at things as final strings and thus misses stuff.

Another Example

D:\>asadmin get -m server.applications.x\.y.server.jsp.servicetime*
server.applications.x\.y.server.jsp.dotted-name = server.applications.x\.y.server.jsp
server.applications.x\.y.server.jsp.servicetime-count = 0
server.applications.x\.y.server.jsp.servicetime-description = Aggregate response time
server.applications.x\.y.server.jsp.servicetime-lastsampletime = 1300811411960
server.applications.x\.y.server.jsp.servicetime-name = ServiceTime
server.applications.x\.y.server.jsp.servicetime-starttime = 1300811252183
server.applications.x\.y.server.jsp.servicetime-unit = millisecond

D:\>asadmin get m server.applications.x\.y.server.jsp.servicetime*
No monitoring data to report.

Comment by Byron Nevins [ 14/Apr/11 ]
  • Why fix this issue in 3.1.1?
    Just piping output to grep with a regular expression works. Meanwhile giving the same regular expression to the monitoring framework gets no matches at all – this reflects badly on the product.
  • Which is the targeted build of 3.1.1 for this fix?
    I have no list of builds to pick from ?!?
  • Do regression tests exist for this issue?
    Yes. There are many unit tests, dev tests and QE tests
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Homer should re-run the QE 3.1 monitoring tests
Comment by scatari [ 14/Apr/11 ]

Approved.

Comment by Byron Nevins [ 24/May/11 ]

Excluding from 3.1.1

I spent an hour looking at this. The code has "high resistance to change". It is too risky and time-consuming for 3.1.1

Also there is a very very easy work-around which is to move the star upstream.

E.g. this does not work because the "-count" is a calculated thing. There is no "real" monitoring data with that name ending in a hyphen

server.applications.HelloWeb.server.sessionstotal-*

But this works fine:

server.applications.HelloWeb.server.sessionstotal*





[GLASSFISH-6780] Monitoring Tray Icon Created: 15/Nov/08  Updated: 05/Apr/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: V3
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: mkarg Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,780
Tags: 3_1-exclude

 Description   

Lots of "native" Windows Services, like "Exchange" or "MS SQL Server" supply a
tray icon to the admin's desktop that allows to (remotely) see the "health
state" of the service. This is really nice since a tray icon is always there and
it can call for help in a simple way. So I want to suggest that GlassFish comes
with such a tray icon.

  • Shows the "health state" of the service: Could check several paramters (the
    service's "blood pressure" and "pulse"), so the admin can see whether the
    service is idle, running at it's limits, hanging or crashed, or just stopped by
    intention.
  • Shows the most essential health state information in the tool tip when the
    mouse hovers over the icon.
  • Shows a "bubble" automatically, containing alerts, when bad things have
    happened (like the server not responding anymore, IP connections broken, or
    another admin stopped the instance).
  • Has popup menu containing the most essentials commands, like "Administrate"
    (opens the browser to http://xyz:4848), "Shut Down", "Start Up".

This would be a really smart tool for the most essential operational monitoring.



 Comments   
Comment by mkarg [ 27/Apr/09 ]

This is not a bug but a feature request, so I changed the issue type from DEFECT
to FEATURE.

Comment by Tom Mueller [ 06/Jan/11 ]

User is no longer on the project. Reassigning to default assignee for monitoring.

Comment by Byron Nevins [ 07/Feb/11 ]

I'm guessing that the other platforms have something similar as well.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-7033] "asadmin monitor": Add capability to limit output fields Created: 13/Jan/09  Updated: 05/Apr/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: V3
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: rpetruzzelli Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 7,033
Tags: 3_1-exclude

 Description   

ref: "./asadmin monitor --type webmodule --interval 5 --filter //server/someurl
--user admin --passwordfile ./.pwd server"

Provide a way to limit the fields displayed when running "asadmin monitor..."
For example, Omit the "ss" field. When there are many sessions the ss listing is
too overwhelming.

--fields=asc,ash,est,jc,jec,jrc,rst,svpt,ss,sst
or maybe just:
--omitfields=ss



 Comments   
Comment by Tom Mueller [ 06/Jan/11 ]

User is no longer on the project. Reassigning to default assignee for monitoring.

Comment by Byron Nevins [ 07/Feb/11 ]

We need many changes like this for the monitor command

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-5379] asadmin in monitoring mode creates new connections with --iterations Created: 25/Jul/08  Updated: 05/Apr/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 9.1peur2
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: binujohn Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 5,379
Tags: 3_1-exclude

 Description   

During some tests with the monitoring framework using asadmin, I noticed that a
new connection is being created for each request even when --iterations flag is
set. Here is a concrete example.

I was monitoring the number of connections in the keep alive state using the
following command -

#./asadmin get -m --iterations 100 --interval 5
server.http-svice.connection-queue.countqueued-count
server.http-service.keep-alive.countconnections-count
server.http-service.keep-alive.counthits-count
server.http-service.keep-alive.counttimeouts-count

server.http-service.connection-queue.countqueued-count = 0
server.http-service.keep-alive.countconnections-count = 62
server.http-service.keep-alive.counthits-count = 298
server.http-service.keep-alive.counttimeouts-count = 0

server.http-service.connection-queue.countqueued-count = 0
server.http-service.keep-alive.countconnections-count = 63
server.http-service.keep-alive.counthits-count = 299
server.http-service.keep-alive.counttimeouts-count = 0

As you can see from the 'countconnections-count' value, every iteration is
creating a new connection. I verified this using netstat as well.

asadmin should reuse one connection in the --iterations mode, rather than create
a new connection for each request.

There are a couple of reasons for requesting this change -
1. Creating a new connection per request is inefficient and this will put more
load on the server that is being monitored.
2. The monitoring itself will skew the data that is being measured (for example
changing the interval will increase the countconnections-count). We should try
to keep the intrusive effect of monitoring as low as possible.



 Comments   
Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Tom Mueller [ 06/Jan/11 ]

User is no longer on the project. Reassigning to default assignee for monitoring.

Comment by Byron Nevins [ 07/Feb/11 ]

The "iterations" option does not exist in V3+ so this does not apply as a bug.

I'm leaving this issue alive as a new feature for 3.2

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-5165] asadmin monitor should provide a logging or batch mode Created: 16/Jun/08  Updated: 05/Apr/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 9.1peur2
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: writtmeyer Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5,165
Tags: 3_1-exclude

 Description   

I want to use "asadmin monitor" in some scripts to periodically send me some
reports. But right now there is no logging/batch mode (like e.g. "top -l 1" or
"top -n 1", depending on which top version you are using).

For a command used to monitor something I think this is essential.



 Comments   
Comment by writtmeyer [ 26/Oct/09 ]

This issue has been filed originally for v2.1. But it is still relevant for v3
(tested with promoted build b69). Thus I've changed the version to v3.

Retested as part of the FishCAT program.

Comment by janey [ 28/Feb/10 ]

reassign to bill.

Comment by Bill Shannon [ 01/Mar/10 ]

Reassign.

Comment by Tom Mueller [ 06/Jan/11 ]

User is no longer on the project. Reassigning to default assignee for monitoring.

Comment by Byron Nevins [ 07/Feb/11 ]

An improvement idea.

Perhaps the scripting client (in OGS) is what you want?

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-17886] nucleus contains javaee monitoring related code Created: 02/Dec/11  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 4.0
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: nucleus-cleanup, spo

 Description   

see files in trunk/nucleus/common/common-util/src/main/java/com/sun/enterprise/admin/monitor/callflow/



 Comments   
Comment by Sanjeeb Sahoo [ 07/Apr/12 ]

any update on when this will be fixed?





[GLASSFISH-17044] [PERF] gmbal objects consuming large part of heap Created: 13/Jul/11  Updated: 03/Dec/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1, 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Scott Oaks Assignee: Scott Oaks
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File heap-dump-gmbal-api-only.jpg     JPEG File HeapDump-gmbal-classes.jpg     File MyEjb.ear    
Issue Links:
Dependency
depends on GLASSFISH_CORBA-5 [PERF] gmbal objects consuming large ... In Progress
depends on METRO-17 [PERF] gmbal objects consuming large ... Resolved
blocks GLASSFISH-16355 startup and footprint of larger size ... Open
Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude, PSRBUG

 Description   

The gmbal related classes added in 3.x have contributed significantly to the heap regression usage for larger apps between 2.x and 3.x. In fact, now that other issues (notably 16747) have been fixed, these classes constitute almost all of the remaining regression. In a standard domain with specj deployed, the gmbal classes retain some 33MB of heap space (and the entire consumed heap space after startup is only 130MB).



 Comments   
Comment by scatari [ 26/Jul/11 ]

Targeting to be fixed in the patch release post 3.1.1.

Comment by Tom Mueller [ 18/Aug/11 ]

Scott, can you please provide details on how to recreate this issue?

Is monitoring turned on during the test?
Do you see a relatively significant amount of memory consumed by gmbal objects with a smaller application?
How did you determine the values that are quoted in the description?

Comment by Scott Oaks [ 18/Aug/11 ]

The numbers I quoted come from examining the heap dump taken after the domain has started (but not accessed); the 33MB is the size of the memory retained by the 5,619 org.glassfish.gmbal.typelib.DeclarationFactory$EvaluatedClassDeclarationImpl objects.

Monitoring options are out-of-the box settings; the only changes to the domain are to add the necessary JDBC and JMS resources for the app (which in this case is specjappserver). My understanding from Ken is that although there is a way to disable gmbal monitoring, the necessary code is not implemented at the glassfish level (it means using a different gmbal factory to get a no-op gmbal manager). Allowing that might be a good option.

We have only observed this on ejb-related deployments, not on web-only deployments. I'll have to see if we can get measurements from other apps.

Comment by Jennifer Chou [ 14/Oct/11 ]
  • If monitoring is disabled - setting mbean-enabled=false will make no difference.
  • If it is the ManagedObjectManagerFactory that is causing problems, there is only 2 places it is referenced - monitoring and web services. Since the monitoring is disabled it will not go through the code path that references ManagedObjectManagerFactory.

I tried to reproduce the issue, but was unsuccessful.

1. Download glassfish 3.1.1 open source edition
2. asadmin start-domain
3. jconsole <gf pid>
4. MBeans > com.sun.management > Operations
a. enter 'heap.dump.out' in p0
b. clicked on dumpHeap
5. Open 'heap.dump.out' in NetBeans.

I couldn't find any gmbal classes listed under Classes. I searched for 'DeclarationFactory' and 'gmbal'.

What am I missing? Do I need to have specj deployed?

Comment by Scott Oaks [ 14/Oct/11 ]

You don't need specj per se, but you need some application with EJBs deployed.

Comment by Jennifer Chou [ 14/Oct/11 ]

After deploying attached simple EJB app (with a stateless session bean), the gmbal classes can be seen in the screenshot of the heap dump list.

Comment by Jennifer Chou [ 14/Oct/11 ]

After replacing gmbal.jar with gmbal-api-only.jar, the size and number of instances is greatly reduced. See attached screenshot - heap-dump-gmbal-api-only.

gmbal-api-only.jar is downloaded from http://download.java.net/maven/2/org/glassfish/gmbal/gmbal-api-only/3.1.0-b001/gmbal-api-only-3.1.0-b001.jar

Comment by Jennifer Chou [ 14/Oct/11 ]

From Scott:

The gmbal instances are all held by the org.glassfish.gmbal.impl.ManagedObjectManagerImpl object that is held in the ORB.

There is a factory that produces a "null" maanged object manager impl instead of that ManagedObjectManagerImpl, so if we could arrange for the ORB to use that factory when we don't want the overhead of gmbal, that would solve the issue.

Comment by Jennifer Chou [ 28/Oct/11 ]

The fix should be in ORB to defer the gmbal API calls until there is a JMX client connection.

http://java.net/jira/browse/GLASSFISH_CORBA-5

Comment by Jennifer Chou [ 28/Oct/11 ]

The fix should be in metro and WebServicesContainer to defer the gmbal API call until there is a JMX client connection.

http://java.net/jira/browse/METRO-17

Comment by Jennifer Chou [ 28/Dec/11 ]

Transfer to Scott Oaks. This is an umbrella bug to track the 2 issues in ORB and Metro.

Comment by Joe Di Pol [ 18/Jan/12 ]

We've done all we plan on doing for 3.1.2 (See linked Metro bug). The ORB fix will have to wait for a subsequent release.





[GLASSFISH-17258] Determine Default Name of Probes Automatically Created: 30/Aug/11  Updated: 30/Aug/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Byron Nevins Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

@Probe
//@Probe(name = "getMovieStarted")
public void getMovieStarted(@ProbeParam("nano") long nano) {
}

=========

I tried the above code and discovered that Flashlight accepts it – but it sets the name of the probe to null!!:

JavaOne:19120-app:MovieSessionBean: (long nano)

instead of the desired:
JavaOne:19120-app:MovieSessionBean:getMovieStarted(long nano)






[GLASSFISH-17241] list-probes is not showing all probes! Created: 25/Aug/11  Updated: 26/Oct/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Byron Nevins Assignee: Jennifer Chou
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_x-exclude

 Description   

I want the 2 hours that I spent figuring this out back!

1) create these probes:

@Probe(name = "thisistorture")
public void torture(String s) {
}

@Probe(name = "thisistorture2")
public void torture(String[] ss) {
}

2) run list-probes
– the first will appear and the second will NOT. It has nothing to do with the name. Adding
@ProbeParam("nicename")
has no effect.

I finally figured this out by running MonApp – which shows that both Probes are really there.

I stepped through the Flashlight registration code. Everything worked perfectly.

String[] are a problem for list-probes.
int[] is NOT a problem



 Comments   
Comment by Jennifer Chou [ 26/Oct/11 ]

I checked that we don't have existing probes with params of String[] so 3.1.x is not affected. Added the 3_1_x-exclude tag.





[GLASSFISH-17182] Make monitoring framework completely extensible without framework changes Created: 10/Aug/11  Updated: 10/Aug/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Jennifer Chou Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-17085 Provide way to write monitoring liste... Open
depends on GLASSFISH-17166 Remove hard-coded container-specific ... Open
depends on GLASSFISH-17167 Make the monitor command generic Open

 Description   

This is an umbrella bug for removing glassfish-specific code from monitoring so monitoring can be easily extended:

GLASSFISH-17166 Remove hard-coded container-specific monitoring configuration from ModuleMonitoringLevels config bean
GLASSFISH-17167 Make the monitor command generic
GLASSFISH-17085 Provide way to write monitoring listener without modifying framework classes






[GLASSFISH-17176] New annotation @TimedProbe to probe the beginning and end of a method and calculate total time Created: 09/Aug/11  Updated: 09/Aug/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Jennifer Chou Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Commonly needed is how much time is spent in a method. Create a new @TimedProbe which does this automatically.






[GLASSFISH-17175] Add begin and end attributes to @Probe to instrument either at the beginning or end of the method. Created: 09/Aug/11  Updated: 09/Aug/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Jennifer Chou Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently probes are only instrumented at either the beginning (or end - not sure which) of the method.
Adding begin and end attributes allows more flexibility, esp. usefully in calculating processing times.



 Comments   
Comment by Byron Nevins [ 09/Aug/11 ]

The injected code is put at the BEGINNING of the method

You can verify by:

1) set AS_DEBUG=true in your environment
2) decompile and look at any of the re-written .class files in (on my machine)
D:\glassfish3\glassfish\flashlight-generated
– of course you have to look at an instrumented method that actually *has* some code!

Example 1:

public static void gc()

{ ProbeRegistry.invokeProbe(177, new Object[0]); Runtime.getRuntime().gc(); }

=================

Example 2
Deploy MonApp [1] and access it in a browser first

@Probe(name="myProbe")
public void myProbe(String arg1)
{
ProbeRegistry.invokeProbe(157, new Object[]

{ ??? }

);
String s;
System.out.println("inside myProbeMethod called with this arg: " + s);
}

[1]
Source: https://svn.java.net/svn/glassfish~svn/trunk/v2/appserv-tests/devtests/admin/cli/apps/MonApp
War file: https://svn.java.net/svn/glassfish~svn/trunk/v2/appserv-tests/devtests/admin/cli/resources/MonApp.war





[GLASSFISH-17172] Improving Monitoring Tree Created: 09/Aug/11  Updated: 09/Aug/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Jennifer Chou Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Investigate improving monitoring tree for stability (There were many regressions in 3.1).

Potentially refactor AbstractTreeNode:

  • Remove if possible "band-aid" fixes:
  • encoding/decoding
  • Better way to do pattern matching?
  • Currently, in getNodes(String pattern) the dotted name pattern is converted to regex. Code goes through the entire list of tree nodes and compares the pattern with the complete dotted name of the nodes to find the list of matching TreeNodes.

Notes:

  • A TreeNode consists of node name and whether the node is enabled. The TreeNode can also contain a method on an instance to invoke to return a Statistic object.
  • asadmin get -m (MonitoringReporter) and REST (MonitoringResource) both use the monitoring tree to display the statistics. REST uses getNode (String completeName) and get -m command uses getNodes(String pattern). REST monitoring does not take '*' wildcard like the get -m command can use. That's why they use different path to retrieve the statistics.





[GLASSFISH-17168] Improve use of '/' and '.' for the monitoring tree nodes Created: 09/Aug/11  Updated: 09/Aug/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Jennifer Chou Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

1)
Replace the subTreeRoot delimiter of '/' to something else: '.' is nice because it is used already in dotted names. Or use space, tab, newline, carriage return: " \t\n\r\f"
Compatibility issue?

2)
Allow tree node to contain '/' in the node name. No need for user to use _SLASH_. Example: register("web", "aaa.bbb.cc/d", statsProvider)

3)
Allow tree node to contain a '.' in the node name by using backlash to escape the '.'.
Example: register("web", "aaa.bbb.cc\.d", statsProvider)






[GLASSFISH-17167] Make the monitor command generic Created: 09/Aug/11  Updated: 10/Aug/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Jennifer Chou Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-17182 Make monitoring framework completely ... Open

 Description   

Current monitor command is glassfish-specific with hard-coded display headers and details for jvm, httplistener, webcontainer, servlet. Make the monitor command generic, exensible.






[GLASSFISH-17166] Remove hard-coded container-specific monitoring configuration from ModuleMonitoringLevels config bean Created: 09/Aug/11  Updated: 10/Aug/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Jennifer Chou Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-17182 Make monitoring framework completely ... Open

 Description   

This is part of Nucleus Cleanup






[GLASSFISH-17164] Add request id in the probe such that we can track a specific request in the server as it flows through various containers Created: 08/Aug/11  Updated: 08/Aug/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Jennifer Chou Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Trace a specific request from end-to-end. This is something that WebLogic already has.
We could use ThreadLocal to for the request ID.






[GLASSFISH-17165] Improve performance impact Created: 08/Aug/11  Updated: 08/Aug/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Jennifer Chou Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Performance impact is currenntly ~7%.






[GLASSFISH-17089] Uninstrument probe providers when probe listener is unregistered Created: 21/Jul/11  Updated: 21/Jul/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Jennifer Chou Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[GLASSFISH-17088] Turn on monitoring at fine-grained levels, for specific attributes Created: 21/Jul/11  Updated: 21/Jul/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Jennifer Chou Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It would be nice to turn monitoring on for just the things you are interested in. Right now you can turn on monitoring at the module level. How about just for a specific attribute?

We may look at the java logging and logging.properties for ideas.
Maybe specify in monitoring.properties:
aaa.bbb.cccc = FINE
aaa.bbb = FINER






[GLASSFISH-17085] Provide way to write monitoring listener without modifying framework classes Created: 21/Jul/11  Updated: 10/Aug/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Tom Mueller Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File XYZListener.java    
Issue Links:
Dependency
blocks GLASSFISH-17182 Make monitoring framework completely ... Open

 Description   

When writing an monitoring listener by extending the ProbeProviderEventListener class, it becomes necessary to modify the framework's ProbeClientInvokerFactory class to add a create*Invoker method that increments the AtomicInteger that is contained in that class.

This RFE is for modifying the flashlight framework so that it is possible to create a ProbeProviderEventListener and add it to the system without having to modify any of the framework classes.



 Comments   
Comment by Byron Nevins [ 21/Jul/11 ]

ProbeProviderEventListener is an interface not a class. You don't extend it you implement it.

Can you give more details?
What exactly do you want?

How about:
1) Sample Code for how you have to do it now.
2) Sample Code for how you would like to do it instead.

Comment by Tom Mueller [ 21/Jul/11 ]

Please see the attached file, XYZListener.java, for sample code that implements the ProbeProviderEventListener interface. In the probeProviderAdded method, there is a call to p.addInvoker(ProbeClientInvokerFactory.createXYZInvoker(p)

The code for the createXYZInvoker method is the following:

public static ProbeClientInvoker createXYZInvoker(FlashlightProbe probe)

{ int invokerId = clientMethodIdCounter.incrementAndGet(); return new XYZListener.XYZProbeClientInvoker(invokerId, probe); }

Maybe there is a way to get an invokerId without using the clientMethodIdCounter that is a private member of ProbeClientInvokderFactory, but I didn't see one.





[GLASSFISH-18577] list command: Too much info for instances! Created: 29/Mar/12  Updated: 29/Mar/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Byron Nevins Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File badlist.txt    

 Description   

I was investigating why weare getting Admin DevTests failures regularly with

asadmin list -m "*" (Jira14389 test)

I did the following:

create-domain
create-instance i1

    • turn on monitoring full blast **
      start-domain
      start-instance
      deploy --target i1 HelloWeb.war
      ====
      I put the output from
      asadmin list -m "*"

The list output is correct for DAS. For instance i1 there is WAY too much info. It looks like it really is showing the output from "get -m *" rather than "list -m *"






[GLASSFISH-18415] Montioring/utils: Inspect JDK 7 getMethods()/getDeclaredMethods() usage Created: 28/Feb/12  Updated: 28/Feb/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 4.0_b25
Fix Version/s: None

Type: Task Priority: Major
Reporter: Joe Di Pol Assignee: Jennifer Chou
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Recent JDK 7 releases have altered the order of methods returned by the
Class.getMethods() and Class.getDeclaredMethods() calls. The order is
no longer stable and can change from one JVM run to the next.

This caused a number of sporadic bugs to appear during 3.1.2 development
when running with JDK 7. Those have been fixed, but further inspection
of the source has found a number of cases where we use getMethods() and
getDeclaredMethods().

Each of these cases should be visually inspected to see if the code is
making any assumptions on the order of methods returned by get*Methods().
In particular it should handle the case of multiple methods having the
same name.

For more details on what to look for and how to fix it see this document:

https://wikis.oracle.com/display/GlassFish/Method+Ordering+from+Class.getMethods

Please inspect the following files for their use of getMethods() /
getDeclaredMethods() to ensure the code is not making any assumptions
with respect to the order of methods returned. Create bugs for
any issues that need to be fixed and link them to this task. Once you
have completed inspection update this task with status and close it.

Common Utilities
    CommandModelImpl.java
    GenericCommandModel.java
    ObjectAnalyzer.java
    Utility.java
GlassFish ORB connector implementation
    GenericStatsImpl.java
admin-monitoring
    StatsProviderManagerDelegateImpl.java
flashlight-framework
    DTraceMethodFinder.java
    FlashlightProbeClientMediator.java
    FlashlightProbeProviderFactory.java
    FlashlightUtils.java
    ProviderImplGenerator.java
stats77
    GenericStatsImpl.java





[GLASSFISH-18410] In the monitor logging module,the MDB can not output MethodReadyCount, LowWaterMark and HighWaterMark Created: 27/Feb/12  Updated: 27/Feb/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: v2.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lzg5039 Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows



 Description   

In the monitor logging module, the following items can be output in Stateless Session Bean, but why they cannot be output in MDB?

  • MethodReadyCount
  • LowWaterMark
  • HighWaterMark

All these items are relating to the number of EJB Instances that has been pooled.

Since both Stateless Session Bean and MDB are running by using the same Instance pooling mechanism, it is believed that the above information can also be output in MDB.

Anyhow, we still like to know the reason why the above information is not output in MDB only.
And the V3 also has the same question,please tell me the answer too.






[GLASSFISH-18935] Flashlight Uninstrumentation Created: 24/Jul/12  Updated: 24/Jul/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Byron Nevins Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Add the ability to "un-instrument" classes at run-time.






[GLASSFISH-16751] Allow Setting Monitoring Levels for Individual Instances in a Cluster Created: 27/May/11  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: V3
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Byron Nevins Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7ri_cleanup_deferred

 Description   

Currently the monitoring levels (e.g. web-container=HIGH) are part of the monitoring-service element under the config element.
All clustered instances must share the same config.

There is no reason to not allow instances to override the monitoring levels of their cluster. We just can't currently.

We should add support for doing this. Perhaps something similar to how we allow separate instances to override port numbers?



 Comments   
Comment by Tom Mueller [ 18/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issue was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-16825] If It is Impossible to Transform Classes -- Disable Monitoring Created: 08/Jun/11  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: Byron Nevins Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-next, 3_1_1-scrubbed, 3_1_x-exclude

 Description   

Very early in the process of booting up a GF Server we should check and see if it is possible to do bytecode transformation of classes. If NOT then we should :

1) if monitoring is enabled, log a SEVERE message about the problem and then disable monitoring – but just for that run. Don't persist it in domain.xml

2) if monitoring is disabled – then do nothing

In either case if the user runs "enable-monitoring" we should return a strongly worded error.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-16775] Should Validate listeners Created: 31/May/11  Updated: 31/May/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Byron Nevins Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-16755 Monitoring Invoker class not handling... Resolved

 Description   

We ought to rigorously check listeners that are added to make sure that their method signatures match the corresponding probe signatures.

Note that I have already added code that will change a primitive in the probe to a String in the listener. See 16755



 Comments   
Comment by Byron Nevins [ 31/May/11 ]

After the fact detection is fine – but it's always best to not allow such errors in in the first place.





[GLASSFISH-15930] Need an Easier way to add new Monitoring Modules Created: 09/Feb/11  Updated: 05/Apr/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Byron Nevins Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude

 Description   

See 15923

I fixed 15923 (svn 45033) to handle the "deployment" monitoring module. For 3.2 we should re-engineer the code in
MonitoringConfig.java and ContainerMonitoring.java

E.g. we could simply use reflection and the JavaBean API to get the right setter methods.



 Comments   
Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-16866] systemloadaverage not available in monitoring data Created: 15/Jun/11  Updated: 27/Jun/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: carlavmott Assignee: Jennifer Chou
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

mac, linux


Tags: 3_1-next, 3_1_1-scrubbed

 Description   

The systemloadaverage is not available in the monitoring data. We will need this as part of the elasticity work moving forward. The value returned needs to be a double. The existing code in JVMOSStatsProvider has this method commented out.



 Comments   
Comment by carlavmott [ 15/Jun/11 ]

Not sure how to make this one issue against both 3.1.1 and 3.2. It should apply to both releases.

Comment by scatari [ 27/Jun/11 ]

Enhancement.

Comment by Byron Nevins [ 27/Jun/11 ]

--> Jennifer





[GLASSFISH-21046] JMX Monitoring authentication fails when using LDAP Created: 21/Apr/14  Updated: 21/Apr/14

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ecarpenter Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The JMX Remote monitoring does not work when Glassfish is configured to use LDAP for admin authentication. Changing the "Realm Name" of the Admin Service to a file based security realm does not help either.

In our environment we have a couple of clusters managed by the same DAS. The cluster's admin-realm is still file based(the default settting) and can one monitor the instances in the clusters without a problem. It is only the DAS that is failing with an authentication error.






[GLASSFISH-21296] the value of create in MDB is worng Created: 04/Feb/15  Updated: 18/Mar/15

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lzg5039 Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

linux



 Description   

The method of MessageDrivenBeanStatsProvider'getCreateCount override the method of EjbMonitoringStatsProvider'getCreateCount,
but ManagedAttribute id of MessageDrivenBeanStatsProvider'getCreateCount is messagecount,
and return value of MessageDrivenBeanStatsProvider'getCreateCount is messageCount,
So I think the method name of MessageDrivenBeanStatsProvider is wrong.

org.glassfish.ejb.mdb.monitoring.stats.MessageDrivenBeanStatsProvider is as follows.

    @ManagedAttribute(id="messagecount")
    @Description( "Number of messages received for a message-driven bean")
    public CountStatistic getCreateCount() {
        return messageCount.getStatistic();
    }

com.sun.ejb.monitoring.stats.EjbMonitoringStatsProvider is as follows.

    @ManagedAttribute(id="createcount")
    @Description( "Number of times EJB create method is called")
    public CountStatistic getCreateCount() {
        return createStat.getStatistic();
    }


 Comments   
Comment by lzg5039 [ 04/Feb/15 ]

Modify the method name.The modified code is as follows.

The following source in the org.glassfish.ejb.mdb.monitoring.stats.MessageDrivenBeanStatsProvider

    @ManagedAttribute(id="messagecount")
    @Description( "Number of messages received for a message-driven bean")
    public CountStatistic getMessageCount() {
        return messageCount.getStatistic();
    }
Comment by zhouronghui [ 09/Feb/15 ]

Would you please give the operations and the error message?
By the way, the Title has a miss. "worng" should be "wrong".

Comment by lzg5039 [ 11/Mar/15 ]

Hi zhou

The following steps are excuted,the bug would happen
1.start imqbrokerd.
2.create jms resource.
3.write MDB APP(bussiness method print "Hello world" in server.log).
4.deploy MDB(receive jms message)
5.a client send a jms message,after MDB processed this message("Hello world" has been printed in server.log),the client send another jms message.

bug happens:
Because after MDB processed first message, the MDB receive second message, the MDB use the same instance to process first and second message.So the value of message-driven-bean-mon'createcount should be 1.But at this time use jconsole to see the value of message-driven-bean-mon'createcount which is 2.





[GLASSFISH-19722] module-monitoring-levels should not include cloud related attributes Created: 23/Feb/13  Updated: 11/Sep/14

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 4.0_b77
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Anissa Lam Assignee: srinik76
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: console

 Description   

Console's Monitoring Service page list out the attributes of module-monitoring-levels and allow user to set each one to be OFF/LOW/HIGH.
The attributes related to cloud such as cloud, cloud-account-manager, cloud-elasticity, cloud-orchestrator, shouldn't be included nor returned for GlassFish.

%~ 16) asadmin get configs.config.server-config.monitoring-service.module-monitoring-levels
configs.config.server-config.monitoring-service.module-monitoring-levels.cloud=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.cloud-account-manager=HIGH
configs.config.server-config.monitoring-service.module-monitoring-levels.cloud-elasticity=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.cloud-orchestrator=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.cloud-virt-assembly-service=HIGH
configs.config.server-config.monitoring-service.module-monitoring-levels.connector-connection-pool=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.connector-service=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.deployment=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.ejb-container=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.http-service=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.jdbc-connection-pool=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.jersey=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.jms-service=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.jpa=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.jvm=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.orb=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.security=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.thread-pool=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.transaction-service=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.web-container=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.web-services-container=OFF
Command get executed successfully.

cloud related attributes should be removed from GlassFish 4.0



 Comments   
Comment by Byron Nevins [ 24/Feb/13 ]

This was done by Suma and Srini last May

Ref:
com.sun.enterprise.config.serverbeans.ModuleMonitoringLevels

Comment by Anissa Lam [ 08/Mar/13 ]

Change the fix version to b82, MS7.
MS7 is the HCF day, 3/25.

Comment by srinik76 [ 21/Mar/13 ]

There is already a HK2 RFE raised to address this issue. (http://java.net/jira/browse/HK2-23)
Also there is a wiki page which lists outs the information this issue.

http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Nucleus+Cleanup+-+Monitoring

To fix the current issue we need to fix the above blocking issue.

Comments from Nazrul...

We should take this to a CCC meeting if we are unable to fix the HK2 RFE.

Chris/Masoud: We should explore why we are not able to fix HK2 RFE. Please schedule a meeting with HK2 team first (John Wells, Mahesh, Larry F, Tom Snyder).
After that, depending on the result, please schedule a CCC meeting and include Bill, Paul Davies, Sudipa and folks we need from Dev (Tom, Mahesh, John Wells).

Thanks.

Comment by Anissa Lam [ 02/Apr/13 ]

I have added a filter in the GUI code to filter out any modules that starts with "cloud".
Log Message:
------------
work around for GLASSFISH-19722. hide cloud modules for monitoring level screen.

Revisions:
----------
61083

Modified Paths:
---------------
trunk/main/appserver/admingui/common/src/main/java/org/glassfish/admingui/common/handlers/MonitoringHandlers.java

When this bug is fixed, the workaround should be removed as it is not needed.

Comment by Anissa Lam [ 08/Apr/13 ]

Since i have put in the workaround for the console by filtering out the cloud* container name, the actual fix of this bug can be deferred to after 4.0.
I am changing the target to 4.1.

Comment by Anissa Lam [ 26/Apr/13 ]

I saw that Srini added "4_0-release-notes" to the tag.
Do we really need to release note this, how does the release note help our users ?
With the work around, user will not see the cloud related monitoring level in the console, they will only see it exists by using CLI get and then set it.
Setting it doesn't give any error and user will not notice any problem as they won't see cloud related monitoring anyway.

I feel that adding this to the release note is just going to prevent user to easily see issues that they should be aware of.

Comment by srinik76 [ 29/Apr/13 ]

As per anissa's comment i am removing the tag on 4_0_release_notes





[GLASSFISH-19500] Asadmin get --monitor returns remote failure when dynamic-reconfiguration-enabled=false Created: 08/Jan/13  Updated: 08/Jan/13

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tesgoran Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Red Hat Linux 6.3



 Description   

I've several clusters with dynamic-reconfiguration-enabled=false.
When I use asadmin get --monitor to monitorize one instance I got "remote failure:" error.
But if I enable dynamic reconfiguration on a cluster I get the statistics for the resources of the instance.
I prefer not to enable dynamic reconfiguration on my clusters.
Is possible to monitorize the instances without dynamic-reconfiguration?

The steps to reproduce the problem:

  • Create "test" cluster with dynamic-reconfiguration-enabled=false
  • Create "test01" instance in "test" cluster.
  • asadmin get --monitor "test01.*" -> Remote failure: error
  • asadmin set test-config.dynamic-reconfiguration-enabled=true
  • asadmin get --monitor "test01.*" -> OK.


 Comments   
Comment by Tom Mueller [ 08/Jan/13 ]

Assigning to the monitoring component.





[GLASSFISH-20498] Monitoring: misleading message or failure to register probe misses important data Created: 10/May/13  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 4.0_b88_RC4
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: marina vatkina Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See GLASSFISH-19677 - the failed probe registration reports the probe class, not the actual failure:

WARNING: MNTG0201:Flashlight listener registration failed for listener class : com.sun.ejb.monitoring.stats.StatelessSessionBeanStatsProvider , will retry later

The actual cause is available only at FINE level:

FINE: Listener registration failed
java.lang.RuntimeException: Probe is not yet registered: glassfish:ejb:bean_null_MonTest_TestBean:methodEndEvent

But the actual probes are registered fine...



 Comments   
Comment by Terry2013 [ 31/Dec/14 ]

Hi Romain , Marina
I have reproduced the issue on the latest GlssfishV4.
I investigated a bit of source code , and found the logic in ejb-container is very odd.

com.sun.ejb.containers.BaseContainer
protected void createMonitoringRegistry() {
            //Please disregard the above code

            ejbProbeListener = getMonitoringStatsProvider(appName, modName, ejbName);
            ejbProbeListener.addMethods(getContainerId(), appName, modName, ejbName, getMonitoringMethodsArray());
            ejbProbeListener.register();★1

            if (_logger.isLoggable(Level.FINE)) {
	        _logger.log(Level.FINE, "Created MonitoringRegistry: " + 
                        EjbMonitoringUtils.getDetailedLoggingName(appName, modName, ejbName));
            }
	} catch (Exception ex) {
	    _logger.log(Level.SEVERE, COULD_NOT_CREATE_MONITORREGISTRYMEDIATOR, new Object[]{EjbMonitoringUtils.getDetailedLoggingName(appName, modName, ejbName), ex});
	}

        // Always create to avoid NPE
        try {
            ProbeProviderFactory probeFactory = ejbContainerUtilImpl.getProbeProviderFactory();
            String invokerId = EjbMonitoringUtils.getInvokerId(appName, modName, ejbName);
            ejbProbeNotifier = probeFactory.getProbeProvider(EjbMonitoringProbeProvider.class, invokerId);★2
            if (_logger.isLoggable(Level.FINE)) {
                _logger.log(Level.FINE, "Got ProbeProvider: " + ejbProbeNotifier.getClass().getName());
            }
        } catch (Exception ex) {
            ejbProbeNotifier = new EjbMonitoringProbeProvider();
            if (_logger.isLoggable(Level.FINE)) {
                _logger.log(Level.FINE, "Error getting the EjbMonitoringProbeProvider");
            }
        }

    }

In my understanding , Monitoring in GlassFish V4 need to register ProbeProvider and StatsProvider.
And StatProvider depend on ProbeProvider.So I think StatProvider's registration need after ProbeProvider's.
But in ejb container , StatProvider's registration (★1) is before ProbeProvider's(★2).
So the MNTG0201 message is output .

By the way,After I change ProbeProvider and ProbeProvider registration order, the MNTG0201 message is not output .

Comment by lzg5039 [ 20/Jan/15 ]

Hi Romain , Marina ,Terry2013

there is same probelm in the com.sun.ejb.containers.StatefulSessionContainer.registerMonitorableComponents
★2 order to register before ★1

 protected void registerMonitorableComponents() {
        super.registerMonitorableComponents();
        cacheProbeListener = new EjbCacheStatsProvider(sessionBeanCache,
                getContainerId(), containerInfo.appName, containerInfo.modName,
                containerInfo.ejbName);
        cacheProbeListener.register();★1

        try {
            ProbeProviderFactory probeFactory = ejbContainerUtilImpl.getProbeProviderFactory();
            String invokerId = EjbMonitoringUtils.getInvokerId(containerInfo.appName,
                    containerInfo.modName, containerInfo.ejbName);
            cacheProbeNotifier = probeFactory.getProbeProvider(EjbCacheProbeProvider.class, invokerId);★2
            if (_logger.isLoggable(Level.FINE)) {
                _logger.log(Level.FINE, "Got ProbeProvider: " + cacheProbeNotifier.getClass().getName());
            }
        } catch (Exception ex) {
            cacheProbeNotifier = new EjbCacheProbeProvider();
            if (_logger.isLoggable(Level.FINE)) {
                _logger.log(Level.FINE, "Error getting the EjbMonitoringProbeProvider");
            }
        }

        if (isHAEnabled) {
            sfsbStoreMonitor = new HAStatefulSessionStoreMonitor();
        } else {
            sfsbStoreMonitor = new StatefulSessionStoreMonitor();
        }
        sessionBeanCache.setStatefulSessionStoreMonitor(sfsbStoreMonitor);
        _logger.log(Level.FINE, "[SFSBContainer] registered monitorable");
    }

There is an another problem in the org.glassfish.persistence.ejb.entitybean.container.registerMonitorableComponents.
There is not EjbCacheProbeProvider in the registerMonitorableComponents(),but EjbCacheStatsProvider depends on the EjbCacheProbeProvider .
So I think it needs to register EjbCacheProbeProvider before ★1.

  protected void registerMonitorableComponents() {
        super.registerMonitorableComponents();
	if (readyStore != null) {
	    int confMaxCacheSize = cacheProp.maxCacheSize;
	    if (confMaxCacheSize <= 0) {
		confMaxCacheSize = Integer.MAX_VALUE;
	    }
	    this.cacheStatsProvider = new EntityCacheStatsProvider(
		    (BaseCache) readyStore, confMaxCacheSize);
	    //registryMediator.registerProvider(cacheStatsProvider);
            cacheProbeListener = new EjbCacheStatsProvider(cacheStatsProvider,
                    getContainerId(), containerInfo.appName, containerInfo.modName,
                    containerInfo.ejbName);
            cacheProbeListener.register();★1
	}
        poolProbeListener = new EjbPoolStatsProvider(entityCtxPool, 
                getContainerId(), containerInfo.appName, containerInfo.modName,
                containerInfo.ejbName);
        poolProbeListener.register();
        _logger.log(Level.FINE, "[Entity Container] registered monitorable");
    }





[GLASSFISH-20529] No easy way to specify LOW/HIGH monitoring level Created: 14/May/13  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: marina vatkina Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There is no simple/declarative way to specify if the probe is available at LOW or HIGH monitoring level



 Comments   
Comment by Byron Nevins [ 14/May/13 ]

Research notes

> StatsProviderInfo has the info for a stats provider. It had the levels hacked into it later. So the constructor doesn't accept levels. The only way to set the level is to literally call the setter method at the exact right moment during registration.
>

That class is in GMBAL

hg clone https://hg.java.net/hg/gmbal~gf_common

Tip --> hunt around for StatsProviderInfo string and setConfigLevelk(sp?)

=====================

Comment by Byron Nevins [ 14/May/13 ]

More notes from an email thread:

Here it is:

public void registerStatsProvider(StatsProviderInfo spInfo) {
String configLevelStr = spInfo.getConfigLevel();

if (configLevelStr == null)

{ // Pick the highest in the configLevels spInfo.setConfigLevel(defaultConfigLevels[defaultConfigLevels.length-1]); }

==============

i.e. the StatsProviderInfo holds the config level (LOW or HIGH). Unfortunately that code is in GMBAL which I don't have right now.

If your code has something derived from StatsProviderInfo you can call setConfigLevel("LOW")





[GLASSFISH-20813] ConcurrentModificationException in GrizzlyService when booting GlassFish Created: 16/Sep/13  Updated: 17/Sep/13

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jwells Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

On approximately 1 in 10 boots of GlassFish I get the following exception:

Shutting down server due to startup exception
java.util.ConcurrentModificationException
at java.util.Vector$Itr.checkForComodification(Vector.java:1156)
at java.util.Vector$Itr.next(Vector.java:1133)
at org.glassfish.external.probe.provider.StatsProviderManager.unregister(StatsProviderManager.java:100)
at com.sun.enterprise.v3.services.impl.monitor.GrizzlyMonitoring.registerThreadPoolStatsProvider(GrizzlyMonitoring.java:145)
at com.sun.enterprise.v3.services.impl.GlassfishNetworkListener.registerMonitoringStatsProviders(GlassfishNetworkListener.java:279)
at com.sun.enterprise.v3.services.impl.GlassfishNetworkListener.start(GlassfishNetworkListener.java:106)
at com.sun.enterprise.v3.services.impl.GrizzlyProxy.start0(GrizzlyProxy.java:267)
at com.sun.enterprise.v3.services.impl.GrizzlyProxy.start(GrizzlyProxy.java:241)
at com.sun.enterprise.v3.services.impl.GrizzlyService.createNetworkProxy(GrizzlyService.java:567)
at com.sun.enterprise.v3.services.impl.GrizzlyService.postConstruct(GrizzlyService.java:490)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:298)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:345)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:454)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:200)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2296)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:951)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:936)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)



 Comments   
Comment by oleksiys [ 17/Sep/13 ]

It's not related to Grizzly. Looks like it's monitoring (gmbal) related issue.





[GLASSFISH-20612] Meaningless Warnings In Log File Created: 06/Jun/13  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 4.0_b89_RC5
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: abien Assignee: Byron Nevins
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: fishcat

 Description   

Deployment of a Stateless Session Bean causes:

WARNING: Flashlight listener registration failed for listener class: com.sun.ejb.monitoring.stats.StatelessSessionBeanStatsProvider , will retry later

Deployment of a Singlet Bean causes:

WARNING: Flashlight listener registration failed for listener class: com.sun.ejb.monitoring.stats.SingletonBeanStatsProvider , will retry later

(Not tested with SFSB)

The same warnings already appeared on GF v3



 Comments   
Comment by Hong Zhang [ 06/Jun/13 ]

As these messages are from ejb monitoring probes, assign to ejb team for evaluation.

Comment by marina vatkina [ 06/Jun/13 ]

The warning comes from Flashlight code. EJB container can't do much about it.

Comment by ymajoros [ 20/Jun/13 ]

Looks like a duplicate of https://java.net/jira/browse/GLASSFISH-19677





[GLASSFISH-19254] WARNING Error during registration of FlashlightProbe java.lang.RuntimeException: JSR/RET are not supported with computeFrames option Created: 29/Oct/12  Updated: 29/Oct/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tvlatas Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux host 2.6.18-308.0.0.0.1.el5xen #1 SMP Sat Feb 25 16:26:29 EST 2012 x86_64 x86_64 x86_64 GNU/Linux
java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) Server VM (build 23.3-b01, mixed mode)



 Description   

I'm seeing a probe that is failing to be transformed by Flashlight:

[#|2012-10-29T07:34:24.441-0700|WARNING|44.0|javax.enterprise.system.tools.monitor|_ThreadID=1;_ThreadName=main;_TimeMillis=1351521264441;_LevelValue=900;_MessageID=NCLS-MON-0508;|Error during registration of FlashlightProbe
java.lang.RuntimeException: JSR/RET are not supported with computeFrames option
at org.objectweb.asm.Frame.execute(Frame.java:1159)
at org.objectweb.asm.MethodWriter.visitJumpInsn(MethodWriter.java:873)
at org.objectweb.asm.ClassReader.accept(ClassReader.java:1316)
at org.glassfish.flashlight.impl.client.ProbeProviderClassFileTransformer.transform(ProbeProviderClassFileTransformer.java:247)
at sun.instrument.TransformerManager.transform(TransformerManager.java:188)
at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:424)
at sun.instrument.InstrumentationImpl.retransformClasses0(Native Method)
at sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:144)
at org.glassfish.flashlight.impl.client.ProbeProviderClassFileTransformer.transform(ProbeProviderClassFileTransformer.java:180)
at org.glassfish.flashlight.impl.client.ProbeProviderClassFileTransformer.transformAll(ProbeProviderClassFileTransformer.java:121)
at org.glassfish.flashlight.impl.client.FlashlightProbeClientMediator.transformProbes(FlashlightProbeClientMediator.java:208)
at com.oracle.diagnostics.flightrecorder.impl.listener.JfrListener.evaluateProbeAndEventSettings(JfrListener.java:208)

Here is the probe it choked on:

Class: com.sun.mail.smtp.SMTPTransport
Probes: sendMessageStart::(Ljava/lang/String;)V
moduleprovidername: glassfish
modulename: javamail
probename: sendMessageStart

Looking at SMTPTransport, it is a V1.4 class with JSR/RET instructions being used there (ie: old style try/finally handling). The fix here would either be to have Flashlight not compute the frames for older version classes, or run the JSRInlinerAdapter across it to remove those usages (ie: so compute_frames won't choke on it). Note that JSRInlinerAdapter adds to the overhead, so probably want to conditionalize handling that for older classes only (ie: either way, conditionalize using compute_frames or conditionalize using the JSRInlinerAdapter)






[GLASSFISH-19416] the value of monitor becomes negative value Created: 07/Dec/12  Updated: 13/Dec/13

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jifeng Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File JdbcConnPoolSatasProvider.patch     PNG File numConnFree.PNG    

 Description   

I execute under two commands:
1.set resources.jdbc-connection-pool.oracle_pool.pooling=false
2.enable-monitoring --modules jdbc-connection-pool=HIGH

then I get three jdbc connections from oracle_pool by my application.
at this time I find the value of "numconnfree-current" which become negative value



 Comments   
Comment by jifeng [ 07/Dec/12 ]

I think the code which is marked as "★" has problem
because there is no connection in the pool when the state of pool is unpooling

ConnectionPool.java

public String internalGetResource()
{   
    ........
    if (result != null) {
     if (maxConnectionUsage_ > 0) {
           result.incrementUsageCount();
     }
     if (poolLifeCycleListener != null) {
           poolLifeCycleListener.connectionUsed(result.getId());
          //Decrement numConnFree
          poolLifeCycleListener.decrementNumConnFree(); "★" 
     }
    }
}
Comment by jifeng [ 07/Dec/12 ]

I create a patch and it works fine, cloud you please confirm it.

Comment by jifeng [ 07/Dec/12 ]

I modify this method : JdbcConnPoolSatasProvider#decrementNumConnFreeEvent

Comment by jifeng [ 01/Aug/13 ]

Hi:

Byron Nevins

I find This phenomenon also occurs in glassfish v4 .

I added one line of code which is marked as "★" , and it works fine.

com.sun.enterprise.resource.pool.monitor.JdbcConnPoolStatsProvider.java
@ProbeListener(JDBC_PROBE_LISTENER + "decrementNumConnFreeEvent")
    public void decrementNumConnFreeEvent(
        @ProbeParam("poolName") String poolName,
        @ProbeParam("appName") String appName,
        @ProbeParam("moduleName") String moduleName
     ) {
     ......
        synchronized(numConnFree) {
            long numConnFreeToSet = (numConnFree.getCurrent() - 1 >= 0) ? numConnFree.getCurrent() - 1 : 0;★
            numConnFree.setCurrent(numConnFreeToSet);
        }
     }
    }

could you please confirm it and give me some suggestions?

Comment by boernd [ 13/Dec/13 ]

Hi,

we also got this phenomenon of negative values (gf 3.1.2.2) with the numConnUsed count. I changed the decrementConnectionUsedEvent method the same way:

            //Decrement numConnUsed counter
            synchronized(numConnUsed) {
                long numConnUsedToSet = (numConnUsed.getCurrent() - 1 >= 0) ? numConnUsed.getCurrent() - 1 : 0;                
                numConnUsed.setCurrent(numConnUsedToSet);
            }




[GLASSFISH-19404] "get --monitor server.transaction-service.activeids-current" does not work when tx monitor-level is set to LOW (both standalone instance and clustered instance) Created: 05/Dec/12  Updated: 05/Dec/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Wu Jie Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File parentTreeNode.png     Text File StatsProviderRegistry.patch    
Tags: jts

 Description   

when tx monitor-level is set to LOW by the commands below.
"enable-monitoring --modules transaction-service"
or
"set monitoring-service.module-monitoring-levels.transaction-service"

It could not get any inflight transaction info by the following command
"get --monitor server.transaction-service.activeids-current"



 Comments   
Comment by Wu Jie [ 05/Dec/12 ]

there is the same phenomenon on admin gui.

Comment by Wu Jie [ 05/Dec/12 ]

when execute "get --monitor server.transaction-service.activeids-current" ,
it will run into com.sun.enterprise.v3.admin.MonitoringReporter#runLocally() as listing in below.

    private void runLocally() {

        // don't run if this is DAS **and** DAS is not in the server list.
        // otherwise we are in an instance and definitely want to run!
        if (isDas() && !dasIsInList())
            return;

        // say the pattern is "something" -->
        // we want "server.something" for DAS and "i1.server.something" for i1
        // Yes -- this is difficult to get perfect!!!  What if user entered
        //"server.something"?

        String localPattern = prependServerDot(pattern);
        org.glassfish.flashlight.datatree.TreeNode tn = datareg.get(serverEnv.getInstanceName());

        if (tn == null) {
            // No monitoring data, so nothing to list
            // officially this is considered a "success"
            setSuccess(Strings.get("admin.get.monitoring.empty"));
            return;
        }

        List<org.glassfish.flashlight.datatree.TreeNode> ltn = tn.getNodes(localPattern);
        boolean singleStat = false;

        if (ltn == null || ltn.isEmpty()) {
            org.glassfish.flashlight.datatree.TreeNode parent = tn.getPossibleParentNode(localPattern);

            if (parent != null) {★
                ltn = new ArrayList<org.glassfish.flashlight.datatree.TreeNode>(1);
                ltn.add(parent);
                singleStat = true;
            }
        }

        if (!singleStat)
            localPattern = null; // signal to method call below.  localPattern was already used above...

        if (outputType == OutputType.GET)
            doGet(localPattern, ltn);
        else if (outputType == OutputType.LIST)
            doList(localPattern, ltn);

        if (plainReporter != null) {
            plainReporter.appendMessage(cliOutput.toString());
        }
    }

when tx monitor-level is HIGH, the parent TreeNode that is marked as "★" above is not null, which has value as the attached file "parentTreeNode.png".
but the parent TreeNode is null when tx monitor-level is LOW.

It seems that the transaction info is not registered into TreeNode(MonitoringRuntimeDataRegistry?) ...

Comment by marina vatkina [ 05/Dec/12 ]

"set monitoring-service.module-monitoring-levels.transaction-service" is not turning monitoring on, you should explicitly set it to LOW or HIGH

This is the code that turns monitoring on/off is:

           if (event.getSource() instanceof ModuleMonitoringLevels) {
                if (eventName.equals(ServerTags.TRANSACTION_SERVICE)) {
                    String newlevel = newValue.toString();
                    _logger.log(Level.FINE, "Changing transaction monitoring level");
                    if ("OFF".equals(newlevel)) {
                        tm.setMonitoringEnabled(false);
                    } else if ("LOW".equals(newlevel) || "HIGH".equals(newlevel)) {
                        tm.setMonitoringEnabled(true);
                    }
                } // else skip

So no value is considered as a no-op

Comment by Wu Jie [ 05/Dec/12 ]

I got the difference between "set monitoring-service.module-monitoring-levels.transaction-service" and "enable-monitoring --modules transaction-service".
but this issue is not related to the source above which is the segment of TransactionServiceConfigListener.

I observed that there is some difference between OFF->HIGH and OFF->LOW
when I change tx monitoring level from OFF to HIGH.
the runtime will run along the route as below.

Daemon Thread [pool-130-thread-1] (Suspended)
TransactionServiceStatsProvider.getActiveIds() line: 135
GeneratedMethodAccessor130.invoke(Object, Object[]) line: not available
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
Method.invoke(Object, Object...) line: 601
MethodInvokerImpl.getValue() line: 90
StatsProviderManagerDelegateImpl.resetChildNodeStatistics(String, List<String>, String) line: 556
StatsProviderManagerDelegateImpl.resetStatistics(StatsProviderRegistry$StatsProviderRegistryElement) line: 539
StatsProviderManagerDelegateImpl.enableStatsProvider(StatsProviderRegistry$StatsProviderRegistryElement) line: 389
StatsProviderManagerDelegateImpl.enableStatsProviders(String) line: 329
MonitoringBootstrap.handleLevelChange(String, String) line: 569
MonitoringBootstrap.changed(PropertyChangeEvent[]) line: 521
Transactions$ConfigListenerJob.process(ConfigListener) line: 401
Transactions$ConfigListenerJob.process(Object) line: 391
Transactions$ConfigListenerNotifier$1$1.call() line: 281
Transactions$ConfigListenerNotifier$1$1.call() line: 279
FutureTask$Sync.innerRun() line: 334
FutureTask<V>.run() line: 166
ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1110
ThreadPoolExecutor$Worker.run() line: 603
Thread.run() line: 722

but the situation which is OFF->LOW does not run the route above.

and look into related source, I doubt the source as following(org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl).

    public void enableStatsProviders(String configElement) {
        //If monitoring-enabled is false, just return
        if (!getMonitoringEnabled())
            return;
        String configLevel = getMonitoringLevel(configElement);
        //Enable all the StatsProviders for a given configElement
        if (logger.isLoggable(Level.FINE))
            logger.fine("Enabling all the statsProviders for - " + configElement);
        List<StatsProviderRegistryElement> spreList = statsProviderRegistry.getStatsProviderRegistryElement(configElement);
        if (spreList == null)
            return;
        for (StatsProviderRegistryElement spre : spreList) {
            //Check to see if the enable is allowed
            // Not allowed if statsProvider is registered for Low and configLevel is HIGH
            boolean isEnableAllowed = spre.isEnableAllowed(configLevel);★
            if (!spre.isEnabled()) {
                //OFF->LOW, OFF->HIGH
                if (isEnableAllowed) {
                    enableStatsProvider(spre);
                }
            }
            else {
                //Disable if the stats were enabled, but current level is not allowed for these stats(HIGH->LOW) and
                // stats were registered at HIGH
                if (!isEnableAllowed) {
                    disableStatsProvider(spre);
                }// else, Dont do anything LOW->HIGH (stats were registered at LOW)
            }
        }
    }

the "isEnableAllowed" which is marked as "★" will be false in the situations as below.
・OFF->LOW
・HIGH->LOW

I think is there any wrong with the style.
and the "isEnableAllowed" should be true when OFF->LOW.

Comment by marina vatkina [ 05/Dec/12 ]

If this is the case, the error is in monitoring code.

Comment by Wu Jie [ 05/Dec/12 ]

the logic of "isEnableAllowed" is abstracted from org.glassfish.admin.monitor.StatsProviderRegistry as following:

        public boolean isEnableAllowed(String userConfigLevelStr) {
            Integer userConfigLevel = StatsProviderRegistry.configLevelsMap.get(userConfigLevelStr.toUpperCase());
            if ((userConfigLevel != null) && (userConfigLevel >= configLevel))//※the value of configLevel is always "1" which equals to "HIGH"
                return true;
            return false;
        }

※the value of configLevel is always "1" which equals to "HIGH" which related to the following source.

    static final String[] defaultConfigLevels = new String[] {"LOW","HIGH"};
    public static final Map<String, Integer> configLevelsMap = new ConcurrentHashMap();

    public StatsProviderRegistry(MonitoringRuntimeDataRegistry mrdr) {
        this.mrdr = mrdr;
        for (int i = 0; i < defaultConfigLevels.length; i++) {
            configLevelsMap.put(defaultConfigLevels[i].toUpperCase(), i);
        }
    }

    public void registerStatsProvider(StatsProviderInfo spInfo) {
        String configLevelStr = spInfo.getConfigLevel();

        if (configLevelStr == null) {
            // Pick the highest in the configLevels
            spInfo.setConfigLevel(defaultConfigLevels[defaultConfigLevels.length-1]);//★
        }

        StatsProviderRegistryElement spre =
                    new StatsProviderRegistryElement(spInfo);
        initialize(spre, spInfo.getConfigElement(), spInfo.getStatsProvider());
    }

the source which marked as "★" set the configLevelStr to "HIGH".

as the logic above, the "isEnableAllowed" returns false regardless of OFF->LOW or HIGH->LOW.
and I think the src logic may be modified as below.
① set configLevelStr to "LOW" as initial value.
② change the StatsProviderInfo#configLevel when monitoring level has been changed(LOW or HIGH).

Comment by Wu Jie [ 05/Dec/12 ]

I create a patch and it works fine. cloud you please confirm it.





[GLASSFISH-5979] Lack Of CallFlow Monitoring Created: 07/Sep/08  Updated: 05/Apr/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: V3
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: abien Assignee: Byron Nevins
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: other
Platform: All


Issuezilla Id: 5,979

 Description   

Server: Glassfish v3 b23

In GF v2 CallFlow was a convenient way to easily debug and monitor the
application. GF v3 is lacking such "lightweight" functionality. At least a
call-tree should be visible in the console as well as "slowest" methods.

The monitoring features of GF v2 were unique comparing it to other, opensource
application servers...



 Comments   
Comment by Tom Mueller [ 06/Jan/11 ]

User is no longer on the project. Reassigning to default assignee for monitoring.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-5875] Watch out for http requests that are not accepted in time Created: 04/Sep/08  Updated: 05/Apr/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: v2.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: kohsuke Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 5,875
Tags: 3_1-exclude

 Description   

I'm not sure whether this should be under Grizzly or monitoring.

A trouble-shooting session with the internal customer of GlassFish (JavaFX)
revealed that one typical failure mode of GlassFish is the exhaustion of HTTP
request processing threads.

This can happen for a number of reasons, with a varying degree of consequences.
For example, if the # of request processing threads are too low (the system in
question had only 5 threads on a 4 core system), then it will cause GlassFish to
slow down.

Or if the web application has some problem and the request processing thread
never comes back (for example, it can be blocked during a processing on infinite
Object.wait() or dead lock), then GlassFish will eventually run out of all the
HTTP request threads, and GlassFish will look as if it hanged.

The problem here is that GlassFish doesn't provide any useful information to
point the system admin to the right direction, and it took someone from the
GlassFish team (namely, me) to look at it to figure out what's going on. This is
clearly undesirable.

So the RFEs here are two folds:

1. watch out for average delay an accepted socket connection is picked up by a
request handling thread. If it's longer than a certain threshold (say 1sec) and
if the # of HTTP request threads is too low compared to # of CPUs, then let the
admin know that there is a potential bottleneck.

2. if an accepted socket connection sits in the queue for too long, reject the
request and issue an error.

3. if no HTTP request thread picks up incoming connection for a certain period
of time (this could be long, like 1min), then it means all the threads are
hanging, so report an error with a stack trace indicating where the threads are
stuck.



 Comments   
Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Tom Mueller [ 06/Jan/11 ]

User is no longer on the project. Reassigning to default assignee for monitoring.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-10106] Provide additional types for use with monitor command Created: 08/Oct/09  Updated: 05/Apr/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: V3
Fix Version/s: future release

Type: Improvement Priority: Minor
Reporter: msreddy Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 10,106

 Description   

Based on the use case that whenever a performance issue arises some one would
first go to top command (in unix) to detect the symptom for subsequent
diagnosis. Similarly, asadmin monitor command will be used to get the symptom.
This will be possible when we provide several 'types' to monitor. Presently, we
have very few types which are servlet, httplistener, jvm, webmodule.

We need to enhance this based on core monitoring infrastructure.



 Comments   
Comment by Tom Mueller [ 06/Jan/11 ]

User is no longer on the project. Reassigning to default assignee for monitoring.

Comment by Jennifer Chou [ 18/Jan/11 ]

Consider for 3.2 From v2.1.1 asadmin monitor --help there are the following types:

-type The type of statistics to moni
tor. Valid values are:

o connection

o connectionqueue

o connectorpool

o endpoint

o entitybean

o filecache

o httplistener

o httpservice

o jdbcpool

o jvm

o keepalive

o messagedriven

o servlet

o statefulsession

o statelesssession

o threadpool

o webmodule

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-8853] Multi-line StringStatistics corrupts all statistics Created: 23/Jul/09  Updated: 05/Apr/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: V3
Fix Version/s: future release

Type: Improvement Priority: Minor
Reporter: marina vatkina Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issue Links:
Dependency
blocks GLASSFISH-8955 headers and values are printed in the... Resolved
Issuezilla Id: 8,853

 Description   

This is the multiline output that is set into the current:

Transaction Id Status ElapsedTime(ms)
ComponentName ResourceNames

03000000AC5A66A9757068696C6C2C5431323438333832353731363336NoTransaction
3134 unknown
04000000AC5A66A9757068696C6C2C5431323438333832353731363336NoTransaction
2929 unknown

And this is what I get (see that even the CountStatistics are broken):

% asadmin get --monitor=true "server.transaction-service.*"
com.sun.enterprise.cli.framework.CommandException: remote failure: Unknown plain
text format. Response from the server: Signature-Version: 1.0
message: null
children: server.transaction-service.activecount-count = 0;server.tran
saction-service.activecount-description = Provides the number of tran
sactions that are currently active.;server.transaction-service.active
count-lastsampletime = 1248382567087;server.transaction-service.activ
ecount-name = ActiveCount;server.transaction-service.activecount-star
ttime = 1248382567087;server.transaction-service.activecount-unit = c
ount;server.transaction-service.activeids-description = Provides the
IDs of the transactions that are currently active a.k.a. in-flight tr
ansactions. Every such transaction can be rolled back after freezing
the transaction service.;server.transaction-service.activeids-lastsam
pletime = 1248382567089;server.transaction-service.activeids-name = A
ctiveIds;server.transaction-service.activeids-name-current =

Transa
ction Id Status ElapsedTim
e(ms) ComponentName ResourceNames

03000000AC5A6
6A9757068696C6C2C5431323438333832353731363336NoTransaction
3134 unknown
04000000AC5A66A97
57068696C6C2C5431323438333832353731363336NoTransaction 292
9 unknown ;server.transaction-se
rvice.activeids-starttime = 1248382567089;server.transaction-service.
activeids-unit = List;server.transaction-service.committedcount-count
= 0;server.transaction-service.committedcount-description = Provides
the number of transactions that have been committed.;server.transact
ion-service.committedcount-lastsampletime = 1248382567089;server.tran
saction-service.committedcount-name = CommittedCount;server.transacti
on-service.committedcount-starttime = 1248382567089;server.transactio
n-service.committedcount-unit = count;server.transaction-service.roll
edbackcount-count = 0;server.transaction-service.rolledbackcount-desc
ription = Provides the number of transactions that have been rolled b
ack.;server.transaction-service.rolledbackcount-lastsampletime = 1248
382567089;server.transaction-service.rolledbackcount-name = Rolledbac
kCount;server.transaction-service.rolledbackcount-starttime = 1248382
567089;server.transaction-service.rolledbackcount-unit = count;server
.transaction-service.state-description = Indicates if the transaction
service has been frozen;server.transaction-service.state-lastsamplet
ime = 1248382567091;server.transaction-service.state-name = State;ser
ver.transaction-service.state-name-current = False;server.transaction
-service.state-starttime = 1248382567091;server.transaction-service.s
tate-unit = String
use-main-children-attribute: true
children-type: null
exit-code: SUCCESS

Name: server.transaction-service.activecount-starttime = 1248382567087
message: server.transaction-service.activecount-starttime = 1248382567
087

Name: server.transaction-service.committedcount-starttime = 1248382567
089
message: server.transaction-service.committedcount-starttime = 1248382
567089

Name: server.transaction-service.committedcount-unit = count
message: server.transaction-service.committedcount-unit = count

Name: server.transaction-service.rolledbackcount-name = RolledbackCoun
t
message: server.transaction-service.rolledbackcount-name = RolledbackC
ount

Name: server.transaction-service.state-lastsampletime = 1248382567091
message: server.transaction-service.state-lastsampletime = 12483825670
91

Name: server.transaction-service.rolledbackcount-description = Provide
s the number of transactions that have been rolled back.
message: server.transaction-service.rolledbackcount-description = Prov
ides the number of transactions that have been rolled back.

Name: server.transaction-service.rolledbackcount-starttime = 124838256
7089
message: server.transaction-service.rolledbackcount-starttime = 124838
2567089

Name: server.transaction-service.activecount-lastsampletime = 12483825
67087
message: server.transaction-service.activecount-lastsampletime = 12483
82567087

Name: server.transaction-service.rolledbackcount-unit = count
message: server.transaction-service.rolledbackcount-unit = count

Name: server.transaction-service.state-name = State
message: server.transaction-service.state-name = State

Name: server.transaction-service.rolledbackcount-lastsampletime = 1248
382567089
message: server.transaction-service.rolledbackcount-lastsampletime = 1
248382567089

Name: server.transaction-service.committedcount-description = Provides
the number of transactions that have been committed.
message: server.transaction-service.committedcount-description = Provi
des the number of transactions that have been committed.

Name: server.transaction-service.activecount-name = ActiveCount
message: server.transaction-service.activecount-name = ActiveCount

Name: server.transaction-service.activeids-unit = List
message: server.transaction-service.activeids-unit = List

Name: server.transaction-service.activeids-description = Provides the
IDs of the transactions that are currently active a.k.a. in-flight tr
ansactions. Every such transaction can be rolled back after freezing
the transaction service.
message: server.transaction-service.activeids-description = Provides t
he IDs of the transactions that are currently active a.k.a. in-flight
transactions. Every such transaction can be rolled back after freezi
ng the transaction service.

Name: server.transaction-service.rolledbackcount-count = 0
message: server.transaction-service.rolledbackcount-count = 0

Name: server.transaction-service.state-name-current = False
message: server.transaction-service.state-name-current = False

Name: server.transaction-service.state-unit = String
message: server.transaction-service.state-unit = String

Name: server.transaction-service.activecount-unit = count
message: server.transaction-service.activecount-unit = count

Name: server.transaction-service.activecount-count = 0
message: server.transaction-service.activecount-count = 0

Name: server.transaction-service.committedcount-count = 0
message: server.transaction-service.committedcount-count = 0

Name: server.transaction-service.committedcount-lastsampletime = 12483
82567089
message: server.transaction-service.committedcount-lastsampletime = 12
48382567089

Name: server.transaction-service.activeids-name-current =

Transactio
n Id Status ElapsedTime(ms
) ComponentName ResourceNames

03000000AC5A66A97
57068696C6C2C5431323438333832353731363336NoTransaction 313
4 unknown
04000000AC5A66A975706
8696C6C2C5431323438333832353731363336NoTransaction 2929
unknown
message: server.transaction-service.activeids-name-current =

Transac
tion Id Status ElapsedTime
(ms) ComponentName ResourceNames

03000000AC5A66
A9757068696C6C2C5431323438333832353731363336NoTransaction
3134 unknown
04000000AC5A66A975
7068696C6C2C5431323438333832353731363336NoTransaction 2929
unknown

Name: server.transaction-service.state-description = Indicates if the
transaction service has been frozen
message: server.transaction-service.state-description = Indicates if t
he transaction service has been frozen

Name: server.transaction-service.activeids-starttime = 1248382567089
message: server.transaction-service.activeids-starttime = 124838256708
9

Name: server.transaction-service.activecount-description = Provides th
e number of transactions that are currently active.
message: server.transaction-service.activecount-description = Provides
the number of transactions that are currently active.

Name: server.transaction-service.committedcount-name = CommittedCount
message: server.transaction-service.committedcount-name = CommittedCou
nt

Name: server.transaction-service.state-starttime = 1248382567091
message: server.transaction-service.state-starttime = 1248382567091

Name: server.transaction-service.activeids-name = ActiveIds
message: server.transaction-service.activeids-name = ActiveIds

Name: server.transaction-service.activeids-lastsampletime = 1248382567
089
message: server.transaction-service.activeids-lastsampletime = 1248382
567089

Command get failed.



 Comments   
Comment by Nazrul [ 09/Sep/09 ]

Prashanth -> Nachiappan

Comment by abbagani [ 25/Sep/09 ]

Formatting the output in the backend is wrong design. We were doing this wrong
in V2 and there is no reason to continue doing this for v3. We should return
proper objects to the client and let the client design what format he/she wants
it to be displayed. More important as we have varying degrees of clients here
(GUI,asadmin,DTrace,Scripting-client and MBeans).

The proper way to handle this is enclose your transaction information into a
Statistic object and then return that array back to the caller.
You will first need to define your Transaction Statistic object which will
contain (Transaction Id, Status, ElapsedTime(ms), ComponentName, ResourceNames)
which will extend StatisticImpl. Please see
org.glassfish.webservices.monitoring.DeployedEndpointData as an example.
If you have multiples of this Objects to be returned, you would define your
Transactions Stats object which will implement Stats interface, and return your
array from here. See the inner class MyStats in
org.glassfish.webservices.monitoring.WebServiceStatsProvider on how they did
this. Once you have this, all the clients will handle the output in their own
way and you will not have to worry about the formatting for them.

Marking the bug as P3 and transferring to Transaction owner

Comment by marina vatkina [ 26/Sep/09 ]

There is a separate bug in transactions output (see the issue that depends on
this one).

1. It's still a bug in the monitoring that a multi-line String (whether right or
wrong) not only can't be displayed properly, but it corrupts output for other
monitoring data.

2. If there are already 3 places that need a multi-line output, and the existing
code can't handle a String that represents more than 1 line, either the
StringStatisticImpl should be able to take an Array or a List of Strings or a
separate MultilineStringStatisticImpl should be added.

Comment by abbagani [ 27/Sep/09 ]

What other 3 places are you referring to, can you please state that. No other
modules has this requirement.

I see the same example being referred in the 8955 bugs as well.
As far as this example is concerned, you shouldn't be formatting the output on
your side. They should be returned as statistic objects to the clients. Please
plan on fixing it.

Comment by abbagani [ 28/Sep/09 ]

Trasferring to Marina.

Comment by marina vatkina [ 30/Sep/09 ]

As discussed on the eng meeting...

Comment by Nazrul [ 30/Sep/09 ]

Getting help from Sreeni

Comment by msreddy [ 01/Oct/09 ]

Thanks to Nachi for help on this bug.
Suggested to Marina to use "%%%EOL%%%" instead of "/n" as the data sent back to
client is done using Zip Manifest. I have tested it on Mac, Linux and Solaris
X86 and it works fine with the above change.

The code diff for Marina is:

jyothi[77]: svn diff
src/main/java/com/sun/enterprise/transaction/monitoring/TransactionServiceStatsProvider.java
Index:
src/main/java/com/sun/enterprise/transaction/monitoring/TransactionServiceStatsProvider.java
===================================================================

src/main/java/com/sun/enterprise/transaction/monitoring/TransactionServiceStatsProvider.java
(revision 32153)
+++
src/main/java/com/sun/enterprise/transaction/monitoring/TransactionServiceStatsProvider.java
(working copy)
@@ -142,11 +142,12 @@
if (aList.size() > 0)

{ // XXX strBuf.append("\n\n"); + strBuf.append("%%%EOL%%%"); appendColumn(strBuf, "Transaction Id", COLUMN_LENGTH+15); appendColumn(strBuf, "Status", COLUMN_LENGTH); appendColumn(strBuf, "ElapsedTime(ms)", COLUMN_LENGTH); appendColumn(strBuf, "ComponentName", componentNameLength); - strBuf.append("ResourceNames "); // XXX \n"); + strBuf.append("ResourceNames %%%EOL%%%"); }

for (int i=0; i < aList.size(); i++) {
@@ -154,6 +155,7 @@
String txnId = txnBean.getId();

// XXX strBuf.append("\n");
+ strBuf.append("%%%EOL%%%");
_logger.fine("=== Processing txnId: " + txnId);
appendColumn(strBuf, txnId, COLUMN_LENGTH+15);
appendColumn(strBuf, txnBean.getStatus(), COLUMN_LENGTH);
jyothi[78]:

The corresponding output of get is:

jyothi[65]: ./asadmin get -m "server.transaction-service.*"
server.transaction-service.activecount-count = 1
server.transaction-service.activecount-description = Provides the number of
transactions that are currently active.
server.transaction-service.activecount-lastsampletime = 1254449158267
server.transaction-service.activecount-name = ActiveCount
server.transaction-service.activecount-starttime = 1254449062341
server.transaction-service.activecount-unit = count
server.transaction-service.activeids-current =
Transaction Id Status ElapsedTime(ms)
ComponentName ResourceNames

0000000000000001_00 Active 20930
org.nachi.transactiontest.ejb.SimpleSessionBean jdbc/__default,
server.transaction-service.activeids-description = Provides the IDs of the
transactions that are currently active a.k.a. in-flight transactions. Every such
transaction can be rolled back after freezing the transaction service.
server.transaction-service.activeids-lastsampletime = 1254449179193
server.transaction-service.activeids-name = ActiveIds
server.transaction-service.activeids-starttime = 1254449062341
server.transaction-service.activeids-unit = List
server.transaction-service.committedcount-count = 0
server.transaction-service.committedcount-description = Provides the number of
transactions that have been committed.
server.transaction-service.committedcount-lastsampletime = -1
server.transaction-service.committedcount-name = CommittedCount
server.transaction-service.committedcount-starttime = 1254449062341
server.transaction-service.committedcount-unit = count
server.transaction-service.dotted-name = server.transaction-service
server.transaction-service.rolledbackcount-count = 0
server.transaction-service.rolledbackcount-description = Provides the number of
transactions that have been rolled back.
server.transaction-service.rolledbackcount-lastsampletime = -1
server.transaction-service.rolledbackcount-name = RolledbackCount
server.transaction-service.rolledbackcount-starttime = 1254449062341
server.transaction-service.rolledbackcount-unit = count
server.transaction-service.state-current = True
server.transaction-service.state-description = Indicates if the transaction
service has been frozen
server.transaction-service.state-lastsampletime = 1254449179194
server.transaction-service.state-name = State
server.transaction-service.state-starttime = 1254449062341
server.transaction-service.state-unit = String

Command get executed successfully.
jyothi[66]:

Based on discussion with Marina, lowering the priority to P4 to fix the
infrastructure as enhancement.

Comment by Tom Mueller [ 06/Jan/11 ]

Assigned user is no longer on project. Reassigning to category owner.

Comment by Byron Nevins [ 07/Feb/11 ]

Unfortunately we are forced to use the Manifest object for returning data to asadmin.

One of the annoying problems with the Manifest object is that it will happily accept embedded linefeeds when you WRITE it. And then explode later when it is READ!

The solution is to always encode linefeeds that are part of your formatting for a String like so –

import com.sun.enterprise.universal.collections.ManifestUtils;
myString = ManifestUtils.encode(myString);

Comment by marina vatkina [ 23/Mar/11 ]

Byron, either close this bug as won't fix, or reject linefeeds in the monitoring strings. I can't do anything with the infrastructure, and the jts code already replaces linefeeds with the special marker

Comment by Byron Nevins [ 23/Mar/11 ]

Marina,

Your comment does not compute. Please clarify.

I'll mark it for 3.2 for now.

I may just run all monitoring strings through the ONE extra line of code to guarantee the manifest object won't explode in asadmin
Clearly monitoring should be more defensive. Monitoring callers are ignoring the rules of the road!

Comment by marina vatkina [ 23/Mar/11 ]

My comment was about reassigning this bug to you - it was assigned to me, though I'm not working on monitoring infrastructure. HTH.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-6422] [UB] [Release Note] newly created vs didn't show under HTTPService monitoring Created: 03/Oct/08  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: V3
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: yifeng1 Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: PC


Attachments: JPEG File monitoring1.JPG    
Issuezilla Id: 6,422
Status Whiteboard:

gfv3-prelude-excluded


 Description   

b27, open solaris, IE 7

after creation of a new virtual server, I go to monotoring tab, from the drop
down list, I didn't see this new virtual server. I have tried reload browser,
click refresh page, still doesn't show. CLI command doesn't have new virtual
server listed either.

to reproduce:

1. turn monitoring level to HIGH and save
2. configuration->virtual servers>click new>input myvs1 as id->click save
3. configuration->http listeners>click new->
put name as myhs1, network address 0.0.0.0 listener port 6666 default virtual
server myvs1-> click next--> click finish
4. access http://myhost:6666 , make sure the new http listener for myvs1 is working
5. application server->monitor->HTTP Service
notice the virtual server named myvs1 is not on the pulldown list

6. corresponding CLI command doesn't return the stats for myvs1 either

  1. uname -a/asadmin get --monitor=true "server.http-service.*"
    server.http-service.__asadmin.request.count5xx-count = 0
    server.http-service.server.request.count404-count = 0
    server.http-service.__asadmin.request.count503-count = 0
    server.http-service.__asadmin.request.requestCount = 0
    server.http-service.__asadmin.request.processingTime = NaN
    server.http-service.server.request.count200-count = 0
    server.http-service.server.request.count2xx-count = 0
    server.http-service.server.request.count302-count = 0
    server.http-service.server.request.countother-count = 0
    server.http-service.server.request.requestCount = 0
    server.http-service.server.request.count4xx-count = 0
    server.http-service.server.request.count400-count = 0
    server.http-service.__asadmin.request.count401-count = 0
    server.http-service.__asadmin.request.countother-count = 0
    server.http-service.__asadmin.request.count400-count = 0
    server.http-service.server.request.errorCount = 0
    server.http-service.server.request.maxTime = 0
    server.http-service.__asadmin.request.count403-count = 0
    server.http-service.__asadmin.request.count302-count = 0
    server.http-service.server.request.count5xx-count = 0
    server.http-service.__asadmin.request.count3xx-count = 0
    server.http-service.__asadmin.request.count2xx-count = 0
    server.http-service.__asadmin.request.count4xx-count = 0
    server.http-service.__asadmin.request.errorCount = 0
    server.http-service.server.request.count503-count = 0
    server.http-service.__asadmin.request.count200-count = 0
    server.http-service.server.request.count3xx-count = 0
    server.http-service.server.request.count401-count = 0
    server.http-service.server.request.processingTime = NaN
    server.http-service.__asadmin.request.count304-count = 0
    server.http-service.__asadmin.request.count404-count = 0
    server.http-service.server.request.count403-count = 0
    server.http-service.server.request.count304-count = 0
    server.http-service.__asadmin.request.maxTime = 0


 Comments   
Comment by yifeng1 [ 03/Oct/08 ]

Created an attachment (id=1929)
add attachment

Comment by yifeng1 [ 03/Oct/08 ]

add one attachment, in the picture, left side window shows the newly created
http listener myhs1 is running on myvs1, right side window is Admin console, the
drop down list doesn't have myvs1.

Comment by Anissa Lam [ 03/Oct/08 ]

This is a monitoring issue, related to dynamic reconfiguration.
The newly created VS will show up after server restart.
Transferring to monitoring.

Comment by Nazrul [ 08/Oct/08 ]

Discussed this with Jerome and Abhijit. Will be fixed after GFv3 Prelude. User
will need to restart to see stats for newly created virtual server.

We may release note this.

Comment by Nazrul [ 15/Oct/08 ]

Need to release note for GFv3 Prelude.

Comment by kumara [ 24/Oct/08 ]

Prashanth: Please be sure to get a release note entry added for this issue. Excluding from prelude release.

Comment by kumara [ 24/Oct/08 ]

Reclassifying as P4 because these issues are not must fix for prelude release.
This issue will be scrubbed after prelude release and will be given the right
priority for v3 final release.

Comment by Gail Risdal [ 08/Dec/09 ]

Added to v3 Release Notes.

Comment by Tom Mueller [ 06/Jan/11 ]

User is no longer on the project. Reassigning to default assignee for monitoring.

Comment by Jennifer Chou [ 18/Jan/11 ]

Consider for 3.2.





[GLASSFISH-6263] Add --filter option to monitor command Created: 23/Sep/08  Updated: 05/Apr/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: V3
Fix Version/s: future release

Type: New Feature Priority: Minor
Reporter: sankarpn Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,263
Status Whiteboard:

gfv3-prelude-excluded


 Description   

C:\work\admincli\ws\v3\glassfishv3-prelude\glassfish>asadmin list-applications

webmodmonitoring <web>
jdbcapp1webmod1 <web>

Command list-applications executed successfully.

There are 2 webmodules deployed in the server.

Executing this command should fail since there is a ambiguity in deciding for
which module it is supposed to return the stats. But the command doesn't fail
and deisplays the stats.

C:\work\admincli\ws\v3\glassfishv3-prelude\glassfish>asadmin monitor --type=webm
odule --interval=10 server
asc ast rst st ajlc mjlc tjlc aslc mslc tslc
0 0 0 0 0 0 0 16 16 16

0 0 0 0 0 0 0 16 16 16



 Comments   
Comment by kumara [ 23/Sep/08 ]

v3 defect tracking

Comment by janey [ 23/Sep/08 ]

reassign to Sreeni.

Comment by msreddy [ 24/Sep/08 ]

In prelude, we are not supporting filters for web module which is contemplated
for post prelude.

Comment by kumara [ 24/Oct/08 ]

Reclassifying as P4 because these issues are not must fix for prelude release.
This issue will be scrubbed after prelude release and will be given the right
priority for v3 final release.

Comment by Tom Mueller [ 23/Jun/10 ]

Sreenivas no longer on project.

Comment by Jennifer Chou [ 20/Jan/11 ]

Considering adding support for --filter in monitor command for 3.2

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-6238] [UB] [Release Note] monitoring:after change virtual server for app, monitoring page shows old value Created: 22/Sep/08  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: V3
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: yifeng1 Assignee: Jennifer Chou
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: PC


Issuezilla Id: 6,238
Status Whiteboard:

gfv3-prelude-excluded

Tags: 3_1-exclude

 Description   

platform: open solaris
b25

to reproduce:
1. configuration -> monitoring->set value to high and save
2. applications->web applications->deploy, deploy webapps-simple.war and point
to server1
3. configuration->virutal servers->create new called myvs1, provide id,
hosts,and save
4. configuration->http listeners->create new http listeners,provide name,
network address, listener ort, default virtual server point to myvs1
5. applications->web applications-->click webapps-simple and change virtual
server to myvs1 , save
6.application server->monitoring->web container,
select application webapps-simple, notice that after page refresh, virtual
server shows server --> bug



 Comments   
Comment by Anissa Lam [ 23/Sep/08 ]

not sure if this is gui issue or monitoring.
Jennifer please take a look

Comment by kumara [ 23/Sep/08 ]

v3 defect tracking

Comment by Jennifer Chou [ 23/Sep/08 ]

I also see this issue on CLI: asadmin get --monitor=true "server.applications.*"

When I restart the appserver, then both the gui (Web Container tab) and CLI
(asadmin get --monitor=true "server.applications.*") show the newly changed
virtual-server, myvs1.

Seems to be a dynamic reconfig issue.
------------------------
There is a second problem I see though. After I restarted the appserver, the
HTTP Service tab (in gui) and the 'server.http-service.<virtual-server>.request
nodes from CLI get --monitor=true "request" still shows the old 'server' name:

C:\gfv3_0922\v3\distributions\web\target\glassfish\bin>asadmin get --monitor=tr
e "request"
server.http-service.__asadmin.request.count5xx-count = 0
server.http-service.__asadmin.request.count503-count = 0
server.http-service.myvs1.request.count5xx-count = 0
server.http-service.__asadmin.request.requestCount = 0
server.http-service.server.request.count302-count = 0
server.http-service.server.request.countother-count = 0
server.http-service.server.request.requestCount = 0
server.http-service.server.request.count400-count = 0
server.http-service.__asadmin.request.count401-count = 0
server.http-service.myvs1.request.count4xx-count = 0
server.http-service.__asadmin.request.countother-count = 0
server.http-service.__asadmin.request.count400-count = 0
server.http-service.server.request.errorCount = 0
server.web.request.processingTime = 149.55345911949686
server.web.request.maxTime = 14375
server.http-service.myvs1.request.count302-count = 0
server.http-service.__asadmin.request.count3xx-count = 0
server.http-service.myvs1.request.count401-count = 0
server.http-service.myvs1.request.count400-count = 0
server.http-service.myvs1.request.errorCount = 0
server.web.request.errorCount = 0
server.http-service.__asadmin.request.count200-count = 0
server.http-service.myvs1.request.maxTime = 0
server.http-service.__asadmin.request.count304-count = 0
server.http-service.server.request.count403-count = 0
server.http-service.__asadmin.request.maxTime = 0
server.http-service.myvs1.request.count403-count = 0
server.http-service.server.request.count404-count = 0
server.http-service.myvs1.request.countother-count = 0
server.http-service.__asadmin.request.processingTime = NaN
server.http-service.server.request.count200-count = 0
server.http-service.server.request.count2xx-count = 0
server.http-service.server.request.count4xx-count = 0
server.web.request.requestCount = 159
server.http-service.myvs1.request.count2xx-count = 0
server.http-service.server.request.maxTime = 0
server.http-service.__asadmin.request.count403-count = 0
server.http-service.myvs1.request.count200-count = 0
server.http-service.__asadmin.request.count302-count = 0
server.http-service.myvs1.request.processingTime = NaN
server.http-service.server.request.count5xx-count = 0
server.http-service.myvs1.request.count3xx-count = 0
server.http-service.__asadmin.request.count2xx-count = 0
server.http-service.myvs1.request.count503-count = 0
server.http-service.__asadmin.request.count4xx-count = 0
server.http-service.__asadmin.request.errorCount = 0
server.http-service.server.request.count503-count = 0
server.http-service.server.request.count3xx-count = 0
server.http-service.server.request.count401-count = 0
server.http-service.myvs1.request.requestCount = 0
server.http-service.server.request.processingTime = NaN
server.http-service.myvs1.request.count304-count = 0
server.http-service.myvs1.request.count404-count = 0
server.applications.hello.server.requestCount = 159
server.http-service.__asadmin.request.count404-count = 0
server.http-service.server.request.count304-count = 0

Comment by abbagani [ 23/Sep/08 ]

Looking into the problem

Comment by kumara [ 24/Sep/08 ]

Not a must have for Prelude release.

Comment by Nazrul [ 15/Oct/08 ]

Release note that user will need to restart the server to see virtual server
changes in monitoring tier.

Comment by kumara [ 24/Oct/08 ]

Prashanth: Please be sure get this recorded in the release note. Exclude from the prelude release.

Comment by kumara [ 24/Oct/08 ]

Reclassifying as P4 because these issues are not must fix for prelude release.
This issue will be scrubbed after prelude release and will be given the right
priority for v3 final release.

Comment by Gail Risdal [ 08/Dec/09 ]

Added to v3 Release Notes.

Comment by Tom Mueller [ 06/Jan/11 ]

User is no longer on the project. Reassigning to default assignee for monitoring.

Comment by Byron Nevins [ 07/Feb/11 ]

Jennifer - can you verify that this still exists?

I'm setting it to 3.2 so it doesn't get lost...

Comment by Jennifer Chou [ 07/Feb/11 ]

This issue still exists in 3.1. It's now called Network Listeners, instead of HTTP Listeners.
Turn on monitoring for http-service.





[GLASSFISH-16859] hard-coded messages with no message IDs in flashlight Created: 14/Jun/11  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Dies Koper Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Below java file contains direct usage of log messages:

http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3LoggingMessageFormat

flashlight\framework\src\main\java\org\glassfish\flashlight\transformer\ProbeProviderClassFileTransformer.java

There are multiple messages hard-coded instead of using LogStrings.properties file for localization.

One particularly that stands out is the following, which is logged several times during QL. Probably this one could be changed to level FINE.

logger.log(Level.INFO, "Successfully got INSTRUMENTATION: " + instrumentation);

[#|2011-06-14T14:05:40.210+1000|INFO|glassfish3.2|org.glassfish.flashlight.transformer.ProbeProviderClassFileTransformer|_ThreadID=17;_ThreadName=Thread-1;|Successfully got INSTRUMENTATION: sun.instrument.InstrumentationImpl@1ccaac7|#]



 Comments   
Comment by Dies Koper [ 05/Jul/11 ]

Another hard-coded message appeared in my QL logs today:

[#|2011-07-05T12:58:07.684+1000|INFO|glassfish3.2|org.glassfish.flashlight.transformer.ProbeProviderClassFileTransformer|_ThreadID=15;_ThreadName=Thread-2;|Couldn't write the retransformed class data

See ProbeProviderClassFileTransformer.java:

logger.log(Level.INFO, "Couldn't write the retransformed class data", th);





[GLASSFISH-21100] Glassfish monitoring shows irrealistic values about connection pool Created: 25/Jun/14  Updated: 15/Jul/14

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: bence.takacs Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux



 Description   

Glassfish monitoring shows irrealistic values about connection pool.

Settings:

<jdbc-connection-pool validation-table-name="dual" steady-pool-size="16" associate-with-thread="true" connection-leak-reclaim="true" max-wait-time-in-millis="300000" lazy-connection-association="true" lazy-connection-enlistment="true" max-pool-size="120" datasource-classname="oracle.jdbc.xa.client.OracleXADataSource" max-connection-usage-count="5000" res-type="javax.sql.XADataSource" description="Engine database pool" name="myPool" is-connection-validation-required="true" transaction-isolation-level="read-committed">

Shown values (/monitoring/myDomain/server/resources/myPool):

numconnfree
highwatermark : 16
lastsampletime : 1403693439207
description : The+total+number+of+free+connections+in+the+pool+as+of+the+last+sampling.
unit : count
name : NumConnFree
starttime : 1403661640985
current : -57092
lowwatermark : -57093
numconnused
highwatermark : 57272
lastsampletime : 1403693439207
description : Provides+connection+usage+statistics.The+total+number+of+connections+that+are+currently+being+used%2C+as+well+as+information+about+the+maximum+number+of+connections+that+were+used%28the+high+water+mark%29.
unit : count
name : NumConnUsed
starttime : 1403661640985
current : 57271
lowwatermark : 0

While the active transaction count is 21 - according to the same monitoring interface.



 Comments   
Comment by bence.takacs [ 15/Jul/14 ]

Maybe it is related to this one:
https://java.net/jira/browse/GLASSFISH-16843

Is it possible that this has already been fixed but only for versions above 4.0?
If yes, is it possible to backport the fix into 3.x?





[GLASSFISH-19275] Flashlight seeing probes in ProbeRegistry even though the ProbeProvider failed to register Created: 01/Nov/12  Updated: 01/Nov/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: tvlatas Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux



 Description   

I've been doing some testing which uses XML probes.

During some testing which uses XML probe definitions, I had inadvertently had defined some XML probe provider definitions which were being rejected by Flashlight, but my tests were actually still finding the probes in the ProbeRegistry.

The probe definitions from the XML providers that failed appear to actually have been consumed here and were showing up in the ProbeRegistry after that occurred. For example, while my unit tests logged a severe error, the call to FlashlightProbeProviderFactory.processXMLProbeProviders() itself though returned as if it had succeeded and the probe definitions from those providers showed up and appeared valid when the unit tests called probeRegistry.getAllProbes() and verified it found the probes.

Knowing the provider failed to be processed fully there, I'm thinking that the probes from those providers would not want to be showing up after that occurred. For example, even if the FlashlightProbeProviderFactory.processXMLProbeProviders() eats the exception, I'm thinking that the probes that were defined for those providers that were determined to be invalid would not show up as being registered later (right?). I haven't dug into why that happened and whether they may case adverse side effects later on if they are not cleared out (ie: it may be that they are just "zombie" probes taking up heap and not causing other issues since the provider wasn't really completely registered?)

I suspect what is happening there is as the provider is being processed createProbe calls are registering the probes.

I believe that this could be reproduced using the flashlight unit tests by adding a new test that does something along these lines:

@BeforeClass
public static void setUpClass() throws Exception

{ FlashlightUtils.initialize(new MyServiceLocator(), new MyMonitoringService()); flashlightProbeProviderFactory = new FlashlightProbeProviderFactory(); assertNotNull(flashlightProbeProviderFactory); flashlightProbeProviderFactory.postConstruct(); flashlightProbeProviderFactory.processXMLProbeProviders(ProbeEventGenerationTest.class.getClassLoader(), "one_probe.xml", true); flashlightProbeProviderFactory.processXMLProbeProviders(ProbeEventGenerationTest.class.getClassLoader(), "two_probe.xml", true); probeRegistry = ProbeRegistry.getInstance(); assertNotNull(probeRegistry); // check the probe registry for probes from the failed provider }




[GLASSFISH-19274] Flashlight ProbeProviderRegistry.registerProbeProvider error can be more specific when it rejects a provider if due to the class having been registered already Created: 01/Nov/12  Updated: 01/Nov/12

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: tvlatas Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux



 Description   

I was doing some testing using XML providers and hit a failure processing some of the XML files:
java.lang.IllegalStateException: Provider already mapped CamelNameTestModuleProvider:CamelNameTestModule:CamelNameTestProvider
at org.glassfish.flashlight.impl.core.ProbeProviderRegistry.registerProbeProvider(ProbeProviderRegistry.java:104)
at org.glassfish.flashlight.impl.provider.FlashlightProbeProviderFactory.registerProvider(FlashlightProbeProviderFactory.java:596)
at org.glassfish.flashlight.impl.provider.FlashlightProbeProviderFactory.processXMLProbeProviders(FlashlightProbeProviderFactory.java:420)

The error pointed me at the right XML file with a problem, but it turns out the problem was the classname in the XML file was the same as a provider already registered (and the name of the provider was OK).

if (providerMap.putIfAbsent(qname, provider) != null)

{ throw new IllegalStateException("Provider already mapped " + qname); }

if (classProviderMap.putIfAbsent(clz, provider) != null)

{ throw new IllegalStateException("Provider already mapped " + qname); <== This is line 104 where the exception was thrown }

The IllegalStateException in ProbeProviderRegistry.registerProbeProvider may want to clarify that problem is that class already was mapped there for a different provider name. Ie: in this case, it was a new probe provider name, but the same class was specified. A minor thing, but I'm thinking it could really help someone that did a cut/paste of the XML there like I did to catch what was wrong about it faster.






Generated at Fri Jul 29 07:19:53 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.