Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement the cache import and export options #10

Closed
adobeDan opened this issue Jan 16, 2021 · 1 comment · Fixed by #17
Closed

Implement the cache import and export options #10

adobeDan opened this issue Jan 16, 2021 · 1 comment · Fixed by #17
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@adobeDan
Copy link
Contributor

adobeDan commented Jan 16, 2021

Is your feature request related to a problem? Please describe.
In order to use the store and forward options effectively, there needs to be a way of exporting the stored requests that have no response, and importing forwarded responses to those requests.

(The import/export options are already defined but marked as not implemented in #7)

Describe the solution you'd like

  • Implement the export-file option by finding all the cached activation and deactivation requests without responses (which are those that are auto-forwarded by forward mode of operation), and exporting them to the named separate sqlite database which can be transported to a forwarding proxy. If the named export database already exists (e.g., from a prior export), then append to it.
  • Implement the import-file option by importing any activation requests and responses where the responses are newer than (or have different activation keys than) the existing activation requests and responses, and by removing any existing activation requests and responses for which (newer) matching deactivation responses exist in the import database.

Describe alternatives you've considered
There are two open questions about store/forward functionality:

  1. When handling deactivations imported from a forwarding server, should we remove all activation responses from the local server, or just the older activation responses. The only chance of a difference between the two behaviors comes if the server you are importing into is running in cache rather than store mode, which is arguably an error if you are importing forwarded responses.
  2. If there are newer activation requests for the same keys in the local server than there are in the forwarded responses, should we remove those requests in favor of the requests that were used by the forwarding server, or should we just import the responses and use them against future requests?

Additional context
If you think about how the cache works, you quickly realize that no client of a store server ever gets the response to its original request. Instead, the stored response from a forwarded request is returned after being "re-id'd" to match the client request. Thus, there isn't much point to importing activation requests from the forwarded server.

@adobeDan adobeDan added the enhancement New feature or request label Jan 16, 2021
@adobeDan adobeDan added this to the 1.0 milestone Jan 16, 2021
@adobeDan
Copy link
Contributor Author

The server currently doesn't keep deactivation responses; rather, it deletes any matching activation requests and responses. This actually doesn't allow for implementation of import, because we need to know the timestamp on the activation response. So to make this work we will need to keep at least successful deactivation response keys and timestamps, in order to apply them against existing caches.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants