Reader Group Notifications continued

The number of revisions the observables can take depends on the next update from the reader group state change. Readers come online or go offline only once but their numbers in a reader group can vary. A stream having a lot of segments will have a large number of readers for uniform balancing. The reader group can even show the distribution of readers to segments.  The application can use the notifications and the reader distribution to scale up or down the readers. 

Since the synchronizer is the only one making the revisions with the help of a revisioned-stream client, it can synchronize the revisions made from across the processes. The synchronizer and therefore its client can be one per reader even as it synchronizes the state change per reader.  The call out here is that there are three stages to smooth out the notification process. First, is the detection of every state change such as the changes in the number of readers and the number of segments from all sources. For example, segment changes can come from both segment sealing and auto-scaling.  The changes in the readers can be detected if the reader group is kept notified. Second, each and every change should be serialized to the revisioned-stream. If the appends to the stream are skipped because the revision turns to be not as new as the most recent revision, then all the detection will still lead to lossy serialization. Third, the revisioned streams should be polled and read by notifier frequently so that all the events are sent to the notification system. If any of the events are skipped and the application is not informed, the notifications will not be accurate in their sequence. Each notification and the sequence of notifications are both useful to the application. 

One of the best ways to detect all reader group segment changes is to check the number of segments at the time of addmission of readers into the reader group.  

This would involve: 

Map<SegmentWithRange, Long> segments = ReaderGroupImpl.getSegmentsForStreams(controller, config); 

synchronizer.initialize(new ReaderGroupState.ReaderGroupStateInit(config, segments, getEndSegmentsForStreams(config))); 

Where the segments are read from the ReaderGroup which knows the segment map and the distribution of readers rather than getting the segments from the state.