For more information, I give here versions I test with.
ubuntu 14.04, scala 2.11.8, oracle jdk 1.8
akka-http: 2.4.11
spray: 1.3.1 with akka 2.3.6
On Thursday, October 6, 2016 at 10:26:48 PM UTC+3, Olga Gorun wrote:
>
> Hi Christian. Thank you for response. I checked that equal Xms/Xmx both
>
Hi Christian. Thank you for response. I checked that equal Xms/Xmx both set
to more than enough memory (4GB while used heap is not more than 1.5GB
during load test with or without explicitly defined memory) don't
influence results. I'll try other JVM settings you propose. But generally
garbadge collection I guess. also I didn't see if you've set Xms/Xmx you
should set them equal. And also try the following: -XX:+UseNUMA
-XX:+UseG1GC -XX:+AlwaysPreTouch -XX:+PerfDisableSharedMem
-XX:+ParallelRefProcEnabled paramters, not all of them will be helpful, but
you should try some of
happy hakking!
On Thu, Oct 6, 2016 at 6:19 PM, Alexander Lukyanchikov <
alexanderlukyanchi...@gmail.com> wrote:
> Yes, it is. Now it's clear. Thank you.
>
> On Thursday, October 6, 2016 at 6:04:22 PM UTC+3, √ wrote:
>>
>> My guess is that your default dispatcher has ~30 threads
>>
>> --
>>
Yes, it is. Now it's clear. Thank you.
On Thursday, October 6, 2016 at 6:04:22 PM UTC+3, √ wrote:
>
> My guess is that your default dispatcher has ~30 threads
>
> --
> Cheers,
> √
>
> On Oct 6, 2016 10:03, "Viktor Klang"
> wrote:
>
>> Of course it builds up if you can't
I continue playing with given example projects and see strange results. If
I increase string length of static response from 7 to 2490 characters
throughput is reduced to ~24K rps for both spray and akka-http.
Does anybody else see such results? How can they be explained?
On Wednesday,
Thanks Tal.
On Thu, Oct 6, 2016 at 2:50 AM, Tal Pressman wrote:
> Hi,
>
> The type provided to Source.actorRef is the type of the messages emitted
> from the Actor (WorkResult in your case). Success messages can be *sent
> to the actor* in order to cause the stream to
That problem does not happen in Akka Streams, it explicitly manages
flow-control by the way.
On Thu, Oct 6, 2016 at 10:03 AM, Viktor Klang
wrote:
> Of course it builds up if you can't process the messages equal-or-faster
> than you get them?
>
> --
> Cheers,
> √
>
> On
Of course it builds up if you can't process the messages equal-or-faster
than you get them?
--
Cheers,
√
On Oct 6, 2016 09:49, "Alexander Lukyanchikov" <
alexanderlukyanchi...@gmail.com> wrote:
>
> Sorry guys, quick update:
>
> Time interval actually affects the situation: if actor job time <
My guess is that your default dispatcher has ~30 threads
--
Cheers,
√
On Oct 6, 2016 10:03, "Viktor Klang" wrote:
> Of course it builds up if you can't process the messages equal-or-faster
> than you get them?
>
> --
> Cheers,
> √
>
> On Oct 6, 2016 09:49, "Alexander
Sorry guys, quick update:
Time interval actually affects the situation: if actor job time < scheduler
interval, everything is good, no matter how many actors we have.
When actor job time > scheduler interval and ACTOR_COUNT < 30, envelopes
filling up and not garbage collected (millions of
Hi everyone,
We have a pretty weird memory leak - akka.dispatch.Envelope instances are
not garbage collected.
Here is the code:
List actors = new ArrayList<>(); for (int i = 0; i < ACTOR_COUNT;
i++) { actors.add(system.actorOf(...)); } for (ActorRef actor : actors) {
As Rob suggested, please have it in your classpath, if you are using maven
it should be in " src/main/resources"
On Wednesday, October 5, 2016 at 12:53:22 PM UTC-4, Luigi D'Onofrio wrote:
>
> I have it in *myproject/src/* directory but i got error:
>
> [ERROR] [10/05/2016 17:21:33.097]
Hi,
The type provided to Source.actorRef is the type of the messages emitted
from the Actor (WorkResult in your case). Success messages can be *sent to
the actor* in order to cause the stream to complete, but they are handled
separately and aren't actually emitted to the stream.
As for
14 matches
Mail list logo