search

SatoshiPortal / cyphernode

Modular Bitcoin full-node microservices API server architecture and utilities toolkit to build scalable, secure and featureful apps and services without trusted third parties
MIT License
364 stars 68 forks source link

Liquid Branch - Stability Issues #214

Open xsats opened 3 years ago

xsats commented 3 years ago

I've been testing the liquid branch on regtest and mainnet a little and noticed that stopping then starting the elements container (with start.sh/stop.sh) causes a memory warning after first restart. The container then becomes stuck in a restarting cycle - I'm not sure what's causing this. For testing, deleting the chainstate+blocks offered a blunt rudimentary 'fix'. What's the best workaround currently?

In terms of the wider stability of the branch, what's needed to make it prod ready? Understand it's not pegged for the master branch yet, but eager to know what stage it's at in terms of stability. Thanks

Kexkey commented 3 years ago

Hi @xsats ! I think the problem is when elementsd is synchronizing after some time stopped, it executes the blocknotify command that curls the proxy (blocknotify=/usr/bin/curl proxy:8888/elements_newblock/%s) and that causes the proxy to check if it has liquid watch webhooks to process... (https://github.com/SatoshiPortal/cyphernode/blob/features/liquid/proxy_docker/app/script/elements_newblock.sh)

I added a flock and code to execute all that only 1/5 of the times, but it's still not the right way to do it. When elementsd catches up the mined blocks, it is very fast.

I need to think about some queueing of events instead of processing everything in real-time. Probably use the mosquito mqtt broker we already have in Cyphernode.