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

2017-09-17 Thread David Pinn
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

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

2015-08-12 Thread David Pinn
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 at 10:32:57 AM UTC-4, David Pinn wrote: Lance, I've been translating your autoRefresh method into Java. Kill. Me. Now

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

2015-08-11 Thread David Pinn
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]],

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

2015-08-06 Thread David Pinn
(AccessToken.code))) } On Wednesday, August 5, 2015 at 9:46:05 AM UTC-4, David Pinn wrote: 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

[akka-user] Akka Streams and OAuth 2.0

2015-08-05 Thread David Pinn
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

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

2015-07-26 Thread David Pinn
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

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

2015-07-26 Thread David Pinn
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

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

2015-07-26 Thread David Pinn
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/faq.html Search the

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

2015-07-26 Thread David Pinn
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 https://gist.github.com/dpinn/cdac6709e00b7de64163. Two things to note: a) the stream completes

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

2015-07-26 Thread David Pinn
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 under test spits out

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

2015-07-25 Thread David Pinn
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