Administration

This section describes known administration issues and associated solutions.

The package-appclient script does not work if domain1 is not present (6171458)

Description

By default, there is a hard-coded value in $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.

Solution

Do one of the following:

1. Leave domain1 intact, and create your other domains around it.

2. Remove domain1 and replace the hard-coded value for domain1 in $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.

Cannot restore backed-up domain with another name (6196993)

Description

Mirroring of a domain on the same Application Server installation cannot be performed using the backup-domain and restore-domain commands because the domain cannot be restored using a different name than the original, even though the asadmin restore-domain command provides an option to rename the domain. Renaming the backed-up domain appears to succeed, but attempts to start the renamed domain fail because the entries in the domain configuration are not changed, and startserv and stopserv use the original domain name to set paths.

Solution

The domain name used for restore-domain must be the same as that used for the original backup-domain command. The backup-domain and restore-domain commands in Application Server 8.1 work only for backing up and restoring the same domain on the same machine.

Starting Application Server with additional JMX Agent is not supported (6200011)

Description

J2SE 1.4.x, 5.0, or later can be configured on the Application 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 Application Server Virtual Machine. An undesirable side-effect of this is that the administration functions are affected adversely, and the Application Server 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.

Solution

If using jconsole (or any other JMX-compliant client), consider reusing the standard JMX Connector Server that is started with Application 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 Java System Application Server 9.1 Administration Guide.

On UNIX, overly restrictive execute permissions on Application Server start and stop scripts (6206176)

Description

If you run the asadmin restore-domain command while logged in as user "A", the scripts will end up with permissions as 744 (rwxr--r--). If you subsequently attempt to start or stop a domain as user "B" (even if "B" is root), it will fail because the scripts are only executable for "A".

Solution

Change the permissions on the scripts:

chmod 755 appserv/domains/domain-name/bin/*

Load balancer configuration file does not get created with the endpoint URL of any web service (6236544, 6275436)

Description

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.

Solution

1. 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"/>

2. Replace context-root-name value with the context root name of the web service that was exposed as an EJB.

Application Server restart using sun-appserv-admin causes LoginException error (6288893)

Solution

1. Rename the existing <as_install>/bin/asant script to asant.bak.

2. Copy the asant.template file in <as_install>/lib/install/templates/ee (for SE/EE version) to the <as_install>/bin/ directory and rename the file asant.

3. Edit the newly copied <as_install>/bin/asant script, replacing the %CONFIG_HOME% token with <as_install>/config.

4. If there were any manual changes made to the original asant.bak file, merge them into the new asant script.

.asadmintruststore file not described in the Application Server documentation (6315957)

Description

The .asadmintruststore file is not described in the Application 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.

Solution

• If possible, the asadmin start-domain domain1 command should be run by 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 installing user to the home directory of the running user.

• 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.

Clustered instances fail to start due to a timeout in reaching the JMS broker (6523663)

Description

The default MQ integration mode for a Application Server cluster instance is LOCAL. When Application 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.

Solution

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 Application Server cluster starts up. See “Auto-clustering” in Section 4.1, Division iii of the one-pager at http://www.glassfishwiki.org/gfwiki/attach/OnePagersOrFunctionalSpecs/as-mq-integration-gfv2.txt for more information. The above functionality will not be available!

Using the command-line

Before You Begin

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.

1. Modify the cluster configuration, changing the JMS type to REMOTE.

   $AS91_HOME/bin/asadmin.bat set --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/password_file racluster.jms-service.type=REMOTE

2. Create a JMS host corresponding to the DAS JMS host.

   $AS91_HOME/bin/asadmin.bat create-jms-host --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/password_file --target racluster --mqhost localhost --mqport 7676 \ --mquser admin --mqpassword admin dashost

3. Set the default JMS host to be the DAS JMS host created in the previous step.

   $AS91_HOME/bin/asadmin.bat set --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/password_file racluster.jms-service.default-jms-host=dashost

Using the Admin GUI

1. Go to Configurations->cluster_name-config->Java Message Service->JMS Hosts.

2. Click New to create a new JMS host; name it dashost.

3. 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.

4. Navigate back to the Java Message Service tab, and change the JMS service type to REMOTE (default is LOCAL).

5. Choose dashost from the default-jms-host drop-down list.

6. Save the changes, and then start your node-agent or cluster.

Cannot display jmaki chart in Netscape 8.1.3, Mozilla 1.7 and Safari 2.0.4 browsers (6543014)

Description

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

Solution

Use a supported browser. Refer to Browsers for a list of browsers supported by Application Server 9.1.

Default ports changing in each AS major release (6566481)

Description

The default admin port has changed in each of the past three major Application 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

Solution

This is not a bug, but something to be aware of. The default admin port is just a recommendation. It is anticipated that future Application Server releases going forward will retain the default 4848 port.

On Windows: Application Server fails to start due to NSS initialization failure. (6618442)

Description

In some cases, Application Server (enterprise profile) might not start on Windows when PKCS11 fails to initialize.

Solution

Remove softokn3.dll from the Windows system path.