Very slow startup after upgrade to Play 2.6.11

scala
sbt

(Bwbecker) #21

I don’t think filtering the resolvers works. When I load the build.sbt file and print “resolvers” at the SBT console, all I get back is the sonatype-snapshots. It seems to me that the jshint plugin must define it’s own list of resolvers that is managed independently of the resolvers I have access to in build.sbt.


(Marcos Pereira) #22

Now think about this happening 108 times, the number of client errors you reported. There is a pause between errors because there are requests to other repositories/resolvers - including the local one at the file system - to check the dependency.

How did you take it off the path? Using excludeDependency setting?

Using the dependency metadata as described here:

Next:

There is jshint itself and other sbt-web plugins. This is, in fact, the main repository for sbt plugins.

This is a Bintray repository, and maybe it was just a temporary problem. You can see Bintray was having some issues these days: http://status.bintray.com/.


(Marcos Pereira) #23

I think you need to override the externalResolvers setting instead. See https://www.scala-sbt.org/1.x/docs/Library-Dependencies.html#Overriding+default+resolvers. But, keep in mind you need to maintain https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases (the plugins repositories). So maybe you want to reorder them?

Also, since this is happening while resolving plugins dependencies, you may need to override/reorder the resolvers in project/plugins.sbt instead of build.sbt (I haven’t tried that though).


(Bwbecker) #24

marcospereira

    March 28

bwbecker:
In the many runs where I was watching the log file being printed, it seemed there was a noticeable pause around the printing of CLIENT ERROR. Sure enough, when I put https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/org.webjars.npm/shelljs/ into my browser and look at the network timings in Chrome’s dev tools, it takes 1.57sec to get a response that “The requested path was not found.” (using clear cache and hard reload).

Now think about this happening 108 times, the number of client errors you reported. There is a pause between errors because there are requests to other repositories/resolvers - including the local one at the file system - to check the dependency.

I don’t think this addresses my observation. Put the URL it was attempting to access (according to the error log) into Chrome. Chrome reports that it takes 1.57sec to get a response. Multiply that by the 108 errors and you get a l-o-n-g time without needing to factor in the retries.

Another question is why https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/ (which redirects to https://dl.bintray.com/sbt/sbt-plugin-releases/) takes so long to respond in the first place.
This is a Bintray repository, and maybe it was just a temporary problem. You can see Bintray was having some issues these days: http://status.bintray.com/.

I think this is a more likely explanation because when I retry the repo.scala-sbt.org URL today it resolves much more quickly (~350ms). That’s still 10x slower than the response from https://repo1.maven.org/maven2/org/webjars/npm/shelljs/.

That still leaves open the question of why jshint is hitting a repo 108 times for info that repo apparently doesn’t have.


(Marcos Pereira) #25

That is what I was trying to say. Slow multiplied by 108. :slight_smile:

It is not jshint. It is sbt trying to resolve the jshint plugin dependencies. And it needs to make a request to the resolver to know if it has the dependency or not. If none of the resolvers has the dependency, then you will get an error. That is why I was suggesting to reorder the resolvers so that the one you know that have the plugins is first one to be requested.

But keep this in mind: