[GLASSFISH-15393] [PERF] Admin Console - slow load time Created: 30/Dec/10  Updated: 19/Dec/16

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

Type: Improvement Priority: Critical
Reporter: Harshad Vilekar Assignee: sirajg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

DAS/Instances on: Solaris 10, Sparc, JDK6u23
Browser: Firefox 3.6.10, on remote Solaris 10, Sparc machine.


Attachments: Text File dasonly-server.log     Text File dasonly-trace.log     Text File multinode-cluster-hudson-console.txt     Zip Archive perf-logging.zip     Java Archive File server-logs-take2.jar     Text File server.log     Text File singlenode-two-instance-server-trace.log     Text File singlenode-twoinstance-cluster-creation-log.txt     Text File singlenode-twoinstance-server.log     Text File twonode-threeinstance-server-trace.log     Text File twonode-twoinstance-server-trace.log    
Issue Links:
Dependency
depends on GLASSFISH-15412 [PERF] processApplication() needs imp... Closed
blocks GLASSFISH-12297 b04 slow startup of Admin GUI after e... Resolved
Tags: 3_1-exclude, 3_1-need_more_info, 3_1-next

 Description   

The numbers below show the time taken by Admin Console main screen to show up in the Browser - for the first time after fresh install.

For http, the time is counted after entering the URL in the browser, and pressing return. In case of https, the time is counted after confirming security exception prompt.

1. DAS only (secure admin enabled): 30+ sec
https://host1.us.oracle.com:4848/common/index.jsf

2. Single node, two instance cluster (secure admin not enabled): 100+ sec
http://host2.us.oracle.com:4848/common/index.jsf

3. Two node, two instance cluster (secure admin enabled): 200+ sec
https://host3.us.oracle.com:4848/common/index.jsf

This is by no means any methodical performance test, but simply shows "perceived load time" on Solaris 10 Sparc machines (Niagara, T1000), that are used for day to day testing.

Attached:
Server log for #3.
Hudson cluster creation job log for #3.



 Comments   
Comment by Anissa Lam [ 03/Jan/11 ]

Several developer is trying to look into this. The latest finding from Jason:

