View Issue Details

IDProjectCategoryView StatusLast Update
0005444Talerexchangepublic2021-01-01 16:51
ReporterFlorian Dold Assigned ToChristian Grothoff  
PrioritylowSeverityminorReproducibilityunable to reproduce
Status closedResolutionunable to reproduce 
Product Versiongit (master) 
Target Version0.6Fixed in Version0.6 
Summary0005444: melt transactions fail unexpectedly often
DescriptionWe relatively often get over 100 failed commits for the melt transaction. Maybe we are doing stuff inside the transaction that should be pulled outside?

Or alternatively, maybe the DB config is bad?
Steps To Reproducetaler-exchange-benchmark -c benchmark-local.conf -p 750 -n 500
TagsNo tags attached.

Activities

Christian Grothoff

2018-10-19 11:00

manager   ~0013272

I have trouble reproducing this. On which system did you run it? What is in benchmark-local.conf? Using 'benchmark.conf' on my desktop at home, this runs for a long time, but I don't get the 100-times-retried log message after waiting for like 5 minutes with CPUs all maxed out.

Christian Grothoff

2018-10-19 11:06

manager   ~0013273

I've now also manually checked the exchange logic. It does not really do any 'extra' work in terms of crypto that could be hoisted out. However, /refresh/melt fetches _more_ data than strictly required from the DB. There are two places: (1) when checking whether the same melt was already done, we fetch lots of data about the melt, but we only need the 32-bit noreveal index (gamma).
(2) when calculating whether the coin was over-spent, we fetch all of the associated signature/contract data of the coin's transaction history. *IF* there was no double-spending, we did this for naught. IF there was over-spending we do need it for the reply. So there is a potential _brittle_ optimization here to first only fetch the amounts, and then IF over-spending is detected fetch the rest. But this is dangerous: against malicious behavior we pretty much double the cost, and it is unclear whether fetching fewer bytes actually saves that much.

Christian Grothoff

2018-10-19 11:08

manager   ~0013274

Optimization #1 is now implemented in 9114794b..fb952bab (unsure if there is much of an effect, especially as during the benchmark in all cases we expect an empty response. Still, the resulting new SQL is simpler, might speed up 'something' or reduce evaluation conflicts).

Christian Grothoff

2018-10-19 11:09

manager   ~0013275

Need better instructions for how to reproduce ;-)

Christian Grothoff

2020-03-22 21:25

manager   ~0015461

I've done extensive trials and measurements, the issue is no longer reproducable.

Issue History

Date Modified Username Field Change
2018-09-27 14:18 Florian Dold New Issue
2018-09-27 14:18 Florian Dold Status new => assigned
2018-09-27 14:18 Florian Dold Assigned To => Christian Grothoff
2018-09-27 14:18 Florian Dold Summary melt transaction fail unexpectedly often => melt transactions fail unexpectedly often
2018-10-06 15:09 Christian Grothoff Priority normal => low
2018-10-19 11:00 Christian Grothoff Note Added: 0013272
2018-10-19 11:06 Christian Grothoff Note Added: 0013273
2018-10-19 11:08 Christian Grothoff Note Added: 0013274
2018-10-19 11:09 Christian Grothoff Assigned To Christian Grothoff => Florian Dold
2018-10-19 11:09 Christian Grothoff Status assigned => feedback
2018-10-19 11:09 Christian Grothoff Note Added: 0013275
2020-03-22 21:25 Christian Grothoff Assigned To Florian Dold => Christian Grothoff
2020-03-22 21:25 Christian Grothoff Reproducibility have not tried => unable to reproduce
2020-03-22 21:25 Christian Grothoff Status feedback => closed
2020-03-22 21:25 Christian Grothoff Product Version => git (master)
2020-03-22 21:25 Christian Grothoff Fixed in Version => 0.6
2020-03-22 21:25 Christian Grothoff Target Version => 0.6
2020-03-22 21:25 Christian Grothoff Note Added: 0015461
2021-01-01 16:51 Christian Grothoff Resolution open => unable to reproduce