Re: [akka-user] Re: streams - shutting down a flow / exposing a materialized value

This is pretty much exactly what I'm trying to do. I'm polling an external system every 20 seconds. I use a tick source to control the timing, zipping the ticks with the equivalent of your WatchRequest. The tick source materializes to a Cancellable, so that's nice. Tragically, cancelling the Ca

Re: [akka-user] Re: streams - shutting down a flow / exposing a materialized value

No, but I might try to put one together. When the tick source is cancelled, should that cause cancellation of the stream, or completion of the stream? -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional

Re: [akka-user] Re: streams - shutting down a flow / exposing a materialized value

The JavaDoc for the Source.from(...) method says this: "Elements are emitted periodically with the specified interval. The tick element will be delivered to downstream consumers that has requested any elements. If a consumer has not requested any elements at the point in time when the tick elem

Re: [akka-user] Re: streams - shutting down a flow / exposing a materialized value

Yes, that's what I'm doing. More precisely, I'm defining a composite Source like so: Initial ~> Merge ~> Akka HTTP ~> Broadcast ~> Consumer +~> ~>+ | | +~~~ Throttler <~~+ The Th

Re: [akka-user] Re: streams - shutting down a flow / exposing a materialized value

I've created a test that exercises a composite source that has an internal cycle. It processes integers, starting at 1 and doubling it until it is cancelled. The code can be viewed as a gist . Two things to note: a) the stream completes succes

Re: [akka-user] Re: streams - shutting down a flow / exposing a materialized value

I think this could happen if a stage immediately requests the next element once it starts working on a received element. Is that the case? On Sunday, 26 July 2015 23:39:00 UTC+10, David Pinn wrote: > > b) the stream processes one more element than I expect it to. > > The source unde

[akka-user] Akka Streams and OAuth 2.0

I have an application that pulls data from an external system using HTTP GET requests, the headers of which include an OAuth 2.0 access token. I'm trying to work out what to do when access tokens expire, as they do from time to time. I suppose I could let the stream complete with failure, and t

Re: [akka-user] Re: Akka Streams and OAuth 2.0

// Converts a source of (current, next) Access Token future pairs into > // a continuous stream of Access Tokens, switching to the next token, when > available > def accessTokenSource(source: Source[(Future[AccessToken], > Future[AccessToken])]): Source[AccessToken, Unit] = { > source.m

Re: [akka-user] Re: Akka Streams and OAuth 2.0

Lance, I'm so grateful for your help in solving this problem. You've changed the way I was looking at it, and now you've provided code that illustrates your solution. I am working through it carefully now. I'm really looking forward to seeing how it fits into the application that we're building

Re: [akka-user] Re: Akka Streams and OAuth 2.0

Lance, I've been translating your autoRefresh method into Java. Kill. Me. Now. You wrote this: val auto = Sink( Flow[(RefreshToken, Promise[AccessToken])], Merge[(RefreshToken, Promise[AccessToken])](2), request, Unzip[RefreshToken, Promise[AccessToken]], Zip[Fut

Re: [akka-user] Re: Akka Streams and OAuth 2.0

about the Future contained in an Agent. That's the key > interface between the two components (access and request). Like any > software, as long as you get the interfaces right, the implementation > should be swappable. > > Good luck! > > > On Tuesday, August 11, 2015

[akka-user] Can I create a persistent actor with timers?

I'm working with actors in Java, and I've created one like this: public final class Librarian extends AbstractPersistentActor { ... } Now I want to use timers in that same actor, but I've learned that I need to extend AbstractActorWithTimers. That's not possible in Java, so I'm