[GLASSFISH-12942] Mac: restart fails for instance started with start-instance Created: 10/Aug/10  Updated: 17/Apr/15  Resolved: 29/Oct/10

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: easarina Assignee: Joe Di Pol
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac System 9.0
Platform: Sun


Issue Links:
Related
is related to GLASSFISH-21113 GlassFish 4 does not start on OS X 10.10 Resolved
is related to GLASSFISH-21349 GlassFish 4 does not start on OS X 10... Resolved
Issuezilla Id: 12,942

 Description   

Build 15 08/10. Mac: Darwin asqe-xserver-1.sfbay.sun.com 9.8.0 Darwin Kernel
Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

Executed from DAS machine against a remote machine such commands:

asadmin create-node-ssh --nodehost asqe-xserver-2.sfbay.sun.com
asqe-xserver-2.sfbay.sun.com

Command create-node-ssh executed successfully.

sadmin create-instance --node asqe-xserver-2.sfbay.sun.com in3
Port Assignments for server instance in3: 
JMX_SYSTEM_CONNECTOR_PORT=28688
JMS_PROVIDER_PORT=27678
ASADMIN_LISTENER_PORT=24850
HTTP_LISTENER_PORT=28082
IIOP_LISTENER_PORT=23702
IIOP_SSL_LISTENER_PORT=23822
HTTP_SSL_LISTENER_PORT=28183
IIOP_SSL_MUTUALAUTH_PORT=23922

Command create-instance executed successfully

asadmin start-instance in3

Command start-instance executed successfully.

asadmin restart-instance in3
The instance, in3, was restarted.  !!!! 
Waiting for Instance Status Implementation -- There is no way of knowing for
sure yet.  Dont file bugs until after August 16 2010 !!!trying to

Command restart-instance executed successfully.

But really the instance was not started, see messages from server.log bellow.
But if the same instance stop/start several times, it would be restarted
successfully. But, I've reproduced this issue many times, never would be
restarted after first start. I did not see this issue on Linux and Solaris.

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

[#|2010-08-10T11:53:06.381-0700|INFO|glassfish3.1|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin.cluster|_ThreadID=15;_ThreadName=Thread-1;|Server
restart initiated|#]

[#|2010-08-10T11:53:06.485-0700|INFO|glassfish3.1|org.jvnet.hk2.osgiadapter|_ThreadID=15;_ThreadName=Thread-1;|Stopping
com.sun.enterprise.v3.server.AppServerStartup@2a7d2796|#]

[#|2010-08-10T11:53:15.934-0700|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=15;_ThreadName=Thread-1;|JMXStartupService:
Stopped JMXConnectorServer:
service:jmx:rmi://asqe-xserver-2.SFBay.Sun.COM:28688/jndi/rmi://asqe-xserver-2.SFBay.Sun.COM:28688/jmxrmi|#]

[#|2010-08-10T11:53:15.937-0700|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=15;_ThreadName=Thread-1;|JMXStartupService
and JMXConnectors have been shut down.|#]

[#|2010-08-10T11:53:15.937-0700|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=15;_ThreadName=Thread-1;|Shutdown
procedure finished|#]



 Comments   
Comment by Byron Nevins [ 10/Aug/10 ]

I have no access to a MAc. Can you assign to someone that does? Or get me a Mac?

Comment by Byron Nevins [ 28/Sep/10 ]

I have no Mac. Reassign to Tom for distribution to a Mac owner.

Comment by Joe Di Pol [ 08/Oct/10 ]

I have reproduced this. My setup:

DAS running on Solaris. Instance running on Mac.

If the instance on the Mac is started by running the start-instance remote
command, then running the restart-instance remote command will bring the
instance down instead of restarting it.

If the instance on the Mac is started by running start-local-instance directly
on the Mac, then running restart-instance via the DAS works as expected.

This works fine for instances on Linux or Solaris, so the problem does appear to
be unique to the Mac.

Running start-instance/stop-instance/start-instance/stop-instance works fine.
It's just restart that is having trouble.

Comment by Joe Di Pol [ 08/Oct/10 ]

Latest update: in the failed case the instance is getting to JavaClassRunner
which creates a command line that looks valid (and I have verified it works when
run manually on the command line):

"/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bin/java" "-cp"
"/Users/dipol/glassfish3/glassfish/modules/admin-cli.jar" "-DAS_RESTART=true"
"com.sun.enterprise.admin.cli.AsadminMain" "--host" "sidewinder" "--port" "4848"
"--secure=false" "--terse=false" "--echo=false" "--interactive=false"
"start-local-instance" "--verbose=false" "--debug=true" "--nosync=false"
"--node" "n1" "i1"

This is then handed off to ProcessBuilder:

        ProcessBuilder pb = new ProcessBuilder(cmdline);
        Process p = pb.start();

But after the pb.start() the exit status in Process is "1". So it appears as
though the command is executing but then encountering and error. Next step is to
capture the stderr/out from the command and see if there is anything useful.

Comment by Joe Di Pol [ 11/Oct/10 ]

The newly (re)started instance is getting an UnkownHostException when it
attempts to synchronize with the DAS. For some reason the restarted instance
can't resolve the DAS hostname – which it had no problem resolving at instance
startup (and an UnknownHostException during synchronization will cause an
instance to not start up). Here is the exception stack trace:

Got exception: org.glassfish.api.admin.CommandException: No remote server named
sidewinder. Is that the correct host name?
com.sun.enterprise.admin.remote.RemoteAdminCommand.doHttpCommand(RemoteAdminCommand.java:621)
com.sun.enterprise.admin.remote.RemoteAdminCommand.fetchCommandModel(RemoteAdminCommand.java:853)
com.sun.enterprise.admin.remote.RemoteAdminCommand.getCommandModel(RemoteAdminCommand.java:259)
com.sun.enterprise.admin.cli.remote.RemoteCommand.prepare(RemoteCommand.java:295)
com.sun.enterprise.admin.cli.CLICommand.execute(CLICommand.java:240)
com.sun.enterprise.admin.cli.remote.RemoteCommand.executeAndReturnOutput(RemoteCommand.java:383)
com.sun.enterprise.admin.cli.cluster.SynchronizeInstanceCommand.synchronizeFiles(SynchronizeInstanceCommand.java:302)
com.sun.enterprise.admin.cli.cluster.SynchronizeInstanceCommand.synchronizeInstance(SynchronizeInstanceCommand.java:147)
com.sun.enterprise.admin.cli.cluster.StartLocalInstanceCommand.executeCommand(StartLocalInstanceCommand.java:124)
com.sun.enterprise.admin.cli.CLICommand.execute(CLICommand.java:262)
com.sun.enterprise.admin.cli.AsadminMain.executeCommand(AsadminMain.java:284)
com.sun.enterprise.admin.cli.AsadminMain.main(AsadminMain.java:223)

cause: java.net.UnknownHostException: sidewinder
java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177)
java.net.SocksSocketImpl.connect(SocksSocketImpl.java:432)
java.net.Socket.connect(Socket.java:529)
java.net.Socket.connect(Socket.java:478)
sun.net.NetworkClient.doConnect(NetworkClient.java:163)
sun.net.www.http.HttpClient.openServer(HttpClient.java:394)
sun.net.www.http.HttpClient.openServer(HttpClient.java:529)
sun.net.www.http.HttpClient.<init>(HttpClient.java:233)
sun.net.www.http.HttpClient.New(HttpClient.java:306)
sun.net.www.http.HttpClient.New(HttpClient.java:323)
sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:860)
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:801)
sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:726)
com.sun.enterprise.admin.remote.RemoteAdminCommand$2.doCommand(RemoteAdminCommand.java:859)
com.sun.enterprise.admin.remote.RemoteAdminCommand.doHttpCommand(RemoteAdminCommand.java:556)
com.sun.enterprise.admin.remote.RemoteAdminCommand.fetchCommandModel(RemoteAdminCommand.java:853)
com.sun.enterprise.admin.remote.RemoteAdminCommand.getCommandModel(RemoteAdminCommand.java:259)
com.sun.enterprise.admin.cli.remote.RemoteCommand.prepare(RemoteCommand.java:295)
com.sun.enterprise.admin.cli.CLICommand.execute(CLICommand.java:240)
com.sun.enterprise.admin.cli.remote.RemoteCommand.executeAndReturnOutput(RemoteCommand.java:383)
com.sun.enterprise.admin.cli.cluster.SynchronizeInstanceCommand.synchronizeFiles(SynchronizeInstanceCommand.java:302)
com.sun.enterprise.admin.cli.cluster.SynchronizeInstanceCommand.synchronizeInstance(SynchronizeInstanceCommand.java:147)
com.sun.enterprise.admin.cli.cluster.StartLocalInstanceCommand.executeCommand(StartLocalInstanceCommand.java:124)
com.sun.enterprise.admin.cli.CLICommand.execute(CLICommand.java:262)
com.sun.enterprise.admin.cli.AsadminMain.executeCommand(AsadminMain.java:284)
com.sun.enterprise.admin.cli.AsadminMain.main(AsadminMain.java:223)

Comment by Joe Di Pol [ 21/Oct/10 ]

I've verified that the restarted instance in the failure case gets an
UnknownHostException when doing:

addr = InetAddress.getByName(host);

I then compared the system properties between the failing case (instance started
via start-instance over SSH, then restarted) and the working case (instance
started locally via start-local-instance, then restarted). There are some
differences, and the one that jumps out is that in the failing case the
user.name property is set to "?".

diff working.systemprops failing.systemprops
3c3
< WALL_CLOCK_START:1287703107052
---
> WALL_CLOCK_START:1287702744900
11d10
< ftp.nonProxyHosts:local|*.local|169.254/16|*.169.254/16
13d11
< http.nonProxyHosts:local|*.local|169.254/16|*.169.254/16
21c19
< java.io.tmpdir:/var/folders/2K/2KLZjdblGxKJ03qWNa3H6E++41E/-Tmp-/
---
> java.io.tmpdir:/tmp
47d44
< socksNonProxyHosts:local|*.local|169.254/16|*.169.254/16
58c55
< user.country:US
---
> user.country:
62c59
< user.name:dipol
---
> user.name:?
Comment by Joe Di Pol [ 22/Oct/10 ]

Observations from today's investigation:

o If you ssh to the Mac and run start-local-instance, and stay logged in over
SSH then all is well. You can restart the instance multiple times. But as soon
as you log out of SSH, then the restarted instance fails to look up the DAS
hostname as described in this bug.

o I reproduced the problem with a smaller program that invokes itself in the
same way that GlassFish does. I compared the environment (System.getenv()) of a
"good" JVM and a "bad" JVM (when the hostname lookup fails) and saw no
significant differences.

o I looked in the JDK source to see on unix how the JDK determines the user.name
property since this shows up as "?" in the failing case. On Unix it calls
getpwuid(getuid()), and if this returns null then it sets it to "?". So in the
failing case the JVM process has trouble looking up users.

o On the Mac if I add an entry for "dipol" to /etc/passwd then the failing case
correctly sets the user.name property, but it still can't find the host. Adding
the host to /etc/hosts did not help.

o On the Mac user and host lookup are handled by the DirectoryService daemon, so
I turned on Debug for the DirectoryService daemon. In the failing case it looks
like the DirectoryService is never getting called. I see lots of traffic when
the instance is first started, but nothing when it is restarted.

So it looks like, for some reason the restarted instance that fails can't
contact the Mac's DirectoryService to look up things like users and hosts.
Next step is to try to find some system log files that may give an indication
of what error is occurring.

Comment by Joe Di Pol [ 25/Oct/10 ]

I've reproduced the problem running this shell script (see below). This seems to
confirm that a child process that is created after the ssh connection is closed
is unable to use the Mac Directory Service to look up host names. I have not
found anything useful in system logs. Note for the ping(1) command used in the
script I can work around the problem by adding the host name to /etc/hosts –
ping must fall back to that if it can't use the Mac Directory. But that doesn't
seem to work for Java's InetAddress.getByName().

Moving this to ms07 since it won't be fixed for ms06. The next step may be to
write a small native program that calls the Mac Directory Service API to see
what error is being generated in the failing case. Running a dtrace like truss
script on ping did not reveal anything useful.

# Test script that pings a host, then forks itself
# Used to demonstrate ssh/DirectoryService issue on Mac OS X
#
# Example run:
#
# scp myping.sh 10.132.178.117:/tmp/myping.sh
# ssh 10.132.178.117 /tmp/myping.sh sidewinder 5 
#
# Output is saved in /tmp/mytrace on remote system
# Run the remote system is a Mac the first ping works, but then after
# the ssh shell returns subsequent pings fail with "unknown host"

cmd=$0

_nfork=0
_logfile=/tmp/mytrace
_hostname=

if [ $# -lt 2 ]; then
    echo "Usage: myping.sh <hostname> <number_of_times_to_fork>"
    exit 1
fi

_hostname=$1
_nfork=$2

echo "$_nfork $$  ====================" >> $_logfile
ping -c 1 $_hostname >> $_logfile  2>&1

if [ $_nfork -gt 0 ]; then
    sleep 2
    _nfork=`expr $_nfork - 1`
    # The /dev/null redirects is how we get ssh to return immediately.
    # See http://www.openssh.org/faq.html#3.10
    $cmd $_hostname $_nfork </dev/null >/dev/null 2>&1  &
    exit
fi
Comment by Joe Di Pol [ 29/Oct/10 ]
Author: jfdipol
Date: 2010-10-29 18:25:01+0000
New Revision: 42302

Modified:
  
trunk/v3/admin/launcher/src/main/java/com/sun/enterprise/admin/launcher/GFLauncher.java

Log:
When we start/restart an instance on the Mac, run the JVM in the Mac OS
global bootstrap namespace using the StartupItemContext utility. This 
prevents the process from loosing its namespace context when an SSH  
session ends (or user logs out).
This fixes: 12942: Mac: restart fails for instance started with start-instance 

Modified:
trunk/v3/admin/launcher/src/main/java/com/sun/enterprise/admin/launcher/GFLauncher.java
Url:
https://glassfish-svn.dev.java.net/source/browse/glassfish-svn/trunk/v3/admin/launcher/src/main/java/com/sun/enterprise/admin/launcher/GFLauncher.java?view=diff&rev=42302&p1=trunk/v3/admin/launcher/src/main/java/com/sun/enterprise/admin/launcher/GFLauncher.java&p2=trunk/v3/admin/launcher/src/main/java/com/sun/enterprise/admin/launcher/GFLauncher.java&r1=42301&r2=42302
==============================================================================
---
trunk/v3/admin/launcher/src/main/java/com/sun/enterprise/admin/launcher/GFLauncher.java
(original)
+++
trunk/v3/admin/launcher/src/main/java/com/sun/enterprise/admin/launcher/GFLauncher.java
2010-10-29 18:25:01+0000
@@ -358,7 +358,17 @@
             return;
         }
 
-        List<String> cmds = getCommandLine();
+        List<String> cmds = null;
+        if (OS.isDarwin()) {
+            // On MacOS we need to start long running process with
+            // StartupItemContext. See IT 12942
+            cmds = new ArrayList<String>();
+            cmds.add("/usr/libexec/StartupItemContext");
+            cmds.addAll(getCommandLine());
+        } else {
+            cmds = getCommandLine();
+        }
+
         ProcessBuilder pb = new ProcessBuilder(cmds);




[GLASSFISH-11444] [Embedded] provide logging configuration for the Maven plugin Created: 15/Jan/10  Updated: 08/Mar/15  Resolved: 15/Dec/10

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: V3
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: Alexis MP Assignee: Bhavanishankar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,444

 Description   

When using the GlassFish Maven plugin, there is no way to set the java.util.logging.ConsoleHandler log level for a given instance or a given execution.
Editing the JVM's jre/lib/logging.properties (JAVA_HOME/Home/lib/logging.properties on the Mac) is merely a workaround in the embedded case.

Please provide an additional attribute to set the logging level in pom.xml (plugin <configuration>).



 Comments   
Comment by Bhavanishankar [ 08/Oct/10 ]

updating the milestone.

Comment by Bhavanishankar [ 13/Dec/10 ]

I missed this for ms7 because of its subcategory 'other'.

I may not be able to fix this beyond ms7. May be we can target this for next release.

Comment by Bhavanishankar [ 13/Dec/10 ]

moving to 'embedded' category.

Comment by Bhavanishankar [ 15/Dec/10 ]

I realized that there is no further code change required to fix this.

First of all, create a customlogging.properties file. For example, to set the log level of 'deployment' to FINEST, your customlogging.properties would look like this:

handlers= java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level = FINEST
javax.enterprise.system.tools.deployment.level = FINEST

Once you have customlogging.properties, here are the two ways to feed it into the plugin:

(1) With the additional of system properties support which I had added recently in the plugin, it is possible to do this:

<plugin>
<groupId>org.glassfish</groupId>
<artifactId>maven-embedded-glassfish-plugin</artifactId>
<version>3.1-SNAPSHOT</version>
<configuration>
<systemProperties>
<property>java.util.logging.config.file=customlogging.properties</property>
</systemProperties>
....other configurations...
</configuration>
<executions>
...executions...
</executions>
</plugin>

(2) OR, without changing the pom.xml, you can always pass the logging properties as part of the maven invocation, like this:

MAVEN_OPTS="$MAVEN_OPTS -Djava.util.logging.config.file=customlogging.properties" mvn install

Comment by gray [ 02/Jul/13 ]

Option 1 does not work for maven-embedded-glassfish-plugin 3.1.2.2
This configuration:

<systemProperties>
<property>java.util.logging.config.file=customlogging.properties</property>
</systemProperties>

completely ignored

Comment by Romain Grécourt [ 02/Jul/13 ]

updating affect version / fix version.

Comment by Romain Grécourt [ 02/Jul/13 ]

did not see that issue was resolved, please re-open first and change affect / fix versions accordingly.

Comment by harry.chan [ 08/Mar/15 ]

Same as gray, i still encountered this issue in 3.1.2.2.
BOTH options 1 and 2(from Bhavanishankar) are not working.





[GLASSFISH-14583] webservice invocation hangs using WAST and times out Created: 10/Nov/10  Updated: 30/Jul/14  Resolved: 28/Nov/10

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: Sreekanth Assignee: arjavdesai
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Attachments: File HelloTransactionWebservice.war     File HelloTransactionWebserviceClient.war     Text File jstack-1477.txt     Text File server.log     Zip Archive wsat-example-failing-logs.zip     Zip Archive wsat-example.zip    
Issuezilla Id: 14,583

 Description   

Hi,

Trying to verify wsit issue 1477 and found this.

Environment:
GlassFish Server Open Source Edition 3.1-SNAPSHOT (build 28)
Ubuntu Linux
JDK 6 update 21

I used the work around mentioned by Paul Parkinson to copy the wscoor.wsdl from
$AS_HOME/domains/domain1/applications/wstx_services/WEB-INF/wsdl to
$AS_HOME/domains/domain1/config directory.

Steps to reproduce:
1)Have fresh gf installation or new domain setup
2)Deploy the service used in wsit issue 1477.
3)Now copy the wscoor.wsdl to $AS_HOME/domains/domain1/config as mentioned above
4)Now deploy the client app
5)Run the appclient by invoking the servlet client.
6)Now you will find the service doesnt respond back immediately and after some
time, we get thread interruption.

Attaching the jstack info and server log with this issue.



 Comments   
Comment by Sreekanth [ 10/Nov/10 ]

Created an attachment (id=5404)
server log

Comment by Sreekanth [ 10/Nov/10 ]

Created an attachment (id=5405)
java thread stack trace

Comment by Sreekanth [ 10/Nov/10 ]

Created an attachment (id=5406)
Webservice war file

Comment by Sreekanth [ 10/Nov/10 ]

Created an attachment (id=5407)
war file for client app.

Comment by Sreekanth [ 10/Nov/10 ]

raising priority to p2.

Comment by paul_parkinson [ 18/Nov/10 ]

This only occurs in singleserver/coloc cases (where client and service are in
the same server).

The registerOperation call is made which is processed successfully and a
registerResponse is returned (this registerResponse impl can be found in
BaseRegistration.java) but the caller (WSATServerHelper.register method) never
seems to get the registerResponse. The issue will not reproduce when attaching
a debugger, eg, which would seem to indicate a timing related issue.

I am continuing to look into this now and have also asked for some help.

Comment by paul_parkinson [ 28/Nov/10 ]

When the server is started with -Dhttp.keepAlive=false the issue does not occur. Related email thread...

"
I think it may be running into http://monaco.sfbay.sun.com/detail.jsf?cr=6672144

This is fixed in JDK 7. I think we need to ask them to backport to SE 6. I am ccing Abhijit Saha and see if he can backport this to 6ux train.

Abhijit,

What's the process to request backporting of the above bug to SE 6 train ?

Jitu
"

Therefore, we either need the have this JDK bug backported or document this general web services (this does not seem specific to ws-at) issue/requirement/workaround to use -Dhttp.keepAlive=false when client and service are colocated.

Comment by Romain Grécourt [ 30/Jul/14 ]

I'm hitting this with current glassfish (4.0.1-b08)

Comment by Romain Grécourt [ 30/Jul/14 ]

attaching wsat-example application.

Comment by Romain Grécourt [ 30/Jul/14 ]

I'm using: glassfish 4.0.1-b08 / Mac OSX 10.7.5 / jdk1.7.0_09

Here is how to reproduce (without the workaround as pre-requisite: http.keepAlive=false):

cd [PATH]/wsat-example ; mvn install
cd [PATH]/glassfish4/glassfish
bin/asadmin start-domain
bin/asadmin deploy [PATH]/wsat-example/target/wsat-example.war
curl http://localhost:8080/wsat-example/client

The following can be noticed in the server.log:

[2014-07-30T17:21:18.128+0200] [glassfish 4.0] [SEVERE] [] [com.sun.metro.tx] [tid: _ThreadID=27 _ThreadName=http-listener-1(3)] [timeMillis: 1406733678128] [levelValue: 1000] [[
  WSAT4544: Failed state of 'ACTIVE' during WS-AT XAResource prepare for Address '<?xml version="1.0" encoding="UTF-8" standalone="yes"?><EndpointReference xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing"><Address>http://dhcp-prague08-third-floor-10-163-25-164.cz.oracle.com:8080/__wstx-services/ParticipantPortType</Address><ReferenceParameters><wsat-wsat:txId xmlns:ns2="http://schemas.xmlsoap.org/ws/2004/10/wscoor" xmlns:wsat-wsat="http://com.sun.xml.ws.tx.at/ws/2008/10/wsat">4D2-3444322D333133343330333633373333333333353335333733363330333632443330</wsat-wsat:txId><wsat-wsat:routing xmlns:ns2="http://schemas.xmlsoap.org/ws/2004/10/wscoor" xmlns:wsat-wsat="http://com.sun.xml.ws.tx.at/ws/2008/10/wsat">none</wsat-wsat:routing></ReferenceParameters></EndpointReference>' and Xid 'com.sun.xml.ws.tx.at.internal.XidImpl@300' .  This may be due to a timeout waiting for a response.]]

Creating a jvm-option for "-Dhttp.keepAlive=false" as a pre-requisite solves the problem.

Comment by Romain Grécourt [ 30/Jul/14 ]

attaching zip domain1/logs directory.

server/
server/tx/
server/tx/control
server/tx/cushion
server/tx/extent.001
server/tx/recoveryfile
server/wsat/
server/wsat/inbound/
server/wsat/outbound/
server.log

Output from client:

<!DOCTYPE html>
<html>
<head>
<title>WSSAT Client Servlet</title>
</head>
<body>
<pre>
[1]
</pre>
<pre>
javax.transaction.RollbackException
	at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:333)
	at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.commitDistributedTransaction(JavaEETransactionManagerJTSDelegate.java:185)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:859)
	at com.sun.enterprise.transaction.UserTransactionImpl.commit(UserTransactionImpl.java:212)
	at com.oracle.weblogic.DummyClient.doGet(DummyClient.java:60)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
	at java.lang.Thread.run(Thread.java:722)
</pre>
<pre>
java.lang.IllegalStateException
	at com.sun.jts.jta.TransactionManagerImpl.rollback(TransactionManagerImpl.java:374)
	at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.rollbackDistributedTransaction(JavaEETransactionManagerJTSDelegate.java:222)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.rollback(JavaEETransactionManagerSimplified.java:892)
	at com.sun.enterprise.transaction.UserTransactionImpl.rollback(UserTransactionImpl.java:238)
	at com.oracle.weblogic.DummyClient.doGet(DummyClient.java:72)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
	at java.lang.Thread.run(Thread.java:722)
</pre>
</body>
</html>




[GLASSFISH-14372] [BLOCKING] java.io.StreamCorruptedException when deserializing session on another instance. Created: 03/Nov/10  Updated: 16/Jul/13  Resolved: 08/Dec/10

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: sonymanuel Assignee: Rajiv Mordani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: other
Platform: Linux


Attachments: Text File SessionData.zip     Zip Archive testTXCPDriver-pass.zip     Zip Archive testTXCPDriver.zip     Text File testTXCPDriver.zip     Text File testTXCPDriver.zip    
Issue Links:
Dependency
depends on GLASSFISH-14735 [BLOCKING]Bundle Ids different when i... Resolved
Issuezilla Id: 14,372

 Description   

When running SFSB tests lot test scenarios fail with
java.io.StreamCorruptedException when loading/deserializing the session from
backing store. This error seems to occur on the QE setup where as on the DEV
setup it works. Analysing this a bit I think the error on the QE setup is
probably a combination of platform + JDK.

The basic scenario is

1. Send a few http requests to instance1
2. Fail instance1
3. Send another http request to instance2
4. Now instance2 will load the session from replica.
5. In the process of deserializing the session we get the StreamCorruptedException.

See the attached logs (testTXCPDriver.zip). This has shoal cache log level set
to FINE and shows steps 1 - 4 goes fine. The session is properly replicated. On
failover the replica data is correctly loaded. At the point of deserializing
this fails.
[#|2010-11-03T07:27:32.340+0000|FINE|glassfish3.1|org.shoal.ha.cache.command.load_request|_ThreadID=15;_ThreadName=Thread-1;ClassName=org.shoal.adapter.store.commands.LoadRequestCommand;MethodName=writeObject;|instance102LoadRequestCommand:35
sending load_request command for 0a1c66818654ae4b30870e1aa70bto instance108|#]

[#|2010-11-03T07:27:32.665+0000|FINE|glassfish3.1|org.shoal.ha.cache.command.load_response|_ThreadID=15;_ThreadName=Thread-1;ClassName=org.shoal.adapter.store.commands.LoadResponseCommand;MethodName=execute;|instance102
received load_response key=0a1c66818654ae4b30870e1aa70b;
value=SimpleMetadata

{version=4, lastAccessTime=1288769230862, maxInactiveInterval=1800, state.length=1470, state=SimpleMetadata->state-84_-19_0_5_115_114_0_53_111_114_103_46_103_108_97_115_115_102_105_115_104_46_119_101_98_46_104_97_46_115_101_115_115_105_111_110_46_109_97_110_97_103_101_109_101_110_116_46_70_117_108_108_72_65_83_101_115_115_105_111_110_72_76_71_-125_-73_120_111_24_2_0_0_119_8_0_0_0_0_0_0_0_-93_120_114_0_53_111_114_103_46_103_108_97_115_115_102_105_115_104_46_119_101_98_46_104_97_46_115_101_115_115_105_111_110_46_109_97_110_97_103_101_109_101_110_116_46_66_97_115_101_72_65_83_101_115_115_105_111_110_-22_32_75_-60_-102_-8_-61_-40_3_0_2_90_0_14_112_101_114_115_105_115_116_101_110_116_70_108_97_103_76_0_8_117_115_101_114_78_97_109_101_116_0_18_76_106_97_118_97_47_108_97_110_103_47_83_116_114_105_110_103_59_119_8_0_0_0_0_0_0_0_-93_120_114_0_43_111_114_103_46_97_112_97_99_104_101_46_99_97_116_97_108_105_110_97_46_115_101_115_115_105_111_110_46_83_116_97_110_100_97_114_100_83_101_115_115_105_111_110_126_62_89_94_-109_-97_117_102_3_0_12_74_0_12_99_114_101_97_116_105_111_110_84_105_109_101_90_0_5_105_115_78_101_119_90_0_7_105_115_86_97_108_105_100_74_0_16_108_97_115_116_65_99_99_101_115_115_101_100_84_105_109_101_73_0_19_109_97_120_73_110_97_99_116_105_118_101_73_110_116_101_114_118_97_108_74_0_16_116_104_105_115_65_99_99_101_115_115_101_100_84_105_109_101_76_0_10_97_116_116_114_105_98_117_116_101_115_116_0_15_76_106_97_118_97_47_117_116_105_108_47_77_97_112_59_76_0_5_98_101_75_101_121_113_0_126_0_2_76_0_2_105_100_113_0_126_0_2_76_0_15_115_105_112_65_112_112_83_101_115_115_105_111_110_73_100_113_0_126_0_2_76_0_5_115_115_111_73_100_113_0_126_0_2_76_0_7_118_101_114_115_105_111_110_116_0_40_76_106_97_118_97_47_117_116_105_108_47_99_111_110_99_117_114_114_101_110_116_47_97_116_111_109_105_99_47_65_116_111_109_105_99_76_111_110_103_59_119_8_0_0_0_0_0_0_0_-29_120_112_115_114_0_15_106_97_118_97_46_108_97_110_103_46_83_104_111_114_116_104_77_55_19_52_96_-38_82_2_0_1_83_0_5_118_97_108_117_101_119_8_-1_-1_-1_-1_-1_-1_-1_-1_120_114_0_16_106_97_118_97_46_108_97_110_103_46_78_117_109_98_101_114_-122_-84_-107_29_11_-108_-32_-117_2_0_0_119_8_-1_-1_-1_-1_-1_-1_-1_-1_120_112_0_1_115_114_0_14_106_97_118_97_46_108_97_110_103_46_76_111_110_103_59_-117_-28_-112_-52_-113_35_-33_2_0_1_74_0_5_118_97_108_117_101_119_8_-1_-1_-1_-1_-1_-1_-1_-1_120_113_0_126_0_8_0_0_1_44_16_-95_-58_104_115_113_0_126_0_10_0_0_1_44_16_-95_-40_14_115_114_0_17_106_97_118_97_46_108_97_110_103_46_73_110_116_101_103_101_114_18_-30_-96_-92_-9_-127_-121_56_2_0_1_73_0_5_118_97_108_117_101_119_8_-1_-1_-1_-1_-1_-1_-1_-1_120_113_0_126_0_8_0_0_7_8_115_114_0_17_106_97_118_97_46_108_97_110_103_46_66_111_111_108_101_97_110_-51_32_114_-128_-43_-100_-6_-18_2_0_1_90_0_5_118_97_108_117_101_119_8_-1_-1_-1_-1_-1_-1_-1_-1_120_112_0_115_113_0_126_0_15_1_115_113_0_126_0_10_0_0_1_44_16_-95_-36_19_116_0_28_48_97_49_99_54_54_56_49_56_54_53_52_97_101_52_98_51_48_56_55_48_101_49_97_97_55_48_98_115_113_0_126_0_13_0_0_0_3_116_0_6_83_70_83_66_95_49_115_114_0_94_99_111_109_46_115_117_110_46_101_106_98_46_99_111_110_116_97_105_110_101_114_115_46_69_74_66_76_111_99_97_108_79_98_106_101_99_116_73_110_118_111_99_97_116_105_111_110_72_97_110_100_108_101_114_68_101_108_101_103_97_116_101_36_83_101_114_105_97_108_105_122_97_98_108_101_76_111_99_97_108_79_98_106_101_99_116_68_101_108_101_103_97_116_101_-122_-89_-78_26_-97_-128_-117_34_2_0_5_74_0_11_99_111_110_116_97_105_110_101_114_73_100_90_0_27_105_115_79_112_116_105_111_110_97_108_76_111_99_97_108_66_117_115_105_110_101_115_115_86_105_101_119_74_0_7_118_101_114_115_105_111_110_76_0_13_105_110_116_102_67_108_97_115_115_78_97_109_101_113_0_126_0_2_76_0_10_112_114_105_109_97_114_121_75_101_121_116_0_18_76_106_97_118_97_47_108_97_110_103_47_79_98_106_101_99_116_59_119_8_0_0_0_0_0_0_0_34_120_112_1_44_16_-112_-76_-10_0_1_1_0_0_0_0_0_0_0_11_116_0_67_99_111_109_46_115_117_110_46_103_108_97_115_115_102_105_115_104_46_115_102_115_98_46_95_95_69_74_66_51_49_95_71_101_110_101_114_97_116_101_100_95_95_83_105_109_112_108_101_83_101_115_115_105_111_110_66_101_97_110_95_95_73_110_116_102_95_95_115_114_0_62_99_111_109_46_115_117_110_46_101_106_98_46_98_97_115_101_46_115_102_115_98_46_117_116_105_108_46_83_105_109_112_108_101_75_101_121_71_101_110_101_114_97_116_111_114_36_83_105_109_112_108_101_83_101_115_115_105_111_110_75_101_121_15_37_-8_-113_-64_94_31_37_2_0_3_73_0_2_105_100_74_0_6_112_114_101_102_105_120_74_0_6_115_117_102_102_105_120_119_8_0_0_0_0_0_0_0_34_120_112_0_0_0_1_31_0_-112_10_16_-95_-69_45_-18_0_5_-36_92_71_107_57_116_0_6_83_70_83_66_95_50_115_113_0_126_0_22_1_44_16_-112_-76_-10_0_0_1_0_0_0_0_0_0_0_4_116_0_66_99_111_109_46_115_117_110_46_103_108_97_115_115_102_105_115_104_46_115_102_115_98_46_95_95_69_74_66_51_49_95_71_101_110_101_114_97_116_101_100_95_95_67_104_101_99_107_112_111_105_110_116_101_100_66_101_97_110_95_95_73_110_116_102_95_95_115_113_0_126_0_26_0_0_0_1_31_0_-112_10_16_-95_-69_10_-18_0_5_-36_13_109_122_-92_116_0_7_105_110_116_65_116_116_114_115_113_0_126_0_13_0_0_0_5_112_112_120_116_0_0_120_}

;
from instance108|#]

[#|2010-11-03T07:27:32.695+0000|FINE|glassfish3.1|org.shoal.ha.cache.command.load_request|_ThreadID=15;_ThreadName=Thread-1;ClassName=org.shoal.ha.cache.impl.store.ReplicatedDataStore;MethodName=get;|/SFSBDriver:
load(0a1c66818654ae4b30870e1aa70b) Final result: SimpleMetadata

{version=4, lastAccessTime=1288769230862, maxInactiveInterval=1800, state.length=1470, state=SimpleMetadata->state-84_-19_0_5_115_114_0_53_111_114_103_46_103_108_97_115_115_102_105_115_104_46_119_101_98_46_104_97_46_115_101_115_115_105_111_110_46_109_97_110_97_103_101_109_101_110_116_46_70_117_108_108_72_65_83_101_115_115_105_111_110_72_76_71_-125_-73_120_111_24_2_0_0_119_8_0_0_0_0_0_0_0_-93_120_114_0_53_111_114_103_46_103_108_97_115_115_102_105_115_104_46_119_101_98_46_104_97_46_115_101_115_115_105_111_110_46_109_97_110_97_103_101_109_101_110_116_46_66_97_115_101_72_65_83_101_115_115_105_111_110_-22_32_75_-60_-102_-8_-61_-40_3_0_2_90_0_14_112_101_114_115_105_115_116_101_110_116_70_108_97_103_76_0_8_117_115_101_114_78_97_109_101_116_0_18_76_106_97_118_97_47_108_97_110_103_47_83_116_114_105_110_103_59_119_8_0_0_0_0_0_0_0_-93_120_114_0_43_111_114_103_46_97_112_97_99_104_101_46_99_97_116_97_108_105_110_97_46_115_101_115_115_105_111_110_46_83_116_97_110_100_97_114_100_83_101_115_115_105_111_110_126_62_89_94_-109_-97_117_102_3_0_12_74_0_12_99_114_101_97_116_105_111_110_84_105_109_101_90_0_5_105_115_78_101_119_90_0_7_105_115_86_97_108_105_100_74_0_16_108_97_115_116_65_99_99_101_115_115_101_100_84_105_109_101_73_0_19_109_97_120_73_110_97_99_116_105_118_101_73_110_116_101_114_118_97_108_74_0_16_116_104_105_115_65_99_99_101_115_115_101_100_84_105_109_101_76_0_10_97_116_116_114_105_98_117_116_101_115_116_0_15_76_106_97_118_97_47_117_116_105_108_47_77_97_112_59_76_0_5_98_101_75_101_121_113_0_126_0_2_76_0_2_105_100_113_0_126_0_2_76_0_15_115_105_112_65_112_112_83_101_115_115_105_111_110_73_100_113_0_126_0_2_76_0_5_115_115_111_73_100_113_0_126_0_2_76_0_7_118_101_114_115_105_111_110_116_0_40_76_106_97_118_97_47_117_116_105_108_47_99_111_110_99_117_114_114_101_110_116_47_97_116_111_109_105_99_47_65_116_111_109_105_99_76_111_110_103_59_119_8_0_0_0_0_0_0_0_-29_120_112_115_114_0_15_106_97_118_97_46_108_97_110_103_46_83_104_111_114_116_104_77_55_19_52_96_-38_82_2_0_1_83_0_5_118_97_108_117_101_119_8_-1_-1_-1_-1_-1_-1_-1_-1_120_114_0_16_106_97_118_97_46_108_97_110_103_46_78_117_109_98_101_114_-122_-84_-107_29_11_-108_-32_-117_2_0_0_119_8_-1_-1_-1_-1_-1_-1_-1_-1_120_112_0_1_115_114_0_14_106_97_118_97_46_108_97_110_103_46_76_111_110_103_59_-117_-28_-112_-52_-113_35_-33_2_0_1_74_0_5_118_97_108_117_101_119_8_-1_-1_-1_-1_-1_-1_-1_-1_120_113_0_126_0_8_0_0_1_44_16_-95_-58_104_115_113_0_126_0_10_0_0_1_44_16_-95_-40_14_115_114_0_17_106_97_118_97_46_108_97_110_103_46_73_110_116_101_103_101_114_18_-30_-96_-92_-9_-127_-121_56_2_0_1_73_0_5_118_97_108_117_101_119_8_-1_-1_-1_-1_-1_-1_-1_-1_120_113_0_126_0_8_0_0_7_8_115_114_0_17_106_97_118_97_46_108_97_110_103_46_66_111_111_108_101_97_110_-51_32_114_-128_-43_-100_-6_-18_2_0_1_90_0_5_118_97_108_117_101_119_8_-1_-1_-1_-1_-1_-1_-1_-1_120_112_0_115_113_0_126_0_15_1_115_113_0_126_0_10_0_0_1_44_16_-95_-36_19_116_0_28_48_97_49_99_54_54_56_49_56_54_53_52_97_101_52_98_51_48_56_55_48_101_49_97_97_55_48_98_115_113_0_126_0_13_0_0_0_3_116_0_6_83_70_83_66_95_49_115_114_0_94_99_111_109_46_115_117_110_46_101_106_98_46_99_111_110_116_97_105_110_101_114_115_46_69_74_66_76_111_99_97_108_79_98_106_101_99_116_73_110_118_111_99_97_116_105_111_110_72_97_110_100_108_101_114_68_101_108_101_103_97_116_101_36_83_101_114_105_97_108_105_122_97_98_108_101_76_111_99_97_108_79_98_106_101_99_116_68_101_108_101_103_97_116_101_-122_-89_-78_26_-97_-128_-117_34_2_0_5_74_0_11_99_111_110_116_97_105_110_101_114_73_100_90_0_27_105_115_79_112_116_105_111_110_97_108_76_111_99_97_108_66_117_115_105_110_101_115_115_86_105_101_119_74_0_7_118_101_114_115_105_111_110_76_0_13_105_110_116_102_67_108_97_115_115_78_97_109_101_113_0_126_0_2_76_0_10_112_114_105_109_97_114_121_75_101_121_116_0_18_76_106_97_118_97_47_108_97_110_103_47_79_98_106_101_99_116_59_119_8_0_0_0_0_0_0_0_34_120_112_1_44_16_-112_-76_-10_0_1_1_0_0_0_0_0_0_0_11_116_0_67_99_111_109_46_115_117_110_46_103_108_97_115_115_102_105_115_104_46_115_102_115_98_46_95_95_69_74_66_51_49_95_71_101_110_101_114_97_116_101_100_95_95_83_105_109_112_108_101_83_101_115_115_105_111_110_66_101_97_110_95_95_73_110_116_102_95_95_115_114_0_62_99_111_109_46_115_117_110_46_101_106_98_46_98_97_115_101_46_115_102_115_98_46_117_116_105_108_46_83_105_109_112_108_101_75_101_121_71_101_110_101_114_97_116_111_114_36_83_105_109_112_108_101_83_101_115_115_105_111_110_75_101_121_15_37_-8_-113_-64_94_31_37_2_0_3_73_0_2_105_100_74_0_6_112_114_101_102_105_120_74_0_6_115_117_102_102_105_120_119_8_0_0_0_0_0_0_0_34_120_112_0_0_0_1_31_0_-112_10_16_-95_-69_45_-18_0_5_-36_92_71_107_57_116_0_6_83_70_83_66_95_50_115_113_0_126_0_22_1_44_16_-112_-76_-10_0_0_1_0_0_0_0_0_0_0_4_116_0_66_99_111_109_46_115_117_110_46_103_108_97_115_115_102_105_115_104_46_115_102_115_98_46_95_95_69_74_66_51_49_95_71_101_110_101_114_97_116_101_100_95_95_67_104_101_99_107_112_111_105_110_116_101_100_66_101_97_110_95_95_73_110_116_102_95_95_115_113_0_126_0_26_0_0_0_1_31_0_-112_10_16_-95_-69_10_-18_0_5_-36_13_109_122_-92_116_0_7_105_110_116_65_116_116_114_115_113_0_126_0_13_0_0_0_5_112_112_120_116_0_0_120_}

|#]

[#|2010-11-03T07:27:32.698+0000|WARNING|glassfish3.1|javax.enterprise.system.container.web.org.glassfish.web.ha.session.management|_ThreadID=15;_ThreadName=Thread-1;|Exception
occurred in getSession
java.io.StreamCorruptedException: invalid type code: 00
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1356)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at
org.apache.catalina.session.StandardSession.deserialize(StandardSession.java:1144)
at org.apache.catalina.session.StoreBase.readSession(StoreBase.java:288)
at
org.glassfish.web.ha.session.management.ReplicationStore.getSession(ReplicationStore.java:524)
at
org.glassfish.web.ha.session.management.ReplicationStore.getSession(ReplicationStore.java:476)
at
org.glassfish.web.ha.session.management.ReplicationStore.loadFromBackingStore(ReplicationStore.java:394)
at
org.glassfish.web.ha.session.management.ReplicationStore.load(ReplicationStore.java:377)
at
org.glassfish.web.ha.session.management.ReplicationStore.load(ReplicationStore.java:372)
at
org.apache.catalina.session.PersistentManagerBase.doSwapIn(PersistentManagerBase.java:1055)
at
org.apache.catalina.session.PersistentManagerBase.swapIn(PersistentManagerBase.java:1016)
at
org.apache.catalina.session.PersistentManagerBase.swapIn(PersistentManagerBase.java:982)
at
org.apache.catalina.session.PersistentManagerBase.findSession(PersistentManagerBase.java:738)
at org.apache.catalina.session.ManagerBase.findSession(ManagerBase.java:874)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2832)
at org.apache.catalina.connector.Request.getSession(Request.java:2559)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:920)
at org.apache.catalina.core.StandardHostValve.preInvoke(StandardHostValve.java:623)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

#]

To verify that the replication / saving to backing store is correct I changed
the scenario slightly.

1. Send a few http requests to instance1
2. Fail instance1
3. Send another http request to the instance specified in JREPLICA.
4. Session is loaded from local cache.
5. Test passes.

See the attached logs (testTXCPDriver-pass.zip) for details. I think this proves
that replication and de-serialization works correctly on the same VM. Loading
the session remotely and de-serializing it seems to fail.

Please work with Ming to reproduce this error.



 Comments   
Comment by sonymanuel [ 03/Nov/10 ]

Created an attachment (id=5312)
Failed test run.

Comment by sonymanuel [ 03/Nov/10 ]

Created an attachment (id=5313)
sucessful test run.

Comment by mzh777 [ 03/Nov/10 ]

This issue occurs on OEL 5.4 and this is the tier one platform. The issue
causing 76% of EJB HA tests to fail on OEL so mark it as blocking.

Comment by mzh777 [ 03/Nov/10 ]

Add the attachment extracted from instance server logs to show that the session
data were passed from instance101 (original access instance) to instance108
(Replication) and then to instance102 after failover.

Comment by mzh777 [ 03/Nov/10 ]

Created an attachment (id=5315)
The session data extracted from instance server logs.

Comment by Rajiv Mordani [ 16/Nov/10 ]

After evaluating the bundle ids on the two systems, IT: 14735 was filed.

Comment by Rajiv Mordani [ 08/Dec/10 ]

This was caused by different bundle ids bug - which is now fixed.

Comment by alev50 [ 16/Jul/13 ]

In which version is it fixed ?





[GLASSFISH-14454] [Perf] High thread contention in felix/hk2 module while running performance benchmarks Created: 06/Nov/10  Updated: 03/Dec/12  Resolved: 09/Nov/10

Status: Closed
Project: glassfish
Component/s: other
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: amitagarwal Assignee: Jagadish
Resolution: Fixed 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-13573 [PERF] Huge regression with trade2 be... Closed
blocks GLASSFISH-13944 [PERF] specj enterprise 2010 benchmar... Closed
Issuezilla Id: 14,454
Tags: PSRBUG

 Description   

Please assign this to correct sub component.
While running Trade2 benchmark against 5th Nov nightly we have noticed pretty
high thread contention under following code path and this effects throughput
numbers a lot. Here is the stack trace,

1)
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1756)

  • waiting to lock <0x00002aaabeb43e08> (a
    org.apache.felix.framework.ModuleImpl$ModuleClassLoaderJava5)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
    at org.jvnet.hk2.config.ConfigModel.getProxyType(ConfigModel.java:152)
    at org.jvnet.hk2.config.Dom.getProxyType(Dom.java:870)
    at org.jvnet.hk2.config.Dom.createProxy(Dom.java:861)
    at org.jvnet.hk2.config.ConfigModel$SingleNode.get(ConfigModel.java:471)
    at org.jvnet.hk2.config.Dom.getter(Dom.java:955)
    at org.jvnet.hk2.config.ConfigBean._getter(ConfigBean.java:179)
    at org.jvnet.hk2.config.ConfigBean.getter(ConfigBean.java:187)
    at org.jvnet.hk2.config.Dom.invoke(Dom.java:905)
    at
    org.glassfish.config.support.TranslatedConfigView.invoke(TranslatedConfigView.java:119)
    at $Proxy21.getResources(Unknown Source)
    at
    com.sun.enterprise.connectors.ConnectorRuntime.getResources(ConnectorRuntime.java:1399)
    at
    com.sun.enterprise.connectors.ConnectorRuntime.getResources(ConnectorRuntime.java:1395)
    at
    com.sun.enterprise.connectors.util.ResourcesUtil.getResources(ResourcesUtil.java:106)
    at
    com.sun.enterprise.connectors.util.ResourcesUtil.getResource(ResourcesUtil.java:1133)
    at
    com.sun.enterprise.connectors.ConnectionManagerImpl.validateResourceAndPool(ConnectionManagerImpl.java:393)
    at
    com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:169)
    at
    com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:163)
    at
    com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:158)
    at com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:110)

2)
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1756)

  • waiting to lock <0x00002aaabeb43e08> (a
    org.apache.felix.framework.ModuleImpl$ModuleClassLoaderJava5)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
    at org.jvnet.hk2.config.ConfigModel.getProxyType(ConfigModel.java:152)
    at org.jvnet.hk2.config.Dom.getProxyType(Dom.java:870)
    at org.jvnet.hk2.config.Dom.createProxy(Dom.java:861)
    at org.jvnet.hk2.config.ConfigModel$CollectionNode$1.get(ConfigModel.java:397)
    at org.jvnet.hk2.config.ConfigBean$2.get(ConfigBean.java:200)
    at java.util.AbstractList$Itr.next(AbstractList.java:345)
    at
    com.sun.enterprise.config.serverbeans.Resources$Duck.getResources(Resources.java:105)
    at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source)
    at
    sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.jvnet.hk2.config.Dom.invokeDuckMethod(Dom.java:943)
    at org.jvnet.hk2.config.Dom.invoke(Dom.java:896)
    at
    org.glassfish.config.support.TranslatedConfigView.invoke(TranslatedConfigView.java:119)
    at $Proxy91.getResources(Unknown Source)
    at
    com.sun.enterprise.config.serverbeans.Resources$Duck.getResourceByName(Resources.java:157)
    at sun.reflect.GeneratedMethodAccessor63.invoke(Unknown Source)
    at
    sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.jvnet.hk2.config.Dom.invokeDuckMethod(Dom.java:943)
    at org.jvnet.hk2.config.Dom.invoke(Dom.java:896)
    at
    org.glassfish.config.support.TranslatedConfigView.invoke(TranslatedConfigView.java:119)
    at $Proxy91.getResourceByName(Unknown Source)
    at
    com.sun.enterprise.connectors.util.ResourcesUtil.getResource(ResourcesUtil.java:1136)
    at
    com.sun.enterprise.connectors.ConnectionManagerImpl.validateResourceAndPool(ConnectionManagerImpl.java:393)
    at
    com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:169)
    at
    com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:163)
    at
    com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:158)
    at com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:110)

3)
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1756)

  • waiting to lock <0x00002aaabe8da1a0> (a
    org.apache.felix.framework.ModuleImpl$ModuleClassLoaderJava5)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
    at com.sun.hk2.component.LazyInhabitant.loadClass(LazyInhabitant.java:1221)
    at com.sun.hk2.component.LazyInhabitant.type(LazyInhabitant.java:96)
    at org.jvnet.hk2.config.Dom.domNodeByTypeElements(Dom.java:760)
    at org.jvnet.hk2.config.ConfigModel$CollectionNode.get(ConfigModel.java:388)
    at org.jvnet.hk2.config.Dom.getter(Dom.java:955)
    at org.jvnet.hk2.config.ConfigBean._getter(ConfigBean.java:179)
    at org.jvnet.hk2.config.ConfigBean.getter(ConfigBean.java:187)
    at org.jvnet.hk2.config.Dom.invoke(Dom.java:905)
    at
    org.glassfish.config.support.TranslatedConfigView.invoke(TranslatedConfigView.java:119)
    at $Proxy91.getResources(Unknown Source)
    at
    com.sun.enterprise.config.serverbeans.Resources$Duck.getResources(Resources.java:105)


 Comments   
Comment by Richard S. Hall [ 08/Nov/10 ]

Not exactly sure what can be done here. This is a sync block around a check to
findLoadedClass(), which as far as I can see must be guarded by a lock on the
class loader.

Comment by Scott Oaks [ 08/Nov/10 ]

Somewhere along the line (in the connectors code or the HK2 module), something
needs to get cached. We shouldn't have to do class lookups every time we
allocate a connection.

Comment by dochez [ 08/Nov/10 ]

I can certainly look into caching the class reference in hk2 but another optimization would be to stop
looking at configuration object (observe the ConfigBean/Dom access in the stack traces) and cache enough
of the configuration data to be able to create connection without coming back to the configuration tree.

Comment by dochez [ 08/Nov/10 ]

fixed hk2 to start caching the class object. I am still going to reassign to jagadish as configuration lookup
should not be done during user's request processing. Instead, the container should cache the necessary
configuration and listen to changes from the config events.

Comment by Jagadish [ 09/Nov/10 ]

Hi Jerome,

I can fix part (1) of the stack trace ie., to cache "Resources" configuration.

I am not sure it is possible to do anything from connector container /
Resources' duckType utility method w.r.t part (2) and (3) of stack trace as they
are searching a particular resource (by name or by type).
Both of them internally call Resources.getResources()

Comment by Jagadish [ 09/Nov/10 ]

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=25184
Provided the above fix to cache "Resources" configuration.
Fix will be available from 10th Nov 2010 nightly onwards.





[GLASSFISH-14351] [Perf] time to start domain the 2nd time is too large Created: 02/Nov/10  Updated: 03/Dec/12  Resolved: 08/Nov/10

Status: Closed
Project: glassfish
Component/s: performance
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: amitagarwal Assignee: Richard S. Hall
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows (generic)
Platform: All


Issuezilla Id: 14,351
Tags: PSRBUG

 Description   

Startup time has regressed by huge margins in b26. We are observing around 108%
regression for regular build on Windows & 88% regression for web build on
Windows platform.



 Comments   
Comment by Tom Mueller [ 02/Nov/10 ]

Here are some timings for starting a freshly created domain on Windows:

C:\test>grep 'startup time' 3.1-b26\glassfish3\glassfish\domains\foo\logs\server
.log
[#|2010-11-02T11:31:52.547-
0500|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=15;_ThreadName=Thread-
1;|GlassFish Server Open Source Edition 3.1-b26 (26) startup time : Felix (16,422ms), startup services(812ms),
total(17,234ms)|#]
[#|2010-11-02T11:32:21.407-
0500|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=15;_ThreadName=Thread-
1;|GlassFish Server Open Source Edition 3.1-b26 (26) startup time : Felix (15,563ms), startup services(844ms),
total(16,407ms)|#]
[#|2010-11-02T11:32:33.469-
0500|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=15;_ThreadName=Thread-
1;|GlassFish Server Open Source Edition 3.1-b26 (26) startup time : Felix (2,656ms), startup services(891ms),
total(3,547ms)|#]
[#|2010-11-02T11:32:45.469-
0500|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=15;_ThreadName=Thread-
1;|GlassFish Server Open Source Edition 3.1-b26 (26) startup time : Felix (1,781ms), startup services(781ms),
total(2,562ms)|#]

Notice how the Felix startup time is over 15 seconds for the 2nd start. Normally, the time for the 2nd start is
like the 3rd and 4th starts.

Comment by Tom Mueller [ 02/Nov/10 ]

I tried this experiment:

  • unzipped b26 to a test area
  • copied felix.jar from a b25 install to the b26 test area
  • run start-domain twice

In the case, the 2nd start was fast (1.7 sec) while the first one took 15 sec.

So using the felix.jar from b25 eliminates this problem.

Comment by Sanjeeb Sahoo [ 02/Nov/10 ]

Is it really a p2 at this point of time? I beg to differ. Yes, we should
understand why this is happening so that we can eventually fix it, but fixing it
now will require yet another release of Felix which itself requires quite bit of
effort. IMO, developers start the server so many times that whether the server
started slow first two times would not change their perception. Given the time
constraint, can we change our benchmark in this release to start the server
twice to make it warm? Just my $0.02.

Comment by Tom Mueller [ 02/Nov/10 ]

I might agree if you could explain why it is doing this and why this is the only
effect and why it is a big change. Also, what are the benefits of the 3.0.5
integration. Maybe we should just revert to the previous release of Felix.
Finally, I was hoping that we could still get the cache file format change in for
GF 3.1. That would require another release of felix anyway.

Comment by Richard S. Hall [ 02/Nov/10 ]

I am seeing that the bundles are being updated in the bundle cache on the second
server start:

"FelixStartLevel"
org.apache.felix.framework.Felix.updateBundle(Felix.java:1895)
org.apache.felix.framework.BundleImpl.update(BundleImpl.java:940)
org.apache.felix.framework.BundleImpl.update(BundleImpl.java:927)
org.jvnet.hk2.osgimain.Main.update(Main.java:337)
org.jvnet.hk2.osgimain.Main.traverse(Main.java:289)
org.jvnet.hk2.osgimain.Main.start(Main.java:141)
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:633)
org.apache.felix.framework.Felix.activateBundle(Felix.java:1822)
org.apache.felix.framework.Felix.startBundle(Felix.java:1739)
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1143)
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
java.lang.Thread.run(Thread.java:680)

Comment by Richard S. Hall [ 02/Nov/10 ]

After further discussion with Sahoo, this could be related to a change in the
way Felix initializes the last modified value for bundles in the bundle cache.
We will discuss this.

Comment by Richard S. Hall [ 02/Nov/10 ]

I am fairly certain I see the issue and it is a Felix issue related to changes
for cache initialization. It looks like a bundle's last modified time is not
persisted during the first execution, so the second execution detects old
bundles and updates, which causes the last modified time to be written to the disk.

Comment by Richard S. Hall [ 03/Nov/10 ]

I am going to try to get a Felix 3.0.6 release going this week to address this
issue.

Comment by Tom Mueller [ 08/Nov/10 ]

Felix 3.0.6 is integrated.





[GLASSFISH-14269] [Perf] b26 High thread contention in orb code results in poor performance Created: 28/Oct/10  Updated: 03/Dec/12  Resolved: 02/Nov/10

Status: Closed
Project: glassfish
Component/s: orb
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: amitagarwal Assignee: Ken Cavanaugh
Resolution: Fixed 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-13573 [PERF] Huge regression with trade2 be... Closed
blocks GLASSFISH-14348 [Perf] Thread waiting issue in corba ... Closed
Issuezilla Id: 14,269
Tags: PSRBUG

 Description   

We have observed high thread contention in the following code path while running
Trade2 benchmark against latest promoted build b26. This results in a really
significant regression (90% lower). Unless this bug is fixed there is no point
running perf tests. This will show up in all the benchmarks we run.

Here is the stack trace,

java.lang.Thread.State: BLOCKED (on object monitor)
at
com.sun.corba.ee.impl.osgi.loader.OSGIListener.getBundleForClass(OSGIListener.java:313)

  • waiting to lock <0x00002aaab426ab90> (a java.lang.Class for
    com.sun.corba.ee.impl.osgi.loader.OSGIListener)
    at
    com.sun.corba.ee.impl.osgi.loader.OSGIListener.access$000(OSGIListener.java:77)
    at
    com.sun.corba.ee.impl.osgi.loader.OSGIListener$ClassCodeBaseHandlerImpl.loadClass(OSGIListener.java:211)
    at
    com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.getClassFromString(CDRInputStream_1_0.java:2256)
    at
    com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1095)
    at
    com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
    at
    com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:928)
    at
    com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:918)
    at
    com.sun.corba.ee.impl.encoding.CDRInputObject.read_abstract_interface(CDRInputObject.java:557)
    at
    com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:391)
    at
    com.sun.corba.ee.impl.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:544)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:345)
    at java.util.Hashtable.readObject(Hashtable.java:859)
    at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
    at
    sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at
    com.sun.corba.ee.impl.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1830)
    at
    com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1205)
    at
    com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
    at
    com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
    at
    com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
    at
    com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
    at
    com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1121)
    at
    com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
    at
    com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:525)
    at
    com.sun.corba.ee.impl.copyobject.ORBStreamObjectCopierImpl.copy(ORBStreamObjectCopierImpl.java:78)
    at
    com.sun.corba.ee.impl.copyobject.ORBStreamObjectCopierImpl.copy(ORBStreamObjectCopierImpl.java:65)
    at
    com.sun.corba.ee.impl.orbutil.copyobject.FallbackObjectCopierImpl.copy(FallbackObjectCopierImpl.java:69)
    at
    com.sun.corba.ee.impl.orbutil.copyobject.FallbackObjectCopierImpl.copy(FallbackObjectCopierImpl.java:59)
    at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.copyObject(Util.java:768)
    at
    com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.copyResult(DynamicMethodMarshallerImpl.java:473)
    at
    com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:246)
    at
    com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:155)
    at
    com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
    at trade._Quote_DynamicStub._copyFromEJB(trade/_Quote_DynamicStub.java)
    at
    com.ibm.ivj.ejb.runtime.AbstractEntityAccessBean.refreshCopyHelper(AbstractEntityAccessBean.java:277)


 Comments   
Comment by Richard S. Hall [ 28/Oct/10 ]

This doesn't appear to have anything to do with OSGi, so I'll remove that from
the summary.

It looks like it might be possible to use a copy-on-write map to eliminate the
need to do locking in OSGIListener.getBundleForClass().

Comment by Ken Cavanaugh [ 28/Oct/10 ]

The construction of the InvocationHandler in WrapperGenerator should
include the getLogger call, rather than calling getLogger in every call to
a logging method. In addition, I'll probably add a flag to avoid calling
the log method inside the OSGIListener.loadClass method unless some debugging
is enabled.

Comment by Ken Cavanaugh [ 28/Oct/10 ]
      • Issue 14270 has been marked as a duplicate of this issue. ***
Comment by Ken Cavanaugh [ 28/Oct/10 ]

I just checked in ORB version 3.1.0-b011 for GlassFish, in svn rev 42273.
This should fix this problem. There are two changes:

1. I moved the lookup of the Logger outside of the body of the InvocationHandler.
The logger is fixed per exception class, so this is only needed once.
The logger should now be created in the static initializer (in this case) of
the ORBUtilSystemException class.

2. I also added a debug flag in OSGIListener to avoid the wrapper calls
completely in the getCodebase method, since this method is called MANY
times per invocation when unmarshaling complex data types.

You can either wait for a nightly build, or get the ORB jars from maven
to try this on b26.





[GLASSFISH-13582] [PERF] Really huge regression with trade2 benchmark when replication is turned on Created: 22/Sep/10  Updated: 03/Dec/12  Resolved: 14/Dec/10

Status: Closed
Project: glassfish
Component/s: failover
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: amitagarwal Assignee: Mahesh Kannan
Resolution: Fixed 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-14077 [PERF] investigate performance bottle... Resolved
depends on GLASSFISH-14080 [PERF] Implement Map based caching st... Closed
depends on GLASSFISH-14199 [PERF] Orb deserializing creating Log... Closed
depends on GLASSFISH-14731 [PERF] JDBC resources continually loo... Closed
Issuezilla Id: 13,582
Tags: 3_1-regression, PSRBUG

 Description   

Performance numbers for trade2 benchmark with glassfish 10.1 is 94% lower than
glassfish 9.1.1. This is with 2 instance cluster with HA enabled.

We used default config for HA.
We noticed plenty of threads in following state,

"http-thread-pool-8080(40)" daemon prio=10 tid=0x00002aabe16f9800 nid=0x3d39
waiting on condition [0x00000000445a4000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)

  • parking to wait for <0x00002aab7d006700> (a
    java.util.concurrent.FutureTask$Sync)
    at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)
    at
    java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:947)
    at
    java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1239)
    at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:227)
    at java.util.concurrent.FutureTask.get(FutureTask.java:91)
    at
    org.shoal.adapter.store.commands.AcknowledgedCommand.waitForAck(AcknowledgedCommand.java:105)
    at
    org.shoal.adapter.store.commands.SaveCommand.onSuccess(SaveCommand.java:139)
    at
    org.shoal.ha.cache.impl.command.CommandManager.executeCommand(CommandManager.java:126)
    at
    org.shoal.ha.cache.impl.command.CommandManager.execute(CommandManager.java:109)
    at
    org.shoal.ha.cache.impl.store.ReplicatedDataStore.put(ReplicatedDataStore.java:157)
  • locked <0x00002aabd31ec5a8> (a org.shoal.ha.cache.api.DataStoreEntry)
    at
    org.shoal.ha.cache.impl.store.ReplicatedDataStore.put(ReplicatedDataStore.java:61)
    at
    org.shoal.adapter.store.ReplicatedBackingStore.save(ReplicatedBackingStore.java:186)
    at
    org.glassfish.web.ha.session.management.ReplicationStore.doValveSave(ReplicationStore.java:168)
    at
    org.glassfish.web.ha.session.management.ReplicationWebEventPersistentManager.doValveSave(ReplicationWebEventPersistentManager.java:154)
    at
    org.glassfish.web.ha.session.management.HASessionStoreValve.doPostInvoke(HASessionStoreValve.java:173)
    at
    org.glassfish.web.ha.session.management.HASessionStoreValve.postInvoke(HASessionStoreValve.java:134)
    at
    org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:670)
    at
    org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
    at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
    at
    com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
    at
    org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
    at
    org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
    at
    org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
    at
    com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
    at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:824)
    at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:721)
    at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1014)
    at
    com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:220)
    at
    com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
    at
    com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
    at
    com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
    at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
    at
    com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
    at
    com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
    at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
    at
    com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:530)
    at
    com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511)

"http-thread-pool-8080(39)" daemon prio=10 tid=0x00002aabe16f7800 nid=0x3d38
waiting on condition [0x0000000044563000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)

  • parking to wait for <0x00002aaac25f4cf0> (a
    maskedclasses.LinkedTransferQueue)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
    at
    maskedclasses.LinkedTransferQueue.awaitMatch(LinkedTransferQueue.java:724)
    at maskedclasses.LinkedTransferQueue.xfer(LinkedTransferQueue.java:633)
    at maskedclasses.LinkedTransferQueue.take(LinkedTransferQueue.java:1083)
    at
    com.sun.grizzly.util.FixedThreadPool$BasicWorker.getTask(FixedThreadPool.java:237)
    at
    com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:522)
    at
    com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511)
    at java.lang.Thread.run(Thread.java:619)


 Comments   
Comment by Mahesh Kannan [ 24/Sep/10 ]

It looks like the doAsyncReplication flag is set true after the
DataStoreContext is created/initialized. Thats why the Save command thinks that
it is running in sync replication mode.

Looking into this.

Comment by Mahesh Kannan [ 27/Sep/10 ]

I just did a checkin to shoal workspace that fixed the synchronous replication
issue.

<svn-log>
Date: 2010-09-27 21:42:56+0000
New Revision: 1268

Modified:

branches/SHOAL_1_1_ABSTRACTING_TRANSPORT/cache/src/main/java/org/shoal/adapter/s
tore/ReplicatedBackingStore.java

branches/SHOAL_1_1_ABSTRACTING_TRANSPORT/cache/src/main/java/org/shoal/adapter/s
tore/StoreableReplicatedBackingStore.java

branches/SHOAL_1_1_ABSTRACTING_TRANSPORT/cache/src/main/java/org/shoal/adapter/s
tore/commands/RemoveCommand.java

branches/SHOAL_1_1_ABSTRACTING_TRANSPORT/cache/src/main/java/org/shoal/adapter/s
tore/commands/SaveCommand.java

branches/SHOAL_1_1_ABSTRACTING_TRANSPORT/cache/src/main/java/org/shoal/adapter/s
tore/commands/StoreableFullSaveCommand.java

branches/SHOAL_1_1_ABSTRACTING_TRANSPORT/cache/src/main/java/org/shoal/adapter/s
tore/commands/StoreableRemoveCommand.java

branches/SHOAL_1_1_ABSTRACTING_TRANSPORT/cache/src/main/java/org/shoal/adapter/s
tore/commands/StoreableSaveCommand.java

branches/SHOAL_1_1_ABSTRACTING_TRANSPORT/cache/src/main/java/org/shoal/ha/cache/
api/DataStoreConfigurator.java

branches/SHOAL_1_1_ABSTRACTING_TRANSPORT/cache/src/main/java/org/shoal/ha/cache/
api/DataStoreContext.java

branches/SHOAL_1_1_ABSTRACTING_TRANSPORT/cache/src/main/java/org/shoal/ha/cache/
api/DataStoreFactory.java

branches/SHOAL_1_1_ABSTRACTING_TRANSPORT/cache/src/main/java/org/shoal/ha/cache/
api/ReplicationFramework.java

branches/SHOAL_1_1_ABSTRACTING_TRANSPORT/cache/src/main/java/org/shoal/ha/cache/
impl/interceptor/TransmitInterceptor.java

branches/SHOAL_1_1_ABSTRACTING_TRANSPORT/cache/src/main/java/org/shoal/ha/cache/
impl/store/ReplicatedDataStore.java

Log:
Fix for 13582

</snv-log>

Also, fixed and got rid of most of the info level log messages (from both HA and
Web container).

The next integration of shoal into GF must improve the situation.

Comment by Mahesh Kannan [ 06/Oct/10 ]

Wanted to give an update on this:

We tested with a new patch where replication is done as soon as a fixed batch
size is reached (instead of waiting for fixed period before doing replication).
This removed the Full GCs completely but the CPU usage was still at 30%

Then Joe adjusted a couple of tuning parameters (like number of sender threads
etc.) and we are at 55% regression. Still some ways to go on this issue

Comment by Mahesh Kannan [ 12/Oct/10 ]

I think the reason why DataStoreEntry objects are leaking is because the web
container is NOT calling backingStore.remove() when the HTTP Sessiojn is
invalidated.

I tested this with a simple app containing a Servlet + 2 EJBs. The ejb states are
cleaned up from the Replica store when ejb.remove() is called but the replica
store entries for http sessions are never after httpSession.invalidate.

Discussed with Rajiv and now trying a patch.

Comment by Mahesh Kannan [ 12/Oct/10 ]

The DataStoreEntry leak has been fixed. The code changes that were part of the
patches that we tested have been checked in into shoal workspace. We will shoot
for hoal - GF integration tomorrow.

During the trade2 runs with the patches, we found that there were no Full GCs. It will be great to know the bottleneck that is preventing us from meeting the
V2 perf parity.

I want to mention that I am currently working on a patch that will prevent stale
(ejb) data to be replicated if new version of the same EJB state is available.
This should reduce the number of replication messages that are sent out and
hopefully will increase the throughput

Comment by Mahesh Kannan [ 15/Oct/10 ]

Moved the target milestone to ms6 since this is a blocking issue. We will try to
fix the performance issues that we currently are aware of by ms6.

Comment by Mahesh Kannan [ 19/Oct/10 ]

Add 14080 to the dependent issue

Comment by Scott Oaks [ 22/Oct/10 ]

...

Comment by Mahesh Kannan [ 25/Oct/10 ]

I am moving this to ms7 since this is really an umbrella bug and also there are
other issues 14077, 14080 etc. that need to be fixed for this issue to be
resolved.

We have already fixed what ever know issues in HA area for this issue. The fixes
include (a) removing synchronous replication (b) batching replication messages
so that SaveCommands (that carry replication data) do not back up too much and
(c) fixed the DataStoreEntry leak that was also triggering a mem leak.

As Joe pointed out in his issue 14077, to find out further bottlenecks we need
to use jmap, jstack etc. which is currently not possible because of the issue
mentioned in 14077.

So, I am moving this to ms7

Comment by Scott Oaks [ 25/Oct/10 ]

ORB serialization performance is impacting this test.

Comment by Mahesh Kannan [ 14/Dec/10 ]

We have integrated the new HA shoal jar that contains the fixes that we had been trying with our setup. The regression in our setup (v2.1 ha to v3.1 ha) is around 10%

I am closing this issue because there is no longer a HUGE regression.





[GLASSFISH-14852] [PERF] Performance Regression in corba logging WrapperGenerator Created: 29/Nov/10  Updated: 03/Dec/12  Resolved: 08/Dec/10

Status: Closed
Project: glassfish
Component/s: orb
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: Scott Oaks Assignee: Ken Cavanaugh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File orb.tgz    
Issue Links:
Dependency
blocks GLASSFISH-13573 [PERF] Huge regression with trade2 be... Closed
Tags: PSRBUG

 Description   

Many performance benchmarks are spending 20-50% of their time in com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator as that method gathers information (including stack trace) about its operations – even though those messages are never actually logged). This path must be bypassed.

Ken indicates that MakeWrapper.handleFullLogging can be adjusted to bypass the logging if the level is not set. We also need to make sure that the calls into the logger itself aren't expensive (e.g., that none of the calls do something like handleFullLogging("message " + someExpensiveMethod()), though present profiling does not indicate that to be an issue).



 Comments   
Comment by Ken Cavanaugh [ 29/Nov/10 ]

Fixes are in progress. Two changes:

  • Exit early from invocation handle in makeWrapper call when no log is needed and no value is returned.
  • Change OSGIListener to use ORB tracing facility (which has much lower overhead) instead of
    log wrappers.
Comment by Ken Cavanaugh [ 29/Nov/10 ]

I've attached a tar/gzip file containing the 8 ORB bundles with the
fixes for this issue. Try it out and let me know.

Comment by Ken Cavanaugh [ 08/Dec/10 ]

Fixed in ORB 3.1.0-b017.





[GLASSFISH-14731] [PERF] JDBC resources continually looking up classes Created: 16/Nov/10  Updated: 03/Dec/12  Resolved: 01/Dec/10

Status: Closed
Project: glassfish
Component/s: jca
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: Scott Oaks Assignee: Jagadish
Resolution: Fixed 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-13573 [PERF] Huge regression with trade2 be... Closed
blocks GLASSFISH-13582 [PERF] Really huge regression with tr... Closed
blocks GLASSFISH-13944 [PERF] specj enterprise 2010 benchmar... Closed
Issuezilla Id: 14,731
Tags: PSRBUG

 Description   

I am testing on the nightly build 11/14; performance is still severely regressed
because the connection pools are looking up resources. These should all be
cached; no resources should need to be found after initialization.

This is similar to 14454, which is fixed – this is a different code path, so
apparently there are multiple paths suffering from the same issue.

Here is the path doing the lookup:
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1759)

  • waiting to lock <0x5f404088> (a
    org.apache.felix.framework.ModuleImpl$ModuleClassLoaderJava5)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
    at com.sun.hk2.component.LazyInhabitant.loadClass(LazyInhabitant.java:121)
    at com.sun.hk2.component.LazyInhabitant.type(LazyInhabitant.java:96)
    at org.jvnet.hk2.config.Dom.domNodeByTypeElements(Dom.java:760)
    at org.jvnet.hk2.config.ConfigModel$CollectionNode.get(ConfigModel.java:404)
    at org.jvnet.hk2.config.Dom.getter(Dom.java:955)
    at org.jvnet.hk2.config.ConfigBean._getter(ConfigBean.java:179)
    at org.jvnet.hk2.config.ConfigBean.getter(ConfigBean.java:187)
    at org.jvnet.hk2.config.Dom.invoke(Dom.java:905)
    at
    org.glassfish.config.support.TranslatedConfigView.invoke(TranslatedConfigView.java:119)
    at $Proxy74.getResources(Unknown Source)
    at
    com.sun.enterprise.config.serverbeans.Resources$Duck.getResources(Resources.java:105)
    at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
    at
    sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.jvnet.hk2.config.Dom.invokeDuckMethod(Dom.java:943)
    at org.jvnet.hk2.config.Dom.invoke(Dom.java:896)
    at
    org.glassfish.config.support.TranslatedConfigView.invoke(TranslatedConfigView.java:119)
    at $Proxy74.getResources(Unknown Source)
    at
    com.sun.enterprise.config.serverbeans.Resources$Duck.getResourceByName(Resources.java:157)
    at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)
    at
    sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.jvnet.hk2.config.Dom.invokeDuckMethod(Dom.java:943)
    at org.jvnet.hk2.config.Dom.invoke(Dom.java:896)
    at
    org.glassfish.config.support.TranslatedConfigView.invoke(TranslatedConfigView.java:119)
    at $Proxy74.getResourceByName(Unknown Source)
    at
    com.sun.enterprise.connectors.util.ResourcesUtil.getResource(ResourcesUtil.java:1136)
    at
    com.sun.enterprise.connectors.ConnectionManagerImpl.validateResourceAndPool(ConnectionManagerImpl.java:393)
    at
    com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:169)
    at
    com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:163)
    at
    com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:158)
    at com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:110)
    at
    com.sun.jdo.spi.persistence.support.sqlstore.ejb.TransactionHelperImpl.getConnection(TransactionHelperImpl.java:216)
    at
    com.sun.jdo.spi.persistence.support.sqlstore.ejb.EJBHelper.getConnection(EJBHelper.java:201)
    at
    com.sun.jdo.spi.persistence.support.sqlstore.impl.TransactionImpl.getConnectionInternal(TransactionImpl.java:1451)
    at
    com.sun.jdo.spi.persistence.support.sqlstore.impl.TransactionImpl.getConnection(TransactionImpl.java:1362)
  • locked <0xe96242e0> (a
    com.sun.jdo.spi.persistence.support.sqlstore.impl.TransactionImpl)
    at
    com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQLStoreManager.java:451)
    at
    com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLStoreManager.java:380)
    at
    com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.retrieve(PersistenceManagerImpl.java:1122)
    at
    com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.doExecute(QueryImpl.java:693)
    at
    com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.executeWithArray(QueryImpl.java:611)
  • locked <0xe9624410> (a
    com.sun.jdo.spi.persistence.support.sqlstore.query.jqlc.ParameterTable)
    at
    trade.HoldingBean1565695515_ConcreteImpl.ejbFindByUserID(HoldingBean1565695515_ConcreteImpl.java:139)
    at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source)
    at
    sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    ...


 Comments   
Comment by Jagadish [ 16/Nov/10 ]

Hi Scott, Jerome,
This is the same as part (2) of stack traces in issue 14454
This call is searching a resource by name.

From the issue 14454 :
"I am not sure it is possible to do anything from connector container /
Resources' duckType utility method w.r.t part (2) and (3) of stack trace as they
are searching a particular resource (by name or by type).
Both of them internally call Resources.getResources()"

One option I could try is to start caching the resources in a backing
arrayList/hashSet, listen to config changes of resources for (ADD & REMOVE)
events so as to add or remove "resource" elements from the backing
arrayList/hashSet.

Jerome : Please let me know whether the above approach is fine.

Comment by Scott Oaks [ 16/Nov/10 ]

I am confused about what changed – we didn't see this until a few weeks ago.

Is it something in the habitat that changed after all?

Comment by Jagadish [ 16/Nov/10 ]

There was no change in the duckType utility method in "Resources" confg-bean.
Few weeks ago, we have added a runtime check for each "getConnection" call to
make sure that the resource/pool using which the connection-factory was acquired
is still valid (eg: not stale, not disabled, not deleted) and since this in-turn
calls "Resources.getResourceByName()" which internally calls
"Resources.getResources()".
Probably, the issue of hk2 trying to lock was always there and this new runtime
check for "getConnection()" exposes it.
-------------------------------------------------------------------------------------------------------------------------------------------------------
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1759)

  • waiting to lock <0x5f404088> (a
    org.apache.felix.framework.ModuleImpl$ModuleClassLoaderJava5)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
    at com.sun.hk2.component.LazyInhabitant.loadClass(LazyInhabitant.java:121)
    at com.sun.hk2.component.LazyInhabitant.type(LazyInhabitant.java:96)
    at org.jvnet.hk2.config.Dom.domNodeByTypeElements(Dom.java:760)
    at org.jvnet.hk2.config.ConfigModel$CollectionNode.get(ConfigModel.java:404)
    at org.jvnet.hk2.config.Dom.getter(Dom.java:955)
    at org.jvnet.hk2.config.ConfigBean._getter(ConfigBean.java:179)
    at org.jvnet.hk2.config.ConfigBean.getter(ConfigBean.java:187)
    at org.jvnet.hk2.config.Dom.invoke(Dom.java:905)
    -------------------------------------------------------------------------------------------------------------------------------------------------------
Comment by dochez [ 17/Nov/10 ]

The fix I introduced in hk2 will certainly help the performance, yet doing configuration related methods
dispatching during user's request is inherently slow and should be avoided.

Keeping your own list of resources information would work. I am a bit surprised you actually need to
getResourceByName() at runtime. Is the name changing ? can't the resource object itself be cached ?

Also, once you get the Resource object, if you still do a bunch of config related getXXX, it will still be slow.

Comment by Jagadish [ 20/Nov/10 ]

Fix will be caching the resource object within the ConnectionManager
(the caller that is introducing the bottleneck). This will reduce the
number of calls to resources.getResources() from each and every
getConnection() call to only one per datasource (equivalent to one
datasource lookup).
[Since the ConnectionManager cannot have these non-serializable resource
proxy configurations, there will be one additional lookup whenever
de-serialized ConnectionManager is activated]

There are 2 config bean calls to find whether the "resource" and
"resource-ref" are in enabled state for jdbc resource.
[This will be done for each getConnection()]

  • resource.getEnabled()
  • server.getResourceRef(resourceName).getEnabled()
    I am not sure whether this will also cause performance issues and how
    this can be worked around.

FIX INFORMATION :
svn log -v -r 43025
Provided a fix so that resources.getResourceByName is not called for each
getConnection() call, instead once per DataSource.

Fix will be available in 21st Nov 2010 nightly / 3.1 promoted build 31.

Comment by Scott Oaks [ 29/Nov/10 ]

We've tested the latest nightly build, and the performance of the getResourceByName() has been fixed. However, the getEnabled() calls are still a very big performance impact – on SPECj, they cause database operations to be 2x longer than in 2.1. The call specifically to com.sun.gjc.spi.base.DataSource.getConnection() takes 20 times longer in 3.1 than in 2.1.

The majority of that time difference falls under ConnectionManagerImpl.validateResourceAndPool(). In 2.1, there is no validation (at least by default); in 3.1 it is taking 80% of the time in getConnection(). er in 3.1. This is trigger all the resourceenabled/resourceref calls; the getResourceRef() and getRef() proxies (and to a lesser extent the getEnabled() proxies) are all taking an enormous amount of time when they call TranslatedConfigView.invoke() -> Dom.invoke() -> (either) Dom.invokeDuckMethod() or ConfigModel.toProperty(). We need to avoid that. [I tried turning off connection-validation, but it didn't help; I guess that is a different thing in 3.1.]

In addition to the validateResourceAndPool() call, internalGetConnection() is itself taking 4x longer in 3.1. For getConnection(), we call getAppName(), which does a JNDI lookup, which is known to be an expensive call (we've never optimized that path, preferring instead to avoid calls into lookup()). Can we avoid that call too?

Comment by Jagadish [ 30/Nov/10 ]

Added another fix to avoid calls to config-beans altogether during "ConnectionManagerImpl.validateResourceAndPool()" when the resource is deployed (enabled). Jdbc and connector resources when deployed will be registered with connector-registry.
Only when the resource is not deployed (no resource found in connector-registry), in order to generate appropriate error message, config-beans call will be made. This should not be a issue.

FIX INFORMATION:
svn log -v -r 43200

Above fix should be available from 1st Dec 2010 nightly.

None of the tests (QL, connector, jdbc, connector-cts-standalone) indicated that the config-beans calls were made in "validateResourceAndPool".

Comment by Jagadish [ 30/Nov/10 ]

w.r.t "java:app/AppName" lookup, it is done once per getConnection so as to collect monitoring statistics. This cannot be completely avoided.
Provided another fix such that "java:app/AppName" lookup is not done when monitoring is OFF for jdbc/connector connection pool. I am assuming that SpecJ does not have jdbc/connector pool monitoring enabled (same as default domain configuration) in which case above fix will be helpful to solve the issue.

FIX INFORMATION :
svn log -v -r 43264

Fix will be available from 1st Dec 2010 nightly.





[GLASSFISH-14455] [Perf] Thread contention in orb code during Created: 06/Nov/10  Updated: 03/Dec/12  Resolved: 08/Nov/10

Status: Closed
Project: glassfish
Component/s: orb
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: amitagarwal Assignee: Ken Cavanaugh
Resolution: Fixed 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-13573 [PERF] Huge regression with trade2 be... Closed
blocks GLASSFISH-13944 [PERF] specj enterprise 2010 benchmar... Closed
Issuezilla Id: 14,455
Tags: PSRBUG

 Description   

I had a chance to run Trade2 benchmark again after bug
https://glassfish.dev.java.net/issues/show_bug.cgi?id=14348 got fixed. Now I see
threads block in following code path many times,

java.lang.Thread.State: BLOCKED (on object monitor)
at
com.sun.corba.ee.impl.orbutil.copyobject.ClassCopierFactoryPipelineImpl.getClassCopier(ClassCopierFactoryPipelineImpl.java:231)

  • waiting to lock <0x00002aaac35cd6a0> (a
    com.sun.corba.ee.impl.orbutil.copyobject.ClassCopierFactoryPipelineImpl)
    at
    com.sun.corba.ee.impl.copyobject.ReflectObjectCopierImpl.copy(ReflectObjectCopierImpl.java:197)
    at
    com.sun.corba.ee.impl.orbutil.copyobject.FallbackObjectCopierImpl.copy(FallbackObjectCopierImpl.java:66)
    at
    com.sun.corba.ee.impl.orbutil.copyobject.FallbackObjectCopierImpl.copy(FallbackObjectCopierImpl.java:59)
    at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.copyObject(Util.java:771)
    at
    com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.copyResult(DynamicMethodMarshallerImpl.java:473)
    at
    com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:243)
    at
    com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
    at
    com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
    at trade._TradeHome_DynamicStub.create(trade/_TradeHome_DynamicStub.java)
    at trade.TradeAccessBean.instantiateEJB(TradeAccessBean.java:86)
    at trade.TradeAccessBean.login(TradeAccessBean.java:181)
    at trade_client.TradeAction.doLogin(TradeAction.java:311)
    at trade_client.TradeServletAction.doLogin(TradeServletAction.java:595

And I sometimes do notice that execution blocks at following call sequence as
reported in https://glassfish.dev.java.net/issues/show_bug.cgi?id=14269

java.lang.Thread.State: BLOCKED (on object monitor)
at
com.sun.corba.ee.impl.osgi.loader.OSGIListener.getBundleForClass(OSGIListener.java:329)

  • waiting to lock <0x00002aaab4201c50> (a java.lang.Class for
    com.sun.corba.ee.impl.osgi.loader.OSGIListener)
    at
    com.sun.corba.ee.impl.osgi.loader.OSGIListener.access$000(OSGIListener.java:77)
    at
    com.sun.corba.ee.impl.osgi.loader.OSGIListener$ClassCodeBaseHandlerImpl.loadClass(OSGIListener.java:221)
    at
    com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.getClassFromString(CDRInputStream_1_0.java:2256)
    at
    com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1095)
    at
    com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
    at
    com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:525)
    at
    com.sun.corba.ee.impl.copyobject.ORBStreamObjectCopierImpl.copy(ORBStreamObjectCopierImpl.java:78)
    at
    com.sun.corba.ee.impl.copyobject.ORBStreamObjectCopierImpl.copy(ORBStreamObjectCopierImpl.java:65)
    at
    com.sun.corba.ee.impl.orbutil.copyobject.FallbackObjectCopierImpl.copy(FallbackObjectCopierImpl.java:69)
    at
    com.sun.corba.ee.impl.orbutil.copyobject.FallbackObjectCopierImpl.copy(FallbackObjectCopierImpl.java:59)
    at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.copyObject(Util.java:771)
    at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.copyObjects(Util.java:742)
    at
    com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.copyArguments(DynamicMethodMarshallerImpl.java:439)
    at
    com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:227)
    at
    com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
    at
    com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)


 Comments   
Comment by Ken Cavanaugh [ 08/Nov/10 ]

These should be fixed with the integration of ORB version 3.1.0-b013 in
GF rev 42572. Both issues were fixed by replacing synchronization with
read/write locks.





[GLASSFISH-14199] [PERF] Orb deserializing creating LogManager$Cleaner threads Created: 25/Oct/10  Updated: 03/Dec/12  Resolved: 28/Oct/10

Status: Closed
Project: glassfish
Component/s: orb
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: Scott Oaks Assignee: Ken Cavanaugh
Resolution: Fixed 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-13582 [PERF] Really huge regression with tr... Closed
Issuezilla Id: 14,199
Tags: PSRBUG

 Description   

Objects that have cached the result of LogManager.getLogger() and are then
copied via the corba copying code will end up with new instances of the
LogManager class, which is expected to be a singleton. When the new instances of
the class are created, the LogManager.<init> also constructs a new Cleaner thread.

The end result is a very large memory leak; this is also at least partly
responsible for the deserialization performance regression we are seeing.



 Comments   
Comment by Ken Cavanaugh [ 26/Oct/10 ]

I have a possible workaround for this delivered to Scott for testing.
An improved object copier may need to wait until GF 3.2.

Comment by Ken Cavanaugh [ 28/Oct/10 ]

I modified the ORB object copier in b010 to avoid copying Logger and LogManager.
According to an email from Joe Fialli, this issue has been fixed, so I am
closing this issue.

Comment by preston001 [ 28/Jul/11 ]

What files specifically were modified to resolve this?





[GLASSFISH-14927] [PERF] Performance regression in ORB copyObject Created: 01/Dec/10  Updated: 03/Dec/12  Resolved: 09/Dec/10

Status: Closed
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_ms07
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: Scott Oaks Assignee: Ken Cavanaugh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File orb.tgz     GZip Archive server.log.gz    
Issue Links:
Dependency
blocks GLASSFISH-13573 [PERF] Huge regression with trade2 be... Closed
Tags: PSRBUG

 Description   

We are still observing some cases where the corba Util.copyObject() is regressed in performance from 2.1 to 3.1. In particular, trade2 has a Quote EJB. In 3.1, copying that EJB takes a very long time; the copyObject goes into the Fallback copier, and the time to serialize/deserialize the 5 member hashtable held by that bean is quite large. In 2.x, the hashtable is never serialized/deserialized; presumably it is using the reflective copier.



 Comments   
Comment by Ken Cavanaugh [ 02/Dec/10 ]

Can you attach information about the data members and type of the Quote EJB? I don't know why we are
falling back for this object.

Comment by Scott Oaks [ 08/Dec/10 ]

Attached is the server.log file javax.enterprise.resource.corba.level=FINE.

Comment by Ken Cavanaugh [ 08/Dec/10 ]

I've attached a gzipped tarball of the ORB that fixes the
logger problem that blocked getting information on the
fallback copier behavior.

Comment by Scott Oaks [ 09/Dec/10 ]

Falling back because it is a subclass:

[#|2010-12-09T08:10:10.241-0800|FINE|glassfish3.1|javax.enterprise.resource.corba.orbutil.copyobject|ThreadID=16;_ThreadName=Thread-1;ClassName=com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator;MethodName=handleFullLogging;object=s:1,193.0,details;details=details;price=193.0;symbol=s:1;_Key=trade.QuoteKey@1b6ea;|ORBOCOPY00001: Object copy failed on copy of

{object=s:1,193.0,details details=details price=193.0 symbol=s:1 __Key=trade.QuoteKey@1b6ea}

which has type class com.ibm.ivj.ejb.runtime.AccessBeanHashtable|#]

Comment by Ken Cavanaugh [ 09/Dec/10 ]

Thanks, that's the information I need. The copying of implementations of Map is controlled in the
copyobject code by the ClassCopierFactoryPipelineImpl.mapClasses array, which lists the map implementations
that should be copied by a special map copier, instead of reflectively. Unfortunately the current implementation
requires that all superclasses of a class copied reflectively must also be copied reflectively, so
use of a mapCopier forces a subclass of a class in mapClasses to use the fallback copier (which explains the
regression).

There are currently only two Map implementations that are known to need the map copier:

  • IdentityHashMap, due to the peculiarities of the NULL_KEY value in its implementation]
  • LinkedHashMap, in case a very long linked list causes a stack overflow (we could live
    with the possibility of stack overflow in most cases, though at least one customer has
    encountered it).

GF 3.0 had only IdentityHashMap in the mapCopier list. For GF 3.1, I had all of the standard
JDK Map implementations in the list. I am changing this for ORB b019 to be only
IdentityHashMap and LinkedHashMap.

Comment by Ken Cavanaugh [ 09/Dec/10 ]

Fixed with ORB 3.1.0-b019 integration in GF svn rev 43637.





[GLASSFISH-14017] [PERF] 10% regression in servlet primitives Created: 15/Oct/10  Updated: 03/Dec/12  Resolved: 13/Dec/10

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: Scott Oaks Assignee: Shing Wai Chan
Resolution: Fixed 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 glassfish-3.0.1-threads.png     PNG File glassfish-3.1-threads.png    
Issue Links:
Dependency
depends on GLASSFISH-14018 Cookie handling contributing to servl... Resolved
depends on GLASSFISH-14053 [PERF] Need to fix grizzly issue 900 Closed
blocks GLASSFISH-13944 [PERF] specj enterprise 2010 benchmar... Closed
blocks GLASSFISH-14100 [PERF] Performance of jservlet2 has r... Closed
Issuezilla Id: 14,017
Tags: PSRBUG

 Description   

We are measuring a 10% regression in servlet primitives in 3.1 (vs. 3.0.1).

There are likely several contributing factors; as they are identified, they can
be filed as dependent issues.



 Comments   
Comment by Shing Wai Chan [ 15/Oct/10 ]

Can you provide details on exactly what you try to measure?
Can I access the given tests?

Comment by Scott Oaks [ 18/Oct/10 ]

We measure the ops/sec for 50 users to a hello, world servlet. We use Faban to
drive the load and report the results – so each user is a long-lived session
which performs multiple requests (keep-alive is on, so no connection handling;
everything is dependent on the servlet container and the I/O stack).

Comment by Santiago Pericas-Geertsen [ 08/Nov/10 ]

The current regression is closer to 7%. Here are the latest numbers:

3.0.1

ops/sec: 11181.733
% errors: 0.0
avg. time: 0.003
max time: 0.261
90th %: 0.005

2) 3.1 (nightly)

ops/sec: 10388.988
% errors: 0.0
avg. time: 0.004
max time: 0.257
90th %: 0.005

I collected data with a couple of profilers. An interesting observation is that, even though the
default max size for the http-thread-pool is 5 in both versions, GF 3.0.1 shows 32 threads
running off that pool. GF 3.1 only shows 5 as expected. See attached PNG files.

As far as hot spots, there appears to be a 4% regression in method
com.sun.grizzly.ContextTask.run(), but there may be some correlation between this apparent
regression and the size of the http-thread-pool. Will continue to investigate.

Comment by Santiago Pericas-Geertsen [ 08/Nov/10 ]

Created an attachment (id=5367)
Glassfish 3.0.1 Threads

Comment by Santiago Pericas-Geertsen [ 08/Nov/10 ]

Created an attachment (id=5368)
Glassfish 3.1 Threads

Comment by Santiago Pericas-Geertsen [ 08/Nov/10 ]

The difference in the number of threads in http-thread-pool was a wild goose chase. The
number of "live" threads is the same in both cases. GF 3.0.1 does not appear to reuse threads
ids (compared to 3.1) and that is the difference in the profiles.

Comment by Santiago Pericas-Geertsen [ 02/Dec/10 ]

As stated before, on the test that I'm running the difference is closer to 7%. Looking at the HTTP traffic, I noticed that the value of HTTP header "X-Powered-By" in 3.1 is longer:

[3.0.1] X-Powered-By: Servlet/3.0

[3.1] X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1-SNAPSHOT Java/Sun Microsystems Inc./1.6)

I turned off this header and set the Server header to "" to get an identical response between the two GFs. The result shows a regression of only 1.5% on my system.

Comment by Scott Oaks [ 02/Dec/10 ]

7% sounds reasonable at this point given the two dependent issues that have been fixed. But it surprising that most of that comes just from the single header line.

Can you snoop your network and see if somehow that causes the network packet to be split or something?

Comment by Amy Roh [ 02/Dec/10 ]

The "X-Powered-By" header was changed as part of tomcat fix porting - https://issues.apache.org/bugzilla/show_bug.cgi?id=48006.

svn diff -r36875:38136 src/main/java/org/apache/catalina/connector/CoyoteAdapter.java

The spec says

"It is recommended that containers use the X-Powered-By HTTP header to
publish its implementation information. The field value should consist of one or
more implementation types, such as "Servlet/2.4". Optionally, the
supplementary information of the container and the underlying Java platform can
be added after the implementation type within parentheses. The container should
be configurable to suppress this header.
Here’s the examples of this header.
X-Powered-By: Servlet/2.4
X-Powered-By: Servlet/2.4 JSP/2.0 (Tomcat/5.0 JRE/1.4.1)"

So I think the optional supplementary information can be removed if performance regression is significant.

Comment by Santiago Pericas-Geertsen [ 02/Dec/10 ]

I don't see packet splitting; I do see that Grizzly spends a bit more time writing responses, and that's what prompted me to explore this. However, my benchmark is very "micro" and perhaps not representative of real-world scenarios. Could we do a run of our other benchmarks suppressing this header?

asadmin set server.network-config.protocols.protocol.http-listener-1.http.xpowered-by=false

Comment by Dhiru Pandey [ 13/Dec/10 ]

As per the discussion in the perf meeting today - JServlet regressing is now with in the statistical measurement error range. We concluded that for now this bug should be closed.

Comment by Dhiru Pandey [ 13/Dec/10 ]

JServlet regression with in statistical measurement error range

Comment by Santiago Pericas-Geertsen [ 13/Dec/10 ]

As confirmed by Scott the X-Powered-By header is significant in micro-benchmarks where the size of the payload is small (< 300 bytes or so).





[GLASSFISH-14348] [Perf] Thread waiting issue in corba code causes perf regression Created: 02/Nov/10  Updated: 03/Dec/12  Resolved: 15/Nov/10

Status: Closed
Project: glassfish
Component/s: orb
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: amitagarwal Assignee: Ken Cavanaugh
Resolution: Fixed 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-13573 [PERF] Huge regression with trade2 be... Closed
depends on GLASSFISH-14269 [Perf] b26 High thread contention in ... Closed
blocks GLASSFISH-13944 [PERF] specj enterprise 2010 benchmar... Closed
Issuezilla Id: 14,348
Tags: PSRBUG

 Description   

Tried nightly build b27-10_31_2010 after bug
https://glassfish.dev.java.net/issues/show_bug.cgi?id=14269 got resolved. I
don't see the reported issue in GLASSFISH-14269 but now I see plenty of threads are
waiting in following codepath.
This still causes quite a bit of regression from b25.

java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)

  • parking to wait for <0x00002aaac2080668> (a
    java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
    at
    java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
    at
    java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
    at
    java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
    at
    java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:807)
    at com.sun.corba.ee.impl.oa.poa.POAManagerImpl.exit(POAManagerImpl.java:690)
    at com.sun.corba.ee.impl.oa.poa.POAImpl.exit(POAImpl.java:1694)
    at
    com.sun.corba.ee.impl.protocol.ServantCacheLocalCRDBase.updateCachedInfo(ServantCacheLocalCRDBase.java:99)
    at
    com.sun.corba.ee.impl.protocol.ServantCacheLocalCRDBase.getCachedInfo(ServantCacheLocalCRDBase.java:77)
  • locked <0x00002aabafef6f50> (a
    com.sun.corba.ee.impl.protocol.FullServantCacheLocalCRDImpl)
    at
    com.sun.corba.ee.impl.protocol.FullServantCacheLocalCRDImpl.internalPreinvoke(FullServantCacheLocalCRDImpl.java:64)
    at
    com.sun.corba.ee.impl.protocol.LocalClientRequestDispatcherBase.servant_preinvoke(LocalClientRequestDispatcherBase.java:240)
    at
    com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.servant_preinvoke(CorbaClientDelegateImpl.java:544)
    at
    com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:218)
    at
    com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
    at
    com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
    at trade._MySession_DynamicStub.getHandle(trade/_MySession_DynamicStub.java)
    at trade_client.TradeServletAction.doLogin(TradeServletAction.java:619)
    at
    trade_client.TradeScenarioServlet.performTask(TradeScenarioServlet.java:224)
    at trade_client.TradeScenarioServlet.doGet(TradeScenarioServlet.java:72)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
    at
    org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1522)
    at
    org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
    at
    org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
    at
    org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
    at
    org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
    at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
    at
    com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
    at
    org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
    at
    org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
    at
    org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
    at
    com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
    at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
    at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
    at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
    at
    com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
    at
    com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
    at
    com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
    at
    com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
    at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
    at
    com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)


 Comments   
Comment by Ken Cavanaugh [ 02/Nov/10 ]

The POAManagerImpl.exit code is taking the writeLock too often: it should
only do this if there actually are waiters for the state change, which only
happens when a POAManager state change operation is called. As this is very
rare, the lock is not normally needed.

Comment by Ken Cavanaugh [ 02/Nov/10 ]

Fix integrated in GF 3.1 rev 42400 (ORB version 3.1.0-b012).

Comment by Ken Cavanaugh [ 02/Nov/10 ]

Forgot to update the status.

Comment by amitagarwal [ 11/Nov/10 ]

I still the same issue.

Here are the stack trace,

1)
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)

  • parking to wait for <0x00002aaabd904070> (a
    java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
    at
    java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
    at
    java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:842)
    at
    java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1178)
    at
    java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:807)
    at com.sun.corba.ee.impl.oa.poa.POAImpl.lock(POAImpl.java:346)
    at com.sun.corba.ee.impl.oa.poa.POAImpl.find_POA(POAImpl.java:927)
    at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:224)
    at
    com.sun.corba.ee.impl.protocol.ServantCacheLocalCRDBase.updateCachedInfo(ServantCacheLocalCRDBase.java:86)
    at
    com.sun.corba.ee.impl.protocol.ServantCacheLocalCRDBase.getCachedInfo(ServantCacheLocalCRDBase.java:77)
  • locked <0x00002aab8b9f7f10> (a
    com.sun.corba.ee.impl.protocol.FullServantCacheLocalCRDImpl)
    at
    com.sun.corba.ee.impl.protocol.FullServantCacheLocalCRDImpl.internalPreinvoke(FullServantCacheLocalCRDImpl.java:64)
    at
    com.sun.corba.ee.impl.protocol.LocalClientRequestDispatcherBase.servant_preinvoke(LocalClientRequestDispatcherBase.java:240)
    at
    com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.servant_preinvoke(CorbaClientDelegateImpl.java:544)
    at
    com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:218)
    at
    com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
    at
    com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)

