4 ms·
java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:714) at java.u
by Yuioup 9y ago
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:714)
at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:950)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1368)
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134)
at clojure.core$future_call.invokeStatic(core.clj:6687)
at ring.middleware.gzip$compress_body.invokeStatic(gzip.clj:70)
at ring.middleware.gzip$compress_body.invoke(gzip.clj:70)
at clojure.lang.AFn.applyToHelper(AFn.java:154)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.core$apply.invokeStatic(core.clj:648)
at clojure.core$update_in.invokeStatic(core.clj:5950)
at clojure.core$update_in.doInvoke(core.clj:5939)
at clojure.lang.RestFn.invoke(RestFn.java:445)
at ring.middleware.gzip$gzip_response.invokeStatic(gzip.clj:87)
at ring.middleware.gzip$wrap_gzip$fn__12777.invoke(gzip.clj:95)
at aleph.http.server$handle_request$fn__9026$f__5083__auto____9027.invoke(server.clj:156)
at clojure.lang.AFn.run(AFn.java:22)
at io.aleph.dirigiste.Executor$Worker$1.run(Executor.java:62)
at manifold.executor$thread_factory$reify__4975$f__4976.invoke(executor.clj:44)
at clojure.lang.AFn.run(AFn.java:22)
at java.lang.Thread.run(Thread.java:745)
- aphyr 9y agoI had to migrate prod environments when Skyliner shut down; this is the first release I've done on Heroku. Clearly I should have provisioned more capacity. :) Should be back shortly.
- Myztiq 9y agoYou could also just pop it behind a CDN, it looks like it's all static content anyways.
- softwarelimits 9y agoThis is something I do not understand with java as a webserver - doesn't such behavior show a major design problem? "Lots of traffic" can be expected by any webserver software - handling "too much" of it in a not too painful way could be a design goal. Just spitting out an error on such a condition and making the site disappear is a little bit too simplistic for my taste. I have seen this error on sites with java webservers many times - is this an accepted limitation in the java world? I am not trying to be snarky here, I have lots of respect for aphyrs work, but I am really wondering about this "normal behaviour" of java webservers - how can an "enterprise platform" get away with this?
- aphyr 9y agoThe jepsen.io server is literally something I hacked together in a few weekends. I wouldn't really point to it as an exemplar of high quality production-facing engineering. :) That said, it does push 50,000 reqs/sec on my local box, did just fine on an AWS m3.medium, then fell over today at 5 reqs/sec on a heroku "pro" dyno, so... this is something I'll have to address.
- sandGorgon 9y agoYou should switch over to using Hugo and generating static html for most of your site. Deploying it to Firebase CDN or Netlify should cost you a few dollars every month.
- wmf 9y agoPretty much no web servers or apps are tested to destruction probably because few tools can even generate good overload. It's just an industry in perpetual infancy.