[akka-user] DI and Testing Streams

2016-05-04 Thread Richard Rodseth
I have some streams to test. Each one implements a particular "command". In recent days I have warmed up to using a combination of implicit parameters and constructor injection for DI. http://carefulescapades.blogspot.com/2012/05/using-implicit-parameters-for.html Some of my former singletons

Re: [akka-user] Native LevelDB crashes Akka tests

2016-05-04 Thread Patrik Nordwall
If you tell me the version of Akka when it worked and when not I can take a look at the diff to see if we changed anything in this area. We use leveldb for almost all Akka Persistence tests and we have not noticed any such problem. /Patrik ons 4 maj 2016 kl. 21:51 skrev Paul Roman

Re: [akka-user] Native LevelDB crashes Akka tests

2016-05-04 Thread Paul Roman
Yeah, I can double-check if something changed in sbt (our sbt configs didn't change) around forking - again "it was working before" type of situation. I posted it here since LevelDB is single-threaded and if you changed something in Akka internals this could blow up leveldb - just a wild guess,

Re: [akka-user] Call a function on overflow

2016-05-04 Thread Viktor Klang
+1! -- Cheers, √ On May 4, 2016 7:28 PM, "Tim Harper" wrote: > I should mention... it came to my attention that Source.queue has been > added since I first learned Akka Streams, and that as of 2.4.3, the object > returned by Source.queue can be closed. > > Super happy

Re: [akka-user] Call a function on overflow

2016-05-04 Thread Tim Harper
I should mention... it came to my attention that Source.queue has been added since I first learned Akka Streams, and that as of 2.4.3, the object returned by Source.queue can be closed. Super happy about that. On Wednesday, May 4, 2016 at 11:16:16 AM UTC-6, Tim Harper wrote: > > > On

Re: [akka-user] Call a function on overflow

2016-05-04 Thread Tim Harper
On Wednesday, May 4, 2016 at 8:14:10 AM UTC-6, Johan Andrén wrote: > > > Note that all mutable state should go in the GraphStageLogic, as the > GraphStage is a blueprint that you can create once and materialize multiple > time. > Excellent catch! Thank you. On Wednesday, May 4, 2016 at

Re: [akka-user] Call a function on overflow

2016-05-04 Thread Endre Varga
ah, there is a buffer.isEmpty check before. On Wed, May 4, 2016 at 4:27 PM, Endre Varga wrote: > ... and buffer.poll() might return null. > > On Wed, May 4, 2016 at 4:22 PM, Viktor Klang > wrote: > >> And, the Async Callback is not executed

Re: [akka-user] Call a function on overflow

2016-05-04 Thread Endre Varga
... and buffer.poll() might return null. On Wed, May 4, 2016 at 4:22 PM, Viktor Klang wrote: > And, the Async Callback is not executed concurrently with the graphstage > so no need for the AtomicBoolean, no? > > On Wed, May 4, 2016 at 4:14 PM, Johan Andrén

Re: [akka-user] Call a function on overflow

2016-05-04 Thread Johan Andrén
Tim, Great to hear! Note that all mutable state should go in the GraphStageLogic, as the GraphStage is a blueprint that you can create once and materialize multiple time. -- Johan Andrén Akka Team, Lightbend Inc. -- >> Read the docs: http://akka.io/docs/ >> Check

Re: [akka-user] Call a function on overflow

2016-05-04 Thread Tim Harper
GraphStage is the way to go. I didn't find an example, specifically, for doing this, but I whipped a component together. https://gist.github.com/timcharper/3d4c5ebc59669f7243bd4c1589ae308f Works wonderfully and has better

[akka-user] Re: Using materialized values from stages

2016-05-04 Thread Durga Prasana
Hi Johan, That should work. However, solving it this way would mean non-DRY implementation throughout a graph's stages. Soon, users would want to get insight into how each of their stage is processing & that insight could be some derived info (which can only be determined in specific stage

[akka-user] Re: Using materialized values from stages

2016-05-04 Thread Johan Andrén
Hi Durga, One way would be to keep those stats in an actor, and have a branch that sends that data to it. Something like this: val statsActorSink = Sink.actorRef(refToStatsActor, Done) regularSource.alsoTo(statsActorSink).via(regularProcessingFlow).to(regularSink) This will send every event

[akka-user] Re: Actor with stash

2016-05-04 Thread Johan Andrén
Hi Radi, The UntypedActorWithUnrestrictedStash does not enforce a concrete mailbox but the chosen mailbox must still implement akka.dispatch.DequeBasedMessageQueueSemantics. This is missing from the Java API docs I'm afraid, I have opened a ticket to fix that:

Re: [akka-user] Native LevelDB crashes Akka tests

2016-05-04 Thread Konrad Malawski
Could be better to ask on the LevelDB communities, I don't think we've seen such problems. We don't recommend LevelDB for anything else than just trying out Persistence - for real apps you should pick a distributed journal most of the time. --  Konrad `ktoso` Malawski Akka @ Lightbend On 3 May

[akka-user] Split stream in arbitrary number of sinks

2016-05-04 Thread Filippo De Luca
Hi, I was looking at the reactive tweets stream example when the stream is broadcasted to two downstream sinks. I need to do something similar: I have a Source of rows and I want to distribute these row across several substreams based on a column value. The issue is that I don't know the number

[akka-user] Active/passive deployment

2016-05-04 Thread Denis Mikhaylov
Hi! What is a recommended way to achieve active/passive deployments between 2 DCs? It is clear that only one cluster could be running at time. So in case of failure Ops should shutdown cluster in a failed dc, start the app in another dc, and then switch the traffic. That could take a lot of

[akka-user] [Akka-stream|http] - How to close a flow with killswitch from outside?

2016-05-04 Thread Magnus Andersson
I don't understand how you are to detect this behavior. You have a throttle for 1mgs/sec and a buffer of 1000mgs and a overflow strategy to drop messages. The messages will keep coming if you don't fill up the buffer, up to 1000 seconds after upstream has stopped sending messages. Is this