Sun Java System Application Server 7 Update 11 Release Notes

- Previous: Installation, Upgrade, and Uninstallation
- Next: Database Driver

### Behavior of Log Service create-console Attribute

On Microsoft Windows, when the `create-console` attribute of the `log-service` element in `server.xml` is set to true (the default setting), a window displaying the content of the server event log is displayed on the desktop. By design, closing this window does not result in a persistent termination of the App Server instance process. Closing the console window terminates the `appservd.exe` process, but the watchdog process (`appservd-wdog.exe`) immediately restarts the server instance process.

For developers, closing the event log window of an instance can be used as a means of quickly restarting the Application Server instance.

However, to stop the Application Server instance completely (along with the companion watchdog process), use one of the following methods:

- Administration interface—Start->Programs->Sun Java System Application Server 7->Stop Application Server

- Command-line interface—`asadmin stop-instance` `--local=true` instance name

  This is the local form of the `stop-instance` command. You can also use the remote form. See the `asadmin stop-instance` help for more information.

- Admin Console—Select server instance, and click Stop.

Using the Admin Console, you can enable/disable the console event log window by modifying the Create Console setting under the Logging tab of the App Server instance.

ID | Summary
--- | ---
4725893 | On Solaris, License expiration information is not shown. Affects Solaris SPARC evaluation licenses. Warning information relating to imminent expiration of license (within 14 days or less of expiration) would not be reported through the command-line interface and browser-based interfaces. The warnings would, however, appear in the server log files. Solution Check the server log files.
4738648 | JMS service/Sun Java System Application Server startup fails. If the JMS provider (Sun Java System Message Queue broker) has a large number of undelivered persistent messages, a Sun Java System Application Server initialization failure might occur due to following problems: As it tries to load all the pending messages, the MQ broker might run out of memory and abort. Solution Use more Java heap space for the MQ broker process. To do this, set the `Start Arguments` attribute of the JMS service to `-vmargs -Xmx256m.` The procedure for setting this attribute is described in the “Using the JMS Service” chapter of the Sun Java System Application Server Administrator’s Guide. If the MQ broker cannot complete its initialization sequence within a certain period of time, the Sun Java System Application Server times out and aborts. Solution Increase the value of the JMS service Start Timeout attribute. The procedure for setting this attribute is described in the “Using the JMS Service” chapter of the Sun Java System Application Server Administrator’s Guide.
4762420 | Firewall rules might cause Sun Java System Application Server startup failures. If you have a personal firewall installed, you might experience this problem. The presence of strict firewall rules on the same machine as a Sun Java System Application Server installation might cause startup failures of the Admin Server and App Server instances. Specifically, the Admin Server and App Server instances attempt to establish local connections within the Sun Java System Application Server environment. Since these connection attempts access ports using the host name of the system rather than localhost, local firewall rules might block such attempts. The local firewall might also inadvertently generate alerts saying that either the “Portal of Doom Trojan” attack (for example, TCP connection attempts on port 3700) or similar attacks have occurred when, in fact, such access attempts have been made by the Sun Java System Application Server and are in no way a security threat to your machine. Under some conditions, the port number which the Sun Java System Application Server uses for various local communications might overlap with port numbers used in known popular attacks. Some symptoms of this problem: An attempt to start the Sun Java System Application Server using the Microsoft Windows program group item “Start Application Server” fails with this message: `Could not start the instance: domain1:admin-server server failed to start: abnormal subprocess termination ...` The administrative and server instance log files contain connection exceptions followed by this message: `CORE3186: Failed to set configuration` Solution Modify the firewall policy to allow the Sun Java System Application Server to make connection attempts to ports on the local system. To avoid inaccurate alerts concerning possible attacks, either modify the relevant rules or change the conflicting port number(s) used by the Sun Java System Application Server. To determine the port numbers used by the Admin Server and App Server instances, see the `server.xml` file in the following location of your Sun Java System Application Server installation: domain_config_dir`/domain1/admin-server/config/server.xml` domain_config_dir`/domain1/server1/config/server.xml` where domain_config_dir is the location of your initial server configuration. For example: Microsoft Windows: install_dir`/domains/...`Solaris 9 and above integrated install: `/var/appserver/domains/...`Solaris 8, 9 and above unbundled install: `/var/opt/SUNWappserver7/domains/...` Look for the port settings in the <`iiop-listener`> and <`jms-service`> elements. You can either change these port numbers to other unused port numbers, or you can modify your firewall policy to allow connection attempts from clients on the local machine to these port numbers on the same machine.
4780076 | On Solaris, the Sun Java System Application Server starts all instances as root thereby allowing non-root users to have root access. There are several issues associated with application server startup when the Sun Java System Application Server is installed as part of a Solaris installation (bundled): All application server and administrative server instances are started automatically during Solaris system startup. In many environments, not all the instances are expected to be started automatically during Solaris system startup. Starting every defined instance can adversely impact the memory available on a system. When application server instances and administrative server instances are started automatically, the startup script for each instance is executed as root. Execution of non-root owned instance startup scripts can enable non-root users access to the root user through modification of the instance-level startup scripts. Background During installation of the Sun Java System Application Server as part of a Solaris installation, the `/etc/init.d/appserv` script and symbolic links to the `S84appserv` and `K05appserv` scripts in the `/etc/rc*.d/` directories are installed. These scripts cause all the application server and administrative server instances defined as part of the application server installation to be started and stopped automatically during Solaris system startup and shutdown. The `/etc/init.d/appserv` script contains the following section of code: `...case "$1" in’start’) /usr/sbin/asadmin start-appserv ;;’stop’) /usr/sbin/asadmin stop-appserv ;;...` Running the `asadmin start-appserv` command causes the administration server instance and all application server instances defined in all administrative domains to be started during Solaris system startup. Since the system startup and shutdown scripts are executed as root, the startup script for each application server and administrative server instance is also executed as root. The instance-level startup script is named `startserv` and is located at instance-dir`/bin/startserv`. Since instances might be owned by users other than root, the `startserv` scripts could be modified by the non-root user to execute commands as the root user. In cases where an instance is using a privileged network port, the instance’s `startserv` script must be executed as root. However, in these cases, "run as user" is typically set in the instance’s configuration to force the instance to run as the specified user after the instance has been initially started by the root user.
4780076(Continued) | Solution Perform one of the following workarounds depending on your environment: If your environment does not require all application server and administrative server instances to be started as root, then you should comment out execution of the `asadmin` `start-appserv` and `asadmin` s`top-appserv` commands in the `etc/init.d/appserv` script. If your environment requires starting either specific administrative domains (including the administrative server instance and all application server instances of each domain) or specific instances within one or more administrative domains, then you should either modify the `/etc/init.d/appserv` script to start the domains and/or instances of interest or define new `/etc/rc*.d/` scripts that suit the needs of your environment. Starting a specific domain. If you require to start either an administrative domain or specific instances as non-root users, then you should ensure that the `su` command with the `-c` option is used to start the domains and/or instances of interest. Examples Starting a specific administrative domain—If you want to start the administrative server instance and all application server instances of a specific administrative domain as the root user, you can modify the `/etc/rc*.d/` scripts as follows: .`..case "$1" in’start’) /usr/sbin/asadmin start-domain --domain production-domain ;;` `’stop’) /usr/sbin/asadmin stop-domain --domain production-domain ;;...`
4780076(Continued) | If you want to start specific application server instances as a non-root user, modify the `/etc/rc*.d/` scripts to use the `su` command with the `-c` option: `...case "$1" in’start’) su - usera -c "/usr/sbin/asadmin start-instance --domain test-domain instance-a" su - userb -c "/usr/sbin/asadmin start-instance --domain test-domain instance-b" ;;` `’stop’) su - usera -c "/usr/sbin/asadmin stop-instance --domain test-domain instance-a" su - userb -c "/usr/sbin/asadmin stop-instance --domain test-domain instance-b" ;;...` See the Sun Java System Application Server Administration Guide for more information on the startup and shutdown commands available through the `asadmin` command line interface.

- Previous: Installation, Upgrade, and Uninstallation
- Next: Database Driver

- © 2010, Oracle Corporation and/or its affiliates