Features¶

This page details the main features of TReqS

Client/Server design¶

Ok, this is not the most elegant way to implement a client/server architecture.

The client never talks directly to the server : the transmission of information goes through insert/select in the jobs database.

Database integration¶

The supported database is MySQL.

HSM interaction¶

TReqS uses the HPSS API to get the metadat of files and to order the staging.

Administative interactions¶

Signals¶

On the server side, the service administrator can do some fancy stuff to control the behaviour of the server.

The following attributes in the configuration file are reloaded by the server when it gets the USR1 signal :

pkill -USR1 treqs

• ACTIVATOR_INTERVAL
• DISPATCHER_INTERVAL
• DISPATCHER_FETCH_MAX
• QUEUE_SUSPEND_TIME

Configuration database¶

The configuration in the config database is read at each activator run.
The administrator can change any value :

• number of drives
• share for each user

Violent interactions¶

The treqs server has been designed to support without any damage a shutdown. On restart, the previous state of the server will be recovered from the database.
This means that a server shutdown is a legitimate way to stop everything.
Warning : all the clients will get stuck, unless the administrator changes manualy the status of the pending file requests.