Modular Bitcoin full-node microservices API server architecture and utilities toolkit to build scalable, secure and featureful apps and services without trusted third parties
Make Core’s blocknotify calls queue (using MQTT) and processed serially instead of in parallel like right now … when Cyphernode has been down for a while, the Node syncing and calling blocknotify in batch can make CN crash or at least very slow
I experience this with liquid, because of the 3-minute blocks, when the instance is down for like 1 hour, that makes a burst of requests to CN and creates OS threads that can sometimes end up with OOM crashes
Meaning: blocknotify calls /newblock/blockhash … those would queue the request instead of execute it.
The first step is to have core publish new block events to the broker and to have the proxy dequeue those events. The end goal is to have the dequeuing and processing done in Go or Rust instead of a shell script.
It will be possible to re-use and build on top of the existing test cases. Maybe add even more chaos and fuzzing !
Kexkey
commented
1 year ago
Make Core’s blocknotify calls queue (using MQTT) and processed serially instead of in parallel like right now … when Cyphernode has been down for a while, the Node syncing and calling blocknotify in batch can make CN crash or at least very slow
I experience this with liquid, because of the 3-minute blocks, when the instance is down for like 1 hour, that makes a burst of requests to CN and creates OS threads that can sometimes end up with OOM crashes
Meaning: blocknotify calls /newblock/blockhash … those would queue the request instead of execute it.
The first step is to have core publish new block events to the broker and to have the proxy dequeue those events. The end goal is to have the dequeuing and processing done in Go or Rust instead of a shell script.
It will be possible to re-use and build on top of the existing test cases. Maybe add even more chaos and fuzzing !