• Handles messages for a defined set of entities
  • Keeps current state of entity instances in memory

Implementation details

  • May be scaled out (on multiple role instances), but each entity type must be handled by a single processor worker instance (no sharding)
  • May have multiple worker threads
  • Keeps all the entity instances in memory (see Entity Cache)
  • Processing of a single should be as fast as possible (no long-running operations)
    1. External dependencies must be resolved by submitting a new event to Event Dispatcher
    2. For a proof of concept, long-running processing operations should be investigated
  • Since the processor is multi-threaded, implementation must ensure that conflict between updates will not occur
    1. This is implemented by adding thread affinity to entity ids


Event Repository

Event Repository is a forward-only database repository for valid events. If Processor receives an event, first it validates against the current entity state, and if it passes, it stores the event in the repository. After that, it updates current entity state according to the result of the event, and commits changes to the entity cache.

Since events stored in the repository have already passed validation, they can be safely replayed after restart. For this end, event processing must be atomic, and have no external dependencies.

Since message validation operates on non-saved events, it must be implemented to be as fast as possible.

Entity Cache

Entity cache keeps track of the current entity state.
TODO: write this


1. Regular processing of events

TODO: write this

2. Processing of events with external dependencies

TODO: write this

TODO: should implement a fail-safe logic for the following scenarios:

3. Processor node restart

Entity cache must be restored upon restart
Processed events that are not persisted in Entity Cache Repository must be processed again
Received events that are not persisted in the Event Repository will be sent again by Event Dispatcher
Entity id affinity must be kept after restart

4. Event repost

If an event is sent again, Processor must process it according to the following algorithm:
  1. If the event is the most recent message available, it should process it as normal, and return success
  2. If the event is already processed but it is the most recent message, it should skip processing, but return success
    • In this case, result event will be routed to Dispatcher
  3. If the event is older than the most recent message available, it should check in the event repository for the event
    • If it exists, it should skip processing and return success
    • If it does not exists, it should return failure

Last edited Apr 3, 2012 at 3:55 PM by delzubu, version 2


No comments yet.