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 are subscribed to the Google
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
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 List group.
To unsubscribe from
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.io/docs/
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
On Thursday, April 17, 2014 11:30:22 AM UTC+4, rkuhn wrote:
e also have prepared an Activator
templatehttps://typesafe.com/activator/template/akka-stream-scala with
which you can start exploring the
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/current/additional/faq.html
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: https://groups.google.com/group/akka-user
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
---
You received this message because you
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
Search the archives:
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 message because you are subscribed to
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 archives:
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 =
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
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 have
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:
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
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,
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.google.com/group/akka-user
---
You
Дмитрий,
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:
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
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
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
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:
>>
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:
>>
or Akka Http transport, such as HTTP/2?
>
> fre 10 juni 2016 kl. 19:10 skrev Andrew Gaydenko <andrew@gmail.com
> >:
>
>> Patrik,
>>
>> In the Aeron-as-a-transport context (UDP) what is the akka-http's
>> transport (TCP) planned future?
>>
>>
>
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
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 <andrew@gmail.com
>
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
>
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
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,
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
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
---
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
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?
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
---
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
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:
>>
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
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
>>
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)
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
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 -
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
)(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
>>
&
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
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/
--
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:
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
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:
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
51 matches
Mail list logo
