lization may not always be
desired.
Hbf
> --
> Cheers,
> √
>
> On Feb 8, 2017 03:33, "hbf" > wrote:
>
>> Heya everybody!
>>
>> I know that Akka Stream elegantly distinguishes *describing* a graph
>> from *materializing* a graph.
>>
e the some 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
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 hold
1000, size => 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/
>>>>>>>>>>
Thanks for clarifying, Konrad.
– Hbf
On Tuesday, September 20, 2016 at 4:33:53 PM UTC-7, Konrad Malawski wrote:
>
>
> final Source source = // ...
> final MutableInt max = new MutableInt(Integer.MIN_VALUE);
> final Procedure f = i -> {
>
e AtomicInteger so that the effects
are seen by all threads?
Thanks!
Hbf
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/c
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
>
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
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" > wrote:
>
>> Hey everybody,
>>
>> The documentatio
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.
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,*
>
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
--
>>>>>>>>>>
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
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 materia
;
>
> 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:
>
> Hey everybody,
>
> I c
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, 4, 5));
final
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 wait
)
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
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
it
19 matches
Mail list logo