Dealing with initialization problems

Shared classes initialization requires a number of operations to succeed. A failure might have many potential causes, and it is difficult to provide detailed message information following an initialization failure. Some common reasons for failure are listed here.

If you cannot see why initialization has failed from the command-line output, look at level 1 trace for more information regarding the cause of the failure. The SDK and Runtime User Guide for your platform provides detailed information about operating system limitations. A brief summary of potential reasons for failure is provided here.

Writing data into the javasharedresources directory

To initialize any cache, data must be written into a javasharedresources directory, which is created by the first JVM that needs it.

On Linux®, AIX®, z/OS®, and i5/OS® this directory is /tmp/javasharedresources. On Windows®, it is C:\Documents and Settings\<username>\Local Settings\Application Data\javasharedresources.

On Windows, the memory-mapped file is written here. On Linux, AIX, z/OS, and i5/OS this directory is used only to store small amounts of metadata that identify the semaphore and shared memory areas.

Problems writing to this directory are the most likely cause of initialization failure. A default cache name is created that includes the username to prevent clashes if different users try to share the same default cache. All shared classes users must also have permissions to write to javasharedresources. The user running the first JVM to share classes on a system must have permission to create the javasharedresources directory.

By default on Linux, AIX, z/OS, and i5/OS caches are created with user-only access. Two users cannot share the same cache unless the -Xshareclasses:groupAccess command-line option is used when the cache is created. If user A creates a cache using -Xshareclasses:name=myCache and user B also tries to run the same command line, a failure occurs. The failure is because user B does not have permissions to access "myCache". Caches can be removed only by the user who created them, even if -Xshareclasses:groupAccess is used.

Initializing a persistent cache

Persistent caches are the default on all platforms except for AIX and z/OS.

The following operations must succeed to initialize a persistent cache:
1) Creating the cache file
Persistent caches are a regular file created on disk. The main reasons for failing to create the file are insufficient disk space and incorrect file permissions.
2) Acquiring file locks
Concurrent access to persistent caches is controlled using operating system file-locking. File locks cannot be obtained if you try to use a cache that is located on a remote networked file system. For example, an NFS or SMB mount. This option is not supported.
3) Memory-mapping the file
The cache file is memory-mapped so that reading and writing to and from it is a fast operation. You cannot memory-map the cache file to a remote networked file system, such as an NFS or SMB mount. This option is not supported. Alternatively, memory-mapping might fail if there is insufficient system memory.

Initializing a non-persistent cache

Non-persistent caches are the default on AIX and z/OS.

The following operations must succeed to initialize a non-persistent cache:
1) Create a shared memory area
Possible problems depend on your platform.
Linux, AIX, z/OS, and i5/OS
The SHMMAX operating system environment variable by default is set low. SHMMAX limits the size of shared memory segment that can be allocated. If a cache size greater than SHMMAX is requested, the JVM attempts to allocate SHMMAX and outputs a message indicating that SHMMAX should be increased. For this reason, the default cache size is 16 MB.
2) Create a shared semaphore
Shared semaphores are created in the javasharedresources directory. You must have write access to this directory.
3) Write metadata
Metadata is written to the javasharedresources directory. You must have write access to this directory.
If you are experiencing considerable initialization problems, try a hard reset:
  1. Run java -Xshareclasses:destroyAll to remove all known memory areas and semaphores. On a Linux, AIX, or z/OS system, run this command as root, or as a user with *ALLOBJ authority on i5/OS.
  2. Delete the javasharedresources directory and all of its contents.
  3. On Linux, AIX, z/OS, or i5/OS the memory areas and semaphores created by the JVM might not have been removed using -Xshareclasses:destroyAll. This problem is addressed the next time you start the JVM. If the JVM starts and the javasharedresources directory does not exist, an automated cleanup is triggered. Any remaining shared memory areas that are shared class caches are removed. Follow one of these steps to reset the system and force the JVM to re-create the javasharedresources directory:
    • On Linux, AIX, or z/OS, using root authority, start the JVM with -Xshareclasses.
    • On i5/OS, using a user that has *ALLOBJ authority, start the JVM with -Xshareclasses.


© Copyright IBM Corporation 2005, 2010. All Rights Reserved.
© Copyright Sun Microsystems, Inc. 1997, 2007, 901 San Antonio Rd., Palo Alto, CA 94303 USA. All rights reserved.
US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
This information center is powered by Eclipse technology. (http://www.eclipse.org/)