It is more convenient to handle the RejectedExecutionException in the calling code to get more context for error logging.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Use executor at httpClient builder.
Use httpClient.sendAsync.
Add keep-alive header.
Add RejectedExecutionHandler.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Use onDaoStateBlockCreated instead of onDaoStateHashesChanged to avoid multiple calls when we receive hashes from other nodes.
Add daoStateMonitoringService listener after blockchain parsing is completed
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Use newCachedThreadPool instead of getThreadPoolExecutor
Utilities.getThreadPoolExecutor use a BlockingQueue which prevents the intended
behaviour to increase the pool size to the max value.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
PaymentMethod use an instance of TradeLimits and expect that it
has been injected, which is the case for desktop but not for
headless apps, so we enforce injection in the app base classes
used for headless apps.
The validation of trade statistics use a method in PaymentMethod
where that dependency is required.
Tha hack how the PaymentMethod use TradeLimits is not nice, but
would require more effort for refactoring.
We shut down with a deterministic delay per seed to avoid that all seeds shut down at the
same time in case of a reorg. We use 30 sec. as distance delay between the seeds to be on the
safe side. We have 12 seeds so that's 6 minutes.
Migrate RpcService over to the new block notification daemon and RPC
client based on jsonrpc4j. Drop in own DTO classes in place of the ones
defined by btcd-cli4j and rename requestBtcBlock & addNewBtcBlockHandler
to requestDtoBlock & addNewDtoBlockHandler respectively.
Also remove now redundant filtering from the logback config and update
grade-witness.
now all dao store files and request a shut down of the app.
After a restart the resource files are used. This avoids cases where a resync from
genesis got triggered (observed on seed nodes, not on desktop apps).
Seed nodes and headless apps get shut down automatically.
In case of the desktop app we show a warn popup with shutdown
button and no close button, so we enforce a shutdown to avoid
complications in case the user would continue.
The install_collectd_debian.sh script reads user input to obtain the
onion address. However, when you pipe the output of curl into the shell
you're making the script text be standard input of the shell, which
takes it in as commands to run. After that, there's nothing left to
read. Even if it were to try, it wouldn't get anything from the terminal
input, because it's not connected to it. The pipe has replaced standard
input for the shell process.
Instead, create a pipe for bash to read the output of curl from and
provide it as the script file argument. In this case, the standard input
of the script is still connected to the terminal, and read will work.
* Add seednode service option to enable dumping Bisq Markets data
* Add seednode service setting for DAO fullnode true/false
* Add seednode installer feature to use existing btcnode P2P/RPC config
* Rename to generic "bisq" service, set entrypoint as conf variable
* Split seednode systemd service ExecStart command into multiple lines
* Add setting in seednode configuration to specify btcnode host/port
* Tweak seednode torrc configuration options to improve P2P connectivity
* Require bitcoin.service from bisq-seednode.service via systemd binding
* Make seednode installer run from master and build bisq from release tag
* Seednode must be shutdown using `kill -9` until #3884 is fixed
* Fix seednode uninstall script to use correct service names
* Disable CircuitBuildTimeout in seednode Tor configuration
* Disable seednode torrc advanced configuration options for now
Option handling is now the responsibility of the Config class. JOpt's
OptionParser is no longer passed down to BisqExecutable subclasses'
doExecute method, as they can now rely on the Config abstraction.
In previous commits, BisqEnvironment functionality has been fully ported
to the new, simpler and more type-safe Config class. This change removes
BisqEnvironment and all dependencies on the Spring Framework Environment
interface that it implements.
The one exception is the pricenode module, which is separate and apart
from the rest of the codebase in that it is a standalone, Spring-based
HTTP service.
Note that the default value of 600 advertised in BisqExecutable's option
handling was incorrect. The actual value had since become 1200 MB. This
correct default is now reflected in Config's option handling.
Prior to this commit, BisqExecutable has been responsible for parsing
command line and config file options and BisqEnvironment has been
responsible for assigning default values to those options and providing
access to option values to callers throughout the codebase.
This approach has worked, but at considerable costs in complexity,
verbosity, and lack of any type-safety in option values. BisqEnvironment
is based on the Spring Framework's Environment abstraction, which
provides a great deal of flexibility in handling command line options,
environment variables, and more, but also operates on the assumption
that such inputs have String-based values.
After having this infrastructure in place for years now, it has become
evident that using Spring's Environment abstraction was both overkill
for what we needed and limited us from getting the kind of concision and
type saftey that we want. The Environment abstraction is by default
actually too flexible. For example, Bisq does not want or need to have
environment variables potentially overriding configuration file values,
as this increases our attack surface and makes our threat model more
complex. This is why we explicitly removed support for handling
environment variables quite some time ago.
The BisqEnvironment class has also organically evolved toward becoming a
kind of "God object", responsible for more than just option handling. It
is also, for example, responsible for tracking the status of the user's
local Bitcoin node, if any. It is also responsible for writing values to
the bisq.properties config file when certain ban filters arrive via the
p2p network. In the commits that follow, these unrelated functions will
be factored out appropriately in order to separate concerns.
As a solution to these problems, this commit begins the process of
eliminating BisqEnvironment in favor of a new, bespoke Config class
custom-tailored to Bisq's needs. Config removes the responsibility for
option parsing from BisqExecutable, and in the end provides "one-stop
shopping" for all option parsing and access needs.
The changes included in this commit represent a proof of concept for the
Config class, where handling of a number of options has been moved from
BisqEnvironment and BisqExecutable over to Config. Because the migration
is only partial, both Config and BisqEnvironment are injected
side-by-side into calling code that needs access to options. As the
migration is completed, BisqEnvironment will be removed entirely, and
only the Config object will remain.
An additional benefit of the elimination of BisqEnvironment is that it
will allow us to remove our dependency on the Spring Framework (with the
exception of the standalone pricenode application, which is Spring-based
by design).
Note that while this change and those that follow it are principally a
refactoring effort, certain functional changes have been introduced. For
example, Bisq now supports a `--configFile` argument at the command line
that functions very similarly to Bitcoin Core's `-conf` option.
