swapstatus(requestid, quoteid) causes mm to hang

[lukechilds]

A separate issue related to #626 and following on from this suggestion: #600 (comment)

After the recentswaps/swapstatus(requestid, quoteid) refactor, when we get a matched swap from recentswaps and query the status with swapstatus(requestid, quoteid), swapstatus sometimes causes mm to hang.

We're polling it once a second to be able to show the live swap status in the UI. Not every request is slow, sometimes they go through in a few ms, but there are quite a few that take anywhere between 5-30 seconds. These requests cause mm to hang so it won't accept any other requests.

This means while a trade is in progress we can't update any other parts of the UI or do any more trades or any other actions involving mm, essentially locking up our UI for the duration of the trade.

[jl777]

I will add a fastflag so it will only do local filesystem accesses and not any blockchain (SPV) queries/tx attempts

[lukechilds]

Thanks, that sounds like it would solve the issue.

Just to get a better understanding of what's going on under the hood, what SPV queries are being done for swapstatus(requestid, quoteid)?

I had assumed you would have the swap status for requestid/quoteid in memory and swapstatus(requestid, quoteid) would just read the current data. Is that not how it works?

[jl777]

pushed a version to jl777 branch that supports "fast":1 flag for swapstatus call with requestid/quoteid, it will limit itself to local file access and should never take more than time for at most 10 HDD file accesses

also, moved the adding to the "list" file before the "pending" object is cleared, so you might see recentswaps return the same swap in its list and in the "pending" object, but this avoids the limbo state

[lukechilds]

With {fast: 1} we can now poll during a trade without it hanging, thanks!

[lukechilds]

Just to clarify, this specific issue is resolved but I'm still getting some short periods of mm hanging. Throughout the trade there were 4 separate periods where mm would ignore all requests for around 5-10 seconds.

However it doesn't appear to be consistently caused by a specific command, it seems like maybe when mm is busy doing something internally then it can't reply to any requests and queues them till it's ready.

This is much better than before but will still cause issues building a GUI with a good user experience. If there are regular random periods of 5-10 seconds during a trade where the GUI can't do anything, it'll still feel quite buggy.

However the proposed event based API will hopefully solve this issue so no point looking any further into this at the moment.

[jl777]

yes, a streamlined event driven path for all GUI required things is the way to go, there are just so many potential places that need to be serialized internally, unravelling that will not be practical without rewriting the entire codebase