...
- recover link from tuple (sourceContainerId, targetContainerId, linkName)
- recover unsettled state
- high frequency & low latency update of unsettled state (JSON fail!)
- handle different DeliveryStates (AMQP 1.0 section 3.4)
Design
Brainstorming
- As is currently the case each VirtualHost should have its own registry.
- Both Sessions and Links are abstract immaterial concepts. The concrete objects are the SessionEndpoints and the LinkEndpoints.
For Sessions we already only have one object (called Session_1_0 to be aligned to the legacy protocols but this really is the SessionEndpoint).
We should do the same for Link/-Endpoints and get rid of one of them. Currently the responsibilities are very unclear and there seems to be no value.As is currently the case each VirtualHost should have its own registry. - The implementation of the registry should be hidden behind an API so for example we do not care whether sending links and receiving links are maintained in the same data structure or in separate data structures.
- We should discard the Endpoint upon Detach and recreate it upon Attach to make responsibilities clear.
- Given the remote container id and the link name a lookup should return a Terminus so that a LinkEndpoint (and thus a Link) can be recreated dynamically.
- Persistence of Termini and persistence of deliveryState/unsettled state separate?
- A registry unsettledStore should support different levels of capability in alignment with the TerminusDurability.
For example a Memory VH should not advertise any TerminusDurability, a JSON VirtualHost might be able to persist the configuration but not the settled state, while a BDB VH might support all three terminus durability modes.Given the remote container id and the link name a lookup should return a Terminus so that a LinkEndpoint (and thus a Link) can be recreated dynamically.Persistence of Termini and persistence of deliveryState/unsettled state separate? - This is another example of where we should differentiate between ConfigurableObjects and PersistentObjects which seems to be orthogonal concepts. LinkRegistry should be Persistent but not Configurable.
- Therefore, to not further make bad things worse separate out into distinct store? Same type as ConfigStore?
JSON:
Code Block language text { localContainerId1 : { "sending" : { remoteContainerId1 : { linkName1 : { SourceDef }, linkName2 : { SourceDef }, ... }, remoteContainerId2 : { linkName1 : { SourceDef }, ... }, ... } "receiving" : { remoteContainerId1 : { linkName1 : { TargetDef }, ... }, ... } }, localContainerId2 : { } }
- BDB either:
- key: (sourceContainerId, targetContainerId, linkName)
- value: TerminusDef
- key: (localContainerId, remoteContainerId, linkName)
- value: SourceDef or TargetDef
- JDBC
- COLUMNS: (sourceContainerId, targetContainerId, linkName, TerminusDef)
- COLUMNS: (localContainerId, remoteContainerId, linkName, SourceDef or TargetDef)
- The unsettled delivery map:
- JSON: not supported
- BDB:
- key: (sourceContainerId, targetContainerId, linkName, deliveryTag)
- value: deliveryState
- JDBC:
- COLUMNS: (ref to entry in above table, deliveryTag, deliveryState)
...