You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem
We currently store the address book on the filesystem. This is sub-optimal because:
Eventually we'd like to remove the dependency on the filesystem
If we want to parallelize the processing of records (e.g. simultaneously processed catch up and current), those records may have a different address book in use at that particular point in time and we only store the latest on disk
If we have HA importers with leader election, only one will get the updated address book and the other will fail once it becomes primary
We currently store the address book on the filesystem which is sub optimal for reasons highlighted in #796
We want to be able to persist the address book details in the db for multiple future features
- Added V1_28_0 sql migration to create `address_book` and `address_book_entry `. Also updates `file_data` to have entityId and transaction types.
- Added `address_book` table to store address book files with columns for start and end consensus timestamps indicating what time range it was valid and raw bytes
- Added `address_book_entry ` tables to store node addresses with similar fields as NodeAddress proto
- Added `AddressBookService` interface
- Added `AddressBookServiceImpl` class that will check db for a valid address book. If not found it w
- Removed file system storage and reading of address book with support for loading bootstrap address book from file system or classpath
- Updated `AddressBookServiceImpl.update()` to handle `fileData` objects. Logic will store in `file_data`. If file is of append operation it will retrieve previous create/update and append operations bytes and concatenate them to create an addressBook. Object is then stored in `address_book` and `address_book_entry` tables
- Updated RecordEntityListener to support addressbook vs non-addressbook file parsing
- Updated `AddressBookServiceImpl` to handle update start and end timestamps of address book after network restart
- Added Java migration to parse all previous file_data rows for potential address books
Signed-off-by: Nana-EC <56320167+Nana-EC@users.noreply.github.com>
Problem
We currently store the address book on the filesystem. This is sub-optimal because:
Solution
address_book
with columns for start and end consensus timestamps indicating what time range it was validaddress_book_entry
with similar fields asNodeAddress
protoAlternatives
Store multiple address books on disk, sync them to other instances through other means
Additional Context
The text was updated successfully, but these errors were encountered: