don't load plugins twice.
Not exactly sure where that feature crept in some time ago. It was suppressed by checking to see if a queue plugin was already registered, and then bailing out on subsequent register_hook runs. I noticed it in testing, b/c I didn't have a queue plugin loaded. This removes the duplicate calls to register_hook.
* adds caching of the AUTH methods. You can't add new plugins or register new
hooks w/o restarting QP, so cache the list and avoid having to generate it on every connection.
* other PBP changes (early exits, less indention, fewer unnecessary parens, etc.)
Previously the greylist plugin tried to use redis and fell back to DBM. This means that if a system already had an established DBM database, but happened to have Redis running, the existing DBM db would be abandoned for a new Redis DB. This would inevitably lead to more delays for legitimate mail, and possibly lost mail.
This adds a 'redis_server' argument which enables Redis and sets the location of the redis server; if it is not explicitly set, DBM is used instead.
If the redis server is unavailable, rather than failing to start QP, we instead fail to register the plugin.
Revert to default of -pt=1 rather than -pt=2:
> -bt,-pt,-sbt: Container tightness
> These are parameters for controlling the amount of space within containing
> parentheses, braces, and square brackets. The example below shows the effect
> of the three possible values, 0, 1, and 2, for the case of parentheses:
>
> if ( ( my $len_tab = length( $tabstr ) ) > 0 ) { # -pt=0
> if ( ( my $len_tab = length($tabstr) ) > 0 ) { # -pt=1 (default)
> if ((my $len_tab = length($tabstr)) > 0) { # -pt=2
> A value of 0 causes all parens to be padded on the inside with a space, and
> a value of 2 causes this never to happen. With a value of 1, spaces will be
> introduced if the item within is more than a single token.
The tight parens decision was made in 2005 when .perltidyrc was introduced:
2535e77293
I tried pretty hard but couldn't find any previous discussion about this
decision, I'm not quite sure who supported it, who cared about it at all,
or who knew about it at all.
What I know is that I like pt=1 better. Nobody ever gets what they want
if they don't ask :)
Destroy the AnyDBM-tied hash after untying
Google's wisdom seems to indicate that leaving the AnyDBM-tied hash around after
untying it was causing data to not flush to the DBM file... or something. At any
rate the regression test added here confirms inconsistency when using multiple
instances which is fixed by destroying the AnyDBM-tied hash after untying.
Previously, the GeoIP plugin would crash on certain missing GeoIP data.
Now it will continue to operate on whatever data it can get at.
Note that it already warns when any data it's looking for is missing.
