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

should there be an endpoint to list cached transactions #42

Closed
edaniszewski opened this issue Feb 22, 2018 · 0 comments
Closed

should there be an endpoint to list cached transactions #42

edaniszewski opened this issue Feb 22, 2018 · 0 comments
Assignees

Comments

@edaniszewski
Copy link
Contributor

Description

We maintain a cache of transactions in synse server to do lookups and plugin-routing for the transaction command.

If we have a cache, we should be able to easily list the transactions we currently know about. This would require some changes for it to me more usable by a user (e.g. not just a list of hashes). we already track transaction context (action/raw) in the cache, but not the r/b/d that the write was issued to. we could add that to the cache as well for a more complete view.

the issue that this introduces is that it will only show transactions that are in the cache. there are a few things that fall out of that, but the biggest of which are:

  • if a synse server instance goes down and comes back up, the cache is empty. there is no way to rebuild the cache because there is no support via the gRPC API to get all transactions (though we could add this)
  • if there are multiple synse server instances interfacing with the same plugins, it could very well be the case that the transaction caches on each are different.

These would be solved by adding something to the gRPC API to enumerate active transactions tracked by the plugin, but doing so is a bit of work (has to be plumbed through a lot of places)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant