test

Sun Java System Application Server Enterprise Edition 8.2 Release Notes

Chapter 3 Known Issues and Limitations

This chapter describes known problems and associated workarounds for the Sun Java System Application Server Enterprise Edition 8.2 software. If a summary statement does not specify a particular platform, the problem applies to all platforms. This information is organized into the following sections:

Administration

This section describes known administration issues and associated solutions.

The package-appclient script does not work if domain1 is not present. (ID 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:

Installing the Load Balancing Plugin will overwrite an existing plugin. (ID 6172977)

Description

If you install the Load Balancing plugin against an installation of the Application Server that already has a Load Balancer plugin installed (for example, from 7.1EE), then the 8.2EE plugin will silently replace any existing Load Balancer, even if you have created a new server instance in which to run the plugin.

The plugin files are installed by default under the install_dir/plugins/lbplugin directory, which means that only one version of a plugin can be used with any one Application Server installation. Note that the console installer does display a message indicating that an uninstall is being performed, but this message can sometimes be easy to miss.

Solution

Not everyone will encounter this problem. If you do encounter the problem, remove the old Application Server installation and do a fresh install rather than doing an upgrade installation.

Several Changes in asadmin script in JES3 Application Server 8.2 compared to JES2 AS7 (ID 6189433, 6189436)

There have been several changes made to the asadmin command in Application Server 8.2 compared to Application Server 7.x. For example, in 7.x, the command to start a server instance is:


asadmin start-instance

In 8.2, the equivalent command is:


asadmin start-domain --user admin domain1

Refer to the following documents for complete information about the latest asadmin command syntax:

Default ports changed in Application Server (ID 6198555)

Description

When upgrading to JES5/Application Server 8.2 from JES2/Application Server 7.x, you may experience incompatibilities or errors because the default ports have changed.

Solution

Refer to Other Requirements eariler in these notes for a listing of the default ports used in Application Server 8.2.

Cannot restore backed-up domain with another name. (ID 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.2 work only for backing up and restoring the same domain on the same machine.

Starting Application Server with additional JMX Agent is not supported. (ID 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 VM. An undesirable side-effect of this is that the administration functions are affected adversely, and the Application Server administration GUI and CLI 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 JMXServiceURL 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 8.2 Administration Guide.

On UNIX, overly restrictive execute permissions on Application Server start and stop scripts. (ID 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. (ID 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.

Java Home Setting inside Configuration does not take effect. (ID 6240672)

Description

Application Server domains/servers do not use the JDK pointed to by java-home attribute of java-config element of associated configuration.

Solution

The JDK used by the Application Server processes for all the domains in a given server installation is determined by the appserver-installation-dir/config/asenv.conf file. The property AS_JAVA in this file determines the JDK used and is set at the time of installation. If a different JDK is to be used by Application Server processes after the installation is completed, this value can be modified to point to another JDK. Note that all domains in this installation will be affected by this change.

Note –

Manual changes to asenv.conf file are not checked for validity and hence care should be exercised while changing them. Check the product documentation for minimum JDK version requirements when modifying the value for AS_JAVA.

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

Description

This problem is caused by a wrong value for %CONFIG_HOME%.

Solution

  1. Rename the existing 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.

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

Description

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

Domain fails to start when create-domain master password has special characters. (ID 6345947)

Description

Domain does not start when the domain's master password contains the percent (%) character.

Solution

The domain's master password should not contain a percent character (%). This applies when creating a new domain or changing the master password for an existing domain.

Load Balancer configuration changes in magnus.conf and obj.conf get overwritten (ID 6394181)

Description

After creating a secure http-listener and installing lbplugin, the magnus.conf and obj.conf files under the webserver_instance_dir/config are getting modifiedand the lbplugin contents are getting removed.

The installer modifies the magnus.conf and obj.conf configuration files on the Application Server as part of the installation of the load balancer plugin. If you log in to the Application Server admin console and try to manage the instance configuration for the instance on which the load balancer has been installed, the Application Server gives a warning message stating that it has detected a manual edit in the configuration. This warning is in fact referring to the changes made by the installer.

Solution

Verify that the changes made by the installer have not been overwritten.

Unable to start server instance on Txxxx series (Niagara) machines. (6860787)

Description

On T2000 and T5xxx machines there is possibility of JMX timeouts happening and preventing synchronization. The process of binding the JMX/JMX connection to the domain administration server (DAS) is bounded to 5 seconds. If the JMX connection plus the handshake takes more that 5 seconds, the JMX connection might be deemed a failure. This seems to happen more on a T-series machine, especially if the ORB+SSL initialization takes more time. However, this type of failure also happens in other machine/architecture situations.

Solution

  1. Increase the default values from 5 seconds. 10 seconds should be acceptable, unless the target DAS/network is extremely loaded. (2-4 seconds is the approximate subsystem setup overhead for the ORB/SSL/RMI connection even on a normal Sun v240.)

  2. In Application Server, use the flags (as JVM options) to set the JMX timeout of the synchronization, and other JMX connections if needed.

    • Set the timeout by using DJMXCONNECTOR_TIMEOUT_MILLISEC=<timeout>

    • Turn the timeout off and revert to the old behavior by using DDISABLE_JMXCON_THREAD=true

. As these are JDK options, the synchronization can happen as follows:

Apache and Load Balancer Plugin

This section describes known Apache Web server and load balancer plugin issues and associated solutions.

The High-Availability Administration Guide contains incorrect instructions for using openssl with Apache. (ID 6306784)

When compiling and building openssl, run the following commands:


cd openssl-0.9.7e
config
make

Also, for Apache 1.3, the directory name of the mod_ssl source will vary depending upon the release of Apache used. For example, for Apache 1.3.33, the name is mod_ssl-2.8.22-1.3.33.

The High-Availability Administration Guide does not contain instructions for using a certificate for Apache 2.0. (ID 6307976)

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.

Must start Apache Web Server as root. (ID 6308021)

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.

Addition to instructions for using openssl with Apache Web Server 2.0 on Solaris. (ID 6308043)

After installing Apache 2.0 and the load balancer plug-in, edit ssl.conf and sll-std.conf as follows:

Replace the line:

<VirtualHost _default_:9191>

with

<VirtualHost machine_name:9191>

Where machine_name is the name of your machine and 9191 is a security port number.

Application Client

This section describes known application client issues and associated solutions.

Library JAR packaged in Application Client Archive overwrites MANIFEST file. (ID 6193556)

Description

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.

Solution

None at this time.

Dynamic content technology such as CGI-bin and SHTML functionality not supported. (ID 6373043)

Description

Dynamic content technologies, such as CGI-bin and SHTML, are no longer supported.

Solution

Use JSP and Web service technologies instead.

Bundled Sun JDBC Drivers

This section describes known bundled Sun JDBC driver issues and associated solutions.

Applications using the TRANSACTION_SERIALIZABLE isolation level with the bundled Sun driver for Microsoft SQL Server may hang when using a prepared statement to update if two parallel transactions are running and one of them is rolled back. (ID 6165970)

To set a desired isolation level for a connection, the corresponding connection pool must be created at that same isolation level. See the Sun Java System Application Server Enterprise Edition 8.2 Administration Guide for details about configuring connection pools.

PreparedStatement Errors. (ID 6170432)

Description 1

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.

Solution 1

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 Java System Application Server Enterprise Edition 8.2 Administration Guide for details about configuring connection pools.

Description 2

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.

Solution 2

Increase the DB2 server configuration parameter APPLHEAPSZ. A good value is 4096.

Description 3

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.

Solution 3

To set desired isolation level for a connection, the corresponding connection pool has to be created at that isolation level. See the Sun Java System Application Server Enterprise Edition 8.2 Administration Guide for instructions.

Problems setting isolation level with the bundled Sun driver for Sybase Adaptive Server. (ID 6189199)

Description

Solution

None at this time.

On Solaris 10 and Enterprise Linux 3.0, the Sun bundled Oracle JDBC driver does not allow the creation of a connection. (ID 6247468)

Set the following property on the JDBC connection pool when using the SUN JDBC oracle datasource (com.sun.sql.jdbcx.oracle.OracleDataSource):

<property name="serverType" value="dedicated"/>

The value of the property depends upon the way the Oracle server's listener is configured. If it is configured in the "shared" mode, the above value needs to change to "dedicated".

java.lang.SecurityException: Sealing violation exception (ID 6554602)

Description

Starting with JDBC 10.2 drivers, having more than one JDBC jar file in the CLASSPATH may result in a java.lang.SecurityException: Sealing violation exception.

Detailed explanation from Oracle is documented in the following Oracle Document ID:

Note:405446.1
Subject: JDBC Driver 10.2 Uses Sealed JAR files and May Cause SecurityException Sealing Violation

Solution

(Suggested by Oracle) Make sure that the CLASSPATH includes only one JDBC driver JAR file.

Connectors

This section describes known J2EE connector architecture issues and associated solutions.

After restarting a DAS instance, undeploying the connector module fails when cascade is set to false. (ID 6188343)

Description

In this scenario, a standalone or embedded connector module is deployed in DAS and connector connection pools, and resources are created for the deployed module. After restarting the DAS instance, undeploying the connector module fails when cascade is set to false with the following exception:

[#|2004-10-31T19:52:23.049-0800|INFO|sun-appserver-ee8.1|javax.enterprise.system .core|_ThreadID=14;|CORE5023: Error while unloading application [foo]|#]

Solution

Use cascaded undeploy (set the cascade option to true) for undeploying standalone and embedded connectors after restart of the DAS instance.

JMS create-jms-resource; CLI doesn't set the default values correctly (ID 6294018)

Description

Because you cannot specify the minimum pool size and maximum pool size when creating a new JMS resource from the command line with the asadmin create-jms-resource command, the asadmin command is supposed to create the resource using the default pool size values (minimum 8, maximum 32). However, this is not the case. Instead, creating the resource from the command line results in default minimum and maximum pool sizes of 1 and 250, respectively.

Solution

After creating a JMS resource from the command line, use the admin console to modify the minimum and maximum pool size values.

Documentation

This section describes known documentation issues and associated solutions.

Javadoc Inconsistencies. (Various IDs)

The Javadoc for several AMX interfaces and methods is either missing or incorrect:

Bundled ANT throws java.lang.NoClassDefFoundError. (ID 6265624)

Description

The following exception is thrown in thread main: java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher.

Solution

Use the bundled ANT for things outside the Application Server is not recommended.

Logging options documentation incorrect (ID 6463965)

The Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide incorrectly states the following about Log Options:

The Administration GUI provides the following two logging options:

  • Option 1 – Log stdout (System.out.print) content to the event log

  • Option 2 – Log stderr (System.err.print) content to the event log

These log options no longer exist in Application Server Enterprise Edition 8.2.

Conflicting information regarding HTTP file cache feature in Application Server 8.2 (ID 6474799)

The Application Server Enterprise Edition 8.2 documentation discusses an HTTP file caching feature, in HTTP File Cache in Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide. However, this feature was not included in Application Server Enterprise Edition 8.2. Note that this feature has been reintroduced in Application Server 9.0.

Documentation on getting a physical Connection from a wrapped Connection is no longer correct (ID 6486123)

As a result of other defects (possibly 6295215) the code provided in the Obtaining a Physical Connection from a Wrapped Connection in Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide section of Chapter 11, Using the JDBC API for Database Access, in Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide is not correct. Specifically, the line:


Connection drivercon = ds.getConnection(con);

should now read:


Connection drivercon = ((com.sun.gjc.spi.DataSource)ds).getConnection(con);

High Availability

This section describes known high availability database (HADB) issues and associated solutions.

HADB Configuration with Double Networks. (No ID)

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:

HADB Database Creation Fails. (No ID)

Creating a new database may fail with the following error, stating that too few shared memory segments are available:

Description

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.

Solution

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.

Shared memory segments locked and cannot be paged out. (ID 5052548)

Description

HADB 4.3-0.16 and later is configured to use Intimate Shared Memory when it creates and attaches to its shared memory segments (uses the SHM_SHARE_MMU flag). The use of this flag essentially locks the shared memory segments into physical memory and prevents them from being paged out. This can easily cause problems with installations on low end machines.

Therefore if a developer has a machine with 512MB of memory and plenty of swap space available when using Application Server7.0 EE, and then installed 7.1 EE or later, he or she will encounter problems configuring the default clsetup cluster (which creates two HADB nodes, each with a devicesize of 512, which results in there not being enough physical RAM to support the shared memory that both nodes require.

Solution

Make sure you have the recommended amount of memory when co-locating Application Server and HADB. See HADB Requirements and Supported Platforms for more information.

hadbm set does not check resource availability (disk and memory space). (ID 5091280)

Description

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.

Solution

Verify that there is enough free disk/memory space on all hosts before increasing any of the devicesize or buffersize configuration attributes.

Heterogeneous paths for packagepath not supported. (ID 5091349)

Description

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.

Solution

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.

createdomain may fail. (IDs 6173886, 6253132)

Description

If running the management agent on a host with multiple network interfaces, the create domain 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()).

Solution

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.

Directories need to be cleaned up after deleting an HADB instance. (ID 6190878)

Description

After deleting an HADB instance, subsequent attempts to create new instances with the configure-ha-cluster command fail. The problem is that old directories are left from the original HADB instance in ha_install_dir/rep/* and ha_install_dir/config/hadb/instance_name.

Solution

Be sure to manually delete these directories after deleting an HADB instance.

Starting, stopping, and reconfiguring HADB may fail or hang. (IDs 6230792, 6230415)

Description

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.

Solution

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.

The management agent terminates with the exception "IPV6_MULTICAST_IF failed". (ID 6232140)

Description

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

Solution

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.

clu_trans_srv cannot be interrupted. (ID 6249685)

Description

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.

Solution

Use a 32-bit version of Red Hat Enterprise Linux 3.0.

hadbm does not support passwords containing capital letters. (ID 6262824)

Description

Capital letters in passwords are converted to lowercase when the password is stored in hadb.

Solution

Do not use passwords containing capital letters.

Downgrading from HADB Version 4.4.2.5 to HADB Version 4.4.1.7 causes ma to fail with different error codes. (ID 6265419)

Description

When downgrading to a previous HADB version, the management agent may fail with different error codes.

Solution

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.

Install/removal and symlink preservation. (ID 6271063)

Description

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.

Solution

Delete the symlink before install or after uninstall unless in use.

Management agents in global and local zones may interfere. (ID 6273681)

Description

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.

Solution

Do not install the management agent both in the global and local zone.

hadbm/ma should give a better error message when a session object has timed out and deleted at MA. (ID 6275103)

Description

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.

Solution

Check if there is a resource problem on the server, take proper action (e.g., add more resources), and retry the operation.

Non-root users cannot manage HADB. (ID 6275319)

Description

Installing with Java Enterprise System (as root) does not permit non-root users to manage HADB.

Solution

Always login as root to manage HADB.

The Management Agent should not use special-use interfaces. (ID 6293912)

Description

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.

Solution

When using hadbm create on hosts with multiple interfaces, always specify the IP addresses explicitly using DDN notation.

Reassembly failures on Windows. (ID 6291562)

Description

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.

Solution

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.

When running hadbm start <db_name>, part of the inputted password is displayed without being masked. (ID 6303581, 6346059, 6307497)

Description

It is possible when a machine is under load that the masking mechanism fails and some characters from the password being entered are exposed. This poses a minor security risk, and the password should always be masked.

Solution

Put the passwords in their own password files (the method normally recommended since Application Server 8.1) and refer to these with either the --adminpassword or --dbpasswordfile options.

JES5 HADB installed in Global Zone not accessible from Sparse Local Zones (ID 6460979)

Description

When the Application Server is installed in a Solaris Global Zone to /usr/SUNWappserver, the HADB component installed with that Application Server instance will not be available in Sparse Local Zones.

The problem is that HADB is installed to /opt/SUNWhadb in the Global Zone, but this directory is not readable from Sparse Local Zones. Unfortunately, the HADB bundle in JES5 is not relocateable.

Solution

Because the Application Server HADB component is not relocatable, the HADB component must be installed separately in each Sparse Local Zone from which you want to access HADB.

Installation

This section describes known installation issues and associated solutions.

Installation shutdown hanging on some Linux systems after clicking the "Finish" button. (ID 5009728)

Description

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.

Solution

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://install_dir/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, the imq directory needs to be created during installation. (ID 6199697)

Description

On Windows, immediately after installing Application Server Enterprise Edition, 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.

Solution

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

Application Server cannot be set up on RHLAS 3.0 and RHLAS 4.0 without compat-libstdc++. (ID 6396102)

Description

Installing Application Server Enterprise Edition 8.2 on a Red Hat Linux Advanced Server (RHLAS) 3.0 or 4.0 system will fail if the compat-libstdc++ library is not already installed on the system. Application Server requires t he compat-libstdc++ library on RHLAS systems, but this library is not installed by default. Note that this is only a problem on RHLAS systems.

Solution

Download and install the compat-libstdc++ RPM from http://rpm.pbone.net/index.php3/stat/4/idpl/843376/com/compat-libstdc++-7.3-2.96.118.i386.rpm.html before installing Application Server software.

lbplugin (libpassthrough.so) can not be used when server is running in 64-bit mode (ID 6480952)

Description

When running Application Server Enterprise Edition 8.2 with Web Server 7.0 in 64–bit mode, attempts to run a 64–bit version of the load balancer plugin fail with the following error:


failure: CORE2253: Error running Init function load-modules: dlopen 
of /export/home/mareks/opt/webserver7/plugins/lbplugin/bin/libpassthrough.so 
failed (ld.so.1: webservd: fatal: /export/home/mareks/opt/webserver7/plugins/
lbplugin/bin/libpassthrough.so: wrong ELF class: ELFCLASS32)
failure: server initialization failed

The problem is that there is no 64–bit load balancer plugin for Application Server Enterprise Edition 8.2, and the 64–bit Web Server requires 64–bit plugins.

You can determine whether Web Server is running in 64–bit or 32–bit mode by using the following command:


wadm get-config-prop --user=admin --config=xxx --password-file=xxx platform

Solution

No 64–bit load balancer is planned for Application Server Enterprise Edition 8.2. To work around the problem, either use the Web Server 7.0 reverse proxy feature, or configure Web Server 7.0 to run in 32–bit mode. Refer to the Web Server documentation for instructions.

Cannot run asant deploy: “The input line is too long” (Windows 2000) (ID 6485174)

Description

When installing Application Server 8.2 in the default location on Windows 2000, you may encounter the following error when running asant deploy:


$ C:/Sun/JavaES5/appserver/bin/asant deploy
The input line is too long.
The syntax of the command is incorrect.

The problem is that command lines in Windows 2000 can be no longer than 1000 characters, and depending on your system configuration, the default ANT_OPTS environment may cause the asant deploy command line to be long. This is only an issue on Windows 2000.

Solution

On Windows 2000, install Application Server in a very short directory path; for example, C:\JES5_AS).

JES5 b12, AS installation, in common.properties wrong server instance AppServer1 (ID 6485254)

Description

Using JES 5 b12 on Windows, if Application Server is selected at the top level of the select components installation panel, then the Node Agent subcomponent is also selected by default. The installation process subsequently creates a node agent and a server instance named AppServer1 that belongs to this node agent. This is the correct behavior.

However, if the Node Agent subcomponent is deselected, the installation process still creates an AppServer1 instance in the common.properties file for the domain; for example:


domain.name=domain1
appserver.instance=AppServer1

Subsequent attempts to deploy applications using asant will fail.

Solution

Edit the common.propeties file, replacing appserver.instance=AppServer1 with appserver.instance=server.

Documentation on getting a physical Connection from a wrapped Connection is no longer correct (ID 6486123)

As a result of other defects (possibly 6295215) the code provided in the Obtaining a Physical Connection from a Wrapped Connection in Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide section of Chapter 11, Using the JDBC API for Database Access, in Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide is not correct. Specifically, the line:


Connection drivercon = ds.getConnection(con);

should now read:


Connection drivercon = ((com.sun.gjc.spi.DataSource)ds).getConnection(con);

Application Server does not support NFS. (6396045)

In this version of the software, Application Server does not support Network File System (NFS).

Solution

None.

J2EE Tutorial

To run the J2EE 1.4 Tutorial on the Sun Java System Application Server Enterprise Edition 8.2 perform these tasks:

Lifecycle Management

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: (ID 6193449)

Description

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

Solution

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.

Logging

This section describes known logging issues and solutions.

Setting debug statement for access.failure causes hanging in Application Server startup. (ID 6180095)

Description

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\>

Solution

None at this time. Please avoid setting this flag.

Logging location/Instance location have changed for JES3 Application Server. (ID 6189409)

Default logging and server instance locations have changed in Sun Java System 8.2 compared to 7.x.

For more information, refer to the Sun Java System Application Server Enterprise Edition 8.2 Administration Guide or the Sun Java System Application Server Enterprise Edition 8.2 Upgrade and Migration Guide.

Message Queue

This section describes known Java message queue issues and associated solutions.

JMS reconnection does not successfully complete in certain cases that are timing dependent. (IDs 6173308, 6189645, 6198481, 6199510, 6208728)

Description

Failures to reconnect in timing-dependent scenarios can be caused by several problems.

Solution

You can work around these problems by:

Asynchronous message listener behavior changed in appclient from 8.0 to 8.1 Update 2. (ID 6198465)

Description

Due to a recent change, when an asynchronous message listener is the only live thread in the app-client container, the remaining appclient virtual machine exists as a daemon. This behavior is a regression for past applications that perform asynchronous receives in ACC. This problem affects application clients that set a JMS message listener and exit the main thread.

Solution

Do not exit the main thread. Wait for the message listener to notify the main thread before terminating the main thread.

Monitoring

This section describes known monitoring issues and associated solutions.

Cannot change connector service and connector connection pool monitoring level. (ID 6089026)

Description

Using the Monitoring Level setting page, if you change either the Connector Service or Connector Connection Pool monitoring level to LOW or HIGH and then save, both are not changed in the domain.xml file for the domain. However, if you change the JMS Service monitoring level to LOW or HIGH and save, the values for Connector Service and Connector Connection Pool are also changed at the same time. This problem does not occur when running the equivalent commands from the command line.

Solution

Only use the JMS Service component on the Monitoring Level page to change monitoring levels.

Some of the HTTP Service monitoring statistics do not present useful information and should be ignored. (ID 6174518)

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 Application Server, and should be ignored:

http-service

load1MinuteAverage

load5MinuteAverage

load15MinuteAverage

rateBytesTransmitted

rateBytesReceived

pwc-thread-pool (the element)

Monitoring MBean for an undeployed EJB module is not removed, even though all statistics under that monitoring name are moved. (ID 6191092)

Description

For example:


EJBModuleMonitorMap().size() = 1  eventhough ejb module is 
undeployed EJBModuleMonitor().getName() = sqe_ejb_s1_01

This true for both EJB modules and applications. Both programmatically (through MBean API) and through asadmin list/get, an empty monitoring MBean still exists.

Diagnostics


asadmin list -m "server.applications" shows the following output:
server.applications.MEjbApp
server.applications.__ejb_container_timer_app
server.applications.adminapp
server.applications.admingui
server.applications.com_sun_web_ui
server.applications._export_install_nov-11_domains_domain1_applications
_j2ee-modules_sqe_ejb_s1_01

You can look at statistics:


bin/asadmin list -m "server.applications._export_install_nov-11_domains
_domain1_applications_j2ee-modules_sqe_ejb_s1_01"
server.applications._export_install_nov-11_domains_domain1_applications_
j2ee-modules_sqe_ejb_s1_01.SQEMessage
server.applications._export_install_nov-11_domains_domain1_applications_
j2ee-modules_sqe_ejb_s1_01.TheGreeter

Once you undeploy:


_export_install_nov-11_domains_domain1_applications_j2ee-modules_sqe_
ejb_s1_01

If you do a list command, you still see the application:


asadmin list -m "server.applications"
server.applications.MEjbApp
server.applications.__ejb_container_timer_app
server.applications._export_install_nov-11_domains_domain1_applications_
j2ee-modules_sqe_ejb_s1_01
server.applications.adminapp
server.applications.admingui
server.applications.com_sun_web_ui

but it does not contain any monitoring statistics:


asadmin list -m "server.applications._export_install_nov-11_domains_
domain1_applications_j2ee-modules_sqe_ejb_s1_01"
Nothing to list at server.applications.-export-install-nov-11-domains-
domain1-applications-j2ee-modules-sqe-ejb-s1-01.

To get the valid names beginning with a string, use the wildcard (`*') character. For example, to list the names of all the monitorable entities that begin with server, use list "server.*".

Solution

This is harmless. Module can be safely redeployed with out any problems. The root monitoring Mbean is not removed, but it is empty.

Persistence

This section describes known and associated solutions related to Java Data Objects and Container-Managed Persistence

JDO76018: Unable to flush persistent instances due to circular dependencies. (ID 6500961)

Description

This exception is thrown if a chain of foreign key dependencies between instances modified (or created) in a transaction results in a circular dependency in the database.

Solution

Split the original set of operations into multiple transactions.

PointBase

This section describes known and associated solutions related to PointBase.

Setting the isolation levels on a connection pool for an application causes exceptions in PointBase. (ID 6184797)

Description

For a JDBC connection pool pointing to a PointBase database installation, setting the transaction-isolation-level pool attribute to any value other than the default (Connection.TRANSACTION_READ_COMMITTED) causes an exception. However, setting this same parameter to non-default values for pools pointing to other databases does not throw an exception.

Solution

For a JDBC connection pool pointing to a PointBase database installation, do not attempt to set the transaction-isolation-level.

PointBase throws an exception if a network server and embedded drivers are used together. (ID 6204925)

Description

The bundled PointBase sometimes throws an exception if the network server driver and the embedded driver are simultaneously used.

Solution

Use either the embedded driver or the network server driver, but not both.

Upgrade problem where the default PointBase database is overwritten. (IDs 6264969, 6275448)

Description

When upgrading to Application Server Enterprise Edition 8.2, the Update release patch overwrites the Pointbase default database.

Solution

Recreate or re-enter any scheme or data that existed prior to the upgrade. If you deployed applications with CMP beans with the generate table option, you must undeploy or redeploy the application to have the tables regenerated.

Samples

This section describes known and associated solutions related to the sample code included with the Application Server 8.2 product.

On Windows, setup-one-machine-cluster hangs but works on Solaris; mqfailover requires Ctrl+C to cancel and then must be re-run. (ID 6195092)

Description

From install_dir\samples\ee-samples\failover\apps\mqfailover\docs\index.html, if you run the following commands:

If you have already executed asant setup-one-machine-cluster-without-ha or asant setup-one-machine-cluster-with-ha for any other Enterprise Edition sample, then execute asant configure-mq otherwise execute asant setup-one-machine-cluster-and-configure-mq. In this case, the command appears to succeed:


start_nodeagent: [echo] Start the node agent cluster1-nodeagent 
[exec] Command start-node-agent executed successfully.

But then the system hangs indefinitely.

Solution

None at this time. This problem similarly affects all Enterprise Edition samples that use this ant target on Windows. A workaround is to Ctrl+C out of the hung process and then rerun it.

Documentation does not explicitly state that you need to create JMS resources before running the MQ Failover Sample Application following the asadmin deploy instructions. (ID 6198003)

Description

The error thrown is as follows:


/opt/SUNWappserver/domains/domain1/config/sun-acc.xml -name 
MQFailoverTestClient -textauth -user j2ee -password j2ee
Nov 18, 2004 10:50:17 PM com.sun.enterprise.naming.NamingManagerImpl 
bindObjects
SEVERE: NAM0006: JMS Destination object not found: jms/durable/TopicA
Nov 18, 2004 10:50:18 PM com.sun.enterprise.naming.NamingManagerImpl 
bindObjects
SEVERE: javax.naming.NameNotFoundException
javax.naming.NameNotFoundException

The documentation does not explicitly state that JMS resources must be manually created if manual deployment is done using asadmin deploy commands, and that the provided ant targets to deploy the sample application should be used.

Solution

Use the asant deploy target for the build.xml script, which creates the required JMS resources to run the application.

On Linux, a runtime error is displayed during certificate creation in web services/security samples. (ID 6198239)

Description

When deploying the install_dir/samples/webservices/security sample (basicSSl) on Linux, the certificate is not created and an error similar to the following is thrown:


generate_certs: [echo] ***Exporting certificate from NSS database 
[exec] Result: 1 [echo] ***Generating Java Keystore from generated 
certificate [exec] keytool error: java.lang.Exception: Input not an 
X.509 certificate [exec] Result: 1 [echo] ***Generating Java trust 
store from generated certificate [exec] keytool error: java.lang.
Exception: Input not an X.509 certificate [exec] Result: 1
.
.
.
generate_certs: [echo] ***Exporting server certificate from NSS database to 
a PKCS12 certificate file [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/
libnss3.so: version `NSS_3.9' not found (required by /opt/sun/appserver/lib/
pk12util) [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: 
version `NSS_3.6' not found (required by /opt/sun/appserver/lib/pk12util) 
[exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: version 
`NSS_3.7' not found (required by /opt/sun/appserver/lib/pk12util) [exec] 
Result: 1

The problem is that NSS libraries are in different locations on Linux installations than on Solaris installations. You need to make sure that the LD_LIBRARY_PATH points to the proper NSS libraries when deploying on Linux. Either set LD_LIBRARY_PATH in your environment, or set it in the install_dir/bin/asant shell wrapper script.

Solution

Do one of the following:

Sample documents missing after upgrade from 8.0 Platform Edition to 8.2 Enterprise Edition

Description

After updating from Application Server Platform Edition 8.0 to Application Server Enterprise Edition 8.2, you may receive an HTTP 404 “File not found” error when attempting to access the samples page.

Solution

Copy the sample documents from the 8.0 domains to the 8.2 domains.

Samples fail at runtime when run in Sparse local zone. (ID 6460970)

Description

If Application Server Enterprise Edition 8.2 is installed in a Solaris Global zone, and a Application Server domain is subsequently installed in a Sparse local zone, you may encounter problems running the sample applications if the file permissions for the domain in the Sparse zone are not sufficiently open during the deployment process.

Solution

During the deployment process, make sure the Application Server can retrieve the client JAR file, xmsClient.jar, and copy it into the sample location, (/usr/SUNWappserver/appserver/samples/webservices/security/ejb/apps/xms/xmsClient.jar. This is normally done automatically by the sample harness, but it will fail if the permissions on xmsClient.jar are not open.

Security

This section describes known issues and associated solutions related to Application Server and web application security and certificates.

Cannot run WebServiceSecurity applications on Enterprise Edition with J2SE 5.0. (ID 6183318)

Description

WebServiceSecurity applications cannot run with J2SE 5.0 because:

The J2SE team has filed “CR 6190389: Add support for the RSA-PKCS1 and RSA-OAEP wrap/unwrap mechanisms” for this bug.

Solution

Use J2SE 1.4.2 with any other JCE provider (not the one included by default). Note that hardware accelerator support will not be present in this configuration.

SSL termination is not working. (ID 6269102)

Description

When Load Balancer (Hardware) is configured for SSL termination, the Application Server changes the protocol from https to http during redirection.

Solution

Add a software load balancer between the hardware load balancer and the Application Server.

Upgrade Utility

This section describes known Upgrade utility issues and associated solutions.

Domains created in custom-path other than install_dir/domains directory are not upgraded directly while upgrading from Application Server Enterprise Edition 8 to Application Server Enterprise Edition 8.2. (ID 6165528)

Description

When running the Upgrade Utility and identifying the install_dir as the source installation directory, the upgrade process upgrades only those domains that are created under install_dir/domains directory. Domains created in other locations are not upgraded.

Solution

Before starting the upgrade process, copy all the domain directories from their different locations to the install_dir/domains directory.

The installer running “Upgrade in place” fails to start upgrade tool on some Linux systems after clicking on the “Start Upgrade Wizard” button. (6207337)

Description

This problem has been observed on several Linux systems, it is most common on Java Desktop System 2 but has also been observed on RedHat 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.

Solution

This issue is not encountered if command line installation mode is used to run upgrade in place.

ProcedureTo use command line installation mode

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

  2. Start upgrade tool from the terminal window, using following command:


    install_dir/bin/asupgrade --source install_dir/domains --target install_dir 
--adminuser adminuser--adminpassword adminpassword --masterpassword changeit

    adminuser and adminpassword should match the values used for the installation you are upgrading.

  3. 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://install_dir/docs/about.html

    If you also selected the installation option to register the product, follow the link to registration page available on product About page.

Self-signed certificate is not trusted during and after upgrade from 8.0 Platform Edition (PE) to 8.1 Enterprise Edition (EE) UR2. (ID 6296105)

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>

Port conflict after upgrading Application Server from JES2 to JES5

Description

When updating from Application Server 7.x to 8.2, you may encounter a port conflict between the old and new installations, most likely with the default ports of 8080 and 8181.

Solution

Change the ports used in Application Server 8.2 to resolve the port conflict.

Derby database used by samples script is created under wrong location. (ID 6377804)

Description

There are two aspects to this bug:

  1. When sample application setup scripts that use the Derby database are run, the Derby database gets created under the current directory or under <install_root>/bin.

  2. The sample build Ant script creates a password.txt file that stores the admin password file under current directory, which will not be writable in non-root and sparse zones scenarios.

Solution

  1. Derby database location – Use the --dbhome option with the start-database command to create the database at the value specified for --dbhome. For example, the following is the asadmin command syntax for start-database.


    start-database [--dbhost 0.0.0.0] [--dbport 1527] [--dbhome db_directory] [--echo=false] 
[--verbose=false]

  2. Location of the password.txt file – By design, the samples directory is expected to be writable since all the build commands include the creation of a password.txt file in that directory. Be sure to install a working copy of the samples in a writable location.

LoginException during upgrade from 8.0UR1PE to 8.2EE; upgrade process aborts (ID 6445419)

Description

This problem occurs when you run the upgrade installation using admin credentials other than the defaults.

Solution

When performing a side-by-side upgrade using the file based installer for 8.xPE to 8.2EE, use the following admin credentials for the new Application Server:

After performing the upgrade, you can change these passwords as needed.

Upgrade Tool fails to detect existing but invalid directory input for Source Directory field (ID 6460122)

Description

The Upgrade Tool fails to detect an existing but invalid directory input for Source Directory field, and gives the impression that directory configuration is correct.

The expectation is that an “Invalid directory” message should pop up when an incorrect path is entered for the Source Directory. An invalid directory message correctly pops up if /opt/SUNWappserverEE81UR2/ is entered for the Source Directory. However, when /opt/SUNWappserverEE81UR2/domains is entered, the tool continues with the upgrade process without warning, even though the path is invalid. This issue is similar to ID 6440710, except that the behavior differs depending on the input value.

Solution

When upgrading from Application Server 7 or 8.x to Application Server 8.2, the source directory must first be seeded with the value recommended in the documentation: domain root for in-place and domain directory for side-by-side upgrades.

Should invalidate Admin user/password name for semi-column (;) character (ID 6473341)

Description

The Application Server Enterprise Edition 8.2 installation does not allow special characters in the admin user name. Domain creation will fail if any special characters are used. Note, however, that the admin password can have special characters.

Solution

When upgrading from Application Server 7 to Application Server 8.2, verify that the admin user name does not contain any special characters.

Steps are missing for successful side-by-side upgrade. (6898037)

After upgrading from the older version of Application Server, verify the following under the upgraded installation (target-installation) location:

  1. Domain directory is in the source directory.

  2. Node agent is under node-agent directory as created in the source installation.


    cd target-installation/nodeagents/upgraded-node/agent/config

  3. Check the value of the agent.das.port property in the das.properties file before starting the node agent for the first time. Perform this check on the das.properties file on the upgraded installation. The value of the agent.das.port property must reflect the same value as the jmx-connector port defined in the domain.xml file on the source installation from which the domain is upgraded.

  4. Check the value of the agent.bind.status property in the nodeagent.properties file before starting the node agent for the first time. Perform this check on the nodeagent.properties file on target-installation. The value of the agent.bind.status property must BOUND. Edit the agent.bind.status property in the nodeagent.properties file on the source installation.

If you are upgrading side-by-side on Windows:

After upgrading the domain, if the upgraded-node has not been created under target-installation/nodeagents directory as in the source installation:

  1. Go to the target-installation/bin directory.

  2. Manually create the node agent that has the same name as in the source installation with the admin port specified in the create-node-agent command.

  3. Perform the additional steps above.

  4. Start the node agent.

Web Container

This section describes known web container issues and associated solutions.

On Windows, deploying an application using --precompilejsp=true can lock JAR files in the application, causing later undeployment or redeployment to fail. (ID 5004315)

Description

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.

Diagnostics

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.

Solution

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.

Unable to deploy WAR with Servlet 2.4-based web.xml that contains an empty <load-on-startup> element. (ID 6172006)

Description

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.

Solution

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.

Unable to compile JSP page on resource constrained servers. (ID 6184122)

Description

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)

Solution

Set the JSP compilation switch "fork" to "false."

This can be done either of two ways:

Either setting will prevent ant from spawning a new process for javac compilation.

Application Server does not support auth-passthrough Web Server 6.1 Add-On. (ID 6188932)

Description

The Sun Java System Application Server Enterprise Edition 8.2 adds support for the functionality provided by the auth-passthrough plugin function available with Sun Java System Application Server Enterprise Edition 7.1. However, in Application Server Enterprise Edition 8.2, the auth-passthrough plugin feature is configured differently.

The auth-passthrough plugin function in Application Server Enterprise Edition 7.1 has been useful in two-tier deployment scenarios, where:

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.

Solution

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 Application Server Enterprise Edition 8.2, 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 Application Server Enterprise Edition 8.2. 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 Application Server Enterprise Edition 8.2 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 Application Server 8.1 Update 2 instance with authPassthroughEnabled set to TRUE, SSL client authentication may be enabled on the web server proxy, and disabled on the proxied Application Server 8.1 Update 2 instance. In this case, the proxied Application Server 8.1 Update 2 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.

HTTP listener created with --enabled=false doesn't disable the listener. (ID 6190900)

Description

When an httplistener is created with the --enabled=false flag, the listener does not become disabled. The flag --enabled does not have any effect when used at the same time the listener is created.

Solution

Create the listener in an enable state, then disable it manually later.

Redeployment on Windows fails because verify_file_user_exists_common does not get executed. (ID 6490227)

Description

On Windows, when redeploying an application that creates a user before deployment, the create-file-user command may fail because verify_file_user_exists_common does not get executed (though it is called), and fails to notify that the user already exists. Execution of the deploy target halts at this point, and the deploy and undeploy fail.

Solution

First delete the file user(s) using the keydel target, and then execute deploy target again:


asant keydel
asant deploy