We do not wait until the offer got removed by a network remove message but remove it
directly from the offer book. The broadcast gets now bundled and has 2 sec. delay so the
removal from the network is a bit slower as it has been before. To avoid that the taker gets
confused to see the same offer still in the offerbook we remove it manually. This removal has
only local effect. Other trader might see the offer for a few seconds
still (but cannot take it).
If we would add DisputeManager to previous structure it would cause a
circular dependency error from guice. We change dependency structure so
that TradeManager does not know XmrTxProofService but XmrTxProofService
gets an instance of TradeManager. It makes code cleaner in total as well
as responsibility is better defined.
Next commit will contain the DisputeManager addition.
On OSX InetAddress.getLocalHost() can cause problems. On my machine I
get a 5 sec. delay at each start up in localhost mode. The
InetAddress.getLoopbackAddress call is super fast.
Both versions connect to my local btc node, but not sure what can be
the differences if local environment is configured differently as
default. But as those issues with very slow getLocalHost lookup seems
to be more risky I would recommend that we change it.
It only affects localhost regtest mode and users who have a local btc
node running. The detection code for that is using getLoopbackAddress
as well.
See: a5cca0ee1e
Tested sequence:
1. waiting for response
2. receive TX_NOT_FOUND
3. receive PENDING_CONFIRMATIONS with 0 conf counting up to defined
requiredConf
4. success once required confs reached
- Fix bug with missing persist call
- Revert PENDING results to null when read from persistence as we dont
want to show latest pending state.
- Remove unused API_FAILURE
For tradeStateListener that would cause a wrong state as we would get
called after we have completed and do the isPayoutPublished check.
Keeping it in sync does remove the listener before we complete the
trade.
For autoConfirmSettings it would probably not cause and issue but as
we use a CopyOnWriteArrayList there the remove is safe anyway (to not
cause a ConcurrentListModification exception).
