You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geode.apache.org by Randy May <ra...@mathysphere.com> on 2016/03/14 20:52:01 UTC

Order of Client Server Event Delivery

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 ?


Re: Order of Client Server Event Delivery

Posted by Udo Kohlmeyer <uk...@pivotal.io>.
Hi there Randy,

I assume that you would most likely have 2 interest registrations 
defined, one for regionA and one for regionB. Which means that they 
really are working in their own timings.

I think you could safely assume that they would not be delivered in 
order. Which would mean that there is a strong chance that regionB could 
contain a newer value before regionA is update.

--Udo

On 15/03/2016 6:52 am, Randy May 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 ?
>


Re: Order of Client Server Event Delivery

Posted by Udo Kohlmeyer <uk...@pivotal.io>.
I would believe that given you are dealing with 2 regions and 2 
registered interests, there would still be some semblance of 
"out-of-order" that could creep in. I don't think one should rely on the 
fact that two delivery systems will keep order.

--Udo

On 15/03/2016 7:32 am, John Blum wrote:
> To be precise, I mean a "cache" transaction.
>
> On Mon, Mar 14, 2016 at 1:31 PM, John Blum <jblum@pivotal.io 
> <ma...@pivotal.io>> wrote:
>
>     W/hat about wrapping the 2 Regions in a transaction?
>
>     On Mon, Mar 14, 2016 at 1:18 PM, Michael Stolz <mstolz@pivotal.io
>     <ma...@pivotal.io>> 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
>         <agingade@pivotal.io <ma...@pivotal.io>> 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
>             <mstolz@pivotal.io <ma...@pivotal.io>> 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
>                 <randy@mathysphere.com <ma...@mathysphere.com>>
>                 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 ?
>
>
>
>
>
>
>
>     -- 
>     -John
>     503-504-8657 <tel:503-504-8657>
>     john.blum10101 (skype)
>
>
>
>
> -- 
> -John
> 503-504-8657
> john.blum10101 (skype)


Re: Order of Client Server Event Delivery

Posted by John Blum <jb...@pivotal.io>.
To be precise, I mean a "cache" transaction.

On Mon, Mar 14, 2016 at 1:31 PM, John Blum <jb...@pivotal.io> wrote:

> W/hat about wrapping the 2 Regions in a transaction?
>
> On Mon, Mar 14, 2016 at 1:18 PM, Michael Stolz <ms...@pivotal.io> 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
>>
>> On Mon, Mar 14, 2016 at 4:14 PM, Anilkumar Gingade <ag...@pivotal.io>
>> 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 <ms...@pivotal.io>
>>> 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
>>>>
>>>> On Mon, Mar 14, 2016 at 3:52 PM, Randy May <ra...@mathysphere.com>
>>>> 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 ?
>>>>>
>>>>>
>>>>
>>>
>>
>
>
> --
> -John
> 503-504-8657
> john.blum10101 (skype)
>



-- 
-John
503-504-8657
john.blum10101 (skype)

Re: Order of Client Server Event Delivery

Posted by John Blum <jb...@pivotal.io>.
W/hat about wrapping the 2 Regions in a transaction?

On Mon, Mar 14, 2016 at 1:18 PM, Michael Stolz <ms...@pivotal.io> 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
>
> On Mon, Mar 14, 2016 at 4:14 PM, Anilkumar Gingade <ag...@pivotal.io>
> 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 <ms...@pivotal.io>
>> 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
>>>
>>> On Mon, Mar 14, 2016 at 3:52 PM, Randy May <ra...@mathysphere.com>
>>> 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 ?
>>>>
>>>>
>>>
>>
>


-- 
-John
503-504-8657
john.blum10101 (skype)

Re: Order of Client Server Event Delivery

Posted by Real Wes Williams <Th...@outlook.com>.
Yes, then we are on the same page. There is no guarantee of ordering.

> On Mar 14, 2016, at 5:56 PM, Anilkumar Gingade <ag...@pivotal.io> 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 <TheRealWes@outlook.com <ma...@outlook.com>> 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 <agingade@pivotal.io <ma...@pivotal.io>> 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 <mstolz@pivotal.io <ma...@pivotal.io>> 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 <agingade@pivotal.io <ma...@pivotal.io>> 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 <mstolz@pivotal.io <ma...@pivotal.io>> 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 <randy@mathysphere.com <ma...@mathysphere.com>> 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 ?
>> 
>> 
>> 
>> 
>> 
> 
> 


Re: Order of Client Server Event Delivery

Posted by Anilkumar Gingade <ag...@pivotal.io>.
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 <Th...@outlook.com>
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 <ag...@pivotal.io>
> 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 <ms...@pivotal.io> 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
>>
>> On Mon, Mar 14, 2016 at 4:14 PM, Anilkumar Gingade <ag...@pivotal.io>
>> 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 <ms...@pivotal.io>
>>> 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
>>>>
>>>> On Mon, Mar 14, 2016 at 3:52 PM, Randy May <ra...@mathysphere.com>
>>>> 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 ?
>>>>>
>>>>>
>>>>
>>>
>>
>
>

Re: Order of Client Server Event Delivery

Posted by Real Wes Williams <Th...@outlook.com>.
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 <ag...@pivotal.io> 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 <mstolz@pivotal.io <ma...@pivotal.io>> 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 <agingade@pivotal.io <ma...@pivotal.io>> 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 <mstolz@pivotal.io <ma...@pivotal.io>> 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 <randy@mathysphere.com <ma...@mathysphere.com>> 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 ?
> 
> 
> 
> 
> 


Re: Order of Client Server Event Delivery

Posted by Anilkumar Gingade <ag...@pivotal.io>.
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 <ms...@pivotal.io> 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
>
> On Mon, Mar 14, 2016 at 4:14 PM, Anilkumar Gingade <ag...@pivotal.io>
> 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 <ms...@pivotal.io>
>> 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
>>>
>>> On Mon, Mar 14, 2016 at 3:52 PM, Randy May <ra...@mathysphere.com>
>>> 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 ?
>>>>
>>>>
>>>
>>
>

Re: Order of Client Server Event Delivery

Posted by Michael Stolz <ms...@pivotal.io>.
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

On Mon, Mar 14, 2016 at 4:14 PM, Anilkumar Gingade <ag...@pivotal.io>
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 <ms...@pivotal.io> 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
>>
>> On Mon, Mar 14, 2016 at 3:52 PM, Randy May <ra...@mathysphere.com> 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 ?
>>>
>>>
>>
>

Re: Order of Client Server Event Delivery

Posted by Anilkumar Gingade <ag...@pivotal.io>.
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 <ms...@pivotal.io> 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
>
> On Mon, Mar 14, 2016 at 3:52 PM, Randy May <ra...@mathysphere.com> 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 ?
>>
>>
>

Re: Order of Client Server Event Delivery

Posted by Michael Stolz <ms...@pivotal.io>.
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

On Mon, Mar 14, 2016 at 3:52 PM, Randy May <ra...@mathysphere.com> 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 ?
>
>