Le 6 mars 2013 à 08:53, Heiko Braun <hbraun(a)redhat.com> a écrit :
I have some questions regarding your example, where you describe that a notification is
emitted (n1) when an attribute value changed and a client (curl) executes two subsequent
POST requests (p1, p2) to fetch notifications.
I am wondering what the semantics are for processing/delivering notifications. What can
clients expect?
- Stream of notifications: Clients get to see what exists at a given point in time. There
is the possibility to miss notifications.
- Durable subscriptions: Regardless of a clients availability and polling interval, it
will always get all notifications since the last time it connected. It's not possible
to miss notifications.
- Time windows: Notifications are kept for a certain amount of time, during that interval
clients get the same snapshot, regardless how many times they poll? It's possible to
miss notifications if the polling frequency is much bigger then the window size.
None of the above.
I describe it at the end of this section[1] but it may not be not clear enough.
One each POST request, the client will receive the N most recent notifications that were
emitted since its last POST request. Once the POST response is sent, the server will flush
the notifications held for this client. He will not receive twice the same notification.
It is possible to miss notifications if the client does not poll often enough and there
are more than N notifications emitted. This is a compromise to prevent exhausting server
memory by having clients register a listener and never poll its notifications that'll
fill up the memory.
Having a sensible value for N (e.g. 1024) should leave enough time for a client to poll
regularly and not miss most notifications.
Does that answer your question?
jeff
[1]
https://community.jboss.org/wiki/AddNotificationSupportToTheDomainManagem...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/