Skip to content

Resume mechanism improvements & refactor #766

@antonbashir

Description

@antonbashir

In this issue i offer add next features:

  • Add setup connection frame into resume frames store.
  • ResumePolicy interface with next configuration (passing through factory):
  1. sessionManager
  2. storeFactory (current implementation)
  3. storeFactory (function)
  • input: resume token
  • output:consumer for saving frames state and supplier for producing it from some storage
  1. Reactor's retrySpec which will manage resuming mechanism
    (for example for configuring backoff policy)
  2. enableSessionssRecreation() - flag that enabling recreating of sessions if session was not found by resume token (description below)
  3. sessionDuration, streamTimeout, storeFactory, cleanupStoreOnKeepAlive - currently used parameters

and next default implementations:

  1. DefaultResumePolicy: currently resuming mechanism with using Retry spec
  2. RecreatableSessionsResumePolicy (activates on enableSessionssRecreation()).
    New feature:

Imagine that you have RSocket stream from server to client with enabling resuming and this resume policy. Server provides persistent frames store. Client and Server enables sessions recreation.
We shutting down server. Resuming starts. After some time we restarting server and there is next magic has come:

  1. server received resume frame
  2. server got frames by token from storage
  3. server makes re-setup of acceptor with setup frame from store and start sending frames from position of saved resume frame.
  4. client receive RESUME_OK and starting receiving data from server

By this feature we have realy fault tolerancable resuming with providing ability of frames persisting.

P.S. I will make PR with example of sessions recreating to give some more information about this feature.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions