A newly created offer has no OpenOffer+State (AVAILABLE || DEACTIVATED)
when displayed in the CLI's console. This change adds a 'bool isMyPendingOffer'
to the OfferInfo proto + wrapper, and the CLI's console offer output formatter
uses it to determine if it should display a new offer's Enabled column value
as PENDING, instead of an ambiguous NO value.
Using the API's CLI to edit offers can sometimes result in add/remove messages
being received on peers in the same batch of envolopes, and these messages
are sometimes passed to the UI in (1) add, (2) remove order. This can result in
a newly edited offer being removed immediately after being added to the OfferBook
list. This change uses storage entry sequence number and storage entry payload
hash comparisons to avoid the problem.
- OfferBookListItem Added new constructor taking P2PDataStorage.ByteArray hashOfPayload,
and int sequenceNumber params. Added a new toString() method.
- OfferBook Added new checks on OfferBookListItem hashOfPayload and sequenceNumber while
determining if offer candidates should be added or removed from the UI's OfferBook List.
See OfferBook contructor's implementation of OfferBookChangedListener#onAdded and
OfferBookChangedListener#onRemoved. Added many comments explaining the add/remove rules,
and plenty of debug statements to help trace the add/remove event process.
- OfferBookService#OfferBookChangedListener Added new P2PDataStorage.ByteArray hashOfPayload,
and int sequenceNumber params to listener's onAdded and onRemoved method signatures.
Added these two new paramater values to listener.onAdded and listener.onRemoved calls.
- TakeOfferDataModel Replaced unused, old tradeManager param in offerBook.removeOffer()
with (null) P2PDataStorage.ByteArray hashOfPayload, and (-1) int sequenceNumber params.
OfferBook will remove the candidate offer as before.
- MarketAlerts Adjusted onAdded() & onRemoved listener method signatures, even though
new P2PDataStorage.ByteArray hashOfPayload, int sequenceNumber params are not used
by the implementations.
Add it also before and after daoState monitor checks.
When letting the app run over night I saw that a lot of memory was not
released if System.gc() was not called.
By calling System.gc() it got to the expected state. Tested with the
G1 GC but saw similar behaviour with master with default GC version (parallel).
We could also run it periodically every 10 minutes or so, but I guess the block
interval covers that pretty good as well and those are the moment where load is
added and risk to run out of memory is higher.
We add a bit of delay to take into account that listeners might
react on the state change and to apply the gc after the event is processed completely.
- Run persistence call in thread instead of user thread (serialisation
is very slow and had blocked user thread)
- Create new snapshot only after persistence is completed to avoid to
have 3 daoState objects in memory
- Set DaoState in store to null to let gc remove the old reference (was
left there before so we had 3 instances of daoStates in memory)
Optionally displaying an ENABLED column in CLI side getoffer output
depends on the value of offer.isMyOffer, which is passed via new
boolean arguments to the trade & offer pojo builders.
