2018-10-20 04:53 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0005444Talerexchangepublic2018-10-19 11:09
ReporterFlorian Dold 
Assigned ToFlorian Dold 
PrioritylowSeverityminorReproducibilityhave not tried
StatusfeedbackResolutionopen 
Product Version 
Target VersionFixed in Version 
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.
Attached Files

-Relationships Relation Graph ] Dependency Graph ]
+Relationships

-Notes

~0013272

Christian Grothoff (manager)

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.

~0013273

Christian Grothoff (manager)

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.

~0013274

Christian Grothoff (manager)

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).

~0013275

Christian Grothoff (manager)

Need better instructions for how to reproduce ;-)
+Notes

-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
+Issue History