2)
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)

  • parking to wait for <0x00002aaac190ba60> (a
    java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
    at
    java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
    at
    java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:842)
    at
    java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1178)
    at
    java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:807)
    at com.sun.corba.ee.impl.oa.poa.POAImpl.lock(POAImpl.java:346)
    at com.sun.corba.ee.impl.oa.poa.POAImpl.find_POA(POAImpl.java:927)
    at
    com.sun.corba.ee.impl.oa.rfm.ReferenceFactoryManagerImpl.createReference(ReferenceFactoryManagerImpl.java:546)
    at
    com.sun.corba.ee.impl.oa.rfm.ReferenceFactoryImpl.createReference(ReferenceFactoryImpl.java:62)
    at
    org.glassfish.enterprise.iiop.impl.POARemoteReferenceFactory._createRef(POARemoteReferenceFactory.java:439)
    at
    org.glassfish.enterprise.iiop.impl.POARemoteReferenceFactory.createRef(POARemoteReferenceFactory.java:402)
    at
    org.glassfish.enterprise.iiop.impl.POARemoteReferenceFactory.createRemoteReference(POARemoteReferenceFactory.java:366)
    at
    com.sun.ejb.containers.EntityContainer.getEJBObjectStub(EntityContainer.java:1819)
    at com.sun.ejb.containers.EntityContainer.postFind(EntityContainer.java:920)
    at
    com.sun.ejb.containers.EntityContainer.invokeFindByPrimaryKey(EntityContainer.java:815)
    at
    com.sun.ejb.containers.EJBHomeInvocationHandler.invoke(EJBHomeInvocationHandler.java:306)
    at $Proxy179.findByPrimaryKey(Unknown Source)
    at sun.reflect.GeneratedMethodAccessor98.invoke(Unknown Source)
    at
    sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at
    com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:241)
    at
    com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
    at
    com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
Comment by Ken Cavanaugh [ 11/Nov/10 ]

Both of the new lock contention issues have the same cause: exclusive write
locking in POAImpl.find_POA. I can fix that, but please note that this is
a different issue than was originally reported. That's OK: we are using
this issue generically for any corba trade2 perf issue. But we need to find
a way to turn around fixes for this faster than once a week or so. What we
are doing here is finding issues one after another, because one issue
masks another.

A question: why are these issues showing up now? In most case, I haven't
changed the code since GF 2.1.

I'll fix this in the morning. Currently that means a new ORB integration
into the current GF 3.1, which will take at least 3 hours elapsed time.

Comment by Ken Cavanaugh [ 12/Nov/10 ]

The common path through POA_find (the case where the POA already exists)
now only requires a read lock, so that should fix this performance issue.
Integrated into GF 3.1 rev 42781.





[GLASSFISH-12368] Memory leaks in Glassfish v3 Created: 24/Jun/10  Updated: 08/Feb/12  Resolved: 15/Nov/10

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: v3.0.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: Harald Wellmann Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Attachments: Zip Archive leak.zip    
Issuezilla Id: 12,368
Status Whiteboard:

weld-int-required


 Description   

Glassfish v3 and v3.0.1 leak memory when repeatedly redeploying the same
application.

The actual use case in our project is that we work with Eclipse and the
Glassfish plugin so that our application get redeployed automatically whenever
we save a file. After a couple of edit-save-redeploy cycles, Glassfish throws an
OutOfMemoryError (either with heap or PermGenSpace) so we have to kill the
Glassfish process and/or restart Eclipse to continue working which is rather
annoying.

This problem first occurred on Glassfish v3 (full profile). Our application uses
JPA (Hibernate), EJBs (Local Stateless Session Beans), Wicket and CDI injections
both in the EJB and web layers.

Taking heap dumps with jvisualvm after a number of redeployments, I could
observe multiple copies of our application classes loaded by different instances
of WebappClassLoader. Some of these had a GC root deep down in the Felix module
storage of the weld-osgi-bundle.

Having a look at the Glassfish and Weld sources, I noticed that the problem was
indeed caused by Weld, not by Glassfish: they registered a "singleton per
classloader" of their Container class and forgot to unregister it on undeployment.

This bug is fixed in Weld 1.0.1, so then I checked whether a more recent
Glassfish build would contain this version of Weld (and not the buggy 1.0.0.SP4
version from Glassfish v3).

At that time, Glassfish 3.0.1b21 was the most recent promoted build, and it
contained Weld 1.0.1.SP3, so I gave it a try, and the problem was gone, or at
least I could redeploy my application a much larger number of times without any
memory issues.

I was looking forward to using the official 3.0.1 release instead of the
promoted build, but unfortunately this release has even more drastic memory
leaks on repeated redeployment of our application.

So far, I have no clue what the cause might be, I don't think it is Weld this
time. Heap dumps do not give much indication either; this time I can see
multiple instances of WebAppClassLoader most of which do not have a GC root at
all, and the remaining ones have a GC root in (Timer)Thread.contextClassLoader.

I'll try to isolate the problem and hopefully attach a small web app to this
issue to make it reproducible.

We are using Sun JDK 1.6.0_20 on Ubuntu 10.04 and Windows XP.



 Comments   
Comment by Alexis MP [ 24/Jun/10 ]

cc

Comment by Hong Zhang [ 24/Jun/10 ]

Yes, a small application which could be used to reproduce the problem will be
great. Thanks!

Comment by Harald Wellmann [ 26/Jun/10 ]

Using Eclipse Memory Analyzer which provides more detailed information than
jvisualvm, I discovered the following:

1) There are multiple instances of WebappClassLoader which do not get garbage
collected since they are strongly reachable from
javassist.util.proxy.ProxyFactory.proxyCache, a static member in
weld-osgi-bundle.jar.

2) My application uses Hibernate (contained in the WAR) and CDI (implemented by
the Weld module from Glassfish). Hibernate, Weld and the Glassfish Integration
Module all use javassist. In my heap dump I can see just one copy of the
javassist.util.proxy.ProxyFactory class, but multiple copies of lots of other
javassist.* classes.

My WAR contains Hibernate with all its dependencies, including javassist, and
the Weld OSGi bundle wraps another copy of javassist which for some reason is
not fully private: Bundle org.jboss.weld.osgi-bundle exports package
javassist.util.proxy while keeping all other javassist packages private.

This means that the javassist module as seen by Hibernate is broken: the
javassist.util.proxy package comes from the global Weld bundle class loader via
parent delegation, whereas all other javassist packages come from the same
WebappClassLoader as Hibernate.

3) The static proxyCache is a WeakHashMap, mapping class loaders to maps of
proxied classes. Apparently the intention is that all proxies for classes from a
given classloader should get garbage collected when the given classloader is no
longer strongly reachable.

However, the WeakHashMap Javadoc clearly states that map entries will NOT get
cleared when the key is strongly reachable from the value. But here the proxy
map for my WebappClassLoader contains a Hibernate/javaassist proxy for one of my
entity classes which again strongly references the WebappClassLoader.

So this seems to be causing the PermGen leak.

Comment by Hong Zhang [ 26/Jun/10 ]

Thanks for the investigation. From your analysis, seems this is still mostly
related to weld. Assign to Siva for further investigation.

Comment by Harald Wellmann [ 08/Jul/10 ]

Created an attachment (id=4553)
Example project demonstrating memory leak

Comment by Harald Wellmann [ 08/Jul/10 ]

Now here is a simple example project, containing nothing but a POM, two entity
classes and a @Singleton @Startup bean creating a couple of entities on startup.

Hibernate 3.5.3 is used as persistence provider, using the default Derby data
source (jdbc/__default).

Simply run mvn package, deploy to Glassfish a couple of times, or import the
project into Eclipse and do a couple of whitespace modifications to trigger
redeployment, and you'll see PermGen space filling up.

Running on Linux amd64 with 256m heap and 96m PermSize, I get a PermGen
exception after 5 or 6 redeployments.

In a heap dump you can see most of the symptoms I noted in the analysis of my
larger web app: multiple WebappClassLoader instances, multiple copies of my
application classes and of most javassist classes, except the ones from package
javassist.util.proxy.

Hope this helps.

Comment by Harald Wellmann [ 08/Jul/10 ]

Addendum:

You need to declare the JBoss Maven repository, either in your settings.xml or
in the POM of the example:

<repository>
<id>JBoss</id>
<url>http://repository.jboss.org/nexus/content/groups/public</url>
</repository>

Comment by Harald Wellmann [ 11/Jul/10 ]

Seems they did something about this in Weld:
https://jira.jboss.org/browse/WELD-453

Comment by Harald Wellmann [ 13/Jul/10 ]

Same problem reproducible in 3.1-b09.

Comment by Sivakumar Thyagarajan [ 13/Jul/10 ]

Yes, there is another related WELD issue
https://jira.jboss.org/browse/WELD-476 that captures a similar out-of-memory
issue. NetBeans was earlier adding a beans.xml by default to all Java EE 6
applications and thus large web non-CDI application were also affected by this.
We have since fixed NetBeans to not cdi-enable web-applications by default.

A portion of the Weld changes have been made in the Weld trunk as per the latest
comment in WELD-476. We hope to integrate a latest version of Weld 1.1 (trunk)
into GlassFish v3.1 milestone 3(code freeze next Monday). I would also test the
application attached in this issue against the new integtation. Please let us
know if there are any updates on this.

Comment by Harald Wellmann [ 14/Jul/10 ]

I don't think WELD-476 is related to this problem, they are just trying to
reduce the overall memory footprint.

My problem is to do with dangling classloaders that do not get garbage
collected, so even if the Weld guys reduce their memory footprint by 90 %, the
leak I'm experiencing will still occur after a sufficient number of redeployments.

Their use of javasisst is definitely dodgy, they should not export just one
package from that bundle and keep the rest private. This is bound to cause havoc
for other components using javassist (like Hibernate in my case).

Weld trunk currently still has this javassist export in the manifest headers, so
I do not expect the problem to simply go away with the integration of Weld 1.1.0
or whatever the next release will be.

Have you been able to reproduce the leak with the test case I provided?

Comment by Harald Wellmann [ 26/Jul/10 ]

Problem still persists with upgraded version of Weld in Glassfish 3.1b12.

I filed a bug report for Weld in https://jira.jboss.org/browse/WELD-570.

Comment by Sivakumar Thyagarajan [ 06/Aug/10 ]

Thanks hwellmann for the analysis. I was able to reproduce the scenario and see
the multiple WebappClassloaders(of earlier version of the Webapp) still being
held and the VM running out of PermGen space after multiple re-deploys. I also
agree with his analysis. I am working with the Weld team on this. They are
working on integrating a latest version of Javassist (see
https://jira.jboss.org/browse/WELD-582 added as a dep of
https://jira.jboss.org/browse/WELD-570) which should remove the issues are
Javassist. With the new Weld proxy serialization SPI changes, we can also reduce
the Javassist exports in the weld-osgi-bundle.

Comment by rjdkolb [ 19/Aug/10 ]

Some interesting reading on class loaders and memory leaks :
http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded
http://blogs.sun.com/fkieviet/entry/more_on..._how_to_fix
http://blogs.sun.com/fkieviet/entry/javaone_2007

A similar issue :
https://glassfish.dev.java.net/issues/show_bug.cgi?id=11159

Comment by Sivakumar Thyagarajan [ 08/Oct/10 ]
      • Issue 13456 has been marked as a duplicate of this issue. ***
Comment by Sivakumar Thyagarajan [ 08/Oct/10 ]

We are waiting for a fix to WELD-570 https://jira.jboss.org/browse/WELD-570 that
would resolve this and other memory leak issues. Targetting this for MS7

Comment by Sivakumar Thyagarajan [ 22/Oct/10 ]

Marking as weld-int-required

Comment by Sivakumar Thyagarajan [ 15/Nov/10 ]

With the latest integration of Weld 1.1.MS2 [1] and resolution of WELD-570, I
don't see these leaks anymore. I was able to re-deploy the sample app attached
with this issue about 40-50 times and did not see a marked increase in Permgen
space and multiple webappclassloaders being held. Hence I am closing this issue.
Please let me know or update this issue, if you still see this issue.

[1] Integration of Weld 1.1.0.Beta2 into GlassFish 3.1 was complete a couple of
days ago. The trunk (post svn commit 42731) or a nightly after saturday (b30-
11_13) could be used to test this integration.

Comment by invinity [ 04/Apr/11 ]

Although I haven't dug into the exact memory behavior, I believe I am experiencing this same issue with the currently downloadable version of GF (3.1build43).

I'm using it with Eclipse 3.6 on Windows 7 64bit and after about 10 deployments of a relatively small application from Eclipse, my GF instance is using 1GB+ of memory and seems to peg one of the cores of my CPU (as it sits nearly constantly at 50% CPU usage). The application is deployed via an EAR project that has one EJB project and one web project under it. The EJBs are using JPA (EclipseLink), but no other EE services and the web project is using JSF and JAX-RS.

From what I gather looking at the past GF builds, the fix for this bug should be in the release I am using, but can someone in the know confirm this for sure? If I am running a build with the fix, then is there any advice on how to determine, for sure, where my problem is stemming from?

TIA
-matt

Comment by saboobaker [ 08/Feb/12 ]

We are facing same issue with Glassfish 3.1.1. We notice that when the application is deployed several times (4 or 5 times), glassfish reports permgen out of memory error. We have seen it on Windows as well as Linux platforms. On one of the instances, we do not have embedded eclipse.

Our project also uses Hibernate and Spring.





[GLASSFISH-12599] Injected Session Bean not serializable when it should be Created: 09/Jul/10  Updated: 29/Nov/11  Resolved: 15/Nov/10

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: Harald Wellmann Assignee: Sivakumar Thyagarajan
Resolution: Fixed 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,599
Status Whiteboard:

weld-int-required


 Description   

I have a stateless session bean Foo (no-interface local view) which implements
Serializable.

When I inject this bean into a client class FooClient, in one of the following ways,

@Inject
private Foo foo;

or

@EJB
private Foo foo;

the injected member foo fails to serialize and deserialize correctly.

I tested this using writeObject(foo) to a stream followed by readObject(...)
from that stream.

In the first case (@Inject), I get a null pointer exception when calling any
method on the object returned by readObject().

In the second case (@EJB), writeObject(foo) fails because
com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate is not serializable.

In the first case, the injected instance is a javaassist proxy wrapping a
Glassfish proxy wrapping the Foo implementation. The javasssist proxy appears to
be broken as reported in https://jira.jboss.org/browse/JASSIST-97.

After patching the weld-osgi-bundle.jar with javassist-3.12.1.GA which fixes the
bug, I ran into the same problem with EJBLocalObjectInvocationHandlerDelegate as
in the second case.

To sum up:
1) Glassfish needs to ensure that any proxy it generates for a serializable EJB
is also serializable.

2) Weld needs to be upgraded to a newer version containing the Javassist bugfix.



 Comments   
Comment by Sivakumar Thyagarajan [ 13/Jul/10 ]

As part of Weld 1.1, there is work going in the Weld SPI around better handling
of serialization of dynamically created client proxies and we are handling this
as part of GF3.1.

Is FooClient a Java EE application client or a Servlet/EJB/ManagedBean where the
injection is being done? Could you explain the use-case on why you explicitly
serialize the injected bean? Could you please share the application (client) and
the NPE stack-trace?

Comment by Harald Wellmann [ 14/Jul/10 ]

My application uses Wicket for the web UI, and Wicket serializes each page to
the page store at the end of the HTTP request.

Session beans get injected into my Wicket components for communicating with the
backend.

As I said, it is completely trivial to reproduce the problem construct in a
simple test case using writeObject() on a HelloWorld SLSB, and this is
absolutely independent of Wicket.

This test also fails when using @EJB à la Java EE 5 instead of @Inject, so I
would think that Weld does not enter the scene, and this part of the problem is
entirely on the Glassfish side - assuming that
com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate is within the
Glassfish domain and not third-party code.

Comment by Harald Wellmann [ 14/Jul/10 ]

My application uses Wicket for the web UI, and Wicket serializes each page to
the page store at the end of the HTTP request.

Session beans get injected into my Wicket components for communicating with the
backend.

As I said, it is completely trivial to reproduce the problem in a simple test
case using writeObject() on a HelloWorld SLSB, and this is absolutely
independent of Wicket.

This test also fails when using @EJB à la Java EE 5 instead of @Inject, so I
would think that and this part of the problem has nothing to do with Weld and is
entirely on the Glassfish side - assuming that
com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate is within the
Glassfish domain and not third-party code.

Comment by Mahesh Kannan [ 07/Oct/10 ]

Assigning this to Marina.

Marina: Check with Linda if Local EJB references have to be Serializable

Comment by marina vatkina [ 11/Oct/10 ]

Seems like a CD issue: neither the CDI spec nor the EJB spec imposes
requirements that proxies be serializable. Latest Weld expects them to be
"passivateable". Older versions of weld maybe required it to be serializable,
but weld 1.1 doesn't.

Comment by Harald Wellmann [ 12/Oct/10 ]

Just to make the point clearer: The question is not whether EJB or CDI proxies
should be serializable IN GENERAL.

But when a user-defined class Foo implements Serializable, any proxy to Foo must
satisfy the contract of the original class Foo, so the proxy should be
serializable too.

Comment by marina vatkina [ 12/Oct/10 ]

Neither spec require ANY proxies to be serializable, whether the bean class
implements it or not. So even if Foo implements Serializable, it's proxy is not
required to do so.

Comment by Sivakumar Thyagarajan [ 13/Oct/10 ]

The weld proxy is serializable and for classes that implement serializable its
weld proxy must be serializable too. It appears that the weld de-serializable
should be fixed with an upgrade of javassist. Weld 1.1 trunk nows uses 3.13.0-GA
and once we have an integration of Weld 1.1.BETA2 with this, this issue should
be fixed. I will re-check this scenario after the integration and close this
issue for the @Inject part.

Comment by Sivakumar Thyagarajan [ 22/Oct/10 ]

Marking as weld-int-required

Comment by Sivakumar Thyagarajan [ 15/Nov/10 ]

Since Weld 1.1.BETA2 with the latest javassist release is integrated and a test-
case [1] that tries to reproduce this behaviour passes, I am closing this issue.

[1] https://svn.dev.java.net/svn/glassfish-svn/trunk/v2/appserv-
tests/devtests/cdi/javaee-integration/no-interface-local-view-proxy-serializable

Comment by buddypine [ 24/Nov/11 ]

There is an error in the tests, the SLSB is actually marked as @Stateful - but the test still passes when changed to @Stateless.

However if I directly inject the SLSB into the servlet then try to serialize the injected proxy it fails with a NotSerializableException.
Should the injected SLSB proxy not be serializable?

@WebServlet(name = "mytest", urlPatterns = { "/myurl" })
public class NoInterfaceProxySerializableEJBTestServlet extends HttpServlet {

    @Inject
    HelloNoInterfaceLocalViewSlessEJB helloNoInterfaceLocalViewSlessEJB;
.. 
[#|2011-11-24T08:45:26.535+0100|SEVERE|glassfish3.1.1|
javax.enterprise.system.std.com.sun.enterprise.server.logging
|_ThreadID=22;_ThreadName=Thread-6;|
java.io.NotSerializableException: test.ejb.__EJB31_Generated__HelloNoInterfaceLocalViewSlessEJB__Intf____Bean__
Comment by marina vatkina [ 28/Nov/11 ]

Do you have beans.xml in the your module? If not, local EJB reference is not serializable without CDI being enabled.

Comment by buddypine [ 29/Nov/11 ]

Yes I do. I'm simply modifying the Glassfish tests from here - http://java.net/projects/glassfish/sources/svn/show/trunk/v2/appserv-tests/devtests/cdi/javaee-integration/no-interface-local-view-proxy-serializable.





[GLASSFISH-11536] NoClassDefFoundError: Cannot deploy EAR with beans.xml and session bean contained in WAR Created: 09/Feb/10  Updated: 05/Oct/11  Resolved: 01/Dec/10

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: V3
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: keil Assignee: Sivakumar Thyagarajan
Resolution: Duplicate Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Attachments: File EnterpriseApplication1-war.war     File EnterpriseApplication1.ear     Zip Archive EnterpriseApplication1.zip     Zip Archive mavencdiproject.zip    
Issue Links:
Duplicate
duplicates GLASSFISH-14842 CDI injection stopped working in 3.1? Resolved
Issuezilla Id: 11,536

 Description   

The attached enterprise application (NetBeans project) fails to deploy in glassfish.

The war module works standalone but not within the ear.

Here is the log:

INFO:

{felix.fileinstall.poll (ms) = 5000, felix.fileinstall.dir = C:\Programme\sges-v3\glassfish\domains\domain1\autodeploy\bundles, felix.fileinstall.debug = 1, felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = C:\DOKUME~1\MAM020~1.000\LOKALE~1\Temp\fileinstall-1216822139805894261, felix.fileinstall.filter = null}

INFO: Portable JNDI names for EJB TestBean1 :
[java:global/EnterpriseApplication1/EnterpriseApplication1-ejb/TestBean1,
java:global/EnterpriseApplication1/EnterpriseApplication1-ejb/TestBean1!module.ejb.TestBean1]
INFO: Portable JNDI names for EJB TestBean2 :
[java:global/EnterpriseApplication1/EnterpriseApplication1-war/TestBean2!module.war.TestBean2,
java:global/EnterpriseApplication1/EnterpriseApplication1-war/TestBean2]
INFO: Instantiated an instance of
org.hibernate.validator.engine.resolver.JPATraversableResolver.
INFO: nullID: /C:/Dokumente und Einstellungen/mam02072/Eigene
Dateien/NetBeansProjects/security-scratch/EnterpriseApplication1/dist/gfdeploy/EnterpriseApplication1/EnterpriseApplication1-war_war/
CLASSES: [class module.war.TestBean2, class
org.netbeans.rest.application.config.ApplicationConfig]

SCHWERWIEGEND: Exception while loading the app
org.glassfish.deployment.common.DeploymentException: by
java.lang.NoClassDefFoundError: module/war/TestBean2
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:169)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:125)
at
org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:224)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:338)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183)
at
org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:305)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1224)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:365)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:204)
at
com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
at
com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:245)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.RuntimeException: by java.lang.NoClassDefFoundError:
module/war/TestBean2
at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:344)
at javassist.util.proxy.ProxyFactory.createClass2(ProxyFactory.java:314)
at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:273)
at org.jboss.weld.util.Proxies.createProxyClass(Proxies.java:153)
at org.jboss.weld.util.Proxies.createProxyClass(Proxies.java:141)
at org.jboss.weld.bean.SessionBean.initProxyClass(SessionBean.java:210)
at org.jboss.weld.bean.SessionBean.initialize(SessionBean.java:121)
at
org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy(AbstractBeanDeployer.java:111)
at
org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:151)
at
org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:367)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:167)
... 30 more
Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError:
module/war/TestBean2
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:169)
at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:339)
... 40 more
Caused by: java.lang.NoClassDefFoundError: module/war/TestBean2
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javassist.util.proxy.FactoryHelper.toClass2(FactoryHelper.java:181)
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:163)
... 41 more
Caused by: java.lang.ClassNotFoundException: module.war.TestBean2
at
com.sun.enterprise.loader.ASURLClassLoader.findClassData(ASURLClassLoader.java:713)
at
com.sun.enterprise.loader.ASURLClassLoader.findClass(ASURLClassLoader.java:626)
at java.lang.ClassLoader.loadClass(ClassLoader.java:303)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316)
... 48 more



 Comments   
Comment by keil [ 09/Feb/10 ]

Created an attachment (id=4211)
NetBeans project, deployment fails in glassfish

Comment by Hong Zhang [ 09/Feb/10 ]

assign to cdi category for initial evaluation

Comment by rogerk [ 09/Feb/10 ]

Any chance you can provide a packaged ear/war so I can immediatley deploy it?

Comment by keil [ 09/Feb/10 ]

Created an attachment (id=4212)
packaged ear

Comment by keil [ 09/Feb/10 ]

Created an attachment (id=4213)
working standalone war

Comment by rogerk [ 02/Mar/10 ]

Starting..

Comment by rogerk [ 04/Mar/10 ]

