Aleph has always allowed that, but the latest release allows the asynchrony
to be modeled using core.async channels if that's to your taste.
On Wednesday, January 7, 2015 at 9:52:53 AM UTC-8, Paul deGrandis wrote:
>
> There was another discussion on this list regarding async IO and web
> servers
Thanks. This was very interesting, especially the part about back pressure.
kl. 18:52:53 UTC+1 onsdag 7. januar 2015 skrev Paul deGrandis følgende:
>
> There was another discussion on this list regarding async IO and web
> servers. It may be rather informative to you:
> https://groups.google.co
There was another discussion on this list regarding async IO and web
servers. It may be rather informative to you:
https://groups.google.com/d/msg/clojure/rKqT13Ofy4k/H9xvkZA9Yy4J
To my knowledge, Pedestal is the only web library that let's you go async
all the way down to the wire (potentiall
There is also vertx.io with the clojure module.
Josh
On Tue, Jan 6, 2015 at 3:43 PM, Max Penet wrote:
> Jet is already very usable and used in production by some notable
> projects/clients.
> I am also working on improving the backpressure story on all fronts at the
> moment (matter of few days
Jet is already very usable and used in production by some notable
projects/clients.
I am also working on improving the backpressure story on all fronts at the
moment (matter of few days at most).
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To p
Some jetty adapters also supports the async interface using core.async:
https://github.com/mpenet/jet.
Also, for async database access, I'm currently working on suricatta library
(sql toolkit on top of JOOQ) and it exposes a simple async interface for
execute queries asynchronously in a shared thr
AFAIK https://github.com/ztellman/aleph is the current best async IO
library.
Jozef
On Tue, Jan 6, 2015 at 7:20 AM, Ricardo Gomez
wrote:
> There are, it'll just never happen.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this
There are, it'll just never happen.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe
So there are no benefits to having core.async being the only threadpool in
the app?
kl. 03:12:15 UTC+1 tirsdag 6. januar 2015 skrev tbc++ følgende:
>
> And if you want async web frameworks, Pedestal supports core.async. You
> just return a channel as a response body and it assumes that you will
And if you want async web frameworks, Pedestal supports core.async. You
just return a channel as a response body and it assumes that you will
eventually pipe your data down that channel.
Timothy
On Mon, Jan 5, 2015 at 6:09 PM, David James wrote:
> In case you are interested in a recent example,
In case you are interested in a recent example, I wrote an NIO.2 based Riak
client in Clojure without Netty.
https://github.com/bluemont/kria
It uses callback functions, so the consumer can do whatever they want; such
as core.async.
I agree with Timothy, above. My take-away from the experience
Sure, the actual DB operation is not going to benefit from async io, but if
you have a server using go-blocks to handle incoming requests, using
blocking io would also block the threadpool running the go-blocks, limiting
the number of requests you can handle.
If you have a threadpool of four th
I built a PostgreSQL Java client from scratch recently. Since it was not a
goal to support JDBC ever I thought about writing it with non-blocking
async IO. I played with some ideas but ultimately I decided not to. The
reason is quite simple. Async IO works well if you do enough IO to keep one
a
But wouldn't those async interaces either use their own threads or
threadpool, which would compete with core.async's threadpool for
resources/cycles?
kl. 23:31:53 UTC+1 mandag 5. januar 2015 skrev tbc++ følgende:
>
> Many database APIs already contain async interfaces. Simply use those and
> us
Many database APIs already contain async interfaces. Simply use those and
use core.async/put! and take! to allow them to operate on core.async
channels. You often don't need much more than that.
Timothy
On Mon, Jan 5, 2015 at 3:18 PM, Robin Heggelund Hansen wrote:
> I guess this post is mostly
I guess this post is mostly going to be a question, but one that could
shape up to be a long open source project and contribution on my part, if
it is warranted.
The Clojure community has been blessed with good language interoperability
with Java, which has made it easy to use and wrap Java-lib
16 matches
Mail list logo
