Hi Shawn, On Mon, May 25, 2015 at 4:29 PM, Shawn Garner <shawndgar...@gmail.com> wrote:
> The arbiter sounds like what we would need. > Are there any activator templates or example of someone using an arbiter > in Akka you can point me to? > This way I could demo it to my coworker without having to write something > from scratch? > You could most probably illustrate it on a whiteboard in a simple step-by-step way. But AFAIK there's no pre-cooked version. > > A lot of the problems at my company are cultural rather than matching > problems to solutions like you said. > We have a lot of shared projects which are basically canned solutions to > standard problems and are basically required to use. > If a solution doesn't look exactly the same and fit into the same paradigm > then it is not viewed as viable. > It's viewed as resolving a problem that has already been solved. > I understand, and have had similar situations in the past. The question that usually helps here is why change is being considered if the existing solutions work so well? > > So we're talking about an aging set of canned solutions which are getting > to be about 10 years old without anyone considering anything else along the > way. > The people who created those are still at the company and very stuck on > them. > Part of it is rampant sunken cost fallacy. > Oh, I hear you. Territorialism can be extremely destructive and a source of much inertia. Something that always resonated with me is "You have to pick people up where they are and not where you want them to be.", is there a common ground/understanding/position that you can build from? > > We have a lot of batch import/export jobs which instead of run daily could > be modeled as reacting to events in runtime with Akka. (I've been > thinking/searching about how to get events into Akka when certain tables > change or get data inserted into them without writing code to detect such > events. aka Event sourcing from SQL Server database) > We are having some growing pains where our batch jobs are taking too long. > We have admin pages which don't update themselves because they need to > wait on large batch imports in a single transaction and dirty reads are not > allowed in our databases at the db server level. > Check. That's where the illusion of a strongly consistent reality starts to break down. Seems like a good time to take a step back and focus on the real problem rather than the symptom (the mess in the DB). > So in my mind Akka is a viable solution (and a much preferable one) to a > problem over something like Spring Batch and Spring Integration. > Those Spring things are also mostly canned solutions which look like what > our current shared solutions expect so they would always be preferred over > Akka. > Absolutely. Is this a use-case for Akka Streams perhaps? > > > Thanks, > Shawn > > > On Monday, May 25, 2015 at 4:53:58 AM UTC-5, √ wrote: >> >> Hi Shawn, >> >> The use case you're referring to (transitive ordering) I think >> traditionally is accomplished in the actor model with the use of >> "arbiters": >> https://en.wikipedia.org/wiki/Indeterminacy_in_concurrent_computation >> I.e. you need a single source of truth w.r.t. the ordering, and since >> Actors are "islands of order in a sea of chaos" you "just" need A and B to >> agree on an intermediary when communicating with C, as you say, remoting >> would otherwise be very interesting (and different mailbox implementations >> may give you different semantics). Burdening all communication with acks >> (which could get lost as well, and the original message too) just because >> it is needed in some cases, would not be responsible :) >> >> In general, with your coworker, I suspect it is a matter of mapping >> problems to solutions rather than solutions to solutions (i.e. it may not >> be meaningful to map all solution in his/her world to the world of actors, >> but instead focus on how certain problems are solved with actors and then >> he/she can do the mapping from other-technology-prefered solution to the >> actor-solution themselves) >> >> Does that make sense? >> >> On Sat, May 23, 2015 at 4:41 PM, Shawn Garner <shawnd...@gmail.com> >> wrote: >> >>> I was talking with a coworker and he has some custom behavior he can't >>> understand how to do anything useful without. >>> He want's an tell message (a') sent from A -> C to not allow actor A to >>> continue until after there is confirmation that A's message is in C's >>> mailbox. >>> This way if a sends (a'') to from A -> B and B sends a message (b') fro >>> B -> C that C should process messages always in the defined order a',b'. >>> I was looking at the mailboxes and it sees like even if you use the >>> UnboundedPriorityMailbox and it seems to me that with a tell message it >>> probably is not blocking the sending actor but some kind of internal >>> component of Akka. >>> So I'm thinking UnboundedPriorityMailbox breaks down when you start >>> talking remote actors and http actors in that the first one deserialized >>> would block the other one but not block the sender until the message is in >>> the mailbox. >>> Also I'm thinking that UnboundedPriorityMailbox will just order messages >>> sitting in the mailbox. If b' arrives before a', then b' may already be >>> removed from the mailbox and being processed which the blocking and >>> ordering of UnboundedPriorityMailbox will do nothing to help. >>> Could you help me understand this? >>> Is there anything built into Akka would give you this guarantee of order? >>> Or would I have to build this in yourself with some kind of ack system >>> with an ask vs a tell message waiting to send a'' until a' was ack'd as >>> recieved and delegated to another worker actor D? >>> My co-worker seems fixated on these aynch semantics because he want's it >>> to behave like an asynch queue of ActiveMQ and feels Akka should provide >>> something like that out of the box. >>> I told him I don't think so but you get all the tools to build it >>> yourself whatever semantics you want. >>> >>> Thanks, >>> Shawn >>> >>> -- >>> >>>>>>>>>> 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 http://groups.google.com/group/akka-user. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Cheers, >> √ >> > -- > >>>>>>>>>> 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 http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Cheers, √ -- >>>>>>>>>> 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
