Wiki source code of Generic replication framework architecture
Last modified by Thomas Mortagne on 2022/06/23 12:41
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
1.1 | 1 | {{plantuml}} |
| 2 | @startditaa | ||
| 3 | Instance A Instance B | ||
| 4 | +--------------------------------+ +--------------------------------+ | ||
| 5 | |Filesystem | | Filesystem| | ||
| 6 | | /---------------\| |/---------------\ | | ||
| 7 | | | Send Cache || || Receive Cache | | | ||
| 8 | | \---------------/| |\---------------/ | | ||
| 9 | | ^ | ^ | | ^ | ^ | | ||
| 10 | |----------------|------|------|-| |-|------|------|----------------| | ||
| 11 | | | v | | | | v | | | ||
| 12 | | | /---------\ | | | | /---------\ | | | ||
| 13 | | | | Send | | | | | | Receive | | | | ||
| |
3.1 | 14 | | | | Queue B | | | | | | Queue | | | |
| |
1.1 | 15 | | | \---------/ | | | | \---------/ | | |
| 16 | | | ^ | ^ | | | | ^ | ^ | | | ||
| 17 | |+--------+ | | | | | | | | | v | | +--------+| | ||
| 18 | || MyComp | +-------+ | | | | | | | +---------+ | MyComp || | ||
| 19 | || |-->| Sender| | | | | | | | | Receiver|-->| || | ||
| 20 | |+--------+ +-------+ v | | | | | | +---------+ +--------+| | ||
| 21 | | +----------+| HTTP |+----------+ | | ||
| 22 | | | HTTP ||--------->|| HTTP | | | ||
| 23 | | | Client || || Enpoints | | | ||
| 24 | | +----------+| |+----------+ | | ||
| 25 | +--------------------------------+ +--------------------------------+ | ||
| 26 | @endditaa | ||
| 27 | {{/plantuml}} | ||
| 28 | |||
| |
3.6 | 29 | A message is given to the sender which serialize it before putting it in the send queue associated to each instance to which the message need to be sent. The messages are picked from the queue and sent to each target instance through HTTP. |
| |
1.1 | 30 | |
| |
3.8 | 31 | The received message is serialized on target instance side, the serialized message is added to an handling memory queue and an HTTP response is sent. The messages are picked from the handling queue and provided to the receivers associated with each message type. |
| |
1.1 | 32 | |
| |
3.7 | 33 | If the target instance fail to serialize the message or is not reachable, the sender is going to retry the message after an increasing delay (retrying after 1s, then retrying after 2s, then 4s, etc. until reaching 2h delay where it keep trying 2h until it works). |
| 34 | A flush is triggered in the foillowing cases: | ||
| 35 | * the target instance is sending a ping (happen when the instance starts) | ||
| 36 | * massage is received from the target instance it trigger | ||
| 37 | * the administration UI expose a button to force the flush of wating messages | ||
| |
3.3 | 38 | |
| |
3.7 | 39 | If the the target instance respond that the message was stored sucessfully it's removed from the sender filesystem. |
| 40 | |||
| |
3.2 | 41 | If the sending instance crashes or is stopped before all the message are fully sent, they are loaded from the filesystem store during next init and reinjected in the send queue. |
| |
1.1 | 42 | If the receiving instance crash or is stopped before all the received message have been handled by receivers, they are loaded from the filesystem store during next init and reinjected in the receive queue. |
