community-build: Very slow updates when running community build locally

When running the community build locally I see very long (>= 10 mins) pauses coinciding with log output of the form,

[fs2] [info] Updating {file:/home/miles/projects/community-builds/target-0.9.5/project-builds/fs2-5a963db814460240b52e63b349e38ac1d658a6a7/project/}fs2-5a963db814460240b52e63b349

which I believe corresponds to an sbt update in the project about to be built. During these pauses I can see that the community build process is blocked on a socket read from,

java    7165 miles   70u  IPv4 4172377      0t0  TCP tarski.home:38968->ec2-54-67-111-226.us-west-1.compute.amazonaws.com:https (ESTABLISHED)

which corresponds to https://scala-ci.typesafe.com/. Is it possible that this machine is seriously overloaded? Or that it has limited connectivity with Europe?

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 50 (30 by maintainers)

Commits related to this issue

Most upvoted comments

Would it be possible to have scala-ci advertise a single (virtual?) repository which would do the whole job?

Probably, since that’s what I have in my local config — a single virtual repository, with two entries in my ~/.sbt/repositories, one for Maven-style access and one for Ivy-style access. So I assume the scala-ci Artifactory could be set up the same way. I’d have to ask Adriaan if there were specific reasons he set it up the way he did, or if he was just fumbling around. (“Fumbling around” is how I would describe my own engagement with this, I have little real understanding of what I’m doing.)

I haven’t done a cold timing recently, but 3.5 hours sounds very good — faster than it runs on Jenkins.

I did some work on this over the weekend — starting with a fresh local Artifactory config with only Maven Central, and then:

  • only adding resolvers as needed to resolve specific artifacts
  • never adding a resolver without using Artifactory’s “include filters” feature to ensure that the resolver is only used in specific situations
  • ordering resolvers so that specific, include-filtered resolvers come first and general resolvers come last

That, in combination with a nice long “Metadata Retrieval Cache Period” on all resolvers, seems to have fixed my own performance problems to my own satisfaction.

This is a little different than what Miles did, where his local Artifactory just retrieves everything from the Artifactory on scala-ci.

I took a different approach because my goal is for my new config to eventually replace the one on scala-ci, and hopefully that will result in improved performance for everybody, including our Jenkins runs, and people who are running locally using our Artifactory, and people like Miles who have a local Artifactory that points to ours.

But in order to make that happen, I’d have to upgrade the scala-ci Artifactory to a newer version, otherwise the XML config doesn’t carry over (and I don’t want to keep multiple versions in sync by hand). So, leaving this ticket open, but it is now fixed at least to the extent that:

  • Miles and I have satisfactory working configs
  • if anyone else wants to get up and running, I can give them good advice and not just flail or shrug

I plan to return to this in 2017.