Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 00:30
    Arkatufus opened #5109
  • Jun 23 22:00
    Arkatufus opened #5108
  • Jun 23 21:40

    Aaronontheweb on dev

    [FLAKY TESTS] Update and clean … (compare)

  • Jun 23 21:40
    Aaronontheweb closed #5107
  • Jun 23 21:26
    Aaronontheweb auto_merge_enabled #5107
  • Jun 23 19:26
    Aaronontheweb auto_merge_enabled #5106
  • Jun 23 18:45
    Aaronontheweb ready_for_review #213
  • Jun 23 18:19
    Arkatufus synchronize #5107
  • Jun 23 18:18

    Aaronontheweb on dev

    Make deserialization message mo… (compare)

  • Jun 23 18:18
    Aaronontheweb closed #5105
  • Jun 23 18:07
    Aaronontheweb synchronize #5107
  • Jun 23 18:06
    Aaronontheweb labeled #5105
  • Jun 23 18:06
    Aaronontheweb labeled #5105
  • Jun 23 18:06
    Aaronontheweb milestoned #5105
  • Jun 23 17:53
    Arkatufus opened #5107
  • Jun 23 17:48
    Arkatufus edited #5105
  • Jun 23 17:46
    Aaronontheweb auto_merge_enabled #5105
  • Jun 23 17:46
    Aaronontheweb synchronize #5105
  • Jun 23 17:00
    Arkatufus synchronize #5080
  • Jun 23 17:00

    Arkatufus on nuget

    [FLAKY TESTS] Update and clean … Merge branch 'dev' into dependa… (compare)

Bartosz Sypytkowski
@Horusiath
@pablocastilla what do you mean by timeout message? With fire-and-forget messages, there is nothing to wait for
Pablo Castilla
@pablocastilla
@Horusiath I mean defered messages. When you want to get notified at a certain exact time.
Bartosz Sypytkowski
@Horusiath
this is hard case when you try to think about consistency i.e. should it be allowed to call the same scheduled timeout twice?
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.