Can you provide the Java source in addition to the class files (ok if they are
contained in ear/jar/war.

Comment by keil [ 04/Mar/10 ]

Java source is already attached. Have a look at EnterpriseApplication1.zip
(first attachment)

Comment by rogerk [ 08/Mar/10 ]

More information -

The exception does indeed occur when module.war.TestBean2 is an ejb within the
war. The deployment is fine, however, when module.war.TestBean2 is NOT an ejb
within the war.

Comment by keil [ 09/Mar/10 ]

I'm not sure if your last comment describes the problem correctly.

module.war.TestBean2 is an EJB contained in the war. The war has no dependencies
to any other ejb module.

Deployment of the war works for the standalone war. But if this war is part of
an ear deployment fails.

In other words: cdi in glassfish does not work for enterprise application
archives (ear).

Comment by rogerk [ 16/Mar/10 ]

Assigning to Sahoo.

Comment by keil [ 12/May/10 ]

I've tested the attached EnterpriseApplication1.ear with glassfish-3.0.1-b17 and
the problem still exists.

Is there a chance that this Bug will be fixed in release 3.0.1?

Comment by Sanjeeb Sahoo [ 06/Oct/10 ]

I can still see the issue with recent trunk builds. This bug does not belong to
classloader module. It appears to me that incorrect classloader is used to
bootstrap Weld which is more likely to be caused by incorrect classloader being
set as the thread's context classloader by deployment backend. Assigning it to
deployment team to investigate further.

Comment by Hong Zhang [ 19/Oct/10 ]

The thread context classloader of the APPLICATION_LOADED event (which sent from
ApplicationInfo) is set to be the top level application classloader. In case of
a standalone module, it's the same as the module classloader which knows how to
load classes in the module, but in case of ear, the top level application
classloader is different than the web module classloader which does not know
how to load classes in the module.

Seems like the CDI code needs to listen to Deployment.MODULE_LOADED event
instead (sent from ModuleInfo class) so it gets the module classloader instead.

I have modified the ModueInfo class so that when we send the module load event,
the thread context has the proper classloader (module classloader).

Comment by Sivakumar Thyagarajan [ 01/Dec/10 ]

This issue is the same as 14842. A fix for that is being worked on and a fix would be checked in a few days.

Comment by Sivakumar Thyagarajan [ 01/Dec/10 ]

Marking this as a duplicate. I was able to ensure that the attached EAR in this application also works with the fix for 14842

Comment by alniks [ 05/Oct/11 ]

The problem remains in glassfish 3.1.1. I have reproduced it in a simple CDI maven EAR application attached, with the following exception:

Caused by: java.lang.ClassNotFoundException: com.alniks.test.cdi.web.LoggingInterceptor
at com.sun.enterprise.loader.ASURLClassLoader.findClassData(ASURLClassLoader.java:787)
at com.sun.enterprise.loader.ASURLClassLoader.findClass(ASURLClassLoader.java:696)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at org.jboss.weld.resources.DefaultResourceLoader.classForName(DefaultResourceLoader.java:52)
at org.jboss.weld.manager.Enabled$ClassLoader.apply(Enabled.java:71)
... 41 more

PS: The attached application has been deployed through Netbeans on Windows 7 x64. The application deploys and runs fine on JBoss 7.





[GLASSFISH-14842] CDI injection stopped working in 3.1? Created: 28/Nov/10  Updated: 04/Sep/11  Resolved: 02/Dec/10

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: David Konecny Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish-3.1-b31-11_28_2010.zip
Operating System = Linux version 2.6.35-22-generic running on amd64
Java; VM; Vendor = 1.6.0_22; Java HotSpot(TM) 64-Bit Server VM 17.1-b03; Sun Microsystems Inc.
Runtime = Java(TM) SE Runtime Environment 1.6.0_22-b04


Issue Links:
Duplicate
is duplicated by GLASSFISH-11536 NoClassDefFoundError: Cannot deploy E... Resolved
is duplicated by GLASSFISH-14841 CDI Annotations not working in 3.1-b29 Resolved

 Description   

Running trivial EAR with WEB module (JSF2.0) which uses CDI to create a named bean and access that bean from index.xhtml page does not work on glassfish-3.1-b31-11_28_2010. The application runs fine on GF3.0.1. Using @ManagedBean annotation instead of @Named resolves the problem on 3.1. Therefore something must be wrong with CDI.

The test application can be found here: http://netbeans.org/bugzilla/attachment.cgi?id=103394 - it is Maven based app attached to NetBeans issue 177230.



 Comments   
Comment by Sivakumar Thyagarajan [ 29/Nov/10 ]

This seems to similar as this other issue?
http://java.net/jira/browse/GLASSFISH-11536

The APPLICATION_LOADED events has the application level classloader as the thread context classloader and the MODULE_LOADED event has the module classloader as the thread context classloader, seems CDI code should listen to MODULE_LOADED event instead?

Comment by Sivakumar Thyagarajan [ 01/Dec/10 ]

Transferring this issue back to me. The current state of the EARClassLoader and its use as TCL, will be raised as a separate issue if needed. A fix for this issue could be handled in the Weld integration side. During Bean deployment, when Weld loads Beans classes, GlassFish could either

  • set the appropriate module classloader as TCL and let the Weld's DefaultResourcesLoader pick this TCL to load the class or
  • use a custom ResourceLoader that is aware of the module classloader of the bean.

The former approach is being investigated and a fix is available. Will commit after review/tests.

Comment by Sivakumar Thyagarajan [ 02/Dec/10 ]

Commited the following change to fix this issue.

Sending weld-integration/src/main/java/org/glassfish/weld/BeanDeploymentArchiveImpl.java
Sending weld-integration/src/main/java/org/glassfish/weld/WeldDeployer.java
Transmitting file data ..
Committed revision 43350.

Comment by alniks [ 04/Sep/11 ]

I am having a java.lang.ClassNotFoundException for the @Interceptor in WAR archive when I try to deploy an EAR archive on GF 3.1.1 with CDI enabled in WAR and EJB JAR archives. The application deploys fine on JBoss 7.





[GLASSFISH-6655] Better integration between NetBeans RCP and Glassfish Created: 28/Oct/08  Updated: 23/Aug/11  Resolved: 10/Dec/10

Status: Closed
Project: glassfish
Component/s: ejb_container
Affects Version/s: 9.1peur2
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: vieiro Assignee: Cheng Fang
Resolution: Won't Fix Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Attachments: Java Archive File EJBUtils.jar     Java Source File EJBUtils.java     Java Source File EJBUtils.java     Text File patch.diff    
Issuezilla Id: 6,655

 Description   

Attached please find a patch to com.sun.ejb.EJBUtils that improves integration
between NetBeans RCP based applications and Glassfish, by using standalone clients.

Patch is for

http://fisheye4.atlassian.com/browse/~raw,r=17529/glassfish-svn/trunk/v2/appserv-core/src/java/com/sun/ejb/EJBUtils.java

in Glassfish v2ur2.

I'll be adding a new test case at
http://www.netbeans.org/issues/show_bug.cgi?id=151368
in the following hours



 Comments   
Comment by vieiro [ 28/Oct/08 ]

Created an attachment (id=2023)
Patch for EJBUtils (17529)

Comment by psartini [ 20/Nov/08 ]

added myself to cc

Comment by valarin [ 09/Mar/09 ]
      • Issue 6655 has been confirmed by votes. ***
Comment by David Konecny [ 15/Feb/10 ]

This issue is actually a defect in GF classloader which is blocking several
users from using GF from within NetBeans platform. It is high priority for NB as
NetBeans RCP usability in EE development is one of the themes of NB 69.

Attached patch supposed to fix/workaround it (I have not tested it myself). I
cannot confirm whether problem happens in GFv3 as well but I assume it does.

For long discussion and description of the problem please read
https://netbeans.org/bugzilla/show_bug.cgi?id=151368
and
https://netbeans.org/bugzilla/show_bug.cgi?id=125107

If there is anything you think should be changed on NetBeans side please mention
it in https://netbeans.org/bugzilla/show_bug.cgi?id=125107 and we will address
is ASAP. Thanks.

Comment by David Konecny [ 15/Feb/10 ]

CORRECTION: when I said "please mention it in
https://netbeans.org/bugzilla/show_bug.cgi?id=125107 and we will address is
ASAP" I used wrong issue. Use issue
https://netbeans.org/bugzilla/show_bug.cgi?id=151368 which is still open. thx.

Comment by dbenegiamo [ 17/Feb/10 ]

added myself to cc

Comment by dbenegiamo [ 17/Feb/10 ]

added myself to cc

Comment by dbenegiamo [ 03/Mar/10 ]

Is there any progress with this issue (started in 2008)? A working patch seems
to exists (see also NB links).

As it affects also GF3, issue data (version, milestone, etc.) should be updated?

Comment by Tim Quinn [ 03/Mar/10 ]

For no good reason this fell off my radar screen.

The change described in the patch here and in the NB issues is to an EJB-related
class which I'm not familiar with. I understand that the manifestation of the
problem is in app clients, but even so I think it's best to get the EJB folks to
weigh in on this and make whatever change is appropriate.

For that reason I'm reassigning this to the EJB component.

Comment by marina vatkina [ 09/Jun/10 ]

NB issue says that these changes are needed for v3:
From
https://glassfish-svn.dev.java.net/source/browse/glassfish-svn/trunk/v3/ejb/ejb-container/src/main/java/com/sun/ejb/EJBUtils.java?rev=35461&view=markup

The change is in line 592

From

return _generate(loader, protectionDomainBase.getProtectionDomain(),

To

return _generate(protectionDomainBase.getClassLoader(),
protectionDomainBase.getProtectionDomain(),

vieiro, can you post the stack trace to the point of the call? Most of the
EJBUtils code use classloader that was used to create the class passed to the
generateAndLoad call.

Comment by vieiro [ 09/Jun/10 ]

Hi,

You can find stack traces at:

http://www.netbeans.org/issues/show_bug.cgi?id=151368
or
http://bugzilla-attachments-151368.netbeans.org/bugzilla/attachment.cgi?id=72652

For a more detailed detail of ClassLoader behaviour see

http://netbeans.org/bugzilla/attachment.cgi?id=72653 (gzipped file).

The NetBeans Platform isolates modules by means of independent class loaders.

The test suite at

http://netbeans.org/bugzilla/attachment.cgi?id=72654

Has three modules:

  • An "EJB" module with the EJB client classes only.
  • A "GLASSFISH" module with all Glassfish "standalone" jars. At the time this
    issue
    was posted the following files seemed to work well:
  • appserv-cmp.jar
  • appserv-deployment-client.jar
  • appserv-ext.jar
  • appserv-rt.jar
  • javaee.jar

This module has a dependency to the EJB module, so it can see EJB client
classes. [GLASSFISH -> EJB ]

  • A "GUI" module, that contains a window.
    This module has a dependency to the GLASSFISH module (so it can see
    InitialContext, etc.)
    and a dependency to the EJB module (so it can see EJB interfaces).
    [GUI -> EJB]
    [GUI -> GLASSFISH ]

Note that these dependencies are not transitive (i.e, [GUI -> GLASSFISH] and
[GLASSFISH->EJB]
do NOT imply [GUI->EJB], so that's why we need [GUI->EJB] too.

The problem arises because of this feature of the NetBeans Platform (which has
proven very valuable during the years): there're two "EJB" classloaders:

  • The "EJB" classloader that "GLASSFISH" is able to see.
  • The "EJB" classloader that "GUI" is able to see.

The patch I propose for EJBUtils.java makes GLASSFISH use the appropriate class
loader.

Comment by marina vatkina [ 09/Jun/10 ]

Does it apply to v2.x code (in cvs) or v3 trunk (in svn)?

Comment by vieiro [ 09/Jun/10 ]

The problem happens both on Glassfish v2 and Glassfish v3.

The attached patch at

https://glassfish.dev.java.net/nonav/issues/showattachment.cgi/2023/patch.diff

is for Glassfish v2ur2. I didn't generate a patch for Glassfish v3, but this:

http://netbeans.org/bugzilla/show_bug.cgi?id=151368#c29

may be of help (i.e.: it's the same problem on the same line).

Comment by marina vatkina [ 10/Jun/10 ]

It's not a question on how to fix, but rather why do we need to change anything
(and classloader structure in v3 is very complicated).

Please either attach a (simple) test case that we can use to investigate the
problem, or (if not possible to produce the test) help us with more details. For
the latter, please post the stack trace that leads to the method that you
suggest to change.

Comment by vieiro [ 10/Jun/10 ]

Hi,

I give up. Please consider closing the issue, or letting other people build
another test case.

Cheers,
Antonio

Comment by jthoennes [ 10/Jun/10 ]

Looking at wealth of information and patches provided, it is a pity that Antonio
has to give up. He had really exercised "due diligence."

Would be really good if the Glassfish people could take over.

Comment by marina vatkina [ 10/Jun/10 ]

Antonio, please don't give up! Is there a test case that we can use?

thanks,
-marina

Comment by vieiro [ 11/Jun/10 ]

You can find a test case here:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=6655

But, seriously, don't bother with this issue.

The NetBeans Community has been living with this for several years now, and I
think there's no reason to live with it for another two years.

They've probably solved the problem using a Glassfish AppClientContainer
transferring hundredths of megabytes through the wire, or using JAX-WS (with or
without infoset) or using JBoss or WebLogic or WebSphere or any other J2EE
server out there.

My customers, for instance, are enjoying cool J2EE GUI clients and they don't
bother a dime about what the J2EE server is (currently JBoss).

So, seriously, I think this issue should be closed and we should move to more
profitable things (such as making our customers happy with spiffy client-side
applications, as in my case).

Cheers,
Antonio

Comment by marina vatkina [ 24/Jun/10 ]

->Cheng

Comment by Cheng Fang [ 06/Jul/10 ]

Created an attachment (id=4545)
com/sun/ejb/EJBUtils*.class in a jar, used to update ejb-container.jar

Comment by Cheng Fang [ 06/Jul/10 ]

The changed proposed by vieiro will break the server side. I modified
EJBUtils.java based on vieiro's initial proposal to try an alternate classloader
(protectionDomainBase.getClassLoader()) if the initial loader (the one passed in
as param) fails.

The modified EJBUtils is based on GlassFish 3.1, should be compatible with 3.0.1
and 3.1, but may not work with v2.x.

If someone can try the attached EJBUtils.jar with RCP, that will be great. You
will need to back up your existing ejb-container.jar, update your
ejb-container.jar (both the server side and client side) with the content from
EJBUtils.jar.

Rerun your RCP project. Some logs are also added in EJBUtils, search for
"try alternate" in GF server.log, and there should be none. You should be able
to see some "try alternate" logs in client output.

The following is the modified generateAndLoad(...) method:

private static Class generateAndLoad(ClassGeneratorFactory cgf,
final String actualClassName,
final ClassLoader loader,
final Class protectionDomainBase) {
cgf.evaluate();

final Properties props = new Properties();
if( _logger.isLoggable(Level.FINE) ) {
props.put(DUMP_AFTER_SETUP_VISITOR, "true");
props.put(TRACE_BYTE_CODE_GENERATION, "true");
props.put(USE_ASM_VERIFIER, "true");

try

{ ByteArrayOutputStream baos = new ByteArrayOutputStream(); PrintStream ps = new PrintStream(baos); _sourceCode(ps, props); _logger.fine(baos.toString()); }

catch(Exception e)

{ _logger.log(Level.FINE, "exception generating src", e); }

}

//Fix for issue 6655 (integration with NetBeans Eclipse RCP client)
Class result = null;
RuntimeException exception = null;
try

{ result = generateAndLoad0(props, actualClassName, loader, protectionDomainBase); }

catch (RuntimeException e)

{ exception = e; }

if (result == null) {
_logger.log(Level.INFO,
"Could not generate and load with loader

{0}

, try alternate
classloader:

{1}

",
new Object[]

{loader, protectionDomainBase.getClassLoader()}

);
try

{ result = generateAndLoad0(props, actualClassName, protectionDomainBase.getClassLoader(), protectionDomainBase); }

catch (RuntimeException e)

{ //ignore _logger.log(Level.INFO, "Could not generate and load with alternate loader.", e); }

}
if (result == null)

{ throw exception; }

return result;
}

private static Class generateAndLoad0(final Properties props,
final String actualClassName,
final ClassLoader loader,
final Class protectionDomainBase) {
Class result = null;
try {
if(System.getSecurityManager() == null)

{ result = _generate(loader, protectionDomainBase.getProtectionDomain(), props); }

else {
result = (Class) java.security.AccessController.doPrivileged
(new java.security.PrivilegedAction() {
public java.lang.Object run() {
return _generate(loader,
protectionDomainBase.getProtectionDomain(),
props);
}});
}
} catch (RuntimeException runEx) {
//We would have got this exception if there were two (or more)
// concurrent threads that attempted to define the same class
// Lets try to load the class and if we are able to load it
// then we can ignore the exception. Else throw the original exception
try

{ result = loader.loadClass(actualClassName); _logger.log(Level.FINE, "[EJBUtils] Got exception ex: " + runEx + " but loaded class: " + result.getName()); }

catch (ClassNotFoundException cnfEx)

{ throw runEx; }

}
return result;
}

Comment by xcallejas [ 06/Jul/10 ]

cf126330:

I tested your patch ('Tue Jul 6 19:20:00 +0000 2010: EJBUtils.jar') in Glassfish
3.0.1, with a NBP 6.9 application as client. I replaced the
com/sun/ejb/EJBUtils*.class from the ejb-contaner.jar with the ones of your
patch, both to the server and client (actually I'm running locally so the same
ejb-container.jar is used by the client). Then I restarted GF.

It partially works. The first time the NBP client try to call any EJB it fails
with the same exception, but it begins to work at the second time it tries to
call any (any other or the same) EJB.

The first time it try to call a EJB from the client it throws the exception:

INFO [javax.enterprise.resource.jta.com.sun.enterprise.transaction]: Using
com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate as the
delegate
WARNING [javax.enterprise.resource.corba.ee._CORBA_.util]: "IOP01211405:
(BAD_OPERATION) Exception in loadStub"
java.lang.ClassNotFoundException: com.sun.ejb.codegen.GenericEJBHome_Generated
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:262)
Caused: java.lang.ClassNotFoundException:
com.sun.ejb.codegen.GenericEJBHome_Generated starting from SystemClassLoader[57
modules] with possible defining loaders null and declared parents
[ModuleCL@206e41b5[org.netbeans.modules.print],
ModuleCL@106df95[org.netbeans.modules.autoupdate.services],
ModuleCL@33238785[org.netbeans.libs.osgi],
ModuleCL@510ebe18[org.netbeans.core.netigso],
ModuleCL@5f873eb2[org.netbeans.modules.settings],
ModuleCL@5d89635d[com.sistemasaereos.sscm.lib.swingx],
ModuleCL@52c4c57[com.sistemasaereos.sscm.desk.compras],
ModuleCL@7fb6634c[org.openide.loaders],
ModuleCL@488ddb93[com.sistemasaereos.sscm.lib.apachecommons],
ModuleCL@27a36a2[org.netbeans.api.progress],
ModuleCL@2b76086d[org.netbeans.modules.keyring],
ModuleCL@1d417690[org.netbeans.modules.queries],
ModuleCL@78497062[org.openide.nodes],
ModuleCL@64d22462[org.netbeans.libs.felix],
ModuleCL@f786a3c[com.sistemasaereos.sscm.desk.crm],
ModuleCL@a2a987d[org.openide.awt], ModuleCL@512d8ecd[org.openide.dialogs],
ModuleCL@578b1f8f[org.netbeans.modules.editor.mimelookup],
ModuleCL@64c272bc[org.netbeans.modules.options.api],
ModuleCL@3cd0d12e[org.netbeans.core.ui],
ModuleCL@2a63b2e6[org.netbeans.modules.options.keymap],
ModuleCL@7979a49f[org.netbeans.swing.tabcontrol],
ModuleCL@69f94884[org.netbeans.modules.favorites],
ModuleCL@43ce663c[org.openide.explorer],
ModuleCL@465ff916[com.sistemasaereos.sscm.lib.jcalendar],
ModuleCL@5e6ffd79[org.netbeans.core.windows],
ModuleCL@407e75d2[org.openide.actions], ModuleCL@257807a[org.openide.windows],
ModuleCL@26dfe303[com.sistemasaereos.sscm.model.client.ejb],
ModuleCL@dc67248[org.netbeans.spi.quicksearch],
ModuleCL@d896a4c[com.sistemasaereos.sscm.desk.commons],
ModuleCL@8dc1f04[org.netbeans.core], ModuleCL@4c2d0479[org.openide.text],
ModuleCL@77a9f87c[org.netbeans.modules.progress.ui],
ModuleCL@1e1ec86[com.sistemasaereos.sscm.desk.login],
ModuleCL@27f8922[com.sistemasaereos.sscm.commons.beansbinding],
ModuleCL@679801c[org.netbeans.core.io.ui],
ModuleCL@51a9876e[org.netbeans.modules.masterfs],
ModuleCL@153b2cb[org.netbeans.core.output2],
ModuleCL@6d1a0d35[com.sistemasaereos.sscm.desk.reportes],
ModuleCL@5bf0cf51[com.sistemasaereos.sscm.desk.compras.reportes],
ModuleCL@703aef16[org.netbeans.modules.core.kit],
ModuleCL@7b48392[org.netbeans.swing.outline],
ModuleCL@4c309f9f[com.sistemasaereos.sscm.lib.numerictextfield],
ModuleCL@7dc21ece[com.sistemasaereos.sscm.desk.erp],
ModuleCL@18abe654[org.netbeans.swing.plaf],
org.netbeans.MainImpl$BootClassLoader@593d93f4,
ModuleCL@66e7b3f2[org.netbeans.modules.editor.mimelookup.impl],
ModuleCL@31304043[org.netbeans.libs.jna],
ModuleCL@546d3b92[org.netbeans.modules.autoupdate.ui],
ModuleCL@3c63e8c[org.openide.io], ModuleCL@4ccd43ce[org.netbeans.core.nativeaccess]]
at org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:264)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at com.sun.corba.ee.impl.util.JDKBridge.loadClass(JDKBridge.java:229)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.loadClass(Util.java:640)
at
com.sun.corba.ee.impl.presentation.rmi.StubFactoryFactoryDynamicBase.createStubFactory(StubFactoryFactoryDynamicBase.

...

The second time it successfully call the EJB and display the next message:

INFO [javax.enterprise.system.container.ejb.com.sun.ejb]: Could not generate and
load with loader SystemClassLoader[57 modules], try alternate classloader:
sun.misc.Launcher$AppClassLoader@1f7182c1

rgds.
xavier

Comment by Cheng Fang [ 06/Jul/10 ]

Thanks, xavier. There are more loader issues. Another similar one is issue
12197, where the opposite is happending: the first call worked, and the second
call always failed.

Can you attache your complete RCP project and instructions running with
GlassFish 3.x? vieiro's testcase is for v2. I tried to modified it for v3, but
having various other errors.

Comment by lanthale [ 12/Jul/10 ]

I have recompiled from glassfish 3.0.1 source, changed the code as described in netbeans forum (see
link in this post) and replaced ejb-container.jar into my platform application. Now it is working but it
not reliable. If it is working the speed for calling the first EJB is very slow. If I increase the heap size to
512M than it seems that the login is working reliable and sometimes very fast. When I look at the
memory consumtion of my application that it is increased from 130MB without a client to around 450MB
with a application client. It seems to me that there is an almost complete glassfish server instance
running at the client.

Probably the described second EJB call come from not enough memory available to the client ?

One point which is very important to a platform application:
I know it is possible to create a jar file for a standalone client with package-client command

Comment by lanthale [ 12/Jul/10 ]

Created an attachment (id=4561)
Changed EJB File which is working if enough memory is available, but the first call of an EJB is much slower than in glassfish v2.1

Comment by lanthale [ 12/Jul/10 ]

Created an attachment (id=4562)
Changed EJB File which is working if enough memory is available, but the first call of an EJB is much slower than in glassfish v2.1

Comment by lanthale [ 12/Jul/10 ]

The following steps are necessary to get a working standalone client for glassfish v3:

  • Copy "gf-client.jar" to your modules "release/ext" directory
  • Extract "gf-client.jar" and examine the MANIFEST file
  • Copy all MANIFEST referenced jar files to the modules "release/ext" directory
  • Change the MANIFEST file of gf-client.jar: Remove all glassfish directories for all jar files
  • Update the gf-client.jar with the new MANIFEST file
  • Add "appclient.conf" the the release directory of your module
  • Add "jndi.properties" to the "release" directory of your module
  • Add the configuration to the above files

Now it is working. The attachment above shows the new EJBUtils.java. I have modified the call to the
correct classloader more times than vieiro so that it is the default behavior but I do not know what that
means if someone is using this outside of a netbeans RCP application.

Hopefully I could help you with solving this issue. One good possibility is that I create a netbeans
module which every platform developer can use but the first thing would be to find exactly the
classloader problems in glassfish.

Comment by Alexis MP [ 22/Oct/10 ]

cc

Comment by Cheng Fang [ 10/Dec/10 ]

The proposed fix (i.e., use EJBUtils classloader instead of thead context classloader) does not work on the server side. A similar issue on Eclipse RCP is http://java.net/jira/browse/GLASSFISH-12197 . Close it as Won't Fix.

Comment by mikevader [ 16/Feb/11 ]

Do I understand this correctly: There is no possibility to make an Netbeans RCP application to work with Glassfish v3 and above? Except if I add the patch above manually which would be quite dangerous on a larger server environment?!

Comment by vieiro [ 16/Feb/11 ]

I'm afraid you're not understanding it correctly. The fact is there is no possibility to make Glassfish v3 to work on a NetBeans RCP application. Inside a NetBeans RCP application the class-loading is mandated by the NetBeans RCP classloading architecture, and not by the Glassfish classloading architecture (that is acting just as a library to access the server-side data).

I submitted a patch about two years ago that solved a Glassfish v2 class-loading issue, so it would be possible to get Glassfish v2 to work on a NetBeans RCP application. The patch was targetted to the client-side jars, and you don't need to touch anything on the server side (i.e, you had to apply the patch to the jar in the client-side, but not on the server side).

I didn't try to patch Glassfish v3. It seems somebody else did, without success.

It seems you can also run a NetBeans RCP application inside a glassfish client container (see http://blogs.sun.com/geertjan/entry/deploying_swing_as_an_application) but I haven't investigated that (I don't like that solution).

Comment by arungupta [ 23/Aug/11 ]

Adding myself to the CC.





[GLASSFISH-12383] new db connection is used on commit Created: 25/Jun/10  Updated: 18/Aug/11  Resolved: 10/Nov/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: v3.0.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: nztraveller Assignee: Shalini
Resolution: Fixed 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 address_sql.txt     XML File domain.xml     Text File it-12383.tar.gz     HTML File Re- [Issue 12383] [jca] new db connection is used on commit     Text File server.log     Text File sql_trace.txt     Zip Archive src.zip     Text File stack_trace.txt     File test.ear    
Issuezilla Id: 12,383

 Description   

Using Hibernate, though I suspect this happens with other implementations as well, when some updates/ inserts are
flushed in a ejb method, and other updates/inserts are flushed at commit, an error will sometimes occur.
The error happens when the same data is updated both before and after the flush in the ejb method.
The issue appears to be that the same database connection is not reused when the session is flushed at commit. This
causes the update to fail because the updates from the first connection are not committed yet, and therefor are not visible
to the second connection.
Worse still is that when the rollback statement is issue, it is only issue on the first connection, not the second connection
leaving the database in a inconstant state with some updates/ inserts being left.

I have been able to reproduce this behaviour reliably and can confirm that more then one connection is being used by
tracing the connections and queries via the database directly.

to replicate this:
1) Call and ejb session bean method with cmt
2) retrieve some hibernate objects, and modify one
3) call any hql finder method or call session.flush()
4) Modify the same object again as in step 2

When the method completes the jta transaction manager will call hibernate to flush the session at which point you will get
a StaleObjectStateException because the version number of the modify entity will not match.

I have also run the same code on Glassfish 2.1.1 and WebSphere 5.1 (where we are migrating from) and it executes as
expected with only one connection being used.

To avoid duplicating the same infor again, see post:
http://forums.java.net/jive/thread.jspa?threadID=151083&tstart=0

This is a show stopper issue for us as we using this pattern through out. For the time being we are going to target v2.1.1
instead.

Please contact me if you require any further details.



 Comments   
Comment by marina vatkina [ 25/Jun/10 ]

Requesting connector team to take the 1st cut.

Comment by nztraveller [ 25/Jun/10 ]

Created an attachment (id=4503)
sql trace

Comment by nztraveller [ 25/Jun/10 ]

Created an attachment (id=4504)
sql to create address table

Comment by nztraveller [ 25/Jun/10 ]

Created an attachment (id=4505)
stack trace

Comment by nztraveller [ 25/Jun/10 ]

Created an attachment (id=4506)
domain.xml

Comment by nztraveller [ 25/Jun/10 ]

Created an attachment (id=4507)
ear

Comment by nztraveller [ 25/Jun/10 ]

Hi.
I have attached some addition info. sql trace shows the queries that are executed for v3 and for v2.1.
test.ear is a test.ear is a test case. You will need to add the hibernate jars to the /lib folder as they were
too big to attach. jars required are:
antlr.jar
asm.jar
cglib.jar
commons-collections.jar
commons-logging.jar
dom4j.jar
hibernate-annotations.jar
hibernate.jar

hibernate 3.2.6.ga was used.

src.zip is the source for the ear.
I have also attached my domain.xml as you will need to add a connection pool / data source for
hibernate to use called 'jdbc/mysql'.
The database used was mysql 5.1.43

I think this should provide you with everything you need, but please let me know if you need any
further details.

Cheers,
Jason

Comment by nztraveller [ 25/Jun/10 ]

Created an attachment (id=4508)
source code for test case

Comment by Jagadish [ 27/Jun/10 ]

Transferring to Shalini for investigation

Comment by Shalini [ 01/Jul/10 ]

When V3.1 promoted b07 was used, the issue was not seen. I added a few debug
statements before the application execution and the server.log shows:

[#|2010-07-01T17:39:44.867+0530|INFO|glassfish3.1|null|_ThreadID=34;_ThreadName=Thread-1;|This
is a ejb test|#]

[#|2010-07-01T17:39:45.097+0530|INFO|glassfish3.1|null|_ThreadID=34;_ThreadName=Thread-1;|a
= com.test.Address@1620283|#]

[#|2010-07-01T17:39:45.097+0530|INFO|glassfish3.1|null|_ThreadID=34;_ThreadName=Thread-1;|Done
setting address1|#]

[#|2010-07-01T17:39:45.161+0530|INFO|glassfish3.1|null|_ThreadID=34;_ThreadName=Thread-1;|Done
Flush|#]

[#|2010-07-01T17:39:45.162+0530|INFO|glassfish3.1|null|_ThreadID=34;_ThreadName=Thread-1;|Done
setting address2|#]

There was no StaleObjectStateException observed. Could you please mention which
build of 3.0.1 you used? Could you try using the latest build of v3.1 and see if
this is reproducible for you ?

Comment by nztraveller [ 01/Jul/10 ]

Hi.
Thanks for testing this issue.
We were running "GlassFish Server Open Source Edition 3.0.1 (build 22)".
It is a holiday here (Canada day), so I'll test with 3.1 when I return to the office on Monday.

Cheers,
Jason

Comment by nztraveller [ 05/Jul/10 ]

Hi.
I have tested this with "GlassFish Server Open Source Edition 3.1-b08 (build 8)" and still see the issue.
For this test I tried using another mysql connector to see if there was any difference. I have used mysql-
connector-java-5.0.7 and mysql-connector-java-5.1.12, both fail.
I thought that maybe your transaction isolation was not set correctly, but regardless of the setting it still
fails. If read-committed is used, then you get a StaleObjectStateException, the other settings get a lock
time out exception.
For the jdbc connection,' associate with thread' was used and was set to Guaranteed Isolation level of
Read-committed.
When looking at the sql trace, I see clearly that 2 connections are used.

If you are using mysql 5.1, you can enable the general query log like so: "SET GLOBAL general_log =
ON;" I would like to know if you are seeing 2 connections being used as well.

Can you provide any other details on how your system was configured?

I can provider additional stack trace and sql trace if required.

Cheers,
Jason

Comment by Shalini [ 05/Jul/10 ]

The only difference in the way i am testing is that i am using Derby database
and the corresponding hibernate dialect : org.hibernate.dialect.DerbyDialect. I
set the attributes :
steady pool size = 1
pool resize quantity = 1
associate with thread = true
allow non-component callers = true
statement cache size = 200
transaction isolation level = read committed
fail all connections = true

I use hibernate version 3.2.5.ga.

Comment by nztraveller [ 12/Jul/10 ]

Hi.
Sorry for not replying sooner. Last week was a release week for us.
Hum, I don't know much about Derby... but this issue is most certainly there with MySQL.
Is it possible that you can test with MySQL? I can probably setup a database for you if there is the issue.
I'm surprised that you didn't see the issue as from my logs it is quite clearly getting a new connection from
the pool. I would have expected the same behavior regardless of database or driver.
I'm guessing that maybe it is an issue of the interaction between glassfish and the MySQL driver.

Cheers,
Jason

Comment by Shalini [ 12/Jul/10 ]

Created an attachment (id=4566)
Server.log (successful test execution in mysql)

Comment by Shalini [ 12/Jul/10 ]

I could not reproduce this issue using a mysql driver as well. I changed the
hibernate.cfg.xml file to use org.hibernate.dialect.MySQLInnoDBDialect. I
rebuilt the application and recreated the jdbc connection pool and jdbc resource
to use mysql database. I added properties (missing in your domain.xml) :

<property name="PortNumber" value="3306" />
<property name="URL" value="jdbc:mysql://localhost:3306/mysql" />
All other properties mentioned in your domain.xml are used as is. The
application was deployed and while execution, i do not see any
StaleObjectStateException.

Attaching the server.log i got while the test executed for your reference. Looks
like some configuration issue at your end. I used the same build (V3.1 promoted
b07) to test this.

Comment by nztraveller [ 13/Jul/10 ]

Hi.
Thanks for testing with mysql as well. I just can not figure out why it works for you.
downloaded glassfish 3.1.b7, and the only configuration I did setup the jdbc connection and add the driver jar to the lib/
directory.

I have now tried the same glassfish version 3.1b7, with the same mysql version 5.0.75, and the same driver 5.1.7.

The error is slightly different, lock time out, but still clearly shows 2 connections being used.
Time Id Command Argument
100713 13:01:41 5 Connect root@192.168.1.201 on production
5 Query SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED
5 Query SET autocommit=0
5 Query insert into ADDRESS (...)
6 Connect root@192.168.1.201 on production
6 Query SET autocommit=1
6 Query SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED
6 Query update ADDRESS set ...
5 Query rollback
5 Query SET autocommit=1

I have also tried with Derby and got the same issue with the lock time out.
I have tested this on Mac OS X 10.6.4 and on Windows Vista 64-bit.
On the Mac java 'build 1.6.0_20-b02-279-10M3065' was used.
On Windows java version '1.6.0_20-b02' was used.

I did modify the test case to use an insert and then an updated to see if that made any different, but it didn't:
public void test()

{ System.out.println("This is a ejb test"); Address a = new Address(2); //(Address) HibernateUtil.getObject(Address.class,1); a.setAddress1("test1"); HibernateUtil.getSession().save(a); System.out.println("a = " + a); HibernateUtil.flushSession(); a.setAddress2("test2"); System.out.println("a = " + a); }

If possible can you please detail your environment and exactly how your application server was setup. Maybe provide the
domain.xml?
This issue is very repeatable here so there must be some subtle difference.

Cheers,
Jason

Comment by Shalini [ 13/Jul/10 ]

The hibernate version i use is 3.2.5. While creating the address table, i did
not mention "ENGINE=InnoDB DEFAULT CHARSET=utf8". The jdbc-connection-pool and
jdbc-resource configuration from domain.xml are as follows :

<jdbc-connection-pool pool-resize-quantity="1"
datasource-classname="com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource"
res-type="javax.sql.ConnectionPoolDataSource" steady-pool-size="1"
allow-non-component-callers="true" associate-with-thread="true"
statement-cache-size="200" name="mysql-pool"
transaction-isolation-level="read-committed" fail-all-connections="true">
<property name="databaseName" value="mysql" />
<property name="PortNumber" value="3306" />
<property name="password" value="mysql" />
<property name="serverName" value="localhost" />
<property name="user" value="root" />
<property name="URL" value="jdbc:mysql://localhost:3306/mysql" />
<property name="enableQueryTimeouts" value="false" />
<property name="useOldAliasMetadataBehavior" value="true" />
</jdbc-connection-pool>
<jdbc-resource pool-name="mysql-pool" jndi-name="jdbc/test" />

This jdbc resource is used in the application (provided by you). I just updated
this in the hibernate.cfg.xml, built the app, deployed it to the server. The
application's library has the following jars :
antlr-2.7.6.jar
asm.jar
cglib-2.1.3.jar
commons-collections-2.1.1.jar
commons-logging-1.1.jar
dom4j-1.6.1.jar
hibernate-annotations.jar
hibernate3.jar
ehcache-1.2.3.jar
jdbc2_0-stdext.jar
jta.jar
hibernate-tools.jar
hibernate-commons-annotations.jar
hibernate-entitymanager.jar
javassist.jar

could you try using hibernate 3.2.5 instead of 3.2.6?

Comment by nztraveller [ 14/Jul/10 ]

Hi.
I have tried with hibernate 3.2.5 with the same results.
The only libs I have are:
antlr.jar
asm.jar
cglib.jar
commons-collections.jar
commons-logging.jar
dom4j.jar
hibernate-annotations.jar
hibernate.jar

antlr, asm, commons, dom4j and hibernate are the same versions. I can't confirm the version of cglib
that is being used.
I aslo considered that there might be some interaction with an existing install. As well both of my
machines are dual/quad core cpu machines, so thought there might be a OS level threading issue.
To test these I have loaded a clean Windows XP vm and installed glassfish there. The database is the only
common component. Still had the same issue.
"org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or
unsaved-value mapping was incorrect): com.test.Address#2"

Is is possible for you to arrange to send me your ear? And I can send you mine?

Cheers,
Jason

Comment by Jagadish [ 05/Oct/10 ]

setting target milestone

Comment by Jagadish [ 28/Oct/10 ]

I tried the following setup and it works for me.

1) GlassFish 3.0.1 b-22 (fcs) and GlassFish 3.1 build 25 as well.
2) MySQL driver version mysql-connector-java-5.1.5-bin.jar
3) MySQL configuration
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
<jdbc-connection-pool
datasource-classname="com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource"
pool-resize-quantity="1" res-type="javax.sql.ConnectionPoolDataSource"
steady-pool-size="1" allow-non-component-callers="true"
statement-cache-size="200" associate-with-thread="true" name="mysql"
fail-all-connections="true" transaction-isolation-level="read-committed">
<property name="databaseName" value="mysql"/>
<property name="password" value="jagadish"/>
<property name="serverName" value="localhost"/>
<property name="user" value="jagadish"/>
<property name="enableQueryTimeouts" value="false"/>
<property name="useOldAliasMetadataBehavior" value="true"/>
</jdbc-connection-pool>
<jdbc-resource pool-name="mysql" jndi-name="jdbc/mysql"/>
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
4) Created MySQL table (not using "InnoDB" engine)
5) Hibernate : hibernate3.jar as well hibernate 3.2.5ga.jar
6) dual core machine

Comment by Jagadish [ 28/Oct/10 ]

Created an attachment (id=5265)
server.log and domain.xml from 3.0.1-b22 installation

Comment by nztraveller [ 28/Oct/10 ]

Hi.
The important detail is using the table type INNODB. It needs to be a transactional database.
I had several emails back and forth with sm157516 and he was able to reproduce the issue as well.
Believe me it is a bug. We have just completed our migration to glassfish, and end using v2, we would have
much rather been on v3. And now once this has been resolved I have the work of moving from v2 to v3.
I have attached the email trail.

Cheers,
Jason

Comment by nztraveller [ 28/Oct/10 ]

Created an attachment (id=5267)
emails with Shalini Muthukrishnan

Comment by Jagadish [ 03/Nov/10 ]

Thanks, InnoDB engine does the trick.
I am able to reproduce it intermittently.

  • Not sure why InnoDB alone is causing the issue and not the other engines
    (default one)
  • But, it seems to work fine in GlassFish 2.x and not in v3.x ?

I shall investigate further.

Comment by Jagadish [ 10/Nov/10 ]

Fix will be available from GF 3.1 promoted build 29 or 11th Nov 2010 nightly.

Comment by tosehee [ 18/Aug/11 ]

What was done to resolve this?

I am using latest 3.1.1 release, and I still have this exact issue..





[GLASSFISH-14110] [508] Cannot access "Glassfish Project Page" link using keyboard Created: 20/Oct/10  Updated: 05/Jul/11  Resolved: 05/Jul/11

Status: Closed
Project: glassfish
Component/s: installation
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: shaline Assignee: scatari
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 14,110
Tags: 3_1-508, 3_1-exclude

 Description   

Build used: GF V3.1 promoted b25:
OS: Windows 7, and Solaris Sparc 10.
While running the installer using keyboard ( latest-ogs-windows.exe, and
latest-ogs-unix.sh, In the "Introduction" Link, we cannot navigate to the link
"Glassfish Project Page" using any of the short keys like, TAB, Space, UP/DOWN
Arrow etc, and hence we cannot open the page https://glassfish.dev.java.net/
from the installer.



 Comments   
Comment by scatari [ 20/Oct/10 ]

What is 508 compliance policy for such links embedded in panel(s)? Do we have to support navigation to
them?

Comment by scatari [ 20/Oct/10 ]

BTW, this link doesn't work even if the user clicks on it due to OpenInstaller limitation. Please see 13845
for more info. If 13485 cannot be fixed intime(currently targeted for MS7), then this bug will also be
closed and the URL on this panel will be changed to a text from hyper link.

Comment by scatari [ 03/Nov/10 ]

Please see earlier evaluation comments.

Comment by scatari [ 16/Dec/10 ]

This does not impact the overall functionality in anyways. The installation guide has links to these pages and after the installation the relevant documentation is available to the users if needed.

BTW, the links are now click-able through mouse as issue 13485 has been fixed. Fixing this issue requires patching up OpenInstaller's code path shared by many panels in install sequence and is too risky to attempt at this stage of this release.

Comment by Nazrul [ 20/Dec/10 ]

Too risky to fix during 3.1. Excluding from count.

Comment by scatari [ 05/Jul/11 ]

The related issue has been fixed in 3.1.





[GLASSFISH-14623] Error renaming domain.xml to domain.xml.bak on (slow) Windows system Created: 11/Nov/10  Updated: 27/Jun/11  Resolved: 19/Nov/10

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: Tim Quinn Assignee: Tom Mueller
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows (generic)
Platform: All


Issuezilla Id: 14,623

 Description   

While running deployment devtests on a (slow) Windows system, I saw the error
below recur several times during a 35-minute test run.

I do not know if the slowness of the laptop I was using helps expose this
problem or not.

Even if this problem cannot be fixed, is there a way to display the temp file
which does contain the updated config in the error message so the user could
manually recover the config changes (if we even want to suggest that)?

#|2010-11-11T11:48:47.843-0600|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|Could
not rename
C:\tim\asgroup\v3\b28\publish\glassfish3\glassfish\domains\domain1\config\domain.xml
to
C:\tim\asgroup\v3\b28\publish\glassfish3\glassfish\domains\domain1\config\domain.xml.bak|#]

[#|2010-11-11T11:48:47.843-0600|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|IOException
while saving the configuration, changes not persisted
java.io.IOException: Could not rename
C:\tim\asgroup\v3\b28\publish\glassfish3\glassfish\domains\domain1\config\domain.xml
to
C:\tim\asgroup\v3\b28\publish\glassfish3\glassfish\domains\domain1\config\domain.xml.bak
at
com.sun.enterprise.v3.server.DomainXmlPersistence.save(DomainXmlPersistence.java:192)
at
org.glassfish.config.support.GlassFishDocument$1.transactionCommited(GlassFishDocument.java:90)
at
org.jvnet.hk2.config.Transactions$TransactionListenerJob.process(Transactions.java:341)
at
org.jvnet.hk2.config.Transactions$TransactionListenerJob.process(Transactions.java:332)
at
org.jvnet.hk2.config.Transactions$ListenerNotifier$1.call(Transactions.java:208)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at org.jvnet.hk2.config.Transactions$Notifier$1$1.run(Transactions.java:162)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

#]

[#|2010-11-11T11:48:47.843-0600|SEVERE|glassfish3.1|javax.enterprise.system.core.org.glassfish.config.support|_ThreadID=16;_ThreadName=Thread-1;|CONFIG0100:Exception
Could not rename
C:\tim\asgroup\v3\b28\publish\glassfish3\glassfish\domains\domain1\config\domain.xml
to
C:\tim\asgroup\v3\b28\publish\glassfish3\glassfish\domains\domain1\config\domain.xml.bak
while persisting domain.xml, changes will not be available on server restart|#]



 Comments   
Comment by Tom Mueller [ 12/Nov/10 ]

Please provide more details on how to reproduce this problem. What test was being
run? Did you have the domain.xml file open in an editor while running the test?
Was the test doing anything with the domain.xml file?

Even with a slow system, we should not be seeing this problem with the locking
that we have in place for reading and writing the domain.xml file.

Comment by Tim Quinn [ 12/Nov/10 ]

Perhaps not surprisingly I've found this to be an intermittent problem. In the
additional test I just ran I saw at least one error like this in each two or
three runs of a small test suite.

1. Make sure you have an up-to-date appserv-tests/devtests/deployment directory
tree.

2. cd appserv-tests/devtests/deployment/war/servletonly

3. asadmin start-domain

4. ant all

5. Look in the server.log file.

The results displayed at the client sometimes show all PASSes even if there was
a problem with backing up domain.xml internally in the DAS.

The tests do not manipulate domain.xml beyond what the DAS does internally as it
operates.

Of course the speed of the system should not affect this. I mentioned it
because the system I used for testing is probably quite a bit slower than most
and faster systems might not show the problem, esp. given that it's intermittent.

I did not have domain.xml open in an editor, but it's entirely possible that the
anti-virus software running on my system had it open.

I'm using my personal (old, slow) Windows laptop which runs, among other things,
an auto-protect virus scanner which (according to what I've read about it) will
check each file as it's read or written. So I disabled that feature temporarily
for a few test runs. I did not see this error while I had auto-protect off.

I turned auto-protect back on and saw the error on my second run of the
war/servletonly tests.

This is not conclusive, obviously, but it's a plausible explanation. If this is
what's happening, then I would guess it's less likely to happen with faster more
modern systems. This is partly why much of the deployment code uses
FileUtils.renameFile which retries on Windows if the operation fails. There's
not currently a corresponding method there for deleting with retry but it'd be
easy enough to add.

Comment by Tom Mueller [ 16/Nov/10 ]

Suggested fix: replace uses of File.renameTo in DomainXmlPersistence.java with
FileUtils.renameFile which includes the retry for windows.

Comment by Tom Mueller [ 19/Nov/10 ]

Fixed per the suggested fix in revision 42984.

Tim, can you try this again on your system. Since I can't reproduce this in my
environment, I can't say for sure that this actually fixed the problem.

Comment by allycavs [ 23/Jun/11 ]

Hey Guys

This is definetely an anti virus problem for me. If others have the same issue, look to switch off automated file protection on your anti virus. Look for an option that scans all files after a save and switch this option off. reboot aswell. My antivirus didnt tell me to reboot but the change only took effect after a reboot

Thanks
Alan





[GLASSFISH-12114] WebServiceContext not injected if Web Service is packed to a jar Created: 03/Jun/10  Updated: 15/Jun/11  Resolved: 15/Jun/11

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: v3.0.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Minor
Reporter: syvalta Assignee: Bhakti Mehta
Resolution: Fixed Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Linux


Attachments: Zip Archive gf-wscontext.zip    
Issuezilla Id: 12,114
Tags: 3_1_1-scrubbed

 Description   

Environment: "GlassFish Server Open Source Edition 3.0.1 (build 20)" with
"java-6-sun-1.6.0.20" under Debian.

Everything works fine when a web service is included in war in WEB-INF/classes.
When a web service is packed in a jar, and the jar is included in WEB-INF/lib,
the web service deploys fine, but its web service context is always null.

I will attach an example project with war and source code. Just deploy the war
and call the web services:
http://localhost:8080/war-1.0-SNAPSHOT/WebServiceInWar?Tester
http://localhost:8080/war-1.0-SNAPSHOT/WebServiceInJar?Tester

Calling the methods you can see that the first one has context correctly set,
but in the second one it is null.



 Comments   
Comment by syvalta [ 03/Jun/10 ]

Created an attachment (id=4400)
Test project demonstrating the bug

Comment by syvalta [ 04/Jun/10 ]
      • Issue 12114 has been confirmed by votes. ***
Comment by syvalta [ 24/May/11 ]

Would it be possible to get the Fix version be updated (3.1 was already released)?

Comment by Bhakti Mehta [ 24/May/11 ]

I dont know how this bug is not showing up in our queries. I will look at addressing this for 3.1.1 and get back to you soon

Comment by Bhakti Mehta [ 15/Jun/11 ]

I tried with latest 3.1.1 workspace and this is resolved now. You can see the WebserviceContext is not null for the jar case
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header/>
<S:Body>
<ns2:checkWsContext xmlns:ns2="http://test/"/>
</S:Body>
</S:Envelope>

<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:checkWsContextResponse xmlns:ns2="http://test/">
<return>JAR: wsContext: org.glassfish.webservices.WebServiceContextImpl@4baf19d7, JAR: servletContext: org.apache.catalina.core.ApplicationContextFacade@4af9999b</return>
</ns2:checkWsContextResponse>
</S:Body>
</S:Envelope>





[GLASSFISH-14353] Log viewer: change "Records Before 0" button Created: 02/Nov/10  Updated: 15/Jun/11  Resolved: 15/Jun/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: sirajg
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: JPEG File logviewer-search-results.JPG    
Issuezilla Id: 14,353
Tags: 3_1-next, 3_1_1-scrubbed

 Description   

build: glassfish-3.1-b27-10_31_2010.zip

When in Log Viewer for DAS, I'm searching for some entries and get 11 results.
I see "Records before 0" button and "Records after 11" button.

The first button should be renamed, either to "Previous" and disbled, or
equivalent of "Continue from the end of the file".

Regarding the second button, I think this button would only return more results
if server.log was updated in the meantime with entries that match the query. If
this is the case, this button would be better called "Update results". Ideally
there should always be "Previous" and "Next" buttons, plus optional "Update
results". Buttons called "Records after 11" are misleading - they indicate that
there are more records, where in fact there aren't.



 Comments   
Comment by sirajg [ 09/Nov/10 ]

Records before 0 is not displayed. Records after "x" is displayed because the
log viewer does not know if any more records are available at this time. If no
records are available, and you click "Records after 'x'", then a screen
displaying the information that no more records are available, is displayed.

Comment by lidiam [ 02/Mar/11 ]

Current implementation of displaying search results and "previous", "next" buttons is confusing. I searched for grizzly and see the following:

"Records before 8" button
"Records after 236" button
"Log File Record Numbers 8 through 236" text between the buttons.

At this point I think I have hundreds of results. I click on "Records before 8" button and get a page with "No items found" result and the following buttons:

"Previous"
"Next"

This is inconsistent with the previous button display. Also, this page already has no results, having "Previous" is confusing. I click on "Previous" and results are displayed - the initial results are displayed, so the "Previous" button wrapped the search. This is counter intuitive and there is no reason to wrap searches (specifically since we do not notify user that we do that).

Now I notice that the initial results page has the following text in the title of the table:

"Log Viewer Results (6)"

This is not something that user will see right away. It would be better to put the number of results in the text between the "previous" and "next" buttons. E.g. it could read: "Results: (6); Displaying records 8 through 236". I'll attach a screenshot.

Comment by sirajg [ 15/Jun/11 ]

When you search, filtered results are shown. Record numbers are not associated with the filtered result - those are actual log record numbers.

Wrapping to top of file is a feature that has been in the log viewer for several releases.





[GLASSFISH-13232] Deadlock observed in logging code Created: 02/Sep/10  Updated: 03/May/11  Resolved: 16/Nov/10

Status: Resolved
Project: glassfish
Component/s: logging
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: naman_mehta
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File i1-jstack.out     Text File server.log    
Issue Links:
Duplicate
duplicates GLASSFISH-13877 Deadlock in GF when log level is set ... Resolved
Issuezilla Id: 13,232

 Description   

This is not consistently reproducible, but I have noticed a deadlock preventing
the server to bring to stand still while trying trying to analyse some other
class loading issue (my bad luck). This deadlock happens if felix.log.level is
set to 4 in osgi/felix/config/config.properties file. I used jdk1.6_u21 on:
Linux crocker 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:01:29 UTC 2009 i686
GNU/Linux

Here is the jstack output:

Found one Java-level deadlock:
=============================
"http-thread-pool-10048(1)":
waiting to lock monitor 0x7e996998 (object 0xafd40010, a java.io.PrintStream),
which is held by "main"
"main":
waiting to lock monitor 0x7e9969fc (object 0xaffb0760, a
java.util.logging.ConsoleHandler),
which is held by "Thread-25"
"Thread-25":
waiting to lock monitor 0x7e996998 (object 0xafd40010, a java.io.PrintStream),
which is held by "main"

Java stack information for the threads listed above:
===================================================
"http-thread-pool-10048(1)":
at java.io.PrintStream.println(PrintStream.java:756)

  • waiting to lock <0xafd40010> (a java.io.PrintStream)
    at org.apache.felix.framework.Logger.doLog(Logger.java:115)
    at org.apache.felix.framework.Logger._log(Logger.java:156)
    at org.apache.felix.framework.Logger.log(Logger.java:89)
    at
    org.apache.felix.framework.ModuleImpl.getResourceByDelegation(ModuleImpl.java:649)
    at
    org.apache.felix.framework.ModuleImpl$ModuleClassLoader.getResource(ModuleImpl.java:1937)
    at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1193)
    at java.util.ResourceBundle$Control$1.run(ResourceBundle.java:2324)
    at java.util.ResourceBundle$Control$1.run(ResourceBundle.java:2309)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2308)
    at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1364)
    at java.util.ResourceBundle.findBundle(ResourceBundle.java:1328)
    at java.util.ResourceBundle.findBundle(ResourceBundle.java:1282)
    at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1224)
    at java.util.ResourceBundle.getBundle(ResourceBundle.java:777)
    at com.sun.grizzly.util.res.StringManager.<init>(StringManager.java:97)
    at com.sun.grizzly.util.res.StringManager.<init>(StringManager.java:91)
    at com.sun.grizzly.util.res.StringManager.getManager(StringManager.java:270)
  • locked <0x80f63310> (a java.lang.Class for
    com.sun.grizzly.util.res.StringManager)
    at com.sun.grizzly.util.buf.HexUtils.<clinit>(HexUtils.java:112)
    at com.sun.grizzly.http.ProcessorTask.parseHost(ProcessorTask.java:1540)
    at com.sun.grizzly.http.ProcessorTask.prepareRequest(ProcessorTask.java:1468)
    at com.sun.grizzly.http.ProcessorTask.parseRequest(ProcessorTask.java:924)
    at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:687)
    at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1014)
    at
    com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:220)
    at
    com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
    at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
    at
    com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
    at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
    at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
    at
    com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:530)
    at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511)
    at java.lang.Thread.run(Thread.java:619)
    "main":
    at java.util.logging.StreamHandler.publish(StreamHandler.java:174)
  • waiting to lock <0xaffb0760> (a java.util.logging.ConsoleHandler)
    at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:88)
    at java.util.logging.Logger.log(Logger.java:458)
    at java.util.logging.Logger.doLog(Logger.java:480)
    at java.util.logging.Logger.logp(Logger.java:596)
    at
    com.sun.common.util.logging.LoggingOutputStream.flush(LoggingOutputStream.java:91)
    at java.io.PrintStream.write(PrintStream.java:432)
  • locked <0xafd40010> (a java.io.PrintStream)
    at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
    at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:272)
    at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:85)
  • locked <0xafd40150> (a java.io.OutputStreamWriter)
    at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:168)
    at java.io.PrintStream.write(PrintStream.java:477)
  • locked <0xafd40010> (a java.io.PrintStream)
    at java.io.PrintStream.print(PrintStream.java:619)
    at java.io.PrintStream.println(PrintStream.java:756)
  • locked <0xafd40010> (a java.io.PrintStream)
    at org.apache.felix.framework.Logger.doLog(Logger.java:115)
    at org.apache.felix.framework.Logger._log(Logger.java:156)
    at org.apache.felix.framework.Logger.log(Logger.java:89)
    at
    org.apache.felix.framework.Felix$FelixResolver.markResolvedModules(Felix.java:4187)
    at org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:4009)
    at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3414)
    at org.apache.felix.framework.Felix.startBundle(Felix.java:1754)
    at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)
    at
    com.sun.enterprise.glassfish.bootstrap.GlassFishActivator.startBundle(GlassFishActivator.java:220)
    at
    com.sun.enterprise.glassfish.bootstrap.GlassFishActivator.startPostStartupBundles(GlassFishActivator.java:196)
    at
    com.sun.enterprise.glassfish.bootstrap.GlassFishActivator.access$200(GlassFishActivator.java:63)
    at
    com.sun.enterprise.glassfish.bootstrap.GlassFishActivator$1$1.start(GlassFishActivator.java:97)
  • locked <0xafc18770> (a
    com.sun.enterprise.glassfish.bootstrap.GlassFishActivator$1$1)
    at
    com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at
    sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:98)
    at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:61)
    "Thread-25":
    at java.io.PrintStream.println(PrintStream.java:756)
  • waiting to lock <0xafd40010> (a java.io.PrintStream)
    at org.apache.felix.framework.Logger.doLog(Logger.java:115)
    at org.apache.felix.framework.Logger._log(Logger.java:156)
    at org.apache.felix.framework.Logger.log(Logger.java:89)
    at
    org.apache.felix.framework.ModuleImpl.getResourceByDelegation(ModuleImpl.java:649)
    at
    org.apache.felix.framework.ModuleImpl$ModuleClassLoader.getResource(ModuleImpl.java:1937)
    at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1193)
    at java.util.ResourceBundle$Control$1.run(ResourceBundle.java:2324)
    at java.util.ResourceBundle$Control$1.run(ResourceBundle.java:2309)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2308)
    at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1364)
    at java.util.ResourceBundle.findBundle(ResourceBundle.java:1328)
    at java.util.ResourceBundle.findBundle(ResourceBundle.java:1282)
    at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1224)
    at java.util.ResourceBundle.getBundle(ResourceBundle.java:952)
    at com.sun.logging.LogDomains$1.getResourceBundle(LogDomains.java:357)
    at
    com.sun.enterprise.server.logging.UniformLogFormatter.getResourceBundle(UniformLogFormatter.java:334)
  • locked <0xaffb06d0> (a com.sun.enterprise.server.logging.UniformLogFormatter)
    at
    com.sun.enterprise.server.logging.UniformLogFormatter.uniformLogFormat(UniformLogFormatter.java:290)
    at
    com.sun.enterprise.server.logging.UniformLogFormatter.format(UniformLogFormatter.java:157)
    at java.util.logging.StreamHandler.publish(StreamHandler.java:179)
  • locked <0xaffb0760> (a java.util.logging.ConsoleHandler)
    at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:88)
    at java.util.logging.Logger.log(Logger.java:458)
    at com.sun.logging.LogDomains$1.log(LogDomains.java:338)
    at java.util.logging.Logger.doLog(Logger.java:480)
    at java.util.logging.Logger.log(Logger.java:503)
    at java.util.logging.Logger.info(Logger.java:1022)
    at
    org.glassfish.admin.mbeanserver.RMIConnectorStarter.startRegistry(RMIConnectorStarter.java:227)
    at
    org.glassfish.admin.mbeanserver.RMIConnectorStarter.<init>(RMIConnectorStarter.java:101)
    at
    org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.startConnector(JMXStartupService.java:240)
    at
    org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.run(JMXStartupService.java:291)

