Re: Post-commit hook failure.
Damyan,
On Sun, Feb 8, 2009 at 06:32, Damyan Ivanov <dmn@debian.org> wrote:
>> I'm not sure what you mean. You want to ignore incoming floods at the
>> soap level or just delay the IRC notifications to avoid flooding?
>
> Both. Avoiding IRC flood (per IRC network) will help avoid banning KGB
> from the network. Ignoring input at the SOAP level (per project) would
> avoid growing too big of a queue.
For the first issue, I've just tested it because I was sure that we
got that feature from the very begining, since it's enabled by default
in PoCo::IRC. I've sent a flood of 20 messages to my KGB instance on
canterville, the delivery took 20 seconds. In the IRC channel, that
resulted in 3x20=60 lines sent, of which the first 5 lines were
delivered almost instantly and then the flood protection kicked in:
the remaning 55 lines were delivered with 3 seconds delay between
each, totalling 143 seconds.
> Say commits come two per second and the maximum rate of IRC messages
> is 1 per second. If too many commits come, memory would exhaust, so
> there must be some limit.
Since the rate limit is enforced on IRC delivery, I'm guessing that
the actual memory consumption is quite low. I'd say that you'd need
millions of messages to fill up the memory. I think that the DoS
produced by the bot constantly posting messages for years is a bigger
problem :)
> Schedule::RateLimiter[1] could be used for input limitting (in
> non-blocking mode). That page also says that POE has a more
> heavy-weight solution to the problem, which may be more appropriate,
> since we are in POE land anyways.
I've read it, but I don't find any rate limiter module for POE...
Schedule::RateLimiter could be used without problems inside a POE app,
but it doesn't handle burst mode. In any case, it's not difficult to
code a basic rate limiter, I'll give it a shot.
--
Martín Ferrari
Reply to: