On Fri, Aug 14, 2015 at 5:30 PM, algermissen1971 <[email protected]> wrote:
> Roland, > > On 14 Aug 2015, at 12:23, Akka Team <[email protected]> wrote: > > > Hi Jan, > > > > this process sounds more like an Actor should be the right tool for the > job, the protocol you describe does not really feel like a unidirectional > flow of data from source to sink. Of course it should be possible to model, > but the result will likely not be as pretty/concise/obvious as the Actor > implementation. > > > > thanks a lot, makes sense (using streams at this point was purely of > learning intent) > > However, I understood streams to be meant sort of as a more functional > replacement for actors (but maybe that is more a functional purist POV). > Nope, this is a misunderstanding: Actors are a general distribution/concurrency abstraction that can model all kinds of communication while streams embody one very particular communication scheme (namely data only flowing in one direction across a sequence of processing steps). “Functional purity” is rather irrelevant when it comes to distributed systems, at least with our current knowledge, since these are “nasty to the core”, meaning that no amount of FP fluff will make them any easier to reason about. Sure, you can (and should) treat all non-distributed aspects in as principled a way as possible, but the remaining essence cannot be ignored—and it is perfectly captured and expressed in the Actor Model. One thing that we are in the process of doing is to allow the “pure” (and properly typed) formulation of Actors, but again that only makes them nicer on the inside. Regards, Roland > > Jan > > > > > Regards, > > > > Roland > > > > On Wed, Aug 12, 2015 at 6:23 PM, algermissen1971 <[email protected]> > wrote: > > Hi, > > > > suppose I want to periodically do the following 'work': > > > > - access a database to obtain a 'lock' (only one of a bunch of scaled > out services are to do the work at once) > > - start some 'process' that periodically touches the lock > > - interact with a remote resource (download a file from ftp server if > available) > > - retry N times if interaction fails > > - process the file > > - store some current state in the database > > - stop the lock touching process > > - done (lock times out) > > > > I did something like this using actors but would now like to try it out > with an akka-streams based approach, without using actors[1]; including the > scheduling. > > > > Can anyone provide me with a rough sketch witch kinds of stream > components I should use and how? > > > > - Do I need to create a sink that emits 'start' events based on a > schedule? How would i do that? > > - Would the touching process be a stream on its own that I create for > every time the othet stream runs? > > - How do I go about implementing the retry when the FTP interaction > fails? Are the stateful stages meant for that? > > > > etc. > > > > Pointers to any resources that discuss roughly similar stuff would also > be of great help. > > > > Jan > > > > [1] I am aware the akka-streams uses actors beneath :-) > > > > > > -- > > >>>>>>>>>> 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 [email protected]. > > To post to this group, send email to [email protected]. > > Visit this group at http://groups.google.com/group/akka-user. > > For more options, visit https://groups.google.com/d/optout. > > > > > > > > -- > > Akka Team > > Typesafe - Reactive apps on the JVM > > Blog: letitcrash.com > > Twitter: @akkateam > > > > -- > > >>>>>>>>>> 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 [email protected]. > > To post to this group, send email to [email protected]. > > Visit this group at http://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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Akka Team Typesafe - Reactive apps on the JVM Blog: letitcrash.com Twitter: @akkateam -- >>>>>>>>>> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
