[akka-user] Re: Can't execute more than 4 requests in parallel

May be without client ? -- >> 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

[akka-user] Re: [ANNOUNCE] Announcing the new Akka Team Blog (Let it Crash!)

Thanks! At that moment for some reason Firefox hasn't found the refs. Now it does. Sorry for noise. -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> Search the archives: htt

[akka-user] Re: [ANNOUNCE] Announcing the new Akka Team Blog (Let it Crash!)

Great! Any chance for RSS? -- >> 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 becau

Re: [akka-user] Re: ANNOUNCE: New Remoting Milestone 2

ka-streams which in turn uses Akka >IO for the TCP part—no Netty anywhere >- akka-remote has nothing to do with Akka IO, akka-stream, or akka-http > > > Regards, > > Roland > > 11 juni 2016 kl. 12:58 skrev Andrew Gaydenko >: > > Patrik, sorry I wasn't

Re: [akka-user] Re: ANNOUNCE: New Remoting Milestone 2

of any plans for Akka Http transport, such as HTTP/2? > > fre 10 juni 2016 kl. 19:10 skrev Andrew Gaydenko >: > >> Patrik, >> >> In the Aeron-as-a-transport context (UDP) what is the akka-http's >> transport (TCP) planned future? >> >> >> On

[akka-user] Re: ANNOUNCE: New Remoting Milestone 2

Patrik, In the Aeron-as-a-transport context (UDP) what is the akka-http's transport (TCP) planned future? On Friday, June 10, 2016 at 6:46:09 PM UTC+3, Patrik Nordwall wrote: > > Dear hakkers, > > We’re excited to announce that we have released the second development > milestone of the new Akka

[akka-user] Re: Akka HTTP performance for short lived connections

Adam, thanks! Very informative. I also have found handy to use almost empty response to estimate the whole request-response chain itself (starting from now abandoned tiscaf [1] and rising rps up to almost 90K on humble workstation :) ). [1] http://gaydenko.com/scala/tiscaf/httpd/ --

[akka-user] Re: Akka HTTP performance for short lived connections

Adam, just curious, can you, please, supply some example ApacheBench output? -- >> 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/gr

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

Giovanni, hi! With some piece of stubbornness :) I (guess) have found a way with Source.last(): def sinkFoldM[U, T](zero: U)(f: (U, T) ⇒ Future[U]): Sink[T, Future[U]] = Sink.fromGraph { val last = Sink.last[U] GraphDSL.create(last) { implicit b => last => import GraphDSL.Impli

Re: [akka-user] Re: [2.5-Scala] How to cleanup Sink/Source?

Or, if to reformulate, how does transparent stage look? -- >> 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 --- Yo

Re: [akka-user] Re: [2.5-Scala] How to cleanup Sink/Source?

Johan, hi! Sorry, haven't grokked exactly :) Do I understand correctly, in code above I must eliminate all complete()/cancel() calls, instead just bothering about own clean up only? In other words, are `finish` events propagating to other stages independently these my stage's in/out handlers?

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

On Wednesday, March 9, 2016 at 1:20:37 PM UTC+3, Giovanni Alberto Caporaletti wrote: > > It would fail with an empty stream. You can use lastOption but you would > need to map over the materialized value thus needing an execution context > outside the stream context. > Oh.. Yes! Thanks for poin

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

Giovanni, I mean your last suggestion with custom stage. -- >> 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 --- Y

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

Giovanni, hi! What do you think about replacing val sink = Sink.fold(zero)(Keep.right[U, U]) with val sink = Sink.last[U] ? -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html

[akka-user] Re: change of Tech Lead

Roland, Thanks for your help here, in the group! - for some magic reason you are just the best in understanding my ugly, vague questions. Good luck! -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/

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

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 o

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

On Sunday, March 6, 2016 at 2:28:22 AM UTC+3, Giovanni Alberto Caporaletti 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 :) > Giovanni, thanks for this graph - I

[akka-user] Re: [2.5-Scala] How to cleanup Sink/Source?

Or - must the last method be override def onDownstreamFinish(): Unit = { cancel(in) onDownFinish } ? -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >>

[akka-user] Re: [2.5-Scala] How to cleanup Sink/Source?

At the moment I have got this approach. Let's define a stage: class OnFinish[A] extends GraphStage[FlowShape[A, A]] { def onUpFinish: Unit = {} def onDownFinish: Unit = {} val in = Inlet[A]("onFinish.in") val out = Outlet[A]("onFinish.out") override val shape = FlowShape.of(in, out)

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

> 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 U

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

On Saturday, March 5, 2016 at 11:52:06 PM UTC+3, 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. > Roland, hi! Thanks fo

[akka-user] [2.5-Scala] How to cleanup Sink/Source?

HI! I'm playing with Play projects migrating them to v.2.5.0. Play's Iteratee and Enumerator have got some means to cleanup streams (Input.EOF and onDoneEnumeratiing() appropriately). So, what is that obvious way :) to cleanup sources and sinks in Akka Stream? -- >> Read the docs

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

