Yes, then we are on the same page. There is no guarantee of ordering.
> On Mar 14, 2016, at 5:56 PM, Anilkumar Gingade <[email protected]> wrote:
>
> Wes, As I mentioned earlier; the ordering is maintained for a thread...We
> don't guarantee ordering of cache operations between multiple threads...
>
> -Anil.
>
>
>
>
> On Mon, Mar 14, 2016 at 2:51 PM, Real Wes Williams <[email protected]
> <mailto:[email protected]>> wrote:
> What about this scenario?
>
> regionA.put(“1”)
> Thread A - puts “1" into local region A
> Thread A - starts distribution to secondary region A’
>
> ====> Full GC pauses thread A <======
>
> regionB.put(“2”) on a different server node
> ThreadB - puts “2” into local region B
> ThreadB - completes distribution to secondary region B'
> ThreadB puts “2” onto client queue
>
> ThreadA wakes up
> ThreadA completes distribution to second region A’
> ThreadA puts “1” onto client queue
>
> Does the subscription queue know that it is “out of order” due to an internal
> timestamp receipt?
> If so, will the subscription queue put the events into the proper order
> before the queue ships back to the client?
> Does the subscription queue know to “wait” for the out-of-sequence event to
> come before shipping to the client?
>
>
>> On Mar 14, 2016, at 4:51 PM, Anilkumar Gingade <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Mike, With distributed ack (default for PartitionedRegion), the put
>> operation is not returned (to calling thread) until the events are added to
>> the client subscription queue...And in the subscription queue, we check for
>> out-of-order events....
>>
>> -Anil.
>>
>>
>> On Mon, Mar 14, 2016 at 1:18 PM, Michael Stolz <[email protected]
>> <mailto:[email protected]>> wrote:
>> Even if it's across 2 separate regions and the primaries aren't even located
>> on the same machine?
>> I don't think our guarantee of ordering goes that far.
>>
>> Two puts on the same key in the same region, yes they will be received in
>> order.
>>
>> Two puts on same or different keys in different regions, I don't believe so.
>>
>>
>> --
>> Mike Stolz
>> Principal Engineer, GemFire Product Manager
>> Mobile: 631-835-4771 <tel:631-835-4771>
>> On Mon, Mar 14, 2016 at 4:14 PM, Anilkumar Gingade <[email protected]
>> <mailto:[email protected]>> wrote:
>> If its the same thread that did the put; the client (any) will receive it in
>> order...We guarantee event ordering at thread level...
>>
>> -Anil.
>>
>>
>> On Mon, Mar 14, 2016 at 12:59 PM, Michael Stolz <[email protected]
>> <mailto:[email protected]>> wrote:
>> I'd say there's a pretty good chance of the ordering being different for two
>> different regions.
>>
>> --
>> Mike Stolz
>> Principal Engineer, GemFire Product Manager
>> Mobile: 631-835-4771 <tel:631-835-4771>
>> On Mon, Mar 14, 2016 at 3:52 PM, Randy May <[email protected]
>> <mailto:[email protected]>> wrote:
>> Suppose in a client, I do two puts in a particular order:
>>
>> regionA.put(K,V);
>> regionB.put(K,V);
>>
>> If another client has registered interest on both regions, is there any
>> guaranty about the order in which those 2 events are received on that client
>> ? If the client is using local cache, could there be a time when region B
>> contains the new value but region A contains the old value ?
>>
>>
>>
>>
>>
>
>
