That is a good point. about unit testing the file handling part without
running in it in actors.
On Friday, February 13, 2015 at 6:00:26 AM UTC-6, Patrik Nordwall wrote:
You can probably get some ideas from
http://doc.akka.io/docs/akka/2.3.9/scala/testing.html
or
I just found out that :
ActorPublisher and ActorSubscriber *cannot be used with remote actors*,
because if signals of the Reactive Streams protocol (e.g. request) are lost
the the stream may deadlock.
but the same applies for https://github.com/akka/akka/issues/16416, right?
--
Hi,
I'm trying to do something similar to the rx.observable.firstOrElse(x),
that is emitting a default value when the source is empty.
I want to evaluate the default value *only* if the source is empty. The
only way I found is writing a custom stage (below).
Is there some built-in operator I
Jim,
I think you’re referring to this reference.conf
https://github.com/akka/akka/blob/master/akka-actor/src/main/resources/reference.conf
which has this section of the scheduler settings:
# Used to set the behavior of the scheduler.
# Changing the default values may change the system
Hi Charlie,
thanks for the interest! We're working hard to hit 1.0 with streams and
http in the next weeks.
Java API and docs is of course a large part of what we consider to be 1.0 -
can't make any hard promises at this point about exact dates.
Please track our release news/notes, and happy
They're going to have to figure a way around that. Maybe with better
protocoling around demand signals. The gem of Akka is its location
transparency. I find it hard to believe they'd leave this functionality out of
Streams forever. Sure, it'll be work to develop good signaling protocols for
You could use ActorSubscribers and Publishers here. Or depending on what your
response handling logic is, use a simple forEach sink to process the results.
I'm guessing you'd model your indexer as a flow component and then put a
broadcast on the output channel. So a flow graph that looks
Thanks a lot for noticing and pulling through with the PR (now merged)!
On Sun, Feb 15, 2015 at 2:04 PM, Paweł Kaczor pablo.kac...@gmail.com
wrote:
I created a ticket: https://github.com/akka/akka/issues/16874
and pull request: https://github.com/akka/akka/pull/16877
Cheers,
Pawel
--
Yeah, but as I said those are remote actors So this is not an option.
Not even ActorPublisher/Subscriber because that doesn't work remotely
either...
LineSource ~ lineToRecord ~ indexRecord ~ bcast ~ sink.ignore
sink.ignore ~ responseHandler ~ bcast
I don't get
Hi Maatary,
I believe this question was already answered in the 2nd thread about this
you opened recently:
https://groups.google.com/forum/#!searchin/akka-user/stm$20maatary/akka-user/3JWz-X5dbe8/48A2Fbj5F34J
Let us know if you have more questions though!
-- Konrad
On Mon, Feb 16, 2015 at 6:53
Hi Moiz,
actor messaging is *not* designed for very large messages - you should use
akka.io and a dedicated tcp socket for this.
With actor messaging all messages share one tcp connection, thus you're
blocking all messages to go through until the large message has been sent.
Also, exacly as Jim
Hi there,
I'm not entirely sure what the problem is, would you mind including some
more logs or explain the tested scenario in more detail?
Thanks!
-- Konrad
On Sun, Feb 15, 2015 at 9:39 PM, hfaouaz hassan.fao...@gmail.com wrote:
Hello,
I am trying to leverage akka to initiate one single
Glad you like it!
Yes, I think we'll need to provide something out of the box... not sure
about it's end form yet, but we're slowly getting there :-)
Happy hakking!
-- Konrad
On Wed, Feb 18, 2015 at 2:04 AM, Łukasz Sowa luk...@gmail.com wrote:
Hi Konrad,
Thanks a lot, these are excellent
I think the OS you're using matters a lot for this sort of test. Hopefully
it's not windows...
What was the maximum concurrency level that you've tested?
Did you make sure (in the performance test code) that this concurrency
level is actually met in all cases?
Did you try tweaking with the
Hi Giovanni,
stages are exactly the right approach to tackle these things: we want to avoid
having a ton of combinators on the core API due to the maintenance burden (cf.
«binary compatibility»), but a repository of such stages could be a great thing
to have!
Regards,
Roland
22 feb 2015
You're right. In this case we don't need the bcast at all. Dunno what I was
thinking, but it made sense at the time. :)
-Jim
-- Sent from my mobile device
On Feb 22, 2015, at 10:08 AM, Jakub Liska liska.ja...@gmail.com wrote:
Yeah, but as I said those are remote actors So this is not
16 matches
Mail list logo
