View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005444 | Taler | exchange | public | 2018-09-27 14:18 | 2021-01-01 16:51 |
| Reporter | Florian Dold | Assigned To | Christian Grothoff | ||
| Priority | low | Severity | minor | Reproducibility | unable to reproduce |
| Status | closed | Resolution | unable to reproduce | ||
| Product Version | git (master) | ||||
| Target Version | 0.6 | Fixed in Version | 0.6 | ||
| Summary | 0005444: melt transactions fail unexpectedly often | ||||
| Description | We 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 Reproduce | taler-exchange-benchmark -c benchmark-local.conf -p 750 -n 500 | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
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. |
|
|
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). |
|
|
Need better instructions for how to reproduce ;-) |
|
|
I've done extensive trials and measurements, the issue is no longer reproducable. |
| 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 |
