Versions Compared

Old Version 2

changes.mady.by.user Lorenz Quack

Saved on

compared with

New Version 3

changes.mady.by.user Lorenz Quack

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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.
  • A registry 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
      languagetexttitleJSON
      {
  localContainerId1 : {
    "sending" : {
      remoteContainerId1 : {
        linkName1 : { SourceDef },
        linkName2 : { SourceDef },
        ...
      },
      remoteContainerId2 : {
        linkName1 : { SourceDef },
        ...
      },
      ...
    }
    "receiving" : {
      remoteContainerId1 : {
        linkName1 : { TargetDef },
        ...
      },
      ...
    }
  },
  localContainerId2 : {
  }
}
    • BDB either:
      • key: (sourceContainerId, targetContainerId, linkName) 
      • value: TerminusDef
      or two tables for sending and receiving with:
      • key: (localContainerId, remoteContainerId, linkName) 
      • value: SourceDef or TargetDef
    • JDBC
      • COLUMNS: (sourceContainerId, targetContainerId, linkName, TerminusDef)
      or two tables for sending and receiving with:
      • 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)

 

API

  • VH.putLink(String remoteContrainerId, String linkName, Terminus terminus) -> Terminus
  • VH.putIfAbsentLink(String remoteContrainerId, String linkName, Terminus terminus) -> Terminus
  • VH.getLink(String remoteContrainerId, String linkName) -> Terminus
  • VH.removeLink(String remoteContrainerId, String linkName) -> Terminus

...