so, i finally nailed down the cause of the concurrency bug i was having with my relay
i had added a mutex on the majority of database transactions because in my firehose test i was getting all these nasty red errors saying "transaction conflict, please try again"
the mutex fixed it, but then when i actually tested it in operation, it was getting stuck, especially, on count requests
well, i removed the lock, and i will put it back, once i have audited all the database transaction code because clearly transactions are happening that stay open until some signal is sent and that's not how you do database transactions (nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 i assure you that there is several of these in your badger event store)
i had already bumped into this in a couple of places where transactions weren't getting locked into the database tx history and fixed them by flipping the loop from iterating a list inside the tx to iterating the list and then in each iteration making a tx
i'm just gonna go through all of the database transactions, because this is an error, it diminishes the atomicity of the database, and that makes it slower, ultimately
was such a relief to finally find i could just comment out a couple of mutex lock/unlocks in one place and voila fixed but those mutexes should be ok to have in there
final assessment of the grant project is up for 2 weeks time, and i'm quite sure i have got this now
nostr:npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl i'm gonna steal your idea of calling it #Layer2 #nostr event storage, ty :) because that's what it is essentially doing, and the way i have architected it, it could ultimately be coupled with a #blossom based event store if you build a blossom spider
that has a nice ring to it too... Blossom Spider
gonna probably use that too, later on, or someone else can steal it, this is the fun of this game... whoever puts it to use first gets the most kudos, open source FTW
#deardiary #devstr
Showing page 1 of
1 pages
