https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6876

--- Comment #3 from John Hardin <[email protected]> ---
(In reply to comment #2)
> (In reply to comment #1)
> > I've suggested it before and I'll suggest it again: if the volume of
> > sa-update downloads is larger than we're comfortable supporting with
> > available infrastructure, then the config files should try using the
> > official mirror servers.

Argh! I don't know how "official mirror servers" crept into that comment.

What I've suggested before and was suggesting again here was to first try
CORAL-ified URLs.

> > This is simple, transparent, automatically
> > distributed, retrieves from a cache server topologically near the requesting
> > host, and is (in my experience) reliable. It also makes updates robust in
> > the face of temporary unavailablility of the mirror servers.
> > 
> > I'm not offering this as an alternative to code changes that rate-limit
> > sa-update download attempts, but as anothar approach to use along with such
> > limits to manage load.
> 
> I believe this issue is that these are unnecessary checks. For example bug
> 6655.
> 
> If someone is checking for updates, that just hits DNS and is minor.  But we
> have systems for no known reason checking repeatedly for updates.  
> 
> While I agree with you John, the reality is that replacing and keeping the
> existing infrastructure running for the entire project is time consuming.  I
> want to try and focus on publishing code rather than changing/improving
> infrastructure as much as possible.  

Trying CORAL first is no change whatsoever to infrastructure, I apologize that
my misstatement about "official mirror servers" gave that inpression. It is
either a minor change to the base sa-update URLs file, or a (likely) minor code
change in sa-update, to first try downloading:

  http://buildbot.spamassassin.org.nyud.net:8080/updatestage/1422798.tar.gz

before trying to download:

  http://buildbot.spamassassin.org/updatestage/1422798.tar.gz

simply append ".nyud.net:8080" to the base host FQDN and you try to retrieve
the file from a transparent automatic distributed cache service.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to