Comment by Yuioup | Hacker News Reader

Comment by Yuioup | Hacker News Reader

Parent Full thread

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)

I 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.

You could also just pop it behind a CDN, it looks like it's all static content anyways.

This 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?

The 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.

You 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.

Pretty 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.

Reply on news.ycombinator.com