- Doc Structure
- A Globus Primer
- Installing GT
- Platform Notes
- Migrating from GT2
- Migrating from GT3
- PDF version
- Best Practices
- Coding Guidelines
- API docs
- Public Interfaces
- Resource Properties
- Performance Studies
Table of Contents
A Call for Community Testing is a mechanism to notify our users that new Globus code is available for testing in the field. Through these calls, we hope to expose the code to a wide variety of usage scenarios early in its development process. The ultimate goals are to catch bugs that have historically been found only after final releases, and to elicit feedback from the community on ways our software can be improved.
- Install the software in a non-production environment. Use the 4.1.0 distribution
the code can also be retrieved directly from CVS using the tag
- Exercise the software.
- Log your experiences in http://bugzilla.globus.org/globus/ under the "Replica Location" product "RLS" component. Please mention 4.1.0 explicitly in the body of the report.
- If you have any questions or comments regarding this component, join the firstname.lastname@example.org list to participate in discussions with other testers. (To subscribe, read the instructions here.)
- Optional: Consider sending descriptions of your tests to email@example.com so that we might use them to build standard tests in the future. (To subscribe, read the instructions here.)
The Replica Location Service (RLS) is a standalone server (i.e., it is not deployed in a Web services container) that provides for the registration and lookup of replica information. Within the RLS, there are two types of services, a catalog service and an index service.
The Local Replica Catalog (LRC) maintains a catalog of replica information. Replica information in the RLS is maintained in the form of mappings from logical names for data items to target names. These target names may represent physical locations of data items, or an entry in the RLS may map to another level of logical naming for the data item.
In addition to the LRC, the RLS also exposes the Replica Location Index (RLI). The RLI maintains an index of logical names which indicates the LRC services(s) that have mappings for the specific logical names. The LRC generates an index of its logical names and pushes the index to one or more RLI services.
In a typical deployment, the RLS will be deployed in conjunction with one or more Storage Elements (SE). The LRC will be used to store mappings from logical names for data sets to the physical file locations as managed by the SEs. The LRC then sends an index of its contents to its associated RLI service as well as multiple remote RLI services at collaborating sites. Clients interested in a particular logical name will first query a RLI service to find the LRC services, then they will query one or more LRC services to find the target names (which may correspond to storage location URLs).
RLS depends on the following GT components:
RLS depends on the following 3rd party software:
- RDBMS: MySQL, PostgreSQL, or Oracle
- ODBC manager: unixODBC, iODBC
- ODBC driver: MyODBC, psqlODBC, or Oracle
- Build, install, and test on RedHat (ES, AS), Fedora, and Debian flavors of Linux.
- Build, install, and test on FreeBSD, Solaris, AIX, and HP-UX flavors of UNIX.
- Build and test Java clients using JDK 1.4 compliant JVM's from vendors other than Sun (e.g., IBM).
- Deploy with Oracle for database management.
- Test large-scale deployment with multiple sites for LRC and RLI services in fully connected and partially connected architectures.
- Test large-scale deployment by registering several million logical and physical file names at each LRC and propagate to connected RLIs.
- Test large-scale deployment using C Client API to execute 1000's of bulk operations per second.