Oracle GlassFish Server 3.0.1 Troubleshooting Guide

Chapter 2 Specific Issues

This chapter lists problems that you might encounter when using Oracle GlassFishTM Server 3.0.1. The following topics are addressed:

Cannot Access Local Server (http://localhost:8080)

When this error occurs, check the following:

Did the Server Start?


If the console window is still open, the expected message indicates that the default domain was started successfully.

If the console window is already closed, check for messages in the log file:


If startup was successful, the expected message is similar to that on the console, and appears at the end of the log file.

For more information about starting a domain, see Starting and Stopping a Domain in Oracle GlassFish Server 3.0.1 Administration Guide. To easily determine if a domain is running, use the asadmin list-domains command.

Was the Server Started at the Expected Port?


The server might be running at a different port number than expected, either because it was intentionally installed there, or because another server was already running on the default port when the server was installed.

ProcedureTo Determine Which Port Number the Server Is Using

  1. Examine the server's configuration file:

  2. Find the network-listener element.

  3. Inspect the value of the port attribute.

    Be sure to enter the correct port number when invoking the server.

    Note –

    The server's default port number is 8080, however, there are a number of ways in which the expected value can change:

    • A different port number was specified during installation.

    • A previous installation exists.

Is a Personal Firewall Enabled?

Issues might result when personal firewalls are enabled. Disable your personal firewall and see if the server access problem still exists.

Cannot Access Remote Server

When attempting to open the start page of GlassFish Server, the initial screen does not appear.

When this error occurs, check the following:

Is the Server Available Locally?


If the server cannot be accessed from the web, but it is running locally, then the server is actually running.


Verify that the server is running locally.

ProcedureTo Verify That the Server Is Running Locally

  1. Log on to the host where the server is running.

  2. Go to the local web page. For example, if 8080 is the default port, go to:


    If the start page does appear, the web connection is encountering a problem that prevents accessing the server remotely. If the start page does not appear, see Did the Server Start?.

Is the Proxy Setting Causing a Problem?


The server should be accessible directly from the host on which it is running (localhost); for example, using the default port 8080:



A server instance running on localhost might not be accessible if the server host machine is connected to the web through a proxy. To solve this problem, do one of the following:

Note –

To determine the host name for the localhost machine, type hostname at the command prompt.

Cannot Access the Administration Console

The Administration Console provides a graphical interface for administrative functions. If the Administration Console is not accessible, check the following:

For more information about the Administration Console, see Administration Console in Oracle GlassFish Server 3.0.1 Administration Guide.

Is the Application Server Running?


The server must be running before the Administration Console can be accessed.


Review the information in Did the Server Start? to determine if the server is running.

Is the Administration Console Running on the Expected Port?


The default port number for the Administration Console is 4848. However, it could be running on a different port number than expected, either because it was intentionally installed there, or because that port was in use when the server was started.


Refer to Was the Server Started at the Expected Port? for guidelines on verifying the port on which the Administration Console is running. Be sure to enter the correct port number and HTTP protocol when invoking the Administration Console.

Cannot Access a Server Application

If a particular application cannot be accessed through GlassFish Server, check the following:

Is the Application Server Running?


If GlassFish Server is not running, applications are not accessible.


Review the information in Did the Server Start? to determine if the server is running. The server must be running before a server application can be accessed.

Was Application Deployment Successful?


An application must be successfully deployed before it can be accessed.


Verify that the application was successfully deployed. There are several ways to do this:

For more information about deploying applications, see Chapter 2, Deploying Applications, in Oracle GlassFish Server 3.0.1 Application Deployment Guide. Also see the Administration Console online help.

Administrator User Name or Password Not Known

If you have forgotten the administrator user name, you can find it by inspecting the as-install/domains/domain-name/config/admin-keyfile file, where domain-name is the name of the domain. In the default domain, domain1, the file to inspect is as-install/domains/domain1/config/admin-keyfile. For a different domain, substitute its name in the path.

If you have forgotten the administrator password, one solution is to create a new domain with the admin username and password that you want, then copy the entry from the config/admin-keyfile file in that new domain to the other domain.

Experience Issues Related to the JDK


You experience JDK-related issues in a variety of circumstances.


GlassFish Server 3.0.1 requires JDK 6, so check your system for that dependency.

The minimum (and certified) version of the JDK software that is required for GlassFish Server depends on the operating system:

Ensure that the required JDK software is installed and that the JAVA_HOME environment variable points to the JDK installation directory, not the Java Runtime Environment (JRETM) software.

Set JAVA_HOME and $JAVA_HOME/bin in the PATH to point to the supported JDK version.

Server Will Not Start on Windows (Port Conflict)

If a message similar to the following is displayed when starting GlassFish Server on Microsoft Windows, a server port conflict has occurred:

Address already in use

This error occurs when another application is running on the GlassFish Server port (default 8080), or because a previous instance of GlassFish Server did not shut down cleanly.

You might also check the following:

Is Another Application Running on the Server's Port?

If another application is using the server's port, stop the other application, then restart GlassFish Server.

Has an Ungraceful Shutdown Occurred on a Previously Running Server?

Use the asadmin stop-domain command to stop the server, or explicitly kill the Java process and then restart GlassFish Server.

Two Server Instances Bind to Same Port on Windows


This problem occurs on Windows XP systems with GlassFish Server software, and is due to a known Windows security flaw rather than a problem with GlassFish Server itself.

The problem occurs when two or more instances of GlassFish Server are created using the same port number for the instanceport option; for example:

asadmin create-domain -adminport 5001 options -instanceport 6001 domain
asadmin create-domain -adminport 5002 options -instanceport 6001 domain

When the two domains are started on a UNIX or Linux system, a port conflict error is thrown and the second instance fails to start. However, when the two domains are started on Windows XP, no error is thrown, both server instances start, but only the first instance is accessible at the specified port. When that first server instance is subsequently shut down, the second instance then becomes accessible. Moreover, when both instances are running, the Windows netstat command only reports the first instance.


Be sure to use unique port numbers for all server instances on Windows systems.

Cannot Produce a JVM Thread Dump After Server Crash


If GlassFish Server crashes, the server dumps a core file and, by default, restarts with the -Xrs flag, which prevents the dump of a JVM thread dump.


ProcedureTo Obtain a Server Thread Dump

  1. Type the following command:

    asadmin generate-jvm-report --type=thread
See Also


Issues Related to Applications

Cannot Undeploy or Redeploy Application With Open Streams to jar Files (Windows)


On Windows systems, after running an application, subsequent attempts to undeploy it or redeploy it throw exceptions about the server being unable to delete a file or rename a directory.

On Windows systems, an application may use getClass().getResource or getResourceAsStream methods to locate a resource inside the application, particularly in jar files that are in the application or accessible to it. If the streams remain open, subsequent attempts to redeploy or undeploy the application can fail. In addition, the Java runtime by default caches streams to jar files for performance reasons.


Be sure to close streams opened by your applications. Also, if an application needs to be redeployed or undeployed repeatedly, and also needs to obtain a resource from a jar file using getResource or getResourceAsStream, consider using getClass().getResource, which returns a URL object, then invoke the url.setUseCaches method to turn off caching for that jar file, and use url.getInputStream() to obtain the stream.

Although turning off caching for access to the jar file can slow performance, this approach does allow the application to be undeployed or redeployed. Note also that if the getClass().getResourceAsStream method is used instead, then the jar file in which the resource is located is cached (this is the default Java runtime setting) and remains open until the server is stopped.

Issues Related to asadmin

asadmin start-domain Command Fails

The command asadmin start-domain fails with the following error:

There is more than one domain...


When issued with no arguments, the command asadmin start-domain fails.

This error occurs when there is more than one domain in the domains directory, none of them is named domain1, and no domain is specified with the start-domain command.


Specify the domain when issuing the start-domain command:

asadmin start-domain domain-name

For example:

asadmin start-domain mycustomdomain

Cannot Stop Domain Using asadmin stop-domain


You cannot stop the domain using the asadmin stop-domain command.


Look for error messages that display in the console when you issue the command.

Search the server.log file for error messages related to your inability to stop the domain.

Issues Related to Installation

Installation Hangs During Update Tool Configuration


Installation hangs more than five minutes during Update Tool configuration.


Cancel the installation and run the installation program again, but this time deselect the Install Update Tool check box. Update Tool can be installed later from as-install/bin/. For more information about Update Tool, see Update Tool in Oracle GlassFish Server 3.0.1 Administration Guide. For general information about GlassFish Serverinstallation, see the Oracle GlassFish Server 3.0.1 Installation Guide.

Note –

Update Tool differs from Upgrade Tool, which is used to migrate the configuration and deployed applications from an earlier version of GlassFish Server to the current version. For more information about Upgrade Tool and upgrading, see the Oracle GlassFish Server 3.0.1 Upgrade Guide.

Enterprise Server Components Not Removed During Uninstallation


Not all GlassFish Server directories are automatically removed by the uninstallation program. Some directories and files remain after uninstalling.


Examine the remaining directories and remove any files or directories that you do not want, including hidden directories prefixed with a dot. It is safe to remove uninstallation and installation log files after you have examined them.

For information related to uninstallation, see Chapter 2, Uninstalling Oracle GlassFish Server 3.0.1, in Oracle GlassFish Server 3.0.1 Installation Guide.

Issues Related to Security Access Denied Error


The following error occurs from an application client, or appears in the server.log file: access denied
(java.util.PropertyPermission name write...)

There is a permissions issue in the policy files. Either the client.policy file for the application client or the server.policy file for server side components does not have permission to set the property.


Add the permission in client.policy (for the application client), or in server.policy (for web modules) for the application that needs to set the property. By default, applications only have read permission for properties.

For example, to grant read/write permission for all files in the codebase directory, add or append the following to client.policy or server.policy:

grant codeBase "file:/.../build/sparc_SunOS/sec/-" {
   permission java.util.PropertyPermission "*", "read,write";

Mutual Authentication Not Working With the Application Client


This failure can occur when the keystore and truststore properties are not set properly.


Set the following properties on the JVM:

To use the application client, set the environment variable VMARGS to the following value:${admin.domain.dir}/${admin.domain}/config/keystore.jks${admin.domain.dir}/${admin.domain}/config/cacerts.jks