There is 1 comment.
 
 
XWiki Platform / cid:jira-generated-image-avatar-c0fc0e1d-3ae0-4ccd-acd1-7cab14dc0b24 XWIKI-25270 Open

Notifications of events produced by a cluster member that never comes back are never sent

 
View issue   ยท   Add comment
 

1 comment

 
cid:jira-generated-image-avatar-b686adf5-f857-45f6-b0c6-d5e98d487af0 Claude on 12/Oct/26 11:32
 

Precisions on the proposed change, which the description does not mention:

  • Only the events produced from observation.remote.reclaimMaxAge (1 day by default) before the member left are taken over: older events of that member stay undispatched (their number is logged). This avoids old alerts and immediate live mails for old events after an upgrade of a cluster which ran with changing identifiers. The events produced up to observation.remote.reclaimDelay after the departure (as seen by the cluster singleton node) are included, so that a clock difference between the members does not leave events behind.
  • The pending live notification mails are resumed first, then the undispatched events are dispatched, each member being taken over once while the same member is the cluster singleton node. The events of each member gone for good are queried separately, so the number of such members does not change the size of the queries.
  • Mails can still be sent twice in these cases: a member which comes back while its mails are being taken over (each user and each event is checked, but the mails already queued by the cluster singleton node are sent by it), a change of cluster singleton node during a take-over, a network partition longer than observation.remote.reclaimDelay, and an event whose dispatch was interrupted after some of its mails were created (an existing limitation, the same as at a restart).