Don't let the client wait too long when it reconnects because of a
broken connection.

Don't allocate additional memory in the trie if we are over the limit.

After reconnecting, either ignore the config update (if the config is
the same we have) or wipe out the old config first to free the memory.

Don't let the client wait too long when it reconnects because of a
broken connection.

Don't allocate additional memory in the trie if we are over the limit.

After reconnecting, either ignore the config update (if the config is
the same we have) or wipe out the old config first to free the memory.

Otherwise, the errors might be overwritten or some other bad things may
happen.

We are using features of API version 2, so don't forget to increase it.

Call a plugin's callback whenever a child terminates. Increases the API
version, as there's an added callback in the structure.

If we mark them as explicitly rejected or dropped by an IPset from the
server-side blacklists, then don't let it in. We don't need to test if
the IP is attacker, we already know that.

Use „Fwup“, as this is automagically deduced by some auxiliary scripts.
It is easier than hacking all these scripts.

This situation is rare, but actually can happen, because the client may
reconnect/restart or join the group before it received the config. Just
warn in such case instead of crashing and ignore the request (the server
will be OK if it doesn't get the answer, it waits for a timeout anyway).

When there's an exception during a looping call, don't abort future
calls of the callback. In case of database error or something, we want
to continue operating with the next attempt.

They help only a very little, but slow down the cache computation a lot.

Since TRUNCATE has the same problems as REFRESH MATERIALIZED VIEW.

Use a table & view to fill it with data instead of materialized view. It
is similar in principle, but the table allows us to specify indices and
updates concurrently, instead of locking the whole table.

Wait until the DB starts accepting connections if it doesn't work at the
beginning. Blocking.

Detect when a database connection dies and reinitialize it.

As it is supposed to be faster by dropping it, it shall release some
resources in the server.

Recover from lost DB connection. Initialize a new one.

Disable the old connection without compression. It is no longer used, so
don't sit on the port.

Use diff_addr_store.py in the master flow plugin, to share the same code
with FWUp to handle updating the address sets.

Don't leave old values in the sets when the plugin starts and does a
full update. They might be gone by now, so do a full replace of the set.