4 ms·

Could you imagine a layer that compiles down to actors? If that it too much of a stretch maybe something that can lint the protocol flows between actors. So you

Could you imagine a layer that compiles down to actors? If that it too much of a stretch maybe something that can lint the protocol flows between actors. So you can have proof that fragmentation and re-assembly is done correctly. Or that message sizes are bounded. Or some other higher level property is proven true?

smabie 7y ago
One thing I’ve thought of is that instead of messages, each actor exports a list of functions that it provides. Then other actors can call these functions and everything looks synchronous but under the hood each actor is calling other actors functions transparently. This would eliminate message bloat (too many kinds of messages) and would end up looking kind of like OO. So instead of sending the message: Sum(x, y) and eventually getting the response: SumReturn(x), I could just do something like: actorA.sum(x, y) that would look and act like a regular function call. Then actorA could implement sum like: def sum(x: DbInt, y: DbInt) = DbActor.get(x) + DbActor.get(y) With Akka, none of this is possible. Once actorA received the Sum message, first it would have to send the Get messages to DbObject and update some record indicating I’m waiting for two Get responses while also saving who I’m supposed to send the data to. Then I need to have a big match statement and update the record whenever I get that specific response. Once I finally have received the two responses, I look up where to send my message, and then finally send my SumReturn() message. It’s a total nightmare and it sucks big-time. A lot of Akka code just ends up being maintaining these large dictionaries keeping track of all the unfinished stuff I eventually need to send various actors when I finally receive all the ingredients. And it starts to get really bad when you have hierarchical actor structure and one of the terminal actors needs some information held by the top nodes. Then I either need to forward the message up one by one maintaining state along the way, or find the parent of the parent of the parent and send the message directly. And if I do that, now my root actors are talking to everyone else, and the information partitioning advantages of the hierarchy are broken. There’s one actor topology that really shines though: directed acyclic graphs. If I only send information one way, like a waterfall, actors work really really well. Great for bioinformatics or other ML/data science pipelines.
- davedx 7y ago
  > A lot of Akka code just ends up being maintaining these large dictionaries keeping track of all the unfinished stuff I eventually need to send various actors when I finally receive all the ingredients. I don't think this is an Akka-specific thing. I work with NServiceBus, which implements long running processes using database-persisted sagas (sort of state machines), and we have exactly the same situation... NServiceBus even makes these big state-tracking dictionaries explicit (every saga has a corresponding "saga data" object).

smabie 7y ago

One thing I’ve thought of is that instead of messages, each actor exports a list of functions that it provides. Then other actors can call these functions and everything looks synchronous but under the hood each actor is calling other actors functions transparently. This would eliminate message bloat (too many kinds of messages) and would end up looking kind of like OO. So instead of sending the message: Sum(x, y) and eventually getting the response: SumReturn(x), I could just do something like: actorA.sum(x, y) that would look and act like a regular function call. Then actorA could implement sum like: def sum(x: DbInt, y: DbInt) = DbActor.get(x) + DbActor.get(y) With Akka, none of this is possible. Once actorA received the Sum message, first it would have to send the Get messages to DbObject and update some record indicating I’m waiting for two Get responses while also saving who I’m supposed to send the data to. Then I need to have a big match statement and update the record whenever I get that specific response. Once I finally have received the two responses, I look up where to send my message, and then finally send my SumReturn() message. It’s a total nightmare and it sucks big-time. A lot of Akka code just ends up being maintaining these large dictionaries keeping track of all the unfinished stuff I eventually need to send various actors when I finally receive all the ingredients. And it starts to get really bad when you have hierarchical actor structure and one of the terminal actors needs some information held by the top nodes. Then I either need to forward the message up one by one maintaining state along the way, or find the parent of the parent of the parent and send the message directly. And if I do that, now my root actors are talking to everyone else, and the information partitioning advantages of the hierarchy are broken. There’s one actor topology that really shines though: directed acyclic graphs. If I only send information one way, like a waterfall, actors work really really well. Great for bioinformatics or other ML/data science pipelines.

davedx 7y ago
> A lot of Akka code just ends up being maintaining these large dictionaries keeping track of all the unfinished stuff I eventually need to send various actors when I finally receive all the ingredients. I don't think this is an Akka-specific thing. I work with NServiceBus, which implements long running processes using database-persisted sagas (sort of state machines), and we have exactly the same situation... NServiceBus even makes these big state-tracking dictionaries explicit (every saga has a corresponding "saga data" object).