archive snowblossom slack dev
prev 2018-07-24 next
2018-07-24 04:26:26
GitHub
[snowblossomcoin/snowblossom] Issue closed by fireduck64
2018-07-24 04:27:00
GitHub
[snowblossomcoin/snowblossom] Issue closed by fireduck64
2018-07-24 04:31:57
GitHub
[snowblossomcoin/snowblossom] Issue closed by fireduck64
2018-07-24 04:38:22
Clueless
@Fireduck nice, fixed the rocks db error? I believe that was our most common.
2018-07-24 04:38:37
GitHub
[snowblossomcoin/snowblossom] Issue closed by fireduck64
2018-07-24 04:38:59
Fireduck
@Clueless it was just a matter of wait for facebook to fix it
2018-07-24 04:39:04
Fireduck
they were aware of it
2018-07-24 04:39:21
Fireduck
it was some deep weird c++ compile issue with rocks db library
2018-07-24 04:39:42
Fireduck
have you seen the new jsonrpc on MrPlow?
2018-07-24 04:39:44
Fireduck
it is pretty sweet
2018-07-24 04:46:01
Fireduck
wrting params for jsonrpc send
2018-07-24 04:46:09
Fireduck
what should you call the address your are sending to?
2018-07-24 04:46:17
Fireduck
recipient is most correct, but i hate spelling that
2018-07-24 04:50:57
Clueless
To from?
2018-07-24 04:51:19
Clueless
from_address to_address
2018-07-24 04:51:30
Fireduck
from address isn't something you can control in this case
2018-07-24 04:51:33
Fireduck
at least not right now
2018-07-24 04:51:46
Clueless
input/output
2018-07-24 04:53:05
Fireduck
{ "jsonrpc": "2.0", "method": "send", "id": "send_test", "params": { "broadcast": true, "to": { "snowtest:j4hl7axx24yy9m3pfmag3a3jn26f20rwz3u9jhr9": 25, "snowtest:u4wmy9c8n56vd9285srvd4928ewm0urru2g7va2m": 50 } } }
2018-07-24 05:03:18
Fireduck
oh god, there are insane race conditions
2018-07-24 05:03:40
Fireduck
with the jsonrpc have to be ready for multiple things to happen at once
2018-07-24 05:03:46
Fireduck
which is fine
2018-07-24 05:04:03
Fireduck
but went building sends I need to make sure they don't use the same outputs
2018-07-24 05:04:35
Fireduck
the real solution is to have a pool of them in memory and let threads pull from them but that is a pain
2018-07-24 05:07:20
Fireduck
ok, I'll have something lock things while it is doing it
2018-07-24 05:07:35
Fireduck
which effectively serializes the operation, but it is proper
2018-07-24 05:07:42
Fireduck
and doing it better can be a later improvement
2018-07-24 08:47:30
Rotonen
java should have queue implementations built in?
2018-07-24 13:50:02
Fireduck
it has many
2018-07-24 14:02:21
Shoots
great work on the RPC :thumbsup:
2018-07-24 14:05:48
Fireduck
@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.
2018-07-24 14:06:23
Fireduck
Right now I have it synchronized, so it is basically only building a single tx at a time
2018-07-24 14:06:38
Fireduck
which is probably fine for now. Good to be safe and proper before fast.
2018-07-24 14:06:42
Fireduck
Can make it fast later.
2018-07-24 16:59:17
Rotonen
iirc java had fancy concurrent queue stuff for ~banking transaction queue processing
2018-07-24 17:02:39
Fireduck
absolutely. The concurrent queue is the easy part.
2018-07-24 17:03:14
Fireduck
The consistency I was talking about is making sure the spendable transaction outputs in the queue are still spendable
2018-07-24 17:03:39
Fireduck
since other transactions could be spending them from other clients, we could have block reorgs, etc