Skip to main content
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Application Roles

    Managing Application Roles and Other Server Settings

    The settings of each server, including the assignment of an application role to a server, are defined in the configuration file called, which is locatedunder $dps_dev/system.dir/conf/.

    This file holds all the settings that might vary between servers, while all the settings that are relevant for the entire installation are defined in the databaseג€™s general parameters table (see below).
    Changes in the global_properties file take effect only after running the script $dps_dev/system.dir/bin/
    Rosetta must be shut down before running

    2-Tier Topologies

    In a two-tier topology, before changing the the APP_ROLE of a certain server, the System Administrator must update [module].server in with the correct FQDN for each module (before running the set_globals script). If a load balancer is applied, update load.balancer.[module].host and load.balancer.[module].port for each relevant module.
    If the changes affect more than just the, the System Administrator must run the $dps_dev/system.dir/bin/rosettings.csh script.
    Cases that require the Administrator to run the rosettings.csh script include:
    • Changing FQDN/LB name / port for deposit, operational, delivery application roles
    • Changing the PDS URL / port
    • Changing the database credentials
    • Turning the PDS SSL on or off, or changing the PDS SSL port
    • Setting the Rosetta SSL via load balancer
    In any of these cases, we strongly recommend that you consult first with the Rosetta Support team.

    Rosetta Scalability

    To increase the computing power of Rosetta, you can use more than one server with the same application role. In this case, all the servers that work with the same application role should have a load balancer that balances the load between them.
    When adding or modifying the load balancer settings, the URL must be changed in the file of each server. To apply the changes, the System Administrator must run the $dps_dev/system.dir/bin/rosettings.csh script.
    Changing the application role of a server or adding a load balancer should be undertaken only after consulting the Rosetta Support team.

    Managing Workers

    Rosetta uses worker threads to handle back-end processing. Such back-end processes include:
    • Deposit work
    • Event processing
    • Indexing
    • SIP processing
    • Permanent processing
    • SIP loading

      Rosetta Workers
    SIP processing resources can be configured on each server in order to optimize the performance of the system. These settings are configured out-of-the-box for a server of typical computing power in line with the Rosetta system requirements. Installations with larger or smaller servers may need to adjust these settings to achieve an optimum utilization of system resources. In addition, worker threads can be configured to create a server that handles only specific functionality within an application role. A typical use case could be the need to allocate enough computing power for front-end activity (such as Web deposit and Delivery) while back-end activities such as maintenance tasks run in the background.
    To adjust these settings, log on to the Rosetta Administration site and follow the path from the Administration page: System Configuration > General > SIP Processing Workers.

    SIP Processing Workers
    The Level parameter is a 0-10 value that determines the SIP processing load for the entire environment by setting all servers to default and adjusting the default value, or by individually adjusting each SIP processing server (DEP, REP, and PER).
    To ensure UI high-availability, lower the level on one or more of your REP servers, or consider reserving one of your REP servers for UI functionality by setting its level to 0.
    An indication of a balanced and fully-utilized SIP processing configuration is one in which the number of waiting SIPs is constantly approaching 0 and the number of SIPs in process is steady (the actual number naturally depends on the number of servers). Adjust the Default Level to apply changes to all servers set to Default, or adjust servers' levels individually. If the number of waiting SIPs is rising and SIP processing level is at maximum (and/or cannot be increased in order to reserve UI resources), you may require additional hardware resources to achieve better throughput. Please consult the Rosetta Support Team and Ex Libris Sizing Manager for further analysis.
    Users with heavy SIP loading needs may also want to reserve Operational server resources for end-user-facing modules by detaching the Operational servers that handle SIP processing from the load balancer. The load balancer would direct all requests to servers with a low level of SIP processing workers (or none at all), ensuring high availability.
    Currently these servers are not dedicated to end user requests, as they also handle Process Automation.

    High Availability Server Flow
    Libraries that are interested in setting up such a topology should contact Rosetta Support.
    To have several worker processes allocated per SIP, select the Run in Parallel check box. This allows Rosetta to process a large amount of files much more quickly.

    SIP Processing Throttling

    SIP processing can be configured to refrain from processing additional SIPs when the system load average (during the last minute) is above a certain level. The load average is calculated similar to the top UNIX utility, taking into consideration memory usage and CPU utilization. This setting is useful when unusually large SIPs are deposited sporadically and unpredictably, in order to prevent Rosetta from unexpectedly running out of resources.
    • Was this article helpful?