Hi,
Please see the logs attached. The logs are directly taken from Kibana so
the formatting is not great.
On a side note we are running each of our component inside a docker
container on AWS.
Thank you,
Philippe
The main hint for us when this happens is when we see the following
exception:
Hi,
I am trying to set up a unidirectional websocket connection using the Java
DSL to create a server-push mechanism.
I am currently struggling with converting the Source to a proper Graph that
UpgradeToWebSocket.handleMessagesWith() can accept.
Here is what I have so far:
public Route
On Fri, Oct 21, 2016 at 10:32 AM, Richard Rodseth
wrote:
> I've had no problems using Futures within actors and piping the result to
> the actor, after mapping. I have had problems when an actor gets flooded
> and you get timeouts because you're simply starting up too many
Isn't your comment about "messes up the pseudo-single-threading invariant
of Actors" more about not closing over mutable state? In any case, you
can't avoid Futures if you're using Slick or HTTP clients, for example.
On Fri, Oct 21, 2016 at 7:32 AM, Richard Rodseth wrote:
>
Hello hAkkers,
Consider this simple test (scalatest 3.0.0, scalacheck 1.13.2 and
akka-streams-testkit 2.4.11 is used):
describe("Either") {
implicit def noShrink[T]: Shrink[List[T]] = Shrink.shrinkAny
it("should filter 'Either.Left(..)' objects") {
forAll("left", "right.head",
I've had no problems using Futures within actors and piping the result to
the actor, after mapping. I have had problems when an actor gets flooded
and you get timeouts because you're simply starting up too many Futures.
That, I think, is where back-pressure changes the landscape.
Thanks for the
I would be grateful for some help with this Akka configuration question.
This is probably something obvious, but I've been googling and looking at
for a day or two and have not yet come up with an answer.
Checking the name of the ActorSystem at the top of RCStreamReceiver shows
that it is
On Thu, Oct 20, 2016 at 5:55 PM, Richard Rodseth wrote:
> Short version: is it fair to say the traditional warnings against ask()
> hold less weight because we have back-pressure?
>
Well, keep in mind that at least some of the usual warnings against ask()
have nothing