I'm confortable with Scala, but for reasons outside my control, Java was
mandated for this project. We're using streams for another part of the
application, in a somewhat simpler scenario. This conversation has been
very helpful. The gems are these, I think:
a) Treat the refresh flow as normal
Oh, jeez. Yeah, that's entirely hideous.
You know there's a cure for this disease. It's called Scala. However, side
effects may include crawling compiles, awkward builds, and speaking
optionally in futures :-)
Seriously, if I'd known you were approaching this from Java, I'd advised
against
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]],
David-
Excellent call on using an agent. It's a nice fit for this situation. My
only hesitation would be ensuring that the agent is properly initialized
with a valid token before you start slinging requests. The flow I
originally posted ensures that by way of the Access Token source, but it
Hi Lance,
Nice to meet you, I am working with David on this problem, so let me jump
in while he is sleeping :)
I think one scenario of having an expired token (even with the constant
refresh happening in the background), is if the system goes down for a
period of time (either planned or
Hi Patrick-
Nice to meet you as well.
Can you help me understand what would start with an expired token? If
possible, this would seem to be a design flaw in the token publisher, not
the subscriber. The Access Token publisher should *always* be publishing
valid tokens, if at all possible.
Wow, Lance! You have blown my mind. You are so right about treating a token
refresh as a part of normal program flow, and not an error condition. I'm
spending today getting this right.
I have a couple of thoughts on implementation. I'm wondering if Akka Agents
can help us out here. They're
