Re: [akka-user] akka stream : Source[S](init: => Future[(Option[S], R)] )( f: S => Future[(Option[S], R)]

[Viktor Klang]

Hi Valérian,

https://github.com/akka/akka/issues/19021

On Tue, Dec 1, 2015 at 5:35 PM, Valérian B  wrote:

> Hi,
>
> I would like to build something like that :
> Source[S, R](init: => Future[(Option[S], R)])(f: S => Future[(Option[S],
> R)]
>
> S is the State
> R is the Result aka the elements used later in the flow
> f is called recursively with the State S from the result
> the recursion stop when the future is success of (None, R)
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Are there any libraries that help me implementing a Micro-Service Archicteture with Akka?

[Viktor Klang]

Hi John,

yes, it is most definitely usable from Java, here's the link to ConductR:
https://www.typesafe.com/products/conductr
And you can also try it out it in development for free (it's for-pay for
production usage): https://www.typesafe.com/product/conductr/developer

On Wed, Dec 9, 2015 at 7:13 PM,  wrote:

> Yes I ran over ConductR yesterday and seems to have a lot what I need.
> I think you have posted some videos on type safe.  I hope it will usable
> from  java.
> I am not allowed to use any scala
>
>
> Am Mittwoch, 9. Dezember 2015 14:44:34 UTC+1 schrieb Johan Andrén:
>>
>> You didn't mention if you are looking for something free/OSS so not sure
>> if this interests you, but there is ConductR from Typesafe that does
>> similiar
>> things to what you describe.
>>
>> You can find more info here: http://conductr.typesafe.com/docs/1.0.x/Home
>>
>> --
>> Johan Andrén
>> Typesafe -  Reactive apps on the JVM
>> Twitter: @apnylle
>>
>> On Friday, December 4, 2015 at 11:46:32 AM UTC+1, john@gmail.com
>> wrote:
>>>
>>> Hi,
>>>
>>> If I have a  bare bone Akka cluster running on n nodes with a fixed
>>> configuration.
>>> I am cosidering to build a system where one could deploy dynamically
>>> akka-jars to this cluster.
>>> These akka-jars should be  isolated as much as possible from each other.
>>> (Maybe through different classloaders)
>>>
>>> Does the akka echo system offer any thing here.
>>> I skimmed through the 2.4 docs but couldn't find much on this subject?
>>>
>>> Many Greetings
>>> john
>>>
>> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka streams: last n elements window

[Viktor Klang]

Would this work?

Flow[Double].buffer(n, OverflowStrategy.dropHead).grouped(n)

On Mon, Dec 14, 2015 at 10:37 AM, Andrea Ferretti 
wrote:

> I have a Akka streams application, and I would like to emulate the
> following behaviour: a node should emit the last n elements from upstream.
> It should never backpressure, but instead drop the oldest elements.
>
> The situation is as follows: there is an incoming stream of elements
> `source`. A few computations are to be ran on `source`, each of which will
> take some time. The results of the computations will be then zipped
> together. Downstream one is interested in having the freshest results, at
> the cost of skipping some elements.
>
> An example application would be like this:
>
>   val source: Source[Double] = ???
>   val n: Int = ???
>   def computation1(xs: Seq[Double]): Double = ???
>   def computation2(xs: Seq[Double]): Double = ???
>
>   val g = RunnableGraph.fromGraph(FlowGraph.create() { implicit builder =>
> import FlowGraph.Implicits._
>
> val broadcast = builder.add(Broadcast[Double](3))
> val merge = builder.add(ZipWith[A, B, C, (A, B, C)](Tuple3.apply))
> val comp1 = Flow[Double]
>   .nonBlockingSliding(n)
>   .map(computation1)
> val comp2 = Flow[Double]
>   .nonBlockingSliding(n)
>   .map(computation2)
>
> source ~> broadcast ~> merge.in0
> broadcast ~> comp1 ~> merge.in1
> broadcast ~> comp2 ~> merge.in2
> merge.out ~> Sink.foreach(println)
>
> ClosedShape
>   })
>
> The problem here is how to write the `.nonBlockingSliding` operation.
>
> I have tried to use the `sliding` method, but it backpressures, so for
> large values of n, the `merge` node never emits.
>
> What would be the best way to write this? I could use `transform` using a
> custom Stage, but I have the impression that some combination of `conflate`
> and `sliding` would be enough
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Streaming http call gives EntityStreamSizeException (2.0-M2)

[Viktor Klang]

Or use a negative value for without limit ;)

On Fri, Dec 18, 2015 at 3:25 PM, Konrad Malawski <
konrad.malaw...@typesafe.com> wrote:

> Yeah, you can use .withSizeLimit(Long.MaxValue), which is pretty much
> infinite in this context,
> It's around 9223 petabytes, pumping so much in a single http connection is
> rather unlikely :-)
>
> It could be made simpler I guess though withNoLimit hm... Would you open a
> ticket on github about it please? Thanks!
>
> --
> Cheers,
> Konrad 'ktoso’ Malawski
> Akka  @ Typesafe 
>
> On 18 December 2015 at 15:22:53, Jeroen Gordijn (jeroen.gord...@gmail.com)
> wrote:
>
> BTW is there a way to set infinite on a specific entity? I set put this in
> my application conf "max-content-length = infinite", but it seems
> reasonable to do this only for the entities where it makes sense.
> WithSizeLimit takes a long and although I could use Long.MaxValue, it
> doesn't state infinite.
>
> --Jeroen
>
> Op vrijdag 18 december 2015 15:16:40 UTC+1 schreef Jeroen Gordijn:
>>
>> Hi Konrad,
>>
>> thanks for you answer. This explains a lot and makes sense. Configuring
>> 'infinite' fixes my issue. The new error description makes it a lot easier.
>>
>> One thing I do notice is that the CPU keeps running high whenever I kill
>> 'curl'. Is there something I should do to close the stream? Suspending curl
>> works fine though.
>>
>> Thanks,
>> Jeroen
>>
>>
>> Op vrijdag 18 december 2015 14:17:47 UTC+1 schreef Konrad Malawski:
>>>
>>> It's a feature. (yes, really) :-)
>>>
>>> Allow me to explain; Akka HTTP always opts on the safe side of things.
>>> For example, if you write an endpoint that can get POST data, and
>>> someone (an attacker) sends you data and it never ends sending...
>>> You do want to kill that connection as soon as you notice something
>>> fishy is going on (i.e. perhaps an attack, someone sending loads of data
>>> and you never expected them to).
>>>
>>> So the default is to play safe, and limit any HTTP Entity to 8M (which
>>> is pretty huge anyway, if you think about it – we've heard
>>> people say "whoa, that's a huge default!", but of course they'd trim it
>>> down to a lower setting for production, suiting their needs).
>>>
>>> If you know that all calls you do will use streaming instead of
>>> "accumulate that infinite stream as String" (you can do that, right),
>>> you can disable this check by using the setting described here:
>>>
>>> http://doc.akka.io/docs/akka-stream-and-http-experimental/snapshot/scala/http/common/http-model.html#Limiting_message_entity_length
>>>
>>> So the value of:
>>> akka.http.[server|client].parsing.max-content-length
>>> (Depending if you want it for server or client).
>>>
>>> Last week I also improved that exception to be more self-explanatory,
>>> how it looks like this ( https://github.com/akka/akka/pull/19158 ):
>>> s"EntityStreamSizeException: actual entity size ($actualSize) exceeded
>>> content length limit ($limit bytes)! " +
>>> s"You can configure this by setting
>>> `akka.http.[server|client].parsing.max-content-length` or calling
>>> `HttpEntity.withSizeLimit` " +
>>> s"before materializing the dataBytes stream."
>>>
>>> So your question will have been answered by the exception itself
>>> hopefully :-)
>>>
>>>
>>> I also strongly recommend you have a look at this workshop I did on
>>> Scala Exchange a week ago:
>>>
>>> https://skillsmatter.com/skillscasts/6869-workshop-end-to-end-asynchronous-back-pressure-with-akka-streams
>>> It goes into depth who and how these things work the way they work.
>>>
>>> Thanks for trying out the early 2.0 milestones, we'll be releasing a
>>> "2.0" very soon, please upgrade to it then! :-)
>>> Hope this helps, happy hakking!
>>>
>>> --
>>> Cheers,
>>> Konrad 'ktoso’ Malawski
>>> Akka  @ Typesafe 
>>>
>>> On 18 December 2015 at 14:02:30, Jeroen Gordijn (jeroen@gmail.com)
>>> wrote:
>>>
>>> Same code with akka-streams 1.0 works fine.
>>>
>>> Is this a bug?
>>>
>>> Regards,
>>> Jeroen
>>>
>>> Op donderdag 17 december 2015 22:16:17 UTC+1 schreef Jeroen Gordijn:

 Hi all,

 I'm running into an EntityStreamSizeException when streaming data from
 a streaming response I got by calling another endpoint.. It is a little bit
 like presented in the talk by Mathias & Johannes at scalaworld:
 https://www.youtube.com/watch?v=6VBn9V3S2aQ

 I'm using with akka-http 2.0-M2 and created my problem in isolation.
 See the route (and link to full gist below). When I call `curl -i
 http://localhost:8080/endless`  the
 stream will continue indefinitely. However, when I call `curl -i
 http://localhost:8080/pipe`  it takes a
 few seconds to get "curl: (56) Recv failure: Connection reset by peer" on
 the client an the exception below on the server. The source below is just
 an example to isolate the problem.

 Am I doing s

Re: [akka-user] Bounded Mailboxes and throttling

[Viktor Klang]

Hi Jochen,

In my experience, the NACK-ing approach doesn't work. If you signal a
NACK-I'm-90%-full there could already be millions of items in flight. We
went through all of this for the Reactive Streams initiative, and I'm very
confident in that we ended up with the most reasonable solution :)

On Mon, Dec 28, 2015 at 7:01 PM, Jochen Mader 
wrote:

> Ok, so I am using it correctly :)
> The NACK-ing mailbox is something I will take a look at. But I'd rather
> spin it with "Hey, slow down I am 90% full" to retain some buffering and
> maybe get rid of messages already in flight.
> But I was basically just curious because in theory I should not run into
> such a scenario using Reactive Streams.
>
> Thanks,
> Jochen
>
> Am Montag, 28. Dezember 2015 17:57:44 UTC+1 schrieb Konrad Malawski:
>>
>> Hi Jochen,
>> The bounded mailboxes are designed around the idea that in Akka delivery
>> is at-most-once in any case (because network, and no re-delivery – unless
>> you use AtLeastOnceDelivery or do it yourself). So yeah, they're protecting
>> the receiver, nothing more - it's not a full-blown flow-control mechanism
>> just an overflow protection.
>>
>> In that sense, they stick to what is core to Akka – messages may be
>> dropped.
>> Replying a NACK ("hey, please slow down") on each dropped message in such
>> mailbox may sound interesting,
>> but in practice often you'd rather get back ACKs and base your sending of
>> data on those I think.
>>
>> A NACKing mailbox is not something we have built in. It's something you
>> could write though (you can write a mailbox).
>>
>> --
>> Cheers,
>> Konrad 'ktoso’ Malawski
>> Akka  @ Typesafe 
>>
>> On 28 December 2015 at 17:24:24, Jochen Mader (jochen...@codecentric.de)
>> wrote:
>>
>> Before I start: I am perfectly aware of Reactive Streams and it is what I
>> am currently using. I still use bounded mailboxes to prevent human error
>> from sneaking through.
>>
>> With the current implementation of bounded mailboxes there is no way that
>> either consumer or producer get to know if the mailbox is full or filling
>> up.
>> Overflow is redirected directly to Dead Letters with neither of them
>> being informed.
>> While preventing the crash of the system with an OOM it also feels like a
>> missed opportunity for throttling.
>> Are they just there to prevent OOMs or am I missing something in the API?
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+...@googlegroups.com.
>> To post to this group, send email to akka...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] fatjar with gradle and shadowjar

[Viktor Klang]

Hi Ash,

It's situations like these Google Groups shine since they are searchable:
https://groups.google.com/forum/#!searchin/akka-user/%22No$20configuration$20setting$20found$20for$20key%22%7Csort:date

Also, the Akka Documentation has a lot of effort put into it, and is a
great source of information:
http://doc.akka.io/docs/akka/2.4.1/general/configuration.html#When_using_JarJar__OneJar__Assembly_or_any_jar-bundler

Please let us know if you didn't find the answer in there,

Happy hAkking!


On Wed, Dec 30, 2015 at 6:15 PM, ash.ta  wrote:

> hi,
>
> i'm struggling with a gradle build in attempt to build a fatjar.
> following some examples i've found, i created the following gradle.build:
>
> import 
> com.github.jengelman.gradle.plugins.shadow.transformers.AppendingTransformer
>
> apply plugin: "java"
> apply plugin: "scala"
> apply plugin: "com.github.johnrengelman.shadow"
>
> sourceCompatibility = 1.8
> version = '0.0.1'
>
> if (!JavaVersion.current().java8Compatible) {
> throw new IllegalStateException("Java 8 is mandatory for building this 
> project")
> }
>
> repositories {
> mavenCentral()
> jcenter()
> }
>
> buildscript {
> repositories {
> jcenter {
> url "http://jcenter.bintray.com/";
> }
> }
> dependencies {
> classpath 'com.github.jengelman.gradle.plugins:shadow:1.2.2'
> }
> }
>
> dependencies {
>
> compile("com.typesafe.akka:akka-actor_2.11:2.4.1")
> compile("com.typesafe.akka:akka-cluster_2.11:2.4.1")
> compile("com.typesafe.akka:akka-cluster-tools_2.11:2.4.1")
> compile("com.typesafe.akka:akka-http-experimental_2.11:2.0.1")
> compile("com.typesafe.akka:akka-http-core-experimental_2.11:2.0.1")
> compile("org.scala-lang:scala-library:2.11.7")
>
> testCompile("junit:junit:4.11")
> }
>
> tasks.withType(ScalaCompile) {
> scalaCompileOptions.useAnt = false
> }
>
> task wrapper(type: Wrapper) {
> gradleVersion = '2.9'
> }
> jar {
> manifest {
> attributes "Main-Class": "com.whatever.Main"
> attributes "Build-Version": version
> }
> from {
> configurations.compile.collect { it.isDirectory() ? it : zipTree(it) }
> }
> archiveName 'fat.jar'
> }
>
> shadowJar {
> transform(AppendingTransformer) {
> resource = 'reference.conf'
> }
> }
>
>
>  unfortunately, i still fail to run created jar due to the following error:
>
> Exception in thread "main" com.typesafe.config.ConfigException$Missing: No
> configuration setting found for key 'akka.version'
>
> does anyone have an idea what do i miss here?
>
> thanks!
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Stream Grouping

[Viktor Klang]

Hi Marino,

Yes, the grouping function (if by that you mean "grouped(100)") is not done
in parallel (with respect to itself)

On Sat, Jan 2, 2016 at 6:35 PM, Marino Borra  wrote:

> Hi to all,
>
>
>
> I have a question. I want to create a flow that will process a large size
> List with these steps:
>
>
>
>1. Transform (concurrently) each elements
>2. Grouping (concurrently, one *grouped* per threads?) in Lists of
>1000 items
>3. With a function, simultaneously process the lists grouped
>
> I tried using the code below:
>
>   Flow[String].
> mapAsyncUnordered(5) {
> case audience:String => transform( audience, null )
> }.
> grouped(100).
> mapAsyncUnordered(4)( persist( _ ) ) )
>
> But the grouping function is executed sequentially
>
>
> Thanks to all for any suggestions
>
> Marino
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Stream Grouping

[Viktor Klang]

Hi Marino,

What (measurable) benefit are you looking to achieve and how are you
benchmarking it?

On Sun, Jan 3, 2016 at 11:23 AM, Marino Borra 
wrote:

> Hi Victor, thanks for your reply.
>
>
>
> Is possible to accumulate elements in parallel? Otherwise you can suggest
> a point of extensions?
>
>
> Il giorno sabato 2 gennaio 2016 19:38:54 UTC+1, √ ha scritto:
>>
>> Hi Marino,
>>
>> Yes, the grouping function (if by that you mean "grouped(100)") is not
>> done in parallel (with respect to itself)
>>
>> On Sat, Jan 2, 2016 at 6:35 PM, Marino Borra  wrote:
>>
>>> Hi to all,
>>>
>>>
>>>
>>> I have a question. I want to create a flow that will process a large
>>> size List with these steps:
>>>
>>>
>>>
>>>1. Transform (concurrently) each elements
>>>2. Grouping (concurrently, one *grouped* per threads?) in Lists of
>>>1000 items
>>>3. With a function, simultaneously process the lists grouped
>>>
>>> I tried using the code below:
>>>
>>>   Flow[String].
>>> mapAsyncUnordered(5) {
>>> case audience:String => transform( audience, null )
>>> }.
>>> grouped(100).
>>> mapAsyncUnordered(4)( persist( _ ) ) )
>>>
>>> But the grouping function is executed sequentially
>>>
>>>
>>> Thanks to all for any suggestions
>>>
>>> Marino
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Backpressure with akka-http

[Viktor Klang]

Hi Yaakov,

See:
http://doc.akka.io/docs/akka-stream-and-http-experimental/2.0.1/scala/http/routing-dsl/index.html#File_uploads

In short: you need to send the response *after* the upload has been
completed.

On Sun, Jan 3, 2016 at 4:13 PM, Yaakov Berkovitch <
yaakov.berkovi...@gmail.com> wrote:

> Hi,
>
> I'm trying to create a simple http-server that consumes slowly incoming
> http request . This is a kind of self-learning session and to demonstrate
> it internally in my company as Roland did it during some conference.
>
> My problem is that my flow is not slowing down and curl terminates
> immediately.
>
> Below is the relevant code:
>   val slowFlow = Flow[ByteString].mapAsync(1){x => after(10.second, system
> .scheduler)(Future.successful(x))}
>   val routes =
>
>   path("upload") {
>
> extractRequest { req =>
>
>   println(req)
>   req.entity.dataBytes.via(slowFlow).to(Sink.ignore).run()
>   complete(StatusCodes.OK)
> }
>   }
>
>
>
> Thanks,
> Yaakov
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka stream groupedWithin does not seem to work

[Viktor Klang]

And of course "Thread.sleep()" is evil™ also always applies.

On Mon, Jan 11, 2016 at 11:47 AM, Bruno Bieth  wrote:

> Thanks,
>
> @drewhk  told me this as well and it works! I
> forgot that akka-stream 2.0 introduced fusing...
>
> Regards,
> Bruno
>
>
> On Monday, January 11, 2016 at 10:36:28 AM UTC+1, rkuhn wrote:
>>
>> Hi Bruno,
>>
>> it works with fuzzing because the interpreter will only process one step
>> before looking into its Actor mailbox—but what actually breaks things is
>> your usage of Thread.sleep. If you want to block, you’ll typically want to
>> do so behind an Attributes.asyncBoundary.
>>
>> Regards,
>>
>> Roland
>>
>> 11 jan 2016 kl. 10:26 skrev Bruno Bieth :
>>
>> Turns out it works with fuzzing (explaining why it passes the test suite).
>> I've submitted an issue: https://github.com/akka/akka/issues/19394
>>
>> On Monday, January 11, 2016 at 8:45:19 AM UTC+1, Bruno Bieth wrote:
>>>
>>> I can't tell if I'm doing something wrong in this code:
>>>
>>> implicit val as = ActorSystem()
>>> implicit val mat = ActorMaterializer()
>>>
>>> val future = Source.fromIterator(() => new Iterator[Int] {
>>>   var i = 0
>>>   override def hasNext: Boolean = true
>>>   override def next(): Int = {
>>> println(s"Waiting $i seconds")
>>>
>>> scala.concurrent.blocking {
>>>
>>> Thread.sleep(i * 1000)
>>>
>>> }
>>> i = i + 1
>>> i
>>>   }
>>> }).groupedWithin(20, 2.seconds).runForeach(println)
>>>
>>> Await.ready(future, 10.seconds)
>>>
>>>
>>> It seems to me that at least something should be printed. But the output
>>> invariably is:
>>>
>>> Waiting 0 seconds
>>> Waiting 1 seconds
>>> Waiting 2 seconds
>>> Waiting 3 seconds
>>> Waiting 4 seconds
>>> Waiting 5 seconds
>>>
>>> java.util.concurrent.TimeoutException: Futures timed out after [1
>>> milliseconds]
>>>
>>> I tried to follow the code of GroupedWithin and it seems that the timer
>>> works as expected but then when the AsyncCall gets called nothing happens
>>> (from `GraphStage`):
>>>
>>> interpreter.onAsyncInput(GraphStageLogic.this, event, 
>>> handler.asInstanceOf[Any ⇒ Unit])
>>>
>>>
>>> Bruno
>>>
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+...@googlegroups.com.
>> To post to this group, send email to akka...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>>
>> *Dr. Roland Kuhn*
>> *Akka Tech Lead*
>> Typesafe  – Reactive apps on the JVM.
>> twitter: @rolandkuhn
>> 
>>
>> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka stream groupedWithin does not seem to work

[Viktor Klang]

Speaking of which: It would be interesting if it were possible to specify a
Clock to either the ActorSystem or the Materializer.

On Mon, Jan 11, 2016 at 12:22 PM, Bruno Bieth  wrote:

> Yeah :) but I couldn't figure a quicker way to test groupedWithin.
>
> On Monday, January 11, 2016 at 12:06:53 PM UTC+1, √ wrote:
>>
>> And of course "Thread.sleep()" is evil™ also always applies.
>>
>> On Mon, Jan 11, 2016 at 11:47 AM, Bruno Bieth  wrote:
>>
>>> Thanks,
>>>
>>> @drewhk  told me this as well and it works!
>>> I forgot that akka-stream 2.0 introduced fusing...
>>>
>>> Regards,
>>> Bruno
>>>
>>>
>>> On Monday, January 11, 2016 at 10:36:28 AM UTC+1, rkuhn wrote:

 Hi Bruno,

 it works with fuzzing because the interpreter will only process one
 step before looking into its Actor mailbox—but what actually breaks things
 is your usage of Thread.sleep. If you want to block, you’ll typically want
 to do so behind an Attributes.asyncBoundary.

 Regards,

 Roland

 11 jan 2016 kl. 10:26 skrev Bruno Bieth :

 Turns out it works with fuzzing (explaining why it passes the test
 suite).
 I've submitted an issue: https://github.com/akka/akka/issues/19394

 On Monday, January 11, 2016 at 8:45:19 AM UTC+1, Bruno Bieth wrote:
>
> I can't tell if I'm doing something wrong in this code:
>
> implicit val as = ActorSystem()
> implicit val mat = ActorMaterializer()
>
> val future = Source.fromIterator(() => new Iterator[Int] {
>   var i = 0
>   override def hasNext: Boolean = true
>   override def next(): Int = {
> println(s"Waiting $i seconds")
>
> scala.concurrent.blocking {
>
> Thread.sleep(i * 1000)
>
> }
> i = i + 1
> i
>   }
> }).groupedWithin(20, 2.seconds).runForeach(println)
>
> Await.ready(future, 10.seconds)
>
>
> It seems to me that at least something should be printed. But the
> output invariably is:
>
> Waiting 0 seconds
> Waiting 1 seconds
> Waiting 2 seconds
> Waiting 3 seconds
> Waiting 4 seconds
> Waiting 5 seconds
>
> java.util.concurrent.TimeoutException: Futures timed out after [1
> milliseconds]
>
> I tried to follow the code of GroupedWithin and it seems that the
> timer works as expected but then when the AsyncCall gets called nothing
> happens (from `GraphStage`):
>
> interpreter.onAsyncInput(GraphStageLogic.this, event, 
> handler.asInstanceOf[Any ⇒ Unit])
>
>
> Bruno
>

 --
 >> Read the docs: http://akka.io/docs/
 >> Check the FAQ:
 http://doc.akka.io/docs/akka/current/additional/faq.html
 >> Search the archives:
 https://groups.google.com/group/akka-user
 ---
 You received this message because you are subscribed to the Google
 Groups "Akka User List" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to akka-user+...@googlegroups.com.
 To post to this group, send email to akka...@googlegroups.com.
 Visit this group at https://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 *Dr. Roland Kuhn*
 *Akka Tech Lead*
 Typesafe  – Reactive apps on the JVM.
 twitter: @rolandkuhn
 

 --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc

Re: [akka-user] future usage within an actor

[Viktor Klang]

Hi Ash,

http://doc.akka.io/docs/akka/2.4.1/additional/faq.html#sender___getSender___disappears_when_I_use_Future_in_my_Actor__why_

On Tue, Jan 12, 2016 at 7:10 PM, ash.ta  wrote:

> hi hakkers,
>
> i have two actors: the first one patterns.ask() a message to the second
> one which returns a response:
>
> a snippet osender:
>
> ...
> public PartialFunction receive() {
> return ReceiveBuilder
> .match( Boolean.class, msg -> {
> ActorRef receiver = context().system()
>  .actorOf( Props.create( 
> ReceiveActor.class ), ReceiveActor.class
>  .getSimpleName() );
> Future future = Patterns.ask( receiver, "Hello 
> world", new Timeout( Duration
> .create( 5, "seconds" ) ) );
> Patterns.pipe( future, context().dispatcher() ).to( 
> self() );
> } )
> .match( String.class, msg-> log(msg) )
> .build();
> }
> *...*
>
>
> receiver:
>
> ...
> public PartialFunction receive() {
>
> return ReceiveBuilder.matchAny( msg -> {
> sender().tell( ((String)msg).toUpperCase(), self() );
> } ).build();
> }
> ...
>
>
> all is good, a message is sent and response arrives as expected.
>
> now, i try to change a receiver so that the message handling is done in a
> separate thread:
>
> ...
> public PartialFunction receive() {
> return ReceiveBuilder.matchAny( msg -> {
> Future done= Futures.future( (Callable) () -> 
> ((String)msg).toUpperCase(), context().dispatcher() ) ;
> done.onSuccess( new OnSuccess() {
> @Override
> public void onSuccess( String result ) throws Throwable {
> sender().tell( result, self() );
> }
> }, context().dispatcher() );
> } ).build();
> }
> ...
>
>
> in this case i get the following error:
>
> [akka://main/deadLetters] Message [java.lang.String] from
> Actor[akka://main/user/ReceiveActor#603147641] to
> Actor[akka://main/deadLetters] was not delivered.
>
> it seems that sender() within the future is not recognizable as my sender
> actor anymore.
>
> what do i miss and what is the solution?
>
> thanks!
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] future usage within an actor

[Viktor Klang]

In your case, spawn a child-actor?

On Tue, Jan 12, 2016 at 9:36 PM, ash.ta  wrote:

> hi again,
>
> thanks for your prompt response.
>
> in such case, what in your opinion is the right way to implement something
> like async calls to db? to use the async driver from an actor with a
> dedicated separate dispatcher
> and block the async call itself?
>
> cheers
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] future usage within an actor

[Viktor Klang]

:)

On Wed, Jan 13, 2016 at 9:41 AM, ash.ta  wrote:

> yup, thanks for help. already solved it using a child actor.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Service discovery?

[Viktor Klang]

Hi Igor,

ConductR (free for development) has built in service discovery for Akka
Cluster-based applications: https://conductr.typesafe.com/

On Thu, Jan 14, 2016 at 9:14 AM, Igor Katz  wrote:

> Thank you for your response.
>
> We have understood that we can perform service discovery in many different
> ways. We know that Akka supports a cluster for Actor system, but we want to
> use akka-http w/o Actors.
>
> *We want to know, does akka have plans to implement a service discovery in
> cluster for akka-stream/akka-http. If yes what is the estimated time?*
>
> Thanks,
>
> Igor
>
>
> On Wednesday, January 13, 2016 at 8:04:05 PM UTC+2, Michael Frank wrote:
>>
>> you could perform service discovery many different ways.  at a really
>> high level here are a few i can think of:
>>
>>1. be totally static.  place each of your microservices behind an
>>ELB, use AutoScaling (assuming AWS here).
>>2. use Zookeeper or Etcd for coordination.  Curator has some recipes
>>to do this for Zookeeper:
>>http://curator.apache.org/curator-x-discovery/index.html.
>>3. use akka cluster and specify node roles to differentiate different
>>microservices:
>>http://doc.akka.io/docs/akka/2.4.1/scala/cluster-usage.html#Node_Roles.
>>this requires you to write more code, akka just provides the framework 
>> here.
>>
>> these kinds of architectural questions are impossible to answer without
>> knowing your *business requirements* and the architecture you already have
>> in place.  you will get a better response if you do some more research,
>> evaluate the options you find, then come back and ask very specific,
>> targeted questions.  or you can talk to the fine people at Typesafe:
>> http://www.typesafe.com/services/consulting (i have no affiliation with
>> Typesafe, i just think they are smart people :)
>>
>> -Michael
>>
>> On 01/12/16 22:55, Igor Katz wrote:
>>
>> Hi,
>>
>> We need a service registry where all our components will turn to for
>> discovering the actual URLs which they can use to communicate to other
>> parts of our system. The service has to provide a load balancing and fault
>> tolerance. It has to be distributed to prevent a production outage. In
>> *CAP* 
>> terms, it has to be AP.
>> Igor
>>
>> On Wednesday, January 13, 2016 at 1:45:00 AM UTC+2, Michael Frank wrote:
>>
>>> On 01/12/16 07:28, Igor Katz wrote:
>>>
>>> Hi,
>>>
>>> We are going to use Akka-HTTP as IPC in our new distributed system that
>>> is based on microservice architecture. How to perform Service discovery
>>> for akka-stream/akka-http in distributed system? What is the best way to
>>> implement this?
>>>
>>> what are your requirements?
>>>
>>> -Michael
>>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives:
>> 
>> https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+...@googlegroups.com.
>> To post to this group, send email to akka...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Help on AudioInputStrem to Bytestring convert

[Viktor Klang]

Hi Pablo,

what have you tried and where are you stuck?

On Thu, Jan 14, 2016 at 11:31 AM, Pablo Souza  wrote:

> I'm trying to send RTCP packets and RTP with audio through a UDP Client
> Actor > UDP Server Actor . Can I convert AudioInputStrem to ByteString and
> ByteString to AudioInputStrem in Java? What better way to do this?
>
> There are examples of streaming audio using Akka?
>
> --
> Atenciosamente,
>
> Pablo Souza
> Twitter: @pvrsouza
> Tel.: (71) 9983-7775
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Utility of SubFlow generating methods confusing to me

[Viktor Klang]

+1!

On Mon, Jan 18, 2016 at 10:13 AM, Roland Kuhn  wrote:

> Wow, nice! Thanks a lot for your enthusiasm, Tim!
>
> 18 jan 2016 kl. 09:37 skrev Tim Harper :
>
> Okay! Here it is!
>
> https://github.com/akka/akka/pull/19501
>
> Working on this led me need to upgrade sbt-pgp, which led me to discover a
> bug in sbt's handling of AutoPlugins, which led me to work on SBT and
> submit a patch for that... finally to get to this.
>
> Thanks for being nice and helpful. Your interactions have rippled and
> inspired me.
>
> Tim
>
> On Jan 16, 2016, at 12:07, Roland Kuhn  wrote:
>
> Yes, thanks! (and to the Java version as well, please)
>
> 15 jan 2016 kl. 22:42 skrev Tim Harper :
>
> Fantastic explanation. I can work your answer into the docs. Any place
> you'd best like it go? I'm thinking here:
> http://doc.akka.io/docs/akka-stream-and-http-experimental/2.0.1/scala/migration-guide-1.0-2.x-scala.html#groupby-splitwhen-and-splitafter-now-return-subflow
>
>
> On Thursday, January 14, 2016 at 7:55:51 AM UTC-7, rkuhn wrote:
>>
>> Hi Tim,
>>
>> sorry again for the delay. You raise a valid question that is not
>> answered in the documentation, perhaps it should be.
>>
>> The handling of substreams has been a concern in our design from day 1,
>> the most prominent problem being that users may decide to not consume all
>> of them (using combinators like filter() or take() that drop elements
>> containing substream Publishers to the floor). This has an associated cost
>> because the substreams bind resources that need to be released explicitly,
>> plus it is very easy to create deadlocks by never consuming the data that
>> would need to be fed into these streams. Another pitfall for users is that
>> the substreams are coupled and must therefore be drained in a fashion that
>> is compatible with their source, in particular groupBy would deadlock
>> easily when merging the resulting streams with a breadth that is exceeded
>> at runtime.
>>
>> The idea for the change came from the Gearpump team, they mentioned that
>> the signature of groupBy in big data analytics does not usually return a
>> stream of streams, it returns a restricted substream abstraction that can
>> be handled specially by the platform. The issue for these engines is that
>> they are designed for flow graphs with a stable (i.e. non-dynamic) stream
>> layout, the network of combinators must be known before elements flow
>> through it. This is exactly what the new representation of
>> splitWhen/splitAfter/groupBy achieves, the materializer knows up-front what
>> shall be materialized for the substreams; this allows a wider range of
>> optimizations to be applied.
>>
>> Looking at the current signatures we see that they prevent users from
>> expressing most of the dangerous (deadlocking) stream layouts: groupBy will
>> limit the number of open streams and configure the merge such that it will
>> not deadlock, the split combinators make it impossible to write code that
>> tries to consume the substreams out-of-order. Dynamic processing can still
>> be expressed through stateful combinators like fold and scan that configure
>> the contained computation according to the first processed element—the
>> normal use of split is to factor out boundary detection from the rest of
>> the stream transformation.
>>
>> We left an escape hatch for those use-cases which require true
>> substreams, but we intentionally do not document it as such: using
>> prefixAndTail(0) you can lift a stream into a single element that contains
>> a sub-source that you can transform to your heart’s content—with all the
>> pitfalls.
>>
>> Looking ahead I see several more interesting applications of the SubFlow
>> infrastructure: we might offer a retry mechanism for pieces of a Flow, or
>> we might parallelize a piece of a Flow, or we might dynamically insert
>> processing steps depending on the first element of a Flow.
>>
>> I hope this explains the rationale and gives you some ideas on how to
>> exploit the new features, and if you see use-cases that are currently not
>> covered then please let us know!
>>
>> Regards,
>>
>> Roland
>>
>> 4 jan 2016 kl. 06:50 skrev Tim Harper :
>>
>> A big reason why groupBy, splitWhen (and other split* friends) were
>> useful was the ability to apply different behavior to the bifurcated
>> streams. With the recent (and, what seems to been a bit sudden) change to
>> SubFlow, I'm having a difficulty understanding the value of these methods.
>>
>> It seems like the only thing it offers you, now, is to provide a grouping
>> for parallelizing the streams, which I'll confess to be somewhat useful for
>> groupBy, but for the split* family of methods there seems to be little
>> tenable benefit.
>>
>> I scanned the gitter backlog for more backstory on why this change
>> happened. Being acquainted with Roland Kuhn's work, I entirely trust that
>> it was made thoughtfully and with good reason. Is there anything I can read
>> to understand more of the motivation for the cha

Re: [akka-user] MergePreferred is broken in 2.0._ ?

[Viktor Klang]

Wouldn't a little creativity with ThreadLocalRandom get us close to
"original" behavior?

On Mon, Jan 18, 2016 at 12:55 PM, Endre Varga 
wrote:

>
>
> On Mon, Jan 18, 2016 at 12:20 PM, Quizzie Fogg 
> wrote:
>
>> I understand that one side isn't completely drained (up to the complete),
>> but what I expect from MergePreferred is that as long as there is data
>> available at the preferred port, it takes data *only* from that port.
>> I agree that the issue could be caused by fusing, but is this wanted
>> behavior? Should fusing really stop MergePreferred from behaving as defined?
>>
>
> Well, it behaves as being defined since there are no guarantees on the
> priorities :)
>
> In fact, the logic of the stage is always the same independently of
> fusing, but what fusing changes that it removes any nondeterminism and
> always executes a specific ordering of events which could happen in the
> asynchronous case, just with less probabilty. In a very twisted way, this
> means actually that MergePreferred is working exactly within the boundaries
> of its specification :D
>
> The issue is basically that a mergePreferred is *not* a concat. In the
> concat case you just drain one input until it is finished, then take the
> other. mergePreferred is not allowed to do that, since if the preferred
> input is, let's say a tick, which is not yet available, but the other port
> has available input, then the non-preferred input must be consumed. This
> means though that this stage must alway pull both ports, unlike concat.
> This, due to the internal FIFO event queue of the interpreter, guarantees
> that in finite many rounds both ports are consumed if they have elements
> available.
>
> In fact, what this all means, that in a synchronous setting it is
> basically impossible to implement an intuitively valid mergePreferred.
> There are two conflicting goals:
>  - non-blocking (merge-like) behavior: always emit if there are elements
> available
>  - unfair: allocate more bandwith to one of the ports than to the rest
>
> The underlying force that is in motion here is basically the FIFO event
> queue of the interpreter. In order to be merge-like, all ports must be
> pulled, but due to FIFO ordering eventually all ports will receive the
> events and in a deterministic order. Once an input port is available and
> the output is also available, you must decide between
> merge-like/non-blocking behavior or unfairness.
>
> The current implementation is *actually* unfair, but this can only work,
> if steps needed to get the output port pulled again are more than the steps
> needed to get the preferred input to be pushed. This would guarantee that
> at the point where the output port is available, the preferred input is
> also available and hence unfairness can be maintained. There is a little
> bit of "buffer-like" behavior in our implementation that helps to achieve
> this, but there cannot be guarantees for all situations.
>
> -Endre
>
>
>
>>
>>
>> On Monday, January 18, 2016 at 11:50:31 AM UTC+1, drewhk wrote:
>>>
>>> I think what is happening here is the effects of fusing. I.e. all of
>>> these stages will be executed on the same thread and as such there won't be
>>> that much preferring going on. If you add an async boundary around your
>>> merge I would expect the old behavior to "come back".
>>>
>>> (Btw, preferred merge never guarantees that one side is completely
>>> drained before the other, that would be concat.)
>>>
>>> -Endre
>>>
>>>
>>>
>>> On Mon, Jan 18, 2016 at 11:35 AM, Quizzie Fogg 
>>> wrote:
>>>
 Hi.

 I think MergePreferred might not be working correctly in streams
 version 2.0._

 Old working test code (version 1.0):
 def mergePreferredMat[A, M1, M2, M3](sourceA: Source[A, M1], sourceB:
 Source[A, M2])(combine: (M1, M2) => M3): Source[A, M3] = {
   val merger = FlowGraph.partial(sourceB) { implicit b =>
 sourceB =>
   val merge = b.add(MergePreferred[A](1))
   sourceB ~> merge.in(0)
   FlowShape(merge.preferred, merge.out)
   }
   sourceA.viaMat(merger)(combine)
 }

 def testPreferred(): Unit = {
   val mergedSource = mergePreferredMat(TestPublisher.Probe[ByteString],
 TestPublisher.Probe[ByteString])(Keep.both)
   val (in1, in2, out): (TestPublisher.Probe[ByteString],
 TestPublisher.Probe[ByteString], TestSubscriber.Probe[ByteString]) =
 mergedSource.toMat(TestSubscriber.Probe[ByteString]) {
   case ((in1, in2), out) => (in1, in2, out)
 }.run()

   in2.sendNext(data2)
   in1.sendNext(data1)
   in2.sendNext(data2)
   in1.sendNext(data1)

   out.request(4)
   out.expectNext(data1)
   out.expectNext(data1)
   out.expectNext(data2)
   out.expectNext(data2)
 }
 The data is received in the correct order: first all the data from the
 preferred port 1, then all data from port 2.

 But in version 2.0._ (tested in 2.0.1 and 2.02) thi

Re: [akka-user] [akka-streams] How to deal with input Streams

[Viktor Klang]

Why do you want to read the entire document into memory?

On Wed, Jan 27, 2016 at 4:19 AM, Ryan Stradling 
wrote:

> Hi all,
> I have the below code.  I have a list of document ids that I want to
> return the documents for.  However, I want to stream each document's data
> chunk by chunk.  So the general structure would be
>
> Seq[DocId] -> Document(DocId, ByteString) -> sink
>
> So for instance for document id X whose document size is 10 bytes and my
> chunk size is 1 byte I would get
> Document(X, ByteString[Byte 0])
> Document(X, ByteString[Byte 1])
> ...
> Document(X, ByteString[Byte 9])
>
> I totally realize that Application.flow function I have is not correct as
> it will only give me the first chunk size.  It is meant as a "here is the
> stateful action I would want to do for my flow."
>
>
>
>
> import java.io.{InputStream}
>
> import akka.actor.ActorSystem
> import akka.stream.ActorMaterializer
> import akka.stream.scaladsl.{Flow, Source}
> import akka.util.ByteString
>
>
> object Database {
>
>   case class DocId(id: String)
>
>   case class Document(id: DocId, bs: ByteString)
>
>   trait Database {
> def getDocumentStream(id: DocId): Option[InputStream]
>
>   }
>
>   object ResourceDatabase extends Database {
> def getDocumentStream(id: DocId): Option[InputStream] = {
>   val rs = getClass.getResourceAsStream("/" + id.id + ".json")
>   if (rs != null) {
> Some(rs)
>   }
>   else {
> None
>   }
> }
>   }
> }
>
> object Application extends App {
>
>   import Database._
>
>   val source = Source(Vector(DocId("1"), DocId("2")))
>
>   def flow(): Flow[DocId, Option[Document], Unit] = {
> val emptyByteString = ByteString("")
> Flow[DocId].map { x =>
>   val ds = ResourceDatabase.getDocumentStream(x)
>   ds map { y =>
> /* Know this is not correct but would like to know how to do this 
> properly */
> val b = new Array[Byte](8192)
> val bytesRead = y.read(b, 0, 8192)
> if (bytesRead >= 0) {
>   Document(x, ByteString(b.take(bytesRead)))
> }
> else {
>   y.close
>   Document(x, emptyByteString)
> }
>   }
> }
>   }
>
>   import scala.concurrent.ExecutionContext.Implicits.global
>
>   implicit val system = ActorSystem("application-streams")
>   implicit val materializer = ActorMaterializer()
>   val f = source.via(flow).runForeach(x => x map {
> println _
>   })
>
>   f onFailure {
> case t => println("Failed with " + t.getMessage)
>   }
>   f onSuccess {
> case t => println("Success")
>   }
>   system.awaitTermination()
> }
>
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [akka-streams] How to deal with input Streams

[Viktor Klang]

What about Document(X, Source[ByteString]) ?

On Wed, Jan 27, 2016 at 2:18 PM, Ryan Stradling 
wrote:

> I absolutely don't want to read the whole file and apologize if it came
> across that way.  I want to export a tuple that contains the doc id and the
> bytes of the chunk.  The doc id is so that I can keep track of eventually
> what chunks go with which document.   So for example if I had in document X
> the bytes 012 and my chunk size was 1 byte I would expect 4 Document ids
> streamed
> Document(X, ["0"])
> Document(X, ["1"])
> Document(X, ["2"])
> Document(X, [""])
>
> And then downstream would write this to a sink.
>
>
> --
> >>  Read the docs: http://akka.io/docs/
> >>  Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>  Search the archives:
> https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Understanding materialized value

[Viktor Klang]

mapMaterializedValue

-- 
Cheers,
√
On Jan 28, 2016 5:04 AM, "Richard Rodseth"  wrote:

> I've since become aware that for something like counting a parent stream
> for monitoring purposes I could use alsoTo to a counting sink.
> But I'm still curious how a Source[T, Unit] becomes a Source[T, Mat], if
> such a thing makes sense.
>
> On Wed, Jan 27, 2016 at 2:36 PM, Richard Rodseth 
> wrote:
>
>> How does a Source[T, Unit] become a Source[T, M] ?
>>
>> I see that methods like via have a corresponding viaMat which let you
>> provide a combiner to combine the materialized value of the previous stage
>> and the next stage (I think)
>>
>> But how do you get the ball rolling with a Source?
>>
>> Say for example I have a stage that does a flatMapConcat and I want the
>> final materialized value to contain a tuple of the count of the parent
>> stream and a count of the final derived stream. I've done such counting
>> using folds but only at the Sink level
>>
>> I believe I have read the relevant sections of the docs, so apologies if
>> I am being slow on the uptake.
>>
>>
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [akka-streams] How to deal with input Streams

[Viktor Klang]

Glad you found the solution, my computer died yesterday so I am still
trying to recover from the loss and, setting up a new machine.

-- 
Cheers,
√
On Jan 29, 2016 2:53 AM, "Ryan Stradling"  wrote:

> And of course I find the solution right after I post. :) :(
>
> val f = source.via(flow).flatMapConcat(identity).runForEach(println(_))
>
> That solves both the interleave and the source of sources
>
> On Thursday, January 28, 2016 at 8:46:45 PM UTC-5, Ryan Stradling wrote:
>>
>> I have simplified the example further and got rid of some mistakes.
>> However, I effectively end up with a type of Source of Source.  This does
>> not seem correct to me.  Is there a way to flatten that given the code
>> below?
>>
>> In addition, how can I make it so all of the first documents are
>> processed before the second document rather than being interleaved?
>>
>> import java.io.{ByteArrayInputStream}
>> import akka.actor.ActorSystem
>> import akka.stream.ActorMaterializer
>> import akka.stream.scaladsl._
>> import akka.util.ByteString
>> import scala.concurrent.Future
>>
>>
>> object Database {
>>
>>   case class DocId(id: String)
>>
>>   object ResourceDatabase {
>> def getDocumentStream(id: DocId): Source[ByteString, Future[Long]] = {
>>   val i =   id.id.toByte
>>   val ba = new ByteArrayInputStream (Array.fill[Byte] (1)(i))
>>   StreamConverters.fromInputStream(() => ba, 1000)
>> }
>>   }
>> }
>>
>> object Application extends App {
>>
>>   import Database._
>>
>>   val source = Source(Vector(DocId("1"), DocId("2")))
>>
>>   def flow(): Flow[DocId, Source[ByteString, Future[Long]], Unit] = {
>> Flow[DocId] map ResourceDatabase.getDocumentStream
>>   }
>>
>>   import scala.concurrent.ExecutionContext.Implicits.global
>>
>>   implicit val system = ActorSystem("application-streams")
>>   implicit val materializer = ActorMaterializer()
>>
>>
>>   val f = source.via(flow).runForeach { y =>
>> y.runForeach(x => println(x))
>>   }
>>
>>   f onSuccess {
>> case t => println("Success")
>>   }
>>   f onFailure {
>> case t => println("Failure")
>>   }
>>
>>   system.awaitTermination()
>> }
>>
>>
>>
>> On Thursday, January 28, 2016 at 12:28:32 AM UTC-5, Ryan Stradling wrote:
>>>
>>> Here is what I have now...
>>> I am very curious about the following...
>>> 1) Is there a better way?  I am not sure that I am handling having a
>>> source that generates multiple sources correctly.  For instance in
>>> docStreamToDoc each source in the sequence is being run explicitly.
>>> 2) I am surprised by the output that the 2 documents are interleaved in
>>> certain places.  I would expect that not to be the case so maybe I am doing
>>> something incorrect?
>>> DocId(1) ByteString(91, 10, 32, 32, 123, 10, 32, 32, 32, 32)
>>> DocId(2) ByteString(91, 10, 32, 32, 123, 10, 32, 32, 32, 32)
>>> DocId(1) ByteString(34, 95, 105, 100, 34, 58, 32, 34, 53, 54)
>>> DocId(2) ByteString(34, 95, 105, 100, 34, 58, 32, 34, 53, 54)
>>> DocId(2) ByteString(97, 56, 50, 49, 98, 50, 102, 51, 53, 99)
>>>
>>>
>>>
>>> import java.io.{InputStream}
>>>
>>> import akka.actor.ActorSystem
>>> import akka.stream.ActorMaterializer
>>> import akka.stream.scaladsl._
>>> import akka.util.ByteString
>>>
>>> import scala.collection.immutable
>>> import scala.concurrent.Future
>>>
>>>
>>> object Database {
>>>
>>>   case class DocId(id: String)
>>>
>>>   case class Document(id: DocId, bs: Iterator[ByteString])
>>>   case class Document2(id: DocId, bs : ByteString)
>>>   case class DocumentStream(id : DocId, source : Source[ByteString, 
>>> Future[Long]])
>>>
>>>   trait Database {
>>> def getDocumentStream(id: DocId): DocumentStream
>>>
>>>   }
>>>
>>>   object ResourceDatabase extends Database {
>>> def getDocumentStream(id: DocId): DocumentStream = {
>>>   val rs = getClass.getResourceAsStream("/" + id.id + ".json")
>>>   DocumentStream(id, StreamConverters.fromInputStream(() => rs))
>>> }
>>>   }
>>> }
>>>
>>> object Application extends App {
>>>
>>>   import Database._
>>>
>>>   val source = Source(Vector(DocId("1"), DocId("2")))
>>>
>>>   def flow(): Flow[DocId, DocumentStream, Unit] = {
>>> val emptyByteString = ByteString("")
>>> Flow[DocId] map ResourceDatabase.getDocumentStream
>>>   }
>>>
>>>   def docStreamToDocFlow(): Flow[DocumentStream, Future[Seq[Document]], 
>>> Unit] = {
>>> implicit val materializer = ActorMaterializer()
>>> Flow[DocumentStream] map { ds =>
>>>   val grouped: Source[Iterator[ByteString], Future[Long]] = 
>>> ds.source.map(x => x.grouped(10))
>>>   val f: Future[Seq[Document]] = (grouped map { (s : 
>>> Iterator[ByteString]) => Document(ds.id, s)}).runWith(Sink.seq)
>>>   f
>>> }
>>>   }
>>>
>>>   import scala.concurrent.ExecutionContext.Implicits.global
>>>
>>>   implicit val system = ActorSystem("application-streams")
>>>   implicit val materializer = ActorMaterializer()
>>>
>>>
>>>   val f = source.via(flow).via(docStreamToDocFlow).runForeach { y =>
>>>

Re: [akka-user] Dynamic flow multiplexer

[Viktor Klang]

Hi Jakob,

Perhaps create a fanout Publisher from the Sink and materialize the
consumers as Subscribers and connect them to the Publisher?

-- 
Cheers,
√
On Jan 28, 2016 6:28 AM, "Jakob Odersky"  wrote:

> What is the best approach to "connecting" streams at run-time?
>
> My use-case is a server that has an established connection to some
> backend service, modeled as a flow. Several clients can connect
> through websockets, also modeled as flows.
>
> If the number of clients was known at materialization, this scenario
> would translate smoothly into a fan-out stage, as illustrated in the
> following figure:
>
>   <=> Client 1
> [I/O] <=> [Parser] <=> [FanOut]   <=> Client 2
> ...
>   <=> Client N
>
>
> The catch however is that during run-time, clients should be able
> connect and disconnect, without having to re-materialize (i.e.
> restart) the whole graph.
>
> I know that this kind of "mutable" configuration is not an appropriate
> situation to use graphs directly and have thought of another solution.
> My idea is to implement the above FanOut with a "multiplexer" actor. I
> would also implement custom GraphLogics that would interface with
> incoming connections (and also for the backend) and communicate with
> the multiplexer actor once materialized.
>
> Before I dive into that however, I was wondering if Akka already
> provides some similar solution out-of-the-box?
>
> thanks,
> --Jakob
>
> --
> >>  Read the docs: http://akka.io/docs/
> >>  Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>  Search the archives:
> https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Dynamic flow multiplexer

[Viktor Klang]

Hi Jakob,

Let us know how that solution fares!

-- 
Cheers,
√
On Jan 29, 2016 8:10 PM, "Jakob Odersky"  wrote:

> Hey Viktor,
> I never thought of using the underlying reactive streams API directly
> but it sounds like a good idea!
>
> cheers,
> --Jakob
>
> On Fri, Jan 29, 2016 at 12:45 AM, Viktor Klang 
> wrote:
> > Hi Jakob,
> >
> > Perhaps create a fanout Publisher from the Sink and materialize the
> > consumers as Subscribers and connect them to the Publisher?
> >
> > --
> > Cheers,
> > √
> >
> > On Jan 28, 2016 6:28 AM, "Jakob Odersky"  wrote:
> >>
> >> What is the best approach to "connecting" streams at run-time?
> >>
> >> My use-case is a server that has an established connection to some
> >> backend service, modeled as a flow. Several clients can connect
> >> through websockets, also modeled as flows.
> >>
> >> If the number of clients was known at materialization, this scenario
> >> would translate smoothly into a fan-out stage, as illustrated in the
> >> following figure:
> >>
> >>   <=> Client 1
> >> [I/O] <=> [Parser] <=> [FanOut]   <=> Client 2
> >> ...
> >>   <=> Client N
> >>
> >>
> >> The catch however is that during run-time, clients should be able
> >> connect and disconnect, without having to re-materialize (i.e.
> >> restart) the whole graph.
> >>
> >> I know that this kind of "mutable" configuration is not an appropriate
> >> situation to use graphs directly and have thought of another solution.
> >> My idea is to implement the above FanOut with a "multiplexer" actor. I
> >> would also implement custom GraphLogics that would interface with
> >> incoming connections (and also for the backend) and communicate with
> >> the multiplexer actor once materialized.
> >>
> >> Before I dive into that however, I was wondering if Akka already
> >> provides some similar solution out-of-the-box?
> >>
> >> thanks,
> >> --Jakob
> >>
> >> --
> >> >>>>>>>>>>  Read the docs: http://akka.io/docs/
> >> >>>>>>>>>>  Check the FAQ:
> >> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> >>>>>>>>>>  Search the archives:
> >> >>>>>>>>>> https://groups.google.com/group/akka-user
> >> ---
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Akka User List" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to akka-user+unsubscr...@googlegroups.com.
> >> To post to this group, send email to akka-user@googlegroups.com.
> >> Visit this group at https://groups.google.com/group/akka-user.
> >> For more options, visit https://groups.google.com/d/optout.
> >
> > --
> >>>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>>> Check the FAQ:
> >>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Akka User List" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to akka-user+unsubscr...@googlegroups.com.
> > To post to this group, send email to akka-user@googlegroups.com.
> > Visit this group at https://groups.google.com/group/akka-user.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> >>>>>>>>>>  Read the docs: http://akka.io/docs/
> >>>>>>>>>>  Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>>  Search the archives:
> https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Streaming protobuf objects

[Viktor Klang]

What's the layout of the file with protobuf objects?

On Sat, Jan 30, 2016 at 2:57 PM, Kyrylo Stokoz  wrote:

> Hi All,
>
> I`m trying to learn more about akka streams and have on first sight
> trivial task.
> I have a very large file of protobuf encoded objects i want to stream them
> using akka http streams.
>
> So i would like to create following flow:
>
>  Read file(s) -> parse protobuf into seq(domain objects) -> transform each
> object -> render result into json / other format -> send to receiver.
>
> I start with creating source from each file i needed to render using
> FileIO.fromFile(file).
> And i`m stuck on 2nd step: to parse protobufs i have 3 options:
> 1. Obj.parseFrom(inputstream): Obj
> 2. Obj.parseFrom(byte []): Obj
> 3. Obj.streamFromDelimitedInput(inputstream): Stream[Obj]
>
> So far i was not able to find a way how i can properly convert
> Source[ByteString, _] to Source[Obj, _].
>
> Is there any way to create above mentioned flow? ideally without loading
> all data in memory.
>
> So far i tried to play with:
> 1. Framing not success, i was not able to find correct delimiter to parse
> protobuf
> 2. Create Stream[Obj] using (Obj.streamFromDelimitedInput(input stream):
> Stream[Obj]) and later create Source from Stream - but this gives very
> poor performance results.
>
> Thanks in advance for your help,
> Kyrylo
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Streaming protobuf objects

[Viktor Klang]

Hi,

it is important to know how the file is layouted. (i.e. between MyObjects)

On Sat, Jan 30, 2016 at 6:32 PM, Kyrylo Stokoz  wrote:

> Sorry looks like i was wrong, there is no record length in beginning.
> Example of proto definition see below:
>
> message MyObject {
> optional string FieldName1 = 1;
> optional string FieldName2 = 2;
> optional string FieldName3 = 3;
> optional string FieldName4 = 4;
> optional int64 FieldName5 = 5;
> }
>
>
> On Saturday, January 30, 2016 at 6:19:40 PM UTC+1, Kyrylo Stokoz wrote:
>>
>> I guess you are interested how objects are stored:
>>
>> Initial bytes define length of record later goes record itself. Normally
>> i have file with 350K of them. Example head of file you can see below:
>> Hope this answers your question.
>>
>> ~$
>> ^I326216374^R^KtrafficFlow^Xú<85>^B">bb1246cb-6f12-4b9e-a68c-fe3f67e65388*
>> 324a6978e0ae0e159437dc03a3f00ad9~$
>> ^I326216375^R^KtrafficFlow^Xú<85>^B">f647601e-5b1f-4325-a0a4-48cc1a1598a6*
>> 9585fd96770a68faa41eb0bd202c45d1~$
>> ^I326216380^R^KtrafficFlow^Xú<85>^B">6e3c8929-dd6e-4de7-8342-8f5f08da9e38*
>> df06d0a9f4ef5d8866538f5d2352b3fd~$
>> ...
>>
>> On Saturday, January 30, 2016 at 4:16:53 PM UTC+1, √ wrote:
>>>
>>> What's the layout of the file with protobuf objects?
>>>
>>> On Sat, Jan 30, 2016 at 2:57 PM, Kyrylo Stokoz 
>>> wrote:
>>>
 Hi All,

 I`m trying to learn more about akka streams and have on first sight
 trivial task.
 I have a very large file of protobuf encoded objects i want to stream
 them using akka http streams.

 So i would like to create following flow:

  Read file(s) -> parse protobuf into seq(domain objects) -> transform
 each object -> render result into json / other format -> send to receiver.

 I start with creating source from each file i needed to render using
 FileIO.fromFile(file).
 And i`m stuck on 2nd step: to parse protobufs i have 3 options:
 1. Obj.parseFrom(inputstream): Obj
 2. Obj.parseFrom(byte []): Obj
 3. Obj.streamFromDelimitedInput(inputstream): Stream[Obj]

 So far i was not able to find a way how i can properly convert
 Source[ByteString, _] to Source[Obj, _].

 Is there any way to create above mentioned flow? ideally without
 loading all data in memory.

 So far i tried to play with:
 1. Framing not success, i was not able to find correct delimiter to
 parse protobuf
 2. Create Stream[Obj] using (Obj.streamFromDelimitedInput(input
 stream): Stream[Obj]) and later create Source from Stream - but this
 gives very poor performance results.

 Thanks in advance for your help,
 Kyrylo

 --
 >> Read the docs: http://akka.io/docs/
 >> Check the FAQ:
 http://doc.akka.io/docs/akka/current/additional/faq.html
 >> Search the archives:
 https://groups.google.com/group/akka-user
 ---
 You received this message because you are subscribed to the Google
 Groups "Akka User List" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to akka-user+...@googlegroups.com.
 To post to this group, send email to akka...@googlegroups.com.
 Visit this group at https://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> --
>>> Cheers,
>>> √
>>>
>> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Streaming protobuf objects

[Viktor Klang]

Sounds like you ought to write a parser GraphStage which decodes inbound
ByteStrings and emits ByteStrings, one per object, then you can decode it
no matter if it comes from a file or over network, and the conversion from
ByteString to your protobuf object can be a simple map()

-- 
Cheers,
√
On Jan 31, 2016 1:13 PM, "Kyrylo Stokoz"  wrote:

> Ok, i dug into how our objects are stored and indeed they have a record
> length in front of them, but unfortunately protobuf is using base 128
> varints (https://developers.google.com/protocol-buffers/docs/encoding),
> length field can be encoded in 1 byte for short records and 2-4 bytes for
> longer records.
>
> Basically in this case i cannot split stream into frames with Framing.
> lengthField.
>
> Taking into account proto layout is there anything i can do to build above
> mentioned pipeline in efficient way?
> Any suggestions very appreciated.
>
> Thanks,
> Kyrylo
>
> On Saturday, January 30, 2016 at 6:50:13 PM UTC+1, √ wrote:
>>
>> Hi,
>>
>> it is important to know how the file is layouted. (i.e. between MyObjects)
>>
>> On Sat, Jan 30, 2016 at 6:32 PM, Kyrylo Stokoz  wrote:
>>
>>> Sorry looks like i was wrong, there is no record length in beginning.
>>> Example of proto definition see below:
>>>
>>> message MyObject {
>>> optional string FieldName1 = 1;
>>> optional string FieldName2 = 2;
>>> optional string FieldName3 = 3;
>>> optional string FieldName4 = 4;
>>> optional int64 FieldName5 = 5;
>>> }
>>>
>>>
>>> On Saturday, January 30, 2016 at 6:19:40 PM UTC+1, Kyrylo Stokoz wrote:

 I guess you are interested how objects are stored:

 Initial bytes define length of record later goes record itself.
 Normally i have file with 350K of them. Example head of file you can see
 below:
 Hope this answers your question.

 ~$
 ^I326216374^R^KtrafficFlow^Xú<85>^B">bb1246cb-6f12-4b9e-a68c-fe3f67e65388*
 324a6978e0ae0e159437dc03a3f00ad9~$
 ^I326216375^R^KtrafficFlow^Xú<85>^B">f647601e-5b1f-4325-a0a4-48cc1a1598a6*
 9585fd96770a68faa41eb0bd202c45d1~$
 ^I326216380^R^KtrafficFlow^Xú<85>^B">6e3c8929-dd6e-4de7-8342-8f5f08da9e38*
 df06d0a9f4ef5d8866538f5d2352b3fd~$
 ...

 On Saturday, January 30, 2016 at 4:16:53 PM UTC+1, √ wrote:
>
> What's the layout of the file with protobuf objects?
>
> On Sat, Jan 30, 2016 at 2:57 PM, Kyrylo Stokoz 
> wrote:
>
>> Hi All,
>>
>> I`m trying to learn more about akka streams and have on first sight
>> trivial task.
>> I have a very large file of protobuf encoded objects i want to stream
>> them using akka http streams.
>>
>> So i would like to create following flow:
>>
>>  Read file(s) -> parse protobuf into seq(domain objects) -> transform
>> each object -> render result into json / other format -> send to 
>> receiver.
>>
>> I start with creating source from each file i needed to render using
>> FileIO.fromFile(file).
>> And i`m stuck on 2nd step: to parse protobufs i have 3 options:
>> 1. Obj.parseFrom(inputstream): Obj
>> 2. Obj.parseFrom(byte []): Obj
>> 3. Obj.streamFromDelimitedInput(inputstream): Stream[Obj]
>>
>> So far i was not able to find a way how i can properly convert
>> Source[ByteString, _] to Source[Obj, _].
>>
>> Is there any way to create above mentioned flow? ideally without
>> loading all data in memory.
>>
>> So far i tried to play with:
>> 1. Framing not success, i was not able to find correct delimiter to
>> parse protobuf
>> 2. Create Stream[Obj] using (Obj.streamFromDelimitedInput(input
>> stream): Stream[Obj]) and later create Source from Stream - but this
>> gives very poor performance results.
>>
>> Thanks in advance for your help,
>> Kyrylo
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives:
>> https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to akka-user+...@googlegroups.com.
>> To post to this group, send email to akka...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Cheers,
> √
>
 --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe f

Re: [akka-user] Akka HTTP 2 cpu scaling

[Viktor Klang]

Try 2.4.2-RC1?

On Mon, Feb 1, 2016 at 4:59 PM, Sebastian Jastrzebski 
wrote:

> Hi,
>
> I'm trying to run a simple load test against Akka HTTP 2.0 (2.0.3
> specifically using openjdk 8) and I'm having problems getting the server to
> saturate all cores. The cpu utilization revolves around 180% on a 8 core
> system resulting in 1300 req/s. Same test against Spay results in 700%
> utilization and 12000+ req/s.
>
> The setup is using reference akka and akka-http configuration.
>
> Any ideas on how to get these numbers and utilization up?
>
> Thanks
> -Sebastian
>
> ## Load Test Results
>
> > ab -c 100 -n 10 http://localhost:8080/v1/tweets
>
> Server Software:akka-http/2.3.12
> Server Hostname:localhost
> Server Port:8080
>
> Document Path:  /v1/tweets
> Document Length:61 bytes
>
> Concurrency Level:  100
> Time taken for tests:   76.685 seconds
> Complete requests:  10
> Failed requests:0
> Total transferred:  2140 bytes
> HTML transferred:   610 bytes
> Requests per second:1304.04 [#/sec] (mean)
> Time per request:   76.685 [ms] (mean)
> Time per request:   0.767 [ms] (mean, across all concurrent requests)
> Transfer rate:  272.52 [Kbytes/sec] received
>
> ## application.conf
>
> akka {
>   loglevel = ERROR
> }
>
> ## Backend
>
> import akka.actor.ActorSystem
> import akka.http.scaladsl.Http
> import akka.http.scaladsl.marshallers.sprayjson.SprayJsonSupport
> import akka.http.scaladsl.server.Directives._
> import akka.stream.ActorMaterializer
> import spray.json._
>
> case class Tweet(id: String, author: String, content: String)
>
> trait TweetProtocol extends DefaultJsonProtocol {
>   implicit val tweetFormatter = jsonFormat3(Tweet.apply)
> }
>
> object Boot extends App with TweetProtocol with SprayJsonSupport {
>
>   implicit val system = ActorSystem()
>   implicit val materializer = ActorMaterializer()
>
>   val routes = pathPrefix("v1") {
> path("tweets") {
>   get {
> complete {
>   List(Tweet("1", "author", "tweet"))
> }
>   }
> }
>   }
>
>   Http().bindAndHandle(
> handler = routes,
> interface = "localhost",
> port = 8080)
> }
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How to keep a Source alive

[Viktor Klang]

Perhaps a Source with a buffer attached with the appropriate dropping
strategy?

-- 
Cheers,
√
On Feb 3, 2016 9:17 AM, "Endre Varga"  wrote:

> Hi Claudio,
>
> I don't really understand your question here, a Source is alive until you
> close its output port. Can you show a simplified code example of what you
> mean?
>
> -Endre
>
> On Wed, Feb 3, 2016 at 12:04 AM, clca  wrote:
>
>> I searched through the topics but I could not find any example on how to
>> pull from a Source in the case where data is coming in bursts. I built a
>> customized Source that read from an external source. Data is coming in
>> bursts, the flow can stop for a while so I need to keep pulling the Source
>> in such a way I can keep reading data (the actual read process is done in
>> the old poll fashion). I guess I need something like a KeepAlive type of
>> mechanism for the data stream.
>>
>> BTW: Fantastic job with Akka, Akka Stream & Akka HTTP!
>>
>> Thanks
>> Claudio
>>
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka 2.4+, Java 8 low latency micro-services JVM GC options

[Viktor Klang]

Do you have a jmh bench for testing this?

-- 
Cheers,
√
On Feb 3, 2016 1:58 PM, "Guido Medina"  wrote:

> For what I could gather and after 2012 bug fixed on the Linux kernel for
> NUMA it is safe and profitable to use NUMA, though I'm not fully aware if
> G1GC is NUMA-aware, at least JVM is not complaining about it:
>
>-
>
> http://docs.oracle.com/javase/8/docs/technotes/guides/vm/performance-enhancements-7.html
>
> I also learned that Eden and Young Generation for G1GC are adjusted by the
> max pause in millis target hence I got mine to a low value to avoid full GC.
> Some options are on by default specially in Java 8 like
> *TieredCompilation* if you specify -server, etc.
> Remember the GC I/O bug (http://www.evanjones.ca/jvm-mmap-pause.html)
> while writing stats to */tmp/hsperfdata_${user}* which it can be resolved
> with either of the following options:
>
>- Map /tmp to RAM
>- Disable writing of stats which is OK for production but tools like
>VisualVM won't automatically discover your JVM.
>
> New fill listing of GC settings:
>
> -server
> -Xms256m
> -Xmx256m
> -XX:+UseNUMA
> -XX:+UseG1GC
> -XX:+AlwaysPreTouch
> -XX:MaxGCPauseMillis=10
> -XX:+PerfDisableSharedMem
> -XX:+ParallelRefProcEnabled
>
> Enjoy,
>
> Guido.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] SubFlow.to

[Viktor Klang]

I don't understand the question: What are you trying to achieve?

On Wed, Feb 3, 2016 at 5:55 PM, Richard Rodseth  wrote:

> Ok. I suppose I should examine the GroupBy or SubFlow source code, but if
> I understand correctly different stages will run concurrently (if fusing is
> off or async boundaries have been added), but there's not a separate actor
> for each substream in a SubFlow?
>
> On Wed, Feb 3, 2016 at 7:35 AM, Francesco Di Muccio <
> francesco.dimuc...@gmail.com> wrote:
>
>>
>> Il giorno mercoledì 3 febbraio 2016 15:30:29 UTC+1, rrodseth ha scritto:
>>>
>>> Thanks very much. Actually, I would argue this is preferable to what's
>>> in the template now, and both deserve a juicy comment!
>>>
>>> Does groupBy alone introduce any parallelism? With/without fusing? In
>>> this example, if there were n log levels rather than 5, would more than 5
>>> files be written concurrently?
>>>
>>> In this example the 5 (or n) files are written concurrently, but one
>> problem of this approach is that if mapAsync parallelism is less than 5 it
>> can deadlock the whole stream.
>>
>>
>>> With the proposed new two-input stage in akka, would parallel file
>>> writing be internal and configurable?
>>>
>>> This might be a good time to say that I am extremely impressed with the
>>> thought and ingenuity that has gone into this library, and love using it.
>>> Thanks!
>>>
>>> On Wed, Feb 3, 2016 at 2:56 AM, Roland Kuhn  wrote:
>>>
 Yes, this is exactly what I was referring to, and I hope it is clear
 that we don’t want to show this approach to users in the Activator
 template—we need a better solution :-)

 Thanks Francesco!

 Regards,

 Roland

 3 feb 2016 kl. 10:31 skrev Francesco Di Muccio >>> >:



 Il giorno mercoledì 3 febbraio 2016 01:54:55 UTC+1, rrodseth ha scritto:
>
> No worries. I wish I had the time and expertise to help.
>
> I don't mean to be a pest, but since my credibility with management is
> at stake [ :) ]  can anyone suggest any ways I can tackle the problem of
> groupBy followed by write to file?
>
> I might be able to get away with draining each substream to a
> collection and then using mapAsync to run a separate stream (per-key) to
> write the file, returning a Future as required by mapAsync. Not unlike
> where the activator template has ended up, but I'd really rather not.
>
> But I also find myself wondering if I could do something with fold,
> where the initial value contains the Sink for that substream.
>
> Roland also alluded to a hack(?) using prefixAndTail(0), but I don't
> quite see what that would look like.
>

 Hi,

 I can try to help using prefixAndTail, I came up with this so far:

 FileIO.fromFile(logFile).
   // parse chunks of bytes into lines
   via(Framing.delimiter(ByteString(System.lineSeparator),
 maximumFrameLength = 512, allowTruncation = true)).
   map(_.utf8String).
   map {
 case line@LoglevelPattern(level) => (level, line)
 case line@other => ("OTHER", line)
   }.
   // group them by log level
   groupBy(5, _._1).
   prefixAndTail(1).
   // write lines of each group to a separate file
   mapAsync(5) {
 case (Seq((level, line)), source) =>
   Source.single(line)
 .concat(source.map(_._2))
 .map(line => ByteString(line + "\n"))
 .runWith(FileIO.toFile(new
 java.io.File(s"target/log-$level.txt")))

 // Not sure that this will ever happen
 case _ =>
   Future.successful(0)
   }.
   mergeSubstreams.
   runWith(Sink.onComplete { _ =>
 system.shutdown()
   })

 What prefixAndTail does (if I got it right) emits a pair where the
 first value is a sequence of n elements (prefix), and
 the second value is the rest (tail) lifted to a source. Here I'm using
 prefixAndTail(1) because I need to extract the level
 from the first element to calculate the filename.

 Hope it helps,
 Francesco


> Clutching at straws!
>
> On Tue, Feb 2, 2016 at 12:27 AM, Roland Kuhn 
> wrote:
>
>> Yes, indeed, I didn’t have the time to get that link yesterday. If
>> anyone wants to work on that: contributions are *always* welcome! :-)
>>
>> Regards,
>>
>> Roland
>>
>> 1 feb 2016 kl. 23:59 skrev Richard Rodseth :
>>
>> For anyone following along, I believe this is the issue Roland refers
>> to
>>
>> https://github.com/akka/akka/issues/18969
>>
>> On Mon, Feb 1, 2016 at 2:28 PM, Richard Rodseth 
>> wrote:
>>
>>> Ouch. Thanks.
>>>
>>> On Mon, Feb 1, 2016 at 1:49 PM, Roland Kuhn 
>>> wrote:
>>>
 Hi Richard,

 this is not yet solved, and we have an issue tracking this in
 akka/akka as well. It is not certain that w

Re: [akka-user] SubFlow.to

[Viktor Klang]

Put in async boundaries where you want to have them. And writing to file
concurrently is likely not faster, but as always needs to be measured.

On Wed, Feb 3, 2016 at 6:55 PM, Richard Rodseth  wrote:

> Write sub streams to files as fast as possible. But this latest was just
> me trying to understand groupBy. I'm unclear whether the substreams are
> processed concurrently (in the case where there is no mapAsync). In other
> words if I call to() to pipe all substreams to the same actor will the
> actor receive interleaved items? And if not will the outputs at least be
> computed in parallel?
>
> Sent from my phone - will be brief
>
> On Feb 3, 2016, at 9:42 AM, Viktor Klang  wrote:
>
> I don't understand the question: What are you trying to achieve?
>
> On Wed, Feb 3, 2016 at 5:55 PM, Richard Rodseth 
> wrote:
>
>> Ok. I suppose I should examine the GroupBy or SubFlow source code, but if
>> I understand correctly different stages will run concurrently (if fusing is
>> off or async boundaries have been added), but there's not a separate actor
>> for each substream in a SubFlow?
>>
>> On Wed, Feb 3, 2016 at 7:35 AM, Francesco Di Muccio <
>> francesco.dimuc...@gmail.com> wrote:
>>
>>>
>>> Il giorno mercoledì 3 febbraio 2016 15:30:29 UTC+1, rrodseth ha scritto:
>>>>
>>>> Thanks very much. Actually, I would argue this is preferable to what's
>>>> in the template now, and both deserve a juicy comment!
>>>>
>>>> Does groupBy alone introduce any parallelism? With/without fusing? In
>>>> this example, if there were n log levels rather than 5, would more than 5
>>>> files be written concurrently?
>>>>
>>>> In this example the 5 (or n) files are written concurrently, but one
>>> problem of this approach is that if mapAsync parallelism is less than 5 it
>>> can deadlock the whole stream.
>>>
>>>
>>>> With the proposed new two-input stage in akka, would parallel file
>>>> writing be internal and configurable?
>>>>
>>>> This might be a good time to say that I am extremely impressed with the
>>>> thought and ingenuity that has gone into this library, and love using it.
>>>> Thanks!
>>>>
>>>> On Wed, Feb 3, 2016 at 2:56 AM, Roland Kuhn  wrote:
>>>>
>>>>> Yes, this is exactly what I was referring to, and I hope it is clear
>>>>> that we don’t want to show this approach to users in the Activator
>>>>> template—we need a better solution :-)
>>>>>
>>>>> Thanks Francesco!
>>>>>
>>>>> Regards,
>>>>>
>>>>> Roland
>>>>>
>>>>> 3 feb 2016 kl. 10:31 skrev Francesco Di Muccio >>>> >:
>>>>>
>>>>>
>>>>>
>>>>> Il giorno mercoledì 3 febbraio 2016 01:54:55 UTC+1, rrodseth ha
>>>>> scritto:
>>>>>>
>>>>>> No worries. I wish I had the time and expertise to help.
>>>>>>
>>>>>> I don't mean to be a pest, but since my credibility with management
>>>>>> is at stake [ :) ]  can anyone suggest any ways I can tackle the problem 
>>>>>> of
>>>>>> groupBy followed by write to file?
>>>>>>
>>>>>> I might be able to get away with draining each substream to a
>>>>>> collection and then using mapAsync to run a separate stream (per-key) to
>>>>>> write the file, returning a Future as required by mapAsync. Not unlike
>>>>>> where the activator template has ended up, but I'd really rather not.
>>>>>>
>>>>>> But I also find myself wondering if I could do something with fold,
>>>>>> where the initial value contains the Sink for that substream.
>>>>>>
>>>>>> Roland also alluded to a hack(?) using prefixAndTail(0), but I don't
>>>>>> quite see what that would look like.
>>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I can try to help using prefixAndTail, I came up with this so far:
>>>>>
>>>>> FileIO.fromFile(logFile).
>>>>>   // parse chunks of bytes into lines
>>>>>   via(Framing.delimiter(ByteString(System.lineSeparator),
>>>>> maximumFrameLength = 512, allowTruncation = true)).
>>>>>   map(_.utf8String).
>>>>>   map 

Re: [akka-user] Re: How to keep a Source alive

[Viktor Klang]

I don't see why you'd need to write a custom GraphStage for this.

unfold/unfoldAsync paired with a buffer with an appropriate dropping policy
should work, no?

On Wed, Feb 3, 2016 at 8:47 PM, clca  wrote:

> Yes this is close to what I need to do.
> The code in the onPull method is something like
>
> val m = ReadFromService(...)
> if(m != null)
>push(out, m)
>
> in a traditional app reading would be done in a loop
>
> while(true) {
>   val m = ReadFromService(...)
> //do something with the new message
> }
>
> So I'll add a mechanism  in the Source to keep polling the external
> service.
>
> Thanks!
>
>
> On Wednesday, February 3, 2016 at 12:55:16 AM UTC-8, john@gmail.com
> wrote:
>>
>> I've done something similar.
>> I adapted this JobManager
>> .
>> When no data is available( for example when it recieves a Request(16)
>> Messag) it starts a" polling Actor" which polls an external Database for
>> more data.
>> Does this help?
>>
>> Am Mittwoch, 3. Februar 2016 08:33:16 UTC+1 schrieb clca:
>>>
>>> I searched through the topics but I could not find any example on how to
>>> pull from a Source in the case where data is coming in bursts. I built a
>>> customized Source that read from an external source. Data is coming in
>>> bursts, the flow can stop for a while so I need to keep pulling the Source
>>> in such a way I can keep reading data (the actual read process is done in
>>> the old poll fashion). I guess I need something like a KeepAlive type of
>>> mechanism for the data stream.
>>>
>>> BTW: Fantastic job with Akka, Akka Stream & Akka HTTP!
>>>
>>> Thanks
>>> Claudio
>>>
>>>
>> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka HTTP Performance (2.4.2-RC1)

[Viktor Klang]

https://groups.google.com/forum/#!topic/akka-user/Cb_wg7nVbx4

On Wed, Feb 3, 2016 at 9:05 PM, tigerfoot  wrote:

