You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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
export-file
option by finding all the cached activation and deactivation requests without responses (which are those that are auto-forwarded byforward
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.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:
cache
rather thanstore
mode, which is arguably an error if you are importing forwarded responses.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.
The text was updated successfully, but these errors were encountered: