Page History
...
The prototype code includes new classes and interfaces making up the
event system itself, some event consumer classes, and a large
set of changes to the codebase. The changes are to implement the
event system, and also to remove the old calls search and browse index updates,
since they are now handled through event consumers.
It adds event consumers for search and browse systems which will be
the only means to automatically update the search and browse indexes.
It also includes an event-based implementation of the Subscribe function
( email sent to an EPerson about new/changed Items in subscribed collections)
to demonstrate what can be done with asynchronous event processing.
The prototype supports multiple configured event dispatchers, so each
application (or even each Context within an application) can choose
a dispatcher appropriate for its needs – e.g. interactive apps can
process search updates immediately, while batch imports defer them
to improve performance.
The old HistoryManager is removed and is not replaced by this implementation. See the History Prototype page for a new implementation.
This code has only be tested against the PostgresQL 7.34 and 8.1 databases; I would
appreciate information about experiences with other databases.
...
Here is a list of all the configuration keys, topic, followed by
by an example (default) fragment of your configuration file.
...
event.consumer.name.class - Creates a consumer named name, the
value is a fully-qualified Java class name that implements the consumer.
There must be a corresponding filters configuration.
event.consumer.name.filters - Defines a set of event filters
for the named Consumer. The value is a list of "filters" which select
the events this consumer will see, selected by combinations of
DSpace object type and action. The filter list value consists of a
set of filter
clauses separated
by colons (:). Each clause is a set of DSpace Object types, a
plus sign (+), and a set of actions. The object and action lists are
separated by vertical-bar (|). Here is a rough grammar:
...
Whitespace and case are ignored in the filter list, so e.g. ALL is as good as all.
Dispatchers
...
event.dispatcher.
...
name
...
.class
...
- Creates a dispatcher named name, the
value is a fully-qualified Java class name that implements the dispatcher.
There must be a corresponding
| Code Block |
|---|
consumers |
configuration.
...
event.dispatcher.
...
name
...
.consumers
...
- List of consumers to which
this dispatcher sends events. The value is a list of consumer clauses,
separated by comma (,). Each clause contains the name of the
consumer, which must correspond to a
| Code Block |
|---|
event.consumer |
configuration
as described above, followed by a colon (:) and a declaration of
whether it is
...
synchronous
...
or
...
asynchronous
...
. The words may
be abbreviated
...
sync
...
and
...
async
...
, and case is not important.
There must always be a dispatcher named
...
default
...
. This is the
dispatcher used when the application does not set any specific
dispatcher in the
...
Context
...
.
Choosing Dispatcher in Applications
To demonstrate configurable dispatchers, the
...
org.dspace.app.packager.Packager
...
application has a configurable dispatcher. The key is
...
packager.dispatcher
...
, the value is the name of a dispatcher. Default
is, of course,
...
default
...
.
Optional Asynchronous Support
...
The following keys configure the Event system's use of JMS. Note
that these are only needed if your chosen Dispatchers have any
asynchronous consumers.
...
jms.timeToLive
...
- sets the "time to live", for persistent messages
bearing asynchronous events, which is the time they will be kept around.
It is an integer measured in milliseconds.
Default is 2 days.
...
jms.messageType
...
- type of JMS message to use for asynch events.
Not used by ActiveMQ, but it might be needed by a different
JMS provider, so the configuration mechanism is ready.
...
jms.broker.uri
...
- URI of broker to use when creating the first
...
ConnectionFactory
...
. See ActiveMQ 4.0 documentation
Documentationfor details about how to configure this.
...
jms.configuration
...
- URI of XML configuration file for JMS java beans.
Used by Spring to configure ActiveMQ. The default value,
...
xbean:/activemq.xml
...
looks for a file
...
activemq.xml
...
in the DSpace config directory.
See ActiveMQ 4.0 documentation
Documentationfor instructions on the contents of this file, or follow the example.
...
The default version of the ActiveMQ configuration file will be
in your install directory under
...
| Code Block |
|---|
/dspace/config |
) and modify it
if necessary, consult
the ActiveMQ 4.0 documentation
for details.
The version supplied works with a PostgreSQL database.
...
Overview
Content Tools