[zeromq-dev] Pls. advice on design/architecture.
Artem V12
artem.vysochyn at gmail.com
Sun Jul 29 00:39:52 CEST 2012
Hello there, 0Community!
I want to build some cool notification system based on 0MQ, but this's
gonna be challening effort. I read the guide(almost all) but didn't find
what can help me. So here's the thing:
I have a persistent layer where I store users and their preferences. The
preferences, essentially, are the filters against neverending flow of some
events (at this point it's doesn't matter what events represent by itself)
and can be updated at any time by user. One fact about events and user'
preferences - they can be matched together by certain prefix. So, at the
end of the day I have to have notification system which on arrival of
certain event has to match (by prefix in the messsage) corresponding user'
pref, then check that event matched is 'good', and send email to user.
Essentially I have to track the updates of certain stuff.
So I after reading the guide, it's more/less clear to me how to impl. this.
1. On one side there will be fanout broadcast of events which will bombard
by messages the two 0MQ boxes (second is backup).
2. On the other side - clients which has to be subscribed (by user' pref)
onto one of the two endpoints.
If understood 0MQ idea correctly then making some component to listen for
some events isn't hard thing. But here's the issue: user' prefs (i.e.
filters) are persistent and, worse, are subject to Create/Update/Delete.
So, say, in jvm, I will pull a user' pref, make it listen on ZMQ.SUB
socket, but while I was doing this user could Update/Delete his pref. Or
better - once user' pref is created - let it listen 'from the birth', but
the first restart of the box where user' pref is listening for events will
end the connection.
In general the problem I faced is: how to make persistent things to listen
in reliable manner?
Thanks in advance!
-regards
-artemv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120729/f99baa56/attachment.htm>
More information about the zeromq-dev
mailing list