Even if B sees that the remote component for A received from C is not
monotonically increasing, would it make any difference in how region B
orders messages? What if B updated it's remote component for region A only
when the message it received has srcRegion as A ? That way we could still
guarantee that the remote components internally are monotonically
increasing and it would give us information on exactly how many messages a
region has seen from any of the other regions.

In the current scheme, after the merging, the remote component for region X
gives the maximum messageID that any of the regions have seen from X for
that topic.

Regards,
Aniruddha.

On Wed, May 9, 2012 at 4:19 AM, Ivan Kelly <[email protected]> wrote:

> On Tue, May 08, 2012 at 08:07:11PM -0700, Aniruddha Laud wrote:
> > When the RegionManager subscribes to topics from a remote hub, it gets
> > merges the remote component part of the received message with that of the
> > last persisted local message. The merge policy takes the maximum of the
> two
> > values for any region X in these two messages. Why exactly is this being
> > done? How is the remote component section from one region useful for hubs
> > in another region?
> My understanding of this code is that it is trying to ensure that the
> remote components for a topic are monotonically increasing in the view
> of a single region.
>
> Take the example of 3 regions, A,B&C, with topic t.
>
> A publishes message 1, which B and C receives with remote components
> [A:1,B:null,C:null].
>
> Now A publishs message 2, so which arrives quickly at B but with a
> delay at C.
>
> The last pushedSeqId for the topic is now
> at A: [A:2,B:null,C:null]
> at B: [A:2,B:null,C:null]
> at C: [A:1,B:null,C:null]
>
> C now publishes to topic t. The message has remote components of
> [A:1,B:null,C:1]
>
> When this arrives at B, if B does not do the merging, the client will
> see that the remote component for A is not increasing monotonically.
>
> Utkarsh can probably give you more detail on this.
>
> Regards
> Ivan
>

Reply via email to