This chapter describes known problems and associated workarounds for the Sun GlassFish Enterprise Server v2.1.1 software. If a summary statement does not specify a particular platform, the problem applies to all platforms.
This section describes known administration issues and associated solutions.
When a cluster is created, Enterprise Server randomly assigns a heartbeat port between 1026 to 45556. For default-cluster, which is the default cluster created by a Enterprise Server installation, a random number selected between 0 to 45556. The cluster creation process does not accurately detect if the heartbeat port is already being used by another service.
If automated cluster creation configuration selects a heartbeat port that is in conflict with another service that is already using that port, update the cluster heartbeat port to a port that is not being used by the system.
To change the heartbeat port of a cluster, use the following asadmin command:
asadmin set cluster-name.heartbeat-port=newportnumber
The asadmin create-domain command may fail while attempting to create a domain on a Network File System (NFS) mounted file system with the NFS server running on 64-bit Linux.
No known solution.
When a huge log file is rotated, a slight increase in the response time is observed.
Performance degradation can be minimized by modifying the values for File Rotation Limit and File Rotation Time Limit in the Logger settings. The values for these properties would depend on your application and environment.
Deployment of a generic RA adapter against IBM Message Queue product fails. The permissions granted in the server.policy file is as follows.
grant { permission java.util.logging.LoggingPermission "control"; permission java.util.PropertyPermission "*", "read,write"; } |
Change the permissions in the server.policy file as follows:
grant codeBase "file:${com.sun.aas.installRoot}/lib/install/applications/adminapp/-" { permission java.util.logging.LoggingPermission "control"; }; |
In some circumstances, files installed on the DAS intending to be synchronized with a specific instance actually get sent to additional instances.
No known solution.
The asadmin start-cluster command shows too many messages even when non-critical components fail during startup. See the following example command output when non-critical elements (related to the instances in the cluster) fail:
./asadmin start-cluster --port 9898 cluster1 Please enter the admin user name>admin Please enter the admin password> The clustered instance, instance2, was successfully started. error 0 [#|2008-07-17T14:58:16.496+0200|WARNING|sun-appserver9.1|javax.jms| _ThreadID=10;_ThreadName=main; _RequestID=90bbbe3a-d654-4480-b295-7e317d945a4a;|[C4003]: Error occurred on connection creation [localhost:37676]. - cause: java.net.ConnectException: Connection refused|#] error 1 [#|2008-07-17T14:58:17.517+0200|WARNING|sun-appserver9.1|javax.jms| _ThreadID=10;_ThreadName=main; _RequestID=90bbbe3a-d654-4480-b295-7e317d945a4a;|[C4003]: Error occurred on connection creation [localhost:37676]. - cause: java.net.ConnectException: Connection refused|#] error 2 [#|2008-07-17T14:58:30.596+0200|WARNING|sun-appserver9.1| javax.enterprise.system.container.ejb| _ThreadID=13;_ThreadName=pool-1-thread-4;TimerBean; _RequestID=5954a044-df06-4a3e-902a-0c40b4b6cddb; |EJB5108:Unable to initialize EJB Timer Service. The likely cause is the database has not been started or the timer database table has not been created.|#] error 3 [#|2008-07-17T14:58:32.512+0200|WARNING|sun-appserver9.1| javax.enterprise.resource.resourceadapter|_ThreadID=10;_ThreadName=main; __CallFlowPool;_RequestID=90bbbe3a-d654-4480-b295-7e317d945a4a;| RAR5005:Error in accessing XA resource with JNDI name [__CallFlowPool] for recovery|#] The clustered instance, instance1, was successfully started. error 0 [#|2008-07-17T14:58:21.117+0200|WARNING|sun-appserver9.1| javax.enterprise.system.container.ejb| _ThreadID=13;_ThreadName=pool-1-thread-4;TimerBean; _RequestID=30827d9a-72ac-4854-b216-06494b6a9fb5; |EJB5108:Unable to initialize EJB Timer Service. The likely cause is the database has not been started or the timer database table has not been created.|#] error 1 [#|2008-07-17T14:58:23.106+0200|WARNING|sun-appserver9.1| javax.enterprise.resource.resourceadapter| _ThreadID=10;_ThreadName=main;__CallFlowPool; _RequestID=b41d76fa-0203-49f7-a2ae-83bf242d3e7a; |RAR5005:Error in accessing XA resource with JNDI name [__CallFlowPool] for recovery|#] Command start-cluster executed successfully.
No known solution. These (exceptions) messages can be ignored.
Deployment of a generic RA adapter against IBM Message Queue product fails. The permissions granted in the server.policy file is as follows.
grant { permission java.util.logging.LoggingPermission "control"; permission java.util.PropertyPermission "*", "read,write"; } |
Change the permissions in the server.policy file as follows:
grant codeBase "file:${com.sun.aas.installRoot}/lib/install/applications/adminapp/-" { permission java.util.logging.LoggingPermission "control"; }; |
By default, there is a hard-coded value in as-install/lib/package-appclient.xml for the AS_ACC_CONFIG variable for domain1 that is pointed to by asenv.conf. If domain1 is deleted and a new domain created, the AS_ACC_CONFIG variable is not updated with the new domain name, which causes the package-appclient script to fail.
Do one of the following:
Leave domain1 intact, and create your other domains around it.
Remove domain1 and replace the hard-coded value for domain1 in as-install/lib/package-appclient.xml with the new domain name.
This will have to be done every time a new domain is created if domain1 is not present.
J2SE 1.4.x, 5.0, or later can be configured on the server. An integral feature of J2SE 5.0 platform is the ability to start a JMX agent. This is activated when you explicitly set system properties at the server startup.
Example values include:
name="com.sun.management.jmxremote" value="true" name="com.sun.management.jmxremote.port" value="9999" name="com.sun.management.jmxremote.authenticate" value="false" name="com.sun.management.jmxremote.ssl" value="false" |
After configuring JMX properties and starting the server, a new jmx-connector server is started within the Virtual Machine. An undesirable side-effect of this is that the administration functions are affected adversely, and the Administration Console and command—line interface may produce unexpected results. The problem is that there are some conflicts between the built in jmx-connector server and the new jmx-connector server.
If using jconsole (or any other JMX-compliant client), consider reusing the standard JMX Connector Server that is started with server startup.
When the server starts up, a line similar to the one shown below appears in the server.log. You can connect to the JMXService URL specified there and perform the same management/configuration operations after successfully providing the credentials; for example:
[#|2004-11-24T17:49:08.203-0800|INFO|sun-appserver-ee8.1| javax.enterprise.system.tools.admin|_ThreadID=10;|ADM1501: Here is the JMXServiceURL for the JMXConnectorServer: [service:jmx:rmi:///jndi/rmi://hostname:8686/management/ rmi-jmx-connector]. This is where the remote administrative clients should connect using the JSR 160 JMX Connectors.|#]
For more information, refer to the Sun GlassFish Enterprise Server v2.1.1 Administration Guide.
When setting up the load balancer configuration with an application that has an EJB module that exports a web service URL, the context root for the web service isn't in the resulting loadbalancer.xml file.
Edit the loadbalancer.xml file to add the missing web module as follows:
<web-module context-root="context-root-name" disable-timeout-in-minutes="30" enabled="true"/> |
Replace context-root-name value with the context root name of the web service that was exposed as an EJB.
The .asadmintruststore file is not described in the Enterprise Server documentation. If this file does not exist in the server administrator's home directory, you may experience serious bugs when upgrading certain applications hosted on the server.
If possible, the asadmin start-domain domain1 command should be run by the user who installed the server.
If it is not run by that user, the .asadmintruststore should be moved or copied from the home directory of the user who performed the installation to the home directory of the user who is running the server.
Note that if the file is moved (not copied) from the installing user's home directory to the running user's home directory, you might experience application upgrade problems, as described in bugs 6309079, 6310428 and 6312869, because the upgrade/install user (normally root in Java ES) will no longer have the .asadminstruststore file in his or her home directory.
The default MQ integration mode for a Enterprise Server cluster instance is LOCAL. When Enterprise Server is installed in a location (PATH) that is long (read “not short”), imqbrokerscv.exe crashes when the cluster instance starts. The problem is a memory allocation problem in imqbrokersvc.
The JMS service type for the cluster instance must be changed from the default LOCAL to REMOTE. In this configuration, all the instances point back to the DAS broker. Follow the instructions below to configure a cluster in REMOTE mode.
When using REMOTE mode, all instances are using one broker (DAS) , and therefore no broker cluster is created when the Enterprise Server cluster starts up. See “Auto-clustering” in Section 4.1, Division iii of the one-pager at http://wikis.sun.com/display/GlassFish for more information. The above functionality will not be available!
Modify the port and password file according to your environment. Note that in the instructions below, the cluster name is racluster, the DAS admin port is 5858, and the DAS JMS port is 7676.
Modify the cluster configuration, changing the JMS type to REMOTE.
as-install/bin/asadmin.bat set --port 5858 --user admin --passwordfile \ as-install/bin/password_file racluster.jms-service.type=REMOTE |
Create a JMS host corresponding to the DAS JMS host.
as-install/bin/asadmin.bat create-jms-host --port 5858 --user admin --passwordfile \ as-install/bin/password_file --target racluster --mqhost localhost --mqport 7676 \ --mquser admin --mqpassword admin dashost |
Set the default JMS host to be the DAS JMS host created in the previous step.
as-install/bin/asadmin.bat set --port 5858 --user admin --passwordfile \ as-install/bin/password_file racluster.jms-service.default-jms-host=dashost |
Go to Configurations->cluster-name-config->Java Message Service->JMS Hosts.
Click New to create a new JMS host; name it dashost.
Enter configuration settings corresponding to the JMS service for the DAS; defaults are as follows:
Hostname: localhost
Port: 7676
Admin user: admin
Password: admin
Modify these settings as appropriate for your DAS JMS service.
Navigate back to the Java Message Service tab, and change the JMS service type to REMOTE (default is LOCAL).
Choose dashost from the default-jms-host drop-down list.
Save the changes, and then start your node-agent or cluster.
When trying to display a chart from the Log Statistics Monitoring page using some unsupported browsers, the following error may be thrown:
Error loading jmaki.widgets.jmaki.charting.line.Widget : id=form1:jmaki_chart11 Script: http://easqelx5.red.iplanet.com:4848/resources/jmaki/charting/ \ line/component.js (line:5437). Message: area.initialize is not a function |
Use a supported browser. Refer to Browsers for a list of browsers supported by Enterprise Server v2.1.1.
The default admin port has changed in each of the past three major Enterprise Server releases. Specifically, the default admin ports in 7.x, 8.x, and 9.x are as follows:
AS 7.x: 4848
AS 8.x: 4849
AS 9.x: 4848
This is not a bug, but something to be aware of. The default admin port is just a recommendation. It is anticipated that future Enterprise Server releases going forward will retain the default 4848 port.
On the AIX operating system, an attempt to create a domain with a custom master password fails with the following error:
keytool error (likely untranslated): java.lang.NullPointerException Enter keystore password: New keystore password: |
In the procedure that follows, only the options that are required in each step are provided. If you require additional options for a command, specify these options in the command. For information about Enterprise Server commands, see Sun GlassFish Enterprise Server v2.1.1 Reference Manual.
Create a shell script that contains the following lines of code:
#!/bin/sh changeKeystorePass() { keytool -storepasswd -keystore ${KEYSTORE} -storepass ${OLD} -new ${NEW} } changeTruststorePass() { keytool -storepasswd -keystore ${TRUSTSTORE} -storepass ${OLD} -new ${NEW} } changeKeyPass() { keytool -keypasswd -alias s1as -keystore ${KEYSTORE} -storepass ${NEW} -keypass ${OLD} -new ${NEW} } changeDomainPasswordEntry() { keytool -storepasswd -storetype JCEKS -keystore ${DOMAINPASSWORDS} -storepass ${OLD} -new ${NEW} } deleteMasterPasswordFile() { if [ -f ${DOMAIN_PATH}/master-password ] ; then echo Deleting ${DOMAIN_PATH}/master-password rm -f ${DOMAIN_PATH}/master-password fi } DOMAIN_PATH=$1 OLD=$2 NEW=$3 if [ $# != 3 ] ; then echo Usage: $0 domain-path old-master-pass new-master-pass exit 1 fi echo Processing ... if [ ! -f ${DOMAIN_PATH}/config/domain.xml ] ; then echo "Domain with folder ${DOMAIN_PATH} does not exist, create it first" exit 2 else KEYSTORE=${DOMAIN_PATH}/config/keystore.jks TRUSTSTORE=${DOMAIN_PATH}/config/cacerts.jks DOMAINPASSWORDS=${DOMAIN_PATH}/config/domain-passwords changeKeystorePass changeTruststorePass changeKeyPass changeDomainPasswordEntry deleteMasterPasswordFile fi
Create a domain, specifying the default master password.
aadmin create-domain {--adminport aminportno|--portbase portbase} domain-name Please enter the admin user name>admin-user Please enter the admin password>admin-user-password Please enter the admin password again>admin-user-password Please enter the master password [Enter to accept the default]:> Please enter the master password again [Enter to accept the default]:> |
The default master password is changeit.
Change the master password of the domain that you have just created.
To change the master password, run the script that you created in Step 1.
script-name domain-path old-password new-password |
Start the domain that you created in Step 2.
asadmin start-domain domain-name |
Because the domain has a custom master password, you are prompted for the master password.
In response to the prompt, type the new master password.
For domains that are configured to support clusters, create and start a node agent.
Create a node agent for the domain that you created in Step 2.
asadmin create-node-agent --port portno --user admin-user |
Start the node agent that you created in Step a.
asadmin start-node-agent |
Because the domain has a custom master password, you are prompted for the master password.
In response to the prompt, type the new master password.
The following Enterprise Server man pages:
On the AIX operating system, some OS-related operations might fail with the following error:
0403-027 The parameter list is too long |
Examples of OS-related operations are deploying applications or running the application client container.
This issue is commonly caused by long file paths in the CLASSPATH environment variable.
Use one of the following solutions:
Increase the maximum length of the command line. For more information, see (AIX) To Increase the Maximum Length of the Command Line.
Use the xargs command to construct the argument list and start the command. The xargs command allows commands to exceed the maximum length of the command line.
The ncargs attribute determines maximum length of the command line, including environment variables. On the AIX operating system, the default value of the ncargs attribute is four, 4–Kbyte blocks. To ensure that Enterprise Server commands do not exceed the maximum length of the command line , increase this value to 16 4–Kbyte blocks.
After the value of the ncargs attribute is changed, no reboot or refresh of daemons is required.
Determine the value of the ncargs attribute.
lsattr -EH -l sys0 | grep ncargs |
If the value of the ncargs attribute is less than 16 4–Kbyte blocks, increase the value to 16.
chdev -l sys0 -a ncargs=16 |
This section describes known Apache Web server and load balancer plugin issues and associated solutions.
Enabling the Sun GlassFish Enterprise Server v2.1.1 Patch 2 Load Balancer on SUSE Linux Enterprise Server 10 SP2 with Sun Java System Web Server 7u8 crashes the Web server.
Add the following lines to the startup script for the Sun Java System Web Server:
LD_PRELOAD=/usr/lib/libstdc++-libc6.2-2.so.3 export LD_PRELOAD |
When you deploy any WAR (or EAR) with a servlet-based web service, the HTTP Load Balancer is updated with information about the web service. When an EJB-based web service is deployed, the configuration of the HTTP Load Balancer is not updated to reflect the new object.
Add these context roots manually to the load balancer configuration file (loadbalancer.xml). However, dynamic reconfiguration of load balancer configuration (using the auto-apply feature) would result in older manual edits being lost.
Turn off the auto-apply feature from DAS and instead use the manual export feature to edit and apply the load balancer configuration onto the Web Server.
To run Apache security, you must use a certificate. For instructions on obtaining a certificate from a certificate authority, see the information on certificates in the modssl FAQ.
On Solaris, if your Application Server was installed under root, you must start the Apache Web Server as root. Java Enterprise System installations are installed as root. For Apache 2.0, after starting as root, Apache switches and runs as another user you designate. You designate that user in the /conf/httpd.conf file. To start as root, on many systems you must edit the httpd.conf file to designate the correct group. Replace the line:
Group #-1
with
Group nobody
More information on user/group use is included in the httpd.conf file.
This section describes known application client issues and associated solutions.
If you have a top level JAR file inside your client JAR (in this case, reporter.jar), when you deploy the client JAR, the MANIFEST file for that JAR overwrites the MANIFEST file for the client JAR.
None at this time.
The application client always tries to connect to localhost:3700. The problem is that several system properties need to be read before the client code is invoked.
Set the following as system properties (-D in your JAVA_CMD). Do not set them in your appclient code:
org.omg.CORBA.ORBInitialHost = server-instance-host org.omg.CORBA.ORBInitialPort = server-instance-port |
Running on 64–bit Linux, the following exception when starting a domain. The issue is a missing sunpkcs11.jar under jdk1.5.0_11/jre/lib/ext/.
This is a known JDK bug with 64–bit Linux, and will be fixed in JDK 1.5.0_13.
When a SocketChannel is registered on several Selectors, doing socketChannel.keyFor(lastRegisteredSelector) returns null instead of the SelectionKey.
This is related to a JDK bug, 6562829, and is expected to be fixed in 6.0 U3. A workaround has been included in Enterprise Server 2.1, such that the selector is unwrapped before the keyFor API is called. This enables the keyFor to succeed until JDK bug is fixed.
This section describes known bundled Sun JDBC driver issues and associated solutions.
If an application generates more than 3000 PreparedStatement objects in one transaction, the following error may occur with DB2:
[sunm][DB2 JDBC Driver] No more available statements.Please recreate your package with a larger dynamicSections value.
Add following properties to the connection pool definition to get the driver to rebind DB2 packages with a larger dynamic sections value:
createDefaultPackage=true replacePackage=true dynamicSections=1000
See the Sun GlassFish Enterprise Server v2.1.1 Administration Guidefor details about configuring connection pools.
Related to the PrepardStatement error above, another error message that may be thrown is:
[sunm][DB2 JDBC Driver][DB2]Virtual storage or database resource is not available.
Increase the DB2 server configuration parameter APPLHEAPSZ. A good value is 4096.
Isolation level TRANSACTION_SERIALIZABLE. If your application uses isolation level TRANSACTION_SERIALIZABLE and uses one of the parameters suggested above, it might hang while obtaining a connection.
To set desired isolation level for a connection, the corresponding connection pool has to be created at that isolation level. See the Sun GlassFish Enterprise Server v2.1.1 Administration Guide for instructions.
The bundled Java DB database is not automatically restarted after a host system or Solaris zone reboot, or an Enterprise Server start. This is not a bug, but expected behavior for any bundled or third-party application. The problem is that the Java DB must be started before the Enterprise Server instance.
After rebooting the host machine or Solaris zone, be sure to start the Java DB before starting Enterprise Server; for example:
/opt/SUNWappserver/appserver/bin/asadmin start-database |
Refer to Administration Tools in Sun GlassFish Enterprise Server v2.1.1 Quick Start Guide in the Sun GlassFish Enterprise Server v2.1.1 Quick Start Guide for more information about asadmin command options.
Timing issues sometimes cause autodeployment to fail in domains that are configured to support clusters. The issue is not observed in domains that do not support clusters.
Use one of the following solutions:
Use autodeployment as follows:
Automatically deploy individual applications sequentially.
Introduce a delay between autodeployments of individual applications
Deploy applications manually by using either the Admin Console GUI or the command line.
The following exception is thrown in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher.
Use of the bundled ANT for things outside the Enterprise Server is not recommended.
The application-specific classloader (applibs or --libraries) is not used by the JSP compilation. As a result, JSPs referencing these JARs will not compile.
No known solution.
This section describes known documentation issues and associated solutions.
The Javadoc for several AMX interfaces and methods is either missing or incorrect:
Getter methods for NumConnAcquired and NumConnReleased statistics are missing from ConnectorConnectionPoolStats and AltJDBCConnectionPoolStats. These getter methods will be added in a future release as getNumConnAcquired() and getNumConnReleased().
Calling the following methods in EJBCacheStats will throw an exception: getPassivationSuccesses(), getExpiredSessionsRemoved(), getPassivationErrors(), getPassivations(). This will be fixed in a future release.
The AMX MBeans may require several seconds after server startup before they are all registered and available for use. A future release will make it possible to determine when the AMX MBeans are fully loaded.
The constant XTypes.CONNNECTOR_CONNECTION_POOL_MONITOR is misspelled ("NNN"). This will be corrected in a future release.
Several locations in the GlassFish 2.x documentation set refer to the deprecated create-session-store subcommand.
Use the create-ha-store subcommand instead of the deprecated create-session-store subcommand. For example, change the following command:
asadmin create-session-store --storeurl url --storeuser user --storepassword password --dbsystempassword password |
to
asadmin create-ha-store --user user --passwordfile filename databasename |
The Domain Administration Server (DAS) in versions of Sun GlassFish Enterprise Server prior to v2.1.1 did not allow multiple applications to be deployed using the same web context root, even if those applications were targeted for different Enterprise Server instances.
This behavior was changed in Enterprise Server v2.1.1, and the DAS now supports the deployment of applications using the same context root as long as those applications are deployed to different Enterprise Server instances. However, this new DAS support is not sufficiently documented.
Deploying a WAR Module in Sun GlassFish Enterprise Server v2.1.1 Application Deployment Guide states:
Web module context roots must be unique within a server instance.
While technically accurate, it is useful to add the following further clarification to this statement:
The DAS in Sun GlassFish Enterprise Server versions v2.1.1 and later supports the deployment of multiple web applications using the same web context root as long as those applications are deployed to different Enterprise Server instances. Deploying multiple applications using the same context root within a single Enterprise Server instance will produce a DAS error.
Resouce Injection does not work in HandlerChain due to EJB initialization order.
No known solution.
This section describes known high availability database (HADB) issues and associated solutions.
Load balancer plug-in healthcheck generates a large number of connection/disconnection at the background (load). For health check purposes, a runDaemonMonitor thread performs connect/disconnect for every Application Server listener. This can lead to connection saturation on Enterprise Server.
A new attribute, monitor-interval-in-seconds, has been developed for the loadbalancer.xml file. This attribute can be used to insert a pause between connect/disconnect events in the case where hundreds of listeners are configure for the load balancer plug-in. Default pause value is 0.
HADB configured with double networks on two subnets works properly on Solaris SPARC. However, due to problems in the operating system or network drivers on some hardware platforms, it has been observed that Solaris x86 and Linux platforms do not always handle double networks properly. This causes the following problems with HADB:
On Linux, some of the HADB processes are blocked when sending messages. This causes HADB node restarts and network partitioning.
On Solaris x86, some problems may arise after a network failure that prevent switching to the other network interface. This does not happen all the time, so it is still better to have two networks than one. These problems are partially solved in Solaris 10.
Trunking is not supported.
HADB does not support double networks on Windows 2003 (ID 5103186).
Creating a new database may fail with the following error, stating that too few shared memory segments are available:
HADB-E-21054: System resource is unavailable: HADB-S-05512: Attaching shared memory segment with key "xxxxx" failed, OS status=24 OS error message: Too many open files.
Verify that shared memory is configured and the configuration is working. In particular, on Solaris 8, inspect the file /etc/system, and check that the value of the variable shmsys:shminfo_shmseg is at least six times the number of nodes per host.
When increasing device or buffer sizes using hadbm set, the management system checks resource availability when creating databases or adding nodes, but does not check if there are sufficient resources available when device or main-memory buffer sizes are changed.
Verify that there is enough free disk/memory space on all hosts before increasing any of the devicesize or buffersize configuration attributes.
It is not possible to register the same software package with the same name with different locations at different hosts; for example:
hadbm registerpackage test --packagepath=/var/install1 --hosts europa11 Package successfully registered. hadbm registerpackage test --packagepath=/var/install2 --hosts europa12 hadbm:Error 22171: A software package has already been registered with the package name test. |
HADB does not support heterogeneous paths across nodes in a database cluster. Make sure that the HADB server installation directory (--packagepath) is the same across all participating hosts.
If running the management agent on a host with multiple network interfaces, the createdomain command may fail if not all network interfaces are on the same subnet:
hadbm:Error 22020: The management agents could not establish a domain, please check that the hosts can communicate with UDP multicast. |
The management agents will (if not configured otherwise) use the "first" interface for UDP multicasts ("first" as defined by the result from java.net.NetworkInterface.getNetworkInterfaces()).
The best solution is to tell the management agent which subnet to use (set ma.server.mainternal.interfaces in the configuration file, e.g., ma.server.mainternal.interfaces=10.11.100.0). Alternatively one may configure the router between the subnets to route multicast packets (the management agent uses multicast address 228.8.8.8).
Before retrying with a new configuration of the management agents, you may have to clean up the management agent repository. Stop all agents in the domain, and delete all files and directories in the repository directory (identified by repository.dr.path in the management agent configuration file). This must be done on all hosts before restarting the agents with a new configuration file.
On Solaris 10 Opteron, starting, stopping or reconfiguring HADB using the hadbm command may fail or hang with one of the following errors:
hadbm:Error 22009: The command issued had no progress in the last 300 seconds. HADB-E-21070: The operation did not complete within the time limit, but has not been cancelled and may complete at a later time. |
This may happen if there are inconsistencies reading/writing to a file (nomandevice) which the clu_noman_srv process uses. This problem can be detected by looking for the following messages in the HADB history files:
n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Child process noman3 733 does not respond. n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Have not heard from it in 104.537454 sec. n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Child process noman3 733 did not start.
The following workaround is unverified, as the problem has not been reproduced manually. However, running this command for the affected node should solve the problem.
hadbm restartnode --level=clear nodeno dbname |
Note that all devices for the node will be reinitialized. You may have to stop the node before reinitializing it.
When starting on a host running Solaris 8 with several NIC cards installed, if there is a mixture of cards with IPv6 and IPv4 enabled, the management agent may terminate with the exception "IPV6_MULTICAST_IF failed."
Set the environment variable JAVA_OPTIONS to -Djava.net.preferIPv4Stack=true; for example:
export JAVA_OPTIONS="-Djava.net.preferIPv4Stack=true" |
Alternatively, use Solaris 9 or later, which do not exhibit this problem.
There is a bug in the 64-bit version of Red Hat Enterprise Linux 3.0 that makes the clu_trans_srv process end up in an uninterruptible mode when performing asynchronous I/O. This means that kill -9 does not work and the operating system must be rebooted.
Use a 32-bit version of Red Hat Enterprise Linux 3.0.
Capital letters in passwords are converted to lowercase when the password is stored in hadb.
Do not use passwords containing capital letters.
When downgrading to a previous HADB version, the management agent may fail with different error codes.
It is possible to downgrade the HADB database, however the management agent cannot be downgraded if there changes have been made in the repository objects. After a downgrade, you must keep use the management agent from the latest HADB version.
Regarding install/removal of HADB c package (Solaris: SUNWhadbc, Linux: sun-hadb-c) version <m.n.u-p>, the symlink /opt/SUNWhadb/<m> is never touched once it exists. Thus, it is possible that an orphaned symlink will exist.
Delete the symlink before install or after uninstall unless in use.
On Solaris 10, stopping a management agent by using the ma-initd script in a global zone stops the management agent in the local zone as well.
Do not install the management agent both in the global and local zone.
Sometimes, a resource contention problem on the server may cause a management client to become disconnected, When reconnecting, a misleading error message "hadbm:Error 22184: A password is required to connect to the management agent" may be returned.
Sometimes, a resource contention problem on the server may cause a management client to become disconnected, When reconnecting, a misleading error message "hadbm:Error 22184: A password is required to connect to the management agent" may be returned.
Check if there is a resource problem on the server, take proper action (e.g., add more resources), and retry the operation.
Installing with Java Enterprise System (as root) does not permit non-root users to manage HADB.
Always login as root to manage HADB.
Special use interfaces with IP addresses like 0.0.0.0 should not be registered as valid interfaces to be used for HADB nodes in the Management Agent. Registering such interfaces may cause problems if HADB nodes are set up on these interfaces by means of a user issuing a hadbm create command using host names instead of IP addresses. The nodes will then be unable to communicate, causing the create command to hang.
When using hadbm create on hosts with multiple interfaces, always specify the IP addresses explicitly using DDN notation.
On the Windows platform, with certain configurations and loads, there may be a large number of reassembly failures in the operating system. The problem has been seen with configurations of more than twenty nodes when running several table scans (select *) in parallel. The symptoms may be that transactions abort frequently, repair or recovery may take a long time to complete, and there may be frequent timeouts in various parts of the system.
To fix the problem, the Windows registry variable HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters can be set to a value higher than the default 100. It is recommended that you increase this value to 0x1000 (4096). For more information, see. article 811003 from the Microsoft support pages.
Cookies with a path equal to “/” interfere with the cookies of a highly available web application deployed at a context root other than “/” that uses in-memory replication as its persistence type, making it impossible for the highly available web application to maintain any HTTP session state. One common scenario where this may happen is when using the same browser to access both the Admin GUI (which is deployed at “/”) and the highly available web application.
Access the web application deployed at “/” from a different browser.
SASL32.DLL and ZLIB.DLL are required files for Load Balancer to work with Windows IIS 6. These files are currently not available under as-install/lib.
Copy the two DLL files manually to as-install/lib. These files can be downloaded from:
http://download.java.net/javaee5/external/OS/aslb/jars/ |
Where OS represents the desired platform, and can be one of the following values:
SunOS
SunOS_X86
Linux
WINNT
Two issues arise when installing or uninstalling Enterprise Server with High Availability packages in a Global Zone:
HA packages get installed in all zones, which may not be desirable.
When uninstalling, HA, MQ, JDK packages get removed from all zones, which may not be desirable.
This problem does not occur when installing or uninstalling from a root local zone.
Perform installation and uninstallations from a local root zone rather than a global zone.
Highly available web applications deployed at “/” are unable to maintain any HTTP sessions when using in-memory replication as their persistence type.
Deploy highly available web applications that use in-memory replication as their persistence type to a context root other than “/”. If you want to make such a web application available at “/”, you may designate it as the default-web-module of the virtual server to which the web application has been deployed.
During Enterprise Server Load Balancer installation for Apache on Solaris, the installer updates LD_LIBRARY_PATH in the apachectl script. However, the installer does not correctly write the /usr/lib/mps path. On Solaris, the Apache security instance will not start without this path in LD_LIBRARY_PATH.
This issue exists only on Solaris platforms. To work around the issue, add /opt/SUNWappserver/appserver/lib/lbplugin/lib to your LD_LIBRARY_PATH.
The Enable LoadBalance button is always enabled on the Clustered/Instance general page, regardless of what is saved in domain.xml.
For clustered instances, select Instances tab, and then click the Quiesce action from the table pull-down.
For standalone instances, make sure the instance is running, and then click the Quiesce button on instance General screen.
(Solaris only) After installing Enterprise Server v2.1.1 on SPARC Solaris 10 with HADB, you may receive the following error after starting Enterprise Server and then attempting to install JES 5 UR1 with Registry Server:
Dependency Error: Installation can not proceed because the version of HA Session Store 4.4.3 detected on this host is incomplete , and a compatible version is required by Servervice Registry Deployment Support. |
It is not possible to install Registry Server from JES 5 UR1 with Enterprise Server IFR on Solaris machines. The Registry Server packages have to be installed manually using the pkgadd command from the following JES5 UR1 distribution directory:
path/OS/Products/registry-svr/Packages |
(Internet Explorer 6 and 7 only) When attempting to export the Load Balancer configuration file (loadbalancer.xml) from Internet Explorer 6 or 7, the browser displays an error message saying that the sun-loadbalancer_1_2.dtd DTD file cannot be located.
To save the file, use the following workaround:
Click Export on the Load Balancer page in Internet Explorer.
The “XML page cannot be displayed” message is displayed.
Click the error frame, and then choose File->Save As from the Internet Explorer.
Save the loadbalancer.xml file to the directory of your choice.
This section describes known installation issues and associated solutions.
The image on the left-hand side of the installer shows an older product version instead of v2.1.1.
None.
On OpenSolaris 2008.11, when you attempt to start the domain with the asadmin start-domain command, the following error message is displayed:
Timeout waiting for domain domain1 to go to starting state. CLI156 Could not start the domain domain1. |
The domain has started successfully. Correct the time and date after rebooting the machine.
Installation of Enterprise Server v2.1.1 Patch 7 with the enterprise profile does not work on any 64–bit platform.
None. Installation with the enterprise profile is not supported on any 64-bit platform in Enterprise Server v2.1.1 Patch 7.
Installation fails on 64–bit systems that have 64–bit JDK because the installer tries to use the 64–bit JDK.
If you are installing Sun GlassFish Enterprise Server on a 64–bit system, download the 32–bit JDK and use it to install Sun GlassFish Enterprise Server on your 64–bit machine. You will need to use the following command: ./distribution_filename —javahome path to 32–bit JDK location
After installation, to ensure that Sun GlassFish Enterprise Server uses a 64–bit JDK, edit the value of the AS_JAVA variable in the asenv.conf file to point to the 64–bit JDK installation.
This problem has been observed on systems running Linux with the environment variable, MALLOC_CHECK_, set to 2.
Set the environment variable, MALLOC_CHECK_ to 0. Run one of the following commands:
For Bourne shell:
MALLOC_CHECK_=0; export MALLOC_CHECK_ |
For bash shell:
export MALLOC_CHECK_=0 |
For csh, tcsh shell:
setenv MALLOC_CHECK_ 0 |
This problem has been observed on several Linux systems. It is most common on Java Desktop System 2 but has also been observed on Linux Red Hat distributions.
After clicking the "Finish" button on the last installer screen, the installer fails to launch a browser window containing the product About page or product registration page, and hangs indefinitely, not returning the command prompt.
Exit the installer by pressing Ctrl+C in the terminal window in which the installer was started. After doing this, browser window containing product About page or registration page will sometimes be launched, but if it does not show up, start the browser and enter following URL in order to review About page:
file://as-install/docs-ee/about.html |
If you also selected the installation option to register the product, follow the link to registration page available on product About page.
On Windows, immediately after installation, the Message Queue broker fails on startup with a message saying the directory drive:\as\domains\domain1\imq does not exist.
Note that if the broker is started after starting domain1, the directory will be created by the Application Server and the problem will not occur.
Create the var_home_dir_location before creating the broker:
$imqbrokerd -varhome var_home_dir_location |
For example:
$imqbrokerd -varhome D:\as\domains\domain1\imq |
If the Enterprise Server productregistry file contains shared component configurations, an Enterprise Server uninstallation procedure does not update the productregistry file correctly, and you will not be able to use silent mode in a subsequent installation unless the productregistry file is renamed or removed. Leaving the shared components entries in the productregistry file intact is by design, but it leads to confusion with subsequent silent installs.
After a successful uninstallation is reported back through uninstall log files, delete the productregistry file prior to running a subsequent installation. To verify that a previous uninstallation has completed successfully, look for a appserv_uninstall.class file in as-install. This file will not be present if the uninstallation was successful.
Do not delete the productregistry if the uninstallation was not successful.
The productregistry file is located in /var/sadm/install on Solaris and /var/tmp on Linux.
When installing Enterprise Server in a sparse local zone, the installation fails if Message Queue (MQ) is not installed first. The installer attempts to install MQ, and then the whole installation fails.
MQ must be manually installed in the global zone before installing Enterprise Server in a sparse local zone. There are two work-arounds for this issue:
Install MQ 4.1 manually in the global zone from the same media on which Enterprise Server IFR installation is located to get the latest MQ packages.
Use the installer that corresponds to your platform:
mq4_1-installer-SunOS.zip mq4_1-installer-SunOS_X86.zip mq4_1-installer-Linux_X86.zip mq4_1-installer-WINNT.zip |
Unzip the bits and run the installer.
The installer will be in the mq4_1-installer directory.
Install any component of IFR installation in global zone. This action would check the version of MQ in GZ and if required upgrade it to the one bundled in Enterprise Server IFR. Even Selecting and Installing the Sample Applications component upgrades MQ to IFR version.
Run the Enterprise Server installation in the global zone, but select only the sample components.
The sample component installation also installs MQ and Enterprise Server shared components in all zones.
Run the Enterprise Server installation again, this time in the local sparse zone.
Installation should complete without any problems.
When running the Enterprise Server IFR installer with the —console option (command-line mode), you are prompted:
Do you want to upgrade from previous Application Server version? |
Unfortunately, the IFR installer does not support such upgrades, and so this prompt is erroneous. If you answer yes to the prompt, the installation proceeds normally, but no indication that a complete installation was performed, rather than an upgrade.
Use the upgrade tool if you want to upgrade your Enterprise Server installation.
The following exceptions might be thrown:
#|2008-11-19T01:44:37.422+0530|SEVERE|sun-appserver9.1|org.apache.catalina.session.ManagerBase|_ThreadID=17;_ThreadName=pool-1-thread-3;_Req uestID=cc0ddf54-a42e-400a-9788-e30d79a25d88;|PWC2768: IOException while loading persisted sessions: java.io.InvalidClassException: org.apache .catalina.session.StandardSession; local class incompatible: stream classdesc serialVersionUID = 8647852380089530442, local class serialVersi onUID = -8515037662877107054 java.io.InvalidClassException: org.apache.catalina.session.StandardSession; local class incompatible: stream classdesc serialVersionUID = 864 7852380089530442, local class serialVersionUID = -8515037662877107054..... .....
After upgrade is done and the upgrade domain is started, these exceptions can be ignored if they occur.
When using the Administration Console to create any resource, use the Targets tab to specify the server as the target. If you use the command line or an asant target, the server is the default target, no further action is required.
If the java.util.Arrays.asList() API is used to convert an Object[] to Collection, the JDK returns an implementation of java.util.ArrayList that is not cloneable. This results in the following exception:
The method invocation of the method [protected native java.lang.Object java.lang.Object.clone() throws java.lang.CloneNotSupportedException] on the object [[pkg.A id = xxx]], of class [class java.util.Arrays$ArrayList], triggered an exception. Internal Exception: java.lang.reflect.InvocationTargetException Target Invocation Exception: java.lang.CloneNotSupportedException: java.util.Arrays$ArrayList |
This issue is tracked at http://java.net/jira/browse/GLASSFISH-556.
Create another collection using its constructor; for example:
myCollection = new ArrayList(java.util.Arrays.asList(a)) |
An attempt to insert an entity that uses GenerationType.IDENTITY fails when the DataDirect driver is used with SyBase. The attempt fails because the DataDirect driver creates a stored procedure for every parameterized prepared statement.
In the domain.xml file, set the property PrepareMethod=direct on the corresponding data source.
This section describes known lifecycle management issues and associated solutions.
After setting the ejb-timer-service property minimum-delivery-interval to 9000, an attempt to set the ejb-timer-service property redelivery-interval-in-mills to 7000 causes the set command to fail with the following error:
[echo] Doing admin task set [exec] [Attribute(id=redelivery-interval-internal-in-millis) : Redelivery-Interval (7,000) should be greater than or equal to Minimum-delivery-interval- in-millis (9,000)] [exec] CLI137 Command set failed. |
minimum-delivery-interval is the minimal interval duration between deliveries of the same periodic timer.
redelivery-interval-in-mills is the time the timer service will wait after a failed ejbTimeout before attempting redelivery.
The problem is that the logic that relates the redelivery interval property to the minimum delivery property is incorrect and prevents you from using the GUI or the CLI to set any value where the minimum delivery interval is greater than redelivery interval.
The minimum-delivery-interval-in-millis must always be set equal to or higher than ejb-timer-service property redelivery-interval-in-millis. The problem is that there is an erroneous validation check in the aerver to verify that the value for redelivery-interval-in-millis is greater than the value for minimum-delivery-interval-in-millis.
Use the default values for these properties, as follows:
minimum-delivery-interval(default)=7000 redelivery-interval-in-millis(default)=5000 |
Values other than these defaults will generate an error.
If you are trying to view the JMS Physical Destinations using the default-config, you will see an error message.
This is expected behavior. In Enterprise Server, default-config is a template of configuration information and hence JMS operations (such as list and create) cannot be executed for the default-config. These JMS operations can, however, be executed for the configurations of your cluster or standalone instances.
(Windows 2003 only) There are memory leaks on Windows 2003 systems when performing rich access functions. The problem occurs because the Win32 nonpaged pool keeps growing, eventually bringing down the entire TCP/IP stack. Once the failure happens, the TCP/IP stack is left in an recoverable state, and the only way restore it is by rebooting the Windows 2003 system.
There are two workarounds to this issue:
Use Grizzly blocking mode by configuring the domain.xml http-listener attribute, blocking-enabled="true" or add the following http-listener property:
<property name="blocking" value="true"/> |
Use Windows Vista or Windows XP.
This section describes known logging issues and solutions.
Setting the java.security.debug option for the JVM will cause the server instance startup to freeze with a deadlock; for example, setting the following in domain.xml causes the problem:
<jvm-options>-Djava.security.debug=access,failure</jvm-options> |
None at this time. Please avoid setting this flag.
This section describes known Java message queue issues and associated solutions.
If you configure JMS to be REMOTE, Enterprise Server fails to start if the MQ broker is not started.
Set the following JVM option as follows: com.sun.enterprise.jms.CONNECT_MQ_LAZILY=true. After setting this JVM option, you can start Enterprise Server if the MQ broker is not started. However, it is recommended that you start MQ before starting the server.
Failures to reconnect in timing-dependent scenarios can be caused by several problems.
You can work around these problems by:
Restarting the brokers involved
Restarting the instances involved
After creating a domain with a cluster profile on a Linux system, you may encounter a java.lang.OutOfMemoryError: Java heap space error, and the server instance may fail to restart because the MQ broker does not start. The system never recovers after this condition. The problem is a misconfigured /etc/hosts file; specifically, the server host name is pointing to the loopback address 127.0.0.1.
By design, an MQ broker cluster cannot start with the network device configured to point to the loopback address. This is not a bug. The solution is to make sure that the /etc/hosts file for the Enterprise Server host does not point to 127.0.0.1.
During server startup, the server checks the Message Queue version. If the Message Queue version is incorrect, then the server upgrades using the imqjmsra.jar. This upgrade JAR and its classes will not be available to the server until the next restart. This situation only occurs if Message Queue is upgraded alone, or if Application Server is patched alone. A side effect of this situation is that sometimes server does not start.
Both Message Queue and Enterprise Server need to be maintained at the same patch level, or restart the server.
This section describes known monitoring issues and associated solutions.
When viewing the monitoring statistics of some elements of the HTTP Service, some values presented do not correspond to current values or are always 0. Specifically, the following HTTP Service statistics do not present information applicable to the Enterprise Server, and should be ignored:
http-service
load1MinuteAverage
load5MinuteAverage
load15MinuteAverage
rateBytesTransmitted
rateBytesReceived
pwc-thread-pool (the element)
These monitors will be removed in future releases and replaced with more appropriate information.
Many exceptions are thrown when the JNDI browser is opened from the Admin GUI.
None at this time.
This section describes known issues and associated solutions related to the packaging of the software code for the Enterprise Server product.
The monitor command cannot be run on the AIX operating system because the libcliutil.so library file is not packaged in Enterprise Server.
Change to the directory to where you downloaded the appserv-native-9.1.1-b16a.jar file.
prompt% cd destination-dir |
Extract the contents of the appserv-native-9.1.1-b16a.jar file.
prompt% jar xf appserv-native-9.1.1-b16a.jar |
Copy the libcliutil.so file to the as-install/lib directory.
prompt% cp libcliutil.so as-install/lib |
This section describes known issues and associated solutions related to the sample code included with the Enterprise Server product.
After installing Sun GlassFish Enterprise Server, the installation log files show that some files for samples are not created.
No known solution. This problem does not affect basic samples functionality.
On Windows, after upgrading to Enterprise Server v2.1.1, the samples and JES5 portal samples compete on Derby port 1527. Specifically, Enterprise Server v2.1.1 automatically starts JavaDB on port 0.0.0.0:1527 with APP:APP, however the JES5 Portal JavaDB wants to bind to hostnameIP:1527 with portal:portal.
This bug describes an issue that was already seen for JES 5, Bug 6472173. The workaround for bug 6472173 is documented in the Sun Java Enterprise System 5 Installation Guide for Microsoft Windows on http://docs.sun.com.
Start the Derby database using the following command:
JES-installation-dir\appserver\bin\asadmin start-database --dbhome JES-installation-dir\portal\data\derby |
This section describes known issues and associated solutions related to Enterprise Server and web application security and certificates.
The CA certificate bundled with Sun GlassFish Enterprise Server v2.1.1 has expired since Jan 08, 2010. Hence some SEVERE messages may be observed while starting the domain.
Remove the expired certificate from the keystore. To remove the certificate from the JKS keystore, use the following command,
keytool delete -alias verisignserverca -keystore domain-dir/config/cacerts.jks
To remove the certificate from the NSS keystore, use the following command,
certutil -D -n verisignserverca -d domain-dir/config
A JDK bug (See: https://jdk6.dev.java.net/issues/show_bug.cgi?id=23) in JDK6 Sun PKCS11 Provider could cause an OutOfMemoryError when running certain SSL scenarios under heavy stress.
If you run into this issue, remove sun.security.pkcs11.SunPKCS11 provider from the java.security file in your JRE installation.
On the AIX platform, dynamic encryption for the determination of an encryption key for a response is failing. The failure occurs during the validation of the certificate on the server side.
In response to the failure, the following error messages are written to the server's log file server.log:
Unable to validate certificate |
Error occurred while resolving key information com.sun.xml.wss.impl.WssSoapFaultException: Certificate validation failed |
Install Metro 1.1 on Enterprise Server v2.1.1
A method in an enterprise bean whose run-as, or propagated, security identity is defined by using the @RunAs annotation attempts to invoke a method in another enterprise bean. If no run-as principal is defined in the sun-ejb-jar.xml deployment descriptor file, the attempt might fail with a javax.ejb.AccessLocalException exception.
javax.ejb.AccessLocalException: Client not authorized for this invocation. |
In the sun-ejb-jar.xml deployment descriptor file, define in the principal-name element the principal name for which the run-as role specified.
SSL termination is not working; when Load Balancer (Hardware) is configured for SSL termination, the Enterprise Server changes the protocol from https to http during redirection.
Add a software load balancer between the hardware load balancer and the Enterprise Server.
Because of a JVM bug, there is a leak issue with some JDK versions when security-enabled is set to true on an HTTP listener. Specifically, the steps to reproduce this bug are as follows:
Set security-enabled to true on the HTTP listener:
<http-listener acceptor-threads="1" address="0.0.0.0" blocking-enabled="false" default-virtual-server="server" enabled="true" family="inet" id=" http-listener-1" port="8080" security-enabled="true" server-name="" xpowered-by="true"> |
Comment out stopping domain at the end of quicklook tests.
Run quicklook tests.
Check socket usage:
netstat -an | grep 8080 |
The following are shown to be in use:
*.8080 *.* 0 0 49152 0 LISTEN *.8080 *.* 0 0 49152 0 BOUND |
This issue is tracked on the GlassFish site at http://java.net/jira/browse/GLASSFISH-849.
Upgrade to the latest JDK version.
This section describes known upgrade issues and associated solutions.
This problem has been observed on several Linux systems, it is most common on Java Desktop System 2 but has also been observed on Red Hat distributions.
After clicking the "Start Upgrade Tool" button on the final installer screen, the installer fails to launch the upgrade tool to complete the upgrade process, and hangs indefinitely, not returning the command prompt.
This issue is not encountered if command line installation mode is used to run upgrade in place.
If you ran upgrade in place in GUI mode and encountered this problem, exit the installer by pressing Ctrl+C in the terminal window in which the installer was started.
Start upgrade tool from the terminal window, using following command:
as-install/bin/asupgrade --source as-install/domains --target as-install --adminuser adminuser --adminpassword adminpassword --masterpassword changeit |
adminuser and adminpassword should match the values used for the installation you are upgrading.
When the upgrade tool completes the upgrade process you can also start the browser and enter following URL in order to review About page:
file://as-install/docs-ee/about.html |
If you also selected the installation option to register the product, follow the link to registration page available on product About page.
Remove the following entries from the target domain.xml (after the upgrade) and restart the server:
<jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot} /config/keystore.jks</jvm-options>- <jvm-options>Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot} /config/cacerts.jks</jvm-options>
When upgrading from Enterprise Server 8.0PE to v2.1.1, an error is thrown saying the server does not have system connector named null, and invalid user information as seen in sbs-manual. Even after changing the hardcoded values, the same error message is seen.
You can only encounter this bug while upgrading from a 8.0 PE toEnterprise Server. The workaround is to upgrade to either 8.1, 8.2, or 9.0 and then upgrade to Enterprise Server.
When performing an inplace upgrade, in cases where there are multiple domains in the source, the installer invokes upgrade tool even though the process is killed. This happens when it is invoked in GUI mode.
Install inplace in the CLI mode, and exit when the installer prompts you to select the upgrade tool at the end of installation process. This does not delete any of the domains present in the domains directory. Upgrade tool should be manually invoked from the bin directory.
When installing inplace in GUI mode, make a backup of the domains present in the domains root to prevent losing any domains in the process. At the end of the installation process, exit when the installer prompts you to invoke the upgrade tool. Copy any backed up domains into the domains directory if they have been lost. Launch upgrade tool manually to do an upgrade.
When upgrading from AS 8.2, the master password from the 8.2 installation is not inherited in the target installation. This subsequently causes an authentication error at the next admin login.
The default admin password in Enterprise Server v2.1.1 is changeit. To avoid problems when logging in to the Enterprise Server after upgrading from 8.2, do one of the three following things:
Change the 8.2 admin password to changeit before performing the upgrade.
Do not accept the default admin password during the upgrade process, but instead explicitly enter the password you want to use.
Log in to Enterprise Server v2.1.1 with the default password, and then immediately change it.
When running the asupgrade GUI in a language other than English, the online help for the GUI is not localized for the selected non-English language.
None at the time. Online help is scheduled to be localized in all non-English target languages.
After a side-by-side upgrade of a configuration that contains multiple domains, only the node agents of the last processed domain are present. This issue occurs because Upgrade Tool removes and re-creates the nodeagents directory in the target each time Upgrade Tool processes a domain.
After processing each domain, create a zip file of the nodeagents directory.
When all domains have been processed, unzip the files that you created.
All node agents should now be present.
While performing in-place upgrade, the index.html file of a domain that already exists is not replaced. It might still show the old version of the server. This index.html file could be replaced by the index.html file from SGES_BASE.
SGES_BASE/lib/install/templates/ee/index.html DOMAIN_DIR/docroot/index.html |
This section describes known web container issues and associated solutions.
If you request precompilation of JSPs when you deploy an application on Windows, later attempts to undeploy that application or to redeploy it (or any application with the same module ID) will not work as expected. The problem is that JSP precompilation opens JAR files in your application but does not close them, and Windows prevents the undeployment from deleting those files or the redeployment from overwriting them.
Note that undeployment succeeds to a point, in that the application is logically removed from the Application Server. Also note that no error message is returned by the asadmin utility, but the application's directory and the locked jar files remain on the server. The server's log file will contain messages describing the failure to delete the files and the application's directory.
Attempts to redeploy the application after undeploying fail because the server tries to remove the existing files and directory, and these attempts also fail. This can happen if you try to deploy any application that uses the same module ID as the originally deployed application, because the server uses the module ID in choosing a directory name to hold the application's files.
Attempts to redeploy the application without undeploying it first will fail for the same reasons.
If you attempt to redeploy the application or deploy it after undeploying it, the asadmin utility returns an error similar to the one below.
An exception occurred while running the command. The exception message is: CLI171 Command deploy failed : Deploying application in domain failed; Cannot deploy. Module directory is locked and can't be deleted. |
If you specify --precompilejsps=false (the default setting) when you deploy an application, then this problem will not occur. Be aware that the first use of the application will trigger the JSP compilation, so the response time to the first request will be longer than for later requests.
Note also that if you do precompile, you should stop and restart the server before undeploying or redeploying the application. The shutdown frees the locked JAR files so the undeployment or redeployment after the restart can succeed.
The optional load-on-startup servlet element in a web.xml indicates that the associated servlet is to be loaded and initialized as part of the startup of the web application that declares it.
The optional content of this element is an integer indicating the order in which the servlet is to be loaded and initialized with respect to the web application's other servlets. An empty <load-on-startup> indicates that the order is irrelevant, as long as the servlet is loaded and initialized during the startup of its containing web application.
The Servlet 2.4 schema for web.xml no longer supports an empty <load-on-startup>, meaning that an integer must be specified when using a Servlet 2.4 based web.xml. If specifying an empty <load-on-startup>, as in <load-on-startup/>, the web.xml will fail validation against the Servlet 2.4 schema for web.xml, causing deployment of the web application to fail.
Backwards compatibility issue. Specifying an empty <load-on-startup> still works with Servlet 2.3 based web.xml.
Specify <load-on-startup>0</load-on-startup> when using a Servlet 2.4 based web.xml to indicate that servlet load order does not matter.
The JSP page is accessed but fails to compile, and the server log contains the error message "Unable to execute command" with the following stack trace:
at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher. exec(Execute.java:655) at org.apache.tools.ant.taskdefs.Execute. launch(Execute.java:416) at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:427) at org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter. executeExternalCompile(DefaultCompilerAdapter.java:448) at org.apache.tools.ant.taskdefs.compilers.JavacExternal.execute (JavacExternal.java:81) at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:842) at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682) at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:396)
Set the JSP compilation switch "fork" to "false."
This can be done either of two ways:
Globally, by setting the fork init parameter of the JspServlet in domain-dir/config/default-web.xml to false:
<servlet> <servlet-name>jsp</servlet-name> <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class> .... <init-param> <param-name>fork</param-name> <param-value>false</param-value> </init-param> .... </servlet> |
On a per-web application basis, by setting the fork JSP configuration property in sun-web.xml to false:
<sun-web-app> <jsp-config> <property name="fork" value="false" /> </jsp-config> </sun-web-app> |
Either setting will prevent ant from spawning a new process for javac compilation.
The Sun GlassFish Enterprise Server v2.1.1 adds support for the functionality provided by the auth-passthrough plugin function available with Sun GlassFish Enterprise Server Enterprise Edition 7.1. However, in Enterprise Server v2.1.1, the auth-passthrough plugin feature is configured differently.
The auth-passthrough plugin function in Enterprise Server Enterprise Edition 7.1 has been useful in two-tier deployment scenarios, where:
Application Server instance is protected by a second firewall behind the corporate firewall.
No client connections are permitted directly to the Application Server instance.
In such network architectures, a client connects to a front-end web server, which has been configured with the service-passthrough plugin function and forwards HTTP requests to the proxied Application Server instance for processing. The Application Server instance can only receive requests from the web server proxy, but never directly from any client hosts. As a result of this, any applications deployed on the proxied Application Server instance that query for client information, such as the client's IP address, will receive the proxy host IP, since that is the actual originating host of the relayed request.
In Application Server Enterprise Edition 7.1, the auth-passthrough plugin function could be configured on the proxied Application Server instance in order to make the remote client's information directly available to any applications deployed on it; as if the proxied Application Server instance had received the request directly, instead of via an intermediate web server running the service-passthrough plugin.
In Enterprise Server v2.1.1, the auth-passthrough feature may be enabled by setting the authPassthroughEnabled property of the <http-service> element in domain.xml to TRUE, as follows:
<property name="authPassthroughEnabled" value="true"/> |
The same security considerations of the auth-passthrough plugin function in Application Server Enterprise Edition 7.1 also apply to the authPassthroughEnabled property in Enterprise Server v2.1.1. Since authPassthroughEnabled makes it possible to override information that may be used for authentication purposes (such as the IP address from which the request originated, or the SSL client certificate), it is essential that only trusted clients or servers be allowed to connect to an Enterprise Server v2.1.1 instance with authPassthroughEnabled set to TRUE. As a precautionary measure, it is recommended that only servers behind the corporate firewall should be configured with authPassthroughEnabled set to TRUE. A server that is accessible through the Internet must never be configured with authPassthroughEnabled set to TRUE.
Notice that in the scenario where a proxy web server has been configured with the service-passthrough plugin and forwards requests to an Enterprise Server instance with authPassthroughEnabled set to TRUE, SSL client authentication may be enabled on the web server proxy, and disabled on the proxied Enterprise Server instance. In this case, the proxied Enterprise Server instance will still treat the request as though it was authenticated via SSL, and provide the client's SSL certificate to any deployed applications requesting it.
This section describes known web server issues and associated solutions.
When Enterprise Server v2.1.1 is configured for load balancing with Web Server 7.0, Jroute cookies are no longer generated. The problem is that the default loadbalancer.xml file sets the rewrite-cookies property to false.
<property name="rewrite-cookies" value="false"/> |
Remove the rewrite-cookies property from loadbalancer.xml; that is, remove the line that reads:
<property name="rewrite-cookies" value="false"/> |
You may also find it necessary to modify the relaxVersionSemantics property in sun-web.xml. For more information, see Memory Replication & Multi-threaded Concurrent Access to HttpSessions.
Restart the Web Server after making either of these changes.
This issue only applies you are using the Sun GlassFish Web Server with Enterprise Server and Load Balancer on a Linux system. In such a case, after installing Enterprise Server and a load balancer, the Web Server may fail to start because libicui18n.so.2 and libicuuc.so.2 are in conflict. These libraries are present in both /opt/sun/private/lib and /opt/sun/appserver/lib.
The correct libraries to use are the ones in /opt/sun/appserver/lib because lbplugin is built against those libraries. Once you remove the two libraries from /opt/sun/private/lib, Web Server should start without error.
Alternatively, if you do not want to delete the libraries from /opt/sun/private/lib, you can instead put /opt/sun/appserver/lib before /opt/sun/private/lib in LD_LIBRARY_PATH in the Web Server startserv script; that is, replace:
# Add instance-specific information to LD_LIBRARY_PATH for Solaris and Linux LD_LIBRARY_PATH="${SERVER_LIB_PATH}:${SERVER_JVM_LIBPATH}:${LD_LIBRARY_PATH}: /opt/sun/appserver/lib:/opt/sun/appserver/lbplugin/lib"; export LD_LIBRARY_PATH
with:
# Add instance-specific information to LD_LIBRARY_PATH for Solaris and Linux LD_LIBRARY_PATH="/opt/sun/appserver/lib:/opt/sun/appserver/lbplugin/lib: ${SERVER_LIB_PATH}:${SERVER_JVM_LIBPATH}:${LD_LIBRARY_PATH}"; export LD_LIBRARY_PATH
This section describes known web container issues and associated solutions.
You may encounter a problem when running the JAX—WS tests with the JDK 1.6 included with the Java EE SDK b33d. The tests immediately abort with the following message:
[wsimport] Exception in thread "main" java.lang.NoClassDefFoundError: \ com/sun/tools/ws/WsImport |
This error occurs even though the webservices-tools.jar does contain com/sun/tools/ws/WsImport.class, com/sun/tools/ws/ant/WsImport.class, and com/sun/tools/ws/ant/WsImport2.class. Moreover, the same test workspace works without problem using the 1.5.0-10 JDK.
Copy the webservices-api.jar to $JAVA_HOME/jre/lib/endorsed before running the JAX-WS tests.
JAXR uses SAAJ to send soap messages to the registry. In the non-IFR case, the SAAJ impl classes are under lib/webservices-rt.jar. In the IFR case, the SAAJ classes are still under lib/webservices-rt.jar. In addition, saaj-impl.jar is located in the /usr/share/lib directory. This jar file is picked up by Enterprise Server and has precedence over classes from webservices-rt.jar. This jar file does not have the necessary security permissions to send soap messages to the Web services registry. The packaging should be modified to grant permissions to the jars under /usr/share/lib directory or not depend on the /usr/share/lib jars.
Add the following to the server.policy file:
grant codeBase "file:/usr/share/lib/saaj-impl.jar" { permission java.security.AllPermission; }; |
The wscompile ant task fails for JDK 6 Update 4. For each JAX-RPC API class, the following error message is displayed:
package package-name does not exist |
Before running the wscompile ant task, ensure that javaee.jar is specified in the class path, not j2ee.jar.