This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-18
Channels
- # admin-announcements (3)
- # alda (1)
- # boot (85)
- # capetown (4)
- # cider (10)
- # clara (16)
- # cljsrn (3)
- # clojars (35)
- # clojure (83)
- # clojure-austin (8)
- # clojure-brasil (4)
- # clojure-canada (16)
- # clojure-greece (2)
- # clojure-ireland (7)
- # clojure-russia (23)
- # clojure-spec (22)
- # clojure-uk (151)
- # clojurescript (97)
- # core-async (10)
- # cursive (1)
- # datascript (7)
- # datomic (21)
- # defnpodcast (13)
- # devcards (3)
- # emacs (4)
- # events (3)
- # hoplon (18)
- # juxt (4)
- # leiningen (7)
- # mount (4)
- # off-topic (2)
- # om (1)
- # onyx (30)
- # planck (6)
- # proton (81)
- # re-frame (3)
- # reagent (9)
- # rum (10)
- # spacemacs (1)
- # specter (6)
- # testing (7)
- # untangled (66)
- # vim (84)
- # yada (23)
Anyone else seen this error trying to deploy a new release: Could not transfer metadata my-tmpl:lein-template/maven-metadata.xml from/to releases (
? Tried 2 different releases and gotten this error both times. status says clojars is 100% up.
@cap10morgan: yes, that's been reported, but we have no idea of the cause right now https://github.com/clojars/clojars-web/issues/546
ah, OK. pretty quickly.
we are using maven-medata.xml as a trigger to validate the deploy, copy it from a tmp repo to the live repo (part of the atomic deploy feature), and, just recently, to copy the project to Rackspace cloudfiles in anticipation of serving the repo from a CDN
@cap10morgan: I saw that error, but the release seemed to deploy successfully anyway.
@tcrawley: the error seemed to occur within a few seconds
OK, that’s good at least 🙂
@daveliepmann: was your error with maven-metadata.xml as well?
Yes: Could not transfer metadata uruk:uruk/maven-metadata.xml from/to clojars (https://clojars.org/repo/): Read timed out Failed to deploy metadata: Could not transfer metadata uruk:uruk/maven-metadata.xml from/to clojars (https://clojars.org/repo/): Read timed out
@tcrawley: want me to do another one w/ some debugging output turned on?
I suspect we may need to move uploading to cloudfiles to a queue that gets processed async
@cap10morgan: let me add some timing output to the server side, give me a few minutes
OK, sounds good
those are pretty small, I was thinking it was large uploads to cloudfiles causing the issue
@cap10morgan: @daveliepmann: I added some profiling to the validation and upload-to-cloudfiles code, and deployed a small test app
yeah, it looks like 10s may be the default - I just recreated the issue by increasing the jar size to 23k
the validate+upload took 9800ms, and it's safe to assume we're spending another 200ms outside of that process to get us over 10s
I'm going to disable the cloudfiles upload for now, since we're not yet using the artifacts uploaded there
@cap10morgan: @daveliepmann: the cloudfiles uploads are now disabled in production. I just deployed my testapp, and the deploy time went from ~10s to 200ms. Please let me know if you continue to see the problem
@tcrawley: cool, will do. thanks!