...
PlantUML |
---|
skinparam dpi 80 @startuml hide empty members title Server to Client Queues - Class Diagram class CacheClientNotifier { Singleton for a Cache. } class CacheClientProxy { One for each client. Keeps track of a the subscriptions for the client. } class MessageDispatcher { Thread that reads events from the queue. } class HARegionQueue { Holds the list of events to dispatch to a single client. } class HAContainerMap { Holds the actual values for events to dispatch. Used to store only a single copy of each value across all queues. } interface HAContainerMap CacheClientNotifier "1 " o-- "*" CacheClientProxy CacheClientProxy o-- MessageDispatcher CacheClientNotifier o-- HAContainerMap MessageDispatcher o-- HARegionQueue HARegionQueue "*" --> "1" HAContainerMap HARegionQueue o-- HARegion @enduml |
This next diagram focuses on cardinality:
- between
HARegionQueue
andDACE
(DispatchedAndCurrentEvents
) objects (through the mis-namedHARegionQueue.eventsMap
) - between
HARegion
and the two kinds of entries it holds:<Position,Conflatable>
and<ThreadIdentifier,SequenceID>
In both cases, the Java Map
s are depicted as associations in the diagram (the Map
objects are not shown explicitly). So, for instance HARegionQueue.eventsMap
is a Map
. It's depicted as a 1-to-(0..1 per Position)
association from HARegionQueue
to Position
. Similarly for HARegion
to Conflatable
and HARegion
to SequenceID
.
The diagram introduces two types not actually present in the Java code. Both are depicted as subtypes of Long
: SequenceID
to stand for an event's sequence id; and Position
to stand for a position in a queue. In the source code these are both just Long
s.
PlantUML |
---|
@startuml title HARegionQueue—Class Diagram\nHARegion and DACE Cardinalities class SequenceID <<design class>> Long <|-- SequenceID class Position <<design class>> Long <|-- Position class HARegionQueue { Position tailKey } class DispatchedAndCurrentEvents { SequenceID lastDispatchedSequenceID } ' these are together because I want to highlight the similarity (potential subtype relationship) together { ' putting this first causes it to be layed out to the right of ThreadIdentifier, making the ' association (line) from Conflatable shorter class EventID { byte[] membershipId long threadId SequenceID sequenceId int bucketId } class ThreadIdentifier { byte[] membershipId long threadId } } interface Conflatable ' these subtypes of Conflatable are grouped together together { interface ClientMessage class HAEventWrapper class ConflatableObject } Conflatable <|-- HAEventWrapper Conflatable <|-- ConflatableObject Conflatable <|-- ClientMessage interface ClientUpdateMessage ClientMessage <|-- ClientUpdateMessage ClientUpdateMessage <|-- ClientUpdateMessageImpl ClientUpdateMessageImpl <|-- ClientInstantiatorMessage ClientMessage <|-- ClientMarkerMessageImpl Conflatable --> EventID interface RegionQueue RegionQueue <|-- HARegionQueue HARegionQueue <|-- BlockingHARegionQueue BlockingHARegionQueue <|-- DurableHARegionQueue DistributedRegion <|-- HARegion ' while method signatures in HARegionQueue take Object, there's downcasting to Conflatable HARegion "*" *-- "0..1 per Position" Conflatable HARegion "*" *-- "0..1 per ThreadIdentifier" SequenceID HARegionQueue *-- HARegion HARegionQueue "1" *-- "0..1 per ThreadIdentifier" DispatchedAndCurrentEvents DispatchedAndCurrentEvents "1" *-- "0..1 per Position" Position ' this hidden assoc changes layout such that cardinality text on SequenceID and Position isn't overlapping as much ConflatableObject -[hidden]- HARegion @enduml |
Sequence Diagrams
PlantUML |
---|
skinparam dpi 80 title Put into Queue (for Partitioned Regions) actor user user -> "PR Primary" : put "PR Primary" -> "PR Secondary" : UpdateMessage "PR Primary" -> "Adjunct Receiver": PutMessage note right The primary notifies all members that have clients with interest end note "PR Primary" -> CacheClientNotifier: notifyClients() "Adjunct Receiver" -> CacheClientNotifier: notifyClients() note right All members with interest call notifyClients locally end note "PR Secondary" -> CacheClientNotifier: notifyClients() CacheClientNotifier -> CacheClientProxy: deliverMessage() CacheClientProxy -> MessageDispatcher : enqueueMessage() MessageDispatcher -> HARegionQueue: basicPut() |
...
1. The server is providing an initial image to a performed (see HARegionQueue.giiQueue)
2. The server A client is initializing in the process of registering and its message dispatcher as part of cliesnt queue initialization logic (see CacheClientProxy.queuedEvents)/queue are not fully created and initialized
After these operations are completed, the temporary queues are drained and the event is added to the HARegionQueue. The diagrams below show the different put paths in detail.
These diagrams show more detail around the special handling during client queue initialization or providing an initial image.
Delivering/Dispatching Events to Client:
...