Guarantees » History » Version 7

J. Wienke, 05/16/2011 12:24 PM

1 1 J. Moringen
h1. Guarantees
2 1 J. Moringen
3 1 J. Moringen
h2. Quality of Service
4 1 J. Moringen
5 3 J. Moringen
For listeners, any guarantee applies to the stream of events received from the bus (not to the entire processing of a given event). In particular, it is possibly that the effective guarantees are weaker than those specified for the listener (if the informer has weaker guarantees than the listener).
6 3 J. Moringen
7 3 J. Moringen
For informer, any guarantee applies to the submitting of events to the bus. Guarantees at the receiving end may effectively be weakened depending on the listener configuration.
8 3 J. Moringen
9 1 J. Moringen
_In the following lists of guarantees, subsequent items include all guarantees given by preceding items._
10 1 J. Moringen
11 7 J. Wienke
QoS only applies to framework code. If e.g. an asynchronous user handler throws an error it is the user's task to notice this. For the framework the message was delivered. -> logging is ok
12 7 J. Wienke
13 1 J. Moringen
h3. Ordering
14 1 J. Moringen
15 1 J. Moringen
# Unordered: Events are delivered in (potentially) arbitrary order.
16 1 J. Moringen
# Ordered: Every listener receives the events of one informer in the order the informer sent the events. No guarantees are given for events of multiple informers.
17 1 J. Moringen
18 1 J. Moringen
Independent of the requested ordering, no relation is guaranteed for events arriving at multiple listeners.
19 1 J. Moringen
20 1 J. Moringen
h3. Reliability
21 1 J. Moringen
22 1 J. Moringen
# Unreliable: Events may be dropped and not be visible to a listener.
23 1 J. Moringen
# Reliable: Messages are guaranteed to be delivered. Otherwise an error is raised.
24 1 J. Moringen
25 1 J. Moringen
h2. Threading
26 2 J. Moringen
27 2 J. Moringen
* Informer is thread-safe
28 2 J. Moringen
* Listener is thread-safe. This implies:
29 4 J. Moringen
** Adding/Removing filters from arbitrary threads is possible but does not affect other already registered filters
30 4 J. Moringen
*** the changes will be applied sometime after the method call, but not synchronized with the method call
31 4 J. Moringen
** Add/Remove handlers from arbitrary threads is possible but does not affect other already registered handlers
32 4 J. Moringen
*** existing handlers will not noticed and effect on the event stream for changes of different handlers
33 5 J. Moringen
*** for the added or removed handler as a default no guarantee is given that it will be called immediately / won't be called anymore when the add/remove method returns. Nevertheless, a flag can be set to achieve these guarantees.
34 6 J. Wienke
* Services are thread-safe