[Aaron-devel-cvs] CVS: aaron/doc architecture,NONE,1.1

[Sean C. <the...@us...>]

Update of /cvsroot/aaron/aaron/doc
In directory usw-pr-cvs1:/tmp/cvs-serv27653

Added Files:
	architecture 
Log Message:
First cut at aaron's architecture.  This needs to get reworked


--- NEW FILE: architecture ---
$Id: architecture,v 1.1 2001/06/29 08:51:37 thetitan Exp $

Aaron's architecture

/--------------------------------------------------------------------------------------------------\
|                                                                                                  |
| Aaron - Task Scheduling, exception, and monitoring machine                                       |
|                                                                                                  |
|  /------------------\  /--------------------------------------\                                  |
|  |                  |  |                                      |                                  |
|  | Stats Manager    |  |  Config Loader and Data Validator    |                                  |
|  |                  |  |                                      |                                  |
|  \------------------/  \--------------------------------------/                                  |
|                                                                                                  |
|                                                                                                  |
|                                                                                                  |
|  /------------------\  /------------------------------------------------------------\            |
|  |                  |  |                                                            |            |
|  | Network sync for |  | Action Manager                                             |            |
|  | incoming data in |  |                                                            |            |
|  | queue (locking   |  |  /------------------------------------------------------\  |            |
|  | and syncing      |  |  |                                                      |  |            |
|  | mechanism)       |  |  |  Event Manager                                       |  |            |
|  |                  |  |  |                                                      |  |            |
|  +------------------+  |  \  Instances of actions that can be used in AR (action |  |            |
|  |                  |----+ \ reaction) transactions.  If an action is removed    |  |            |
|  | Queue of action and   \+ \ from the Action Manager, then the departing        |  |            |
|  | reaction transactions. | | action instance inspects the queue and will either |  |            |
|  | Action and reaction    | | invalidate the transaction, or see if the          |  |            |
|  | transactions are a     | | transaction can complete with the missing AR       |  |            |
|  | collection of action   | | component.                                         |  |            |
|  | and reaction           | |                                                    |  |            |
|  | references.  Upon the  | \----------------------------------------------------/  |            |
|  | addition of either an  |                                                         |            |
|  | action or reaction to  |                                                         |            |
|  | a transaction          | /----------------------------------------------------\  |            |
|  | container, the         | |                                                    |  |            |
|  | instance of the action | |  Response Manager (reactive actions)               |  |            |
|  | or reaction in their   | |                                                    |  |            |
|  | respective manager     | |  Instances of actions that can be used in AR       |  |            |
|  | is notified that way   | |  transactions.  If a reaction is removed from the  |  |            |
|  | when an action or      | |  the Reactive Manager, then the departing reaction |  |            |
|  | reaction is updated or | |  instance inspects the queue and will either       |  |            |
|  | deleted from their     | |  invalidate the transaction, or see if the         |  |            |
|  | respective manager,    | |  transaction can complete with the missing AR      |  |            |
|  | the transaction can    | |  component.                                        |  |            |
|  | either be invalidated  | |                                                    |  |            |
|  | or can continue        | \----------------------------------------------------/  |            |
|  | depending on the       |                                                         |            |
|  | configuration.         |                                                         |            |
|  |                        |  If an action is removed from the Action Manager, then  |            |
|  +------------------+-----/  the departing action instance inspects the queue and   |            |
|  |                  |  |     will either invalidate the transaction, or see if the  |            |
|  | Network sync for |  |     transaction can be completed with the missing Action   |            |
|  | outgoing data in |  |     component.                                             |            |
|  | queue (locking   |  |                                                            |            |
|  | and syncing      |  \------------------------------------------------------------/            |
|  | mechanism)       |                                                                            |
|  |                  |                                                                            |
|  \------------------/                                                                            |
|                                                                                                  |
|                                                                                                  |
|  /----------------------------------------------------------------------------------\            |
|  |                                                                                  |            |
|  |  Thread manager                                                                  |            |
|  |                                                                                  |            |
|  |  Responsible for making sure that every thread that is delligated to a task      |            |
|  |  from the AR queue has a timer set to make sure the action doesn't take too      |            |
|  |  long, a soft memory limit (RAM), and an exception layer that will catch all     |            |
|  |  possible exceptions that a thread could throw.  A thrown exception by a         |            |
|  |  thread is caught and passed down the stack in an AR transaction until it is     |            |
|  |  dealth with until it hits the default aaron reaction manager and spits an       |            |
|  |  error to the log file.  If a transaction is flagged as having a system call     |            |
|  |  (that is executed outside of aaron such as a fork or a system call that         |            |
|  |  could block the parent), then the thread manager is responsible for spawning    |            |
|  |  a special thread that will fork once for the transaction management (sets a     |            |
|  |  semephore for shared memory, locking, etc) and the newly forked process will    |            |
|  |  fork from itself whenever the system call is made that way the parent aaron     |            |
|  |  process is never caught waiting for an external system call to finish.          |            |
|  |                                                                                  |            |
|  \----------------------------------------------------------------------------------/            |
|                                                                                                  |
|  /----------------------------------------------------------------------------------\            |
|  |                                                                                  |            |
|  | Logging Manager                                                                  |            |
|  |                                                                                  |            |
|  | As opposed to the Stats Manager which is a data collection device (dynamically   |            |
|  | definable collection device based on the configuration), the logging manager     |            |
|  | is responsible for outputing anything not caught in an AR Transaction and        |            |
|  | logging this uncaught transaction to disk).                                      |            |
|  |                                                                                  |            |
|  \----------------------------------------------------------------------------------/            |
|                                                                                                  |


Notes:

Config File Loader and Validator loads once on startup in a special invocation.  Upon the completion
of the Loader's execution, the Loader registers itself as an Action with the Action Manager and
schedules itself as a transaction that needs to be rerun as specified in its own configuration files
or as by default (10 minutes).


The Config Loader will register new actions after the data that has been read in has been validated.

A new Action that is being registered will register itself in the following order:
  Action Manager
  Stats Manager