platform and language. Start by mastering the essentials of object-oriented
programming on the Java platform, and progress incrementally to the
more-sophisticated syntax and libraries that you need to develop complex,
real-world Java applications.
Attachmate Java applications rely on the Java Virtual Machine (JVM) to manage memory. The JVM allocates a pool of memory at startup and applications running in that JVM share that memory. Each Attachmate application that uses Java sets a maximum value for the size of the JVM memory pool. (This is also called the Java heap size.) The JVM can use memory, as required, up to this specified limit. As memory use approaches this limit, the JVM will recycle unused memory so that it remains available to applications running in the JVM.
When viewing memory used by a Java application, note the following:
In the Windows Task Manager, some Java applications create processes that use an application-specific image name. (For example Reflection X Manager and Reflection X Manager for Domains create processes listed under rxmgr.exe and rxmgrdomains.exe). Other applications (including the Reflection X Service) create processes that use java.exe as the image name.
If you also run other applications that consume a lot of memory, you may see performance issues. As Windows runs out of the random access memory (RAM) needed to run your applications, it uses something called virtual memory to compensate. When the available RAM runs low, Windows moves data from RAM to disk storage in a file called the paging file. Moving data to and from the paging file frees up RAM so your computer can complete its work, but reading data from the disk is slower than reading data directly from memory.
On most systems, you will not need to modify your settings using any of the following troubleshooting techniques. The Reflection X Advantage default JVM settings provide sufficient memory to address the memory demands created by most X clients and servers. The default maximum heap size also ensures sufficient memory will be available on most systems for your Windows applications that don’t use this JVM. However, in some cases, contention for memory may prevent Reflection X Advantage applications from launching, or affect the performance of other applications on your system.
If your system’s memory is limited or fragmented, you may see one of the following indications that memory limits are preventing Reflection X Advantage applications from running.
“The description for Event ID (1025) in Source (RXAdvantage) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: The event log file is corrupt.”
If memory limits prevent Reflection X Advantage from running, or you have determined that contention for memory is affecting performance of other applications, consider the following approaches.
If you have installed Reflection X Advantage using the 32-bit installer on a 64-bit system, and Reflection X Advantage applications fail to launch, reinstall using the 64-bit installer. The memory limit on 64-bit processes is much larger than the limit on a 32-bit processes.
The more RAM your computer has, the faster your programs will generally run. If a lack of RAM is slowing your computer, you may have success using the following adjustments. However, if none of these solutions result in better performance, adding additional RAM is the best solution.
Reducing the maximum memory limit for Reflection X Advantage (also called the Java heap size) can resolve the problem of Reflection X Applications failing to launch and can also increase the amount of memory available to other applications.
Note: This solution may affect performance in Reflection X Advantage. If memory is available Reflection X Advantage sessions cache images, the results of certain calculations, and other data. These actions can improve drawing performance and compression over low-bandwidth networks. If changing the Java heap size results in slow performance or X client failures, the value is probably set too low.
To change the maximum memory available to the Reflection X Advantage JVM:
Note: The *.alp files are replaced by newer, default files when you upgrade your Reflection X Advantage product. If memory problems reappear after an upgrade, see Technical Note 2530, “Installing Newer Versions of Reflection X Advantage If You Have Edited Rxmgr.alp.”
You can increase the amount of virtual memory available by increasing the minimum and maximum sizes of the paging file.
This change can result in slower performance in Reflection X Advantage and other applications because of excessive disk paging. This solution may work for you if there are idle applications that can be paged out at times.
To modify virtual memory in Windows:
Increases in size usually don’t require a restart, but if you decrease the size, you will need to restart Windows.
If you are running Reflection X Advantage in domain mode and are experiencing memory contention on the domain node, you can experiment with using multiple nodes to help alleviate memory problems. Reflection X Advantage supports creating multiple nodes on the same system. This change effectively increases the allowed memory available to run sessions. You can also add nodes on remote systems. This increases both the number of CPU cores available and amount of available memory.
To add nodes to a domain, use the rxsconfig command line utility. For details, see “Set Up Domain Nodes” in the Reflection X Advantage product Help.
The number of sessions that a node can support depends on what kind of domain services are configured for the session (such as whether the session has a headless server running on the node) and how active the clients of the session are. You can monitor the load on your nodes using the Administrative Console. As an initial approximation, a session without a headless server can be expected to require about 1MB, and with a headless server about 25MB of heap space. For a 1GB heap (the default), this can be anything from about 30-1000 sessions. With a large number of sessions, resources such as cores and network bandwidth become a bigger concern.
Is there a way to pass an rstring to a java native function so I can reference it as an RString? Or is there perhaps a better way to decode a byte array directly in SPL?