Re: [akka-user] [Akka stream] Sink/source materialization

lization may not always be desired. Hbf > -- > Cheers, > √ > > On Feb 8, 2017 03:33, "hbf" <k...@iaeth.ch > wrote: > >> Heya everybody! >> >> I know that Akka Stream elegantly distinguishes *describing* a graph >> from *materializing* a

[akka-user] [Akka stream] Sink/source materialization

action (make the HTTP request, open the connection) to only take part when we materialize, and each time we materialize the flow. Am I missing something? Thanks for any feedback! Hbf P.S. I know I can use the GraphStage API to achieve this (and that's what I'm doing) but I think it might

Re: [akka-user] [Akka Stream] Happens-before relation and runForEach

Thanks, Roland and √. My example was indeed made up (there are better constructs in place) but thanks for clarifying that it's indeed the JVM happens-before relations that applies. – Kaspar On Wednesday, September 21, 2016 at 12:56:41 AM UTC-7, √ wrote: > > Technically I think the solution

[akka-user] Akka Stream buffer size monitoring

=> Metrics.gauge("Buffer size", size)) (where Metrics.gauge() is just an example call to a metrics framework). Any ideas? Thanks, Hbf -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the

Re: [akka-user] [Akka Stream] Happens-before relation and runForEach

Thanks for clarifying, Konrad. – Hbf On Tuesday, September 20, 2016 at 4:33:53 PM UTC-7, Konrad Malawski wrote: > > > final Source<Integer, NotUsed> source = // ... > final MutableInt max = new MutableInt(Integer.MIN_VALUE); > final Procedure f = i -> { >

[akka-user] [Akka Stream] Happens-before relation and runForEach

of f. Do I still need to use AtomicInteger so that the effects are seen by all threads? Thanks! Hbf -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://d

Re: [akka-user] [Stream] Connecting arbitrary number of graphs with materialized values

Can you do it recursively? Write method that takes two and combines their materialized values. Then recurse to do *n*. Hbf. On Friday, 26 February 2016 05:02:34 UTC-8, Tal Pressman wrote: > > This isn't actually a matter of size - I don't expect that I'll have too > many sinks, I j

Re: [akka-user] Thread interrupt during message send

On Friday, February 19, 2016 at 12:25:36 AM UTC-8, rkuhn wrote: > > Hi Hbf, > > (which is a bit funny because I always read «Hauptbahnhof» :-) ) > I can imagine :) > there are no guarantees, we only promise at-most-once messaging. That > said, local message sends are

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

Thanks, √! On Friday, February 12, 2016 at 12:19:23 AM UTC-8, √ wrote: > > They will fail the stage if they throw > > -- > Cheers, > √ > On Feb 12, 2016 8:54 AM, "hbf" <h...@dreizak.com > wrote: > >> Hey everybody, >> >> The documenta

[akka-user] Thread interrupt during message send

and the "real" one, I'd like to confirm this. Thanks! Hbf [ERROR] [02/18/2016 21:39:03.400] [Thread-3] [akka://default/system/testProbe-2] interrupted during message send java.lang.InterruptedException at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAc

[akka-user] Re: [ANNOUNCE] Akka 2.4.2 including Streams and HTTP Released!

Thanks a lot! – A "humongous" thanks, I want to say :) One question: will there be a release for Scala 2.10 (i.e., 'com.typesafe.akka:akka-actor_2.10:2.4.2')? – Hbf On Wednesday, February 17, 2016 at 7:42:18 AM UTC-8, Konrad Malawski wrote: > > *Dear hakkers,* > >

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 <k...@iaeth.ch > wrote: > &

[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

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

Hey Akka Stream'ers, Is there a simple way to await the completion of stream? If I have a source that is not yet connected, I can pipe it throw a Sink.fold() to materialize it to Future. This allows me to wait for the stream to complete. But what if I already have a sink and it doesn't

Re: [akka-user] [akka-stream] Wait until two sinks are completed

turn SinkShape.of(bcast.in()); > }); > > Hope this helps, happy hakking! > > -- > Cheers, > Konrad 'ktoso’ Malawski > Akka <http://akka.io> @ Typesafe <http://typesafe.com> > > On 23 December 2015 at 05:23:29, hbf (kaspar@gmail.com ) > wrote: >

[akka-user] [akka-stream] Wait until two sinks are completed

Hey everybody, I can create a sink that broadcasts incoming messages to a given list of sinks. How can I make that sink materialize a future that completes when the downstream sinks have completed? For example, final Source in = Source.from(Arrays.asList(1, 2, 3,

[akka-user] Deadlock in a flow with a cycle?

Hey everybody, I'm trying to convince myself that a flow I'm building with Akka Streams is deadlock-free. Here's what I'm trying to do: - I have an infinite source *s* of some kind of requests *r1, r2, ... *that I need "execute". - In case such an execution fails, I'd like to

[akka-user] Re: [Akka Streams] Sink vs Flow (or: committing offsets after writing to Kafka)

You'd write your message out in processMessage. – Kaspar > HTH, > > Julian > > On Sunday, October 11, 2015 at 11:55:21 PM UTC+1, hbf wrote: >> >> Hi, >> >> I using Akka streams to read (= consume) messages from a Kafka tropic, >> transform them, and write the

[akka-user] [Akka Streams] Sink vs Flow (or: committing offsets after writing to Kafka)

Hi, I using Akka streams to read (= consume) messages from a Kafka tropic, transform them, and write them to another Kafka topic. I am looking for a way to commit the consumer offset of a message after it was written. Example: if I've read message *m*, I'd like to first process it and write