Hi Rüdiger,
Have you tried to play around with the throughput setting of the
dispatcher? For these kind of non-interactive jobs fairness is not an
issue, so you might most likely want to increase that value.
-Endre
On Tue, Jan 7, 2014 at 1:26 AM, Rüdiger Möller moru0...@gmail.com wrote:
In your calculate()-method you keep creating ActorSystems and spawn an
actor responsible for the actual computation.
Ah, good observation, we missed that one.
You should prefer creating and keeping one ActorSystem for your benchmark
and just spawn an actor to handle your calculation
Hi Roger,
I thought that each message was delivered in sequence, which I'm pretty
sure I've seen described on a few places (?)
Each *user *message is delivered in sequence. System messages are not
something that are observable by user code directly and they use separate
mechanisms -- it is
Hi Jim,
That indeed sounds strange. Do you have some logs?
-Endre
On Wed, Mar 5, 2014 at 4:05 AM, Jim Newsham jim.news...@gmail.com wrote:
I am playing around with remoting, and now I'm confused because I
reconstructed a situation where remote deathwatch is triggered, and yet the
Thanks Jim, I will take a look at it. Quite probably a bug.
-Endre
On Thu, Mar 6, 2014 at 2:23 AM, Jim Newsham jim.news...@gmail.com wrote:
I cleaned up my test case a bit and I'm attaching it, as well as the logs
of one of the runs. Some quick notes:
- EchoMain starts EchoActor. This
Hi Daniel,
The issue is that type systems are designed for local and not distributed
computations. Let's look at an example.
Imagine an actor that has three states, A, B and C
In state A it accepts messages of type X, and when received one, it
transitions to B
In state B it accepts messages of
Hi Aleh,
On Sun, Mar 9, 2014 at 6:56 PM, OlegYch olegl...@gmail.com wrote:
Endre, i don't think this is related to distributed computations at all.
Any method call can fail even locally.
This is true of course, but way more relevant in distributed cases where
failures are orders of
into deployment sets is part of the
system design, needs careful planning, and doesn't change often. Inside
each local set, the benefits of guaranteed locality would be large
(messages aren't lost, static typing, etc.)
On Sun, Mar 9, 2014 at 7:42 PM, Endre Varga endre.va...@typesafe.comwrote:
Hi Daniel
On Mon, Mar 24, 2014 at 8:30 AM, Patrik Nordwall
patrik.nordw...@gmail.comwrote:
Hi Boris,
Thanks for packing it in a reproducible sample. As Viktor points out the
Java serializer is one of the prime suspect for bottlenecks in remote
communication. Here you have found something that I think
Hi Boris,
Thank you for trying out! Patrik I think figured out the reason (described
in the ticket). This is very much related to backpressure since the
messages get piling up in the EndpointWriter which continuosly stashes and
unstashes an ever growing amount of messages (gets to O(n^2)
Hi Boris,
On Mon, Mar 24, 2014 at 4:19 PM, Boris Capitanu bor...@gmail.com wrote:
Thank you, Patrik.
I think you hit the nail in the head with that ticket. I wanted to write
earlier that this felt like behavior you see when you have two nested for
loops:
for i = N to 1
for j = 1 to N
Hi George,
On Tue, Apr 29, 2014 at 7:01 PM, George Wilk
george.wilk.the@gmail.comwrote:
Thanks, Patrik.
I rebuilt my POC with akka release 2.3.2 and re-tested. I was able to
recreate the scenario with in-flight event not being replayed after JVM
crash. Here are some additional
Hi George,
On Tue, Apr 29, 2014 at 7:12 PM, George Wilk
george.wilk.the@gmail.comwrote:
This posting is somewhat related to my earlier topic titled “Recovery
following node failure”, which focused on replay of event following
processor failure due to VM crash. Even though this question
That is a really good summary, Roland. This should go into docs or at least
a blog post?
-Endre
On Tue, May 6, 2014 at 8:28 PM, Akka Team akka.offic...@gmail.com wrote:
Hi Shikhar,
thanks for sharing!
There are many possible ways of dealing with partitions in a distributed
system, and it
Hi Adam
- is it reasonable (thinking about reactive streams in general) to have an
actor which produces elements on-demand (instead of providing a
collection/iterator/() = as is currently supported)? As far as I
understand the current implementation, subscribers explicitly ask
publishers
Just a sidenote, CPU usage can be very misleading when profiling things
using the ForkJoinPool. Without a detalied profile, parameters and ways to
reproduce, it is impossible to say anything meaningful here.
-Endre
On Tue, Jun 24, 2014 at 3:03 PM, √iktor Ҡlang viktor.kl...@gmail.com
wrote:
Hi Benoit
On Wed, Jun 25, 2014 at 9:49 AM, benq benoit.quart...@gmail.com wrote:
Hi All,
Is it possible to feed a Duct (/Flow) with the elements it produces, like
a loop.
Looping this way is dangerous, in general it usually leads to element count
explosion, but since streams are always
Hi Benoit,
I wasn't proposing ActorProucer to loop back, instead you should
encapsulate the scrollId state and corresponding behacior in that
ActorProducer -- i.e. you implement your original snippet not in terms of
flow, but inside the ActorProducer. Then you can compose that stream with
others.
On Fri, Jun 27, 2014 at 12:23 PM, Endre Varga endre.va...@typesafe.com
wrote:
On Fri, Jun 27, 2014 at 11:59 AM, benq benoit.quart...@gmail.com wrote:
Le vendredi 27 juin 2014 10:01:57 UTC+2, drewhk a écrit :
Hi Benoit,
I wasn't proposing ActorProucer to loop back, instead you should
Hi Alan,
Akka-http works together with akka-stream, so it does work differently than
you tried. Since this is an early technical preview the docs are quite a
bit sketchy, but there are some examples already here:
HI Sean,
I come from bigdata background.
In my opinion, the Flow DSL is not expressive for many cases, like data
shuffle. Have you considered using DSL like the one used in cascading, or
spark, or storm trident?
The primary goal for streams is to provide a unified way to handle
Hi!
On Wed, Jul 16, 2014 at 10:49 AM, schoefts thomas.schoeft...@gmail.com
wrote:
Hi everyone,
we are currently integrating Akka-Streams in an application.
Looking at the current Flow DSL/API, I can see that Transformers
(Flow#transform) allow to *synchronously* produce a number of
Hi Alexey,
One way is to reformulate the problem: make your IO operation an api like
myIOwithRetries(retries: Int, inputParam: Param): Producer[Output] and
implement it as an ActorProducer. This producer can now do the retries
automatially and asynchronously inside the actor and just provide a
Hi Michael,
This seems to be a genuine problem. Can you open a ticket?
What I suspect is that calling toStrict inside the stream causes some
unwanted dependency and backpressure cannot be enforced without deadlocking
(it wants to drain more elements than it has permit to, but to get more
permits
Yes, mapFuture is the other option if the result set is small.
On Fri, Jul 18, 2014 at 10:40 AM, √iktor Ҡlang viktor.kl...@gmail.com
wrote:
mapFuture ought to work for that use case.
On Jul 17, 2014 8:43 AM, Alexey Romanchuk alexey.romanc...@gmail.com
wrote:
Hey hakkers!
I have a
Hi Michael,
On Fri, Jul 18, 2014 at 12:18 PM, Michael Barton michael.barto...@gmail.com
wrote:
Hi Endre,
Opened here https://github.com/akka/akka/issues/15560 as requested.
Thanks for taking a look.
Thanks!
I reworked my code to use the stream directly and it's working great:
Can we see the stacktrace?
2014.07.25. 17:55 ezt írta (Ian Phillips ian.phill...@gmail.com):
Akka has nothing to do with Ebeans, this is definitely not an issue
related to Akka.
Ah sorry, my bad, looking at the stack trace I thought that the There is
no started application error was being
Hi Evgeniy
Of course, but it will produce a lot of boilerplate (instead .map(_.param)
you will write .map(_.map(_.param)) - for all transformers).
It is same as saying: Library has no such behavior, but you can write it
by himself.
Streams is a basic building block and its purpose is
Hi Sean,
I think this might be a real issue. Remote deployment should maybe
automatically initiate a watch from the child to the parent. This problem
rings a bell though... Have you tried this in Akka 2.3.4? I have a feeling
that we fixed something like that before.
As a sidenote, I don't really
On Wed, Jul 30, 2014 at 12:25 PM, Evgeniy Ostapenko sml...@gmail.com
wrote:
среда, 30 июля 2014 г., 13:46:49 UTC+4 пользователь drewhk написал:
Absolutely yes! But more exactly the behavior of recovery depends on
stream type.
1) When you reading from file then you have byte stream
On Thu, Aug 7, 2014 at 10:05 AM, √iktor Ҡlang viktor.kl...@gmail.com
wrote:
Or add compression.
This is the Akka wire level envelope, cannot be directly controlled by
users (unless someone writes a new transport of course).
-Endre
On Aug 7, 2014 9:52 AM, Endre Varga endre.va
Hi Syed,
As the very first step, can you tell us what is the Akka version you are
using? If it is not Akka 2.3.4, please try to upgrade to 2.3.4 and see if
the issue still remains.
-Endre
On Thu, Aug 7, 2014 at 12:12 AM, Ryan Tanner ryan.tan...@gmail.com wrote:
When those large messages are
Sean,
Yes the separate dispatcher might be the cause. This default was added to
protect the remoting subsystem from load in userspace (learning from some
past problems). Feel free to reconfigure it to anything that works for you
-- the default might be conservative indeed.
-Endre
On Thu, Aug
There is a bug in Akka Tcp which causes this. I dont remember the ticket
No. but it is fixed and will be part of the next Akka bugfix release - then
streams will be fixed at the next release.
2014.08.13. 7:37 ezt írta (William Le Ferrand warne...@gmail.com):
Dear List,
I've facing a puzzling
Hi Chris,
Casting the ByteString to a stream of Bytes is very ineffective. I would go
with a stream of ByteStrings (chunks) instead. In these cases a Transformer
step is the best option, buffering up chunks as much as it is needed and
then emitting as much lines as you parsed.
Btw, there is a
Hi Karthik,
*def output =
Source.fromFile(C:\\Users\\karthik\\Downloads\\big_buck_bunny.mp4)(scala.io.Codec.ISO8859)*
Using Source here will be horribly inefficient.
*def video = HttpResponse(entity =
HttpEntity.Chunked(MediaTypes.`video/mp4`, Flow(output.map(_.toByte).map(a
=
There will be all kinds of merges available in the future. Akka Streams is
still a preview so we change stuff all the time. To get to the point where
we can support pluggable merges we needed the graph API and support for
n-way fan-in operations first. So stay tuned :)
-Endre
On Wed, Sep 24,
Do you properly close/flush the outputstream?
-Endre
On Wed, Oct 8, 2014 at 3:45 PM, Nicolas Jozwiak n.jozw...@gmail.com wrote:
I've just tried with a smaller chunk size (1000), and now I have a
different file size at the end = (Expected file length: '114541', actual:
'95541')
Weird...
Nicolas, I am not sure the code you wrote does what you want.
First of all reading something in byte-by-byte is highly inefficient, you
should have your source as a stream of blocks, for example
Source[ByteString]. The .grouped() will not help at all, because now you
will get Seq[Byte] which
* use-dispatcher : cluster-dispatcher*
That should be akka.cluster.cluster-dispatcher, you have to reference
dispatchers by their full path. By the way, you also seem to have this
strange nesting of cluster.akka.cluster.etc, which looks wrong.
-Endre
}
},
Any other ideas?
The same: you are providing the wrong path to the dispatcher configuration.
Configuration elements are nested, and correspond to paths. To set the
dispatcher any of the following works:
akka.cluster.use-dispatcher = dispatcher-path
or
akka.cluster {
use-dispatcher =
On Thu, Oct 16, 2014 at 10:49 AM, Alec Zorab aleczo...@gmail.com wrote:
I think this is a very common use case for applications streaming time
sensitive data (for example prices) where we would want to do an n-way zip
and then receive the most recent set of data for those n things.
I agree,
Hi Robert,
On Wed, Nov 5, 2014 at 9:55 PM, Robert Preissl robe...@ticketfly.com
wrote:
hello!
I am having a problem in my remote Akka production system, which consists
of 3 nodes running with the latest version of Akka (2.3.6.):
In more details, I am experiencing errors with *rolling
Hi Joe,
There is a configuration section for the underlying IO stuff:
# The maximum number of bytes delivered by a `Received` message. Before
# more data is read from the network the connection actor will try to
# do other work.
akka.io.tcp.max-received-message-size = unlimited
(see
On Sat, Dec 6, 2014 at 2:40 PM, Muki nepomuk.sei...@gmail.com wrote:
Nice work! I tried it and was wondering if the usage of *Stage* and
*Directive* is correct
*class* GridCellTransformer(*implicit* *val* resolution: Double) *extends*
PushStage[LocationUpdate, IndexedLocationUpdate] {
only exist compile time, since the context,
under the hood will return null every time. The types are just a nice way
to enforce that it must be called, an not every time is allowed to call
every method.
-Endre
On 8 Dec 2014 08:44, Endre Varga endre.va...@typesafe.com wrote:
On Sat, Dec 6
On Mon, Dec 8, 2014 at 3:08 PM, Roland Kuhn goo...@rkuhn.info wrote:
Which server do you see this with? A priori it makes sense to close the
sending side if no further requests will follow, but if relevant HTTP
servers misinterpret this then we’ll have to fix it (whether or not it is
broken
On Wed, Sep 24, 2014 at 5:07 AM, Endre Varga endre.va...@typesafe.com
wrote:
There will be all kinds of merges available in the future. Akka Streams
is still a preview so we change stuff all the time. To get to the point
where we can support pluggable merges we needed the graph API
I guess this is exactly being fixed right now:
https://github.com/akka/akka/issues/16505
-Endre
On Wed, Dec 10, 2014 at 1:39 PM, √iktor Ҡlang viktor.kl...@gmail.com
wrote:
Hi Jason,
always, always, give us what versions you are using.
This saves both of us time, so please do this. Thanks!
Hi Magnus,
On Wed, Dec 24, 2014 at 1:55 AM, Magnus Andersson
magnus.anders...@mollyware.se wrote:
Hi
I am building a simple reverse proxy as an exercise to understand Akka
Streams. I have read the new docs but could not find an answer.
I'm using FlexiRoute as recommended in an earlier
Hi Alexey,
On Thu, Jan 22, 2015 at 12:31 PM, Alexey Romanchuk
alexey.romanc...@gmail.com wrote:
It is exactly what I have tried to achieve! You guys did amazing work with
all akka streams. Thanks! :)
You might be also interested in this ticket:
https://github.com/akka/akka/issues/16610
It
Without detailed logs I cannot say. If there would be a system message
buffer overflow then it would cry loudly in the logs. Also it says that an
unreachable node is being removed, so there should be events happening
before unreachability. This might be something completely else. The full
config
On Sun, Feb 1, 2015 at 9:05 PM, Jeremy Stone jeremymichaelst...@gmail.com
wrote:
Would something like the following in the server handler do it for you?...
def silentSource = ??? // Source that emits nothing but does never
completes
def handleDataFromClient: ByteString = Unit = ???
Hi Evan,
As we progress we make more and more things possible, we will keep this
use-case in mind.
-Endre
On Sat, Jan 31, 2015 at 2:52 AM, Evan Chan vel...@gmail.com wrote:
Thanks Bjorn.
On Fri, Jan 30, 2015 at 2:33 AM, Björn Antonsson
bjorn.antons...@typesafe.com wrote:
Hi Evan,
I
On Mon, Feb 2, 2015 at 6:49 PM, Akka Team akka.offic...@gmail.com wrote:
Hi Elmar,
On Mon, Feb 2, 2015 at 6:40 PM, Elmar Weber goo...@elmarweber.org wrote:
I am looking to batch elements in a flow in a non-standard way and
sending them off.
A typical flow for this based on a static count
Hi,
On Mon, Jan 19, 2015 at 5:54 PM, Alexey Romanchuk
alexey.romanc...@gmail.com wrote:
Hey hakkers!
I am currently updating old application built on akka-streams 0.4 to
1.0-MX API. I used Transformers and now migrate it to PullPushStages. In
general migration is pretty easy, but I can
Hi Johannes,
See the milestone here:
https://github.com/akka/akka/issues?q=milestone%3A2.3.9+is%3Aclosed
The tickets cross reference the PRs, too, so you can look at the code
changes. The issue that probably hit you is
https://github.com/akka/akka/issues/16623 which manifested as system
message
Hi Alexey,
On Thu, Jan 22, 2015 at 4:15 AM, Alexey Romanchuk
alexey.romanc...@gmail.com wrote:
Hey!
I have a stream that process incoming messages, assemble big message
pack and send it to other system via network. Incoming messages are
relatively small and I use big buffers to improve
Hi Frank,
On Thu, Jan 22, 2015 at 2:51 AM, Frank Sauer fsaue...@gmail.com wrote:
Thanks, I came up with the following, but I have some questions:
/**
* Holds elements of type A for a given finite duration after a
predicate p first yields true and as long as subsequent
* elements
On Thu, Jan 22, 2015 at 5:07 AM, Frank Sauer fsaue...@gmail.com wrote:
Update, in a simple test scenario like so
val ticks = Source(1 second, 1 second, () = Hello)
val flow = ticks.transform(() = new FilterFor[String](10 seconds)(x =
true)).to(Sink.foreach(println(_)))
flow.run()
Hi Carsten,
If you express that you want to read ALL inputs, then you implicitly also
expressed that you want to be completed when ANY of the inputs are
completed (otherwise you cannot get ALL, so it would be a deadlock).
The default completion handling is invoked on completion, but its
On Wed, Jan 14, 2015 at 5:02 PM, Akka Team akka.offic...@gmail.com wrote:
Hi Oleg,
Your understanding of both topics, in the current version of Akka, are
correct.
More specifically:
Is it possible to configure Akka Cluster with auto-downing so that with
100% probability at each moment at
Hi Johannes,
On Thu, Jan 22, 2015 at 4:53 PM, Johannes Berg jberg...@gmail.com wrote:
I will try that but it seems that will only help to a certain point and
when I push the load further it will hit it again.
There is no system message traffic between two Akka systems by default, to
have a
Hi Sam,
On Tue, Jan 20, 2015 at 9:56 PM, Sam Halliday sam.halli...@gmail.com
wrote:
One more comment on the streams API. It is really cool that you've thought
about using mapConcat instead of flatMap to enable optimised merge
operations. I just wanted to draw your attention to a clojure
] and a function T = Seq[U] and gives a Source[U] (similarly
with Flow). Source is not a Seq, it is a completely different beast.
On 21 Jan 2015 08:03, Endre Varga endre.va...@typesafe.com wrote:
Hi Sam,
On Tue, Jan 20, 2015 at 9:56 PM, Sam Halliday sam.halli...@gmail.com
wrote:
One more
Hi Johannes,
We just released 2.3.9 with important bugfixes. I recommend to update and
see if the problem is still persisting.
-Endre
On Wed, Jan 21, 2015 at 10:29 AM, Johannes Berg jberg...@gmail.com wrote:
Many connections seem to be formed in the case when the node has been
marked down
Hi Sam,
Bjorn asked if I felt any examples were missing, and sadly my
original request (that I've been going on about for years,
sorry!) is indeed missing. It is the case of a fast producer and
a slow consumer that is ideal for parallelisation.
There are many examples of slow consumers,
Hi, Philippe,
On Thu, Jan 22, 2015 at 6:28 PM, Philippe Milot pmi...@turbulent.ca wrote:
So I'm following the documentation on the new Akka-Http experimental
modules, and I'm trying to get a basic Hello World using the Routing DSL.
I've defined my route as follows:
val route: Route = {
Hi Wolfgang,
On Thu, Feb 19, 2015 at 4:47 PM, Wolfgang Friedl
wolfgang.fri...@hotmail.com wrote:
There is one thing which came int to my mind.
We are using mapConcat which does have the signature (f: Out ⇒
immutable.Seq[T])
Could it be that in a case were more elements are published the
Hi Wolfgang,
On Thu, Feb 19, 2015 at 3:24 PM, Wolfgang Friedl
wolfgang.fri...@hotmail.com wrote:
Hi togehter!
I observed the same exception ( Input buffer overrun) on my side today.
Even so I read this task I'm not sure if I got it right.
I do have a Flow were I put some processing steps
On Mon, Feb 16, 2015 at 1:24 PM, Carl Pulley carl.pul...@googlemail.com
wrote:
Thanks for that (and the AutoPublisher hint). It was a great help in
seeing what I was misunderstanding!
Let's hope so :) If it does not work, then we have a bug, but thankfully we
also will have a reproducer ;)
HI Giovanni,
On Mon, Feb 16, 2015 at 11:31 PM, Giovanni Alberto Caporaletti
paradi...@gmail.com wrote:
You're absolutely right about the future not representing an already
running computation. But it's not a blueprint. If a see a future, I take
for granted that something will happen sooner
Hi Wolfgang,
On Thu, Feb 19, 2015 at 7:35 PM, Wolfgang Friedl
wolfgang.fri...@hotmail.com wrote:
Hi Endre
My publisher is quite simple! It is an actor (extending the
ActorPublisher) waiting for incoming messages. He puts the messages in the
buffer if the totaldemand is 0 I call onNext.
Hi Simon,
One trick I like to use is to define a Source in terms of a PushPullStage.
Now this sounds strange, since a PushPullStage is supposed to be someting
that transforms incoming element into outgoing elements, how can that be a
Source? Well, the trick is this:
def mySource =
On Tue, Jan 27, 2015 at 1:35 PM, Björn Antonsson
bjorn.antons...@typesafe.com wrote:
Hi Thomas,
There is a recipe for chunking up bytestrings in the stream docs
Hi Yarden,
On Tue, Jan 27, 2015 at 9:58 AM, Yarden Bar ayash.jor...@gmail.com wrote:
Hi
Thanks for the SUPER fast reply.
I'll upgrade as you suggested.
The upgrade will not change the message though. This is a status message
that is useful to debug if you send remote messages much faster
Hi,
There is a setting akka.io.tcp.windows-connection-abort-workaround-enabled
setting that is known to be causing this. It is a workaround for Windows to
get connection abort events reliably, but unfortunately has this
side-effect. You can disable the workaround from the config, currently it
is
Hi Thomas,
On Tue, Jan 27, 2015 at 3:32 PM, Thomas Zimmer t...@turtle-entertainment.de
wrote:
Thank you so much guys! You definitely rock :)
I think Björn link was excatly what I was loooking for. Is there a way to
influence the demanded chunk-size dynamically?
No, the ByteStrings are of
Hi Jean,
On Mon, Jan 26, 2015 at 9:03 AM, Jean Rossier jean.ross...@gmail.com
wrote:
Hello,
I'm wondering if there is a way to use back-pressure mechanism on incoming
connections with Akka HTTP ?
The documentation mentions clearly that there is no back-pressure applied
to the connections
Hi Johannes,
On Fri, Jan 23, 2015 at 8:39 AM, Johannes Berg jberg...@gmail.com wrote:
Thanks for the answers, this really explains a lot. I will go back to my
abyss and rethink some things. See below some answers/comments.
On Thursday, January 22, 2015 at 6:31:01 PM UTC+2, drewhk wrote:
Hi
Hi,
On Fri, Jan 9, 2015 at 10:53 PM, Allen Nie aiming...@gmail.com wrote:
Hey Viktor,
I'm trying to use Akka to parallelize this process. There shouldn't be
any bottleneck, and I don't understand why I got memory overflow with my
first version (actor version). The main task is to read
On Mon, Jan 12, 2015 at 5:38 AM, Krishna Kadam shrikrishna.kad...@gmail.com
wrote:
Hi all,
Thanks for your valuable guidance, But I am bit confused with the answer
to first question. In what circumstances I should share the message queue
in between two actors and In what circumstances
Hi,
On Fri, Jan 9, 2015 at 4:12 PM, Matan Safriel dev.ma...@gmail.com wrote:
Thanks Patrik, good to know, because the cluster module may seem like a
very specific and rather unfinished reference implementation;
What do you mean by unfinished reference implementation? It is a fully
supported
Hi,
Streams is compiled against Akka 2.3.x which is not guaranteed to be binary
compatible with 2.4. I expect that the above code to work with Akka 2.3.x.
(if not, then this is a bug)
-Endre
On Wed, Jan 7, 2015 at 4:40 AM, tigerfoot gzol...@gmail.com wrote:
Hello,
I've got this code:
def
Hi Jim,
We are aware of the issue, a fix is being prepared:
https://github.com/akka/akka/pull/16640
-Endre
On Wed, Jan 14, 2015 at 2:24 AM, Jim Newsham jim.news...@gmail.com wrote:
P.S. I've checked the release notes and didn't see anything specifically
related to
Hi,
There is a flatMap, it is just not called that. There is a flatten() method
that takes a strategy, currently the only one being concat:
flatten(FlattenStrategy.concat). The reason for that we don't provide a
method called flatMap is to avoid it being overused in for comprehensions.
In the
Hi,
The problem is really simple. You request sub.request(msgs.length) from the
Window element, and then you send elements to it:
for (msg - msgs) {
pub.sendNext(msg)
}
The problem here is your underlying assumption is that if you request X
elements from a Processor (which is what the
On Fri, Mar 6, 2015 at 11:04 AM, Bogdan Nechyporenko
bogdannechipore...@gmail.com wrote:
I'm updating from
com.typesafe.akka:akka-stream-experimental_2.10:1.0-M4
to
com.typesafe.akka:akka-stream-experimental_2.10:1.0-M4
but there are no classes like UndefinedSource,
This will be solved by Stage fusing which will allow you to denote a region
of the graph to be executed synchronously. The synchronous island will be
buffer-free internally and will only buffer at the edges. Asynchronous
boundaries will always have buffers.
-Endre
On Mon, Mar 30, 2015 at 10:36
On Mon, Mar 30, 2015 at 3:08 PM, Peter Schmitz petrischm...@gmail.com
wrote:
Hi Endre,
I earlier mentioned that my calculations are done within val f:
FlowGraph.Builder = Outlet[T] = Outlet[S] which then is wrapped into a
partial flowgraph.
This function is created by a DSL I have
Hi Peter,
The issue is, that these processing elements are actors, which have a
mailbox, so there is buffering in any case. You cannot have meaningful
asynchronous processing without at least a buffer size of one.
-Endre
On Mon, Mar 30, 2015 at 2:36 PM, Peter Schmitz petrischm...@gmail.com
Hi Peter,
Why don't you just create a custom stage then where you bundle up all the
calculations you need to be done synchronously?
(Btw, I agree with Roland that you probably over-worry about those buffers)
-Endre
On Mon, Mar 30, 2015 at 2:54 PM, Peter Schmitz petrischm...@gmail.com
wrote:
Hi Robert
What is your watch failure detector setting? Detection speed depends on
those. There was a bug in earlier remoting that published internal
AddressTerminated messages when it was not supposed to (remoting does not
consider unreachable machines as dead, that decision is taken by remote
You should look at this cookbook recipe:
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M4/scala/stream-cookbook.html#Parsing_lines_from_a_stream_of_ByteStrings
On Fri, Mar 27, 2015 at 11:14 AM, Borut borut.daga...@gmail.com wrote:
Hi
Ws.url(req).getStream() returns a
...and there is the ongoing AsyncStage work:
https://github.com/akka/akka/pull/17105/
which generalizes DetachedStages into a more powerful tool allowing
asynchronous side-channels.
-Endre
On Tue, Mar 31, 2015 at 12:39 PM, Roland Kuhn goo...@rkuhn.info wrote:
To add some more detail: getting
Hi Jakub,
On Tue, Mar 3, 2015 at 1:07 PM, Jakub Liska liska.ja...@gmail.com wrote:
Hey,
I'm trying to design a stream processing of hundreds of thousands of files
row by row, reading files lazily. It comes with the obligation to close the
InputStream at the end so that creating an
This is a non-trivial problem, but not totally hard either. The problem is,
if you always try to wait for a full chunk, then some data might get
delayed for an arbitrary amount of time. Consider a target of chunk size 3,
then the following events
- 2 bytes arrive
- 10 minutes elapse
- 1 byte
Hi Joost,
On Wed, Mar 4, 2015 at 8:26 AM, Joost den Boer jdb...@diversit.eu wrote:
Hi,
I am trying to get the hang of Akka Streams and have been struggling last
night with some of the examples in the Streams documentation because of
this api change. It would be great if the documentation
Hi Boris,
On Fri, Feb 27, 2015 at 10:41 AM, Boris Lopukhov 89bo...@gmail.com wrote:
I have a simple actor publisher:
class TestActor extends ActorPublisher[Int] {
println(RUN)
def receive = {
case Request(elements) = while (totalDemand 0 isActive) {
onNext(1)
}
Hi Luis,
It should not stuck but throw, but this will not work:
broadcast.out(i) ~ worker ~ merge.in(i)
You imported worker once, you cannot use it N times. You can either use
builder.add to add as many times as you need (the parametric import you
used only matters if you want to
1 - 100 of 390 matches
Mail list logo