> Hello,
>
> I'm running some simple HTTP performance measurements.  I've created a
> trivial "ping" endpoint (blindly returns "pong") in Akka HTTP and hit it
> like this:
>
> val now = System.currentTimeMillis()
> (1 to 500).foreach(i => {
>   HttpUtil.send(HttpRequest(uri = 
> s"http://$IP:8082/ping";).withHeaders(ApiVerHeader("v1.0"))).status
> should be(StatusCodes.OK)
> })
> val later = System.currentTimeMillis()
> println("TIME: " + (later - now))
>
>
> Ok, so I'm timing the send of 500 ping requests running on the same
> machine as the server.  My time for this was 3114ms.  Granted these are
> fully serialized in my test, and I will try a non-blocking client run, but
> I'm still surprised by the low throughput.  I thought the serialized test
> would best show the overhead of the HTTP processing, vs total possible
> throughput.
>
> I also see on my screen a few hundred of these messages:
>
> 13:47:51.953 [foo-akka.actor.default-dispatcher-17] ERROR
> akka.actor.ActorSystemImpl - Outgoing request stream error
> akka.stream.AbruptTerminationException: Processor actor
> [Actor[akka://foo/user/StreamSupervisor-0/flow-1046-0-unknown-operation#291433690]]
> terminated abruptly
>
> Not sure what these are, or if they're just harmless noise generated when
> I shut down my ActorSystem after the test.
>
> Does this performance seem about right/expected?  I was hopeful to see a
> stronger showing since 2.4.2 was supposed to be getting closer to Spray's
> performance.
>
> Greg
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: How to keep a Source alive

[Viktor Klang]

http://doc.akka.io/api/akka-stream-and-http-experimental/2.0.3/?_ga=1.45749860.1579561034.1353497989#akka.stream.scaladsl.Source$

On Wed, Feb 3, 2016 at 11:06 PM,  wrote:

> where do I find unfold/unfoldAsync ? I looked at
> http://doc.akka.io/docs/akka-stream-and-http-experimental/2.0.3/stages-overview.html
> ?
> Many Greetings
> John
>
>
> Am Mittwoch, 3. Februar 2016 20:51:17 UTC+1 schrieb √:
>>
>> I don't see why you'd need to write a custom GraphStage for this.
>>
>> unfold/unfoldAsync paired with a buffer with an appropriate dropping
>> policy should work, no?
>>
>> On Wed, Feb 3, 2016 at 8:47 PM, clca  wrote:
>>
>>> Yes this is close to what I need to do.
>>> The code in the onPull method is something like
>>>
>>> val m = ReadFromService(...)
>>> if(m != null)
>>>push(out, m)
>>>
>>> in a traditional app reading would be done in a loop
>>>
>>> while(true) {
>>>   val m = ReadFromService(...)
>>> //do something with the new message
>>> }
>>>
>>> So I'll add a mechanism  in the Source to keep polling the external
>>> service.
>>>
>>> Thanks!
>>>
>>>
>>> On Wednesday, February 3, 2016 at 12:55:16 AM UTC-8, john@gmail.com
>>> wrote:

 I've done something similar.
 I adapted this JobManager
 .
 When no data is available( for example when it recieves a Request(16)
 Messag) it starts a" polling Actor" which polls an external Database for
 more data.
 Does this help?

 Am Mittwoch, 3. Februar 2016 08:33:16 UTC+1 schrieb clca:
>
> I searched through the topics but I could not find any example on how
> to pull from a Source in the case where data is coming in bursts. I built 
> a
> customized Source that read from an external source. Data is coming in
> bursts, the flow can stop for a while so I need to keep pulling the Source
> in such a way I can keep reading data (the actual read process is done in
> the old poll fashion). I guess I need something like a KeepAlive type of
> mechanism for the data stream.
>
> BTW: Fantastic job with Akka, Akka Stream & Akka HTTP!
>
> Thanks
> Claudio
>
>
 --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: [akka-stream-2.0.3] Flow with drop-everything feedback branch doesn't terminate

[Viktor Klang]

Follow the demand.

On Thu, Feb 4, 2016 at 9:43 PM, Giovanni Alberto Caporaletti <
paradi...@gmail.com> wrote:

> Hi Endre,
>
> Why do I need buffer space if I only send a single element and drop
> everything else in the feedback loop?
>
> On Thursday, 4 February 2016 20:46:21 UTC+1, drewhk wrote:
>>
>> Hi Giovanni,
>>
>> There is not enough buffer space in the loop, hence it deadlocks.
>>
>> -Endre
>>
>> On Thu, Feb 4, 2016 at 8:37 PM, Giovanni Alberto Caporaletti <
>> para...@gmail.com> wrote:
>>
>>> Ok, what about this then: it's supposed to print 42,43,44...49 and then
>>> complete. It only prints 42 with eagerClose = true and it hangs after 42
>>> with eagerClose = false.
>>>
>>> The broadcast waits for the merge and the merge waits for the broadcast.
>>>
>>> I guess it's something similar to the chicken-and-egg scenario described
>>> here:
>>>
>>> http://doc.akka.io/docs/akka-stream-and-http-experimental/2.0.2/scala/stream-graphs.html#graph-cycles-liveness-and-deadlocks
>>>
>>> object Test extends App {
>>>   implicit val system = ActorSystem()
>>>   implicit val mat = ActorMaterializer()
>>>
>>>   val flow = Flow.fromGraph(GraphDSL.create() { implicit b =>
>>> import GraphDSL.Implicits._
>>>
>>> val add1AndDropGT50 = b.add(Flow[Int].map(_ + 1).filter(_ < 50))
>>> val input = b.add(Merge[Int](2, eagerClose = true))
>>> val bcast = b.add(Broadcast[Int](2))
>>>
>>> input   ~> bcast
>>> input.in(1) <~ add1AndDropGT50  <~ bcast.out(1)
>>>
>>> FlowShape(input.in(0), bcast.out(0))
>>>   })
>>>
>>>
>>> On Thursday, 4 February 2016 19:43:20 UTC+1, RC213V wrote:

 I am brand new and learning.

 From what i understand, merge(input) has 2 inputs one from single
 source (42) and from the output of broadcast.
 Merge apply function looks like this

 object Merge {

   def apply[T](inputPorts: Int, eagerComplete: Boolean = false): Merge[T] 
 = new Merge(inputPorts, eagerComplete)

 }


 The eager complete flag controls when the merge element will run to
  completion.
 If the eager complete flag is set to true, then if any of the upstreams
 providing input to the merge complete the merge stage will complete.
 If the eager complete flag is set to false, then all the upstreams
 providing input to the merge has to complete to complete the merge stage.

 I am assuming   input.in(1) <~ dropEverything <~ bcast.out(1) which is
 one of the input to merge never completes and so the stream never
 terminates.

 Try the following, and see if it helps.

 Merge[Int](2, eagerComplete = true)

 If my understanding is wrong please correct me :)

 Thanks,
 Vishnu.






 On Thursday, 4 February 2016 09:54:29 UTC-8, Giovanni Alberto
 Caporaletti wrote:
>
> Hi everyone
>
> I created a small example in which I pass the input elements directly
> to the output and also send them to a feedback loop that drops everything
> (using filter).
>
> What happens is that the input elements are emitted as expected but
> the materialization never completes.
> Am I doing something wrong? Is this supposed to happen? Shouldn't the
> feedback output of the broadcast complete when the input stream completes?
>
>
> Cheers
> G
>
> object Test extends App {
>   implicit val system = ActorSystem()
>   implicit val mat = ActorMaterializer()
>
>   val flow = Flow.fromGraph(GraphDSL.create() { implicit b =>
> import GraphDSL.Implicits._
>
> val dropEverything = b.add(Flow[Int].filter(_ => false))
> val input = b.add(Merge[Int](2))
> val bcast = b.add(Broadcast[Int](2))
>
> input ~> bcast
> input.in(1) <~ dropEverything <~ bcast.out(1)
>
> FlowShape(input.in(0), bcast.out(0))
>   })
>
>   val result = Source.single(42).via(flow).runWith(Sink.foreach(println))
>
>   try {
> // prints 42 but the stream doesn't terminate and the await timeouts
> println(Await.result(result, 5.seconds))
>   } finally {
> system.terminate()
>   }
> }
>
> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> >> Read

Re: [akka-user] [akka-http] Sink.head & Sink.last problem on processing responses

[Viktor Klang]

Hi, are you using the latest RC of Akka 2.4.2? (If not, please do)

That aside, please do not do
this: entity.dataBytes.runWith(Sink.head).map(x => new String(x.toArray))
// not OK

That String constructor should be banished, it uses the platform default
character encoding, so it may work on some deployments and for others not.
Also, creating a Byte-array from a ByteString allocates a new array (since
the array is mutable) also a character encoding needs to be used when
transcoding the bytes to a String.

Recommendation, use byteString.decodeString(encoding):

abstract defdecodeString(charset: String): String


Decodes this ByteString using a charset to produce a String.


On Fri, Feb 5, 2016 at 2:27 PM, Hao Ren  wrote:

> Hi,
>
> I am using akka http to feed kafka via kafka-rest-proxy.
>
> The client code is simple. It just makes post requests at a rate given.
>
> Here is the code processing the response:
>
> val http = Http()
> def postRequest(request: HttpRequest, index: Int): Future[String] = {
>   http.singleRequest(request) flatMap {
> case HttpResponse(StatusCodes.OK, _, entity, _) =>
>   entity.dataBytes.runWith(Sink.head).map(x => new String(x.toArray)) // 
> not OK
>   //entity.dataBytes.runWith(Sink.head).map(x => new String(x.toArray)) 
> // OK
> case HttpResponse(statusCode, _, entity, _) =>
>   entity.dataBytes.runWith(Sink.ignore)
>   Promise.failed(new 
> KafkaRestProxyException(statusCode.toString())).future
>   }
> }
>
>
> where the function `postRequest` is call a lot of times in a loop.
>
> When the message rate is low, everything is ok.
> However, when the rate is high, it will process several messages at first,
> and then akka http is stuck indefinitely.
> It happens only when `Sink.head` is used. If I replace it by `Sink.last`
> (or even Sink.ignore), everything is ok.
>
> It looks like back pressure is activated if `Sink.last` is not used to
> force consumption of entities of all the responses.
> What is strange is that the connexion stream has only element (one
> response) to retrieve. It should not make difference between `Sink.last`
> and `Sink.head`
>
> (jstack is in the end)
>
> Any help is highly appreciated !
>
> Hao
>
>
> 
>
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.72-b15 mixed mode):
>
> "Attach Listener" #34 daemon prio=9 os_prio=0 tid=0x7fd5e4001000
> nid=0x4add waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
>
> "DestroyJavaVM" #33 prio=5 os_prio=0 tid=0x7fd628014000 nid=0x49d1
> waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
>
> "ForkJoinPool-2-worker-7" #31 daemon prio=5 os_prio=0
> tid=0x7fd58c004800 nid=0x4a11 waiting on condition [0x7fd60c66d000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x000775603f20> (a
> scala.concurrent.forkjoin.ForkJoinPool)
> at
> scala.concurrent.forkjoin.ForkJoinPool.idleAwaitWork(ForkJoinPool.java:2135)
> at scala.concurrent.forkjoin.ForkJoinPool.scan(ForkJoinPool.java:2067)
> at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
> at
> scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
>
> "ForkJoinPool-2-worker-1" #30 daemon prio=5 os_prio=0
> tid=0x01a31800 nid=0x4a0f waiting on condition [0x7fd60c76e000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x000775603f20> (a
> scala.concurrent.forkjoin.ForkJoinPool)
> at scala.concurrent.forkjoin.ForkJoinPool.scan(ForkJoinPool.java:2075)
> at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
> at
> scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
>
> "default-akka.actor.default-dispatcher-14" #27 prio=5 os_prio=0
> tid=0x7fd5bc072800 nid=0x4a0c waiting on condition [0x7fd60cc71000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x0006c681ae68> (a
> akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinPool)
> at scala.concurrent.forkjoin.ForkJoinPool.scan(ForkJoinPool.java:2075)
> at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
> at
> scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
>
> "default-akka.actor.default-dispatcher-13" #26 prio=5 os_prio=0
> tid=0x7fd59c002800 nid=0x4a0b waiting on condition [0x7fd60cd72000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x0006c681ae68> (a
> akka.dispatch.ForkJoinExecutorConfigurator$AkkaFo

Re: [akka-user] Re: groupBy.viaAsync vs mapAsync

[Viktor Klang]

What does your tests show?

-- 
Cheers,
√
On Feb 5, 2016 4:24 PM, "Richard Rodseth"  wrote:

> In an effort to be more succinct :) Is this a true statement?
>
> "groupBy does not automatically introduce any *per-key* parallelism,
> unless followed by mapAsync"
>
> On Thu, Feb 4, 2016 at 3:05 PM, Richard Rodseth 
> wrote:
>
>> I guess I'm still a bit confused by parallelism in akka streams, but let
>> me describe what I have.
>>
>> Tenants have Sites which have Channels which have Intervals (start end
>> value)
>>
>> My root source is a stream of TenantSiteChannelInfo (obtained from a join
>> of channels with their sites and tenants)
>>
>> I am successfully writing files, one per channel-month arranged by tenant
>> and site, eg.
>>
>> /archive_.txt
>>
>> using a flow like this
>>
>>   def channelToBytesWritten(db: JdbcBackend.DatabaseDef, batchSize: Int,
>> requestedRange:InstantRange): Flow[TenantSiteChannelInfo,(String,Long),Unit]
>> = {
>>
>> val result = Flow[TenantSiteChannelInfo]
>>
>>   .via(Transformations.channelToChannelMonths(requestedRange)) //
>> uses flatMapConcat
>>
>>   .via(Transformations.channelMonthToChannelMonthIntervals(db,
>> batchSize)) // uses flatMapConcat
>>
>>   .via(Transformations.channelMonthIntervalToBytesWritten) // see
>> below
>>
>> result
>>
>>   }
>>
>> Transformations.channelMonthIntervalToBytesWritten does a
>> groupBy.prefixAndTail(1).mapAsync as discussed in a recent thread, where
>> the key is (year-month,channelid)
>>
>> The result is I see the files showing up in the Finder in parallel, which
>> is OK and fun to watch. The number of distinct keys is rather large but I
>> could presumably throttle the source channels if necessary to address that.
>>
>> But suppose I just/also wanted to process each *channel* (the very first
>> type of stream element) in parallel? Does inserting a
>> groupBy(_channelId).viaAsync at the beginning of this flow and merging
>> substreams at the end achieve that, or is running the latter half of the
>> flow inside mapAsync the only/best way?
>>
>> If the groupBy wouldn't achieve per-channel parallelism, is it fair to
>> say that groupBy only has utility if followed by some sort of "folding", as
>> in the word count example or the file writing above, or if the receiving
>> sink (shared by all substreams, an actor perhaps) can key off the same key
>> in some way.
>>
>> Thanks.
>>
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: groupBy.viaAsync vs mapAsync

[Viktor Klang]

I'm not irritated at all, I just meant that sometimes it is faster to try
than ask :)

-- 
Cheers,
√
On Feb 5, 2016 4:35 PM, "Richard Rodseth"  wrote:

> Point taken. Perhaps my questions irritate you, but they may help others,
> and the documentation.
>
> On Fri, Feb 5, 2016 at 7:28 AM, Viktor Klang 
> wrote:
>
>> What does your tests show?
>>
>> --
>> Cheers,
>> √
>> On Feb 5, 2016 4:24 PM, "Richard Rodseth"  wrote:
>>
>>> In an effort to be more succinct :) Is this a true statement?
>>>
>>> "groupBy does not automatically introduce any *per-key* parallelism,
>>> unless followed by mapAsync"
>>>
>>> On Thu, Feb 4, 2016 at 3:05 PM, Richard Rodseth 
>>> wrote:
>>>
>>>> I guess I'm still a bit confused by parallelism in akka streams, but
>>>> let me describe what I have.
>>>>
>>>> Tenants have Sites which have Channels which have Intervals (start end
>>>> value)
>>>>
>>>> My root source is a stream of TenantSiteChannelInfo (obtained from a
>>>> join of channels with their sites and tenants)
>>>>
>>>> I am successfully writing files, one per channel-month arranged by
>>>> tenant and site, eg.
>>>>
>>>> /archive_.txt
>>>>
>>>> using a flow like this
>>>>
>>>>   def channelToBytesWritten(db: JdbcBackend.DatabaseDef, batchSize:
>>>> Int, requestedRange:InstantRange): 
>>>> Flow[TenantSiteChannelInfo,(String,Long),Unit]
>>>> = {
>>>>
>>>> val result = Flow[TenantSiteChannelInfo]
>>>>
>>>>   .via(Transformations.channelToChannelMonths(requestedRange)) //
>>>> uses flatMapConcat
>>>>
>>>>   .via(Transformations.channelMonthToChannelMonthIntervals(db,
>>>> batchSize)) // uses flatMapConcat
>>>>
>>>>   .via(Transformations.channelMonthIntervalToBytesWritten) // see
>>>> below
>>>>
>>>> result
>>>>
>>>>   }
>>>>
>>>> Transformations.channelMonthIntervalToBytesWritten does a
>>>> groupBy.prefixAndTail(1).mapAsync as discussed in a recent thread, where
>>>> the key is (year-month,channelid)
>>>>
>>>> The result is I see the files showing up in the Finder in parallel,
>>>> which is OK and fun to watch. The number of distinct keys is rather large
>>>> but I could presumably throttle the source channels if necessary to address
>>>> that.
>>>>
>>>> But suppose I just/also wanted to process each *channel* (the very
>>>> first type of stream element) in parallel? Does inserting a
>>>> groupBy(_channelId).viaAsync at the beginning of this flow and merging
>>>> substreams at the end achieve that, or is running the latter half of the
>>>> flow inside mapAsync the only/best way?
>>>>
>>>> If the groupBy wouldn't achieve per-channel parallelism, is it fair to
>>>> say that groupBy only has utility if followed by some sort of "folding", as
>>>> in the word count example or the file writing above, or if the receiving
>>>> sink (shared by all substreams, an actor perhaps) can key off the same key
>>>> in some way.
>>>>
>>>> Thanks.
>>>>
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >>>>>>>>>> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+unsubscr...@googlegroups.com.
>>> To post to this group, send email to akka-user@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>>

Re: [akka-user] Re: How to keep a Source alive

[Viktor Klang]

Hi John!

I think I can help you, but I have some follow-on questions :)

On Sun, Feb 7, 2016 at 12:52 PM,  wrote:

> Hi Victor,
> I know you  love simple elegant code but
> I looked at unfoldAsync  and I don't see that it solves the usecase I have
> in mind.
>
> I'll try to explain why because I am not sure if I am overlooking
> something obvious?
>
> An external system writes events into a log table. Since this is a
> non-reactive-sql-database the consumer needs to poll the log table (for
> example every 2 seconds) for new events.
>

(Why) does it need to poll the log table if there is no demand for events?


>
>  To convert this scenario into a streaming source using unfoldAsync
>  I need to implement a polling loop inside the future so that
> Future.success gets  only called when new events are inserted in the log
> table.
>

This seems much like a technical aspect rather than a requirement.


>
> If I don't use polling the future would send 0 Events upstream and the
> stream would come to an end?
>

Events go downstream, or did I misunderstand something?


>
> That's why I like using instead of  unfoldAsync an Actor like JobManager
> .
> as an Source. Within the Actor I can be more fine grained and  use the
> scheduler to implement the polling logic.
>

Let's take a step back, what are the actual requirements?

1. You have a source of "events" and the only way you know if there are any
events, is if you ask for events
2. You want to consume events from this source
3. You only need to consume events from the source if there is demand from
"downstream"
4. Does the source of events ever end, and how do you know?
5. can you ask for a specified number of events or does polling imply
reading all available events?


>
> Many Greetings
> John
>
>
>
>
>
>
>
>
>
>
>
> Am Mittwoch, 3. Februar 2016 23:10:15 UTC+1 schrieb √:
>>
>>
>> http://doc.akka.io/api/akka-stream-and-http-experimental/2.0.3/?_ga=1.45749860.1579561034.1353497989#akka.stream.scaladsl.Source$
>>
>> On Wed, Feb 3, 2016 at 11:06 PM,  wrote:
>>
>>> where do I find unfold/unfoldAsync ? I looked at
>>> http://doc.akka.io/docs/akka-stream-and-http-experimental/2.0.3/stages-overview.html
>>> ?
>>> Many Greetings
>>> John
>>>
>>>
>>> Am Mittwoch, 3. Februar 2016 20:51:17 UTC+1 schrieb √:

 I don't see why you'd need to write a custom GraphStage for this.

 unfold/unfoldAsync paired with a buffer with an appropriate dropping
 policy should work, no?

 On Wed, Feb 3, 2016 at 8:47 PM, clca  wrote:

> Yes this is close to what I need to do.
> The code in the onPull method is something like
>
> val m = ReadFromService(...)
> if(m != null)
>push(out, m)
>
> in a traditional app reading would be done in a loop
>
> while(true) {
>   val m = ReadFromService(...)
> //do something with the new message
> }
>
> So I'll add a mechanism  in the Source to keep polling the external
> service.
>
> Thanks!
>
>
> On Wednesday, February 3, 2016 at 12:55:16 AM UTC-8,
> john@gmail.com wrote:
>>
>> I've done something similar.
>> I adapted this JobManager
>> .
>> When no data is available( for example when it recieves a Request(16)
>> Messag) it starts a" polling Actor" which polls an external Database for
>> more data.
>> Does this help?
>>
>> Am Mittwoch, 3. Februar 2016 08:33:16 UTC+1 schrieb clca:
>>>
>>> I searched through the topics but I could not find any example on
>>> how to pull from a Source in the case where data is coming in bursts. I
>>> built a customized Source that read from an external source. Data is 
>>> coming
>>> in bursts, the flow can stop for a while so I need to keep pulling the
>>> Source in such a way I can keep reading data (the actual read process is
>>> done in the old poll fashion). I guess I need something like a KeepAlive
>>> type of mechanism for the data stream.
>>>
>>> BTW: Fantastic job with Akka, Akka Stream & Akka HTTP!
>>>
>>> Thanks
>>> Claudio
>>>
>>>
>> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives:
> https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google
> Groups "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.

Re: [akka-user] Re: How to keep a Source alive

[Viktor Klang]

On Sun, Feb 7, 2016 at 2:17 PM,  wrote:

> Hi Victor,
> thank you for your reply and here are my remarks :
>
> Point 1. You have a source of "events" and the only way you know if there
> are any events, is if you ask for events
>
> exactly
>
> Point 2.You want to consume events from this source
>
> Yes
>
>  Point 3) You only need to consume events from the source if there is
> demand from "downstream"
>
> It is the other way round. The source logically pushes the events
> downstream.
> Ideally  as soon as theses Events arrive I would like them to be pushed
> downstream. So its more a push scenario.
> The source pushes as many Events as the downstream processes can handle.
> (But I have to limit myself for polling the database at a rate of 2-5
> seconds because of hardware reasons)
>

You only want to send data if the downstream can handle it, and the source
knows that by keeping track of downstream demand.


>
>  Point 4) Does the source of events ever end, and how do you know?
>
> No the source never ends. External Systems always insert new Event records
> into the database
>
>   Point 5. can you ask for a specified number of events or does polling
> imply reading all available events?
>
> No I can ask for a specified number of events.
>
> Here is a concrete business case:
> 1) External systems want Email Messages to be emailed to Users.
> 2) They insert Email Events (Records with email-address, content,
> user_id,etc) into a Email Table (log-table)
> 3)  Email-Send-Service sends these  Emails over the wire
> 4)  Acknowledge-Service logs the Email-Send Event and cleans up the Email
> Table (log-table).
>
> So I can set up a Stream: Email-Source -> Email-Send-Service -
> Acknowledge-Service .
>
> I am now considering two ways of doing it and are hoping for your advice
> (-:
> 1) create the following
> Email-Source  (select * from Email limit 1000)  -> Email-Send-Service
> -> Acknowledge-Service
> and materialize this stream every two seconds
>
> 2) Set up a custom source which polls forever
> Polling-Neverending-Email-Source  (select * from Email limit 1000
> every two seconds inside the Actor) -> Email-Send-Service  ->
> Acknowledge-Service
>

Sounds like you should be able to, construct your source as something like
this:

 +  + 

This means that the polling gets throttled, and the mapConcat is if you
read more than 1 event per poll and the buffer is there to make sure that
the demand that gets to the poller is > 1 to increase throughput.


>
>
> Background: I am building up with Akka Streams a inhouse toolkit which
> deals with many ESB typical processes.
> The above usecase profits not so much from throughput (actually the users
> could live with some delay) but more from
> reusing stream components and having a nice clear Flow DSL.
>
> Many Greetings
> John
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Am Sonntag, 7. Februar 2016 13:05:59 UTC+1 schrieb √:
>>
>> Hi John!
>>
>> I think I can help you, but I have some follow-on questions :)
>>
>> On Sun, Feb 7, 2016 at 12:52 PM,  wrote:
>>
>>> Hi Victor,
>>> I know you  love simple elegant code but
>>> I looked at unfoldAsync  and I don't see that it solves the usecase I
>>> have in mind.
>>>
>>> I'll try to explain why because I am not sure if I am overlooking
>>> something obvious?
>>>
>>> An external system writes events into a log table. Since this is a
>>> non-reactive-sql-database the consumer needs to poll the log table (for
>>> example every 2 seconds) for new events.
>>>
>>
>> (Why) does it need to poll the log table if there is no demand for events?
>>
>>
>>>
>>>  To convert this scenario into a streaming source using unfoldAsync
>>>  I need to implement a polling loop inside the future so that
>>> Future.success gets  only called when new events are inserted in the log
>>> table.
>>>
>>
>> This seems much like a technical aspect rather than a requirement.
>>
>>
>>>
>>> If I don't use polling the future would send 0 Events upstream and the
>>> stream would come to an end?
>>>
>>
>> Events go downstream, or did I misunderstand something?
>>
>>
>>>
>>> That's why I like using instead of  unfoldAsync an Actor like JobManager
>>> .
>>> as an Source. Within the Actor I can be more fine grained and  use the
>>> scheduler to implement the polling logic.
>>>
>>
>> Let's take a step back, what are the actual requirements?
>>
>> 1. You have a source of "events" and the only way you know if there are
>> any events, is if you ask for events
>> 2. You want to consume events from this source
>> 3. You only need to consume events from the source if there is demand
>> from "downstream"
>> 4. Does the source of events ever end, and how do you know?
>> 5. can you ask for a specified number of events or does polling imply
>> reading all available events?
>>
>>
>>>
>>> Many Greetings
>>> John
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Am Mittwoch, 3. Februar 2016 23:10:

Re: [akka-user] Re: How to keep a Source alive

[Viktor Klang]

If the Buffer has Backpressure as overflow strategy I don't see how it
decouples upstream from downstream.

On Mon, Feb 8, 2016 at 11:52 AM, Endre Varga 
wrote:

>
>
> On Sun, Feb 7, 2016 at 9:49 PM, Viktor Klang 
> wrote:
>
>>
>>
>> On Sun, Feb 7, 2016 at 2:17 PM,  wrote:
>>
>>> Hi Victor,
>>> thank you for your reply and here are my remarks :
>>>
>>> Point 1. You have a source of "events" and the only way you know if
>>> there are any events, is if you ask for events
>>>
>>> exactly
>>>
>>> Point 2.You want to consume events from this source
>>>
>>> Yes
>>>
>>>  Point 3) You only need to consume events from the source if there is
>>> demand from "downstream"
>>>
>>> It is the other way round. The source logically pushes the events
>>> downstream.
>>> Ideally  as soon as theses Events arrive I would like them to be pushed
>>> downstream. So its more a push scenario.
>>> The source pushes as many Events as the downstream processes can handle.
>>> (But I have to limit myself for polling the database at a rate of 2-5
>>> seconds because of hardware reasons)
>>>
>>
>> You only want to send data if the downstream can handle it, and the
>> source knows that by keeping track of downstream demand.
>>
>>
>>>
>>>  Point 4) Does the source of events ever end, and how do you know?
>>>
>>> No the source never ends. External Systems always insert new Event
>>> records into the database
>>>
>>>   Point 5. can you ask for a specified number of events or does polling
>>> imply reading all available events?
>>>
>>> No I can ask for a specified number of events.
>>>
>>> Here is a concrete business case:
>>> 1) External systems want Email Messages to be emailed to Users.
>>> 2) They insert Email Events (Records with email-address, content,
>>> user_id,etc) into a Email Table (log-table)
>>> 3)  Email-Send-Service sends these  Emails over the wire
>>> 4)  Acknowledge-Service logs the Email-Send Event and cleans up the
>>> Email Table (log-table).
>>>
>>> So I can set up a Stream: Email-Source -> Email-Send-Service -
>>> Acknowledge-Service .
>>>
>>> I am now considering two ways of doing it and are hoping for your advice
>>> (-:
>>> 1) create the following
>>> Email-Source  (select * from Email limit 1000)  ->
>>> Email-Send-Service  -> Acknowledge-Service
>>> and materialize this stream every two seconds
>>>
>>> 2) Set up a custom source which polls forever
>>> Polling-Neverending-Email-Source  (select * from Email limit 1000
>>> every two seconds inside the Actor) -> Email-Send-Service  ->
>>> Acknowledge-Service
>>>
>>
>> Sounds like you should be able to, construct your source as something
>> like this:
>>
>>  +  + 
>>
>> This means that the polling gets throttled, and the mapConcat is if you
>> read more than 1 event per poll and the buffer is there to make sure that
>> the demand that gets to the poller is > 1 to increase throughput.
>>
>
> On the other hand buffer detaches the upstream, so the poller will be
> called even when there is no downstream demand, causing it to return
> potentially stale data from the buffer if there are long pauses in
> downstream consumption. So this is a tradeoff, not necessarily a bad one,
> but one to be aware of.
>
> -Endre
>
>
>
>>
>>
>>>
>>>
>>> Background: I am building up with Akka Streams a inhouse toolkit which
>>> deals with many ESB typical processes.
>>> The above usecase profits not so much from throughput (actually the
>>> users could live with some delay) but more from
>>> reusing stream components and having a nice clear Flow DSL.
>>>
>>> Many Greetings
>>> John
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Am Sonntag, 7. Februar 2016 13:05:59 UTC+1 schrieb √:
>>>>
>>>> Hi John!
>>>>
>>>> I think I can help you, but I have some follow-on questions :)
>>>>
>>>> On Sun, Feb 7, 2016 at 12:52 PM,  wrote:
>>>>
>>>>> Hi Victor,
>>>>> I know you  love simple elegant code but
&

Re: [akka-user] Re: How to keep a Source alive

[Viktor Klang]

What? How would anything be dropped if buffer has Backpressure as
OverflowStrategy?

On Mon, Feb 8, 2016 at 11:56 AM, Endre Varga 
wrote:

