Hi guys,
Under current Hedwig semantic, a subscriber cannot aware of messages
published before he subscribes the topic. So in following example, subscriber A
can only receives messages after seqId 2.
---------------------------------
Topic T: msg1 msg2 msg3 msg4 ...
| <- subscriber A subscribe the topic
---------------------------------
This semantic is very reasonable, but Hedwig client needs to handle this
corner case: a new topic is just to be created, and as topic is lazily created
by the first request (generally it's PUB or SUB), so the client side must
coordinate between publisher and subscriber to make sure the first SUB is
handled before the first PUB at this very beginning status (consider subscriber
may have very bad network connection which causes SUB failed and user does not
want to miss any messages). In summary, it requires special works if there is a
subscriber would like to receive all the messages since topic is created, and I
think this requirement is very general.
Handle this problem in client side is a choice, but I think maybe we can
simply resolve it in server side if Hedwig can support queue semantic (so that
we can also extend Hedwig JMS provider to support JMS queue in BOOKKEEPER-312).
And as I known, the major concern on queue semantic is how long to keep the
messages, however:
1. It is user's responsibility to know about the feature and impact of queue
semantic.
2. On the other hand, we can add a parameter to limit the queue length.
In a word, here are the two problem I would like to discuss:
1. How to gracefully resolve the above issue in server side under current
semantic.
2. Whether or not to introduce queue semantic into Hedwig.
Thanks,
Jiannan
