We can also allocate only a fixed memory amount for holding
subscriptions
(the limit may be set by user). If the limit is exceeded, we can
either
report error or switch the filtering off.
It's not clear is the limit is a size of the tree, or buffer size? If
it's
size of the tree, then how large buffer can be (if it's filled by
unsubscriptions). If the limit is buffer size, then (apart from being
what
I've proposed in the first place), it may be lower than the size of
the
tree. But nevermind, we can have two different limits to cover all
cases.
The other thing is not clear too. Reporting error of overflowing size
of
the tree is ok. However, as indicated above it's not enought. If we
report
error of buffer overflow, then what can user do to it? Never do any
subscription from this point on? Close and reopen the whole socket?
Ah, ok
in case of one publisher it would work (user knows which publisher is
failing, and reopening connection to failing pubslisher is not a
problem
either). Another option: switch filtering off. I don't even understand
how
it can work. The publisher already received some subscriptions. For
him to
know that filtering is off it should receive a message (which is
stalled in
pushback). We could close that overloaded connection and start a fresh
new
one with filtering disabled, but I don't like this idea.
All in all, the limit of the number of subscriptions seems to be a
nice
idea, but doesn't solve any problem by itself. Combining it with some
heuristics for buffer size and reconnect mechanics along the lines of
what
I've described in previous mail would work for me.