>
>
> On Mon, Feb 8, 2016 at 11:53 AM, Viktor Klang 
> wrote:
>
>> If the Buffer has Backpressure as overflow strategy I don't see how it
>> decouples upstream from downstream.
>>
>
> That is a dangerous move though, since you put the buffer *after* the
> mapConcat, so this means that dropping will be independent of the batch
> boundaries. I.e. the buffer might hold 1 full batch and the half, dopping
> the other half. I think in this case it is better to use a more flexible
> tool there and "batcher" seems to be the right one (it is a conflate-like
> op with capacity, so can implement "smart" buffers). Or, mapConcat should
> not be used here. I guess it depends on the use case.
>
> -Endre
>
>
>>
>> On Mon, Feb 8, 2016 at 11:52 AM, Endre Varga 
>> wrote:
>>
>>>
>>>
>>> On Sun, Feb 7, 2016 at 9:49 PM, Viktor Klang 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sun, Feb 7, 2016 at 2:17 PM,  wrote:
>>>>
>>>>> Hi Victor,
>>>>> thank you for your reply and here are my remarks :
>>>>>
>>>>> Point 1. You have a source of "events" and the only way you know if
>>>>> there are any events, is if you ask for events
>>>>>
>>>>> exactly
>>>>>
>>>>> Point 2.You want to consume events from this source
>>>>>
>>>>> Yes
>>>>>
>>>>>  Point 3) You only need to consume events from the source if there is
>>>>> demand from "downstream"
>>>>>
>>>>> It is the other way round. The source logically pushes the events
>>>>> downstream.
>>>>> Ideally  as soon as theses Events arrive I would like them to be
>>>>> pushed downstream. So its more a push scenario.
>>>>> The source pushes as many Events as the downstream processes can
>>>>> handle.
>>>>> (But I have to limit myself for polling the database at a rate of 2-5
>>>>> seconds because of hardware reasons)
>>>>>
>>>>
>>>> You only want to send data if the downstream can handle it, and the
>>>> source knows that by keeping track of downstream demand.
>>>>
>>>>
>>>>>
>>>>>  Point 4) Does the source of events ever end, and how do you know?
>>>>>
>>>>> No the source never ends. External Systems always insert new Event
>>>>> records into the database
>>>>>
>>>>>   Point 5. can you ask for a specified number of events or does
>>>>> polling imply reading all available events?
>>>>>
>>>>> No I can ask for a specified number of events.
>>>>>
>>>>> Here is a concrete business case:
>>>>> 1) External systems want Email Messages to be emailed to Users.
>>>>> 2) They insert Email Events (Records with email-address, content,
>>>>> user_id,etc) into a Email Table (log-table)
>>>>> 3)  Email-Send-Service sends these  Emails over the wire
>>>>> 4)  Acknowledge-Service logs the Email-Send Event and cleans up the
>>>>> Email Table (log-table).
>>>>>
>>>>> So I can set up a Stream: Email-Source -> Email-Send-Service -
>>>>> Acknowledge-Service .
>>>>>
>>>>> I am now considering two ways of doing it and are hoping for your
>>>>> advice (-:
>>>>> 1) create the following
>>>>> Email-Source  (select * from Email limit 1000)  ->
>>>>> Email-Send-Service  -> Acknowledge-Service
>>>>> and materialize this stream every two seconds
>>>>>
>>>>> 2) Set up a custom source which polls forever
>>>>> Polling-Neverending-Email-Source  (select * from Email limit 1000
>>>>> every two seconds inside the Actor) -> Email-Send-Service  ->
>>>>> Acknowledge-Service
>>>>>
>>>>
>>>> Sounds like you should be able to, construct your source as something
>>>> like this:
>>>>
>>>>  +  + 
>>>>
>>>> This means that the polling gets throttled, and the mapConcat is if you
>>>> read more than 1 event per poll and the buffer is there to make sure that
>&g

Re: [akka-user] Re: How to keep a Source alive

[Viktor Klang]

How is that a problem? OP only wanted to make sure that the external system
wasn't polled too often.

On Mon, Feb 8, 2016 at 12:20 PM, Endre Varga 
wrote:

> Ah, you meant Backpressure. But then what I originally said is true. Just
> think about it:
>
>  - buffer requests
>  - buffer is enough to contain the next batch emitted by mapConcat
>  - buffer hence stores some result
>  - downstream now asks for next batch, but 3 hours later
>  - emitted result is now 3 hours old
>
> -Endre
>
> On Mon, Feb 8, 2016 at 12:05 PM, Viktor Klang 
> wrote:
>
>> What? How would anything be dropped if buffer has Backpressure as
>> OverflowStrategy?
>>
>> On Mon, Feb 8, 2016 at 11:56 AM, Endre Varga 
>> wrote:
>>
>>>
>>>
>>> On Mon, Feb 8, 2016 at 11:53 AM, Viktor Klang 
>>> wrote:
>>>
>>>> If the Buffer has Backpressure as overflow strategy I don't see how it
>>>> decouples upstream from downstream.
>>>>
>>>
>>> That is a dangerous move though, since you put the buffer *after* the
>>> mapConcat, so this means that dropping will be independent of the batch
>>> boundaries. I.e. the buffer might hold 1 full batch and the half, dopping
>>> the other half. I think in this case it is better to use a more flexible
>>> tool there and "batcher" seems to be the right one (it is a conflate-like
>>> op with capacity, so can implement "smart" buffers). Or, mapConcat should
>>> not be used here. I guess it depends on the use case.
>>>
>>> -Endre
>>>
>>>
>>>>
>>>> On Mon, Feb 8, 2016 at 11:52 AM, Endre Varga 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, Feb 7, 2016 at 9:49 PM, Viktor Klang 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Feb 7, 2016 at 2:17 PM,  wrote:
>>>>>>
>>>>>>> Hi Victor,
>>>>>>> thank you for your reply and here are my remarks :
>>>>>>>
>>>>>>> Point 1. You have a source of "events" and the only way you know if
>>>>>>> there are any events, is if you ask for events
>>>>>>>
>>>>>>> exactly
>>>>>>>
>>>>>>> Point 2.You want to consume events from this source
>>>>>>>
>>>>>>> Yes
>>>>>>>
>>>>>>>  Point 3) You only need to consume events from the source if there
>>>>>>> is demand from "downstream"
>>>>>>>
>>>>>>> It is the other way round. The source logically pushes the events
>>>>>>> downstream.
>>>>>>> Ideally  as soon as theses Events arrive I would like them to be
>>>>>>> pushed downstream. So its more a push scenario.
>>>>>>> The source pushes as many Events as the downstream processes can
>>>>>>> handle.
>>>>>>> (But I have to limit myself for polling the database at a rate of
>>>>>>> 2-5 seconds because of hardware reasons)
>>>>>>>
>>>>>>
>>>>>> You only want to send data if the downstream can handle it, and the
>>>>>> source knows that by keeping track of downstream demand.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>  Point 4) Does the source of events ever end, and how do you know?
>>>>>>>
>>>>>>> No the source never ends. External Systems always insert new Event
>>>>>>> records into the database
>>>>>>>
>>>>>>>   Point 5. can you ask for a specified number of events or does
>>>>>>> polling imply reading all available events?
>>>>>>>
>>>>>>> No I can ask for a specified number of events.
>>>>>>>
>>>>>>> Here is a concrete business case:
>>>>>>> 1) External systems want Email Messages to be emailed to Users.
>>>>>>> 2) They insert Email Events (Records with email-address, content,
>>>>>>> user_id,etc) into a Email Table (log-table)
>>>>>>> 3)  Email-Send-Service sends these  Emails over the wire
>>>>>>> 4)  Acknowledge-Service logs the Email-Send Event and cleans up the
>>>>>&

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

[Viktor Klang]

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,
>
> 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 materialize to a future?
>
> Thanks!
> Kaspar
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

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

[Viktor Klang]

They will fail the stage if they throw

-- 
Cheers,
√
On Feb 12, 2016 8:54 AM, "hbf"  wrote:

> 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/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka streams file compression

[Viktor Klang]

(Or add support for compression!)

On Tue, Feb 16, 2016 at 2:13 PM, Konrad Malawski  wrote:

> Hi Richard,
> Not that I'm aware of.
>
> You can ping the library maintainer to upgrade to 2.4.2 (we're releasing
> that today) though :)
>
> On Tue, Feb 16, 2016 at 1:45 AM, Richard Rodseth 
> wrote:
>
>> I just had the rather gratifying experience of adding Snappy compression
>> using snappy-flows with
>>
>> .via(SnappyFlows.compress)
>>
>> For comparision purposes, and while I wait for snappy-flows to be updated
>> to 2.4.2, is there an equivalent built-in to akka-streams for GZip or other
>> compression algorithms ?
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Feb 9, 2016 at 2:03 PM, Richard Rodseth 
>> wrote:
>>
>>> I'm writing to files and reading from them using FileIO.fromFile and
>>> toFile.
>>>
>>> Looking to add compression of the files.
>>>
>>> This looks promising:
>>> https://github.com/maciej/snappy-flows
>>>
>>> The compression is expressed as a Flow[ByteString,ByteString,Unit]
>>>
>>> Are there other examples or documentation I should be looking at or is
>>> snappy-flows the way to go?
>>>
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Cheers,
> Konrad 'ktoso' Malawski
> Akka  @ Typesafe 
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka streams file compression

[Viktor Klang]

No, it was encouragement for the OP :)

On Tue, Feb 16, 2016 at 2:16 PM, Endre Varga 
wrote:

> Planned. Had not time so far :)
>
> On Tue, Feb 16, 2016 at 2:15 PM, Viktor Klang 
> wrote:
>
>> (Or add support for compression!)
>>
>> On Tue, Feb 16, 2016 at 2:13 PM, Konrad Malawski 
>> wrote:
>>
>>> Hi Richard,
>>> Not that I'm aware of.
>>>
>>> You can ping the library maintainer to upgrade to 2.4.2 (we're releasing
>>> that today) though :)
>>>
>>> On Tue, Feb 16, 2016 at 1:45 AM, Richard Rodseth 
>>> wrote:
>>>
>>>> I just had the rather gratifying experience of adding Snappy
>>>> compression using snappy-flows with
>>>>
>>>> .via(SnappyFlows.compress)
>>>>
>>>> For comparision purposes, and while I wait for snappy-flows to be
>>>> updated to 2.4.2, is there an equivalent built-in to akka-streams for GZip
>>>> or other compression algorithms ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Feb 9, 2016 at 2:03 PM, Richard Rodseth 
>>>> wrote:
>>>>
>>>>> I'm writing to files and reading from them using FileIO.fromFile and
>>>>> toFile.
>>>>>
>>>>> Looking to add compression of the files.
>>>>>
>>>>> This looks promising:
>>>>> https://github.com/maciej/snappy-flows
>>>>>
>>>>> The compression is expressed as a Flow[ByteString,ByteString,Unit]
>>>>>
>>>>> Are there other examples or documentation I should be looking at or is
>>>>> snappy-flows the way to go?
>>>>>
>>>>
>>>> --
>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>> >>>>>>>>>> Check the FAQ:
>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>> >>>>>>>>>> Search the archives:
>>>> https://groups.google.com/group/akka-user
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Akka User List" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to akka-user+unsubscr...@googlegroups.com.
>>>> To post to this group, send email to akka-user@googlegroups.com.
>>>> Visit this group at https://groups.google.com/group/akka-user.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Konrad 'ktoso' Malawski
>>> Akka <http://akka.io/> @ Typesafe <http://typesafe.com/>
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >>>>>>>>>> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+unsubscr...@googlegroups.com.
>>> To post to this group, send email to akka-user@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka streams file compression

[Viktor Klang]

Perhaps include a link to it here for someone to perhaps do just that? :-)

On Tue, Feb 16, 2016 at 2:36 PM, Endre Varga 
wrote:

> We have one actually hidden in HTTP, it just waits for someone to migrate
> it out :)
>
> On Tue, Feb 16, 2016 at 2:25 PM, Viktor Klang 
> wrote:
>
>> No, it was encouragement for the OP :)
>>
>> On Tue, Feb 16, 2016 at 2:16 PM, Endre Varga 
>> wrote:
>>
>>> Planned. Had not time so far :)
>>>
>>> On Tue, Feb 16, 2016 at 2:15 PM, Viktor Klang 
>>> wrote:
>>>
>>>> (Or add support for compression!)
>>>>
>>>> On Tue, Feb 16, 2016 at 2:13 PM, Konrad Malawski 
>>>> wrote:
>>>>
>>>>> Hi Richard,
>>>>> Not that I'm aware of.
>>>>>
>>>>> You can ping the library maintainer to upgrade to 2.4.2 (we're
>>>>> releasing that today) though :)
>>>>>
>>>>> On Tue, Feb 16, 2016 at 1:45 AM, Richard Rodseth 
>>>>> wrote:
>>>>>
>>>>>> I just had the rather gratifying experience of adding Snappy
>>>>>> compression using snappy-flows with
>>>>>>
>>>>>> .via(SnappyFlows.compress)
>>>>>>
>>>>>> For comparision purposes, and while I wait for snappy-flows to be
>>>>>> updated to 2.4.2, is there an equivalent built-in to akka-streams for 
>>>>>> GZip
>>>>>> or other compression algorithms ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Feb 9, 2016 at 2:03 PM, Richard Rodseth 
>>>>>> wrote:
>>>>>>
>>>>>>> I'm writing to files and reading from them using FileIO.fromFile and
>>>>>>> toFile.
>>>>>>>
>>>>>>> Looking to add compression of the files.
>>>>>>>
>>>>>>> This looks promising:
>>>>>>> https://github.com/maciej/snappy-flows
>>>>>>>
>>>>>>> The compression is expressed as a Flow[ByteString,ByteString,Unit]
>>>>>>>
>>>>>>> Are there other examples or documentation I should be looking at or
>>>>>>> is snappy-flows the way to go?
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>> >>>>>>>>>> Check the FAQ:
>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>> >>>>>>>>>> Search the archives:
>>>>>> https://groups.google.com/group/akka-user
>>>>>> ---
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "Akka User List" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to akka-user+unsubscr...@googlegroups.com.
>>>>>> To post to this group, send email to akka-user@googlegroups.com.
>>>>>> Visit this group at https://groups.google.com/group/akka-user.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Konrad 'ktoso' Malawski
>>>>> Akka <http://akka.io/> @ Typesafe <http://typesafe.com/>
>>>>>
>>>>> --
>>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>> >>>>>>>>>> Check the FAQ:
>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>> >>>>>>>>>> Search the archives:
>>>>> https://groups.google.com/group/akka-user
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Akka User List" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to akka-user+unsubscr...@googlegroups.com.
>>>>> To post to this group, send email to akka-user@googlegroups.com.
>>>>> Visit this group a

Re: [akka-user] Re: Akka dispatchers are not reused instead new dispatchers are created overtime

[Viktor Klang]

Wow, you have 500 CPU cores on your machine?

-- 
Cheers,
√
On Feb 16, 2016 5:01 PM, "Hareesh Jagannathan"  wrote:

> Thanks for responding quickly. Attaching a screeshot form visual Vm. As
> you can see there are more than 700 dispatcher for one my system.
>
> My design is as below.
>
>1. The system is created once when application starts.
>2. Many DAG/workflow which is basically a pipeline of actor/routers
>are create when a job is submitted.
>3. when job is done the actors/routers of this pipeline is poison
>pilled. Sytem is never sutdown.
>
>  Below is config for this system
>
> worker {
>akka {
>   actor {
>  default-dispatcher {
> fork-join-executor {
> parallelism-factor = 48.0
> parallelism-max = 512
>  }
>  }
>   }
>}
>
>bestselling-cache-timeout = 12
>
>pool-size {
>   bestbuy {
>   full {
>  skusFromPageFetcher = 10
> skuTransformer = 120
> solrXmlPublisher = 70
> skuXmlPersistor = 60
>   }
>   reindex {
> solrAllXmlFetcher = 50
> solrXmlPublisher = 250
>   }
>   sku_refresh {
>  skuIdListFetcher = 10
>  skuTransformer = 120
>  postSolrXmlFilter = 90
>  solrXmlPublisher = 20
>  skuXmlPersistor = 20
>   }
>   delta {
>  skuTransformer = 30
>  solrXmlPublisher = 20
>  skuXmlPersistor = 20
>   }
>   autocomplete_full {
>  suggestionFetcher = 10
>  suggestionToSolrDocTransformer = 10
>  suggestionPublisher = 20
>  suggestionSolrDocPersistor = 10
>   }
>   autocomplete_delta {
>  suggestionFetcher = 10
>  suggestionToSolrDocTransformer = 10
>  suggestionPublisher = 20
>  suggestionSolrDocPersistor = 10
>   }
>   autocomplete_reindex {
>  suggestionFetcher = 10
>  suggestionPublisher = 20
>   }
>   }
>   pacsales {
>  full {
>  skusFromPageFetcher = 3
>  skuTransformer = 20
>  solrXmlPublisher = 10
>  skuXmlPersistor = 10
>   }
>   reindex {
> solrAllXmlFetcher = 5
> solrXmlPublisher = 30
>   }
>   }
>}
> }
>
>
>
>
>
>
> On Tuesday, February 16, 2016 at 9:33:17 AM UTC-6, Hareesh Jagannathan
> wrote:
>>
>> Akka application spins a lot of new dispatchers overtime instead of
>> reusing . The old dispatchers are going back to waiting state and never
>> been reused or terminated.
>>
>> We use akka's default dispatcher with fork-join executors. we do override
>> the default parallelism parameter between our actors based on actors
>> purpose.
>>
>> Is there a configuration that we are missing that causing this issue?
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka dispatchers are not reused instead new dispatchers are created overtime

[Viktor Klang]

If you don't do any blocking then your max should be the number of cores
you have and the factor about 0.6-0.7

-- 
Cheers,
√
On Feb 16, 2016 5:17 PM, "Hareesh Jagannathan"  wrote:

> See thats my problem.  All i have is 8core CPU (3 nodes) so basically 24
> cores.
>
>  I understood the below form documentation and blogs.
>
> Max*factor is most number of threads i can have.
> Min*factor in minimum number of threads i can have.
>
> So what exactly would you recommend. also why is that i am able to see
> only dispatchers and not threads in visual Vm.
>
> On Tuesday, February 16, 2016 at 9:33:17 AM UTC-6, Hareesh Jagannathan
> wrote:
>>
>> Akka application spins a lot of new dispatchers overtime instead of
>> reusing . The old dispatchers are going back to waiting state and never
>> been reused or terminated.
>>
>> We use akka's default dispatcher with fork-join executors. we do override
>> the default parallelism parameter between our actors based on actors
>> purpose.
>>
>> Is there a configuration that we are missing that causing this issue?
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka dispatchers are not reused instead new dispatchers are created overtime

[Viktor Klang]

No, I'd use a dedicated dispatcher for the routees which do IO, use
ThreadPoolExecutor.

-- 
Cheers,
√
On Feb 16, 2016 5:24 PM, "Hareesh Jagannathan"  wrote:

>
> I do have blocking file-io in one of the router of the pipeline.
>
> Should i used Pinned dispatcher for those and go ahead with what you
> suggested for non blocking actors?
>
> On Tuesday, February 16, 2016 at 9:33:17 AM UTC-6, Hareesh Jagannathan
> wrote:
>>
>> Akka application spins a lot of new dispatchers overtime instead of
>> reusing . The old dispatchers are going back to waiting state and never
>> been reused or terminated.
>>
>> We use akka's default dispatcher with fork-join executors. we do override
>> the default parallelism parameter between our actors based on actors
>> purpose.
>>
>> Is there a configuration that we are missing that causing this issue?
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Message ordering for newly instantiated actors

[Viktor Klang]

Hi James,

1) Message sends are not guaranteed to be delivered (i.e. at-most-once)
2) B could die/exit before it gets the message from C
3) C could die/exit before it gets the message from A

That aside, if those things do not happen, it should be fine.

On Tue, Feb 16, 2016 at 9:27 PM, James P  wrote:

> Hi folks,
>
> Good day. I'm fairly new to Akka so I just wanted to ask the community a
> quick question.
>
> Consider the following scenario:
>
> 1) Actor A creates Actor B
> 2) Actor A sends a message to Actor C telling it to perform a computation
> and send results to Actor B
> 3) Actor C sends a message to Actor B
>
> My question is, is it guaranteed that Actor B will receive the message
> from Actor C? Or will there exist a potential race condition wherein Actor
> B might not be fully instantiated yet by the time Actor C sends the message
> destined for Actor B?
>
> Any help would be much appreciated.
>
> Thanks and have a great day.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [akka-stream] Difference between Source[Future[T]] .mapAsync(n)(f => f) and .flatMapConcat(f => Source.fromFuture(f))?

[Viktor Klang]

If I were you, I'd use parallelism 1, and if that ever became a problem,
I'd revisit that choice.

Focus on the business value and tune when you have something which works :)

On Wed, Feb 17, 2016 at 11:49 AM, Alexey Shuksto  wrote:

> Hello there,
>
> I have `Source[Future[T]]` which I need to transform to `Source[T]`
> somehow.
>
> Obvious choice would be to use `FlowOps.mapAsync(parallelism)(...)` but
> the problem is -- I'm not quite sure how to determine 'right' `parallelism`
> value -- basically I need mapAsync to produce as many futures, as requested
> by downstream.
>
> Recently I found `FlowOps.flatMapConcat(...)` method, and something along
> the `Flow[Future[T]].flatMapConcat(f => Source.fromFuture(f))` looks very
> similar to mapAsync but without parallelism guessing.
>
> Could anyone tell me is there any significant differences between them?
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

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

[Viktor Klang]

Or even better, anyone could do that :)

On Thu, Feb 18, 2016 at 10:46 AM, Endre Varga 
wrote:

> We can make it public again once it has been properly tested, documented
> etc. Until then, I think the workaround is to just copy the source and
> include it directly in your project.
>
> -Endre
>
> On Thu, Feb 18, 2016 at 10:07 AM, Konrad Malawski <
> konrad.malaw...@typesafe.com> wrote:
>
>> Spoke too soon about snappy-flows.
>> ByteStringParser seems to have moved or disappeared between RC-3 and
>> final. I'll ping the author.
>>
>> Caused by: java.lang.ClassNotFoundException:
>> akka.stream.io.ByteStringParser
>>
>> at java.net.URLClassLoader.findClass(URLClassLoader.java:381
>>
>>
>> It's rather weird if you've been using the Parser, it's internal API and
>> now moved to make that explicit:
>> akka.stream.impl.io.ByteStringParser (as well as being private[akka]).
>>
>>
>> -- Konrad
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

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

[Viktor Klang]

Hi Tom,

It's "akka-http-testkit" for 2.4.2 proper. See:
http://akka.io/news/2016/02/17/akka-2.4.2-released.html

Does that help?

On Thu, Feb 18, 2016 at 8:10 PM, Tom Lanning  wrote:

> Will "akka-http-testkit-experimental" be updated from "2.4.2-RC3" to
> "2.4.2"?
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Can I Pause some Flow In the the akka-stream?

[Viktor Klang]

Depends on what kind of semantics you're looking for: immediate pause,
controlled rate of inputs, or other?

On Mon, Feb 22, 2016 at 8:56 AM, Tal Pressman  wrote:

> I don't know of any way to do it out of the box, but you can create your
> own custom GraphStage that handles the pause/resume logic, and when it's
> paused doesn't push/pull.
>
>
> On Sunday, February 21, 2016 at 4:19:54 PM UTC+2, 代小飞 wrote:
>>
>> I have know about we can build flow graph use the sink ,source,flow.then
>> materialize this blue picture then run;
>> But when the progress of running. we can not control any of the flows;for
>> example some times I want to stop or pause the flow. how can i do?
>> thanks
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Can I Pause some Flow In the the akka-stream?

[Viktor Klang]

+1 for valve :-)

-- 
Cheers,
√
On Feb 22, 2016 11:33 AM, "Akka Team"  wrote:

> Actually, a controllable version of .throttle called something like .valve
> is not a bad idea. Contributions are welcome :)
>
> -Endre
>
> On Mon, Feb 22, 2016 at 9:53 AM, Viktor Klang 
> wrote:
>
>> Depends on what kind of semantics you're looking for: immediate pause,
>> controlled rate of inputs, or other?
>>
>> On Mon, Feb 22, 2016 at 8:56 AM, Tal Pressman  wrote:
>>
>>> I don't know of any way to do it out of the box, but you can create your
>>> own custom GraphStage that handles the pause/resume logic, and when it's
>>> paused doesn't push/pull.
>>>
>>>
>>> On Sunday, February 21, 2016 at 4:19:54 PM UTC+2, 代小飞 wrote:
>>>>
>>>> I have know about we can build flow graph use the sink
>>>> ,source,flow.then materialize this blue picture then run;
>>>> But when the progress of running. we can not control any of the
>>>> flows;for example some times I want to stop or pause the flow. how can i 
>>>> do?
>>>> thanks
>>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >>>>>>>>>> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+unsubscr...@googlegroups.com.
>>> To post to this group, send email to akka-user@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Akka Team
> Typesafe - Reactive apps on the JVM
> Blog: letitcrash.com
> Twitter: @akkateam
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: [akka-stream-2.0.3] how to force terminate a stream?

[Viktor Klang]

Haven't checked the sources (no pun intended), but how about prepending
your file sink with a stage which fails the stream if complete is signalled
without any elements having been signalled prior?

-- 
Cheers,
√
On Feb 25, 2016 2:03 PM, "Rafał Krzewski"  wrote:

> You can plug in an intermediate graph stage that allows cancelling
> upstream flow + completing downstream flow asynchronously.
>
>
> https://github.com/rkrzewski/akka-cluster-etcd/blob/master/etcd-client/src/main/scala/pl/caltha/akka/streams/FlowBreaker.scala
>
> Cheers,
> Rafał
>
> W dniu środa, 24 lutego 2016 21:23:02 UTC+1 użytkownik Ramin Alidousti
> napisał:
>>
>> Hi,
>>
>> I'm new to akka-stream. I have a bidiflow that has been materialized. Now
>> in certain cases I need to terminate the stream on demand and maybe
>> recreate it later. The way I'm doing that now is to call terminate() on the
>> implicit system. But I was wondering if there was a more appropriate way of
>> "stopping/terminating" the flow since the call to terminate() is too
>> intrusive as the system is also serving other actor related functionalities.
>>
>> Best,
>> Ramin
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: [akka-stream-2.0.3] how to force terminate a stream?

[Viktor Klang]

Gah, that reply was to another thread.

-- 
Cheers,
√
On Feb 25, 2016 2:16 PM, "Viktor Klang"  wrote:

> Haven't checked the sources (no pun intended), but how about prepending
> your file sink with a stage which fails the stream if complete is signalled
> without any elements having been signalled prior?
>
> --
> Cheers,
> √
> On Feb 25, 2016 2:03 PM, "Rafał Krzewski" 
> wrote:
>
>> You can plug in an intermediate graph stage that allows cancelling
>> upstream flow + completing downstream flow asynchronously.
>>
>>
>> https://github.com/rkrzewski/akka-cluster-etcd/blob/master/etcd-client/src/main/scala/pl/caltha/akka/streams/FlowBreaker.scala
>>
>> Cheers,
>> Rafał
>>
>> W dniu środa, 24 lutego 2016 21:23:02 UTC+1 użytkownik Ramin Alidousti
>> napisał:
>>>
>>> Hi,
>>>
>>> I'm new to akka-stream. I have a bidiflow that has been materialized.
>>> Now in certain cases I need to terminate the stream on demand and maybe
>>> recreate it later. The way I'm doing that now is to call terminate() on the
>>> implicit system. But I was wondering if there was a more appropriate way of
>>> "stopping/terminating" the flow since the call to terminate() is too
>>> intrusive as the system is also serving other actor related functionalities.
>>>
>>> Best,
>>> Ramin
>>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Ensure that Soure[A] is not empty

[Viktor Klang]

Haven't checked the sources (no pun intended), but how about prepending
your file sink with a stage which fails the stream if complete is signalled
without any elements having been signalled prior?

-- 
Cheers,
√
On Feb 25, 2016 1:12 PM, "Kyrylo Stokoz"  wrote:

> Hi All,
>
> I would like to ensure that provided Source is not empty, is there any way
> to validate this?
>
> Use case: I have a function that accept source and connects it to file
> sink, if source is empty empty files get created, which i would like to
> avoid.
>
> Regards,
> Kyrylo
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] flexible path router

[Viktor Klang]

Actors can process millions of messages per second. What are your
requirements?

-- 
Cheers,
√
On Feb 29, 2016 2:05 PM, "Henry Story"  wrote:

> Hi,
>
>I am writing an Http Server where each resource on the file system is
> the responsibility of an actor.
> To keep it simple, there are at least two types of actors: one responsible
> for directories and one responsible
> for files. Directory actors will be actors with children and files will be
> actors without.
>
> Now clearly we don't really want to load all actors for the whole file
> system in one go, as it could be huge.
> So I'd like to have actors appear as they are requested.
>
> The way I was thinking of going about it is creating a Router that would
> take a RoutingLogic which would have
> a contructor  taking a root  ActorContext (or something) and try to
> follow the HttpRequest's Akka.Uri path segment
> by  segment until it finds either a remote ActorRef or one that does not
> exist. Then the Router could send the HttpRequest to that actor, and it
> could check out different things:
>
>
>- if the request is a GET on a resource which is available but not
>created, create that actor and send it the HttpRequest.
>- if the request is a PUT on a resource that does not exist, check if
>the author of the GET has access rights to create it, and if so make
>the actor for it.
>
>   ...
>
> But I can't find an efficient way of walking through the contexts, though
> as I look at the akka code it seems to be available, just all of it is
> private. Would it make sense to have a method context.findFirst(path)
> that would do this? Or have I missed an obvious api?
>
> Of course I could just send messages to the root actor, but that would be
> quite inefficient I think in the longer term, as the root Actor would
> receive every single message sent its way.
>
> Henry
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Does each ActorMaterializer need its own ActorSystem?

[Viktor Klang]

I don't understand the question. And looking at the code I don't think it
would compile.

On Wed, Mar 2, 2016 at 10:15 AM,  wrote:

> system = ActorSystem.create();
>
> new Array[]{"a","b"}.stream()
>   .forEach {
> final Materializer m = 
> ActorMaterializer.create(ActorMaterializerSettings.create(system).withSupervisionStrategy(decider),
>  system);
> pipeLine.to(Sink.foreach(..).run(m);
> }
> }
>
>
> Now only the last pipeline in the loop works?
> So I am concluding that each
>
> Materializer needs its own actorSystem
>
>
>
> Am Mittwoch, 2. März 2016 10:12:23 UTC+1 schrieb john@gmail.com:
>>
>> I have the following code
>>
>>
>
>> new Array[]{"a","b"}.stream()
>>   .forEach {
>> }
>> }
>>
>>
>>
>>
>> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Does each ActorMaterializer need its own ActorSystem?

[Viktor Klang]

ActorMaterializer needs ActorContext and a Materializer can be used for
many materializations.

-- 
Cheers,
√
On Mar 2, 2016 10:22,  wrote:

> sorry I hitted the send button too early. its just meant as pesudo code.
> I was wondering if each
>
>  ActorMaterializer needs its own ActorSystem ? Or can one ActorSystem be used 
> for many  Materializers?
>
>
> Am Mittwoch, 2. März 2016 10:17:32 UTC+1 schrieb √:
>>
>> I don't understand the question. And looking at the code I don't think it
>> would compile.
>>
>> On Wed, Mar 2, 2016 at 10:15 AM,  wrote:
>>
>>> system = ActorSystem.create();
>>>
>>> new Array[]{"a","b"}.stream()
>>>   .forEach {
>>> final Materializer m = 
>>> ActorMaterializer.create(ActorMaterializerSettings.create(system).withSupervisionStrategy(decider),
>>>  system);
>>> pipeLine.to(Sink.foreach(..).run(m);
>>> }
>>> }
>>>
>>>
>>> Now only the last pipeline in the loop works?
>>> So I am concluding that each
>>>
>>> Materializer needs its own actorSystem
>>>
>>>
>>>
>>> Am Mittwoch, 2. März 2016 10:12:23 UTC+1 schrieb john@gmail.com:

 I have the following code


>>>
 new Array[]{"a","b"}.stream()
   .forEach {
 }
 }




 --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Issue with Smallest Mailbox router pool introduced in akka 2.4.2

[Viktor Klang]

Could be related to: https://github.com/akka/akka/issues/19216

On Fri, Mar 4, 2016 at 1:26 PM, Chris Baxter  wrote:

> I have noticed a strange issue after we upgraded to akka 2.4.2 that
> appears sporadically but once it rears its ugly head it basically causes
> the server to consume a ton of CPU and we have to restart.  This issue
> appears to be with the smallest mailbox pool router.  It gets hung up in
> peekNode in AbstractNodeQueue, in that do/while loop:
>
> protected final Node peekNode() {
>
> final Node tail = ((Node)Unsafe.instance.getObjectVolatile(
> this, tailOffset));
>
> Node next = tail.next();
>
> if (next == null && get() != tail) {
>
> // if tail != head this is not going to change until producer
> makes progress
>
> // we can avoid reading the head and just spin on next until
> it shows up
>
> do {
>
> next = tail.next();
>
> } while (next == null);
>
> }
>
> return next;
>
> }
>
>
> I have attached a screenshot of the thread dump from jconsole.  I'm still
> in the early stages of debugging this, but would appreciate any info from
> the akka team on this.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Issue with Smallest Mailbox router pool introduced in akka 2.4.2

[Viktor Klang]

I think: regression?

On Fri, Mar 4, 2016 at 1:44 PM, Chris Baxter  wrote:

> Should I create a separate ticket for this?  It appeared to me like the
> issue with AbstractNodeQueue was fixed though.  Am I reading this wrong?
>
> On Friday, March 4, 2016 at 7:38:47 AM UTC-5, √ wrote:
>>
>> Could be related to: https://github.com/akka/akka/issues/19216
>>
>> On Fri, Mar 4, 2016 at 1:26 PM, Chris Baxter  wrote:
>>
>>> I have noticed a strange issue after we upgraded to akka 2.4.2 that
>>> appears sporadically but once it rears its ugly head it basically causes
>>> the server to consume a ton of CPU and we have to restart.  This issue
>>> appears to be with the smallest mailbox pool router.  It gets hung up in
>>> peekNode in AbstractNodeQueue, in that do/while loop:
>>>
>>> protected final Node peekNode() {
>>>
>>> final Node tail = ((Node)Unsafe.instance
>>> .getObjectVolatile(this, tailOffset));
>>>
>>> Node next = tail.next();
>>>
>>> if (next == null && get() != tail) {
>>>
>>> // if tail != head this is not going to change until
>>> producer makes progress
>>>
>>> // we can avoid reading the head and just spin on next
>>> until it shows up
>>>
>>> do {
>>>
>>> next = tail.next();
>>>
>>> } while (next == null);
>>>
>>> }
>>>
>>> return next;
>>>
>>> }
>>>
>>>
>>> I have attached a screenshot of the thread dump from jconsole.  I'm
>>> still in the early stages of debugging this, but would appreciate any info
>>> from the akka team on this.
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: How to? - Sink.foldM[U, T](zero: U)(f: (U, T) ⇒ Future[U]): Sink[T, Future[U]]

[Viktor Klang]

Since we have `unfold` and `unfoldAsync` for Source, I'd say it'd be more
than symmetric to have `fold` and `foldAsync` on Sink :)

On Sun, Mar 6, 2016 at 12:28 AM, Giovanni Alberto Caporaletti <
paradi...@gmail.com> wrote:

> Hi Roland,
> you're right, my solution was a bit naive. I came up with this, I'm pretty
> sure it can be done in a better way, looking forward to seeing your
> solution :)
>
> def foldM[U, T](zero: U)(f: (U, T) ⇒ Future[U]): Sink[T, Future[U]] = 
> Sink.fromGraph {
>   val sink = Sink.fold(zero)(Keep.right[U, U])
>
>   GraphDSL.create(sink) { implicit b => sink =>
> import GraphDSL.Implicits._
> val zip = b.add(ZipWith(f))
> val bcast = b.add(Broadcast[U](2))
> val merge = b.add(Merge[U](2))
> val z = Source.single(zero)
>
> z ~> merge
>  merge ~> zip.in0
>   zip.out.mapAsync(1)(identity) ~> bcast ~> sink
>  merge <~  bcast
>
> SinkShape(zip.in1)
>   }
> }
>
>
> On Saturday, 5 March 2016 21:52:06 UTC+1, rkuhn wrote:
>>
>> Unfortunately these solutions create unbounded amounts of futures without
>> back pressure, so I'd recommend against this approach. But it is late and
>> I'm on the phone so cannot suggest a proper solution.
>>
>> Regards,
>>
>> Roland
>>
>> Sent from my iPhone
>>
>> On 05 Mar 2016, at 17:41, Giovanni Alberto Caporaletti 
>> wrote:
>>
>> how about this:
>>
>> def foldM[U, T](zero: U)(f: (U, T) ⇒ Future[U]): Sink[T, Future[U]] = {
>>   Sink
>> .fold[Future[U], T](Future.successful(zero))((fu, t) => fu.flatMap(f(_, 
>> t)))
>> .mapMaterializedValue(_ flatMap identity)
>> }
>>
>> or this:
>>
>> def foldM[U, T](zero: U)(f: (U, T) ⇒ Future[U]): Sink[T, Future[U]] = {
>>   Flow[T]
>> .fold(Future.successful(zero))((fu, t) => fu.flatMap(f(_, t)))
>> .mapAsync(1)(identity)
>> .toMat(Sink.head)(Keep.right)
>> }
>>
>>
>>
>> On Saturday, 5 March 2016 17:00:08 UTC+1, Andrew Gaydenko wrote:
>>>
>>> Hi! There is
>>>
>>> f: (U, T) ⇒ Future[U]
>>>
>>> rather than
>>>
>>> f: (U, T) ⇒ U
>>>
>>> in hands. How to create
>>>
>>> Sink[T, Future[U]]
>>>
>>> ?
>>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+...@googlegroups.com.
>> To post to this group, send email to akka...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Error while creating router from config

[Viktor Klang]

Your configuration says that the router lives directly beneath /User/ bout
in reality you're trying to put it
under akka://ModellerSystem/user/localProcessor/$a/$b/$b/$a/$a/

On Fri, Mar 4, 2016 at 6:51 PM, Sergey Sopin  wrote:

> Hi,
>
> I am trying to create router from configuration but I'm getting
> ConfigurationException. My code is following:
>
> ActorRef subPathFinderRouter = 
> context().actorOf(FromConfig.getInstance().props(Props.create(SubPathFinderActor.class)),
>  "subPathFinderRouter");
>
>
> Config:
>
> "/*/subPathFinderRouter" {
>   #router = smallest-mailbox-pool
>   router = round-robin-pool
>   resizer {
>
> enabled = off
>
>  }
>
>   optimal-size-exploring-resizer {
> enabled = on
> lower-bound = 10
> #upper-bound = 10
> chance-of-ramping-down-when-full = 0.2
> downsize-after-underutilized-for = 1h
> explore-step-size = 0.2
> chance-of-exploration = 0.4
> downsize-ratio = 0.8
> optimization-range = 50
> weight-of-latest-metric = 0.5
>   }
> }
>
>
> When its trying to create this router it throws following error:
>
> [ERROR] [03/04/2016 19:47:45.466]
> [ModellerSystem-akka.actor.deployment.single-highload-dispatcher-24]
> [akka://ModellerSystem/user/localProcessor/$a/$b/$b/$a/$a] configuration
> problem while creating
> [akka://ModellerSystem/user/localProcessor/$a/$b/$b/$a/$a/subPathFinderRouter]
> with router dispatcher [akka.actor.default-dispatcher] and mailbox
> [akka.actor.default-mailbox] and routee dispatcher
> [akka.actor.default-dispatcher] and mailbox [akka.actor.default-mailbox]
> akka.ConfigurationException: configuration problem while creating
> [akka://ModellerSystem/user/localProcessor/$a/$b/$b/$a/$a/subPathFinderRouter]
> with router dispatcher [akka.actor.default-dispatcher] and mailbox
> [akka.actor.default-mailbox] and routee dispatcher
> [akka.actor.default-dispatcher] and mailbox [akka.actor.default-mailbox]
> at akka.actor.LocalActorRefProvider.actorOf(ActorRefProvider.scala:753)
> at akka.actor.dungeon.Children$class.makeChild(Children.scala:206)
> at akka.actor.dungeon.Children$class.actorOf(Children.scala:37)
> at akka.actor.ActorCell.actorOf(ActorCell.scala:369)
> at
> kernel.modeller.managers.SubPathProcessingSupervisor.createRouter(SubPathProcessingSupervisor.java:44)
> at
> kernel.modeller.managers.SubPathProcessingSupervisor.lambda$new$0(SubPathProcessingSupervisor.java:54)
> at
> kernel.modeller.managers.SubPathProcessingSupervisor$$Lambda$102/1078115745.apply(Unknown
> Source)
> at akka.japi.pf.UnitCaseStatement.apply(CaseStatements.scala:26)
> at akka.japi.pf.UnitCaseStatement.apply(CaseStatements.scala:21)
> at scala.PartialFunction$class.applyOrElse(PartialFunction.scala:118)
> at akka.japi.pf.UnitCaseStatement.applyOrElse(CaseStatements.scala:21)
> at scala.PartialFunction$OrElse.applyOrElse(PartialFunction.scala:165)
> at akka.actor.Actor$class.aroundReceive(Actor.scala:467)
> at akka.actor.AbstractActor.aroundReceive(AbstractActor.scala:47)
> at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)
> at akka.actor.ActorCell.invoke(ActorCell.scala:487)
> at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:238)
> at akka.dispatch.Mailbox.run(Mailbox.scala:220)
> at
> akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:397)
> at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
> at
> scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
> at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
> at
> scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
> Caused by: akka.ConfigurationException: Configuration missing for router
> [akka://ModellerSystem/user/localProcessor/$a/$b/$b/$a/$a/subPathFinderRouter]
> in 'akka.actor.deployment' section.
> at akka.routing.FromConfig.verifyConfig(RouterConfig.scala:297)
> at akka.routing.RoutedActorRef.(RoutedActorRef.scala:40)
> at akka.actor.LocalActorRefProvider.actorOf(ActorRefProvider.scala:751)
> ... 22 more
>
> [ERROR] [03/04/2016 19:47:45.466]
> [ModellerSystem-akka.actor.deployment.single-highload-dispatcher-25]
> [akka://ModellerSystem/user/localProcessor/$a/$b/$b/$b/$a] configuration
> problem while creating
> [akka://ModellerSystem/user/localProcessor/$a/$b/$b/$b/$a/subPathFinderRouter]
> with router dispatcher [akka.actor.default-dispatcher] and mailbox
> [akka.actor.default-mailbox] and routee dispatcher
> [akka.actor.default-dispatcher] and mailbox [akka.actor.default-mailbox]
> akka.ConfigurationException: configuration problem while creating
> [akka://ModellerSystem/user/localProcessor/$a/$b/$b/$b/$a/subPathFinderRouter]
> with router dispatcher [akka.actor.default-dispatcher] and mailbox
> [akka.actor.default-mailbox] and routee dispatcher
> [akka.actor.default-dispatcher] and mailbox [akka.actor.default-mailbox]
> at akka.actor.LocalActorRefProvider.actorOf(ActorRefProvider.scala:753)
> at akka.actor.dungeon.Children

Re: [akka-user] Source Repeat given interval

[Viktor Klang]

mapConcat(identity)

-- 
Cheers,
√
On Mar 7, 2016 10:26 PM, "Arun Sethia"  wrote:

> Hi,
>
> I have requirement where source should repeat infinite times after given
> interval, for example:
>
> val input:List[Int]=List(1,2,3)
>
>
> val flow=Flow[Int].map(x=> x * 2)
>
>
> Source(input.toList).via(*flow)*.runForeach(println)
>
>
> The source "input" should repeat every 1 second.
>
>
> I tried to use val source = 
> Source.tick(FiniteDuration(1,TimeUnit.SECONDS),FiniteDuration(1,TimeUnit.SECONDS),input),
>   but this will provide out stream as List.
>
>
> Thanks
>
> Arun
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] change of Tech Lead

[Viktor Klang]

Roland,

I've enjoyed working with you since the day you were hired,
and I'm glad I somehow managed to challenge you into starting to contribute
to Akka, because that was the start of some massive improvements to Akka
and its direction.

So, thank you for your service, for our many heated debates, for our shared
dislike for Lars Ulrich's drumming efforts, and for bringing tons of good
ideas to the table. (And metal is the best music to code to)


Patrik,

I'm thrilled to see you take on this role—there's zero doubt you're more
than qualified to take on the responsibilities of Akka Tech Lead—you've
done *stellar* work consistently over the years on the team.
I'm pretty stoked about the Future!


Unfortunately for you both, you have to endure me and my pointy-haired PRs
and comments :)

Also, the Akka community has been one of the friendliest and enjoyable
communities that I've had the privilege of being a part of over the years.
So I'm looking forward to see you Roland, sticking around. :)

Happy hAkking,

√

On Mon, Mar 7, 2016 at 6:37 PM, Roland Kuhn  wrote:

> Dear fellow hakkers,
>
> as of today I am passing on the baton of Akka Tech Lead @ Lightbend to
> Patrik Nordwall. Don’t worry, I will stay around and keep working on Akka,
> but it will no longer be my day job come April: I am co-founding actyx
> —a new start-up in Munich that aims at bringing
> reactive design principles to the IT behind industrial manufacturing—where
> I will build and lead the engineering organization. It was always my plan
> to solve concrete customer challenges once I have collected enough
> experience with building the tools, and while I had not yet started looking
> for an opportunity I could also not pass this one up when it presented
> itself.
>
> Akka will be in good hands with Patrik and the rest of the team, he is as
> passionate about distributed systems as I am and he is a much more
> disciplined coder—not to mention that he joined the Akka team before any
> other current member including myself. I am very grateful that I had the
> chance to be part of this amazing team for the past 4.5 years and I have no
> desire to leave this awesome community anytime soon.
>
> Regards,
>
> Roland
>
>
> Lightbend – Reactive apps on the JVM.
> twitter: @rolandkuhn
> 
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: How to? - Sink.foldM[U, T](zero: U)(f: (U, T) ⇒ Future[U]): Sink[T, Future[U]]

[Viktor Klang]

I'd like to repeat that a scanAsync and a foldAsync would be very welcome
additions :)

On Tue, Mar 8, 2016 at 12:01 AM, Andrew Gaydenko 
wrote:

> Giovanni, hi!
>
> Thanks! - have played with this test. In fact, I started tests with
> -Xmx=128M, and range up to 20M. The first two variants resulted in OOME, as
> Roland predicted, and the last one with own Graph resulted in the rather
> quick answer with small RAM footprint during execution (~100MB on system
> monitor) - as you waned :)
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: How to? - Sink.foldM[U, T](zero: U)(f: (U, T) ⇒ Future[U]): Sink[T, Future[U]]

[Viktor Klang]

I'll volunteer to review :)

On Tue, Mar 8, 2016 at 12:26 PM, Konrad Malawski 
wrote:

> Here's the ticket, you'd like to contribute these operations (it's pretty
> easy to contribute, one can look at mapAsync and see how it differs from
> map):
> https://github.com/akka/akka/issues/18603
>
> Thanks in advance if someone steps up to contribute!
>
> On Tue, Mar 8, 2016 at 12:12 PM, Viktor Klang 
> wrote:
>
>> I'd like to repeat that a scanAsync and a foldAsync would be very welcome
>> additions :)
>>
>> On Tue, Mar 8, 2016 at 12:01 AM, Andrew Gaydenko <
>> andrew.gayde...@gmail.com> wrote:
>>
>>> Giovanni, hi!
>>>
>>> Thanks! - have played with this test. In fact, I started tests with
>>> -Xmx=128M, and range up to 20M. The first two variants resulted in OOME, as
>>> Roland predicted, and the last one with own Graph resulted in the rather
>>> quick answer with small RAM footprint during execution (~100MB on system
>>> monitor) - as you waned :)
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >>>>>>>>>> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+unsubscr...@googlegroups.com.
>>> To post to this group, send email to akka-user@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Cheers,
> Konrad 'ktoso' Malawski
> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] zipWithIndex

[Viktor Klang]

There's also: someSource.zip(Source.fromIterator(() => Iterator.from(0)))

On Thu, Mar 10, 2016 at 3:42 PM, Akka Team  wrote:

> Hi Richard,
>
> I would say in general being able to achieve what you want by composition
> rather than a multitude of special stages is what we strive for with akka
> streams. There is also a big difference between the regular collections and
> the streams that streams might be infinite, parallell, cyclic etc, and in
> those cases a zipWithIndex might not make sense.
>
> You could also achieve what you describe with a single stage using
> statefulMapConcat like this:
>
> import scala.collection.immutable.Iterable
> val flow: Flow[String, (String, Long), NotUsed] = 
> Flow[String].statefulMapConcat { () =>
>   var index = 0L
>   def next = {
> index += 1
> index
>   }
>
>   (string) => Iterable((string, next))
> }
>
>
> --
> Johan Andrén
> Akka Team, Lightbend Inc.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Http Client with Source.tick

[Viktor Klang]

For each only deals with elements, not errors.
Please consult the documentation for combinators that let you observe and
manipulate errors.

-- 
Cheers,
√
On Mar 10, 2016 11:04 PM, "Arun Sethia"  wrote:

> httpSourceGraph1 is httpSourceGraph , but still same issue
>
>
> val response= httpSourceGraph.via(httpConnFlow()).runForeach(println)
>
>
> we can test same with any external internet URL also, the result remain same.
>
>
> On Thursday, March 10, 2016 at 3:55:22 PM UTC-6, Arun Sethia wrote:
>>
>> Hi,
>>
>> I am trying to connect http client to a http service exposed by server,
>> the source should send request every 1 second for that I have crated
>> following partial graphs:
>>
>>
>> def httpSourceGraph() = {
>>   Source.fromGraph(GraphDSL.create() { implicit builder =>
>> val sourceOutLet = builder.add(Source.tick(FiniteDuration(0, 
>> TimeUnit.SECONDS), FiniteDuration(1,
>>   TimeUnit.SECONDS),
>>   HttpRequest(uri ="/test", method = HttpMethods.GET))).out
>> // expose outlet
>> SourceShape(sourceOutLet)
>>   })
>> }
>>
>>
>> def httpConnFlow() = {
>>   Flow.fromGraph(GraphDSL.create() { implicit builder =>
>>
>> val httpSourceFlow = builder.add(Http(system).outgoingConnection(host = 
>> "localhost", port = 8080))
>>
>> FlowShape(httpSourceFlow.in, httpSourceFlow.out)
>>   })
>> }
>>
>>
>> the graph is composed as
>>
>>
>> val response= httpSourceGraph1.via(httpConnFlow()).runForeach(println)
>>
>>
>> if the http server (localhost:8080/test) is up and running, everything works 
>> fine, every 1 second I can see the response coming back from the server. I 
>> am not able to any response in case of  either server is down or it goes 
>> down later.
>>
>>
>> *I think it should give me following error:*
>>
>>
>> akka.stream.StreamTcpException: Tcp command 
>> [Connect(localhost/127.0.0.1:8080,None,List(),Some(10 seconds),true)] failed
>>
>>
>> Thanks for the help.
>>
>> -Arun
>>
>>
>>
>>
>> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Http Client with Source.tick

[Viktor Klang]

http://doc.akka.io/api/akka/2.4.2/?_ga=1.176202021.1085570125.1455222020#akka.stream.scaladsl.FlowOps

-- 
Cheers,
√
On Mar 10, 2016 11:43 PM, "Arun Sethia"  wrote:

> Thanks.
>
> please can you provide the link where I can see how to deal with such
> errors.
>
> On Thursday, March 10, 2016 at 4:22:35 PM UTC-6, √ wrote:
>>
>> For each only deals with elements, not errors.
>> Please consult the documentation for combinators that let you observe and
>> manipulate errors.
>>
>> --
>> Cheers,
>> √
>> On Mar 10, 2016 11:04 PM, "Arun Sethia"  wrote:
>>
>>> httpSourceGraph1 is httpSourceGraph , but still same issue
>>>
>>>
>>> val response= httpSourceGraph.via(httpConnFlow()).runForeach(println)
>>>
>>>
>>> we can test same with any external internet URL also, the result remain 
>>> same.
>>>
>>>
>>> On Thursday, March 10, 2016 at 3:55:22 PM UTC-6, Arun Sethia wrote:

 Hi,

 I am trying to connect http client to a http service exposed by server,
 the source should send request every 1 second for that I have crated
 following partial graphs:


 def httpSourceGraph() = {
   Source.fromGraph(GraphDSL.create() { implicit builder =>
 val sourceOutLet = builder.add(Source.tick(FiniteDuration(0, 
 TimeUnit.SECONDS), FiniteDuration(1,
   TimeUnit.SECONDS),
   HttpRequest(uri ="/test", method = HttpMethods.GET))).out
 // expose outlet
 SourceShape(sourceOutLet)
   })
 }


 def httpConnFlow() = {
   Flow.fromGraph(GraphDSL.create() { implicit builder =>

 val httpSourceFlow = builder.add(Http(system).outgoingConnection(host 
 = "localhost", port = 8080))

 FlowShape(httpSourceFlow.in, httpSourceFlow.out)
   })
 }


 the graph is composed as


 val response= httpSourceGraph1.via(httpConnFlow()).runForeach(println)


 if the http server (localhost:8080/test) is up and running, everything 
 works fine, every 1 second I can see the response coming back from the 
 server. I am not able to any response in case of  either server is down or 
 it goes down later.


 *I think it should give me following error:*


 akka.stream.StreamTcpException: Tcp command 
 [Connect(localhost/127.0.0.1:8080,None,List(),Some(10 seconds),true)] 
 failed


 Thanks for the help.

 -Arun




 --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Http Client with Source.tick

[Viktor Klang]

Cool, happy hAkking!

-- 
Cheers,
√
On Mar 11, 2016 12:11 AM, "Arun Sethia"  wrote:

> Super ... you guys are awesome ... more I am learning, it is becoming more
> and more interesting.
>
> I used recover, It worked well. Thanks a lot.
>
>
> On Thursday, March 10, 2016 at 4:52:30 PM UTC-6, √ wrote:
>>
>>
>> http://doc.akka.io/api/akka/2.4.2/?_ga=1.176202021.1085570125.1455222020#akka.stream.scaladsl.FlowOps
>>
>> --
>> Cheers,
>> √
>> On Mar 10, 2016 11:43 PM, "Arun Sethia"  wrote:
>>
>>> Thanks.
>>>
>>> please can you provide the link where I can see how to deal with such
>>> errors.
>>>
>>> On Thursday, March 10, 2016 at 4:22:35 PM UTC-6, √ wrote:

 For each only deals with elements, not errors.
 Please consult the documentation for combinators that let you observe
 and manipulate errors.

 --
 Cheers,
 √
 On Mar 10, 2016 11:04 PM, "Arun Sethia"  wrote:

> httpSourceGraph1 is httpSourceGraph , but still same issue
>
>
> val response= httpSourceGraph.via(httpConnFlow()).runForeach(println)
>
>
> we can test same with any external internet URL also, the result remain 
> same.
>
>
> On Thursday, March 10, 2016 at 3:55:22 PM UTC-6, Arun Sethia wrote:
>>
>> Hi,
>>
>> I am trying to connect http client to a http service exposed by
>> server, the source should send request every 1 second for that I have
>> crated following partial graphs:
>>
>>
>> def httpSourceGraph() = {
>>   Source.fromGraph(GraphDSL.create() { implicit builder =>
>> val sourceOutLet = builder.add(Source.tick(FiniteDuration(0, 
>> TimeUnit.SECONDS), FiniteDuration(1,
>>   TimeUnit.SECONDS),
>>   HttpRequest(uri ="/test", method = HttpMethods.GET))).out
>> // expose outlet
>> SourceShape(sourceOutLet)
>>   })
>> }
>>
>>
>> def httpConnFlow() = {
>>   Flow.fromGraph(GraphDSL.create() { implicit builder =>
>>
>> val httpSourceFlow = 
>> builder.add(Http(system).outgoingConnection(host = "localhost", port = 
>> 8080))
>>
>> FlowShape(httpSourceFlow.in, httpSourceFlow.out)
>>   })
>> }
>>
>>
>> the graph is composed as
>>
>>
>> val response= httpSourceGraph1.via(httpConnFlow()).runForeach(println)
>>
>>
>> if the http server (localhost:8080/test) is up and running, everything 
>> works fine, every 1 second I can see the response coming back from the 
>> server. I am not able to any response in case of  either server is down 
>> or it goes down later.
>>
>>
>> *I think it should give me following error:*
>>
>>
>> akka.stream.StreamTcpException: Tcp command 
>> [Connect(localhost/127.0.0.1:8080,None,List(),Some(10 seconds),true)] 
>> failed
>>
>>
>> Thanks for the help.
>>
>> -Arun
>>
>>
>>
>>
>> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives:
> https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google
> Groups "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
 --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the do

Re: [akka-user] How-to restart a RunnableGraph on failure?

[Viktor Klang]

"The only thing worse than not saying anything, is telling a lie."

(i.e. I don't think that's a solution)

On Mon, Mar 21, 2016 at 7:22 PM, Endre Varga 
wrote:

> The issue is that there might be 3rd party RS stages, or stages from a
> different materializer, so even such future will not guarantee termination
> of a graph. But maybe it is still enough.
>
> On Mon, Mar 21, 2016 at 5:56 PM, Patrik Nordwall <
> patrik.nordw...@gmail.com> wrote:
>
>> Could we have a termination Future, similar to the ActorSystem?
>>
>> mån 21 mars 2016 kl. 16:59 skrev Endre Varga :
>>
>>> Ah, OK that will work. The only issue is that shutdown() is asynchronous
>>> so you cannot be fully sure when it has stopped everything.
>>>
>>> -Endre
>>>
>>> On Mon, Mar 21, 2016 at 4:58 PM,  wrote:
>>>
 Hi Endre,
 forgive my wording. I meant calling shutdown() on the materializer of
 the current exception-throwing stream  and then start this  stream
 with a new materializer

 Am Montag, 21. März 2016 16:51:01 UTC+1 schrieb Akka Team:

>
>
> On Mon, Mar 21, 2016 at 4:45 PM,  wrote:
>
>> Hi Endre,
>> I think  I do have a valid use case. I have a stream which
>> occasionally fails seriously (maybe 2 times a year) .
>> Since it has a zip stage I have the option to either handle the
>> Exception and keep the Zip stage balanced or
>> just let the exception propagate to the default decider and just
>> restart the stream.
>>
>
> But there is no such thing as "restart the stream". The current
> built-in "supervision" only restarts a single stream processing stage but
> not the whole graph. There is currently no way to restart a whole graph 
> and
> it is not a trivial problem to tackle in general.
>
> -Endre
>
>
>> The  work of the stream is "transactional" so I have no problems with
>> the current broken state caused by the exception.
>>
>> For me restart simplifies my code so I think It is ok?!
>>
>> Am Montag, 21. März 2016 10:35:58 UTC+1 schrieb Akka Team:
>>>
>>> Hi John,
>>>
>>> I am not sure what you hope to achieve there and if that even
>>> possible. Restarting a graph is more similar to restarting a group of
>>> actors not to a single actor and it is not that easy to do given the
>>> backpressure state between the restarted stages must be preserved. Also,
>>> while one stage fails, other parts of the graph might not and still run
>>> concurrently, etc.
>>>
>>> -Endre
>>>
>>> On Fri, Mar 18, 2016 at 1:34 PM,  wrote:
>>>
 This would be the solution I would use:

 http://pastebin.com/pJVnHqcH

 I am a little unsure about mat.stop() and the Supervision.stop().

 Should the code work? I want to restart on every Exception thrown
 from any Flow,Source,Sink of the Runnable graph

 Am Freitag, 18. März 2016 11:28:23 UTC+1 schrieb drewhk:
>
> Hi,
>
> There is no such thing at the moment.
>
> The onComplete on the sink does not guarantee that the whole
> stream has actually stopped, it only guarantees that the Sink itself 
> was
> stopped (which may or may not imply completion of the whole stream; 
> think
> of graphs).
>
> -Endre
>
> On Fri, Mar 18, 2016 at 11:25 AM,  wrote:
>
>> Hi,
>> If a graph throws an Exception in any flow  I want  to restart
>> the graph.
>>
>> Actually I would love to have something like Akka Actors
>> OneForOneStrategy(10, Duration.create("1 minute"))
>>
>> I couldn't find the right hints in the docs. What I am trying
>> right now is this pseudo code:
>>
>> Function decider = exc -> 
>> Supervision.stop();
>> Sink sink = ;
>>
>> RunnableGraph> runnableGraph = takeGraph.toMat(sink, 
>> Keep.right());
>>
>> ActorMaterializer mat = 
>> ActorMaterializer.create(ActorMaterializerSettings.create(system).withSupervisionStrategy(decider),
>>  system);
>>
>> runnableGraph.run(mat).onComplete(new OnComplete() {
>>public void onComplete(Throwable failure, Integer value) {
>>   ActorMaterializer mat2 = 
>> ActorMaterializer.create(ActorMaterializerSettings.create(system).withSupervisionStrategy(decider),
>>  system);
>>   runnableGraph.run(mat2);
>>}
>> }, system.dispatcher());
>>
>> Obviously the above code would only restart once...
>> Anyway is this the right direction?
>> Is there an idiomatic way to setup restart of an Runablegraph when a 
>> Exception happens
>>
>> Write now I am thinking of creating a Supervision Actor and u

Re: [akka-user] How implement recursion in futures correctly? (Java)

[Viktor Klang]

Use ACPS:
https://github.com/viktorklang/blog/blob/master/Futures-in-Scala-2.12-part-9.md

-- 
Cheers,
√
On Mar 22, 2016 7:00 AM, "Piper"  wrote:

> I am having a hard time understanding how to use futures specifically when
> it comes to implementing functions within those futures.
>
> So for example, if I wanted to implement factorial in a future using this
> algorithm:
>  int factorial(int n) {
>
>if (n == 0)
>   return 1;
>else
>   return (n * factorial(n-1));
>}
>
>
> My current guess is:
>
>
> Future f = future(new function () {
>  public Integer apply(Integer i) {
> if (i == 0) {
> return 1;
> }
> else {
>   return (i * apply(n-1));
> }
>  }
> }, system.dispatcher());
>results = f.onSuccess(new PrintResult(), 
> system.dispatcher());
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How-to restart a RunnableGraph on failure?

[Viktor Klang]

What is that information going to be useful for, in other words,
let's first outline the requirements before picking a solution.

-- 
Cheers,
√
On Mar 22, 2016 8:57 AM, "Endre Varga"  wrote:

>
>
> On Mon, Mar 21, 2016 at 7:27 PM, Viktor Klang 
> wrote:
>
>> "The only thing worse than not saying anything, is telling a lie."
>>
>
> This does not apply here. The termination Future would correctly signal
> that all stages that has been materialized by that materializer has been
> stopped (since they are child actors this is fully possible). My point was
> that this feature will not double as a "shut down a graph and be notified
> when ready" feature. It will not "lie" though, termination of the
> ActorMaterializer results in stopping all of the actors materialized by
> that materializer.
>
> -Endre
>
>
>
>>
>> (i.e. I don't think that's a solution)
>>
>> On Mon, Mar 21, 2016 at 7:22 PM, Endre Varga 
>> wrote:
>>
>>> The issue is that there might be 3rd party RS stages, or stages from a
>>> different materializer, so even such future will not guarantee termination
>>> of a graph. But maybe it is still enough.
>>>
>>> On Mon, Mar 21, 2016 at 5:56 PM, Patrik Nordwall <
>>> patrik.nordw...@gmail.com> wrote:
>>>
>>>> Could we have a termination Future, similar to the ActorSystem?
>>>>
>>>> mån 21 mars 2016 kl. 16:59 skrev Endre Varga >>> >:
>>>>
>>>>> Ah, OK that will work. The only issue is that shutdown() is
>>>>> asynchronous so you cannot be fully sure when it has stopped everything.
>>>>>
>>>>> -Endre
>>>>>
>>>>> On Mon, Mar 21, 2016 at 4:58 PM,  wrote:
>>>>>
>>>>>> Hi Endre,
>>>>>> forgive my wording. I meant calling shutdown() on the materializer
>>>>>> of the current exception-throwing stream  and then start this  stream
>>>>>> with a new materializer
>>>>>>
>>>>>> Am Montag, 21. März 2016 16:51:01 UTC+1 schrieb Akka Team:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Mar 21, 2016 at 4:45 PM,  wrote:
>>>>>>>
>>>>>>>> Hi Endre,
>>>>>>>> I think  I do have a valid use case. I have a stream which
>>>>>>>> occasionally fails seriously (maybe 2 times a year) .
>>>>>>>> Since it has a zip stage I have the option to either handle the
>>>>>>>> Exception and keep the Zip stage balanced or
>>>>>>>> just let the exception propagate to the default decider and just
>>>>>>>> restart the stream.
>>>>>>>>
>>>>>>>
>>>>>>> But there is no such thing as "restart the stream". The current
>>>>>>> built-in "supervision" only restarts a single stream processing stage 
>>>>>>> but
>>>>>>> not the whole graph. There is currently no way to restart a whole graph 
>>>>>>> and
>>>>>>> it is not a trivial problem to tackle in general.
>>>>>>>
>>>>>>> -Endre
>>>>>>>
>>>>>>>
>>>>>>>> The  work of the stream is "transactional" so I have no problems
>>>>>>>> with the current broken state caused by the exception.
>>>>>>>>
>>>>>>>> For me restart simplifies my code so I think It is ok?!
>>>>>>>>
>>>>>>>> Am Montag, 21. März 2016 10:35:58 UTC+1 schrieb Akka Team:
>>>>>>>>>
>>>>>>>>> Hi John,
>>>>>>>>>
>>>>>>>>> I am not sure what you hope to achieve there and if that even
>>>>>>>>> possible. Restarting a graph is more similar to restarting a group of
>>>>>>>>> actors not to a single actor and it is not that easy to do given the
>>>>>>>>> backpressure state between the restarted stages must be preserved. 
>>>>>>>>> Also,
>>>>>>>>> while one stage fails, other parts of the graph might not and still 
>>>>>>>>> run
>>>>>>>>> concurrently, etc.
>>>>>>>>

Re: [akka-user] Detecting empty source

[Viktor Klang]

…and, an empty source is one which signals onComplete before any data has
passed through. :)

On Tue, Mar 22, 2016 at 10:58 AM, Akka Team  wrote:

> Hi Richard,
>
> There is no other way to detect whether a Source is empty than to run it.
> For example if a Source wraps a DB query then of course it is impossible to
> see if the query will be empty or not without actually materializing and
> hence running the query.
>
> -Endre
>
> On Mon, Mar 21, 2016 at 4:59 AM, Richard Rodseth 
> wrote:
>
>> I'm doing a flatMapMerge something like this:
>>
>> val stream = Source(channelMonths)
>>
>>   .flatMapMerge(10, channelMonth => {
>>
>> ..Sources.intervalsForChannelMonth(channelMonth, ...)
>>
>>   })
>>
>> I'm implementing some monitoring using alsoTo to send stream elements to
>> a monitoring actor which can keep counts and so forth.
>>
>> How could I detect that the intervals source is sometimes empty? eg.
>> record the channels for which there are 0 intervals?
>>
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Akka Team
> Typesafe - Reactive apps on the JVM
> Blog: letitcrash.com
> Twitter: @akkateam
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Apparent thread leak with non-default akka dispatcher

[Viktor Klang]

Great story, Jesse. Thanks for sharing!

On Wed, Mar 23, 2016 at 3:12 PM, Jesse C  wrote:

> Here is what we've figured out. We've got a native library that contains a
> thread local member that includes a ZMQ socket. That socket is apparently
> not being correctly cleaned-up on thread death. ZMQ sockets are created
> from a ZMQ context, which creates 2 helper threads upon construction. Those
> are the threads we were leaking.
>
> The actor in Akka was invoking this native library. In our old code, using
> Scala's now-deprecated, built-in actor library, we had locked that actor to
> a single thread, so there was never any thread leakage. In Akka, we were
> using a Pinned dispatcher, with the understanding that that would result in
> the same behavior. The scalaDocs say "Dedicates a unique thread for each
> actor passed in as reference."
>
> The akka manual also adds "Note that it's not guaranteed that the *same*
> thread is used over time, since the core pool timeout is used for
> PinnedDispatcher to keep resource usage down in case of idle actors. To
> use the same thread all the time you need to add
> thread-pool-executor.allow-core-timeout=off to the configuration of the
> PinnedDispatcher."
>
> We missed that part. It might help others to have that added to the
> scaladocs.
>
> The solution that we've found to work is to set the allow-core-timeout to
> off and the thread-pool-executor.keep-alive-time to a really high number.
> With those settings we've now got the behavior we thought we were
> originally getting, where the actor is locked into a single thread for its
> entire lifetime.
>
> We're also looking at fixing the thread leak issue in the native library.
>
> Thanks for the responses.
>
> cheers
> jesse c
>
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [akka java 2.4.2] Future callbacks for already completed futures

[Viktor Klang]

You're in luck today—I happen to be a Klang!

What you found is no longer valid and applied to the original Akka Futures.

Thanks for finding this ancient documentation remnant, if you ever see me
at a conference, please let me know and I'll thank you in person. :)



On Thu, Mar 24, 2016 at 3:28 PM, Roland Kuhn  wrote:

> I'm no Klang but I can assure you that all callbacks MUST be dispatched on
> the provided ExecutionContext—otherwise someone will invariably find a way
> to trigger a StackOverflowError. These docs should probably be removed
> completely since we also moved to Scala futures.
>
> Regards,
>
> Roland
>
> Sent from my iPhone
>
> On 24 Mar 2016, at 15:20, Akka Team  wrote:
>
> I have a feeling that that doc remark is obsolete (these sections were not
> touched in years), but let the expert/Klang speak.
>
> -Endre
>
> On Thu, Mar 24, 2016 at 3:18 PM, Johannes Berg  wrote:
>
>> Hi!
>>
>> I've read the documentation at
>> http://doc.akka.io/docs/akka/2.4.2/java/futures.html and where the map
>> function is explained it's stated that "If the Future is already
>> complete though, it will be run in our current thread.". I've just done
>> some tests suggesting this statement would be false, it seems like it's
>> always dispatched on the execution context even though it's already
>> completed.
>>
>> For example this prints two different thread ID:s:
>>
>> System.out.println(Thread.currentThread().getId());
>> Futures.successful(new Object()).map(new Mapper() {
>> public Object apply(Object obj) {
>> System.out.println(Thread.currentThread().getId());
>> }
>> }, system.dispatcher());
>>
>> Indeed I would prefer that behaviour and would like to trust that fact
>> but then the statement in the docs needs to be changed.
>>
>> Can somebody confirm this, I'm happy to create a bug report in github if
>> you think this indeed is a bug in the documentation.
>>
>> I also found some old stuff about this:
>>
>> https://www.assembla.com/spaces/akka/tickets/1054-complete-futures-asynchronously-when-replying-through-a-channel/details#
>> http://blog.ometer.com/2011/07/24/callbacks-synchronous-and-asynchronous/
>>
>> Best Regards,
>> Johannes Berg
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Akka Team
> Typesafe - Reactive apps on the JVM
> Blog: letitcrash.com
> Twitter: @akkateam
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] postStop doesn't get invoked after actor initialization failure

[Viktor Klang]

Philosophically, how can something be stopped which failed to start?

-- 
Cheers,
√
On Mar 27, 2016 6:12 PM, "Stanislav Savulchik" 
wrote:

> Hi, everyone!
>
> I've discovered that Actor's postStop method doesn't get invoked if
> exception occurs during actor initialization via preStart method. Does
> anyone know if it is the correct behavior? I expected that the failed actor
> could close some resources in postStop.
>
> P.S. The behavior differs when a failure occurs during regular vs. system
> message processing and supervisor decides to Stop the failed child. It
> seems inconsistent to me.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] akka://ClusterSystem/deadLetters

[Viktor Klang]

?

-- 
Cheers,
√
On Mar 28, 2016 6:49 PM, "Sudha Vuppalapati" 
wrote:

>  [ClusterSystem-akka.actor.default-dispatcher-15]
> [akka://ClusterSystem/deadLetters] Message
> [akka.cluster.InternalClusterAction$InitJoin$] from
> Actor[akka://ClusterSystem/system/cluster/core/daemon/joinSeedNodeProcess-1#-1262010307]
> to Actor[akka://ClusterSystem/deadLetters] was not delivered. [2] dead
> letters encountered. This logging can be turned off or adjusted with
> configuration settings 'akka.log-dead-letters' and
> 'akka.log-dead-letters-during-shutdown'.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] postStop doesn't get invoked after actor initialization failure

[Viktor Klang]

PostStop would never be called if the constructor fails. Which could be
said to be similar to preStart?

-- 
Cheers,
√
On Mar 31, 2016 2:39 PM, "Endre Varga"  wrote:

>
>
> On Thu, Mar 31, 2016 at 2:36 PM, Guido Medina  wrote:
>
>> it gets worse if I failed starting "b" because  now "a" is started and it
>> won't be stopped,
>>
>
> I don't understand this question. If we failed starting "b" then it will
> not be running, this is not changed by calling postStop() on the retreat
> before nulling out the actor.
>
>
>> such cases IMHO should be handled by the user
>>
> and
>> instead just stick to the contract which is, "stop if was started" which
>> will lead to less
>>
>
> The contract will be here just as simple first preStart and eventually
> postStop will be attempted to be called, after which the actor is GC-able.
> This is also a simple contract.
>
>
>> confusion and easier to maintain the exceptional cases.
>>
>>
>> On Thursday, March 31, 2016 at 1:23:39 PM UTC+1, Guido Medina wrote:
>>>
>>> so, say:
>>>
>>> Object a = null, Object b = null;
>>>
>>> preStart():
>>>
>>>   a = new something(); a.start(); *<= say I failed here.*
>>>   b = new somethingElse(); b start();
>>>
>>> postStop():
>>>
>>>   b.stop(); boom NPE.
>>>   a.stop();
>>>
>>> That's why the word transaction exist right? A unit is considered
>>> started or valid of all its parts are valid and started...
>>> But go ahead, make legacy code life miserable...the decision is yours.
>>>
>>> Try catch is there for a reason but somehow magic exists.
>>>
>>> Guido.
>>>
>>> On Thursday, March 31, 2016 at 1:15:27 PM UTC+1, drewhk wrote:



 On Thu, Mar 31, 2016 at 2:10 PM, Guido Medina  wrote:

> I haven't seen any system stopping something consciously that it was
> unable to start, the created instance is just an instance like another
> other object which will be GCed.
>

 I don't agree, you might have opened a file or socket in the
 constructor or parts of preStart() before the exception.


> If you look at it from a state machine perspective Status: CREATED =>
> CALL START (or preStart don't worry about details) => Status: Started
>
> It is more destructive to call postStop if it didn't actually started
> because then you will get NPE for stopping things that are part of the
> actor that weren't instantiated.
>
 Now I have to protect my code from Akka calling postStop...see my point?
>

 Nope, Akka should just swallow the double-fault at that point. I still
 think it should at least attempt to call postStop() to mitigate resource
 leaks.

 -Endre


>
> Guido.
>
> On Thursday, March 31, 2016 at 9:19:15 AM UTC+1, drewhk wrote:
>>
>> That description suits me ;)
>>
>> On Thu, Mar 31, 2016 at 10:18 AM, Patrik Nordwall <
>> patrik@gmail.com> wrote:
>>
>>> From the source: "Only change this if you're very confident and
>>> lucky" :-)
>>>
>>> On Thu, Mar 31, 2016 at 9:30 AM, Endre Varga >> > wrote:
>>>
 Shouldn't we all postStop there if preStart has been at least
 invoked (i.e. there is already an instance)? It does not seem to be 
 hard,
 just shuffling that code a bit around (famous last words?).

 On Thu, Mar 31, 2016 at 9:25 AM, Patrik Nordwall <
 patrik@gmail.com> wrote:

> I think that is how it is implemented. Exception from preStart
> results in clearing the actor field and
> throwing ActorInitializationException:
>
> https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/actor/ActorCell.scala#L599
>
> Default supervision will result in stop, but postStop is not
> called because the actor field was cleared:
> https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/actor/dungeon/FaultHandling.scala#L210
>
> On Wed, Mar 30, 2016 at 10:59 AM, Endre Varga <
> endre...@lightbend.com> wrote:
>
>>
>>
>> On Sun, Mar 27, 2016 at 5:52 PM, Stanislav Savulchik <
>> s.sav...@gmail.com> wrote:
>>
>>> Hi, everyone!
>>>
>>> I've discovered that Actor's postStop method doesn't get invoked
>>> if exception occurs during actor initialization via preStart 
>>> method. Does
>>> anyone know if it is the correct behavior? I expected that the 
>>> failed actor
>>> could close some resources in postStop.
>>>
>>
>> Do you have a reproducer for this? I would also expect postStop
>> to be at least attempted to be called.
>>
>>
>>> P.S. The behavior differs when a failure occurs during regular
>>> vs. system message processing and supervisor decides to Stop the 
>>> failed
>>> child. It seems inconsisten

Re: [akka-user] Akka on Android: akka.actor.ActorInitializationException

[Viktor Klang]

Hi Luca,

check the stack trace of the ActorInitializationException

On Fri, Apr 1, 2016 at 10:02 AM, Luca Lovagnini 
wrote:

> Hello Akka community!
>
> I'm trying to porting Apache Flink  (which
> relays on Akka) to Android, but don't worry: you don't need to know this
> framework for this topic.
>
> While I was debugging, I caught a sendmessage() call in ActorCell.scala
> where the sender is null and message is:
>
>
> Error(akka.actor.ActorInitializationException:exception during creation"
>
>
> and in particular:
>
> Failed resolution of: Ljava/lang/management/ManagementFactory;
>
>
> I don't know Akka so well and I don't understand where actually IS the
> code that generates this message, e.g. where is the actor creation? And of
> course if you know how to solve this on Android, please tell me!
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] akka 2.4.2 [java] stopping http-server and flow handling IncomingConnection

[Viktor Klang]

When you say "cancel" do you mean "abrupt termination" or something with a
code path attached to it?

On Thu, Mar 31, 2016 at 11:53 PM, paweł kamiński  wrote:

> dont take it personally, there is a lot to process and sometimes it is
> easy to overlook the most important part, I guess I didn't get the context
> of the last sentence.
>
> thanks
>
> On Thursday, 31 March 2016 23:45:03 UTC+2, Konrad Malawski wrote:
>>
>> In 2.4.2 you can do the same in a GraphStage (read up on custom stream
>> processing – cancel() and friends).
>>
>> --
>> Cheers,
>> Konrad 'ktoso’ Malawski
>> Akka  @ Lightbend 
>> 
>>
>> On 31 March 2016 at 23:38:30, paweł kamiński (kam...@gmail.com) wrote:
>>
>> hej Konrad, can you please point me to any documentation describing how
>> to manually cancel living flow? the official documentation assumes that
>> flows are infinite or eventually source will be drained - so no problem.
>> I cannot find any section on the topic of cancelling flows subscription.
>>
>> On Wednesday, 30 March 2016 10:39:35 UTC+2, paweł kamiński wrote:
>>>
>>> I thought bold is new black, coming back with a bang...
>>>
>>> ok, your explanation makes kind of sense ;] all I expected was a
>>> shutdown method with timeout.
>>> and yeah a section with examples would be nice and I can write one once
>>> I understand how it works ;]
>>>
>>> I understand that I need to hold each connection and then iterate over
>>> them after unbind.
>>> but I need a hint how to "cancels flows upstream subscription", I can't
>>> see any useful method on connection or connection.flow().
>>>
>>> and one more thing - until now I thought that creating flow from actor
>>> will make such flow child of the actor, so closing actor would close also
>>> flow's actors, obviously it is not and flow is keep on consuming incoming
>>> messages even though actor is long gone.
>>>
>>> On Wednesday, 30 March 2016 00:32:24 UTC+2, Konrad Malawski wrote:

 Helloł,

 I notice that after unbind I cannot create new connection (ie. from a
 browser) but old, alive connection can still send requests. Am I missing
 something?

 Please no bold to highlight question, it looks scary :-)

 That's exactly how it works, by design. I did notice however that we do
 not have a shutting down section for the low level API, we should add that
 - thanks -> https://github.com/akka/akka/issues/20177

 Would be awesome if you'd perhaps step up and help contributing a
 beginning of that docs section :-)

 Just looking at
 http://doc.akka.io/docs/akka/2.4.2/java/http/server-side/low-level-server-side-api.html#starting-and-stopping
 I guess I do the right thing.
 but I cannot understand a fragment from
 http://doc.akka.io/docs/akka/2.4.2/java/http/server-side/low-level-server-side-api.html#Closing_a_connection,
 "The HTTP connection will be closed when the handling Flow cancels its
 upstream subscription".
 Should I manually close connection after unbinding? that would be
 strange, I just want to unbind and shutdown, closing all live connections.

 No, it's not strange for two reasons: a) it's "unbind" which means
 "release that port, I won't be accepting anything new on it", and it also
 it is b) the behaviour one wants for  it's called graceful shutdown – serve
 the people that already sent you requests, and stop accepting new ones,
 then shut down.

 The "shutdown now and drop everything on the floor" can already be
 achieved in a rather brutal way – killing the ActorSystem, however the
 feature is on our radar however it's a new feature: shutdownNow on
 github .


 For injecting "external termination" intro streams, we have KillSwitch
 prepared which will likely ship with 2.4.3.


 --
 Cheers,
 Konrad 'ktoso’ Malawski
 Akka  @ Lightbend 

 

>>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+...@googlegroups.com.
>> To post to this group, send email to akka...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---

Re: [akka-user] any plans to integrate ignite as a data grid with Akka ?

[Viktor Klang]

Hi Mahmoud,

what would the benefits be?

On Thu, Mar 31, 2016 at 4:32 PM, mahmoud romeh 
wrote:

> Hi All ,
>
> is there any plan to have to integration between apache and akka or maybe
> using the cluster manager of Ignite to be the cluster manager of AKKA ?  or
> cache access integration between Akka and Ignite data grid ?
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] akka 2.4.2 [java] stopping http-server and flow handling IncomingConnection

[Viktor Klang]

Call 'shutdown' on the ActorSystem? Or only the Materializer?

On Fri, Apr 1, 2016 at 11:29 AM, paweł kamiński  wrote:

> I want to clean state of the app, so I could
>
> 1) terminate akka-system which would also terminate http-server and start
> it all over again.
> OR
> 2) I thought about shutting down just http-server in reaction to some
> fault state of actors hierarchy.
>
> Konrad's comment states that it is not enough just to unbind from port, as
> active connection and their flows are operating, so I need to terminate
> each flow after unbinding.
> At this point I have no other requirements.
>
> On Friday, 1 April 2016 11:05:57 UTC+2, √ wrote:
>>
>> When you say "cancel" do you mean "abrupt termination" or something with
>> a code path attached to it?
>>
>> On Thu, Mar 31, 2016 at 11:53 PM, paweł kamiński 
>> wrote:
>>
>>> dont take it personally, there is a lot to process and sometimes it is
>>> easy to overlook the most important part, I guess I didn't get the context
>>> of the last sentence.
>>>
>>> thanks
>>>
>>> On Thursday, 31 March 2016 23:45:03 UTC+2, Konrad Malawski wrote:

 In 2.4.2 you can do the same in a GraphStage (read up on custom stream
 processing – cancel() and friends).

 --
 Cheers,
 Konrad 'ktoso’ Malawski
 Akka  @ Lightbend 
 

 On 31 March 2016 at 23:38:30, paweł kamiński (kam...@gmail.com) wrote:

 hej Konrad, can you please point me to any documentation describing how
 to manually cancel living flow? the official documentation assumes that
 flows are infinite or eventually source will be drained - so no problem.
 I cannot find any section on the topic of cancelling flows
 subscription.

 On Wednesday, 30 March 2016 10:39:35 UTC+2, paweł kamiński wrote:
