Key changes

• maintainMultiplexedSession - method executed as part of background task.
• getMultiplexedSessionWithFallback - method to obtain a multiplexed session.

Thanks, I really like how the structure is now looking! This will significantly simplify the entire session pool once we can get rid of all 'normal' sessions. I left a couple of minor comments, but I think that structurally this is largely how it should be.

[olavloite]

We only need one instance of MultiplexedSessionFutureWrapper per instance of SettableFuture that we have for the multiplexed session, as the wrapper does not contain any additional state. So we should just create one instance of it per multiplexed session that we have (meaning one at startup, and one each time that we successfully refresh the multiplexed session). That will reduce the number of objects that we have to create each time a read-only operation is executed.

[arpan14]

Yes, for the time-being it is stateless. Hence, stored a local variable MultiplexedSessionFutureWrapper and managing this in the call back methods.

I fore-see that we may need to store the state of span in the Future object. I'll change this back to a stateful object based on how that refactoring goes at - #3016

[olavloite]

Is this method still used? Or can we remove it?

[arpan14]

Yes, this is called by all invocations which need a session to be available (for ex - maintainer). Modifying the logic in this method to

MultiplexedSessionFuture getMultiplexedSession() {
    return (MultiplexedSessionFuture) getWrappedMultiplexedSessionFuture().get();
  }

This allows callers to not do a get().get() on wrapper as post initialization there will always be a instance available.

[arpan14]

As discussed, i've added necessary docs to mention this method is blocking. Also checked that all places that invoke this method have a isDone() check.