On 14 Nov 2013, at 18:23, Kohsuke Kawaguchi <[email protected]> wrote:
> On 11/13/2013 11:58 PM, Luca Milanesio wrote: >> We need to make some tests on the scalability of the events API because of: >> 1) need to monitor over 1000 repos (one call per repo ? one call for all ?) >> 2) by monitoring the entire jenkinsci org, 300 events could be not enough in >> case of catastrophic events > > The good news is that the push that removes/alters refs also take time. I > have the notification e-mail from your push to 186 repos, and it spans over > an hour. True: however possibly the notifications took an hour but the push was pretty fast but still around 25 / min. 300 events per minute should be then fairly enough :-) The only way to go over that limit is parallel push by multiple accounts ... but that I would say is very unlikely. > > So I'm hoping that polling 300 events every minute would cover us pretty > well. And like you say, a webhook can help us reduce this window down even > further. Yep. > > > There's another reason I'm optimistic about this scheme. > > Suppose you are maliciously trying to cause data loss. If we are regularly > recording refs, you have to mount an attack immediately after some commits go > in so as to overwhelm the 300 event buffer, then keep that saturation going > so that your ref updates/removals will also be dropped from the event buffer. > And even with this much effort you can only cause the data loss of the > commits that went in right before yours. > > So I think it makes the attack so ineffective that we can tolerate that risk, > and I find it unlikely that no accidents will look like this. Agreed. Luca. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
