Re: [akka-user] [Akka Stream] Waiting for stream completion

Thanks, Victor, for asking the right question! Makes sense. – Kaspar On Tuesday, 9 February 2016 00:32:50 UTC-8, √ wrote: > > If the Sink doesn't report when it is done, how would you know it's done? > > On Tue, Feb 9, 2016 at 6:11 AM, hbf wrote: > >> Hey Akka Stream'ers, >> >>

[akka-user] [Akka Stream] Exceptions in AbstractInHandler and AbstractOutHandler

Hey everybody, The documentation doesn't say how exceptions in a GraphStage's handlers ( AbstractInHandler and AbstractOutHandler) are treated. Do they cause undefined behavior or will they implicitly call failStage()? Thanks! Hbf -- >> Read the docs: http://akka.io/docs/

Re: [akka-user] Re: Akka persistence query examples

Hi everyone. Just waking up this thread with a related challenge/question. One of the objectives of Persistence Query was to address the limitation that a PersistentView was only able to project from a single persistence id. As we all know, this meant that trying to do CQRS in a DDD based

[akka-user] Cannot materialize an incoming connection Flow twice

Hello, I was playing around with Stream API 2.0 where I got a strange error-message: "Cannot materialize an incoming connection Flow twice.". I could track down the issue to a code-line. So this what I am doing Server code: val connections = Tcp().bind(localHost.getHostName, port, backlog,

Re: [akka-user] Cannot materialize an incoming connection Flow twice

Hi, Just use the idleTimeout, or completionTimeout combinator (or both). It shouldn't have worked with 1.X versions btw, and I think it did not in more recent versions. -Endre On Thu, Feb 11, 2016 at 3:36 PM, Thomas Zimmer wrote: > Hello, > > I was playing around with

Re: [akka-user] Cannot materialize an incoming connection Flow twice

Would it be possible to set a completion timeout depending on some kind of "state"? Like in my case I have a setup that I have a running Akka Application with a Loadbalancer in front. The Loadblancer open a TCP Connection every 10 seconds (Think its their health-check). Now when I don't

Re: [akka-user] Which of the data races are actually still happening in the current implementation of actors? can there be example code for each?

Thanks for the update :) Sounds interesting. /Patrik ons 10 feb. 2016 kl. 22:04 skrev Mohammed Al-Mahfoudh < mohammed.mahfo...@gmail.com>: > Hi Patrick, > > Thank you so much for the reply! > > That is indeed helpful, I don't know how i missed this reply by almost a > year, nevertheless that

Re: [akka-user] Cannot materialize an incoming connection Flow twice

On Thu, Feb 11, 2016 at 4:24 PM, Thomas Zimmer wrote: > Would it be possible to set a completion timeout depending on some kind of > "state"? Like in my case I have a setup that I have a running Akka > Application with a Loadbalancer in front. The Loadblancer open a TCP >

Re: [akka-user] Cannot materialize an incoming connection Flow twice

Excatly. I use the PROXY Protocol which only sends a string "PROXY IP IP port port\r\n" right in the beginning. So can you think of any good solution? On Thursday, February 11, 2016 at 4:43:08 PM UTC+1, drewhk wrote: > > > > On Thu, Feb 11, 2016 at 4:24 PM, Thomas Zimmer

Re: [akka-user] Cannot materialize an incoming connection Flow twice

Ah sorry for not making a clear statement here. So the LB makes connection from time to time which DO NOT send the Proxy String. Only when a "real" client makes its connection via the LB the PROXY is send out. So what is the best thinkable solution you would recommend me? Thanks for helping me

Re: [akka-user] Cannot materialize an incoming connection Flow twice

I don't understand this answer fully :( Does the client only or also the balancer send this first message? Or reformulated, is there any distinguishing factor between the client and balancer connection? -Endre On Thu, Feb 11, 2016 at 4:45 PM, Thomas Zimmer wrote: >

Re: [akka-user] Cannot materialize an incoming connection Flow twice

If I parse your answer properly, and it does mean that when the LB does its pingy connect thing, then it *does not send anything*, meanwhile a client always sends an initial message, then the simple answer is to use the ".initialTimeout" operator. There are basic 4 timeout related operators: -

[akka-user] Akka Http Client - Retrying a POST Request

Akka nation, I know the documentation says retries in Host-Level Client-Side API happen for idempotent requests which excludes POST requests. But there are times you have to use POST even though your request is are idempotent requests (e.g. large parameter size, binary parameters, etc). Is

Re: [akka-user] Cannot materialize an incoming connection Flow twice

I think that will help me a lot. Thank you On Thursday, February 11, 2016 at 5:26:26 PM UTC+1, drewhk wrote: > > If I parse your answer properly, and it does mean that when the LB does > its pingy connect thing, then it *does not send anything*, meanwhile a > client always sends an initial

[akka-user] how to control lifetime of a sharded entity

Hi, I'm trying to use sharding and that works reasonably well (my entities are being created across my cluster and they respond to my requests). However, I notice that after each call to my entity, it is destroyed. Every next call on the entity then recreates it. This is not ideal for me since

Re: [akka-user] Distributed Data for production use

Thanks, that is reassuring. On Wednesday, February 10, 2016 at 10:10:19 PM UTC-8, Patrik Nordwall wrote: > > It's mature and stable. You can use it in production. We use it in > production in ConductR. We always use the experimental label for new > modules to have the freedom to change API