Found 1 deadlock.

The server output is attached here with.



 Comments   
Comment by Sanjeeb Sahoo [ 02/Sep/10 ]

Created an attachment (id=4787)
Server log

Comment by sonymanuel [ 02/Sep/10 ]

Created an attachment (id=4788)
Another stack trace showing lots of blocked threads.

Comment by naman_mehta [ 06/Oct/10 ]

Need to check with Sahoo on the same to reproduce. Will fix in ms7. Lowering
priority to P3.

Comment by naman_mehta [ 16/Nov/10 ]

Planning to fix the same and discussing with Jerome on the same.

      • This issue has been marked as a duplicate of 13877 ***
Comment by Sanjeeb Sahoo [ 03/May/11 ]

Looks like the duplicate field was not set properly by the issue tracker to JIRA migration code.





[GLASSFISH-14260] Properties: confusing naming Created: 27/Oct/10  Updated: 20/Apr/11  Resolved: 20/Apr/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Minor
Reporter: lidiam Assignee: Jason Lee
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: JPEG File properties-clustered-instance.JPG     JPEG File properties-standalone-instance.JPG    
Issue Links:
Dependency
blocks GLASSFISH-14655 document --kill option for stop-insta... Resolved
Issuezilla Id: 14,260

 Description   

build: glassfish-3.1-b26-10_26_2010.zip

Currently there are the following pages for properties in Admin Console:

  • server
    -> System Properties tab
  • a cluster
    -> Properties tab containing:
    -> System Properties (also called Cluster System Properties) and Cluster
    Properties tabs
  • a clustered instance
    -> Properties tab containing:
    -> Configuration Properties (also named Configuration System Properties)
    and Instance Properties
  • a standalone instance
    -> Properties tab containing:
    -> Configuration Properties (also named Configuration System Properties)
    and Instance Properties
  • a cluster-config
    -> System Properties page (also called Configuration System Properties)
  • other configs as the one above...

There seems to be an inconsistency in naming, where specific System Properties
are called Configuration System Properties. At the cluster or instance level
this is confusing, implying that if a property is specified here it may show
under a specific config, which is not the case. It would be better to call them
as follows:

  • a clustered instance
    -> Properties tab containing:
    -> System Properties (also named Instance System Properties) and Instance
    Properties
  • a standalone instance
    -> Properties tab containing:
    -> System Properties (also named Instance System Properties) and Instance
    Properties


 Comments   
Comment by Jason Lee [ 11/Nov/10 ]

Fix committed.

Comment by Jason Lee [ 11/Nov/10 ]

.

Comment by lidiam [ 28/Feb/11 ]

There is still inconsistency in properties naming between Clustered and Standalone Instance - one is called Instance System Properties the other System Properties. I'll attach screenshots to illustrate.

Comment by Jason Lee [ 02/Mar/11 ]

I don't think this is an issue. the "Instance System Properties" indicates that the properties are on the clustered instance, and not the cluster. For standalone instances, no such distinction is necessary.





[GLASSFISH-13690] [UB] can't configure static JMS ports via GlassFish Created: 29/Sep/10  Updated: 06/Apr/11  Resolved: 06/Apr/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: Mike Fitch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: PDF File AdminGde-Ch17-JMS-draft5-cropped.pdf    
Issuezilla Id: 13,690

 Description   

I haven't been able to find a way to configure embedded or local JMS broker to use
static ports via the GlassFish configuration in domain.xml. It is possible to
setup a stand-alone JMS broker via the MQ commands to do this, but the properties
that one needs to set to do this don't seem to be available via domain.xml.



 Comments   
Comment by Satish Kumar [ 05/Oct/10 ]

In the case of managed brokers -EMBEDDED or LOCAL mode of integration, the MQ
port-mapper port is configured through the JMS_PROVIDER_PORT. Other ports can
be configured by setting them into jms-host.properties (the property name
should be the same as the one used by IMQ).

So it appears that we are covered. Pl let me know if I am missing something
here. What is not very clear through the bug description is what ports are
being referred to here?

Comment by Tom Mueller [ 05/Oct/10 ]

Where does the jms-host.properties file go? In the domains/<domain>/config directory? The jms-
host.properties file is not listed in the default config-files file, so it will not be synchronized to
instances. Or is this a file that needs to go into the instance specific config directory?

Where in the GlassFish documentation is the jms-host.properties file mentioned? I searched for it and didn't
find it mentioned anywhere.

The ports being referred to here are those that you see displayed if you telnet to the JMS_PROVIDER_PORT of
an instance, e.g.,

101 i1i1 4.5
cluster_discovery tcp CLUSTER_DISCOVERY 0
portmapper tcp PORTMAPPER 27676
[imqvarhome=/fishpool/home/trm/test/glassfishv3/glassfish/nodes/localhost/i1/imq,imqhome=/fishpool/home/trm/t
est/glassfishv3/mq,sessionid=2661675193862365184]
jmxrmi rmi JMX 0 [url=service:jmx:rmi://glassfish-sparc-1/jndi/rmi://glassfish-sparc-1:27776/glassfish-sparc-
1/27676/jmxrmi]
admin tcp ADMIN 64053
jms tcp NORMAL 64052
cluster tcp CLUSTER 64054

Here, the dynamic ports are: 64053, 64052, 64054

Maybe this needs to be converted to a doc bug.

Comment by Satish Kumar [ 06/Oct/10 ]

Setting target milestone...

by jmshost.properties I was not referring to a file but the jmshost element in
domain.xml and the properties bucket under it through which these ports can be
configured.

I agree this needs to be assigned to the docs team so that they can include
some documentation around this

Comment by Satish Kumar [ 30/Nov/10 ]

Static ports can be configured by either setting them as part of the properties bucket in jms-service or the properties bucket for jms-host. For instance, the admin tcp port can be changed by running the following command:

./asadmin set server-config.jms-service.property.imq\\.admin\\.tcp
.port=12345