(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

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

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

Re: [akka-user] Re: ANNOUNCE: Akka Streams & HTTP 2.0.2 Released!

On Friday, January 15, 2016 at 9:15:49 AM UTC+3, Patrik Nordwall wrote: > > Play is compatible with Akka 2.4 and Akka Streams 1.0. There will soon be > a new Play 2.5 milestone that is compatible with Akka Stream 2.0. > > If you have found something that Play is not compatible with Akka 2.4 we >

Re: [akka-user] Re: ANNOUNCE: Akka Streams & HTTP 2.0.2 Released!

On Friday, January 15, 2016 at 9:15:49 AM UTC+3, Patrik Nordwall wrote: > > Play is compatible with Akka 2.4 and Akka Streams 1.0. There will soon be > a new Play 2.5 milestone that is compatible with Akka Stream 2.0. > I mean context when streams (2.x at the momemnt) are used in their own, rega

[akka-user] Re: ANNOUNCE: Akka Streams & HTTP 2.0.2 Released!

On Thursday, January 14, 2016 at 11:44:37 PM UTC+3, Konrad Malawski wrote: > > Meanwhile, we have moved all new Streams & HTTP development to the master > branch, which means that these, as previously announced, will very soon > become part of Akka 2.4 > How fast are you going to be? The thing i

[akka-user] Re: Akka Stream and Http 2.0-M1 Released!

Konrad, hi! Thanks for the explanation, now i see the M1 is more interesting (for me) than it can be visible at first :) I remember the Play team intention to (officially, not experimental) switch to Akka Stream from Iteratees only when performance will be comparable. So, that future is moving

[akka-user] Re: Akka Stream and Http 2.0-M1 Released!

Great! On Friday, November 6, 2015 at 4:19:49 PM UTC+3, Martynas Mickevičius wrote: > > ... This is also the feature that will increase performance for various > use cases, including HTTP. > Is it just the first step, or significant part of the way, or almost the whole way to make Akka HTTP com

[akka-user] filePath + encoding = Source[Char, _] - How to?

Hi! In fact the use case in hands demands Source[String, _], where element is a string with length limited by given max. But is can be got from char sink with grouped stage. -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/doc

Re: [akka-user] not-experimental streams?

On Tuesday, September 22, 2015 at 12:57:19 PM UTC+3, Patrik Nordwall wrote: > > We are confident that Akka Streams will be successful. > Great, thanks for the clarification! > -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/do

[akka-user] not-experimental streams?

Hi! Why streams are still named as experimental? Is there still an opportunity current streams API will share pipelines' destiny? :) -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >>>

[akka-user] Re: The best ways to resolve future inside an actor?

Дмитрий, In this topic https://groups.google.com/forum/#!folder/current/akka-user/R1ZxPKlp1fI *Michael Frank* has suggested an idea, I have implemented it, and it does work at my use case as expected. Probably, you will get something useful there also :) -- >> Read the docs: htt

Re: [akka-user] Re: Piping + gracefull shutdown: is it possible?

Michael, I have implemented the idea in my context. Yes, it does work. Thanks again! -- >> 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.goog

Re: [akka-user] Re: Piping + gracefull shutdown: is it possible?

On Monday, May 18, 2015 at 9:33:28 PM UTC+3, Michael Frank wrote: > > i usually solve this by map()ing the future to some request id that i > generate. for example (written on the spot, may not compile) > Michael, Aha, I see, it's very smart. Will try. Thanks! -- >> Read the docs

Re: [akka-user] Re: Piping + gracefull shutdown: is it possible?

On Monday, May 18, 2015 at 7:51:31 PM UTC+3, Michael Frank wrote: > > How about piping the result of the future back to actor1, then send the > result to actor2? you can prune the completed future in actor1 when it > receives the result. > Michael, how does actor1 discover that future returned

[akka-user] Re: Piping + gracefull shutdown: is it possible?

Magnus, hi! Thanks for the suggestions! On Monday, May 18, 2015 at 3:57:00 PM UTC+3, Magnus Andersson wrote: > >1. Keep track of running futures in your actor1 in a var. When your >actor enters poststop you can await the completion of all referenced >futures. You probably would ha

[akka-user] Piping + gracefull shutdown: is it possible?

