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
> s
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
speakin
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
>>
>> --
>> Cheers
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 process the messages eq
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, Octobe
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 complete, but they are
> ha
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 Oct 6, 2016 09:49, "Alexan
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 Lukyanchikov" <
> alexande
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 them
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) {
system.scheduler().sched
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] [System-ak
13 matches
Mail list logo