-
Notifications
You must be signed in to change notification settings - Fork 36.4k
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
[REST] Add memory pool API #6013
Conversation
Concept ACK |
ACK |
Concept ACK. |
Yup, I plan to add them in the evening or tomorrow. |
Array rpcParams; | ||
rpcParams.push_back(true); | ||
|
||
Value mempoolObject = getrawmempool(rpcParams, false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if we should just loop through RPC commands. I know that i did the same when i added the /chaininfos
REST command. This will tie the REST interface to the current RPC implementation. But duplicating code is also something we should avoid.
I don't have a solution here i just wanted to bring up this concern.
3779c93
to
d1f90f8
Compare
nit addressed, squashed, ready. |
Tested ACK. |
Other reviews, please? |
tested ACK |
Needs rebase. |
Rebased (changed the header style in README to match the other entries). |
Needs to be adapted to UniValue. Tomorrow. |
0188efb
to
da94f0d
Compare
Travis CI build fails only in one environment because of the comparison tool. |
I like this PR. But, am i alone with the feeling that calling a RPC method ( But however reACK. |
@jonasschnelli Something like I do not have a problem to refactor once agreed, but in the next PR please. |
No JSON conversion code inside core classes, please. That's something that belongs in the RPC glue layer. |
For sure we don't want json code within core classes. But i think calling a RPC function within REST should be avoided. Maybe something like |
@jonasschnelli Please review. Thanks. |
design wise this looks much better. |
Tested ACK. Two nits: |
@jonasschnelli Thanks for review.
|
If someone actively polls the mempool over REST, he could probably save CPU time and bandwidth if there would be a BIN/HEX support. But as said: low prio.
Thanks. Yes: https://github.com/bitcoin/bitcoin/pull/6013/files?1 (the 1 at the end helps) |
Hmm, 1 at the end seems to not have any effect here (compared with two curl calls and diff on the output). |
Rebased. |
re-ACK |
Needs rebase. |
d848fe6
to
42db8ae
Compare
Rebased (to accomodate #6504 changes). |
ACK |
####Memory pool | ||
`GET /rest/mempool/info.json` | ||
|
||
Returns various informations about the TX mempool. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: informations->information
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in the SQUASHME commit.
utACK |
@laanwj Can you please have a look. Thank you. |
I can merge, after this latest commit is squashed. |
Squashed. |
5b114eb
to
70180b2
Compare
const std::map<std::string, std::string>& mapHeaders, | ||
bool fRun) | ||
{ | ||
vector<string> params; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could (in the future) start adding std::
in front of such code, as that means we can more easily get rid of using namespace std;
:).
Re ACK |
ACK and merge is fine with me, I just comment when I've got time or start reading a pull, nothing more ;). |
utACK |
Bitcoin 0.12 mempool memory usage PRs Cherry-picked from the following upstream PRs: - bitcoin/bitcoin#6410 - bitcoin/bitcoin#6453 - bitcoin/bitcoin#6013 (excludes changes to docs we deleted) Part of #2074.
As requested in #5844, memory pool API added.
Get TX mempool info:
Get TX mempool contents: