Clojurians Log v2

Any idea what could cause Broken Pipe Exception when deploying to Clojars?

E.g. https://circleci.com/gh/cljsjs/packages/1443

Interestingly build 1436 succeeded and I haven't changed configuration after that

@juhoteperi: I don't see any errors in the http://clojars.org logs. I do see entries for the files that were successful, but nothing for the failed jars

can you try against http://clojars.org/repo/ instead? http://repo.clojars.org 302's to http://clojars.org/repo/, but something may be causing that initial request to timeout for some reason

though you would think that would affect all the files, not just the jars

Could the cdn have size limit?

Though the jars shouldn't be particularly large, 700KB or something

hmm, I wonder. maybe there is a limitation there - the full file may be uploaded before the 302 is issued, which would mean 1) the cdn would need to accept the full size, and 2) aether will upload each file twice

302'ing may be a bad idea :(

hmm not sure how http works in this case

trying direct url now

direct url works

Could Fastly be configured to just proxy PUT requests to real server?

Based on CDN announcement, there is currently one origin set up for Fastly, Rackspace Cloud Files

I think it would be possible to set up http://clojars.org/repo/ as another origin, and add request rule to direct PUT requests to that and not cache them

Then there wouldn't be need for redirect

@juhoteperi: I don't understand, what do you mean by "another origin"? http://clojars.org/repo/ is the canonical deploy url, and the legacy read url. The redir solution that is currently in place is just to support boot, since it doesn't have a concept of two different urls for the same repo

the CDN currently doesn't cache anything uploaded to it, it just tries to redirect to http://clojars.org/repo/

the http://clojars.org server then uploads to Cloud Files once the upload is complete, then it can be served by the CDN

I'll see if I can proxy from the CDN instead of redirect though

that may not be an option

Is it normal for maven repos have different read and deploy urls?

We talked about adding support for separate deploy urls on #boot but weren't sure how common this is

well, for nexus, you do have different urls, because deploys go to a staging repo first, so you are deploying to that

I'm not sure about archiva, but nexus is the primary repo implementation

@tcrawley the proxying should be fine, I'm pretty sure Fastly will stream it through without holding onto it all

cool, we just need to figure that out

"origin" is the source for CDN, if I understand correctly, currently CDN loads files from Cloud Files

But CDN probably can have several origins

@juhoteperi yep, that’s what we want to do I think. To clarify, this is probably what we want to happen: * GET/HEAD requests to Fastly are cacheable and go to Rackspace cloudfiles * POST requests to Fastly are passed straight through to the http://clojars.org webapp

Yeah