Le 26 févr. 2013 à 13:57, Heiko Braun <hbraun(a)redhat.com> a écrit :
It makes sense if we speak about async callbacks to notification
handlers. But for the polling based approached you described, there will be time T between
each client poling for notifications. Now if notifications are not kept (persisted
somehow, memory or otherwise) for that window clients will miss them. That's the TTL i
was talking about.
Ah ok, I see.
Yes, with a polling-based approach, we would have to keep the notifications until the HTTP
client fetches them.
I'd keep it simple and have a rolling buffer for each notification handlers would be
enough: e.g. keeping only the 1K most recent notifications.
Every time the HTTP client fetch them (with a POST), the buffer is flushed so the memory
constraint is bounded.
The QoS of remote notifications should be clearly stated. I don't think we need to
provide reliability (keeping the notifications until the HTTP clients acknowledges them)
or persistence (keeping notifications upon server restart).
If the clients really need that type of QoS from notifications, he'd be better served
using a messaging system instead[1] :)
jeff
[1] HornetQ allows to receive notifications using a JMS destination instead of using a
remote JMX connector.
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/