The nice thing with Akka streams and a Source[ByteString, _] is that you can
easily swap it for a different source without changing the rest of your impl :-)
The current impl uses nio.FileChannel with ByteBuffers which proved to give
very good performance - and I've benchmarked a number of impls
I just want to make sure I am using the most "promising" alternative for
I/O... I was reading files on my own with a low-level Java library, and I
wasn't using nio yet. I wasn't sure if I was going to update it to use Java
8 stuff, try out akka.io, or move to akka-stream. I think I am going with
I'm not sure we'll be able to take advantage of that, since all they do is
to multiplex it on top of a given Executor.
What we could do is to create a shim over an ExecutionContext that wraps
their submitted Runnables in BlockContext calls to isolate and make evasive
actions. Let's discuss :)
On M
Hi Nicolau,
this problem is not limited to Akka: most operating systems do not provide true
asynchronous file I/O themselves. We will eventually make use of Java 8’s
facilities (once Streams move into the master branch), but beware that the
asynchrony of the solution depends on deployment detai
What is the most current implementation of Akka based asynchronous file I/O
out there? It seems akka-stream 1.0-RC3 still only has synchronous reading,
and drexin's akka-io-file github repo is more than one year old. Is there
no highly-experimental official async file IO library out there?++
