If tests are run via gradle I get an error:
`Loading library prism_es2 from resource failed: java.lang.UnsatisfiedLinkError: Can't load library: /Users/dev/.openjfx/cache/16/libprism_es2.dylib`
If run from the IDE it works.
CI on windows also fails, other OS work.
Seems that there are some platfomr specific dependency issues...
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Make the 'dataMap' field a ConcurrentHashMap instead of a HashMap, to
prevent a ConcurrentModificationException, which was recently observed
when calling 'IgnoredMailboxMap::toProtoMessage' from the persistence
manager inside the user thread during startup of bisq-desktop. Tracing
through the code, this likely happened during an iteration through the
keyset of 'dataMap' (to check for nulls, inside the proto serialisation
logic during persistence), while simultaneously adding ignored mailbox
messages to the map on a separate thread spawned from the method,
'MailboxMessageService::threadedBatchProcessMailboxEntries'. (The latter
was made asynchronous so as not to block the UI.)
(Since there is a call to 'PersistenceManager::requestPersistence' after
every addition to the ignored mailbox map, there hopefully won't be any
missed entries in the final persisted map, even though the snapshot of
ConcurrentHashMap being iterated through won't be fresh as long as new
entries are simultaneously added.)
As the MarketPricePresentation constructor had anyway a ugly setup code we resolve it by refactoring it to a bit less ugly solution. ;-)
Remove the btcWalletService and feeService dependencies from MarketPricePresentation.
Do the setup of static fields in TxIdTextField and GUIUtil in the applyInjector method in BisqAppMain.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Make sure to include the BSQ stake, and not just the merit stake, when
summing to get the 'voteWeight' field of the vote on each evaluated
proposal in the exported vote results history JSON.
Avoid needlessly repetitive (once per cycle proposal) signature checking
of each 'Merit' object in the DAO state, when exporting the voting
history JSON, by moving the merit calculations to the outer loop over
each cycle, storing the sums in a map by blind vote txId. As signature
verification is expensive, taking seconds to run just once over every
'Merit' object, this is by far the biggest bottleneck when generating
the JSON.
Remove another hotspot in the proposals table creation for a selected
cycle, by making 'ballotByProposalTxIdMap' a field of 'VoteResultView',
recomputed at the same time the cycle list is populated upon calling
'doFillCycleListAndBallotMap()' (renamed from 'doFillCycleList'), when
the Vote Result view is activated.
Also remove an unnecessary outer loop when determining if the user's
vote is included in the result, upon selecting a cycle list item, to
avoid searching the BSQ wallet repeatedly for the same vote reveal tx.
The 'tableRow' field of each (voted upon) proposal list item is reset
upon selection of a cycle list item in the Vote Result view, but not set
anywhere, so remove the field along with its set/reset methods.
Reduce a hotspot searching the BSQ wallet for the user's votes, upon
selecting a list item of the Vote Result view, by optimising the method
'BsqWalletService.isWalletTransaction(String)'. Do this by adding a
lazily initialised Map field, 'walletTransactionsById', kept in sync
with the existing 'walletTransactions' List field, similar to the tx-by-
id cache removed from the base class in the previous commit, so that a
linear scan of that list can be avoided. Don't bother to make the cache
thread safe, however, since 'isWalletTransaction' is only called from
the user thread and wasn't thread safe to begin with -- access to
'walletTransactions' isn't synchronised, and it is updated only on the
user thread, after a 100 ms delay upon any changes to the BSQ wallet.
Also remove the unused methods 'getUnverifiedBsqTransactions()' and
'getBsqWalletTransactions()' from the class.
This was added in an earlier commit (57b2b4b8) to speed up the Trade
History view, via the method 'getConfidenceFotTxId(String)', by
replacing a linear scan of the live wallet txs with a lookup into a
lazily initialised map. However, the delegating 'WalletService' method
'getTransaction(Sha256Hash)' already serves this purpose, with
'o.b.w.Wallet' itself maintaining a map of all the wallet txs. Use that
method instead, taking care to exclude dead txs from the lookups, to
exactly preserve the current behaviour.
Also do some minor cleanup of the class, mainly to remove IDE warnings.
Run through the 'DecryptedBallotsWithMerits' list of each cycle in
parallel, when filling the cycle list of the Vote Result view, to speed
up the signature verification of all the 'Merit' objects found in the
DAO state. Checking all the signatures is necessary to correctly compute
the total merit stake and hence the vote weight of each ballot list, and
profiling shows that it is by far the biggest bottleneck during the
initial view load (with all subsequent activations of the view skipping
'doFillCycleList()', when outside of the Vote Result DAO phase).
(Since each signature is checked only once from 'doFillCycleList()' and
skipping the checks could potentially affect the computed vote weights,
we cannot obviously do any better than parallelise the checks, to speed
up this method.)
(Even though it may be a little more efficient to parallelise the outer
loop of the method, over the cycles instead of the decrypted votes of
each cycle, each individual signature check is expensive enough that it
probably wouldn't give much improvement over this one-line change.)
Uniformise the log patterns somewhat, by making the 'Logger' classname
field width either 15 for the seednode & statsnode, or 40 for the other
applications (lengthened from 30 in a few cases).
Also clean up the logback XML files somewhat, in particular removing
references to the old Thali (thaliproject/Tor_Onion_Proxy_Library) Tor
library, which was replaced years ago with our own fork of NetLayer
(https://github.com/cd2357/netlayer).
Finally, add a missing space back to the log pattern for bisq-desktop,
to prevent DEBUG, ERROR or TRACE lines appearing as follows:
... [JavaFX Application Thread] ERRORb.c.s.CommonSetup: ...
(It isn't clear whether this recently introduced behaviour was really
intentional, though it did prevent two consecutive spaces appearing in
the majority INFO log lines.)
Alleviate a cubic time bug during the update of the bonded roles
repository, reducing it to quadratic running time. On Mainnet, this
gives a roughly ten-fold speedup and should allow better scaling in the
event that many new bonded roles are added.
Replace calls to 'BondedRolesRepository.findBondedAssetByHash' with a
lookup into a lazily initialised map of bonded assets (Roles) by hash
(reset at the start of each call to 'BondRepository.update()' to prevent
stale caching). This avoids rescanning the roles list for every pair of
roles and lockup tx outputs, thus reducing the number of steps (to
highest order) from:
#roles * #roles * #lockup-tx-outputs
to:
#roles * #lockup-tx-outputs
(The logs show 2 or 3 calls to 'BondedRepository.update()' every time a
new block arrives, and while this was only taking around a second or so
on Mainnet, it could potentially grow to something problematic with
cubic scaling in the number of bonded roles.)
This should hopefully resolve images failing to load from resources
on Windows due to problems with imread encountering "can't open/read
file: check file path/integrity".
This restores the functionality that was removed in b5beea58. However,
this implementation utilizes the JavaCV library rather than the
webcam-capture library as discussed in #4940. As a result, this should
now provide macOS support.
In case the other seed node has not updated the historical data is not taken into account, thus we would get more repeated requests until all data is received. To avoid that we get stuck we increase the limit.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
3000 items are about 180.325 kB.
For nodes not being online for longer the repeated requests consumes quite some time.
With 15k we can expect a 1 MB payload which is still acceptable.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
