client/core: OrderBook clarify cache usage#5
Open
norwnd wants to merge 2 commits into
Open
Conversation
norwnd
commented
Mar 9, 2023
Comment on lines
+223
to
231
| // Must be done with ob.noteQueueMtx locked, otherwise some notes might be sent | ||
| // to ob.noteQueue after we are done processing it. Such notes won't be processed | ||
| // until next processCachedNotes call when they'll be irrelevant and more | ||
| // importantly it means we won't apply them on top of server snapshot they were | ||
| // meant to be applied to. | ||
| ob.setSynced(true) | ||
|
|
||
| return nil | ||
| } |
Owner
Author
There was a problem hiding this comment.
Since cache isn't used (based on what I observed in the logs, and my current understanding of the relevant code), this fix is non-effectual really if #1 gets merged.
Moreover, we might not even need caching here really, so in the next PR I'll consider getting rid of it. But if OrderBook.noteQueue cache stays this is very much a necessary fix for it.
Owner
Author
There was a problem hiding this comment.
Thoughts on whether or not we need (to fix or reimplement) that caching there:
- there is a 1024+128 buffer in
commspackage to hold incoming WS messages, it seems like enough of a buffer to hold those server update notifications off for a while (and probably we can easily increase these number if necessary, probably want to add someTraceflogs to monitor saturation in case it gets dangerously high during network delays and whatnot; on master I'm getting single-digits numbers fornextJobsize during normal operation, don't imagine how this could get significantly worse unless we have ~x100 activity increase on DEX maybe) - ALL server notifications will be waiting behind one that got blocked (waiting on
dc.booksMtxfor example), it doesn't seems to be a big deal here cause we don't have to handle them in real time
norwnd
force-pushed
the
master
branch
4 times, most recently
from
ad9d264 to
e298e04
Compare
norwnd
force-pushed
the
master
branch
5 times, most recently
from
f9959eb to
a66bbae
Compare
norwnd
force-pushed
the
master
branch
3 times, most recently
from
e3c487c to
333e9f6
Compare
norwnd
pushed a commit
that referenced
this pull request
Apr 13, 2026
* client: Allow Firo to send to an EXX address. #4 EXX addresses are used for Firo and other privacy coins to send funds to Binance and other exchanges due to last US administration regulations. * imports: update go.mod for btcsuite/btcd/btcutil/base58 #5 * client: Add tests and tidy. - Add testnet tests - Add more Documentation * client/asset: re-implement using btc.PaymentScripter interface. * firo: Update Exx address related tests. - Also changed electrumx.sh to expose both TCP and SSL listening services on ports 50001 and 50002 respectively. * mm,libxc: Remove Firo from assetDisabled list. --------- Co-authored-by: dev-warrior777 <>
norwnd
pushed a commit
that referenced
this pull request
Apr 16, 2026
Second T18 batch — four more items from the consolidation list.
T18#5: formatProfit duplication
- Hoisted `formatProfit(profit)` to `hooks/useFormatters.ts` and
deleted the local copies in MMPage.tsx and MMArchivesPage.tsx.
The two versions were identical modulo the result-field name
(`cls` vs `colorClass`). Standardized on `cls` at the shared
location; updated MMArchivesPage's two call sites
(`total.colorClass`, `p.colorClass`) to `total.cls` / `p.cls`.
T18#3: MM URL building consistency
- MMArchivesPage's two navigation buttons previously built URLs via
manual template strings with individual encodeURIComponent calls.
Refactored to use URLSearchParams like MMPage.tsx does. Cleaner
and handles encoding automatically (though the previous manual
encoding was also correct).
T18#8: manage peers concurrent removal race
- Added a `removingAddrs: Set<string>` state to ManagePeers. The
removePeer callback now bails out if a removal POST for the same
address is already in flight, and the Remove icon for that row
renders as a spinner while the removal is pending. Uses
functional setState so rapid-fire clicks on different rows
don't read stale closure state. Prevents the last-one-wins
refresh() race when the user double-clicks the Remove icon.
T18#2: mw-500 consolidation
- Deleted `#proposals { max-width: 500px; width: 100% }` rule from
css/proposals.scss. ProposalsPage's `<section>` now uses the
shared `mw-500` utility class (already defined in
css/utilities.scss and already used by ProposalPage). Removed
the `id="proposals"` attribute since nothing else referenced it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Working on #1 I got a sense some
OrderBookstuff looks out of date. For example it hasnoteQueuethat never really gets used because update notifications can't make it there pastdc.booksMtxwhen it's locked forReset, and whendc.booksMtxis released there is no need for caching anymore (at least it should work like this with changes from #1; on master it might be used because of insufficient locking as per #1, and it's not fully atomic with respect tosynchedas is fixed in this PR).This PR mostly tries to better document those implicit assumptions we currently make about
OrderBook, and is a prerequisite ground work for the hopefully final step (which is to reduce the reliance ondc.booksMtx, effectively parallelising subscribe functionality by Market) meant to finish chain of changes #1 kicked off.