[snowblossomcoin/snowblossom] Issue closed by fireduck64
[snowblossomcoin/snowblossom] Issue closed by fireduck64
[snowblossomcoin/snowblossom] Issue closed by fireduck64
@Fireduck nice, fixed the rocks db error? I believe that was our most common.
[snowblossomcoin/snowblossom] Issue closed by fireduck64
@Clueless it was just a matter of wait for facebook to fix it
they were aware of it
it was some deep weird c++ compile issue with rocks db library
have you seen the new jsonrpc on MrPlow?
it is pretty sweet
wrting params for jsonrpc send
what should you call the address your are sending to?
recipient is most correct, but i hate spelling that
To from?
from_address to_address
from address isn't something you can control in this case
at least not right now
input/output
{ "jsonrpc": "2.0", "method": "send", "id": "send_test", "params": { "broadcast": true, "to": { "snowtest:j4hl7axx24yy9m3pfmag3a3jn26f20rwz3u9jhr9": 25, "snowtest:u4wmy9c8n56vd9285srvd4928ewm0urru2g7va2m": 50 } } }
oh god, there are insane race conditions
with the jsonrpc have to be ready for multiple things to happen at once
which is fine
but went building sends I need to make sure they don't use the same outputs
the real solution is to have a pool of them in memory and let threads pull from them but that is a pain
ok, I'll have something lock things while it is doing it
which effectively serializes the operation, but it is proper
and doing it better can be a later improvement
java should have queue implementations built in?
it has many
great work on the RPC :thumbsup:
@Rotonen the problem isn't the queue, it is keeping it consistent as transactions are flowing. Which is doable, but takes some thought to get right.
Right now I have it synchronized, so it is basically only building a single tx at a time
which is probably fine for now. Good to be safe and proper before fast.
Can make it fast later.
iirc java had fancy concurrent queue stuff for ~banking transaction queue processing
absolutely. The concurrent queue is the easy part.
The consistency I was talking about is making sure the spendable transaction outputs in the queue are still spendable
since other transactions could be spending them from other clients, we could have block reorgs, etc