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). 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.
