[GLASSFISH-12182] Refactor CreateLocalInstanceFilesystemCommand to share with DAS Created: 08/Jun/10  Updated: 05/Apr/11

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

Type: Improvement 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
Environment:

Operating System: All
Platform: All


Issuezilla Id: 12,182

 Description   

CreateLocalInstanceFilesystemCommand is a local command the creates the
filesystem layout needed for a server instance. In some situations the DAS needs
this capability as well. For example when SSH is configured create-instance
executes _create-instance-filesystem over SSH. But if the server instance is
running local to the DAS we run the command using Runtime.exec(). We'd like to
avoid this and simply reuse the code in CreateLocalInstanceFilesystemCommand.

This is a request to refactor CreateLocalInstanceFilesystemCommand and place the
generic code that does the filesystem creation into a class that can be shared
with the DAS.



 Comments   
Comment by Jennifer Chou [ 04/Aug/10 ]

Defer to 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-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-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-13769] Support nested token substitution Created: 02/Oct/10  Updated: 05/Oct/10

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

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

Operating System: Linux
Platform: All


Issuezilla Id: 13,769

 Description   

1. Login to admin console, create cluster's instance (I used server
configuration copy).
2. Ensure that admin listener has assigned port as reference
$

{ASADMIN_LISTENER_PORT}

3. Go to Configurations-> (instance config) -> System Properties.
4. Add property INSTANCE_PORT_BASE and set default value, then save.
5. Edit ASADMIN_LISTENER_PORT property, and set default value to eg.
$

{INSTANCE_PORT_BASE}

4848.
6. Start choosed cluster's instance with this config.

Instance is starting correctly, and listens on desired port (above e.g. 14848),
but console hangs up, and in log I got:
[#|2010-10-02T19:25:51.676+0200|INFO|glassfish3.1|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin.cluster|_ThreadID=15;_ThreadName=Thread-1;|Cannot
read logging.properties file.
Waiting for the server to start ............
Successfully started the instance: cluster2-instance1
instance Location:
/home/radek/opt/glassfishv3.1/glassfish/nodes/localhost/cluster2-instance1
Log File:
/home/radek/opt/glassfishv3.1/glassfish/nodes/localhost/cluster2-instance1/logs/server.log
Admin Port: -1
Command start-local-instance executed successfully.|#]

Kind regards,
Radosław Smogura
http://www.softperience.eu



 Comments   
Comment by Anissa Lam [ 02/Oct/10 ]

I think the problem is with the fact for using 'server-config' to create the
cluster's instance.
Any change you enter for this also affects the DAS.
In fact, I believe the config should not allow 'server-config' to be one of the
choice, this is also causing issue# 13534.

Can you try choosing the 'default-config' instead ?

Comment by Tom Mueller [ 02/Oct/10 ]

Are you trying to access the admin console on an instance? That isn't allowed.

Comment by rsmogura [ 04/Oct/10 ]

The problems with creating an instance with server "server-config" are different
kind of problems...

Backing to topic.
I don't access cluster instances' admin console (but this could be funny), I
wanted to create general configuration based on properties that adds port prefix
to all system properties stored in configuration (eg. when you create new
configuration you have $

{ASADMIN_LISTENER_PORT} to be setted for e.g. 25678, i
setted ${ASADMIN_LISTENER_PORT}

variable to "$

{INSTANCE_PORT_BASE}4848", so I
don't change admin listener configuration and I leave there
${ASADMIN_LISTENER_PORT}, which is properly expanded on instance start to 14848
(prefix = 1).

I suspect problem is in DAS (or node agent) because it doesn't correctly expand
nested properties, probably when it creates instance it reads admin listener as
${admin_port}, and expands it to "${prefix}4848", which can't be converted to
integer (Admin port: -1 in log). When I will remove ${INSTANCE_PORT_BASE}

from
$

{ASADMIN_LISTENER_PORT}

and set there explicitly 14848 log says Admin Port: 14848.

Bear in mind that instance starts correctly, netstat shows port binds, but just
DAS says instance isn't running (because it can't connect with "-1" admin port).

Comment by rsmogura [ 04/Oct/10 ]

Few word more to clarify, when I wrote "console hangs up" I was thinking about
never ending busy cursor, on DAS admin console, after clicking start instance

Comment by Anissa Lam [ 04/Oct/10 ]

Thanks for the clarification and details.
This sounds like a backend issue, I am going to transfer to 'admin' for further
evaluation.

Comment by Tom Mueller [ 04/Oct/10 ]

It is true that there is no double (or recursive) property substitution. So
currently you cannot do:

<network-listener port="$

{ASADMIN_LISTENER_PORT}

" protocol=...
<system-property name="ASADMIN_LISTENER_PORT" value="$

{index}

4848" />
<system-property name="index" value="2"/>

If that is what is desired here, please refile this as an RFE.

Comment by rsmogura [ 05/Oct/10 ]

I wanted to do exactly what You wrote. I change this to RFE, but I'm not sure
it's good idea, as the instance starts as I want, but DAS doesn't sees it.





[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-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-15870] start-database should have a "verbose" option Created: 06/Feb/11  Updated: 05/Apr/11

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

Type: New Feature 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


 Description   

1) Essential ==> The "--verbose" option should be added to "start-database". The idea is that the asadmin process sits there, blocked, until killed or until the DB is stopped externally.
Why? This makes it smooth and easy to add a Platform Service that will automatically restart the database when necessary (if setup that way). It is precisely analogous with start-domain and the verbose option.

2) As a bonus – have the console window display all DB log messages. That would be very useful.

================
How did I come up with this? On my home website I re-used winsw.exe (in our installation) to run derby as a service via 'asadmin start-domain'. Winsw sees that asadmin exits immediately so Windows reports it as "stopped" even though it is really running.

There are probably other ways of doing this – perhaps JavaDB has its own tools for running as a service?



 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-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-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-16846] Custom Validators fail because of null values for attributes Created: 12/Jun/11  Updated: 02/Dec/11

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

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


 Description   

When an attribute is set to a null value like

asadmin set server.resources.jdbc-connection-pool.DerbyPool.steady-pool-size=

its default value is persisted in the domain.xml. Before this, if there exists a validator for the connection pool, the value received is null instead of default value. As a result, the validator has to set the attribute to its default value before doing certain checks.

Related issue : http://java.net/jira/browse/GLASSFISH-16845

This would affect most elements that do a custom validation on its attributes. Config layer should set default value and call custom validators, when such dotted-names-set is executed.



 Comments   
Comment by Tom Mueller [ 13/Jun/11 ]

Jennifer, can you please take a look at this one. Is this an issue with "set" or with the configuration framework in general?





[GLASSFISH-17537] ServerTags class in nucleus contains appserver-specific tags Created: 31/Oct/11  Updated: 02/Nov/11

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

Type: Bug Priority: Major
Reporter: Tom Mueller 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, nucleus-cleanup

 Description   

The com.sun.enterprise.config.serverbeans.ServerTags class contains constant String values that are specific to interfaces that are defined in main/appserver classes. These Strings should be moved out of nucleus.






[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-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-16393] Refactor DerbyControl Created: 20/Apr/11  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: 4.0

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


 Description   

During investigation of findbugs for DerbyControl, found that it's ok for DerbyControl to call System.exit since is a separate JVM. However, it's being called in the constructor.

Bill's suggestion:
Seems like everything in this class ought to be static, called from main.
Or, the constructor ought to throw an exception in these cases and the
main method should catch the exception and call System.exit.






Generated at Sun May 03 15:26:36 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.