Hi Jim, Simon.
What you say is exactly what I did: I have a normal actor on a different
dispatcher (but it could be any type of asynchronous code) that sends
messages to an actor producer that acts as the Source of the stream.
+1 for adding more external interaction recipes on the
Hi George,
thanks for the feedback, we know that a proper testkit will be required by
users, but we still only have our internal facilities. We are heavily working
on finalizing streams themselves, if you want to help out with suggesting a
concrete testkit (perhaps even in code, take a look at
If an actor is blocking (processing a message) the shutdown will not
complete until that is finished.
/Patrik
On Fri, Feb 20, 2015 at 10:30 AM, Akka Team akka.offic...@gmail.com wrote:
Hi there and welcome to akka-user!
In general it shouldn't take that long for an actor system to shut down,
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 there and welcome to akka-user!
In general it shouldn't take that long for an actor system to shut down,
would you mind sharing an outline of the code you're using to shutdown the
system?
Are you sure shutdown was actually called? Shutting down is progagated as
system message, which has higher
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 =
I got the answer (and figured out what I was doing wrong) in Stackoverflow:
*http://stackoverflow.com/questions/28626917/how-can-i-encrypt-using-ssl-akka-remoting-messages/28629725#28629725*
Thank you very much
On Thursday, 19 February 2015 19:19:29 UTC+1, carlos Hernandez wrote:
Hello, I
(I've asked this question in Play framework mailing list
https://groups.google.com/forum/#!topic/play-framework/zjBhdC80VWM but it
seems better to be asked here)
It's possible to use Play built-in actor system but it seems OK for a few
actors (as it said in docs) while I would have a heavy
Hi,
I'm in a situation where it would be lovely to be able to do a nested
persist, i.e.:
persist(SomeEvent)(handle)
...
def handle = {
case SomeEvent =
changeState()
stateChangeConsequences().foreach { _ =
persist(SomeOtherEvent)(handle)
}
}
According to a quick
Hi Wolfgang, Partik, Roland
I may be seeing a similar problem. I have spent some time, and I believe I
can reproduce this most of the time. I start a 2 node cluster (separate
JVM's), then periodically restart the second node usually within 5 attempts
the ActorSystem on the first node is
To follow up on this, at least for TextFrames, I managed to trick the
wandoulabs websockets layer into sending an Ack.
Basically, instead of using their recommended API (in the server worker)
val Pong = TextFrame(PONG)
...
send(Pong)
I am bypassing the frame rendering logic and doing
Hi all,
I am trying to enable ACK-based backpressure on a websocket server.
The Akka IO backpressure is really fantastic and easy to understand[1].
The Spray Can docs mention something about automatic backpressure[2], but I
can't find any more information about what this means. I presume this
We might have found a potential issue on akka-http / akka. We have an
application that is using akka-http hosted on Amazon EC2; we decided to
scale horizontally to 2 instances and added a Amazon ELB. The ELB was doing
this simple health check every 3 seconds:
1.- Connect to the HTTP port (i.e.
That's quite a nice little trick Endre, way better that writing an
ActorPublisher if you don't need to communicate with the Producer. I did
something similar to create an infinite stream from Amazon SQS (using an
infinite Iterator[Unit] and mapAsyncUnordered) but this seems a much better
approach.
14 matches
Mail list logo
