[PATCH 02/15] Add a BAN_Shutdown() routine that is called before STV_Close(), and makes sure that the ban lists will not change until we exit.

[Martin Blix Grydeland]

On Mon, Nov 12, 2012 at 10:40 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>wrote:

> --------
> In message <1352287938-7247-2-git-send-email-martin at varnish-software.com>,
> Mart
> in Blix Grydeland writes:
> >This is to give persistent stevedores a chance to clean up their ban
> >lists without having to worry about the lists changing under them
> >(normally the ban callbacks are called under the ban mutex, but not so
> >during exit).
>
> I don't have a problem with the idea, but I don't like having BAN_Insert()
> return a failure we don't know how to handle.  I think BAN_Insert() should
> take ownership of the ban even when it fails, but returning a status code
> is probably a good idea, provided it gets used for something somewhere.
>

Changed to make BAN_Insert() always take ownership of the ban, freeing it
on failure. BAN_Insert() will still return the status code.


>
> I think it should be used in the CLI::ban case, so that a
> cluster-controller
> can keep track of which bans have been entered on which varnish instances.
>

CLI will get the error message.


>
> >Also remove the duplicate drop tail bans code. That is now only done
> >in the main thread loop.
>
> This breaks r01030.vtc so it should probably be done in its own commit.
>

This has been moved to a separate commit. Though I do not see how the
change affects r01030.vtc, nor have I been able to make that test case fail.

Martin

-- 
<http://varnish-software.com>*Martin Blix Grydeland*
Senior Developer | Varnish Software AS
Cell: +47 21 98 92 60
We Make Websites Fly!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20121119/655f625f/attachment.html>