Execution model vs Thread.sleep

[Marcin Kulik]

I created a simple "wait" ring handler which waits for 3 seconds (good old
Thread.sleep), and then returns text "done" as the response body (note: I
use Compojure to route to this handler).
I use Aleph but I am not using any Aleph/Manifold/Netty specific features
here.
I created bash script which hits Aleph with curl, 200 parallel requests
(curl http://localhost:3000/myhandler & curl
http://localhost:3000/myhandler & curl http://localhost:3000/myhandler &
...).
To my surprise, I got all 200 responses roughly after 3 seconds.

How is this possible when Thread.sleep blocks the thread, and Aleph uses
2*cpu-cores threads for processing requests? (I have 4 cores)
Is it creating 200 temporary threads to handle this?

I'm switching to Aleph from Jetty because one of my handlers (let's call it
"upload") is uploading file to S3, and I want the synchronous upload
(clj-aws-s3) to happen on my own core.async based, bounded uploader pool.
So I'm returning Manifold deferred from the handler (s/->source
channel-with-eventual-upload-response). Seems to be working great. However,
the above test with "wait" endpoint confused me, and before I put more work
into my main goal ("upload" endpoint), I'd like to understand what's really
going on in there.

[Marcin Kulik]

Clarification about why I'm doing this dance with bounded uploader pool: I
assumed that doing blocking HTTP call with clj-aws-s3 from my handler will
occupy one of Aleph's processing threads until the upload is finished, and
if I have 4 cores, Aleph uses 8 threads, and if 8 upload requests hit my
server no new request will get served until at least one of the 8 uploads
finishes. But I guess I may have made wrong assumption, as we're in NIO
land?

[Zach Tellman]

Hi Marcin,

In order to make sure Aleph is a drop-in replacement for other
Ring-compliant servers, by default it puts another thread pool behind the
Netty event loops. If you want to disable this feature, you can specify
`:executor :none` in the aleph.http/start-server options map, or specify a
different executor if you're looking for specific behavior.

Zach

Post by Marcin Kulik
Clarification about why I'm doing this dance with bounded uploader pool: I
assumed that doing blocking HTTP call with clj-aws-s3 from my handler will
occupy one of Aleph's processing threads until the upload is finished, and
if I have 4 cores, Aleph uses 8 threads, and if 8 upload requests hit my
server no new request will get served until at least one of the 8 uploads
finishes. But I guess I may have made wrong assumption, as we're in NIO
land?
--
You received this message because you are subscribed to the Google Groups "Aleph" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.