Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 13 21:37
    Aaronontheweb commented #4085
  • Dec 13 20:28
    IgorFedchenko commented #4085
  • Dec 13 20:27
    IgorFedchenko commented #4085
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb milestoned #4096
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb opened #4096
  • Dec 13 10:41
    peirens-bart opened #4095
  • Dec 13 08:37
    Aaronontheweb synchronize #4071
  • Dec 13 08:13
    jiyeongj opened #4094
  • Dec 12 15:42
    Aaronontheweb synchronize #4086
  • Dec 12 15:42
    Aaronontheweb closed #4083
  • Dec 12 15:42

    Aaronontheweb on dev

    Fix #4083 - Endpoint receive bu… (compare)

  • Dec 12 15:42
    Aaronontheweb closed #4089
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb opened #4093
  • Dec 12 14:20
    Aaronontheweb commented #4092
  • Dec 12 14:14
    Aaronontheweb labeled #4089
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?
qwoz
@qwoz
Receive<Foo>(async foo => ... is obsolete; you need to use ReceiveAsync<Foo>(async foo => ... instead. As far as I know, Receive<Foo>(foo => ... isn't going away.
Arsene
@Tochemey
I ask that question because of ContinueWith and PipeTo
Corneliu
@corneliutusnea
Is there a way to broadcast a message to all actors part of a SmallestMailboxPool? It's an init message that I want to reach all children
If not, what is the right way to do it? Make the children ask the parent for the init info?
Bartosz Sypytkowski
@Horusiath
@corneliutusnea have you tried to send routerRef.Tell(new Broadcast(initMessage))?
hisabir
@hisabir
Hi, When to expect Akka.Net 1.5 release?
Corneliu
@corneliutusnea
@hisabir no, I haven't tried that but that's looks like a good way to do it. For now I did it as a PreStart Context.Parent.Tell(new PleaseInitMe()) kind of message that the parent replies with the correct init
hisabir
@hisabir
release 1.5...
Bartosz Sypytkowski
@Horusiath
@hisabir the exact date is not yet known
most of the changes, it introduces, are available right now in form of optional settings or plugins
Alessandro Rizzotto
@easysoft2k15
Hi, I'm trying to figure out the best way to implement this architecture:
  • in an ASP.NET application a controller is receiving requests: each request must be dispatched to an entity represented by an actor.
  • there are many instances of the same actor: each request must be dispatched to the right instance of the actor (base on a parameter witch is available within the controller action)
  • there should be a Coordinator actor that is responsible for the life time of all instance actors: if the instance actor does not exist when the request comes in, the coordinator must create the actor. Base on some event the coordinator actor must also kill instances not needed anymore.
    The obvious choice seems to have one coordinator actor managing the list of instances actor (through a dictionary of instances). The problem with this solution is that it doesn't scale: the coordinator actor is the bottleneck.
    What is the best approach?
    It would be great even if the actor instances may be spread on remote machine as well.
    I think that at the end the problem can be state as follow: what is the best way to manage the life time of many actors of the same type that can potentially be spread on many remote machine.
Arjen Smits
@Danthar
Sounds to me you want to use an consistent hashing group http://getakka.net/docs/working-with-actors/Routers#consistenthashing.
When it comes to distributing this across machines i think the cluster sharding feature is want to you want to look at cluster sharding: http://doc.akka.io/docs/akka/current/scala/cluster-sharding.html http://getakka.net/docs/clustering/cluster-sharding
Bartosz Sypytkowski
@Horusiath
@easysoft2k15 sounds like the case for akka-cluster-sharding
Alessandro Rizzotto
@easysoft2k15
@Horusiath , @Danthar Thank You. I was thinking about consistent hashing as well. Regarding cluster-sharding I don't have experience right now. I'll take a look
Aaron Stannard
@Aaronontheweb
@hisabir .NET Core kind of threw a wrench into our release schedule
since that came out sooner than expected