Known Issues

We are aware of the following issues with the lastest GRIA software releases. If you encounter these or new issues and require more details or support, then please request help.

GRIA 5.0.1

• After upgrading from GRIA 5.0, previous usage on SLAs is lost. This means that usage on an SLA may be reported as less than actually occurred. If this is a concern, users should create new SLAs after upgrade.

• There's a possible issue when using cygwin Perl when the GRIA Basic Application Services are deployed on Windows. This needs further investigation, but we recommend using ActiveState Perl were possible, until this is resolved.

• When using a GRIA 5.0.1 Client to view usage information using a GRIA 5.0 Service Provider Management installation, only the last 24 hours of usage is displayed, even though the client display suggests otherwise.

GRIA 5.0

• Due to some inefficiencies in this release, the SLA service will run out of memory when there are a few hundred activities on an SLA. In addition, in some circumstances memory is not always released, so that services will run out memory after running for a while. One way to alleviate this problem is to restrict the number of incoming requests to a service and run the packages in separate JVMs. However, it is still possible to run both packages on a single machine; see the Running Two Tomcat JVMs on one machine section of the user-guide.

• If you are experiencing problems using a proxy then please apply this patch to each of the packages you are employing.

• When the GRIA basic application services are configured to be managed by the service provider management package, jobs and data stagers may be killed by the SLA manager service (to manage resource usage). However, the SLA manager may kill data stagers that are inputs or outputs to jobs, when it is more appropriate to kill the owning job.

• In the current version of GRIA there is no way to see usage on supplier SLAs that are linked to a private account. For this reason it is best not to link both SLA and trade accounts to a single project account. Instead, try using a second (dummy) project account to control access to your SLAs (i.e. using it as a token service only), and monitor usage only through the real private account by checking monetary charges there. A more advanced statement browser will be included in the next release that allows private accounts to easily provide feedback for both types of supplier resources.

GRIA 4.3.1

• If you are using WinXP and encounter an error such as: Status: Error from job service: Couldn't submit job to LCR: Job submission script invocation failed, exit code = 9 then the most likely cause is that windows has not been installed on the C:\ drive. In order to fix the problem, please replace the local exection platform srcipts (located in the rm_local directory) with these updated versions. N.B. do not leave copies or backup versions of these files in that directory, as this will confuse the job service about which scripts should be employed.

• Depending on how Tomcat may have been set up, attempting to view a JSP page may give this error: "java.io.FileNotFoundException: /usr/local/jakarta-tomcat-5.0.25/bin/files990520320 (Permission denied)". The reason for this is that Tomcat has not actually been set up correctly and the user does not have write permissions to the tomcat/temp directory. To fix this problem, make sure the Tomcat user has permission to write to this temporary directory.

• A memory leak has been observed with the Linux kernel provided with SuSE 9.2 (v2.6.8) and Fedora Core 3 (v2.6.9), which can be fixed by upgrading to the latest stock kernel (v2.6.12) available from www.kernel.org . This should only affect users who are running GRIA intensively (e.g. a 1 GB machine was observed to run out memory after more than 5000 jobs). The leak has not been observed with the latest versions of SuSE (9.3 & 10.0), Fedora Core (4) or other linux flavours. Please contact GRIA Support if you observe this memory leak with details of the platform you are using.