-
Notifications
You must be signed in to change notification settings - Fork 242
Description
The data exchange plug-in starts up before FireFly and it has its own initialization process: reading configuration, key and certificate files, etc. It is possible that by the time FireFly starts, Data exchange is not ready to start storing/retrieving/transferring blobs or sending/receiving messages. To address this issue the following proposal is made:
A new endpoint /api/v1/initalization should be added to Data Exchange. On startup FireFly would make a call to this endpoint in order to verify if Data Exchange is ready or not. If Data Exchange is not ready (call returns an error) FireFly would retry a certain number of times with a predefined delay before giving up. The call to the new endpoint would be a POST so that it can include information that Data Exchange needs during initialization. The payload should include the list of FireFly nodes (currently available through /api/v1/network/nodes) which would allow Data Exchange to verify it contains the complete set of peer IDs and certificates. This would address the scenario where a temporary unavailability of the Data Exchange micro service could cause the add-peer API call to fail. It would also allow Data Exchange to become stateless, keeping peer information in memory.
In summary: on startup FireFly would invoke /api/v1/initalization on Data Exchange passing in the request body the list of nodes. The response will indicate if Data Exchange is ready to start working. If that's the case, FireFly continues to initialize normally, otherwise it will retry a set number of times with a predefined delay. If all those attempts fail, FireFly would handle the issue as it does today when the web socket connection to Data Exchange fails.