Difference between revisions of "OS4X Core - understand the queueing system"
| (11 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | === 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: | 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 web interface | ||
| − | *use the command line interface | + | *use the command line interface using the command "[[OS4X_Core_binaries#os4xeq|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. | 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: | 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 [[OS4X Core configuration#run OS4X programs as user|here]] | + | *the file must be readable by the process running OS4X (which may be configured [[OS4X Core configuration#run OS4X programs as user|here]]) |
*the entry must be in the state "new in queue" | *the entry must be in the state "new in queue" | ||
| − | *the entry must fit to the OS4X server ID running the process (see [[OS4X Core parallel installation|documentation on parallel installations]] | + | *the entry must fit to the OS4X server ID running the process (see [[OS4X Core parallel installation|documentation on parallel installations]]) |
*the target partner entry must be active if an "active" row is configured [[OS4X Core configuration#active_column|here]] | *the target partner entry must be active if an "active" row is configured [[OS4X Core configuration#active_column|here]] | ||
| − | *a defined media must be set for that partner (see configuration [[OS4X Core configuration#column_defining_connection_type_.28ISDN.2C_TCP.2FIP_or_TCP.2FIP_TLS_secured.29|here]] and [[OS4X Core configuration#value_for_connection_type_in_above_defined_colum_defining_ISDN_connection.2C_value_for_connection_type_in_above_defined_colum_defining_TCP.2FIP_connection_.26_value_for_connection_type_in_above_defined_column_defining_TLS_over_TCP.2FIP_connection|here]] | + | *a defined media must be set for that partner (see configuration [[OS4X Core configuration#column_defining_connection_type_.28ISDN.2C_TCP.2FIP_or_TCP.2FIP_TLS_secured.29|here]] and [[OS4X Core configuration#value_for_connection_type_in_above_defined_colum_defining_ISDN_connection.2C_value_for_connection_type_in_above_defined_colum_defining_TCP.2FIP_connection_.26_value_for_connection_type_in_above_defined_column_defining_TLS_over_TCP.2FIP_connection|here]]) |
| + | *The maximum sending channels for this partner is not reached. This parameter is either globally configurable [[OS4X Core configuration#default_maximum_parallel_send_processes|here]] or on a per-partner basis via [[OS4X Core configuration#amount_of_parallel_sendings|this]] parameter. | ||
| + | |||
| + | |||
| + | If all these pre-conditions are met, an additional time is being slept (defined through the parameters documented [[OS4X Core configuration#additional_sleeping_time_for_send_queue_daemon_.26_additional_sleeping_time_factor_for_send_queue_daemon|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 [[OS4X Core configuration#delete_send_queue_entries|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 [[OS4X Core configuration#OFTPv1:_Don.27t_wait_for_EERP_message|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 "<code>9</code>") 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 [[OS4X_Core_configuration#run_OS4X_programs_as_user|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 [[OS4X_Core_configuration#send_queue_entry_status_after_abort|here]]. | ||
Latest revision as of 17:09, 14 November 2012
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.