Eclipse GlassFish Troubleshooting Guide, Release 7

Ensure that your system meets the requirements listed in "Hardware and Software Requirements" in Eclipse GlassFish Release Notes. Problems are likely to arise if you attempt to install on a platform that is not supported or on a system that in some other way does not meet release requirements. Also see "Known Issues" in Eclipse GlassFish Release Notes for known issues related to installation.

Eclipse GlassFish requires JDK release 11 or newer. If necessary, download and install the required JDK software.

On Solaris, Linux, and Windows systems, JDK software is available from the Java SE downloads page (https://www.oracle.com/java/technologies/downloads/).

For Mac OS X systems, Eclipse GlassFish uses the JDK that is part of the Macintosh operating system. If necessary, obtain the required JDK version from the Mac OS X Updates site (http://support.apple.com/downloads/).

Also ensure that the JAVA_HOME environment variable on your system points to the JDK installation directory and not the Java Runtime Environment (JRE) software.

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

Your problem might be related to a known issue for the release. Refer to the Eclipse GlassFish Release Notes for the latest information regarding known issues and possible workarounds. Also search the GlassFish issues at https://github.com/eclipse-ee4j/glassfish/issues.

Eclipse GlassFish includes complete product documentation. Search the documentation to see if your problem is addressed. See Eclipse GlassFish Documentation Set for the books in the documentation set and a description of their contents. Also see the Administration Console online help for detailed information about performing administrative tasks using the graphical interface.

The following books will be especially helpful for troubleshooting:

Use the product documentation to learn more about Eclipse GlassFish. The more you know about the product the easier it might be to figure out why something isn’t working.

Lists and forums are extremely helpful resources, and are accessed as follows:

Type the following command:

See Also

generate-jvm-report(1)

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. This is the default location:

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 Eclipse GlassFish Administration Guide. To easily determine if a domain is running, use the asadmin list-domains command.

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.

To Determine Which Port Number the Server Is Using

Follow this procedure.

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.

To Verify That the Server Is Running Locally

Follow this procedure.

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:

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.

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.

If Eclipse GlassFish 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.

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 "Deploying Applications" in Eclipse GlassFish Application Deployment Guide. Also see the Administration Console online help.

Type the following command:

See Also

generate-jvm-report(1)

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.

Application servers such as Eclipse GlassFish allow you to redeploy an application without restarting the server. Simply make the change in your source code, compile the source, and redeploy the application.

Each application is loaded using its own classloader. When you undeploy an application, its classloader is discarded with all the classes it loaded and is garbage collected sooner or later. However, if there’s a reference from outside an application to an object in the application loaded by the application’s classloader, that object can’t be garbage collected. The reference holds the object in memory.

The memory in the Virtual Machine is divided into a number of regions. One of these regions is PermGen. It’s an area of memory used to (among other things) load class files. The size of this memory region is fixed; it does not change when the VM is running. You can specify the size of this region with a command line switch: -XX:MaxPermSize. Setting the -Xmx parameter does not help: this parameter only specifies the total heap size and does not affect the size of the PermGen region.

If you keep loading new classes that can’t be garbage collected because of references to them from outside the application, the VM runs out of space in the PermGen region, even if there’s plenty of memory available. This is called a classloader leak. The resulting exception is java.lang.OutOfMemoryError: PermGen space.

The java.lang.String.intern() method also allocates memory in the PermGen region. If your application uses this method with strings and holds references to these strings, thereby making garbage collection impossible, your application may cause the same PermGen space exception.

Classloader leaks are difficult to diagnose. Most profilers list leaked objects but don’t highlight the ones causing classloader leaks. Most profilers also stop tracing as soon as they reach a class object or classloader.

One diagnostic approach involves undeploying the application and triggering a memory dump using the JDK 11 jcmd tool. The simplest analysis is to list all instances of java.lang.Class and look for class objects that have many instances. This is a sign that the class has been loaded multiple times without being garbage collected.

See https://www.eclipse.org/openj9/docs/tool_jcmd/ for more information.

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:

For example:

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.

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 Eclipse GlassFish Administration Guide. For general information about Eclipse GlassFishinstallation, see the Eclipse GlassFish Installation Guide.

Not all Eclipse GlassFish 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 "Uninstalling GlassFish" in Eclipse GlassFish Installation Guide.

The following error occurs from an application client, or appears in the server.log file:

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:

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: