0

When I run curl http://127.0.0.1:8732/mempool/monitor_operations, the mempool contents are printed to the screen, and more data is printed as more operations come into the mempool (ie: stream of data) After some period of time, X, the connection is closed by the node.

During my tests, X can vary between a couple of seconds, to 15-20s. What determines X? What causes the stream data of monitor_operations to close? I'm assuming that in the RPC-node code, there is some condition that closes the stream; if so, what is that condition?

Improve this question

1 Answer 1

Reset to default
1

The node closes the stream when it changes its head.

When a block (most often the just received one) is chosen as the new head, the mempool is reset. Operations included in blocks are removed, valid operations and branch delayed operations are reconsidered (are they still/now valid?). You have to get these refreshed list of operations by restarting a fresh connection.

Improve this answer
3
  • What if I'm prio0 baker and I need to fetch endorsements? The mempool won't reset until after I submit my block. So how do I use monitor_operations if it never exits until I inject?
    – utdrmac ♦
    Sep 24, 2020 at 0:09
  • You can either use an equivalent of XMLHttpRequest.onprogress aka something that fires each time new data is received even if the request is not complete or you poll periodically /mempool/pending_operations that returns immediately instead.
    – Pierre Boutillier
    Sep 30, 2020 at 8:37
  • Ok. That's what I've been doing. I couldn't tell [what the baker](src/proto_006_PsCARTHA/lib_delegate/client_baking_forge.ml) was doing here. I see it is using monitor_operations but not seeing a timeout period.
    – utdrmac ♦
    Sep 30, 2020 at 15:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.