Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 08:34
    jiyeongj commented #4083
  • 08:33
    jiyeongj commented #4083
  • 08:33
    jiyeongj commented #4083
  • 07:57

    dependabot-preview[bot] on nuget

    (compare)

  • 07:57

    dependabot-preview[bot] on dev

    Bump MongoDB.Driver from 2.9.1 … (compare)

  • 07:57
    dependabot-preview[bot] closed #104
  • 07:52
    dependabot-preview[bot] synchronize #104
  • 07:52

    dependabot-preview[bot] on nuget

    Bump MongoDB.Driver from 2.9.1 … (compare)

  • 07:52
    dependabot-preview[bot] edited #104
  • 07:51
    dependabot-preview[bot] edited #104
  • 07:51
    dependabot-preview[bot] edited #104
  • 07:51
    Aaronontheweb commented #104
  • 07:43

    dependabot-preview[bot] on nuget

    (compare)

  • 07:43

    dependabot-preview[bot] on dev

    Bump Microsoft.NET.Test.Sdk fro… (compare)

  • 07:43
    dependabot-preview[bot] closed #102
  • 07:43
    Aaronontheweb commented #102
  • 06:35

    dependabot-preview[bot] on nuget

    (compare)

  • 06:35
    dependabot-preview[bot] closed #103
  • 06:35
    dependabot-preview[bot] commented #103
  • 06:35
    dependabot-preview[bot] labeled #104
Bart de Boer
@boekabart
@Aaronontheweb any idea what those threads are actually waiting for?
Aaron Stannard
@Aaronontheweb
@boekabart that's what the ForkJoinDispatcher runs on top of
as for why they're all waiting - should be because they're expecting work
however, if you're terminated the actor system by then
and they still aren't shutdown
it means we're not properly disposing of them
Bart de Boer
@boekabart
according to the log, remoting is correctly shut down
Aaron Stannard
@Aaronontheweb
ok
that's a bug then
I'll file an issue for it
need to dispose all dispatchers on shutdown
thanks for reporting it Bart
Bart de Boer
@boekabart
It seems to only happen when using topshelf
Aaron Stannard
@Aaronontheweb
hmmm...
is it possible that with the way Topshself is configured in your instance
that those threads are running in the foreground?
and not the background?\
latter being the default
hi @tjaskula
Bart de Boer
@boekabart
I haven't changed any dispatcher configuration
hold on, I did create dispatcher in foreground, in fact, for some system tasks
Aaron Stannard
@Aaronontheweb
I use Topshelf too
ohhhhhhhhh
that would do it
Bart de Boer
@boekabart
isn't that just thread prio?
Aaron Stannard
@Aaronontheweb
nah
the foreground threads are meant to be literally used for user-facing elements
so like the UI thread in an app
Bart de Boer
@boekabart
let me quickly test that theory
Aaron Stannard
@Aaronontheweb
or the thread that owns the console UI
I don't have the details 100% clear off the top of my head anymore
but basically a process can't exit until its foreground threads are joined
Bart de Boer
@boekabart
Yeah, that fixed it.
still a normal console app (not topshelf) didn't suffer from it, it seems. But that one also did less work on that threadpool, so apples and oranges
Aaron Stannard
@Aaronontheweb
akkadotnet/akka.net#2028
just created that
foreground vs. background doesn't change priority
it's the exit behavior that gets affected
Bart de Boer
@boekabart
ok, clear! Re priority btw, again/still suffering from remote disconnects during load; what was that timeout setting again?
I think - there's other settings in there you can adjust also
Bart de Boer
@boekabart
thanks, let's try that..
Aaron Stannard
@Aaronontheweb
one thing we might be able to do, possibly
is add a configuration setting to the ForkJoinDispatcher and the dedicated thread pool
which will allow you to change the priority
I'm comfortable leaving the default where it is
but also fine with users being able to change it
Tomasz Jaskula
@tjaskula
quick question, does the code shared between the actors needs to be synchronized with lock or maybe there some other ways of doing things ?
Aaron Stannard
@Aaronontheweb
@tjaskula you mean shared memory?
every actor instance's memory should be made private