Telnet after running the command (Note: a restart is required for the changes to take effect)
satish@calvin:~/sats/glassfish3/glassfish/bin$ telnet localhost 7676
Trying ::1...
Connected to localhost.
Escape character is '^]'.
101 imqbroker 4.5
cluster_discovery tcp CLUSTER_DISCOVERY 0
portmapper tcp PORTMAPPER 7676 [imqvarhome=/space/satish/sats/glassfish3/glassfish/domains/domain1/imq,imqhome=/space/satish/sats/glassfish3/mq,sessionid=5793367024399554304]
jmxrmi rmi JMX 0 [url=service:jmx:rmi://calvin/jndi/rmi://calvin:8686/calvin/7676/jmxrmi]
admin tcp ADMIN 12345
jms tcp NORMAL 56522
mqdirect2 none NORMAL 0
jmsdirect none NORMAL 0
cluster tcp CLUSTER 50726

The property names for configuring static ports in MQ are in the MQ admin guide.

Changing this to a docs issue since this needs to be a part of the GF admin guide.

Comment by Mike Fitch [ 14/Dec/10 ]

Added [UB], unbundled doc, indicator

Comment by Mike Fitch [ 06/Apr/11 ]

Instructions for setting broker properties have been added to the GlassFish Server Admin Guide. In the attached pdf, see:

  • "Setting Message Queue Broker Properties in the JMS Service Configuration" on page 337 to see how at the jms-service level
  • "To Create a JMS Host" on pages 339-340 to see how when creating a JMS host
  • "To Update a JMS Host" on page 341 to see how when updating a JMS host




[GLASSFISH-13723] list --monitor "*" == no output Created: 30/Sep/10  Updated: 04/Apr/11  Resolved: 10/Nov/10

Status: Resolved
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

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

Operating System: All
Platform: Sun


Issuezilla Id: 13,723
Tags: added-devtest

 Description   

b22

even after setting the module-monitoring-levels to HIGH for many of the possible
levels.

here is the output

bash-3.2$ GlassFish_Server_3.1/bin/asadmin list --monitor=true "*"
Command list executed successfully.



 Comments   
Comment by vince kraemer [ 30/Sep/10 ]

asadmin list --monitor=true "server.*" appears to give the correct output

Comment by Byron Nevins [ 10/Nov/10 ]

All fixed now





[GLASSFISH-13905] "Enabling the monitoring..." msg logged 16 times in a row Created: 09/Oct/10  Updated: 04/Apr/11  Resolved: 09/Nov/10

Status: Resolved
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: Dies Koper Assignee: Jennifer Chou
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 13,905
Tags: added-devtest

 Description   

When I change the monitoring level to LOW for all components in the GUI, the
following useless messages are logged in server log:

[#|2010-10-10T14:01:51.687+1100|INFO|glassfish3.1|javax.enterprise.system.tools.monitor.org.glassfish.admin.monitor|_ThreadID=15;_ThreadName=Thread-1;|MNTG0107:Enabling
the monitoring for all the stats with level = LOW|#]

[#|2010-10-10T14:01:51.718+1100|INFO|glassfish3.1|javax.enterprise.system.tools.monitor.org.glassfish.admin.monitor|_ThreadID=15;_ThreadName=Thread-1;|MNTG0107:Enabling
the monitoring for all the stats with level = LOW|#]

[#|2010-10-10T14:01:51.734+1100|INFO|glassfish3.1|javax.enterprise.system.tools.monitor.org.glassfish.admin.monitor|_ThreadID=15;_ThreadName=Thread-1;|MNTG0107:Enabling
the monitoring for all the stats with level = LOW|#]

[#|2010-10-10T14:01:51.765+1100|INFO|glassfish3.1|javax.enterprise.system.tools.monitor.org.glassfish.admin.monitor|_ThreadID=15;_ThreadName=Thread-1;|MNTG0107:Enabling
the monitoring for all the stats with level = LOW|#]

[#|2010-10-10T14:01:51.781+1100|INFO|glassfish3.1|javax.enterprise.system.tools.monitor.org.glassfish.admin.monitor|_ThreadID=15;_ThreadName=Thread-1;|MNTG0107:Enabling
the monitoring for all the stats with level = LOW|#]

[#|2010-10-10T14:01:51.812+1100|INFO|glassfish3.1|javax.enterprise.system.tools.monitor.org.glassfish.admin.monitor|_ThreadID=15;_ThreadName=Thread-1;|MNTG0107:Enabling
the monitoring for all the stats with level = LOW|#]

[#|2010-10-10T14:01:51.828+1100|INFO|glassfish3.1|javax.enterprise.system.tools.monitor.org.glassfish.admin.monitor|_ThreadID=15;_ThreadName=Thread-1;|MNTG0107:Enabling
the monitoring for all the stats with level = LOW|#]

[#|2010-10-10T14:01:51.843+1100|INFO|glassfish3.1|javax.enterprise.system.tools.monitor.org.glassfish.admin.monitor|_ThreadID=15;_ThreadName=Thread-1;|MNTG0107:Enabling
the monitoring for all the stats with level = LOW|#]

[#|2010-10-10T14:01:51.859+1100|INFO|glassfish3.1|javax.enterprise.system.tools.monitor.org.glassfish.admin.monitor|_ThreadID=15;_ThreadName=Thread-1;|MNTG0107:Enabling
the monitoring for all the stats with level = LOW|#]

[#|2010-10-10T14:01:51.875+1100|INFO|glassfish3.1|javax.enterprise.system.tools.monitor.org.glassfish.admin.monitor|_ThreadID=15;_ThreadName=Thread-1;|MNTG0107:Enabling
the monitoring for all the stats with level = LOW|#]

[#|2010-10-10T14:01:51.890+1100|INFO|glassfish3.1|javax.enterprise.system.tools.monitor.org.glassfish.admin.monitor|_ThreadID=15;_ThreadName=Thread-1;|MNTG0107:Enabling
the monitoring for all the stats with level = LOW|#]

[#|2010-10-10T14:01:51.906+1100|INFO|glassfish3.1|javax.enterprise.system.tools.monitor.org.glassfish.admin.monitor|_ThreadID=15;_ThreadName=Thread-1;|MNTG0107:Enabling
the monitoring for all the stats with level = LOW|#]

[#|2010-10-10T14:01:51.937+1100|INFO|glassfish3.1|javax.enterprise.system.tools.monitor.org.glassfish.admin.monitor|_ThreadID=15;_ThreadName=Thread-1;|MNTG0107:Enabling
the monitoring for all the stats with level = LOW|#]

[#|2010-10-10T14:01:51.953+1100|INFO|glassfish3.1|javax.enterprise.system.tools.monitor.org.glassfish.admin.monitor|_ThreadID=15;_ThreadName=Thread-1;|MNTG0107:Enabling
the monitoring for all the stats with level = LOW|#]

[#|2010-10-10T14:01:51.968+1100|INFO|glassfish3.1|javax.enterprise.system.tools.monitor.org.glassfish.admin.monitor|_ThreadID=15;_ThreadName=Thread-1;|MNTG0107:Enabling
the monitoring for all the stats with level = LOW|#]

[#|2010-10-10T14:01:52.000+1100|INFO|glassfish3.1|javax.enterprise.system.tools.monitor.org.glassfish.admin.monitor|_ThreadID=15;_ThreadName=Thread-1;|MNTG0107:Enabling
the monitoring for all the stats with level = LOW|#]

I think it should not be logged at all, or include the name of the component I
have just changed the monitoring level for.



 Comments   
Comment by Nazrul [ 28/Oct/10 ]

Getting help from Jennifer

Comment by Jennifer Chou [ 09/Nov/10 ]

Change to FINE and add the component information.

Comment by Jennifer Chou [ 09/Nov/10 ]

fixed





[GLASSFISH-14461] Extra "server." in monitoring output of instances Created: 07/Nov/10  Updated: 04/Apr/11  Resolved: 19/Dec/10

Status: Resolved
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

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

Operating System: All
Platform: All


Attachments: Java Archive File 14461_source_and_diffs.jar     Text File diffs.txt    
Issue Links:
Dependency
blocks GLASSFISH-14389 [BLOCKING] asadmin -m * and asadmin -... Reopened
Issuezilla Id: 14,461
Tags: 3_1-approved, added-devtest

 Description   

V2 output has i1.xyz
while V3 has i1.server.xyz as the output

Why?

I think Vijay designed this. Vijay please comment. Is it a bug or a feature?

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



 Comments   
Comment by vijaysr [ 08/Nov/10 ]

I think this is how it was in 3.0 also - I just added remote capability to the 3.0 behavior. You will have to
check with whosoever did this command for 3.0

Comment by Byron Nevins [ 12/Nov/10 ]

Is this a problem?

Homer???

Make it ms7 for now

Comment by Nazrul [ 18/Nov/10 ]

This needs to be fixed. We do not want "asadmin get" and "asadmin get -m" to
behave differently.

Comment by Byron Nevins [ 18/Nov/10 ]

get and get -m are completely different.

Here's output from "get"

servers.server.server.application-ref.__admingui.disable-timeout-in-minutes=30
servers.server.server.application-ref.__admingui.enabled=true
servers.server.server.application-ref.__admingui.lb-enabled=true
servers.server.server.application-ref._admingui.ref=_admingui
servers.server.server.application-ref._admingui.virtual-servers=_asadmin

============
Note the extra "server"

What to do is unclear. Please elaborate on what to do...

Comment by Nazrul [ 18/Nov/10 ]

Summary of what Byron and I looked at:

We have a remote instance called "i1". We then compared output for the following
two commands:

%asadmin get "i1.*"
%asadmin get -m "i1.*"

get -m has extra "server" after i1 (ex. i1.server...).

We should have consistent output from get and get -m commands.

Comment by Byron Nevins [ 05/Dec/10 ]

C:\gf\v3\core\kernel>svn commit
Sending kernel\src\main\java\com\sun\enterprise\v3\admin\MonitoringReporter.java
Transmitting file data .
Committed revision 43477.

HACK – remove the server later after it is added. Te code is too fragile and risky to change adding it in the first place

Comment by Nazrul [ 15/Dec/10 ]

dotted-name value still has the extra "server". So, re-opening the issue.

i1.applications.webapp2.webapp2webmod1\.war.server.dotted-name =
i1.server.applications.webapp2.webapp2webmod1\.war.server

Comment by Byron Nevins [ 17/Dec/10 ]

How bad is its impact? (Severity)
Not bad. It shows a vestigal ".server" in some monitoring values .

How often does it happen?
Every time if the value contains an extra ".server"

Will many users see this problem? (Frequency)
If they run lots of monitoring commands they will see it.

How much effort is required to fix it? (Cost)
1 full man-day

What is the risk of fixing it and how will the risk be mitigated? (Risk)
The risk is that we are not showing the actual value – we are showing the actual value with <instance-name>.server stripped out.
Now I am assuming, and Nazrul has confirmed, that the user is merely eyeballing these values. In that case there is no risk at all.

=======
Note the extra complication:

When I stripped keys I only had to worry about the CURRENTLY running instance name .server

Now I have to get a list of all servers and search for any of them followed by ".server". Zero risk, just more complicated and time-consuming.

e.g. I have to strip out BOTH of these – no matter what instance I'm running in.

foo=i1.server.x.y.z
goo=i2.server.x.y.z

But I must not touch this one:

hoo=user-supplied.value.here.serverXXXX

Comment by Nazrul [ 17/Dec/10 ]

Approved for checkin

Comment by Byron Nevins [ 18/Dec/10 ]

Finally! I discovered where that &$$% "server" string was coming from – gmbal. No wonder I couldn't find it in the glassfish codebase.

It is too risky to change gmbal right now so I've changed GF code instead. Gmbal has "server" hard-wired into enums – so it is impossible to set it to anything else.

==========

I'm attaching the diffs to the bug. This is a much more satisfying and proper solution. We no longer filter it out after the fact but never add the "server." in the first place.

I'll resolve this bug after review – I've submitted to Nazrul and Tom.

Comment by Byron Nevins [ 18/Dec/10 ]

The diffs

Comment by Byron Nevins [ 18/Dec/10 ]

Changed Source Files

Comment by Byron Nevins [ 18/Dec/10 ]

Diffs & source changed slightly. If you gave the pattern as "i1." it would turn that into "i1.i1."

-
-

  • // Weird – but this is how it works internally!
  • if (!isDas())
  • localPattern = serverEnv.getInstanceName() + "." + localPattern;
    -

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

I.e. 'localPattern' is already perfect. This old code just fouls it up. Now it is gone.

Comment by Byron Nevins [ 18/Dec/10 ]

Updated

Comment by Byron Nevins [ 19/Dec/10 ]

D:\gf\v3>svn commit -F commit.txt admin\monitor\src\main\java\org\glassfish\admin\monitor\StatsProviderManagerDelegateImpl.java admin\monitor\src\main
\java\org\glassfish\flashlight\datatree\impl\AbstractTreeNode.java admin\rest\src\main\java\org\glassfish\admin\rest\resources\MonitoringResource.java
admin\server-mgmt\src\main\java\com\sun\enterprise\admin\servermgmt\services\ServiceAdapter.java core\kernel\src\main\java\com\sun\enterprise\v3\admi
n\MonitoringReporter.java
Sending admin\monitor\src\main\java\org\glassfish\admin\monitor\StatsProviderManagerDelegateImpl.java
Sending admin\monitor\src\main\java\org\glassfish\flashlight\datatree\impl\AbstractTreeNode.java
Sending admin\rest\src\main\java\org\glassfish\admin\rest\resources\MonitoringResource.java
Sending admin\server-mgmt\src\main\java\com\sun\enterprise\admin\servermgmt\services\ServiceAdapter.java
Sending core\kernel\src\main\java\com\sun\enterprise\v3\admin\MonitoringReporter.java
Transmitting file data .....
Committed revision 43967.





[GLASSFISH-14758] Node: add inline information for keyfile authentication Created: 17/Nov/10  Updated: 02/Mar/11  Resolved: 13/Dec/10

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: Paul Davies
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 14,758
Tags: 3_1-verified

 Description   

build: ogs-3.1-b30-11_17_2010.zip

We need to add the following information to the Node creation screen (New Node),
when user chooses SSH type node:

1. Perhaps right under SSH section, we should mention that a private key file
should already exist on the DAS machine, and if not asadmin setup-ssh needs to
be executed before ssh node creation can be successfull.

2. Under KeyFile element we should mention that the file is expected on the DAS
host (I know this may be obvious, but for those unfamiliar with ssh and the
whole process, may be really usefull) plus we should mention what files we
search for (and where) by default: <user's home directory>/.ssh/id_rsa, etc.
Joe can add the details here.



 Comments   
Comment by lidiam [ 17/Nov/10 ]

One more request: please clarify usage of "host" in help on this page. We need
to specify if it's DAS host or Node host.

Comment by Paul Davies [ 18/Nov/10 ]

MS 8.

Comment by Paul Davies [ 10/Dec/10 ]

1. Not necessary, now that the fields for specifying how the SSH user is authenticated have been added.

2. The file need not reside on the DAS host. The path to the key file must be reachable by the DAS and the key file must be readable by the DAS. This requirement is stated in the OLH.

In the help text, the term host is usually qualified with the phrase "this node's", meaning the host that node will represent.

Comment by Paul Davies [ 13/Dec/10 ]

Fix integrated in revision 43779.

Comment by lidiam [ 02/Mar/11 ]

Verified in promoted build b43.





[GLASSFISH-14738] Standalone instance: clicking on name produces severe message in server.log Created: 16/Nov/10  Updated: 02/Mar/11  Resolved: 17/Nov/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

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

Operating System: All
Platform: All


Issuezilla Id: 14,738
Tags: 3_1-verified

 Description   

build: ogs-3.1-b30-11_16_2010.zip

Create a standalone instance and start it. Click on Standalone Instances node
and then instance name. As the page is being displayed, you will notice the
following two messages written to server.log:

[#|2010-11-16T19:08:19.212-0800|SEVERE|oracle-glassfish3.1|org.glassfish.admingui|_ThreadID=19;_ThreadName=Thread-1;|RestResponse.getResponse()
failed. endpoint =
'http://localhost:4848/management/domain/management/domain/get-runtime-info';
attrs = '

{target=sin1}'; RestResponse: "|#]

[#|2010-11-16T19:08:19.213-0800|SEVERE|oracle-glassfish3.1|org.glassfish.admingui|_ThreadID=19;_ThreadName=Thread-1;|RestResponse.getResponse()
failed. endpoint =
'http://localhost:4848/management/domain/management/domain/get-runtime-info';
attrs = '{target=sin1}

'; RestResponse: "|#]

They are printed every time I click on the instance name in the instances table.
However the instance is reported as running just fine.



 Comments   
Comment by lidiam [ 16/Nov/10 ]

At some point Admin Console "froze" - the processing image was displayed and the
GUI was greyed out and wasn't coming back. It happened after I clicked
Applications tab for a standalone instance, but it is not easily reproducible.
Perhaps some timing issue...? Will keep an eye for it.

Comment by Anissa Lam [ 17/Nov/10 ]

endpoing has additional "management/domain" in it.
fixed on 11/18 nightly.

Comment by lidiam [ 02/Mar/11 ]

Verified in promoted build b43.





[GLASSFISH-14737] Node port number: indicate required fields for ssh node creation Created: 16/Nov/10  Updated: 02/Mar/11  Resolved: 18/Nov/10

Status: Closed
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: Joe Di Pol
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 14,737
Tags: 3_1-verified

 Description   

build: ogs-3.1-b30-11_16_2010.zip

Tried to create an SSH node. Since the only required fields seem to be node
name and node host, erased all other entries. Got the following error after
hitting OK to save:

An error has occurred
Warning: some parameters appear to be invalid. SSH node not created. To force
creation of the node with these parameters rerun the command using the --force
option. Invalid port number .

Thus it seems that at least port number is a required field and should be marked
in GUI as such.



 Comments   
Comment by lidiam [ 16/Nov/10 ]

Btw, the way the error message is displayed, it is easy to miss the actual
reason for failure. Could it be printed on a separate line?

Also, GUI should check that the value in this field is a positive integer before
sending it off to backend.

Comment by Anissa Lam [ 16/Nov/10 ]

The sshport is an optional parameter, thats the case for CLI as well.

Usage: asadmin [asadmin-utility-options] create-node-ssh --nodehost <nodehost>
[--installdir <installdir(default:$

{com.sun.aas.productRoot}

)>]
[--nodedir <nodedir>] [--sshport <sshport(default:22)>]
[--sshuser <sshuser(default:$

{user.name}

)>] [--sshkeyfile <sshkeyfile>]
[-force[=<force(default:false)>]] [?|--help[=<help(default:false)>]]
name

I think the admin code should use the default when it is not specified.
transferring to Joe.

admin code should validate the port # as well if it is illegal char. Yes, GUI can check that on client
side, but admin should do that as well, and user will see the error either way.

Comment by Joe Di Pol [ 18/Nov/10 ]

I'm guessing this is a case where the GUI is sending a blank or null string for
the port number when the field is erased. I can change create-node-ssh so that
it detects this and uses the default.

Comment by Joe Di Pol [ 18/Nov/10 ]

The port number, user name, and installation directory should now default
correctly if the fields are cleared in the console.

Author: jfdipol
Date: 2010-11-18 23:59:42+0000
New Revision: 42954

Modified:

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/CreateNodeSshCommand.java

Log:
14737 Node port number: indicate required fields for ssh node creation
create-node-ssh now detects when an empty string is passed as a
parameter and uses the default value in that case.

Comment by lidiam [ 02/Mar/11 ]

Verified in promoted build b43.





[GLASSFISH-14724] Deploy: add information about undeploy button on instance page Created: 16/Nov/10  Updated: 02/Mar/11  Resolved: 14/Dec/10

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: Mike Fitch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 14,724
Tags: 3_1-verified

 Description   

We currently have (b30) 2 buttons on Applications tab for a standalone instance:
Deploy and Remove. There will be another button added: Undeploy, so some
information should be added about it. The same should apply to Applications tab
for clusters.

See related issue https://glassfish.dev.java.net/issues/show_bug.cgi?id=14696.



 Comments   
Comment by Mike Fitch [ 14/Dec/10 ]

Information about Undeploy button added to help pages for "Applications", "<cluster>:Applications" and "<standalone-instance>:Applications".

Available in v3 build 33 (MS7).

Comment by lidiam [ 02/Mar/11 ]

Verified in promoted build b43.





[GLASSFISH-14703] [Blocking] WebServices: cannot access end points when deployed to instance Created: 15/Nov/10  Updated: 02/Mar/11  Resolved: 16/Nov/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: Anissa Lam
Resolution: Fixed 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-14337 [BLOCKING] __list-webservices should ... Resolved
Issuezilla Id: 14,703
Tags: 3_1-verified

 Description   

build: ogs-3.1-b30-11_15_2010.zip

Deploy a webservices application to a standalone instance only. Click on the
instance name, Applications tab and then application name. The link to view
endpoint is not present, hence cannot test viewing webservices related
information when application is deployed to a standalone instance or a cluster only.



 Comments   
Comment by Anissa Lam [ 16/Nov/10 ]

Jitu has fixed the backend bug that we depend on, #14337.
No changes is needed in GUI. I have just looked and everything is working now.
closing this bug.

Please verify using 11/17 nightly or later build.

Comment by lidiam [ 02/Mar/11 ]

Verified in promoted build b43.





[GLASSFISH-14445] Deployment: error adding description Created: 05/Nov/10  Updated: 02/Mar/11  Resolved: 05/Nov/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

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

Operating System: All
Platform: All


Attachments: JPEG File osgi-errorondescription.JPG    
Issuezilla Id: 14,445
Tags: 3_1-verified

 Description   

build: ogs-3.1-b28-11_05_2010.zip

Deployed an osgi module and went to its general page. Tried to add a
description but got the following error on save:

An error has occurred
org.jvnet.hk2.config.ValidationException: Validation Failed: is not of data
type: java.lang.Boolean

I see the following in server.log:

[#|2010-11-05T16:31:07.253-0700|SEVERE|oracle-glassfish3.1|org.glassfish.admingui|_ThreadID=19;_ThreadName=Thread-1;|RestResponse.getResponse()
failed. endpoint =
'http://localhost:4848/management/domain/applications/application/org.apache.felix.eventadmin-1.2.2';
attrs = '{libraries=null, availabilityEnabled=null, enabled=true,
contextRoot=null,
location=$

{com.sun.aas.instanceRootURI}

/applications/org.apache.felix.eventadmin-1.2.2/,
description=no idea, name=org.apache.felix.eventadmin-1.2.2,
asyncReplication=true, objectType=user, directoryDeployed=false}'; RestResponse:

{"message":"org.jvnet.hk2.config.ValidationException: Validation Failed: is not of data type: java.lang.Boolean","exit_code":"FAILURE"}

"|#]



 Comments   
Comment by lidiam [ 05/Nov/10 ]

Created an attachment (id=5353)
screenshot

Comment by Anissa Lam [ 05/Nov/10 ]

The issue is in the Availability checkbox. It is fixed. While fixing this, also made the following
cleanup:

  • align checkbox better by adding dummy label
  • Availability Enable is shown only in cluster environment
  • edit of OSGI type deployment indicates the type
  • Remove "Enabled" word following the checkbox of Precompile JSP and Verifier
  • Add back ":" to labels thats missing ":"
Comment by lidiam [ 02/Mar/11 ]

Verified in promoted build b43.





[GLASSFISH-14444] Deployment: align checkboxes on page for Other type deployment Created: 05/Nov/10  Updated: 02/Mar/11  Resolved: 05/Nov/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

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

Operating System: All
Platform: All


Attachments: JPEG File deployment-tightsqueeze.JPG    
Issuezilla Id: 14,444
Tags: 3_1-verified

 Description   

build: ogs-3.1-b28-11_05_2010.zip

I'm deploying an OSGI application and after choosing Other, for type of
deployment, see that all the elements on the page are very close to each other
and not aligned very well, making it somewhat confusing to tell which checkbox
goes with which element. It would be good to have more spacing between
elements. I'll attach a screenshot.



 Comments   
Comment by lidiam [ 05/Nov/10 ]

Created an attachment (id=5352)
screenshot

Comment by Anissa Lam [ 05/Nov/10 ]

Woodstock cannot align checkbox correctly if there is no 'label' following the checkbox.
Fixed by adding an empty label. This should all be fixed.

You will notice that in edit OSGI type screen, the checkbox is not aligned correctly. This is how
woodstock place read-only checkbox. No matter how i try to work around the problem, it still
display it that way. This is minor issue and will not be fixed, since it is deep in the woodstock code.

Comment by lidiam [ 02/Mar/11 ]

Verified in promoted build b43.





[GLASSFISH-14397] OLH: Notify user that Safari and Chrome do not display xml Created: 03/Nov/10  Updated: 02/Mar/11  Resolved: 14/Dec/10

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: Mike Fitch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 14,397
Tags: 3_1-verified

 Description   

Neither Chrome nor Safari display xml files in browser window. One needs to
select View Source in Safari, to view content of xml files. Where this is
important in Glassfish, is when user tries to view WSDL file from Admin Console,
of a deployed web services application. The file shows fine in Firefox.

Thus we should warn users in the web services section of documentation, that
they will not see WSDL file in Safari nor Chrome, when they click on the link to
the file from Admin Console.



 Comments   
Comment by Anissa Lam [ 03/Nov/10 ]

The helpId for the page to include this information is "endpoint", in the common module.

Basically, If user uses FireFox, they will see the WSDL info by clicking the WSDL link.
If they use Chrome or Safair, the browser will show a blank page, so they need to 'right click' to 'View
Page Source' in order to see the content.

Comment by Paul Davies [ 18/Nov/10 ]

Affects OLH. Reassigned to oncered for further evaluation.

Comment by Mike Fitch [ 14/Dec/10 ]

Following info added to writeup of WSDL on help page for "Web Service Endpoint Information" (ref-endpoint.html):

Note that some web browsers attempt to interpret the WSDL source when you click the WSDL link, and so display a blank page. For such browsers, use the browser's View Source command on the blank page to view the WSDL source.

Committed to v3-docs svn rev 43740; included in v3 build 33 (MS7)

Comment by lidiam [ 02/Mar/11 ]

Found the help text in promoted build b43.





[GLASSFISH-14341] Log viewer: error when specifying time range for search Created: 01/Nov/10  Updated: 02/Mar/11  Resolved: 08/Nov/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: sirajg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: JPEG File logviewer-searcherror.JPG    
Issuezilla Id: 14,341
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b27-10_31_2010.zip

Click on server node, View Log Fiels button. Enter some search text, e.g.
warning, and select timestamp specific range accepting defaults. Hit save and
the following error is displayed at the top of the page:

An error has occurred

Server.log contains:

[#|2010-11-01T16:42:19.411-0700|SEVERE|glassfish3.1|org.glassfish.admingui|_ThreadID=15;_ThreadName=Thread-1;|RestResponse.getResponse()
failed. endpoint =
'http://localhost:4848/management/domain/view-log/details.json'; attrs =
'

{logFileName=server.log, instanceName=server, logLevel=INFO, maximumNumberOfResults=40, anySearch=warning, fromTime=Mon Nov 01 00:00:00 PDT 2010, toTime=Mon Nov 01 16:22:38 PDT 2010, searchForward=false}

'; RestResponse: "|#]

[#|2010-11-01T16:42:19.412-0700|SEVERE|glassfish3.1|org.glassfish.admingui|_ThreadID=15;_ThreadName=Thread-1;|RestResponse.getResponse()
failed. endpoint =
'http://localhost:4848/management/domain/view-log/details.json'; attrs =
'

{logFileName=server.log, instanceName=server, logLevel=INFO, maximumNumberOfResults=40, anySearch=warning, fromTime=Mon Nov 01 00:00:00 PDT 2010, toTime=Mon Nov 01 16:22:38 PDT 2010, searchForward=false}

'; RestResponse: "|#]



 Comments   
Comment by lidiam [ 01/Nov/10 ]

Created an attachment (id=5295)
screenshot

Comment by sirajg [ 03/Nov/10 ]

When fromTime or ToTime is specified the logging backend doesn't function
properly and the rest response gets a 404 status.

Comment by naman_mehta [ 08/Nov/10 ]

Debug this issue and found that call is not coming to back end code
(LogFilter.java). Before that it's failing. So assigning to Siraj for debug.

Comment by sirajg [ 08/Nov/10 ]

LogViewer was passing in a String representation of Date whereas REST expects
Long. Fixed by using consistent representation.

Comment by lidiam [ 02/Mar/11 ]

Verified in promoted build b43.





[GLASSFISH-14339] Log viewer: server log displayed for new instance Created: 01/Nov/10  Updated: 02/Mar/11  Resolved: 03/Nov/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: sirajg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: JPEG File logviewer-mixup.JPG     JPEG File logviewer-server.JPG    
Issuezilla Id: 14,339
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b27-10_31_2010.zip

Create a standalone instance and do not start it. Click on the instance name
and click on View Log Files button. You will notice that DAS log file is
displayed instead.

It would be nice, in this situation, to display a message in the log viewer,
saying that logs directory for the instance does not exist (and asking if the
instance was ever started).



 Comments   
Comment by lidiam [ 01/Nov/10 ]

Created an attachment (id=5293)
screenshot for DAS log file

Comment by lidiam [ 01/Nov/10 ]

Created an attachment (id=5294)
screenshot for instance log file - wrong

Comment by sirajg [ 03/Nov/10 ]

Fixed by processing instance name properly in this case.

Comment by lidiam [ 02/Mar/11 ]

Verified in promoted build b43 - View Log File button is now disabled for a stopped instance.





[GLASSFISH-14333] Config: changing log level on instance, changes it on DAS Created: 01/Nov/10  Updated: 02/Mar/11  Resolved: 02/Nov/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: sirajg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 14,333
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b27-10_31_2010.zip

Create a standalone instance copying default-config. Go to instance's config,
Logger Settings page, Log Levels tab. Select all loggers and change log level
to SEVERE. Hit Save button. Here are the issues:

1. Restart required message and icon pop up at the top. When you click on them
the message says:

server log filename changed.
server log filename changed.

2. Go to server-config, Logger Settings, Log Levels page and you will see that
all levels are severe.

Changing log levels on server-config, affects instance log levels as well (the
issue is present both ways).



 Comments   
Comment by sirajg [ 02/Nov/10 ]

Fix the way config is used

Comment by lidiam [ 02/Mar/11 ]

Verified in build b43.





[GLASSFISH-14331] Launch - display server name not localhost Created: 01/Nov/10  Updated: 02/Mar/11  Resolved: 19/Nov/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: sirajg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 14,331
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b27-10_31_2010.zip

Launch link for an application brings a page with http and https urls for the
application. Those urls refer to localhost, even when I run admin gui on a
remote host. The urls should display the machine name of an instance where
application is deployed instead. E.g. if application is deployed to instance
in1, in1's host name should be displayed in urls. For a cluster, all instances
belonging to a given cluster, where application is deployed, should be displayed.



 Comments   
Comment by sirajg [ 10/Nov/10 ]

Resolve "localhost" by looking up the machine name where admin gui is running -
i.e. DAS.

Comment by sirajg [ 12/Nov/10 ]

Marking fixed.

Comment by lidiam [ 15/Nov/10 ]

After clicking Launch link, the new browser window displays 4 urls, two with
resolved ports, two with tokens:

Application Name:
TestWebJAX-WS20
Links:
https://channi.SFBay.Sun.COM:8181/TestWebJAX-WS20
http://channi.SFBay.Sun.COM:8080/TestWebJAX-WS20
https://channi.SFBay.Sun.COM:$

{HTTP_SSL_LISTENER_PORT}

/TestWebJAX-WS20
http://channi.SFBay.Sun.COM:$

{HTTP_LISTENER_PORT}

/TestWebJAX-WS20

Comment by lidiam [ 15/Nov/10 ]

This is with build: ogs-3.1-b30-11_15_2010.zip.

Comment by lidiam [ 15/Nov/10 ]

I think I know why I have 4 urls: application was deployed to server and a
standalone instance. Is it that we cannot pull the instance related information
from domain.xml to display here?

Comment by sirajg [ 19/Nov/10 ]

yes, for each instance you would get the relevant URLs. Some changes in how token resolution works,
incorporated those changes.

Comment by lidiam [ 02/Mar/11 ]

Verified in promoted build b43.





[GLASSFISH-14310] Restart required icon/text does not show up after installing an add-on Created: 29/Oct/10  Updated: 01/Mar/11  Resolved: 14/Dec/10

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: Mike Fitch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 14,310
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b26-10_26_2010.zip

Go to Update Tool and install an add-on, e.g. ant. After the installation a
message is displayed that it was successful and that server needs to be
restarted. However, restart required text and icon are not displayed at the top
of the Admin Console. Also, just out of curiosity, why is is restart required
for ant?



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

I am transferring this to admin since i need their input, and they may need to fix the backend code.

In 3.0.1, GUI were told to always tell user to restart after installing any additional package. Hence
the message. If this is not needed anymore, GUI can remove that.

GUI display the restart required icon depending what the backend tells us. If it doesn't indicate that
restart is required, it won't be show.
So, backend will need to fix this restart required status, in that case, the icon will show up.

Transfer to Jerome for his input.

Comment by dochez [ 01/Nov/10 ]

I am reassigning to Tom for a final decision but this is my input :

1. when a module is installed/removed in/from the glassfish/modules directory, the application server
must be restarted for that change to be effective.

2. there is no configuration operation happening on the domain.xm when folks add or remove bundles
(including through the update center) so the normal restart-required mechanism does not apply here.

One suggestion would be to watch for directory/file changes in glassfish/modules directory (there is a
@Service for that, called FileMonitoring IIRC) and when a change happens, it should explicitly set the
restart required flag.

Comment by Tom Mueller [ 01/Nov/10 ]

Anissa, what interface do you use to the backend for getting the restart
required status?

The Image Package System has the capability to indicate that a restart is
required when an action is updated through the use of the reboot-needed actuator
on an action. However, there are a few problems with this:

a) GlassFish packages do not tag JAR files with reboot-needed
b) One interpretation of reboot-needed is that this is for the operating system,
i.e., it means that an OS reboot is needed. Therefore, it doesn't apply to
GlassFish. To deal with this, the concept of user-level actuators has been
defined.
c) User-level actuators are not implemented in the version of IPS being used
by GlassFish.
d) The Java API for IPS doesn't support accessing the actuator information on
actions even if it was there.

Then intent with UC 2.4 was that user-level actuators were going to be
implemented to do this. But since UC 2.4 is not being implemented, this
capability is missing.

So the bottom line is that the packaging system at this time does not support
the accurate reporting of whether a server restarted is needed.

As Anissa stated, any reporting of a restart needed by the GUI is message that
is output for every package installation. Maybe the message could be rewritten
to be more vague, such as saying that a restart may be needed to use the
functionality provided by the package. This would also eliminate the need for
the restart required indicator to be turned on, because a restart is not really
required; it is only required if one wants to use the functionality that was
just installed. Since the only package operation that is available from the
console is to add a package, a restart really is never required after this. It
is only needed if one wants to use the functionality.

Reassigning back to admin_gui because eventually something there has to be
fixed. If there is some new functionality related to the backend that is needed
for this, please file a new issue. However, at this point, I would suggest just
changing the message slightly to remove the implication that a restart is
required.

Comment by Anissa Lam [ 01/Nov/10 ]

Tom, GUI calls the "_get-restart-required" command to check if restart is required, which also
gives the reason of why restart is required.

I think the message to user is very clear already. But i do as you suggest and transferring to doc
for a better message to present to user.
Currently, it says:
"selected package(s) successfully installed. Server must be restarted before the module(s) are
available."

However, I don't completely agree with the sentence :
"Since the only package operation that is available from the console is to add a package, a restart
really is never required after this. It is only needed if one wants to use the functionality."

Basically you are saying, "restart is required ONLY if user wants to use the functionality', so 'restart-
required' status isn't really necessary. Isn't this true for everything ? If i set debug enable to
true, I don't need to restart the server unless i want to debug. Then, why the server has the
'restart-required' status for config changes ?
I don't see how this is different than adding additional components. So, I think backend should be
fixed to indicate 'restart-required' after user adds/remove components, maybe as what Jerome
suggested.

Comment by Mike Fitch [ 19/Nov/10 ]

Here's a message that gets rid of the word "must" to avoid confusion between
"must in order to use the new capabilities" and "must in order to continue
successful operation". Additionally, it collapses "package" and "module" to the
single term "component", which is what users add via the Update Tool.


The selected components were successfully installed. To make the components
available, restart the server.

Comment by Mike Fitch [ 14/Dec/10 ]

Message updated to "The selected components were successfully installed. To make the components available, restart the server."

v3 svn commit rev 43777; included in v3 build 33 (MS7)

Comment by lidiam [ 01/Mar/11 ]

Verified in build b43.





[GLASSFISH-14399] Config: node image missing for Transaction Service Created: 03/Nov/10  Updated: 28/Feb/11  Resolved: 26/Nov/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

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

Operating System: All
Platform: All


Attachments: JPEG File image-config-missing.JPG    
Issuezilla Id: 14,399
Tags: 3_1-verified

 Description   

build: ogs-3.1-b27-11_03_2010.zip

Open server-config tree and you will notice a question mark after Security node
and before HTTP Service(will attach screenshot). In default-config question
mark is between Availability Service and HTTP Service.



 Comments   
Comment by lidiam [ 03/Nov/10 ]

Created an attachment (id=5323)
screenshot

Comment by lidiam [ 03/Nov/10 ]

The image is missing on the right hand side of configuration as well.

Comment by Harshad Vilekar [ 10/Nov/10 ]

The server log prints following. Looks like the .gif file is missing. Please fix.
----------------
[#|2010-11-10T14:27:02.679-0800|INFO|oracle-glassfish3.1|com.sun.jsftemplating|_ThreadID=14;_ThreadName=Thread-1;|JSFT0004:
The requested resource (/jts/images/transactionService.gif) is not available.|#]
----------------

Comment by Anissa Lam [ 20/Nov/10 ]

Will work on these issues.

Comment by Anissa Lam [ 26/Nov/10 ]

Fix checked in on 11/23. Marking as Resolved

Comment by lidiam [ 28/Feb/11 ]

Verified in promoted build b43.





[GLASSFISH-14282] Configuration: GMS and System Properties missing on the right side page Created: 28/Oct/10  Updated: 28/Feb/11  Resolved: 26/Nov/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

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

Operating System: All
Platform: All


Attachments: JPEG File configuration-missingelements.JPG    
Issuezilla Id: 14,282
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b26-10_26_2010.zip

Click on default-config. On the right hand page will be a list of config
elements. If you expand default-config node you will roughly see the same
elements. The last two, in the expanded tree, are GMS and System Properties.
These elements are missing in the right hand list. Thus it may be hard for a
user to find those elements, if they don't expand the node. All configs created
from default-config have this issue.



 Comments   
Comment by lidiam [ 28/Oct/10 ]

Created an attachment (id=5272)
screenshot

Comment by Anissa Lam [ 20/Nov/10 ]

Will work on these issues.

Comment by Anissa Lam [ 26/Nov/10 ]

Both System Properties and GMS is added to the configuration page.
Fix checked in on 11/24/2010

Comment by lidiam [ 28/Feb/11 ]

Verified in promoted build b43.





[GLASSFISH-14264] Node: cannot create node with required fields only (different error) Created: 27/Oct/10  Updated: 28/Feb/11  Resolved: 03/Nov/10

Status: Closed
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: Joe Di Pol
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: JPEG File node-createerror.JPG     Text File server.log    
Issuezilla Id: 14,264
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b26-10_26_2010.zip

Tried to create a node with required fields only, specifying localhost as the
node host and got the following error:

An error has occurred
Warning: some parameters appear to be invalid. SSH node not created. To force
creation of the node with these parameters rerun the command using the --force
option. Could not connect to host localhost using SSH. Could not authenticate.
No key or password specified - trying default keys Tried to authenticate using
id_rsa Tried to authenticate using id_dsa Tried to authenticate using identity



 Comments   
Comment by lidiam [ 27/Oct/10 ]

Created an attachment (id=5260)
screenshot

Comment by lidiam [ 27/Oct/10 ]

Created an attachment (id=5261)
server.log

Comment by Anissa Lam [ 27/Oct/10 ]

If you enter the same thing in CLI, you will get the same error message. If you click the 'Force'
checkbox, then the node should be created.
Are you saying this error message isn't informative enough ?
GUI is displaying whatever we get back from backend. Transferring to Joe.

Comment by Joe Di Pol [ 03/Nov/10 ]

If you create an SSH node with "localhost" then we probably should not do the
SSH connection validation since SSH will not be used when nodehost is "localhost".

Comment by Joe Di Pol [ 03/Nov/10 ]

Creating an SSH node with nodehost "localhost" now bypasses the SSH connection
validation.

Author: jfdipol
Date: 2010-11-03 21:44:43+0000
New Revision: 42431

Modified:

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/LocalStrings.properties

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/NodeUtils.java

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/UpdateNodeCommand.java

Comment by lidiam [ 28/Feb/11 ]

Verified in promoted build b43. GUI prompts for host and then creates the node.





[GLASSFISH-14261] Cluster properties: cancel brings 404 error Created: 27/Oct/10  Updated: 28/Feb/11  Resolved: 09/Nov/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: Jason Lee
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: JPEG File properties-cancelerror.JPG     Text File server.log    
Issuezilla Id: 14,261
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b26-10_26_2010.zip

Create a cluster and click on it. Go to Properties tab and click Cancel button.
The following error is displayed:

HTTP Status 404 -

type Status report

message

descriptionThe requested resource () is not available.
GlassFish Server Open Source Edition 3.1-SNAPSHOT



 Comments   
Comment by lidiam [ 27/Oct/10 ]

Created an attachment (id=5255)
screenshot

Comment by lidiam [ 27/Oct/10 ]

Created an attachment (id=5256)
server.log

Comment by lidiam [ 27/Oct/10 ]

This issue is for both system properties and cluster properties.

Comment by Jason Lee [ 09/Nov/10 ]

Fix committed (r42658)

Comment by lidiam [ 28/Feb/11 ]

Verified in promoted build b43.





[GLASSFISH-14256] System Properties: exception when clicking Instance Values for new property Created: 27/Oct/10  Updated: 28/Feb/11  Resolved: 05/Nov/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: Jason Lee
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File server.log     JPEG File sysproperties-exception.JPG    
Issuezilla Id: 14,256
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b25-10_21_2010.zip

Create a cluster with one instance. Go to cluster config, System Properties
page. Click on Add Property, fill out the fields for new property (not really
needed to reproduce this bug) and click on Instance Values link for this new
property. The following exception is displayed on page:

type Exception report

message

descriptionThe server encountered an internal error () that prevented it from
fulfilling this request.

exception

javax.servlet.ServletException: javax.el.PropertyNotFoundException: Field
'cluster' not found in DataProvider.

root cause

javax.el.PropertyNotFoundException: javax.el.PropertyNotFoundException: Field
'cluster' not found in DataProvider.

root cause

javax.el.PropertyNotFoundException: Field 'cluster' not found in DataProvider.

note The full stack traces of the exception and its root causes are available in
the GlassFish Server Open Source Edition 3.1-SNAPSHOT logs.
GlassFish Server Open Source Edition 3.1-SNAPSHOT



 Comments   
Comment by lidiam [ 27/Oct/10 ]

Created an attachment (id=5253)
screenshot

Comment by lidiam [ 27/Oct/10 ]

Created an attachment (id=5254)
server.log

Comment by Jason Lee [ 05/Nov/10 ]

Fix committed (r42497)

Comment by lidiam [ 28/Feb/11 ]

Verified in promoted build b43.





[GLASSFISH-14214] Clustered Instance: disable start/stop buttons appropriately Created: 26/Oct/10  Updated: 28/Feb/11  Resolved: 30/Oct/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

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

Operating System: All
Platform: All


Attachments: JPEG File startstop-enabled.JPG    
Issuezilla Id: 14,214
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b25-10_21_2010.zip

Create a cluster with one instance and start it. Go to the instance's page
(cluster name -> instances tab -> instance name). Note that both Start and Stop
buttons are enabled. They are both enabled regardless if the instance is
running or not.

Since this page does not display instance status (running/not running), these
buttons are the only indicators on this page of the instance's status. Not sure
if we want to add Status field to this page. Also, Standalone Instance page has
a Restart button that's missing here. Should it be added? I can log a separate
issue for it if needed.



 Comments   
Comment by lidiam [ 26/Oct/10 ]

Created an attachment (id=5236)
screenshot

Comment by Anissa Lam [ 30/Oct/10 ]

Added status of the instance to the page, so it is clear whether the instance is running or not.
Start and Stop button is hidden accordingly.

Comment by lidiam [ 28/Feb/11 ]

Verified in promoted build b43.





[GLASSFISH-14211] Exception for properties while starting standalone instance Created: 26/Oct/10  Updated: 28/Feb/11  Resolved: 05/Nov/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: Jason Lee
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: JPEG File cluster-startpropertieserror.JPG     JPEG File properties-error.JPG     Text File server.log    
Issue Links:
Dependency
depends on GLASSFISH-10605 Slow loading pages can lead to FPR Resolved
Issuezilla Id: 14,211
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b25-10_21_2010.zip

Create a standalone instance. Go to General page for that instance and click
Start button. While instance is starting click on Properties tab. When the tab
comes up, click on Add Property in Configuration System Properties. The
following error is displayed:

HTTP Status 500 -
type Exception report
message
descriptionThe server encountered an internal error () that prevented it from
fulfilling this request.
exception
java.lang.IllegalStateException: PWC3991: getOutputStream() has already been
called for this response
note The full stack traces of the exception and its root causes are available in
the GlassFish Server Open Source Edition 3.1-SNAPSHOT logs.
GlassFish Server Open Source Edition 3.1-SNAPSHOT



 Comments   
Comment by lidiam [ 26/Oct/10 ]

Created an attachment (id=5229)
screenshot

Comment by lidiam [ 26/Oct/10 ]

Created an attachment (id=5232)
server.log

Comment by Anissa Lam [ 26/Oct/10 ]

If you click on other page while its pretty clear that you should be waiting for the request to finish,
the result is really unpredictable.
However, you shouldn't see this exception in screen either.
Is this happening consistently ?
Requesting help from Jason since he works on the properties page to see why the error on screen.

Comment by lidiam [ 26/Oct/10 ]

I was able to reproduce it consistently 3 times. It takes a while for
properties tab to load but the exception was thrown each time I tried.

Comment by lidiam [ 26/Oct/10 ]

Created an attachment (id=5233)
screenshot - clustered instance

Comment by lidiam [ 26/Oct/10 ]

I've tried a similar thing with clustered instance - just clicked on Properties
tab when instance was starting and got the following:

TTP Status 500 -

type Exception report

message

descriptionThe server encountered an internal error () that prevented it from
fulfilling this request.

exception

javax.servlet.ServletException: java.lang.reflect.InvocationTargetException
while attempting to process a 'command' event for 'startInstance'.
root cause

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while
attempting to process a 'command' event for 'startInstance'.
root cause

java.lang.reflect.InvocationTargetException
root cause

java.lang.NullPointerException
note The full stack traces of the exception and its root causes are available in
the GlassFish Server Open Source Edition 3.1-SNAPSHOT logs.

GlassFish Server Open Source Edition 3.1-SNAPSH

This time I didn't even need to click on Add property. The whole Admin GUI is
gone (attached image).

The issue is that I personally get bored waiting for things to happen, e.g. an
instance or cluster to start. Thus I start clicking around. I'm not sure how
many people are going to do the same thing. If it is not supported to click
around, can we disable it somehow? Otherwise, user would expect things to work...

Comment by Jason Lee [ 29/Oct/10 ]

I am unable to reproduce this error on my current dev build. Are you still seeing this issue?

Comment by lidiam [ 29/Oct/10 ]

I have just tried on build glassfish-3.1-b26-10_26_2010.zip with clustered
instance and still see the same issue (GUI is gone, exception printed instead as
per previous attachment).

Comment by Jason Lee [ 04/Nov/10 ]

With the fix for 10605, this should no longer be an issue.

Comment by Jason Lee [ 05/Nov/10 ]

This should have been marked as FIXED.

Comment by lidiam [ 28/Feb/11 ]

Verified in promoted build b43.





[GLASSFISH-14165] Improve message when instance creation fails with wrong characters Created: 22/Oct/10  Updated: 28/Feb/11  Resolved: 11/Dec/10

Status: Closed
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: Tom Mueller
Resolution: Fixed 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-12776 Bean Validation API doesn't find Vali... Resolved
depends on HK2-10 hard coded bean validation constraint... Resolved
Issuezilla Id: 14,165
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b25-10_21_2010.zip

When attempting to create a standalone instance with an invalid name, such as -
(dash), the following error is displayed in Admin Console:

An error has occurred
Error copying the config caused by org.jvnet.hk2.config.ValidationException:
Constraints for this bean violated. Message = name must match
"[\p

{L}\p{N}_][\p{L}

\p

{N}-_./;#]*"

When I try to do it in Admin CLI, the following error is displayed:

lancer(j2eetest):/export/home/j2eetest/v3.1# a create-instance
Enter the value for the node option> localhost
Enter the value for the instance_name operand> -
remote failure: Exception while adding the new configuration Constraints for
this bean violated.
Message = name must match "[\p{L}\p{N}

_][\p

{L}

\p

{N}

-_./;#]*" :
org.jvnet.hk2.config.TransactionFailure: Injection failed on public abstract
void com.sun.enterprise.config.serverbeans.Server.setName(java.lang.String)
throws java.beans.PropertyVetoException
Injection failed on public abstract void
com.sun.enterprise.config.serverbeans.Server.setName(java.lang.String) throws
java.beans.PropertyVetoException

Command create-instance failed.

In both cases it would be ideal if the message simply said that the instance
name is not acceptable and what the requirements for the name are. The pattern
listed in both cases is not user friendly and would be better if it was
explained in plain words.



 Comments   
Comment by Tom Mueller [ 25/Oct/10 ]

Need to have a fix for 12776 to allow i18n of the bean validation error message to
be able to fix this.

Comment by Tom Mueller [ 11/Dec/10 ]

This is fixed as of revision 43701. The regular expression part of the error message has been replaced with a description of what is actually required in the name.

Note: this doesn't fix the "Message = " part of the message nor the exception names showing up in the message. There are other bugs filed for that.

Comment by lidiam [ 28/Feb/11 ]

Verified in promoted build b43.





[GLASSFISH-14862] class java.lang.RuntimeException after changing log levels in a new configuration. Created: 29/Nov/10  Updated: 28/Feb/11  Resolved: 09/Dec/10

Status: Closed
Project: glassfish
Component/s: rest-interface
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: shaline Assignee: Jason Lee
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Solaris Sparc 10
Browser: firefox 3.6


Issue Links:
Dependency
depends on GLASSFISH-14969 set-log-levels against a running inst... Closed
Tags: 3_1-verified

 Description   

build used: GF V3.1 nightly dated 11/29

Create a new configuration (instance1-config) by copying from default-config.
Create a standalone instance referring the new configuration (instance1-config), and start the instance.
Under the instance1-config/Logger Settings/Log Levels, select all modules, and select the level to either INFO, or OFF, and SEVERE, and click SAVE button.
We see "class java.lang.RuntimeException".

domain server.log has the following:
[#|2010-11-29T14:22:27.449-0800|SEVERE|glassfish3.1|javax.enterprise.system.std.
com.sun.enterprise.server.logging|_ThreadID=15;_ThreadName=Thread-1;|javax.faces
.FacesException: java.lang.reflect.InvocationTargetException while attempting to
process a 'command' event for 'saveButton'.
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicat
ionPhase.java:89)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:395)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java
:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:215)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.j
ava:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipel
ine.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESess
ionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.j
ava:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(Container
Mapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:8
17)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFil
ter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultPro
tocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.jav
a:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.jav
a:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java
:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextT
ask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.
java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadP
ool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool
.java:513)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetExcepti
on while attempting to process a 'command' event for 'saveButton'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHa
ndlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHa
ndlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.event.CommandActionListener.invokeComman
dHandlers(CommandActionListener.java:150)
at com.sun.jsftemplating.layout.event.CommandActionListener.processActio
n(CommandActionListener.java:98)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:
769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:
166)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1
259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicat
ionPhase.java:81)
... 33 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handl
er.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHa
ndlers(LayoutElementBase.java:420)
... 43 more
Caused by: java.lang.RuntimeException: An error occurred during replication
at org.glassfish.admingui.common.util.RestUtil.parseResponse(RestUtil.ja
va:310)
at org.glassfish.admingui.common.util.RestUtil.restRequest(RestUtil.java
:179)
at org.glassfish.admingui.common.util.RestUtil.restRequest(RestUtil.java
:134)
at org.glassfish.admingui.common.handlers.LoggingHandlers.updateLoggerLe
vels(LoggingHandlers.java:136)
... 49 more
Caused by: java.lang.RuntimeException: An error occurred during replication
at org.glassfish.admingui.common.util.RestUtil.parseResponse(RestUtil.ja
va:283)
... 52 more



 Comments   
Comment by sirajg [ 30/Nov/10 ]

The underlying cause : An error occurred during replication
indicates this was probably a failure in the REST layer. Reassigning issue, possible cause could be missing/incorrect annotation.

Comment by Jason Lee [ 02/Dec/10 ]

There appears to be a bug in the CLI for which an issue has been filed.

Comment by Anissa Lam [ 05/Dec/10 ]

Seeking help from Ludo as Jason has many on his plate.

Comment by ludo [ 05/Dec/10 ]

no time for me this week on that...@Javaone conf...
Jason mentions a CLI bug. Which one?

Comment by ludo [ 05/Dec/10 ]

agree with Jason: seems like 14862 CLI bug

Comment by Jason Lee [ 09/Dec/10 ]

The CLI fix addressed this issue.

Comment by shaline [ 27/Jan/11 ]

Verified in promoted b39.





[GLASSFISH-14891] cannot select or add Authentication Layer in New Message Security Configuration page Created: 30/Nov/10  Updated: 28/Feb/11  Resolved: 08/Dec/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

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

OS: Solaris SParc
Browser: firefox 3.6


Tags: 3_1-verified

 Description   

Build used : nightly dated 11/29

In the server-config/Security/ New Message Security Configuration page, we cannot add any value in the Authentication Layer field, or select from the drop down.



 Comments   
Comment by srinik76 [ 01/Dec/10 ]

This is how the functionality was even in GFv2.

Both the existing message security providers SOAP and HttpServlet is available. Since no other Message Security Providers are available Authentication Layer is empty.

Please verify this and close this bug.

Comment by Anissa Lam [ 05/Dec/10 ]

Srini's comment is correct.
Only SOAP and HttpServlet is allowed. So, you cannot select anything from the dropdown.
However, the "New" button shouldn't be displayed or enabled so user won't get into this situation.
I will take this.

Comment by Anissa Lam [ 08/Dec/10 ]

fixed. The New button is disabled if both HTTPServlet and SOAP layer exist.

Comment by shaline [ 26/Jan/11 ]

Verified in promoted b38.





[GLASSFISH-13891] Nodes: ambiguous location for node directory Created: 08/Oct/10  Updated: 24/Feb/11  Resolved: 03/Nov/10

Status: Closed
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: Joe Di Pol
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File server.log    
Issuezilla Id: 13,891
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b23-10_07_2010.zip

When creating new nodes the following options are displayed:

Node Directory:
Points to the parent directory of the node(s) directory

Installation Directory :
Installation directory of GlassFish on local machine.

The above does not specify where the node directory will be created, if
specified by user. From my testing on localhost, where I specify installation
directory as: $

{com.sun.aas.installRoot}

, the node directory (that I called
mynodes) was created under domains/domain1/config:

lancer(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish# find . -name
lancer
./domains/domain1/config/mynodes/lancer

It does not look like a good, default location. My expectation from the help
text on New Node page would be that "mynodes" would be created directly under
install directory. We should either change the behaviour or update the inline
help, so it is clear to the user where the node directory will be created.



 Comments   
Comment by lidiam [ 08/Oct/10 ]

Created an attachment (id=5106)
server.log

Comment by Anissa Lam [ 08/Oct/10 ]

I need Joe to clarify the different directory.
Please clarify what is the expected behavior and provide GUI with the inline
help text so user will not be confused.

Add your inline help text here in this issue and transfer back to GUI so i can
take care of it, thanks

Comment by Joe Di Pol [ 11/Oct/10 ]

Looks like we need to:

1) Decide what location a relative nodedir is relative too. I agree with the
submitter that this should be glassfish3/glassfish.

2) Fix the implementation to put them there. This could either be done in
create-instance (construct and pass a full path for nodedir to
_create-instance-filesystem), or in _create-instance-filesystem (always root
nodedir relative paths to the install directory).

3) Clarify what should be in the console inline help

Comment by Joe Di Pol [ 03/Nov/10 ]

If the nodedir is a relative path it is now rooted in the glassfish install root
directory so if you use "mynodes" it is in /opt/glassfish3/glassfish/mynodes.

Author: jfdipol
Date: 2010-11-03 17:25:46+0000
New Revision: 42425

Modified:

trunk/v3/admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/Node.java

trunk/v3/admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/Servers.java

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/CreateInstanceCommand.java

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/DeleteInstanceCommand.java

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/InstanceDirUtils.java

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/ListNodesHelper.java

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/NodeUtils.java

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/StartInstanceCommand.java

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/UpdateNodeConfigCommand.java

trunk/v3/cluster/ssh/src/main/java/org/glassfish/cluster/ssh/connect/NodeRunner.java

Log:
Fix:
13891 Nodes: ambiguous location for node directory
14206 update-node-ssh/update-node-config qwerty, replace null with real name

Also:
Remove trailing comma from list of instances that are using a node in
list-nodes and in delete-node. Change exception in NodeRunner so that
if asadmin is not executable it gives you the path.

Comment by Joe Di Pol [ 03/Nov/10 ]

Marked as fixed.

Comment by lidiam [ 24/Feb/11 ]

Verified in download build, b43, web distro.





[GLASSFISH-13842] Nodes page talks about node agents Created: 06/Oct/10  Updated: 24/Feb/11  Resolved: 10/Dec/10

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: Paul Davies
Resolution: Fixed 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,842
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b23-10_06_2010.zip

Node page contains the following text:

A node agent is required on every machine that hosts server instances, including
the machine that hosts the DAS. A default node agent is created when Enterprise
Server is installed. A node agent services a single domain. If a machine hosts
instances running in multiple domains, it must run multiple node agents.

We should remove references to node agents.



 Comments   
Comment by Paul Davies [ 06/Oct/10 ]

Must be fixed by MS 7.

See also Issue 13531.

Comment by lidiam [ 24/Feb/11 ]

Verified in download build, b43, web distro.





[GLASSFISH-13802] Launch - 404 error with standalone instance Created: 04/Oct/10  Updated: 24/Feb/11  Resolved: 27/Oct/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: sirajg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: XML File domain.xml     JPEG File launch-404error.JPG     File scrumtoys.war    
Issuezilla Id: 13,802
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b23-10_04_2010.zip

Deploy an application (e.g. scrumtoys.war) to a standalone instance. Go to
Applications page and click on Launch - 404 error is displayed.



 Comments   
Comment by lidiam [ 04/Oct/10 ]

Created an attachment (id=5070)
404 error page

Comment by lidiam [ 04/Oct/10 ]

Created an attachment (id=5071)
domain.xml

Comment by lidiam [ 04/Oct/10 ]

DAS server.log contains:

[#|2010-10-04T21:52:46.918-0700|SEVERE|glassfish3.1|org.apache.jasper.servlet.JspServlet|_ThreadID=14;_ThreadName=Thread-1;|PWC6117:
File
"/export/home/j2eetest/v3.1/glassfishv3/glassfish/lib/install/applications/__admingui/cluster/standalone/applications/webApplicationLinks.jsp"
not found|#]

The instance in question is a standalone instance.

Comment by Anissa Lam [ 04/Oct/10 ]

It depends on how your application is setup. If there needs to be JSP/Servlet
mapping, instead of just using the context root of the embedded war, then the
launch link will be incorrect.
We want to discuss with web-container group to see if it is possible to
construct the launch link correctly for embedded war. If not, we cannot support
launching of embedded war.

Comment by sirajg [ 24/Oct/10 ]

This has nothing to do with an embedded war. The application being deployed is a standalone war as
indicated by the bug submitter. Please attach the .war file with the bug with which the issue was
reproduced.

Comment by lidiam [ 25/Oct/10 ]

Created an attachment (id=5226)
scrumtoys application

Comment by lidiam [ 25/Oct/10 ]

Attached scrumtoys app, as requested.

Comment by sirajg [ 27/Oct/10 ]

The issue of accessing the launch page is fixed. Accessing the application may
still require modifying the URL, depending on how the application is set up.

Comment by lidiam [ 24/Feb/11 ]

Verified in download build, b43, web distro.





[GLASSFISH-13579] back button brings 404 page Created: 22/Sep/10  Updated: 24/Feb/11  Resolved: 29/Nov/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: Jason Lee
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes
Environment:

Operating System: All
Platform: All


Attachments: JPEG File backbutton-404.JPG    
Issue Links:
Duplicate
is duplicated by GLASSFISH-14904 404 error displayed on browser's back... Resolved
Issuezilla Id: 13,579
Tags: 3_1-verified

 Description   

build:

Bring up Admin Console and click on Connectors, Admin Object Resources. Once
the Admin Object Resources page is brough up click on browser's back button. A
404 page not found error page is displayed. This happens from any Admin Console
page. It does not happen in v2.



 Comments   
Comment by lidiam [ 22/Sep/10 ]

Created an attachment (id=4945)
screenshot

Comment by Anissa Lam [ 22/Sep/10 ]

-> Ken

Comment by Jason Lee [ 17/Nov/10 ]

The root cause of this is our ajax-based navigation. It seems that when the user clicks back, the
browser attempts to navigate to the j_security_check, which is where the login form was POSTed to.
The problem, it seems, is that the container only recognizes the "magic" URI (j_security_check) for
POSTs. The GET request from the back button, then, looks for a file by that name in the app, which is
not there, currently. I added a file by that name that redirects to / (which should probably be smarter
at some point), but I'm not sure what the security implications of that are. I'll follow up on the mailing
list for more input.

Comment by Jason Lee [ 29/Nov/10 ]

Fix committed

Comment by lidiam [ 24/Feb/11 ]

Verified in download build, b43.





[GLASSFISH-13632] Deployment - location cleared on any error Created: 27/Sep/10  Updated: 24/Feb/11  Resolved: 06/Nov/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

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

Operating System: All
Platform: All


Attachments: JPEG File deploy-directory1.JPG     JPEG File deploy-directory2.JPG     JPEG File deploy-directory3.JPG     JPEG File deploy-directory3.JPG    
Issuezilla Id: 13,632
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b22-09_27_2010.zip

1. Go to applications node, click on Deploy.
2. Select "Local Packaged File or Directory That Is Accessible from the 3.
Enterprise Server" for location and choose an expanded application on server.
Click OK, even though the type has not been selected - there is no popup
warning, only Type is displayed in red now (there should be a consistent
behaviour across Admin Console for incorrectly filled up forms - i.e. we should
always display a popup or an error messsage on the page).
3. Select Type and click OK - this time a popup informs that Location cannot be
blank. All the application details are still filled in, only location has been
cleared. We should not clear the application location.
4. Click ok on the popup - the Browse Files and Browse Folders buttons are
grayed out, so user cannot select the location directory. One has to select the
other radio button first and then click radio button next to "Local Packaged
File or Directory That Is Accessible from the Enterprise Server" again to get
those buttons active again.
5. Select the deployment directory again - now Type got reset again...

I was able to do directory deployment to server and standalone instance, while
that fails in v2 with the following error:

Trying to create reference for application in target sin1 failed; Directory
deployment is not supported for non-DAS target. Directory deployment is not
supported for non-DAS target.

Not sure if we now support it in V3.1.



 Comments   
Comment by lidiam [ 27/Sep/10 ]

Created an attachment (id=4970)
screenshot

Comment by lidiam [ 27/Sep/10 ]

Created an attachment (id=4971)
screenshot

Comment by lidiam [ 27/Sep/10 ]

Created an attachment (id=4972)
screenshot

Comment by lidiam [ 27/Sep/10 ]

Created an attachment (id=4973)
screenshot

Comment by Anissa Lam [ 06/Nov/10 ]

I have cleaned up deployment client side validation. It testes for

  • specifying location
  • specifying Type
  • Application Name
  • No target specified in an cluster env.

in the above order.

All the above will be validated before submitted to deployment. So, hopefully it is less chance for
the page to clear out like you seeing now.

However, if there is error in the actual deployment, like file not found, already deployed etc. The
page will be refreshed with location field cleared out. The (text field and browse button) is actually
one component, there is no way to just fill that value back in. This is limitation in Woodstock,
probably due to security reasons.

We have to leave it like this for the location clear out.

Fix should be available on 11/7 nightly.

Comment by lidiam [ 24/Feb/11 ]

Verified in promoted build b43 on Mac.





[GLASSFISH-13531] Nodes - text talks about node agents Created: 17/Sep/10  Updated: 23/Feb/11  Resolved: 10/Dec/10

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: Paul Davies
Resolution: Fixed 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,531
Tags: 3_1-verified

 Description   

build: b20, promoted, MS5

Go to create node screen (New Node) - text at the top of the page talks about
node agent.



 Comments   
Comment by Anissa Lam [ 17/Sep/10 ]

Request Mike to give better title help.

Comment by Paul Davies [ 04/Oct/10 ]

Must be fixed by MS 7.

Reassigned to pauldavies

Comment by lidiam [ 23/Feb/11 ]

Verified in promoted build b43.





[GLASSFISH-13760] hardcode string for command 'create-iiop-listener' and 'delete-iiop-listener' Created: 01/Oct/10  Updated: 23/Feb/11  Resolved: 09/Nov/10

Status: Resolved
Project: glassfish
Component/s: orb
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: leonfan Assignee: Ken Cavanaugh
Resolution: Incomplete 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,760

 Description   

There have some hardcoded strings for command 'create-iiop-listener' and
'delete-iiop-listener':

asadmin> create-iiop-listener --listeneraddress 0.0.0.0 --iiopport 1401
iiop_listener_2
IIOP Listener iiop_listener_2 created.

-hard coded in
orb/orb-connector/src/main/java/org/glassfish/orb/admin/cli/CreateIiopListener.java

asadmin> delete-iiop-listener iiop_listener_2
IIOP Listener iiop_listener_2 deleted.

-hard coded in
orb/orb-connector/src/main/java/org/glassfish/orb/admin/cli/DeleteIiopListener.java



 Comments   
Comment by Tom Mueller [ 02/Oct/10 ]

Note that according to the new command output guidelines, commands should not
output confirmation messages in addition to the one output by asadmin unless they
add additional information, which these messages do not. So the fix should be to
omit the messages.

See: http://wikis.sun.com/display/GlassFish/Asadmin+Command+Output+Guidelines

Comment by Ken Cavanaugh [ 09/Nov/10 ]

All that I see currently in the create/delete commands is the
default "Command xxx executed successfully.". I am closing this.

Comment by Ken Cavanaugh [ 23/Feb/11 ]

Moving to ORB component.





[GLASSFISH-13473] Connectors: no validation for name field Created: 15/Sep/10  Updated: 22/Feb/11  Resolved: 21/Nov/10

Status: Closed
Project: glassfish
Component/s: jca
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: Jagadish
Resolution: Fixed 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,473
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b20-09_13_2010.zip

Currently there is no validation done on the name field for connector connection
pool and thus I can create a pool with name -wow-. When I try it on v2.1.1 I
get the following error:

An error has occurred
ADMVAL1047: Value '-wow-' is not valid for attribute 'name' of connector
connection pool. The value must start with a letter or number and may contain
letters, numbers or the following characters: -._/;# ADMVAL1070: Create of
connector connection pool is rejected.



 Comments   
Comment by sumasri [ 07/Oct/10 ]

Added the target milestone.

Comment by sumasri [ 18/Nov/10 ]

In v2, Error is coming from the backend.
So, transferring it to backend team to evaluate. This is the same case for JDBC
pools also.

Comment by Jagadish [ 21/Nov/10 ]

It looks like "name" field validation is introduced differently in v3 when
compared to v2 for jdbc and connector connection pool.

Fixed the "name" field validation to be same as that of v2 for the following
resource types.

jdbc-connection-pool
connector-connection-pool
resource-adapter-config
security-map.

FIX INFORMATION :
svn log -v -r 13473
Fix will be available in 3.1 promoted build 31 / 22nd Nov 2010 nightly.

Comment by lidiam [ 22/Feb/11 ]

Verified in promoted build b43.





[GLASSFISH-12946] Correct text on Standalone Instance page Created: 10/Aug/10  Updated: 22/Feb/11  Resolved: 14/Dec/10

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: lidiam Assignee: Mike Fitch
Resolution: Fixed 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,946
Tags: 3_1-verified

 Description   

build: promoted b14

Currently Standalone Instance page says the following:

---------------------------
Standalone Server Instances

List of instances of this cluster. Select the row that you want to update Lb
Weight for that instances, and click the Save button. (TBD)
---------------------------

Issues:
1. Standalone instance or list of instances in a cluster?
2. Grammar in the second sentence, plus is the only thing that people can change
for an instance an Lb Weight?
3. Remove TBD

Seems this whole message should be changed.



 Comments   
Comment by Jason Lee [ 31/Aug/10 ]

Reassinging to JMS page owner

Comment by sumasri [ 09/Sep/10 ]

As this is a standalone instance issue, transferring it to Anissa.

Comment by Anissa Lam [ 09/Sep/10 ]

Requesting help from Mike.
Maybe he has already fixed this with the recent checkin.

Comment by Paul Davies [ 04/Oct/10 ]

Must be fixed by MS 7.

Comment by Mike Fitch [ 14/Dec/10 ]

Corrected by pauldavies. Available in v3 build 33 (MS7).

Comment by lidiam [ 22/Feb/11 ]

Verified in promoted build b43.





[GLASSFISH-15127] REGRESSION : uninstallation throws error message Created: 13/Dec/10  Updated: 22/Feb/11  Resolved: 13/Dec/10

Status: Resolved
Project: glassfish
Component/s: installation
Affects Version/s: None
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: hsbhavya Assignee: scatari
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ogs-3.1-b32-unix.sh


Tags: 3-1-regression, 3_1-verified

 Description   

Steps to reproduce :

1) Un-install the 3.1B32 glassfish server.
2) You can see below error message on the console.

-bash-3.00# sh uninstall.sh
Entering Setup...
SwixML 1.5 (#144)
WARNING: Cannot delete file [File=/opt/glassfish3/.org.opensolaris,pkg/state/installed ]
WARNING: Cannot delete file [File=/opt/glassfish3/glassfish/lib/registration ]
WARNING: Cannot delete file [File=/opt/glassfish3/.org.opensolaris,pkg/state ]
WARNING: Cannot delete file [File=/opt/glassfish3/.org.opensolaris,pkg/pkg ]
WARNING: Cannot delete file [File=/opt/glassfish3/.org.opensolaris,pkg ]
WARNING: Cannot delete file [File=/opt/glassfish3/glassfish/lib ]
WARNING: Cannot delete file [File=/opt/glassfish3/glassfish ]
WARNING: Cannot delete file [File=/opt/glassfish3/bin ]
WARNING: Cannot delete file [File=/opt/glassfish3/glassfish ]
// Error: Exception in runnable:Typed variable declaration : Class: RelayService not found in namespace : at Line: 138 : in file: inline evaluation of: `` import org.openinstaller.bus.; import org.openinstaller.core.; import org.ope . . . '' : RelayService

Note : With the previous builds there was only WARNING message , Error message is seen with B32.Hence marking it as REGRESSION



 Comments   
Comment by scatari [ 13/Dec/10 ]

This is not a regression. The installer framework inadvertently tries to load some of the registration classes even during uninstall time. An explicit check will be added not to do this.

Comment by scatari [ 13/Dec/10 ]

Added explicit check to avoid using registration services for uninstall.





[GLASSFISH-14240] BLOCKING: Typical / custom installation on HPUX machine fails Created: 27/Oct/10  Updated: 22/Feb/11  Resolved: 29/Oct/10

Status: Resolved
Project: glassfish
Component/s: installation
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Blocker
Reporter: hsbhavya Assignee: scatari
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: HP-UX
Platform: All


Attachments: PNG File 3.1_installer_hpux_2.png    
Issuezilla Id: 14,240
Tags: 3_1-verified

 Description   

Trigger 3.1B24 Installation on HPUX machine .
Installation will get over without taking much time (less than a miniute) , and
configuration of domain fails.

You can see this issue with both typical and custom installation.



 Comments   
Comment by hsbhavya [ 27/Oct/10 ]

Created an attachment (id=5247)
3.1_installer_hpux

Comment by scatari [ 27/Oct/10 ]

Is this happening only on this machine OR on all of HpUX machine? Could the submitter please try
reproducing this on a different HpUX machine? Also on the machine where the original issue appeared,
please try installing on a directory different than the one used in previous run.

Comment by hsbhavya [ 28/Oct/10 ]

I have tried 3-4 times by changing the different install directory location than
the one used in previous run and issue is still reproducible.
As installation is not happening properly, unable to proceed further . Its a
stopper issue.

Comment by scatari [ 29/Oct/10 ]

Fixed dependency resolution of OpenInstaller by explicitly adding OS info including Archs(IA64N, IA64W
and PA-RISC) to component dependency metadata.





[GLASSFISH-14979] Error while Saving the Domain Attributes Page Created: 03/Dec/10  Updated: 21/Feb/11  Resolved: 08/Dec/10

Status: Closed
Project: glassfish
Component/s: rest-interface
Affects Version/s: 3.1_b31
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: shaline Assignee: Mitesh Meswani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Solaris SParc 10
Browser: firefox 3.6


Issue Links:
Dependency
depends on GLASSFISH-14921 asadmin set fails for attributes of e... Resolved
Tags: 3_1-verified

 Description   

GF build: nightly dated 12/03.

In the Console, Domain/Domain Attributes page, Edit the "Log Root" field, and click Save. An error is thrown as below:
An error has occurred
Could not apply changesInvalid attribute name log-root

Or just by clicking SAVE button in Domain/Domain Attributes page, without editing any fields throws this Error.



 Comments   
Comment by Anissa Lam [ 03/Dec/10 ]

I need the REST team to take a look.
Just go to http://localhost:4848/management/domain and click SAVE shows the same error.

In GUI, here is the info in post() :

endpoint: "http://localhost:4848/management/domain"
payload: {applicationRoot=$

{com.sun.aas.instanceRoot}/applications,
locale=null,
logRoot=${com.sun.aas.instanceRoot}

/logs,
version=anilam-private}

Here is the error shown in server.log:

[#|2010-12-03T17:52:47.385-0800|SEVERE|glassfish3.1|org.glassfish.admingui|_ThreadID=120;_ThreadName=admin-thread-pool-4848(4);|RestResponse.getResponse() failed. endpoint = 'http://localhost:4848/management/domain'; attrs = '{applicationRoot=$

{com.sun.aas.instanceRoot}/applications, locale=null, logRoot=${com.sun.aas.instanceRoot}

/logs, version=anilam-private}'; RestResponse:

{"message":"Could not apply changesInvalid attribute name log-root","exit_code":"FAILURE"}

"|#]

Comment by ludo [ 05/Dec/10 ]

This is also a set command bug.

One cannot set attributes on the Domain object itself there...
Mitesh was supposed to file a but on CLI there. Check with him

Comment by Anissa Lam [ 06/Dec/10 ]

According to Mitesh, depending on this bug.

Comment by Mitesh Meswani [ 08/Dec/10 ]

Fixed with http://java.net/projects/glassfish/sources/svn/revision/43597

Comment by shaline [ 26/Jan/11 ]

verified in promoted b38.





[GLASSFISH-13740] Session Invalidation across instances fails Created: 30/Sep/10  Updated: 20/Feb/11  Resolved: 08/Dec/10

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: gopaljorapur Assignee: Rajiv Mordani
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 13,740
Tags: 3_1-verified

 Description   

I am using Build 20

Following is the scenario

Create an HTTP Session (using Servlet)
add a name/value
Stop the instance that processed above request
Try to invalidate the session

We see an Error 500



 Comments   
Comment by Mahesh Kannan [ 07/Oct/10 ]

-> web container team.

Gopal: Can you attach the app?

Comment by Santiago Pericas-Geertsen [ 12/Oct/10 ]

A simplified sample app would certainly help. Not exactly sure what you're doing in the "stop
the instance" step.

Comment by jjackb [ 09/Nov/10 ]

I can confirm this issue.

My setup:

  • two physical different hosts running ubuntu
  • glassfish-3.1-b28-11_08_2010
  • java version "1.6.0_20" / Java(TM) SE Runtime Environment (build 1.6.0_20-b02) / Java HotSpot(TM) Client VM (build
    16.3-b01, mixed mode, sharing)

Steps to reproduce:
1. create cluster (two instances, one each host)
2. create roundrobin (rr) loadbalancer (lb), no sticky sessions
3. deploy eg SimpleSession.war
4. open lb in browser
-> new session created on eg instance1
5. click "invalidate session"
-> due to rr, request is send to instance2
-> instance2 gets invalidate session request
-> browser shows 500, NullPointer
-> instance2 throws StreamCorruptedException (see end of this comment)

It is not necessary to stop instance1.

a thought:

As described in GLASSFISH-14038, a failover from one physical host to another does n