Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 06:50
    dependabot-preview[bot] labeled #4033
  • 06:50

    dependabot-preview[bot] on nuget

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

  • 06:50
    dependabot-preview[bot] opened #4033
  • Nov 12 22:40
    Horusiath commented #4022
  • Nov 12 22:03

    dependabot-preview[bot] on nuget

    (compare)

  • Nov 12 22:03

    dependabot-preview[bot] on dev

    Bump Microsoft.SourceLink.GitHu… (compare)

  • Nov 12 22:03
    dependabot-preview[bot] closed #4028
  • Nov 12 20:30
    dependabot-preview[bot] synchronize #4029
  • Nov 12 20:30

    dependabot-preview[bot] on nuget

    Bump ApprovalTests from 3.0.10 … (compare)

  • Nov 12 20:30
    dependabot-preview[bot] edited #4029
  • Nov 12 20:30
    dependabot-preview[bot] synchronize #3991
  • Nov 12 20:30

    dependabot-preview[bot] on nuget

    Bump Microsoft.Extensions.Depen… (compare)

  • Nov 12 20:30
    dependabot-preview[bot] synchronize #4028
  • Nov 12 20:30
    dependabot-preview[bot] synchronize #4021
  • Nov 12 20:30
    dependabot-preview[bot] edited #3991
  • Nov 12 20:30
    dependabot-preview[bot] synchronize #3989
  • Nov 12 20:30

    dependabot-preview[bot] on nuget

    Bump Microsoft.SourceLink.GitHu… (compare)

  • Nov 12 20:30

    dependabot-preview[bot] on nuget

    Bump Mono.Cecil from 0.9.6.4 to… (compare)

  • Nov 12 20:30

    dependabot-preview[bot] on nuget

    Bump ApiApprover from 3.0.1 to … (compare)

  • Nov 12 20:30
    dependabot-preview[bot] synchronize #3985
Pablo Castilla
@pablocastilla
that would be ok. The actor could discard the second message. But I have to make sure it gets there, we have business timeouts
another option could be to make sure certain actors are recreated after a reboot or a machine missed? :S
Bartosz Sypytkowski
@Horusiath
this would require to have some scheduler working on each node and distributed "database" where the timeout requests would we written to, so they could be taken over by other nodes in case of unexpected crash
@pablocastilla with cluster sharding I guess you could
(but I haven't checked if actors would be recreated in case of crash, only when migrated between machines)
Bart de Boer
@boekabart
@pablocastilla I suggested a solution at SO
Pablo Castilla
@pablocastilla
so I would have to write it, wouldn't I?
Bartosz Sypytkowski
@Horusiath
also for the first case ddata module would be good, but it's still in development
eventually something like redis would do the job
Pablo Castilla
@pablocastilla
@boekabart I think I got the idea and it should work. Thanks so much. Tell me what you think about the comments plz
Bart de Boer
@boekabart
After wrapping my Akka.Remoting application in a Topshelf service, it won't quit anymore. CTRL-C does 'stop' the service OK, but then the process hangs (with the console window open). Attaching a debugger shows 6 threads waiting for UnfairSemaphore.Wait():
Not Flagged > 12944 8 Worker Thread akka.remote.default-remote-dispatcher_1 Akka.dll!Helios.Concurrency.DedicatedThreadPool.UnfairSemaphore.Wait Normal
any clue what might cause this?
Tomasz Jaskula
@tjaskula
Hi
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