On 1/3/11 8:14 AM, Jason Lee wrote:
> I added logging statements at various points in admin console adapter and installer thread. Here's what I got:
>
> ***** 09:52:40.0944: Application is not yet loaded.
> ***** 09:52:40.0945: Force REST module load
> ***** 09:52:40.0947: Starting installer thread
> ***** 09:52:40.0954: InstallThread.install()
> ***** 09:52:40.0956: building ConfigCode
> ***** 09:52:40.0957: Getting server
> ***** 09:52:40.0957: Applying changes
> ***** 09:52:41.0668: Changes applied
> ***** 09:52:41.0671: Getting ApplicationRef
> ***** 09:52:41.0672: Process application
> ***** 09:52:42.0346: Application is not yet loaded.
> ***** 09:52:59.0675: Application processed
>
> The 'Process application' and 'Application processed' entries show the greatest difference. Those messages came from these lines of code:
>
> adapter.logTime("Process application");
> habitat.getComponent(ApplicationLoaderService.class).processApplication(config, ref, log);
> adapter.logTime("Application processed");
>
> That one line of code took 18 seconds. There may be other hot spots (I'm still looking and tracing), but that seems like a good one to look at.

Comment by Hong Zhang [ 03/Jan/11 ]

Harshad, can you please attach the DAS server.log for all the three scenarios? Want to see how the loading time of the admin gui application compare in the test environment. Thanks.

Comment by Harshad Vilekar [ 04/Jan/11 ]

Attached the server logs for the two scenarios
scenario #1: dasonly-server.log
scenario #2: singlenode-twoinstance-server.log

Comment by Jason Lee [ 04/Jan/11 ]

This archive contains the jars I updated to add logging to the console. Extract this in your GlassFish install root and restart your server.

Comment by Hong Zhang [ 04/Jan/11 ]

Harshad:
Thanks for attaching all the DAS sever.log files, those are very helpful!
The admin console application loading times in your server.log files are kind of different from the ones we observed (on linux/Mac machines): the dasonly-server.log showed 10.815s for loading console application, and the singlenode-twoinstance-server.log showed 62.399s for loading console application. For both me and Jason, the numbers were much closer than this: me on linux das-only loading time 7.974s, singlenode-two-instance 8.736s; jason das-only loading time 17.001s and singlenode-two-instance 20.134s.
I have checked in some changes to enable the deployment tracing for application loading to see the break down of the loading times (more details in 15412). And it will be very useful to see how the loading times break down in your environment. Can you please try with tomorrow's nightly build (which should have my change):
1. Right after you install the server bits in each scenario, add this jvm option to the DAS domain.xml:
<jvm-options>-Dorg.glassfish.deployment.trace=true</jvm-options>
2. Then start DAS, (create/start cluster as applicable), access console as usual.
3. The DAS server.log should have tracing messages like this which will allow us to see how the times break down:
.[#|2011-01-04T16:04:14.207-0500|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=87;_ThreadName=Thread-1;|Container : com.sun.enterprise.web.WebContainer Mark BEFORE_CONTAINER_SETUP at 878|#]
Attach the DAS server.log for all the scenarios in the issue and I will take a look to see where the extra time is spent in application loading for cluster set up.

Comment by Harshad Vilekar [ 05/Jan/11 ]

Attaching logs for scenario #1 and #2 with following option enabled in DAS domain.xml.
<jvm-options>-Dorg.glassfish.deployment.trace=true</jvm-options>

Logs for #3 are not yet available (the hosts are running other tests - so latest nightly build is not yet installed).

Comment by Hong Zhang [ 05/Jan/11 ]

Harshad: thanks for attaching the server.log with the tracing turned on. From your numbers, there is still significant difference between DAS-only and cluster scenarios.

1. The DAS only scenario:
The admin console application loading took 7.119s. And the main time was spent in the container initialization and loading components in web container: the container initialization took 2.874s (the time difference for mark 1 and mark 2) and the loading components in web container took 3.493 s (the time difference for mark 3 and mark 4).

M1.[#|2011-01-05T09:53:55.857-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=92;_ThreadName=Thread-1;|Container : com.sun.enterprise.web.WebContainer Mark BEFORE_CONTAINER_SETUP at 652|#]

M2.[#|2011-01-05T09:53:55.859-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=92;_ThreadName=Thread-1;|Mark CONTAINERS_SETUP_DONE at 3526|#]

M3.[#|2011-01-05T09:53:55.864-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=92;_ThreadName=Thread-1;|Container : web Mark START at 3613|#]

M4.[#|2011-01-05T09:53:55.864-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=92;_ThreadName=Thread-1;|Container : web Mark STARTED at 7106|#]

2. The single node, two cluster instance scenario:

The admin console application loading took 41.302 s. And the main time was also spent in the container initialization and loading components in web container: the container initialization took 14.341s (the time difference for mark 1 and mark 2) and the loading components in web container took 21.720s (the time difference for mark 3 and mark 4).

M1.[#|2011-01-05T11:22:58.378-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=120;_ThreadName=Thread-1;|Container : com.sun.enterprise.web.WebContainer Mark BEFORE_CONTAINER_SETUP at 4057|#]

M2.[#|2011-01-05T11:22:58.386-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=120;_ThreadName=Thread-1;|Mark CONTAINERS_SETUP_DONE at 18398|#

M3.[#|2011-01-05T11:22:58.412-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=120;_ThreadName=Thread-1;|Container : web Mark START at 19515|#]

M4.[#|2011-01-05T11:22:58.413-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=120;_ThreadName=Thread-1;|Container : web Mark STARTED at 41235|#]

Your DAS-only scenario seems to be consistent with what we observed, but your cluster scenario just seems taking much longer for every step, especially in container initialization and component loading. Can you share the exact steps of your cluster scenario, how did you create the cluster etc? And were there any other things running at the same time on the system when you tested? Tom did a testing on Niagra system today too (see issue 15412 for more details), but his numbers on DAS-only and cluster scenario (where 30 local instances were created) were more consistent with what we observed on other systems. We need to figure out what is different on your testing system. Thanks.

Comment by Harshad Vilekar [ 05/Jan/11 ]

Attaching Cluster Creation Steps: singlenode-twoinstance-cluster-creation-log.txt

Multi Node Two Instance Cluster Creation Steps are already attached: multinode-cluster-hudson-console.txt

Comment by Hong Zhang [ 05/Jan/11 ]

Harshad: I don't see anything unusual in the cluster creation steps. Tom was suggesting one possible cause is short of memory on the system, quoting his comments on issue 15412:
One thing to check is the memory on the system. If it is memory starved, everything is going to take longer, and if several local instances are started, that will consume even more memory.
The Niagra system I tested had plenty of memory (64GB or something like that).

Can you share the test system configuration, how much memory it has etc? Thanks.

Comment by Chris Kasso [ 06/Jan/11 ]

I wanted to add a data point.

I created a two node, four instance cluster:

./asadmin list-instances -l
NAME HOST PORT PID CLUSTER STATE
c1i1_sidewinder sidewinder.us.oracle.com 10048 11011 c1 running
c1i2_sidewinder sidewinder.us.oracle.com 11048 11010 c1 running
c1i1_ouch ouch.us.oracle.com 10048 13629 c1 running
c1i2_ouch ouch.us.oracle.com 11048 13631 c1 running
Command list-instances executed successfully.

The DAS is running on a S10/Sparc box (aha.us.oracle.com). The nodes are on S11 Express/x86 system. The firefox (3.6.10) browser was on the S11/x86 box.

I saw no difference in the Admin Console startup time with three different scenarios:

1) Secure Admin enabled: 67 seconds
2) Secure Admin disabled: 65 seconds
3) Secure Admin enabled with only the DAS (no nodes configured): 68 seconds

Given the age of the Solaris 10 Sparc box (SunBlade 1500), about a minute to start the Console is expected.

Comment by Harshad Vilekar [ 06/Jan/11 ]

Hong, I'm attaching server log - with trace enabled - for multi node cluster (scenario #3).

File name:twonode-threeinstance-server-trace.log. The relevant startup log entries begin at line 457.

asadmin list-instances --long
NAME HOST PORT PID CLUSTER STATE
in2 localhost 8363 8948 c1 running
in1 intg2t1000 8107 3011 c1 running
in3 localhost 8619 8955 c1 running
Command list-instances executed successfully.

With latest nightly build - Admin Console took about 140+ seconds to load on above config (this was tested after running some other test).

Comment by Hong Zhang [ 06/Jan/11 ]

Harshad:
Thanks for the attaching the server.log of the multi-node scenario too.

Looking at the server.log, the gui application loading took 36.067s, out of the 140s of the total console accessing time.

And for the application loading part, the container initialization (8.394s) and component loading (24.442s) still took most of the time especially the component loading part.

M1.[#|2011-01-06T17:19:26.048-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=134;_ThreadName=Thread-1;|Container : com.sun.enterprise.web.WebContainer Mark BEFORE_CONTAINER_SETUP at 2481|#

M2.[#|2011-01-06T17:19:26.057-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=134;_ThreadName=Thread-1;|Mark CONTAINERS_SETUP_DONE at 10875|#]

M3.[#|2011-01-06T17:19:26.090-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=134;_ThreadName=Thread-1;|Container : web Mark START at 11558|#]

M4[#|2011-01-06T17:19:26.091-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=134;_ThreadName=Thread-1;|Container : web Mark STARTED at 36000|#]

Comment by Harshad Vilekar [ 06/Jan/11 ]

Notes about numbers reported in twonode-threeinstance-server-trace.log:

1. Hardware config of the machine used to get these numbers:

-bash-3.00$ /usr/sbin/prtdiag
System Configuration: Sun Microsystems sun4v Sun Fire(TM) T1000
System clock frequency: 200 MHz
Memory size: 2040 Megabytes

========================= CPUs ===============================================

CPU CPU
Location CPU Freq Implementation Mask
------------ ----- -------- ------------------- -----
MB/CMP0/P0 0 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P1 1 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P2 2 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P3 3 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P4 4 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P5 5 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P6 6 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P7 7 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P8 8 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P9 9 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P10 10 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P11 11 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P12 12 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P13 13 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P14 14 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P15 15 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P16 16 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P17 17 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P18 18 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P19 19 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P20 20 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P21 21 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P22 22 1000 MHz SUNW,UltraSPARC-T1
MB/CMP0/P23 23 1000 MHz SUNW,UltraSPARC-T1

========================= IO Configuration =========================

IO
Location Type Slot Path Name Model
----------- ----- ---- --------------------------------------------- ------------------------- ---------
MB/NET0 PCIE MB /pci@7c0/pci@0/network@4 network-pci14e4,1668
MB/NET-1 PCIE MB /pci@7c0/pci@0/network network-pci14e4,1668
MB/NET-1 PCIX MB /pci@7c0/pci@0/pci@8/network network-pci108e,1648
MB/NET-1 PCIX MB /pci@7c0/pci@0/pci@8/network network-pci108e,1648
MB/PCIX PCIX MB /pci@7c0/pci@0/pci@8/scsi@2 scsi-pci1000,50 LSI,1064

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

2. One EJB App was deployed on the cluster when these log entries are generated.

Comment by Harshad Vilekar [ 06/Jan/11 ]

One more data point: twonode-twoinstance-server-trace.log

for following configuration:

asadmin list-instances --long
NAME HOST PORT PID CLUSTER STATE
in2 localhost 8363 9059 c1 running
in1 intg2t1000 8107 3083 c1 running

No apps are deployed.

Comment by Hong Zhang [ 07/Jan/11 ]

Harshad:
Thanks for re-run the test. In this test, the gui application loading took 37.368s with container initialization took 11.066s, and component loading in the container took 21.586s.

M1. [#|2011-01-06T19:03:01.872-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=130;_ThreadName=Thread-1;|Container : com.sun.enterprise.web.WebContainer Mark BEFORE_CONTAINER_SETUP at 3972|#]

M2. [#|2011-01-06T19:03:01.882-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=130;_ThreadName=Thread-1;|Mark CONTAINERS_SETUP_DONE at 15038|#]

M3. [#|2011-01-06T19:03:01.913-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=130;_ThreadName=Thread-1;|Container : web Mark START at 15705|#]

M4. [#|2011-01-06T19:03:01.914-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=130;_ThreadName=Thread-1;|Container : web Mark STARTED at 37291|#]

Comment by Harshad Vilekar [ 07/Jan/11 ]

Here are the updated results (take 2) showing Admin Console load time, with clean environment:

1. all test machines now use locally installed jdk (earlier, JDK was installed in remote NFS mounted directory)
2. all test machines rebooted, with no other processes running
3. using latest nightly build
4. no apps deployed
5. browser catch cleared, unwanted plugins removed, browser restarted.
------------------
Config 2.1: DAS only - no secure admin:
Time: 105 secs
Log File: dasonly-nosec-trace.log
------------------
Config 2.2: DAS only - secure admin enabled.
Time: 110 secs
Log File: dasonly-sec-trace.log
------------------
Config 2.3: Cluster on Same host: DAS + two instances, no secure admin:
NAME HOST PORT PID CLUSTER STATE
in2 localhost 8363 1236 c1 running
in1 localhost 8107 1240 c1 running

Time taken: 105 secs
Log file: single-host-two-instance-nosec-trace.log
------------------
Config 2.4: Cluster on Same host: DAS + two instances, secure admin enabled:
NAME HOST PORT PID CLUSTER STATE
in2 localhost 8363 1873 c1 running
in1 localhost 8107 1877 c1 running

Time taken: 125 seconds
Log file: single-host-two-instance-sec-trace.log
-------------------------------------------------

Config 2.5: Cluster on two hosts (host1: DAS + in1, host2: in2), secure admin enabled:
NAME HOST PORT PID CLUSTER STATE
in2 localhost 8363 2008 c1 running
in1 intg2t1000 8107 997 c1 running

Time taken: 130 seconds
Log file: two-host-two-instance-sec-notrace.log (no trace information included)
-------------------------------------------------

Server logs for config 2.1 to 2.5 attached: server-logs-take2.jar

Comment by Hong Zhang [ 07/Jan/11 ]

Harshad: thanks for re-running the tests!
The time in the tests are pretty close to each other now, with the times slightly longer when the secure admin is enabled.
The gui application loading times are pretty close to each other too: 40.124s, 36.523s, 40,928s, 40,036s, 34,714s.
So it now seems there is no significant performance degrading from DAS-only scenario to cluster scenarios which are consistent with what were observed on other platforms.

The console accessing time do seem pretty long in the tests (105s-130s), but maybe this is expected with the machine configuration (resource constraint)?
System clock frequency: 200 MHz
Memory size: 2040 Megabytes

Comment by Nazrul [ 10/Jan/11 ]

This issue happens on a specific hardware. Should we exclude this from 3.1?

We should spend time on this and fix it during 3.2.

Comment by Nazrul [ 11/Jan/11 ]

Excluding from 3.1 count.

Comment by Chris Kasso [ 26/Jan/11 ]

After discussing this with the submitter we decided to clear the "blocker" status.

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes. Note at all clear what wants to be said here, either in terms of description or workaround. Is it really necessary to include in the Release Notes?

Comment by Harshad Vilekar [ 23/Mar/11 ]

No need to release note this issue. I'm Including part of the offline email thread:

— From: Chris Kasso -----------
I would prefer not to Release Note this issue. It is unlikely to generate a customer call and most customers won't see the issue. There is also no workaround.
----------------------

Comment by Anissa Lam [ 31/Oct/11 ]

assign go Siraj as he is leading the GUI initial performance improvement effort.

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

We've done all the work in this area that is planned for 3.1.2. Removing the 3_1_2-review tag (see linked bugs for details).

Comment by Anissa Lam [ 18/Jan/12 ]

The issue is filed about the startup console time between DAS only and DAS with clusters.
It didn't mention whether the cluster's instances are running or not when the server startups and GUI launched. So, i run with both instances running or not.

I do not have a T1000 to run on, so i tried this on a Solaris 10 x86

=====================
This is run on a Solaris 10, x86 machine, 3.1.2 b17.

DAS only, first launch - 20sec; console-preloaded - 10 sec.

Case 1: cluster with 2 instances (both using localhost-domain1)
when instances are not running. console preloaded - 8 sec
when instances are running. console preloaded - 9 sec.

Case 3: cluster with 2 instances ( one on localhost-domain1, one on another solaris host)
when instances are not running, console-preloaded - 10sec
when instances are are running, console-preloaded - 9 sec





[GLASSFISH-18320] [Regression] Addition of AdminConsoleStartupService broke EJB embedded Container Created: 03/Feb/12  Updated: 23/Apr/15

Status: Reopened
Project: glassfish
Component/s: admin
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: marina vatkina Assignee: sirajg
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: javaee_ri_target

 Description   

EJB embeddable container suppresses services that won't be necessary for regular testing of local EJBs. One of such services is a Web container. We do it by modifying domain.xml on the fly and using that temporary version during the run.

02/03/2012 hudson build (http://hudson-sca.us.oracle.com/job/ejb-devtests-v3/623/) failed with

java.lang.IllegalStateException: Can't operate without at least one <network-listener>
[java] at com.sun.enterprise.config.util.ServerHelper.getAdminListener(ServerHelper.java:164)
[java] at com.sun.enterprise.config.serverbeans.Config$Duck.getAdminListener(Config.java:460)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at java.lang.reflect.Method.invoke(Method.java:597)
[java] at org.jvnet.hk2.config.Dom.invokeDuckMethod(Dom.java:961)
[java] at org.jvnet.hk2.config.Dom.invoke(Dom.java:914)
[java] at org.glassfish.config.support.TranslatedConfigView.invoke(TranslatedConfigView.java:131)
[java] at $Proxy30.getAdminListener(Unknown Source)
[java] at com.sun.enterprise.v3.admin.adapter.AdminEndpointDecider.setValues(AdminEndpointDecider.java:118)
[java] at com.sun.enterprise.v3.admin.adapter.AdminEndpointDecider.<init>(AdminEndpointDecider.java:84)
[java] at com.sun.enterprise.v3.admin.adapter.AdminConsoleAdapter.init(AdminConsoleAdapter.java:507)
[java] at com.sun.enterprise.v3.admin.adapter.AdminConsoleAdapter.postConstruct(AdminConsoleAdapter.java:465)

To reproduce (assuming v2/appserv-tests lib/ and config/ are checked out):
cd v2/appserv-tests/devtests/ejb/ejb31/embedded
ant all-report



 Comments   
Comment by Tom Mueller [ 07/Feb/12 ]

Marina,
Do you know when this broke? The recent changes to AdminConsoleAdapter do not change this code that eventually calls ServerHelper.getAdminListener, and ServerHelper hasn't changed since last July.

Can you provide the details of the changes you make to domain.xml. From the exception, it appears as though the admin-listener network-listener has been removed.

Comment by Tom Mueller [ 07/Feb/12 ]

Masoud, this is actually a zero-config issue. Here, we have a situation where the embedded tests have removed the network listener named "admin-listener" and the server (in AdminConsoleAdapter) throws an exception because of it. I expect AdminAdapter would also have a problem here.

We need a design decision here as to whether some minimal configuration is required to have the admin interface (on port 4848) come up or whether it should come up by default if the config information isn't there. I would think that we would want to be able to configure a server that doesn't have an admin interface but this should be discussed.

Comment by marina vatkina [ 07/Feb/12 ]

Tom,

The test started failing on 02/03/2012 (8am). So the change was made in the 24 hours prior to that.

Embedded EJB container is intended for testing EJBs so should start fast and have the least possible outside containers started (e.g. unless a WAR file is being deployed, the web container should not start). You can find all the transformations that are done in ejb/ejb-container/src/main/java/org/glassfish/ejb/embedded/DomainXmlTransformer.java. They were discussed back then with Jerome and Ken Saks.

Also note that there is no way to get currently to the GlassFish API when using embeddable EJB container (http://docs.oracle.com/javaee/6/api/javax/ejb/embeddable/EJBContainer.html).

Comment by Tom Mueller [ 08/Feb/12 ]

The root cause of this was the addition of the AdminConsoleStartupService which was added to the trunk on 2/2/12 in revision 52405.

Assigning to Siraj for an immediate fix since this is breaking the embedded EJB tests.

Siraj, the AdminConsoleStartupService must take into account a configuration where no admin-listener is configured. With the current implementation, AdminConsoleStartupService eventually causes a call to ServerHelper.getAdminListener which throws an exception if there is no admin listener configured. AdminConsoleStartupService needs to handle this exception.

This fix is needed on the trunk.

Comment by sirajg [ 09/Feb/12 ]

The test passes in 3.1.2. In the embedded case, the adapter code is not invoked in 3.1.2, but it is invoked on the trunk.

Comment by sirajg [ 13/Feb/12 ]

Handle the case when no network listeners are found. Revision 52563

Comment by marina vatkina [ 15/Mar/12 ]

The latest change to ServerHelper broke it again





[GLASSFISH-17839] Applications page performance issues related to large number of deployments. Created: 28/Nov/11  Updated: 17/Oct/12

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.1
Fix Version/s: future release

Type: Improvement Priority: Critical
Reporter: Anissa Lam Assignee: sirajg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7ri_cleanup_deferred

 Description   

This was brought up in the forum discussion: http://forums.java.net/node/867604
However, the following discussion in the email wasn't captured in the forum.

=========================
On 11/24/2011 05:56 PM, Anissa Lam wrote:
> Hi Bernhard,
> On 11/24/11 3:51 AM, Bernhard Thalmayr wrote:
>> A 'DAS' (domain administration server) corresponsds to one 'domain'
>>
>> The applications will be deployed into the domain repository (hosted
>> by the 'DAS') and an application reference will exist for every
>> instance the application should be available.
>>
>> The admin-console you become somewhat messy (nearly unusable) if you
>> have 100 web-apps deployed (you may need to use the CLI instead).
>>
> Can you elaborate on the above statement ? Is it performance, UI, layout
> of pages or workflow that makes you feel that way ? We strive to improve
> user experience on the console and your feedback and suggestion will be
> greatly appreciated.

Thanks for your attention Anissa.

For every application deployed the console tries to determine the state f it on every server. This can take a very long time.

You just get the hint 'long running process detected' (or similar).

Currently I have about 25 application deployed and IMHO it's already almost usable. Personally I don't mind to much because I'm using the CLI anyway, but the developers are always using the console and they are complaining a lot.

Although I'm using GF 3.1.1 I still have issues with 'running out of file handles' due to REST-calls not cleaning up the sockets correctly - similar (http://java.net/jira/browse/GLASSFISH-16672). This error is very nasty and makes the console almost unusable if you can not tweak the FD limits at the OS level.
(Of course I set the 'linger' stuff ... but this does not help at all)

Regards,
Bernhard

=================
Think this is probably due to the time for detecting the enabled status or each application and its application-ref.
May need to asynchronously update the status when they are available, instead of waiting for everything before displaying the page.



 Comments   
Comment by Anissa Lam [ 28/Nov/11 ]

target version set to 4.0 for now. Will try our best to address this in 3.1.2.

Comment by Tom Mueller [ 17/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 issues 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-10975] Log viewer page lacks a help button Created: 11/Nov/09  Updated: 19/Oct/12

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

Type: Improvement Priority: Major
Reporter: Kim Haase Assignee: sirajg
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,975
Status Whiteboard:

3.1-exclude

Tags: 3_1-exclude

 Description   

There's an online help topic for the Log Viewer page, and a link to it in
common/src/main/resources/org/glassfish/common/admingui/Helplinks.properties:

logViewer=ref-logviewer.html

However, there is no way to view this link from the Log Viewer page itself. The
page can be reached only from the TOC in the help window. This should be fixed
in the next release if possible.



 Comments   
Comment by Anissa Lam [ 12/Nov/09 ]

We don't have a Help button for logviewer in v2 either.
So, not a regression. Will address this after v3.

thanks.

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 Anissa Lam [ 25/Jul/10 ]

Assign to Ken. Doc team will be affected as i don't know if there is any OLH
for logviewer now.

Comment by Kim Haase [ 26/Jul/10 ]

There is an OLH topic for the log viewer, as stated in the issue description.
There just isn't a link to it from the viewer itself. So the doc team doesn't
have to do anything unless the content of the viewer changes.

Comment by Mike Fitch [ 27/Jul/10 ]

For the log viewer page, the online help key is ref-logviewer and, as indicated
in the initial description, the entry

logViewer=ref-logviewer.html

is already in
common/src/main/resources/org/glassfish/common/admingui/Helplinks.properties.

Comment by Anissa Lam [ 29/Jul/10 ]

whoever works on the logviewer will need to add this help button.

Comment by kenpaulsen [ 07/Oct/10 ]

Updating MS

Comment by sirajg [ 10/Nov/10 ]

This is not a high priority and was not available in previous release.

Comment by Chris Kasso [ 08/Dec/10 ]

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





[GLASSFISH-13898] ear files checked in into src tree Created: 08/Oct/10  Updated: 18/May/11

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

Type: Bug Priority: Major
Reporter: marina vatkina Assignee: sirajg
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: 13,898
Tags: 3_1-exclude, 3_1-next

 Description   

admingui/devtests/src/test/resources/ejb-timer-sessiontimerApp.ear
admingui/devtests/src/test/resources/ejb-ejb30-hello-sessionApp.ear

there is also a .war file



 Comments   
Comment by Nazrul [ 11/Nov/10 ]

Changing target milestone from 3.1_ms08 to not determined

Comment by Nazrul [ 29/Nov/10 ]

Getting help from Siraj. We may consider moving the console test src code outside the main workspace (faster build time for everyone).

Comment by Jason Lee [ 07/Dec/10 ]

For what it's worth, the only effect these tests have on anyone is the time it takes to check them out initially. They are not part of the build, but must be compiled and run separately.

Comment by Anissa Lam [ 08/Dec/10 ]

Markthis as 3.1-exclude.
This won't make it to MS7.
If we have the resource and get approval after MS7, we may reconsider this.





[GLASSFISH-2929] HTTP_BINDING causes Web Services panel in Admin UI to fail (does not show other deployed service) Created: 26/Apr/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services_mgmt
Affects Version/s: 9.1pe
Fix Version/s: not determined

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

Operating System: All
Platform: Linux


Attachments: Text File restful-web.war    
Issuezilla Id: 2,929

 Description   

I have two API services being deployed through the Glassfish Autodeploy. One is
a standard SOAP service. IF deployed by itself, it will show up in the Web
Services page on the Admin server.

If I deploy my REST based service which is using HTTP_BINDING, neither service
will show up in the Admin page. Error messages about Descriptors shows up in
the log files..

Both services are still able to be invoked.

Version: Glassfish V2 b43

Example Code:
@WebServiceProvider(serviceName = "TestService")
@ServiceMode(value = Service.Mode.PAYLOAD)
@BindingType(value = HTTPBinding.HTTP_BINDING)
public class TestService implements Provider<Source>
{
public Source invoke(Source source)

{ return source; }

}

Logs:
[#|2007-04-26T15:33:29.872-0700|WARNING|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=httpWorkerThread-8023-3;_RequestID=13949758-cfa7-40f0-9387-9c5b294e1e66;|com.sun.enterprise.admin.mbeans.J2EEModule:ge
tStringForDDxml FileNotFoundException
/u/cparis/devel.p4/api/glassfish/domains/api/generated/xml/j2ee-modules/platform/null|#]

[#|2007-04-26T15:33:29.880-0700|WARNING|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=httpWorkerThread-8023-3;_RequestID=13949758-cfa7-40f0-9387-9c5b294e1e66;|com.sun.enterprise.admin.mbeans.J2EEModule:ge
tStringForDDxml FileNotFoundException
/u/cparis/devel.p4/api/glassfish/domains/api/generated/xml/j2ee-modules/platform/null|#]

[#|2007-04-26T15:33:29.881-0700|WARNING|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=httpWorkerThread-8023-3;_RequestID=13949758-cfa7-40f0-9387-9c5b294e1e66;|Descriptors
could not be loaded for module pl
atform : null.|#]



 Comments   
Comment by gfbugbridge [ 26/Apr/07 ]

<BT6550920>

Comment by sirajg [ 01/May/07 ]

Discussed with Anissa, transferring to admin gui for evaluation. If there is no
WSDL, certain functions, such as show WSDL and test, will not work. However the
list of non-REST services should be displayed.

Comment by Anissa Lam [ 01/May/07 ]

Please attach the app if possible. This will help us debug and ensure the fix.

Comment by Anissa Lam [ 15/May/07 ]

Admin GUI calls the backend to get the list of web services for displaying the
tree node and also to construct the web services table.
The API used is:
return AMXUtil.getWebServiceMgr().getWebServiceEndpointKeys();

I see that once i call this API, the following error is logged

[#|2007-05-15T15:13:34.230-0700|WARNING|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=14;_ThreadName=httpWorkerThread-4848-0;_RequestID=0acb9608-f7b2-45fb-9ec8-608452baa2ba;|com.sun.enterprise.admin.mbeans.J2EEModule:getStringForDDxml
FileNotFoundException
/Users/anilam/Awork/as91/publish/glassfish/domains/domain1/generated/xml/j2ee-modules/restful-web/null|#]

[#|2007-05-15T15:13:34.254-0700|WARNING|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=14;_ThreadName=httpWorkerThread-4848-0;_RequestID=0acb9608-f7b2-45fb-9ec8-608452baa2ba;|Descriptors
could not be loaded for module restful-web : null.|#]

and the restful-web is not returned as one of the web services.
This is like the error reported by the submitter.

GUI displays whatever is returned by the backend. Transferring this to web
services mgt.

Comment by Anissa Lam [ 15/May/07 ]

Created an attachment (id=915)
web services war to reproduce this error

Comment by Anissa Lam [ 15/May/07 ]

The war file is from
glassfish/appserv-tests/devtests/web service/annotation/restful

Comment by sirajg [ 25/May/07 ]

Standard SOAP services are displayed but REST services are not. This is because
the code fails looking for descriptors

Comment by sirajg [ 25/May/07 ]

This is partially fixed. The non REST web services are displayed in admin gui.
REST services are not displayed because the code :
public Map getWebServicesMap() {
....
....

try

{ wsInfoListInMod = wsInfoPvdr.getWebServiceInfo(descLoc, propMap); }

catch ( Exception e)

{ // log warnin String msg =_stringMgr.getString("ModInfoNotFound",appName + " : " + e.getMessage()); _logger.log(Level.WARNING, msg); }

....
..

in com.sun.enterprise.admin.wsmgmt.WebServiceMgrBackEnd
results in the above exception, when xml files are not found, which would be the
case with REST services. Fixing this could potentially cause some regressions.
So downgrading to P4 for now, and also because non REST services are being
displayed. Please raise priority if this is considered a show stopper.
in

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-3907] web services management not working Created: 10/Dec/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services_mgmt
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: granat Assignee: sirajg
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: 3,907
Status Whiteboard:

as91ur1-na


 Description   

Hi,

I tried to follow the technical article about Managing and Monitoring Web
Services in Project GlassFish
(http://developers.sun.com/appserver/reference/techart/ws_mgmt.html) with the
small change that I deploy the web service as a war file and not as an
autodeploy compilation.

The Web Service works without a glitch and is shown in the top level point "web
service". The test works as well.

I am currently working with a more complex architecture than in the example:

  • The Admin Server doesn't hold any applications and is only used for
    administrative purposes
  • The Applications are deployed on a server instance loaded via a nodeagent
    (same machine, but that shouldn't be a problem if it were another one).

I have a few Problems with the whole thing:
1) The monitoring of the web service doesn't work. I can change the level as I
want, the messages and the traffic is never shown.

2) the wsdl url in the "Web Services> HelloWorld > General" Page points to the
admin server with port 80
(http://testserver.mycp.com/WebServiceTest/HelloWorldService?wsdl) which is not
really pointing anywhere as I don't have ANY server on port 80 (I have a web
server there and I get an error that the object wasn't found, which is actually
correct).

3) When I change the context root of the web service application (from
/HelloWorld to /test/hello as an example). The Test button isn't relinked to the
new URL and the test doesn't work anymore.

4) The URL of the test application hast a slash too much (it still works, isn't
really nice though...):
http:/testserver.mycp.com:38080//WebServiceTest/HelloWorldService?Tester



 Comments   
Comment by basler [ 10/Dec/07 ]

Not a 91ur1 release stopper

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/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-4956] NullPointerException with high-level monitoring of one-way web service Created: 30/Apr/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services_mgmt
Affects Version/s: v2.1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: Tim Quinn Assignee: sirajg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Attachments: Text File npeExample.log    
Issuezilla Id: 4,956

 Description   

Message monitoring (level=high) triggers NPEs when a one-way (no return value)
method/service is called.



 Comments   
Comment by Tim Quinn [ 13/May/08 ]

Created an attachment (id=1498)
Excerpt from server.log showing NPE

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/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-923] Monitor stops capturing messages Created: 10/Aug/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services_mgmt
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: brviking Assignee: sirajg
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: File jwswar-web.war    
Issuezilla Id: 923

 Description   

After redeploy a web service, even with web service monitor configured to "high"
it stops capturing messages (but still capture statistics).



 Comments   
Comment by sv96363 [ 11/Aug/06 ]

I checked in some code right on 9.0 release, which should resolve this issue.
That fix should be in tip of the tree and should be avialable in the latest
glassfish builds. Assigning to me (Satish), so I re-produce verify that. If this
bug still persists, will fix it.

Comment by sv96363 [ 06/Sep/06 ]

Fixed in UR1, build 16 or later.

Comment by sv96363 [ 07/Sep/06 ]

Not completely fixed. Re-opening.

Comment by sv96363 [ 07/Sep/06 ]

Created an attachment (id=424)
Sample web module containing web service

Comment by sv96363 [ 07/Sep/06 ]

When a web module is getting re-deployed, / unloadWebModule/ method of
/WebContainer.java / is getting called. However /TomcatApplicationLoader/ or
other loader's unloader function is not getting called. Should not these be
called as well?

I am copying Hong for comments.

Procedure to reproduce:

1). asadmin deploy jwswar-web.war
2). asadmin deploy jwswar-web.war --> no unload callback on the loaders.

Comment by sv96363 [ 13/Sep/06 ]

Comments from Binod:

Typically XXXDeployEventListener uses a loader to load and unload the module.

Webmodules doesnt follow the normal loader heirarchy used for other modules
like ejb and connectors. There is an RFE assigned to Jan Luehe to address this
issue. The last I heard was that it is planned for 9.2.

You can consider adding your stuff directly on the WebModuleEventListener.
That should work.

DummyWebLoader was introduced for on-demand initialization and it is
tested only on the loading part.

Comment by sv96363 [ 17/Jan/07 ]

During re-deploy a new stats provider was created, however monitoring mbeans
were not re-loaded. Fix this issue. Leaving this issue as p3 as it requires
unloading of monitoring mbeans during undeploy of the module.

Checking in EndpointRegistration.java;
/cvs/glassfish/admin/ws-mgmt/src/java/com/sun/enterprise/admin/wsmgmt/lifecycle/EndpointRegistration.java,v
<-- EndpointRegistration.java
new revision: 1.10; previous revision: 1.9
done

Comment by sirajg [ 15/May/07 ]

assigning to siraj

Comment by gfbugbridge [ 01/Aug/07 ]

<BT6588065>

Comment by sirajg [ 02/Aug/07 ]

Not a release stopper, so downgrading to P4. After redeploying the app, for
monitoring the web service to work, the server has to be restarted.

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.





Generated at Mon Feb 20 00:08:20 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.