This chapter discusses administration of DIVAnet.
DIVAnetAdmin is a simple command-line tool that has options for administering DIVAnet. This utility can be run only on the server where the ClientAdapter and DbSync services are running.
To start the utility, open a command window, and then navigate from the DIVAnet home directory to the Program/divanet/bin subdirectory. Type one of the following commands to start the utility:
Windows:
DIVAnetAdmin.bat {ClientAdapterWebUrl} {DbSyncWebUrl}
Linux:
DIVAnetAdmin.sh {ClientAdapterWebUrl} {DbSyncWebUrl}
Note:
If you do not supply the URL arguments, the utility will assume that the ClientAdapter and DbSync services are running locally, and will prompt for the ClientAdapter and DbSync service ports.Table 6-1 shows the DIVAnetAdmin options, selectable through a menu system.
Table 6-1 DIVAnetAdmin Options
| Category | Option | Description |
|---|---|---|
|
Asset Database Synchronization |
List Synced Sites |
Generates the list of the sites in which asset information is being synchronized. It will also display the synchronization status of each site. If a site is in an initial sync state, the percentage complete will also be displayed. |
|
Asset Database Synchronization |
Resync a Site |
Resynchronizes all object records from a particular site to the DIVAnet database. Caution: This option will delete all asset records in the DIVAnet database (for the selected site) before resyncing them. |
|
Asset Database Synchronization |
Resync an Object |
Updates object records for a specific object at a specific site. Does not synchronize deletes. |
|
API Connections |
List API Connection |
Lists all Client DIVAnet API connections, including those in Direct Mode. |
|
API connections |
End API Connection |
Provides an option to end a particular API connection, identified by ID. |
|
Reload Workflow Profiles |
Reload Workflow Profiles |
This option will cause all Workflow Profiles to be reloaded. It will also reload any Access Rules that are defined. If Access Rules are defined, this option requires access to the ChangeConfig operation. |
|
Site Parameters |
Show Site Parameters |
This option displays DIVA site parameters, including the number of queued requests to the site, number of requests (sent by DIVAnet) running on each site, date of last communication with the site, and the throttling parameters. |
|
Site Parameters |
Set Site Parameters |
This option allows the user to set the DIVA throttling parameters:
If Access Rules are defined, this option requires access to the ChangeConfig operation. |
|
Runtime Stats |
Show Runtime Stats: ClientAdapter |
This option displays useful run time statistics for the ClientAdapter service. |
|
Runtime Stats |
Show Runtime Stats: DbSync |
This option displays useful run time statistics for the DbSync service. |
|
Log Level |
Set Log Level: ClientAdapter |
This option lists the log level of the ClientAdapter services, and provides the option to dynamically change the log level (valid values are ERROR, WARN, INFO, DEBUG, TRACE). |
|
Log Level |
Set Log Level: DbSync |
This option lists the log level of the DbSync services, and provides the option to dynamically change the log level (valid values are ERROR, WARN, INFO, DEBUG, TRACE). |
DIVAnet creates the following types of log files:
Trace Logs — Located within the DIVAnet home directory in the Program/log/divanet subfolder. Each of the DIVAnet services (ManagerAdapter, DbSync, and ClientAdapter) create their own subfolder underneath the Program/log/divanet folder and generate their log files in that subdirectory.
Wrapper Service Logs — These logs output messages related to startup and shutdown of the windows service. This is the place to look if the service is not starting correctly. These logs are within the DIVAnet home directory in the Program/log/divanet subfolder. They will be named similar to the Wrapper.conf file, but with a .log file name extension (for example, ManagerAdapterWrapper.log).
GUI Logs — Errors that occur in DIVAnetUI will appear on the client computer, not on the server side. The logs appear in the Program/log/divanet/gui subfolder.
DIVAnet will package logs older than one hour into zip files, and retain two days worth of logs for review.
The following sections discuss queuing and processing of DIVAnet requests.
DIVAnet can accept more requests than downstream DIVArchive systems can process with request queues. DIVAnet enforces a maximum number of requests that can be queued and (or) running internally (the default is 5000), using the GlobalDivanetRequestLimit parameter. DIVAnet will start rejecting requests if this limit is reached. The DIVAnet ClientAdapter service maintains a queue for each site. You can configure DIVAnet to feed requests to sites slowly, or to send requests to sites all at once (where they will likely be queued by DIVArchive).
If a request is queued to a DIVArchive system, and the DIVA system is restarted, all running requests will be terminated. DIVAnet behaves differently - DIVAnet stores each request in a database. If the ClientAdapter service is restarted, DIVAnet reads the pending and running requests and restarts them. However, not all requests will be restarted this way. For example, delete requests will never be reissued after the service restarts. If recovering requests on startup is not desired, the ClientAdapter AbortAllOnStartup parameter can be set to terminate all requests in the queue at startup.
By default, DIVAnet will send one hundred requests to a site before stopping and waiting for one of the requests to complete. The parameter that controls the limit is SubmittedThrottleThreshold, which is configurable in the ClientAdapter on a per site basis. It can also be changed at run-time through the DIVAnetAdmin utility. In addition, DIVAnet can throttle requests based on the total number of requests running on a DIVArchive site (using the TotalThrottleThreshold parameter). You can set either parameter to -1 to indicate that no throttling should be performed. You can also set the value to 0, indicating that no requests in the queue should be sent to DIVArchive. This can be useful in certain situations.
If a DIVAnet request is queued to a particular site for more than a few seconds, DIVAnetUI will display the position of the request in the queue. If another request is queued with a higher priority than the first, it will likely have a higher position in the queue. If the request fails and is retried, the request will be queued again (although it will get a priority boost from being in the system for a long time).
Delete requests associated with queuing and timeouts are treated differently than other requests. The DeleteWaitTimeoutMins parameter controls how long DIVAnet waits for a delete to complete before timing out the operation. The default is two minutes, but can be increased to be more in line with other commands.
Some requests can be retried automatically within DIVAnet. Copy, Restore, Partial File Restore, and Delete requests can be retried. Restore & Partial File Restore requests can be retried a configurable number of times, where Copy and Delete requests are retried over a configurable time interval. Retries can be specified on a per Workflow Profile basis, and can be modified at run-time without restarting the ClientAdapter (see Configuring Workflow Profiles for more information).
If a site is down, and requests are queued to that site, DIVAnet will wait for SiteDownRequeueWaitMins minutes for the site to become operational. If that configured time period elapses, and retries are configured, DIVAnet will attempt to retry the request, possibly on another site. If retires are not configured the request will terminate.