QueueReaders are persistent, stateful server-like objects, without sockets.
Clients queue requests for later processing.
Based on Offsiders, uses flexible object-oriented message passing.
Useful for coordinating the activity of system components, and controlling process flow.
QueueReader is an Offsider that understands how to queue asynchronous requests for sequential execution.
You create a specific QueueReader by cloning the original one, and giving it a name of your choosing. Once you have a new QueueReader, you can set it up and customise its functionality as you require.
Clients of the QueueReader can place requests on the queue independently of each other and independently of the processing of those requests. Once a request has been queued, it remains in the queue until it is processed. It will even survive rebooting the machine. During and after processing, the request survives as part of an audit trail.
The QueueReader will normally process requests on a First-in-first-out (FIFO) basis. Processing is completely independent of queueing, and can be switched on or off as required.
The contents of the request, and how it is processed, is up to the designer of the application system. Typically you would over-ride one or more QueueReader methods to define exactly what happens when a request is processed. Any programming language can be used for this.
Because QueueReader is based on Offsider technology, it fits very comfortably into the standard Unix environment. It is particularly suitable for bridging various components of a system, as a mechanism for coordinating their activity and exchanging information.
QueueReader is based on Offsider technology, and is itself an Offsider object. It is persistent, and can be cloned to create new instances. All interaction with (an instance of) QueueReader is by means of messages. Messages can be passed from the command line, or from a programming language that supports system calls.
QueueReader provides its instances with a number of methods which can be extended or over-riden as required. Any programming language can be used for this purpose.
A QueueReader allows clients to queue requests for later processing. This is done by using the methods supplied.
The requests are queued asynchronously, and independently of the processing of those requests.
Requests are placed on a queue. The queue is a directory, and each request is a file named with a unique timestamp.
The QueueReader processes the requests by running methods. These methods can be
modified to customise the QueueReader functionality. The method most likely to be
modified is called performRequest
.
The QueueReader normally processes requests in a First-in-first-out (FIFO) order. Methods are provided to do the next request, do the next N requests, or do all requests currently on the queue.
The QueueReader provides an audit trail, which allows you to see which requests were done, and what time they were processed. In the event of a system crash, you can determine whether or not processing was completed. This trail allows for the possibility of undo, rollback and rollforward, provided the programmer is able to supply the required functionality.
There is a method that can be used to archive the audit trail. This can reduce space and will improve system response if there are a large (10,000+) number of audited requests.
The QueueReader can be run as a daemon. status
, start
, pause
and stop
methods enable you to control the daemon. By setting a QueueReader key, (pipeDaemonTo
),
you arrange for the daemon output to be piped to a co-daemon. This
provides an easy way to customise the processing of the requests,
without actually modifying any QueueReader methods (since by default,
the QueueReader will pipe the request to its own stdout
).