How to make middelwares "manifold friendly"

[Alf Kristian Støyle]

Hi.

We're using Aleph with compojure, which is how I found the problem. However
I guess it is a general problem, when trying to keep the server async.

I added following to prevent compojure blocking on deferred, from
(https://github.com/ztellman/aleph/blob/master/examples/src/aleph/examples/http.clj#L54):

(extend-protocol Renderable
manifold.deferred.Deferred
(render [d _] d))

However doing this, now we generally get manifolds threaded through all the
other middlewares. They expect maps, so I we generally get
"manifold.deferred.Deferred cannot be cast to clojure.lang.Associative" in
every middleware.

The "app" set up in simplified version looks like:

(def app
(->
my-routes
session-store-handler
wrap-multipart-params
(cors/wrap-cors
:access-control-allow-credentials true
:access-control-allow-origin "foo.com"
:access-control-allow-methods [:get :put :post :delete :patch])
(wrap-defaults defaults-config)))

Does anyone have any tips on how fix this? I cannot simply change the -> to
a d/chain, I guess since this is a static setup of the server middleware. I
worry I have to re-implement every response handling middleware to be
manifold "aware".

Best regards,
Alf

[Zach Tellman]

You might check out https://github.com/muhuk/aleph-middleware/, which if it
doesn't provide an implementation may at least give some indication of how
to adapt middleware.

Post by Alf Kristian Støyle
Hi.
We're using Aleph with compojure, which is how I found the problem.
However I guess it is a general problem, when trying to keep the server
async.
I added following to prevent compojure blocking on deferred, from (
https://github.com/ztellman/aleph/blob/master/examples/src/aleph/examples/http.clj#L54
(extend-protocol Renderable
manifold.deferred.Deferred
(render [d _] d))
However doing this, now we generally get manifolds threaded through all
the other middlewares. They expect maps, so I we generally get
"manifold.deferred.Deferred cannot be cast to clojure.lang.Associative" in
every middleware.
(def app
(->
my-routes
session-store-handler
wrap-multipart-params
(cors/wrap-cors
:access-control-allow-credentials true
:access-control-allow-origin "foo.com"
:access-control-allow-methods [:get :put :post :delete :patch])
(wrap-defaults defaults-config)))
Does anyone have any tips on how fix this? I cannot simply change the ->
to a d/chain, I guess since this is a static setup of the server
middleware. I worry I have to re-implement every response handling
middleware to be manifold "aware".
Best regards,
Alf
--
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.

[Alf Kristian Støyle]

Ok.

Thanks for the quick response.

Best regards,
Alf

[Alf Kristian Støyle]

Looks pretty good. I guess I can provide pull requests for any missing middleware I will be writing.

Perhaps this library should be mentioned in the Aleph docs, if it isn't already. Just a thought :-)

Cheers,
Alf

[Zach Tellman]

I think I meant to do that a while back. I'll do it now, thanks.

Post by Alf Kristian Støyle
Looks pretty good. I guess I can provide pull requests for any missing
middleware I will be writing.
Perhaps this library should be mentioned in the Aleph docs, if it isn't
already. Just a thought :-)
Cheers,
Alf
--
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.

[Alf Kristian Støyle]

Just an update on the effect I was hoping for.

When making the stack entirely async, I was able to start aleph with the
following setup:

(http/start-server
handler
{:port port
;;:executor (flow/utilization-executor 0.9 128 {:metrics
(EnumSet/of Stats$Metric/UTILIZATION)}) ; Default being 512
:executor (flow/fixed-thread-executor 1)
})

And it runs, apparently at about the same performance, as with a
utilization-executor with 128 max threads. The main benefit here, of
course, is the the server can run with a lot less memory.

Of course it is very important to not have blocking operations anywhere.
When doing so, I am running them on a separate thread pool.

Some of the middlewares will require a bit of work, they are doing things
to the request and response, and they are not split in way which is easy to
use. But I will try to submit PR to the projects I am depending on.

Really happy with this. Aleph is great, and going the "full async" route,
makes it all even greater.

Cheers,
Alf

Post by Zach Tellman
I think I meant to do that a while back. I'll do it now, thanks.

Post by Alf Kristian Støyle
Looks pretty good. I guess I can provide pull requests for any missing
middleware I will be writing.
Perhaps this library should be mentioned in the Aleph docs, if it isn't
already. Just a thought :-)
Cheers,
Alf
--
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.

[Atamert Ölçgen]

Hi Alf,

Post by Alf Kristian Støyle
Looks pretty good. I guess I can provide pull requests for any missing
middleware I will be writing.

I would appreciate any pull requests about the middleware distributed with
ring.core. Another very welcome contribution is a test suite.

Post by Alf Kristian Støyle
Perhaps this library should be mentioned in the Aleph docs, if it isn't
already. Just a thought :-)
Cheers,
Alf
--
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.

--
Kind Regards,
Atamert Ölçgen

◻◌◻
◻◻◌
◌◌◌

www.muhuk.com