Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 05 17:21
    Aaronontheweb synchronize #4079
  • Dec 05 17:20
    Aaronontheweb labeled #4084
  • Dec 05 17:20
    Aaronontheweb labeled #4084
  • Dec 05 17:20
    Aaronontheweb milestoned #4084
  • Dec 05 17:20

    Aaronontheweb on dev

    Remove string interpolation fro… (compare)

  • Dec 05 17:20
    Aaronontheweb closed #4084
  • Dec 05 17:20
    Aaronontheweb commented #4084
  • Dec 05 15:43
    ismaelhamed opened #4084
  • Dec 04 23:34

    Aaronontheweb on dev

    Made cleanup call thread-safe (… (compare)

  • Dec 04 23:34
    Aaronontheweb closed #4081
  • Dec 04 23:34
    Aaronontheweb closed #4020
  • Dec 04 19:08
    Aaronontheweb commented #4079
  • Dec 04 18:35
    maratoss review_requested #4079
  • Dec 04 18:26
    maratoss synchronize #4079
  • Dec 04 07:42
    jiyeongj edited #4083
  • Dec 04 06:45
    jiyeongj opened #4083
  • Dec 04 06:35
    dependabot-preview[bot] labeled #130
  • Dec 04 06:35
    dependabot-preview[bot] opened #130
  • Dec 04 06:35

    dependabot-preview[bot] on nuget

    Bump System.Data.SqlClient from… (compare)

  • Dec 03 19:10
    Aaronontheweb synchronize #4081
wdspider
@wdspider
Is there an example project that uses the Cluster Sharding module? I'm having a bit of trouble envisioning how to use it.
Vagif Abilov
@object
@Horusiath yes, I will try to extract a small example and check if it's still so slow. Then I will create an issue.
Aaron Stannard
@Aaronontheweb
@wdspider yep, inside the main repo
Bartosz Sypytkowski
@Horusiath
btw. guys, I want to finish my CQRS/Eventsourcing akka sample - but it looks like I'm a very unimaginative person. I need some kind of simple event stormed scenario to program, something that could be used for learning purposes. Do you know anything about such scenarios?
Arsene
@Tochemey
Hello please what is the best practice in using await inside a Receive of an Actor?
wdspider
@wdspider
@Aaronontheweb found it, thanks :)
Aaron Stannard
@Aaronontheweb
noice
qwoz
@qwoz
@Tochemey Lots of discussions here as well as blog posts. Perhaps start with the top two results here https://duckduckgo.com/?q=site%3Apetabridge.com+await&ia=web and then ask for clarification on anything you still don't understand?
Aaron Stannard
@Aaronontheweb
my blog post on PipeTo vs. async / await is a bit out of date
wrote that before Akka.NET 1.0 :p
we support async / await inside Akka.NET actors now
didn't at the time
I would still use PipeTo, personally
qwoz
@qwoz
Yeah, though the drawbacks of blocking the actor are still there, correct?
Aaron Stannard
@Aaronontheweb
correct
they are
await has a cost associated with it
to11mtm
@to11mtm
@Horusiath I have some great ideas for eventsourcing examples but you'd be doing my work lol.
Arsene
@Tochemey
@qwoz I am just asking best practices. So far I have been using await inside my Receive. I just want to know whether it is recommended.
Aaron Stannard
@Aaronontheweb
I don't recommend it
wdspider
@wdspider
does the sharding stuff support multiple sets of actors? i.e. Actor A for Node Role A and Actor B for Node Role B ?
Aaron Stannard
@Aaronontheweb
avoid it if possible and use PipeTo instead
PipeTo doesn't block the actor
so you can kick off an asynchronous task and pipe it back to the actor as a message later
the actor can keep doing other things while that task is running
the only case where I think using await makes a lot of sense inside an actor is if you have complex error handling routines
where you might be doing multiple chained async operations
and have to handle exceptions for each
Arsene
@Tochemey
ok
Aaron Stannard
@Aaronontheweb
that's easier to express with await
doing that with ContinueWith and PipeTo can be cumbersome
if your error handling is pretty simple
i.e. pass / fail error handling
then you're better off with a continuation and pipe to
Arsene
@Tochemey
@Aaronontheweb So if I am using a third party lib that offers async methods and sync method I should rather use the sync method. Am I right?
Aaron Stannard
@Aaronontheweb
no
use the async method
just don't await it
pipe the results to yourself instead
Arsene
@Tochemey
Ok
I got it
explains that in more detail
although my comments about await in that blog post are outdated
as I mentioned earlier
qwoz
@qwoz
It'd be really nice if the ContinueWith/PipeTo had a bit more syntactic sugar around it... it's a bit cumbersome to take the result and, if the next thing depends on state from the current message, having to wrap the state in order to be able to process it for the next thing.
I'm not sure if that's feasible or even possible
Aaron Stannard
@Aaronontheweb
you basically have to close over the bits of state you need
qwoz
@qwoz
Yeah... it just seems like there must be a better way. For example, if you want to lookup who owns an object, then do something if that owner has IsAdmin = true setting. Currently you might lookup by ID to fetch the user record and, based on that, find the pref, then perform the original action. This might vary depending on if you're looking up the owner vs. the creator, for instance. So there's a bunch of what feels like unnecessary keyboard mashing in order to pass along enough information to be able to process the result based on the state of the original request.
Arsene
@Tochemey
@Aaronontheweb How do we then use the ReceiveAsync seeing that Receive will be obsolete in the near versions?