>
> I thought bold is new black, coming back with a bang...
>
> ok, your explanation makes kind of sense ;] all I expected was a
> shutdown method with timeout.
> and yeah a section with examples would be nice and I can write one
> once I understand how it works ;]
>
> I understand that I need to hold each connection and then iterate over
> them after unbind.
> but I need a hint how to "cancels flows upstream subscription", I
> can't see any useful method on connection or connection.flow().
>
> and one more thing - until now I thought that creating flow from actor
> will make such flow child of the actor, so closing actor would close also
> flow's actors, obviously it is not and flow is keep on consuming incoming
> messages even though actor is long gone.
>
> On Wednesday, 30 March 2016 00:32:24 UTC+2, Konrad Malawski wrote:
>>
>> Helloł,
>>
>> I notice that after unbind I cannot create new connection (ie. from a
>> browser) but old, alive connection can still send requests. Am I missing
>> something?
>>
>> Please no bold to highlight question, it looks scary :-)
>>
>> That's exactly how it works, by design. I did notice however that we
>> do not have a shutting down section for the low level API, we should add
>> that - thanks -> https://github.com/akka/akka/issues/20177
>>
>> Would be awesome if you'd perhaps step up and help contributing a
>> beginning of that docs section :-)
>>
>> Just looking at
>> http://doc.akka.io/docs/akka/2.4.2/java/http/server-side/low-level-server-side-api.html#starting-and-stopping
>> I guess I do the right thing.
>> but I cannot understand a fragment from
>> http://doc.akka.io/docs/akka/2.4.2/java/http/server-side/low-level-server-side-api.html#Closing_a_connection,
>> "The HTTP connection will be closed when the handling Flow cancels
>> its upstream subscription".
>> Should I manually close connection after unbinding? that would be
>> strange, I just want to unbind and shutdown, closing all live 
>> connections.
>>
>> No, it's not strange for two reasons: a) it's "unbind" which means
>> "release that port, I won't be accepting anything new on it", and it also
>> it is b) the behaviour one wants for  it's called graceful shutdown – 
>> serve
>> the people that already sent you requests, and stop accepting new ones,
>> then shut down.
>>
>> The "shutdown now and drop everything on the floor" can already be
>> achieved in a rather brutal way – killing the ActorSystem, however the
>> feature is on our radar however it's a new feature: shutdownNow on
>> github .
>>
>>
>> For injecting "external termination" intro streams, we have
>> KillSwitch prepared which will likely ship with 2.4.3.
>>
>>
>> --
>> Cheers,
>> Konrad 'ktoso’ Malawski
>> Akka  @ Lightbend
>> 
>>
>> 

Re: [akka-user] Supervising Remote Actors

[Viktor Klang]

http://doc.akka.io/docs/akka/2.4.2/scala/remoting.html#Creating_Actors_Remotely

On Fri, Apr 1, 2016 at 12:05 PM, Jayesh Jadhav  wrote:

> Hi,
>
> Is it possible to supervise remote actors? Since faults should be
> contained, asynchronously signaled and managed, will an exception thrown in
> the onReceive of a child actor be received in supervisor's strategy's apply()
> method? If yes, how are the exceptions propagated over the network?
>
>1. public class Child extends UntypedActor {
>2. int state = 0;
>3.
>4. public void onReceive(Object o) throws Exception {
>5. if (o instanceof Exception) {
>6. throw (Exception) o;
>7. } else if (o instanceof Integer) {
>8. state = (Integer) o;
>9. } else if (o.equals("get")) {
>10. getSender().tell(state, getSelf());
>11. } else {
>12. unhandled(o);
>13. }
>14. }
>15. }
>
> Thank you,
> Jayesh J.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [reactive-kafka 0.9.0.1] Why is my use of reactive-kafka so slow on commit?

[Viktor Klang]

Hi Greg,

I don't know why the performance is low in your example, but there are
several problematic aspects of how you're measuring.

For any benchmark on the JVM, plaese use JMH
 (for sbt projects, see
sbt-jmh )

On Thu, Mar 31, 2016 at 10:44 PM, tigerfoot  wrote:

> Hello,
>
> I'm using a simple consumer pulled right out of the examples in the github
> repo:
>
> count = 0
> val graph = GraphDSL.create(Consumer[Array[Byte], String](provider)) {
> implicit b => kafka =>
>   import GraphDSL.Implicits._
>   type In = ConsumerRecord[Array[Byte], String]
>   val show = Flow[In].map{ i => count += 1; if(i.value=="done")
> println(s"[$id] time 2 ($count): "+(System.currentTimeMillis() - now)); i }
>
>   kafka.messages ~> show ~> Consumer.record2commit ~> kafka.commit
>
>   SourceShape(kafka.confirmation)
> }
> now = System.currentTimeMillis()
> val control = Source.fromGraph(graph)
> .to(shutdownAsOnComplete)
> .run()
>
> This works fine, but its really slow.  When I pre-populate a topic with
> 1000 messages it took 2.2 sec to digest them.
> When I dispensed with the Akka stream logic and just used a trivial while
> loop with consumer.poll() and consumer.comitSync
> I got eye-watering performance--6-figure messages/sec.
>
> To rule out Akka streams I timed a "hello world" stream, and again got a
> very fast throughput number.
>
> My suspicion is that something in reactive-kafka's ManualCommitConsumer class
> is causing the slowness but I'm not sure.
>
> Any ideas appreciated.
> Greg
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka 2.4.3 cannot read response body when using http 1.0 request

[Viktor Klang]

Could you include the error?

-- 
Cheers,
√
On Apr 5, 2016 08:37, "xiaog zh"  wrote:

> Hi,
>   Below is a whole unit test in my project, and it fails when using
> `HTTP/1.0` protocol, success when using `HTTP/1.1`. Can somebody help
> explain the reason?
>
> // setup mock server
> val json =
>   """
> |{"result":true}
>   """.stripMargin
>
> val source = Source(ByteString(json) :: Nil)
> val mockRoutes = path("test" / "proxy_chunked.do") {
>   get {
> complete {
>   HttpResponse(StatusCodes.OK, entity = 
> HttpEntity(ContentTypes.`application/json`, source))
> }
>   }
> } ~ complete {
>   HttpResponse(StatusCodes.NotFound)
> }
>
> val (_, host, port) = AkkaHttpTestUtils.temporaryServerHostnameAndPort()
> val bindingFuture = Http().bindAndHandle(mockRoutes, host, port)
>
> val request = HttpRequest(
>   HttpMethods.GET,
>   uri = s"http://${host}:${port}/test/proxy_chunked.do";,
>   protocol = HttpProtocols.`HTTP/1.0`
> )
>
> val futureByteString = Http().singleRequest(request).map { resp =>
>   println("response returned")
>   resp.entity.dataBytes
> } flatMap { source =>
>   source.runFold(ByteString.empty)((r, bs) => r ++ bs)
> }
> val byteString = Await.result(futureByteString, 10 seconds)
> byteString.utf8String shouldEqual (json)
>
>
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How do you determine/set the version of Akka used by the Scala REPL?

[Viktor Klang]

ActorSystem.Version

On Wed, Apr 6, 2016 at 6:04 AM, Mark Bower  wrote:

> I am running MacOSX10.8, Java1.8, Scala 2.11 and would like to run Akka
> 2.4 in the Scala REPL, but I cannot find out how to specific where the
> Scala REPL gets its Akka implementation. I can run simple Akka actors in
> the REPL, but more advanced topics (like remote applications) generate
> errors that indicate an older version of Akka is being used in the REPL,
> but I can't figure out which one. What I would like is the equivalent of a
> "java -version" in Unix, but for Akka in the Scala REPL. Thoughts?
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How do you determine/set the version of Akka used by the Scala REPL?

[Viktor Klang]

Check the classpath

-- 
Cheers,
√
On Apr 7, 2016 05:12, "Mark Bower"  wrote:

> Thank you, Victor!
>
> Where does the Scala REPL get it's Akka version, and how can that version
> be changed? I tried "System.getProperty("config.path")", but that returned
> "null" (?).
>
> Mark
>
> On Wed, Apr 6, 2016 at 3:00 AM, Viktor Klang 
> wrote:
>
>> ActorSystem.Version
>>
>> On Wed, Apr 6, 2016 at 6:04 AM, Mark Bower  wrote:
>>
>>> I am running MacOSX10.8, Java1.8, Scala 2.11 and would like to run Akka
>>> 2.4 in the Scala REPL, but I cannot find out how to specific where the
>>> Scala REPL gets its Akka implementation. I can run simple Akka actors in
>>> the REPL, but more advanced topics (like remote applications) generate
>>> errors that indicate an older version of Akka is being used in the REPL,
>>> but I can't figure out which one. What I would like is the equivalent of a
>>> "java -version" in Unix, but for Akka in the Scala REPL. Thoughts?
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >>>>>>>>>> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+unsubscr...@googlegroups.com.
>>> To post to this group, send email to akka-user@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Akka User List" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/akka-user/eGCZLpdiRac/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Cancel a Scheduler by terminating its ActorSystem

[Viktor Klang]

Or rather, if scheduled events are not cancelled hen they are no longer
needed, it will be a memory leak. Memory leaks are bad no matter if you
shut the actor system down or not :)

But to answer the question: shutting down the ActorSystem shuts down the
Scheduler.

On Thu, Apr 7, 2016 at 12:11 PM, Konrad Malawski 
wrote:

> Yes, although that's a bit like asking "can I stop a car by driving it
> into a tree?" :-)
>
> In general you should cancel scheduled events (schedule() returns a
> cancellable), instead
>
> --
> Cheers,
> Konrad 'ktoso’ Malawski
> Akka  @ Lightbend 
> 
>
> On 7 April 2016 at 12:09:59, Kayode Odeyemi (drey...@gmail.com) wrote:
>
>
>  Can I cancel a Scheduler by terminating its ActorSystem?
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Cancel a Scheduler by terminating its ActorSystem

[Viktor Klang]

That is surprising, indeed.
What was the cause for that, again?

On Thu, Apr 7, 2016 at 12:39 PM, Patrik Nordwall 
wrote:

> One gotcha with shutting down the actor system is that scheduled tasks
> will run (immediately) when the scheduler is shutdown.
>
> /Patrik
>
> tors 7 apr. 2016 kl. 12:14 skrev Viktor Klang :
>
>> Or rather, if scheduled events are not cancelled hen they are no longer
>> needed, it will be a memory leak. Memory leaks are bad no matter if you
>> shut the actor system down or not :)
>>
>> But to answer the question: shutting down the ActorSystem shuts down the
>> Scheduler.
>>
>> On Thu, Apr 7, 2016 at 12:11 PM, Konrad Malawski 
>> wrote:
>>
>>> Yes, although that's a bit like asking "can I stop a car by driving it
>>> into a tree?" :-)
>>>
>>> In general you should cancel scheduled events (schedule() returns a
>>> cancellable), instead
>>>
>>> --
>>> Cheers,
>>> Konrad 'ktoso’ Malawski
>>> <http://akka.io>Akka <http://akka.io> @ Lightbend <http://typesafe.com>
>>> <http://lightbend.com>
>>>
>>> On 7 April 2016 at 12:09:59, Kayode Odeyemi (drey...@gmail.com) wrote:
>>>
>>>
>>>  Can I cancel a Scheduler by terminating its ActorSystem?
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >>>>>>>>>> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+unsubscr...@googlegroups.com.
>>> To post to this group, send email to akka-user@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >>>>>>>>>> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+unsubscr...@googlegroups.com.
>>> To post to this group, send email to akka-user@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka HTTP bind exception on Windows

[Viktor Klang]

if (isWindows) selector.select(1) // :(

On Thu, Apr 7, 2016 at 2:57 PM, Endre Varga 
wrote:

> Oh, you are our savior! I am 99% sure that that is the solution we are
> looking after, thanks!
>
> -Endre
>
> On Thu, Apr 7, 2016 at 2:35 PM, Antti Nevala  wrote:
>
>> Hi,
>>
>> I'm not sure if this is related but found similar problem from another
>> project and workaround how to solve it:
>>
>> https://github.com/kaazing/nuklei/issues/20
>>
>> -Antti
>>
>> On Thursday, April 7, 2016 at 11:07:03 AM UTC+3, drewhk wrote:
>>>
>>> Hi,
>>>
>>>
>>> On Tue, Apr 5, 2016 at 8:40 PM, Michi 
>>> wrote:
>>>
 Hi,

 I think SO_REUSEADDR is enabled by default for Akka HTTP. At least it
 looks like that when I looked at the code. But even if it is disabled, the
 OS should not need ten minutes to release the socket.  Maybe I write a
 simple test program tomorrow that demonstrates the problem.

>>>
>>> Ok, this might be a bug then, please file a ticket. Strange that it
>>> works on non-Windows though :( (we have test for the behavior)
>>>
>>>

 My problem is that I am running out of time. Our customer is getting
 impatient and the server-side rest interface is just a small part of the
 application.

>>> I think it is probably best if I just use something else for now and go
 back to Akka HTTP if I have some more time. Can anyone suggest a
 lightweight, easy to use HTTP Server library for Java to provide a REST
 interface and deliver some HTML, CSS and Javascript files?

>>>
>>> You can use Play for example.
>>>
>>> -Endre
>>>
>>>

 Thanks,
 Michael

 On Tuesday, April 5, 2016 at 6:34:26 PM UTC+2, drewhk wrote:
>
> Have you tried to add a configuration (ServerSettings) when you bind
> the TCP which enables the ReuseAddress (
> http://doc.akka.io/api/akka/2.4.3/#akka.io.Inet$$SO$$ReuseAddress)
> option?
>
> -Endre
>
> On Tue, Apr 5, 2016 at 6:29 PM, Endre Varga 
> wrote:
>
>> But that code uses SO_REUSEADDR.
>>
>> -Endre
>>
>> On Tue, Apr 5, 2016 at 5:50 PM, Michi <
>> michael...@physik.tu-muenchen.de> wrote:
>>
>>> Hi Endre,
>>>
>>> I wrote a small test program that creates a socket channel, closes
>>> it and creates another one using the same port:
>>>
>>> import java.io.IOException;
>>> import java.net.InetSocketAddress;
>>> import java.net.SocketAddress;
>>> import java.net.StandardSocketOptions;
>>> import java.nio.channels.NetworkChannel;
>>> import java.nio.channels.ServerSocketChannel;
>>>
>>> public class Main {
>>>
>>> public static void main(String[] args) throws IOException, 
>>> InterruptedException {
>>> int port = Integer.parseInt(args[0]);
>>> SocketAddress addr = new InetSocketAddress(port);
>>> System.out.println("Binding server socket to " + addr);
>>> ServerSocketChannel s = ServerSocketChannel.open();
>>> s.setOption(StandardSocketOptions.SO_REUSEADDR, true);
>>> System.out.println("Created server socket channel " + s);
>>> NetworkChannel c = s.bind(addr);
>>> System.out.println("Bound server socket to " + addr);
>>> s.close();
>>> System.out.println("Closed channel: " + s);
>>> Thread.sleep(1000);
>>> System.out.println("Binding server socket to " + addr);
>>> ServerSocketChannel s2 = ServerSocketChannel.open();
>>> s2.setOption(StandardSocketOptions.SO_REUSEADDR, true);
>>> System.out.println("Created server socket channel " + s2);
>>> NetworkChannel c2 = s2.bind(addr);
>>> System.out.println("Bound server socket to " + addr);
>>> s2.close();
>>> System.out.println("Closed channel: " + s2);
>>>
>>> }
>>> }
>>>
>>> It works perfectly both on Linux and on Windows. Here is the output on 
>>> Windows:
>>>
>>> C:\Users\Michael\Desktop>java Main 
>>> Binding server socket to 0.0.0.0/0.0.0.0:
>>> Created server socket channel 
>>> sun.nio.ch.ServerSocketChannelImpl[unbound]
>>> Bound server socket to 0.0.0.0/0.0.0.0:
>>> Closed channel: sun.nio.ch.ServerSocketChannelImpl[closed]
>>> Binding server socket to 0.0.0.0/0.0.0.0:
>>> Created server socket channel 
>>> sun.nio.ch.ServerSocketChannelImpl[unbound]
>>> Bound server socket to 0.0.0.0/0.0.0.0:
>>> Closed channel: sun.nio.ch.ServerSocketChannelImpl[closed]
>>>
>>>
>>> There is also AsynchronousServerSocketChannel, but I doubt this
>>> makes a big difference. I really don't think that NIO does not properly
>>> unbind sockets on Windows. There might be a small delay, but certainly 
>>> not
>>> 10 Minutes! As far as I know StandardSocketOptions.SO_REUSEADDR
>>> should allow to reuse sockets tha

Re: [akka-user] Cancel a Scheduler by terminating its ActorSystem

[Viktor Klang]

Hmmm, since that mechanism is completely internal, perhaps we could solve
that discretely and remove that run-all-on-shutdown.

On Thu, Apr 7, 2016 at 4:17 PM, Patrik Nordwall 
wrote:

>
>
> On Thu, Apr 7, 2016 at 12:46 PM, Viktor Klang 
> wrote:
>
>> That is surprising, indeed.
>> What was the cause for that, again?
>>
>
> The original reason is for shutting down the dispatchers, I think.
>
>
>>
>> On Thu, Apr 7, 2016 at 12:39 PM, Patrik Nordwall <
>> patrik.nordw...@gmail.com> wrote:
>>
>>> One gotcha with shutting down the actor system is that scheduled tasks
>>> will run (immediately) when the scheduler is shutdown.
>>>
>>> /Patrik
>>>
>>> tors 7 apr. 2016 kl. 12:14 skrev Viktor Klang :
>>>
>>>> Or rather, if scheduled events are not cancelled hen they are no longer
>>>> needed, it will be a memory leak. Memory leaks are bad no matter if you
>>>> shut the actor system down or not :)
>>>>
>>>> But to answer the question: shutting down the ActorSystem shuts down
>>>> the Scheduler.
>>>>
>>>> On Thu, Apr 7, 2016 at 12:11 PM, Konrad Malawski 
>>>> wrote:
>>>>
>>>>> Yes, although that's a bit like asking "can I stop a car by driving it
>>>>> into a tree?" :-)
>>>>>
>>>>> In general you should cancel scheduled events (schedule() returns a
>>>>> cancellable), instead
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Konrad 'ktoso’ Malawski
>>>>> <http://akka.io>Akka <http://akka.io> @ Lightbend
>>>>> <http://typesafe.com>
>>>>> <http://lightbend.com>
>>>>>
>>>>> On 7 April 2016 at 12:09:59, Kayode Odeyemi (drey...@gmail.com) wrote:
>>>>>
>>>>>
>>>>>  Can I cancel a Scheduler by terminating its ActorSystem?
>>>>> --
>>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>> >>>>>>>>>> Check the FAQ:
>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>> >>>>>>>>>> Search the archives:
>>>>> https://groups.google.com/group/akka-user
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Akka User List" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to akka-user+unsubscr...@googlegroups.com.
>>>>> To post to this group, send email to akka-user@googlegroups.com.
>>>>> Visit this group at https://groups.google.com/group/akka-user.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>> --
>>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>> >>>>>>>>>> Check the FAQ:
>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>> >>>>>>>>>> Search the archives:
>>>>> https://groups.google.com/group/akka-user
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Akka User List" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to akka-user+unsubscr...@googlegroups.com.
>>>>> To post to this group, send email to akka-user@googlegroups.com.
>>>>> Visit this group at https://groups.google.com/group/akka-user.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> √
>>>>
>>>> --
>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>> >>>>>>>>>> Check the FAQ:
>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>> >>>>>>>>>> Search the archives:
>>>> https://groups.google.com/group/akka-user
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Akka User List" group.
>>>> To unsubscribe from this group and stop 

Re: [akka-user] Cancel a Scheduler by terminating its ActorSystem

[Viktor Klang]

https://github.com/akka/akka/issues/20256

On Thu, Apr 7, 2016 at 5:18 PM, Patrik Nordwall 
wrote:

> I agree, we have had that conclusion several times, but never fixed it. An
> issue is a good start, please.
>
> tors 7 apr. 2016 kl. 16:20 skrev Viktor Klang :
>
>> Hmmm, since that mechanism is completely internal, perhaps we could solve
>> that discretely and remove that run-all-on-shutdown.
>>
>> On Thu, Apr 7, 2016 at 4:17 PM, Patrik Nordwall <
>> patrik.nordw...@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Apr 7, 2016 at 12:46 PM, Viktor Klang 
>>> wrote:
>>>
>>>> That is surprising, indeed.
>>>> What was the cause for that, again?
>>>>
>>>
>>> The original reason is for shutting down the dispatchers, I think.
>>>
>>>
>>>>
>>>> On Thu, Apr 7, 2016 at 12:39 PM, Patrik Nordwall <
>>>> patrik.nordw...@gmail.com> wrote:
>>>>
>>>>> One gotcha with shutting down the actor system is that scheduled tasks
>>>>> will run (immediately) when the scheduler is shutdown.
>>>>>
>>>>> /Patrik
>>>>>
>>>>> tors 7 apr. 2016 kl. 12:14 skrev Viktor Klang >>>> >:
>>>>>
>>>>>> Or rather, if scheduled events are not cancelled hen they are no
>>>>>> longer needed, it will be a memory leak. Memory leaks are bad no matter 
>>>>>> if
>>>>>> you shut the actor system down or not :)
>>>>>>
>>>>>> But to answer the question: shutting down the ActorSystem shuts down
>>>>>> the Scheduler.
>>>>>>
>>>>>> On Thu, Apr 7, 2016 at 12:11 PM, Konrad Malawski >>>>> > wrote:
>>>>>>
>>>>>>> Yes, although that's a bit like asking "can I stop a car by driving
>>>>>>> it into a tree?" :-)
>>>>>>>
>>>>>>> In general you should cancel scheduled events (schedule() returns a
>>>>>>> cancellable), instead
>>>>>>>
>>>>>>> --
>>>>>>> Cheers,
>>>>>>> Konrad 'ktoso’ Malawski
>>>>>>> <http://akka.io>Akka <http://akka.io> @ Lightbend
>>>>>>> <http://typesafe.com>
>>>>>>> <http://lightbend.com>
>>>>>>>
>>>>>>> On 7 April 2016 at 12:09:59, Kayode Odeyemi (drey...@gmail.com)
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>  Can I cancel a Scheduler by terminating its ActorSystem?
>>>>>>> --
>>>>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>> >>>>>>>>>> Check the FAQ:
>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>> >>>>>>>>>> Search the archives:
>>>>>>> https://groups.google.com/group/akka-user
>>>>>>> ---
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "Akka User List" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to akka-user+unsubscr...@googlegroups.com.
>>>>>>> To post to this group, send email to akka-user@googlegroups.com.
>>>>>>> Visit this group at https://groups.google.com/group/akka-user.
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>> --
>>>>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>> >>>>>>>>>> Check the FAQ:
>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>> >>>>>>>>>> Search the archives:
>>>>>>> https://groups.google.com/group/akka-user
>>>>>>> ---
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "Akka User List" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to akka-u

Re: [akka-user] Akka HTTP bind exception on Windows

[Viktor Klang]

And to clarify, by "we", anyone reading this or the Issue is eligible for
fixing it :)

On Fri, Apr 8, 2016 at 10:11 AM, Endre Varga 
wrote:

> Hi Michael,
>
> No, Akka HTTP uses Akka's own TCP stack, we don't use Netty there. I guess
> we should just fix this in the next release.
>
> -Endre
>
> On Fri, Apr 8, 2016 at 8:47 AM, Michi <
> michael.tha...@physik.tu-muenchen.de> wrote:
>
>> Hi,
>>
>> is Akka HTTP still using Netty? To solve the problem I built a small HTTP
>> server using Netty that just creates a Akka HttpRequest from a Netty
>> HttpRequest. This is a bit of a hack but I needed a quick solution because
>> our customer gets really impatient and I just needed something that works
>> quickly. I did not get bind exceptions starting / stopping Netty on
>> Windows. I use the following code (shutdown code from Netty in Action book):
>>
>>   private val bossGroup = new NioEventLoopGroup(1)
>>   private val workerGroup = new NioEventLoopGroup()
>>   private val bootstrap = new ServerBootstrap()
>>   bootstrap.group(bossGroup,
>> workerGroup).channel(classOf[NioServerSocketChannel])
>> .option(ChannelOption.SO_BACKLOG.asInstanceOf[ChannelOption[Any]],
>> 200)
>>
>> .childOption(ChannelOption.ALLOCATOR.asInstanceOf[ChannelOption[Any]],
>> PooledByteBufAllocator.DEFAULT)
>> .childHandler(new ChannelInitializer[SocketChannel] {
>> override def initChannel(ch: SocketChannel): Unit = {
>>   val p = ch.pipeline()
>>   p.addLast("decoder", new HttpRequestDecoder)
>>   p.addLast("encoder", new HttpResponseEncoder)
>>   p.addLast("aggregator", new HttpObjectAggregator(1048576))
>>   p.addLast("handler", new HttpRequestHandler(modules))
>> }
>>   })
>>
>>   logger.info("Trying to start netty on " + interface + ":" + port)
>>   private val serverChannelFuture = bootstrap.bind(interface, port)
>>   serverChannelFuture.addListener(new ChannelFutureListener {
>> override def operationComplete(future: ChannelFuture): Unit = {
>>   if (serverChannelFuture.isSuccess) {
>> logger.info("HTTP server bound to " + interface + ":" + port)
>>   } else {
>> logger.info("Could not bind HTTP server to " + interface + ":" +
>> port, serverChannelFuture.cause())
>>   }
>> }
>>   })
>>
>> override protected def dispose(): Unit = {
>> logger.info("Trying to stop HTTP server")
>> bossGroup.shutdownGracefully().sync()
>> workerGroup.shutdownGracefully().sync()
>> logger.info("Stopped boss and worker groups")
>> bossGroup.terminationFuture().sync()
>> workerGroup.terminationFuture().sync()
>> logger.info("Terminated boss and worker groups")
>>   }
>>
>> Sorry I didn't have any time to figure out what the problem is. I hope I
>> can get rid of my hack when the next version of Akka is released. Looking
>> at several Http frameworks and hacking my own Netty based solution makes me
>> realize even more how nice Akka Http actually is.
>>
>> Thanks for the great work,
>> Michael
>>
>>
>> On Thursday, April 7, 2016 at 9:15:58 PM UTC+2, Antti Nevala wrote:
>>>
>>> No problem, glad to help you.
>>>
>>> -Antti
>>>
>>> On Thursday, April 7, 2016 at 3:57:09 PM UTC+3, drewhk wrote:

 Oh, you are our savior! I am 99% sure that that is the solution we are
 looking after, thanks!

 -Endre

 On Thu, Apr 7, 2016 at 2:35 PM, Antti Nevala  wrote:

> Hi,
>
> I'm not sure if this is related but found similar problem from another
> project and workaround how to solve it:
>
> https://github.com/kaazing/nuklei/issues/20
>
> -Antti
>
> On Thursday, April 7, 2016 at 11:07:03 AM UTC+3, drewhk wrote:
>>
>> Hi,
>>
>>
>> On Tue, Apr 5, 2016 at 8:40 PM, Michi <
>> michael...@physik.tu-muenchen.de> wrote:
>>
>>> Hi,
>>>
>>> I think SO_REUSEADDR is enabled by default for Akka HTTP. At least
>>> it looks like that when I looked at the code. But even if it is 
>>> disabled,
>>> the OS should not need ten minutes to release the socket.  Maybe I 
>>> write a
>>> simple test program tomorrow that demonstrates the problem.
>>>
>>
>> Ok, this might be a bug then, please file a ticket. Strange that it
>> works on non-Windows though :( (we have test for the behavior)
>>
>>
>>>
>>> My problem is that I am running out of time. Our customer is getting
>>> impatient and the server-side rest interface is just a small part of the
>>> application.
>>>
>> I think it is probably best if I just use something else for now and
>>> go back to Akka HTTP if I have some more time. Can anyone suggest a
>>> lightweight, easy to use HTTP Server library for Java to provide a REST
>>> interface and deliver some HTML, CSS and Javascript files?
>>>
>>
>> You can use Play for example.
>>
>> -Endre
>>
>>
>>>
>>> Thanks,
>>> Michael
>>>
>>> On Tuesday, April 5, 2016 at 6