[akka-user] Ideomatic way to do local pubsub in akka
I'm started to work with akka as scala actors become deprecated in favour of akka. So I'm intrested only in local actor systems for now. What is intended way to implement publisher subscriber template in akka? Akka gives multiple choice, I found three already: - Store subscribers manually in a publisher actor and sends them messages - Send messages to system eventbus and let subscribers to lookup for corresponding messages - Create new eventbus for every publisher actor and let subscribers receive all messages without filtering. Which one is more suitable for local pubsub? -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] What is idiomatic way to share state on a local node.
For example, we would like to model the backgammon game with akka actors. Both players are actors (either human or AI), there is also an actor that rules the board and determines dice rolls for players. They all share the single board. What is idiomatic way to have access to the board and to take notifications on board position changes? -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] What is idiomatic way to share state on a local node.
This approach does not work with complex data structures. They should be composable, each part separately addressable, other actors should be able to subscribe to the state changes individually. There should be a way to create read-only view for a data and so on. Approach "just create actor and bunch of accessor messages for wrapped structure" could not scale and adapt for complex structures. , On Friday, August 5, 2016 at 5:45:13 PM UTC+3, Martynas Mickevičius wrote: > > One of the simplest solutions would be to model it as an actor itself. > > A fun challenge would also be to model backgammon board based on a > Conflict Free Replicated Data type. If you solve that, then you could use > Akka > Distributed Data > <http://doc.akka.io/docs/akka/current/scala/distributed-data.html> module. > > On Fri, Aug 5, 2016 at 3:24 PM, scala solist > wrote: > > For example, we would like to model the backgammon game with akka actors. >> Both players are actors (either human or AI), there is also an actor that >> rules the board and determines dice rolls for players. They all share the >> single board. What is idiomatic way to have access to the board and to take >> notifications on board position changes? >> >> -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] general approach to stackable actor behaviour
There is an obvious way to make mixins for actors: take *receive, preStart, postStop* methods, override them and call super inside. Or make *List[Receive]* and fold the list to single partial function. Things become harder with the *become* method. I could modify it in such way that it would apply stored *List[Receive]* before new behaviour. But what if several mixins uses the *become* method? It still could be solved, but you should store behaviour as variable field for each mixin separately and fold them after changing part of it. But things becomes too complicated when using FSM syntax sugar. Too many end-points need to be overridden to be practical. But still actor mixins are very compelling. It is a way to combine behaviours that shares state. You could not substitute mixins with spawning number of actors, because they would have separate states. Combining partial functions improves type safety a bit: instead of *PartialFunction[Any,Unit]* you could have *PartialFunction[A,Unit]* mixed with *PartialFunction[B,Unit]* giving *PartialFunction[Any,Unit]* as result. But each partial function has exact type specified and scala could check case statement for variant coverage. So, could anyone suggest approach how to mix actors fully, like taking two *UntypedActor* and making one of them? -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] transactors and STM are gone. What conception to use instead?
Sometimes you need to do coordinated work between actors and modify shared state. The state in broad sense is separated by actors, there is no need to share them all. But sometimes there is a need to share small chunk of state and work with it with several actors. How it should be done in the recent akka? -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] transactors and STM are gone. What conception to use instead?
I'm using akka for desktop application multithreading, so I need only simple akka features that works local. Unfortunately local-only features are unwelcomed in new akka. So I would code some kind of hack like sending local states of both actor to the third actor and suspending until it would reply. On Friday, January 13, 2017 at 6:46:38 PM UTC+3, Konrad Malawski wrote: > > Correction, Agents are not gone. They will be deprecated in 2.5, they are > present in 2.4. > > Just Actors ;-) > > -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] transactors and STM are gone. What conception to use instead?
Thanks for the reply! I'm currently implemented some plain and simple observable variable model atop of normal actors. Actor could control immutable state, it accepts update messages that contains write lenses and applies them. It manages subscriptions to the changes where subscriber provide read lens and if it had changed - new value is sent. Immutable data structures as well as rough subscriptions are not very effective, but I has no need in computational efficiency. The problem is what should I do, when I have two actors (or agents as you have suggested) and want them to do coordinated updates to both. There was transaction model in the older releases, and now I need to replace it. Is there any existing library in the ecosystem, or should I write it myself? On Friday, January 13, 2017 at 7:23:01 PM UTC+3, Konrad Malawski wrote: > > You can just use the Agents as was explained in my previous email. > We're moving them out, shouldn't really stop you from using it. > > If you want to officially maintain them let us know. > > -- > Konrad `ktoso` Malawski > Akka <http://akka.io> @ Lightbend <http://lightbend.com> > > On 13 January 2017 at 16:46:30, Konrad Malawski (konrad@lightbend.com > ) wrote: > > Correction, Agents are not gone. They will be deprecated in 2.5, they are > present in 2.4. > > Just Actors ;-) > > More is documented in the upcoming migration docs: > > https://github.com/akka/akka/blob/master/akka-docs/rst/project/migration-guide-2.4.x-2.5.x.rst#agents-are-now-deprecated > > > Agents are now deprecated > > Akka Agents are a very simple way of containing mutable state and allowing > to access it safely from multiple threads. The abstraction is leaky though, > as Agents do not work over the network (unlike Akka Actors). > > As users were often confused by "when to use an Actor vs. when to use an > Agent?" a decision was made to deprecate the Agents, as they rarely are > really enough and do not fit the Akka spirit of thinking about > distribution. We also anticipate to replace the uses of Agents by the > upcoming Akka Typed, so in preparation thereof the Agents have been > deprecated in 2.5. > > If you use Agents and would like to take over the maintanance thereof, > please contact the team on gitter or github. > > -- > Konrad `ktoso` Malawski > Akka <http://akka.io> @ Lightbend <http://lightbend.com> > > On 13 January 2017 at 16:42:37, scala solist (scala...@gmail.com > ) wrote: > > Sometimes you need to do coordinated work between actors and modify shared > state. The state in broad sense is separated by actors, there is no need to > share them all. But sometimes there is a need to share small chunk of state > and work with it with several actors. How it should be done in the recent > akka? > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: > http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to akka-user+...@googlegroups.com . > To post to this group, send email to akka...@googlegroups.com > . > Visit this group at https://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] newbie question about await inside actors code
I need to perform number of requests to different actors and sum them to some response. An actor wrap all requests inside futures and compose them to single. After that I suppose actor would be put in sleep until it recovers all needed information (or timer runs out). What if I had hundreds of such actors simultaneously? Naive approach is that they all would be put to sleep and would exhaust thread pool which leads to deadlock possibility. Does akka uses such naive approach or it has some tricky magic to return blocked actor thread back to executor? Should I avoid awaiting inside actors? -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] newbie question about await inside actors code
On Sunday, February 19, 2017 at 10:53:01 PM UTC+3, Justin du coeur wrote: > > Do you mean literally calling "sleep()"? > I mean sleep as a thread state. Alternative is to save actor state somehow and return thread to dispatcher so it can be reused. The dispatcher should never bother the actor until it become available. It complicates things for the actor system, but Akka is already very complicated and I'm not sure if it is already implemented somewhere -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] newbie question about await inside actors code
That is how I've implemented it finally. Just store messages and restore them when the result would become clear. The actor performs some data management, so it should have confidence in own state before it could proceed further messages. But reducing actor activity to just message shuffling is is a little bit discomfortable. Keeping messages in the common mailbox looks more consistent but also more hazardous: it brings possibility of buffer overrun to the mailbox instead of just an actor. All the worries are from akka lacking built-in backpressure control. So you need to reinvent it to some extent. On Tuesday, February 21, 2017 at 3:57:05 PM UTC+3, Justin du coeur wrote: > > On Tue, Feb 21, 2017 at 7:19 AM, Alan Burlison > wrote: > >> On 21/02/2017 12:12, Viktor Klang wrote: >> >> http://doc.akka.io/docs/akka/2.4/scala/actors.html#Stash >>> >> >> Ahah! I'd seen stash in the docs and not really come up with an case >> (other than become/become) where it would be useful, and then forgotten >> about it. I'm still not clear how it would help in this scenario though? > > > As I understand it, you want your parent to "wait" until it has collected > all the info from the children before it moves on to doing something else. > (Forgive me if I'm misunderstanding your use case -- it isn't spelled out > in great detail above.) > > The Akka-idiomatic way to do this is for the parent to do something like: > > -- Send out the jobs to the children > -- become() into a different receive processor > -- In this new processor, everything *other* than the responses from the > children get stash()ed -- that is, you save them away for later > -- Once you have accumulated all of the child responses (or timed out -- > it is often adviseable to have a timeout scheduled), send out the > aggregated response. Then unstash() everything that's been stored up, and > become() back to your original state. > > Essentially, instead of waiting/blocking, you shunt everything else aside > (queueing it, essentially) until you're ready to handle it. The effect is > largely the same, but without tying up threads. > -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] transactors and STM are gone. What conception to use instead?
Thanks for mentioning the saga technique. To my surprise I had already used it without knowing. That is the first thing that comes in mind in certain situations. But saga by no means could provide a transaction guaranties. The intermediate state is visible to third party during so called transaction and that ruins isolation. The process may crash midway beyond recover ability. By the time the saga master performs "rollback" the actors in question may update their state dozen times, so rollback operation has no meaning or could not be performed. So no atomicity for saga either. Saga is good to mitigate damage dealt by broken transaction if possible, but it could not provide any guaranties. On Tuesday, January 31, 2017 at 6:43:38 PM UTC+3, Rafał Krzewski wrote: > > I think you need to look into saga pattern which is actor model analogue > of (distributed) transactions. It has the advantage that the parties > involved in the transaction do not need to be present on the same VM > (cluster node etc.) which is a prerequisite for STM / Agents. > > Cheers, > Rafał > > > -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] transactors and STM are gone. What conception to use instead?
On Monday, March 13, 2017 at 11:55:55 PM UTC+3, Rafał Krzewski wrote: > > If you are up to for an adventure, I recommend you to read "Life beyond > Distributed Transactions" > > cheers, > Rafał > > I know it's hard to believe but I'm interested in local transactions rather than distributed. Akka become cluster and distributed oriented more and more. Distributes systems is what drive akka forward, so cluster deviation is natural. But that is only part of the story. Other part originates from Programming in Scala text book. It claimed that good old ways to multithreading: threads, thread pools, synchronized keyword, synchronized collections - are not so good, they are too low-level and errorprone, glorious scala language deserved better abstraction which is actors. I consent that actor system are great for multitasking. Even if it is used inside single JVM without remote capabilities. Time passes, and builtin scala actors become obsolete in favour of Akka. Which gave even better experience. So now I'm still using akka for single-JVM multitasking and has no desire to go back to synchronized. So I need to program local transactions somehow. It is definitely feasible since it could be done in single-JVM with synchronized. But I'd like to find idiomatic actor way. -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