HI! Say, we have actor1 calling a function on received message returning Future[T]. Then this actor1 pipes the future to actor2. And the last one does some final work on T. I have not found a way to gracefully shutdown such actor system (say, with attached shutdown hook for daemonic actor

Re: [akka-user] Re: The best ways to resolve future inside an actor?

OK, let's take a suggestion and use piping. So, say, we have actor1 (for example, with RoundRobin(1)). calling a function on received message returning Future, and this actor1 pipes the future to actor2 (for example, with RoundRobin(5)). And the last one does some final work. I have not found a

Re: [akka-user] Re: The best ways to resolve future inside an actor?

Дмитрий. Will it look simpler would we add dedicated actor to pipe to? I have tried this way. The problem at my case is a function returns Future limited with timeout, and time starts to tick too early resulting in multiple timeouts (while the dumb way with awaiting doesn't result in any errors

Re: [akka-user] Re: The best ways to resolve future inside an actor?

On Thursday, May 14, 2015 at 8:46:27 PM UTC+3, Patrik Nordwall wrote: > > If there are no relationship (no ordering) between the future result and > other incoming messages you can just use pipe, without stash. > Let's assume at the moment we have: def receive = { case Msg(data) => def job

Re: [akka-user] Re: The best ways to resolve future inside an actor?

On Thursday, May 14, 2015 at 8:04:50 PM UTC+3, √ wrote: > > What if it never completes? > Timeout is acceptable. -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> Search the a

Re: [akka-user] Re: The best ways to resolve future inside an actor?

Sequence order isn't a problem. RondRobinPool(1) here isn't more rather just a limiting CPU consumption to a single core. As at the first message in the topic, the problem is to gracefully call function returning Future inside a message handler. We don't want answering to sender, don't want to

Re: [akka-user] Re: The best ways to resolve future inside an actor?

On Thursday, May 14, 2015 at 1:41:30 PM UTC+3, rrodseth wrote: > > Have you looked at the pipeTo pattern and the Stash trait? I'm not sure > why a combination of pipeTo and become() with Stash wouldn't work. > What is that relation between stashing and piping with resolving a future? Can you, pl

[akka-user] Re: The best ways to resolve future inside an actor?

It's funny just now I have met the same situation! :) More strictly, my case is even simpler as far as an actor hasn't got state. I also use RoundRobinPool(1) to force serialization. I have tried just to use Await.result(), and it seems to work . To call function returning Future I use contex

Re: [akka-user] draining daemon system actors' queues on shutdown

Konrad, great, thanks! - will dig in... -- >> 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

[akka-user] Re: draining daemon system actors' queues on shutdown

I must clarify saying "draining" I mean giving to all system's actors some duration to process all already sent messages. -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> Sea

[akka-user] draining daemon system actors' queues on shutdown

How to drain daemon system actors' queues on system exit? -- >> 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] There are now akka-stream in master. Why?

On Sunday, June 1, 2014 7:42:49 PM UTC+4, Konrad Malawski wrote: > > Yes, perhaps I should explain our current workflow with these branches > actually: > > master will eventually become akka 2.4.x > > release-2.3 will eventually become akka 2.3.4 (and 2.3.5 if it’s needed > etc). > > release-2.3-

Re: [akka-user] There are now akka-stream in master. Why?

Aha, thanks, I see, it's just a way to organize branches. -- >> 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 ---

[akka-user] Re: There are now akka-stream in master. Why?

Sorry, my mistake, I mean "There are *no* akka-stream...". I haven't found a way to edit the subject. -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> Search the archives: ht

[akka-user] There are now akka-stream in master. Why?

I just have noticed master hasn't anymore akka-stream subproject. Does it mean akka (and Scala in whole) reactive streaming is preparing for the next reincarnation? :) -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/

[akka-user] Re: Akka Streams Preview is Available

On Thursday, April 17, 2014 11:30:22 AM UTC+4, rkuhn wrote: > > e also have prepared an Activator > template with > which you can start exploring the > API

Re: [akka-dev] Re: [akka-user] Akka IO Pipelines going away

On Tuesday, April 8, 2014 6:27:44 PM UTC+4, √ wrote: > > Well said, Roland. > Being one of removal-affected Akka users, at the moment I have just moved to netty.io during a couple of days (custom protocol with ~ dozen messages). Knowing main pipeline architecture ideas it was really easy migrat

[akka-user] Re: Has anything been published about the Reactive Streams design?

There were (now deprecated) pipelines borrowed from spray https://groups.google.com/forum/#!starred/akka-user/8fZ75MlVEYc So the team is preparing something new and tasty for April. You are the second in the waiting queue as far as I'm the first :) -- >> Read the docs: http://akka

Re: [akka-user] Akka IO Pipelines going away

Great, I'll be :) -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: http://akka.io/faq/ >> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User Lis

Re: [akka-user] Akka IO Pipelines going away

On Wednesday, January 22, 2014 11:21:46 AM UTC+4, rkuhn wrote: > > We know that people have been running their business on a 1.0 milestone of > Akka, or used the experimental Cluster successfully, and this has maybe led > to the expectation that even our experiments are highly reliable—which we

[akka-user] Re: What happend to the IO stack between 2.3M2 and 2.3RC1 ???

https://groups.google.com/forum/#!topic/akka-user/8fZ75MlVEYc On Tuesday, January 21, 2014 8:15:38 PM UTC+4, Cédric Munger wrote: > > Hello, > > I've started to migrate from 2.3.M2 API to the RC1 and I have some very > bad surprises on the IO API side. > It looks like you've removed a LOT of thin

[akka-user] Re: ANNOUNCE: Akka 2.3.0-RC1 (RELEASE CANDIDATE)

So 2.3.0 will be released without IO at all. Have I missed something? -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: http://akka.io/faq/ >> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you

[akka-user] Re: Akka IO Pipelines going away

Roland, I have a part of some big project based on pipelines. Is it possible to roughly denote that time points of pipelines removing and new streams introducing? Will there be some time frame these technologies be existing in parallel? - to have an opportunity to smoothly switch a code base: p