OS4X Core - understand the queueing system

Enqueueing files

When sending a file in batch mode, you should enqueue a file into the OS4X send queue. In order to do this, you have several possibilities:

• use the web interface
• use the command line interface using the command "os4xeq"

In fact, you could also insert values into the MySQL database table "<tableprefix>send_queue", but when doing this you should contact an OS4X developer because the schema of the table could change.

Send queue daemon behaviour

When a file is enqueued into the send queue, the OS4X send queue daemon is responsible for sending this file to a partner. Some rules are set for sending files:

• the file must be readable by the process running OS4X (which may be configured here)
• the entry must be in the state "new in queue"
• the entry must fit to the OS4X server ID running the process (see documentation on parallel installations)
• the target partner entry must be active if an "active" row is configured here
• a defined media must be set for that partner (see configuration here and here)
• The maximum sending channels for this partner is not reached. This parameter is either globally configurable here or on a per-partner basis via this parameter.

If all these pre-conditions are met, an additional time is being slept (defined through the parameters documented here, in which the send queue entry is in the state "taken by send queue". If the following connection try fails, all send queue entries send try of that partner are raised by one. If the connection is properly set up and the file is transfered correctly, the entry of the send queue may be removed if this flag is enabled, otherwise it changes to "successfully sent".

automatic / semi-automatic EERP

So called "end to end responses" are possibly sent by the remote side, on which OS4X reacts. You may enable this switch for not to wait until an EERP is received in an OFTP1 session for setting the entry to "successfully sent" or remove it (see above).

Aborting send queue transfers

Active transfers can be aborted via web interface or on command line. "Active" transfers exist when a specific process exists for a send queue entry. These are in the states:

• taken by send queue
• send in progress

In both cases, the PID of the process is being displayed in the web GUI (and it is given in the PID column of the send queue database table).

There are two options for aborting an active send queue process:

• signal: sending a non-SIGKILL (not "9") signal to the process will abort the process. This assumes that the user sending the signal is the same as the process itself or it's the superuser "root".
• Set the status to "to be aborted" (8) in the table of the send queue. This status is read before each status change, so it could take a while to take this setting into affect (normally the case if the process has to wait some time until it begins to be transfered, which is in case for "taken by send queue" status).

The web interface tries to abort a send queue entry by sending a signal, and, if this fails, settings the status of the send queue entry to "to be aborted". This only works if the webserver and OS4X run on the same machine and if the webserver user ID is the same as the OS4X processes. The user under which OS4X processes are runnnig can be configured here if they are started by user root (which has the Unix permission to switch user context).

The status right after the abort can be configured here.