Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

asynchronous handler support #2

Open
mxx opened this issue Nov 15, 2017 · 3 comments
Open

asynchronous handler support #2

mxx opened this issue Nov 15, 2017 · 3 comments

Comments

@mxx
Copy link

mxx commented Nov 15, 2017

ring support asynchronous handler,
and undertow also support asynchronous process
it seems luminus do not.
or maybe I misunderstand something.

@yogthos
Copy link
Member

yogthos commented Nov 15, 2017

I'm not sure what you mean here. You can use async Ring handlers in Luminus out of the box. The async functionality is handled by Ring and Compojure libraries.

@poernahi
Copy link

I was experimenting with async handlers and come across this issue. It looks like the immutant adapter is synchronous if used as-is, and assumes 1 arg handler function. Supplying a 3 arg async handler will cause ArityException.

Example implementation: ring-jetty-adapter accepts an additional :async? option which wraps the async handler in an AsyncContext.

I'm not sure yet how to do this on top of immutant as the API is rather different.

Another thing to note when using luminus, is that most of the middlewares in the template only support single arity.

I'm not sure if this is worth doing yet, as the current blocking handler has been more than good enough for many use case. Would like to know your thoughts.

@yogthos
Copy link
Member

yogthos commented Dec 13, 2018

I actually haven't run into a situation where I needed to use the async handlers myself. I find the sync handlers are performant enough even for high loads. Note that the sync handlers don't block either until the thread pool is exhausted. Immutant uses a dedicated thread to accept connections, and then passes the actual request handling off to a thread pool of workers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants