geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Baker <aba...@pivotal.io>
Subject Re: [DISCUSS] TTL setting on WAN
Date Wed, 20 Mar 2019 17:58:43 GMT
I think there are two modes:

1) The developer wants to replicate _events_.  This means all changes need to be sent to the
remote site regardless of the state in the local cluster.  Most likely in order :-)

2) The developer wants to replicate _state_.  This means that implicit state changes (expiration
or eviction w/ destroy) could allow us to optimize the queue size.  This is very similar to
conflation, just a different kind of optimization.

For this second case, does it make sense to allow the user to specify a different TTL than
the underlying region?  It seems like what the user wants is to not replicate stale data and
having an extra TTL attribute would just be another value to mis-configure.  What do you think
about just providing a boolean flag?

Anthony


> On Mar 20, 2019, at 10:25 AM, Anilkumar Gingade <agingade@pivotal.io> wrote:
> 
> +1. Will the expiration (destroy) be applied on local queues or the
> expiration will be replicated (for both serial and parallel)?
> 
> -Anil.
> 
> 
> On Wed, Mar 20, 2019 at 8:59 AM Bruce Schuchardt <bschuchardt@pivotal.io>
> wrote:
> 
>> We've seen situations where the receiving side of a WAN gateway is slow
>> to accept data or is not accepting any data.  This can cause queues to
>> fill up on the sending side.  If disk-overflow is being used this can
>> even lead to an outage.  Some users are concerned more with the latest
>> data and don't really care if old data is thrown away in this
>> situation.  They may have set a TTL on their Regions and would like to
>> be able to do the same thing with their GatewaySenders.
>> 
>> With that in mind I'd like to add this method to GatewaySenderFactory:
>> 
>> /** * Sets the timeToLive expiration attribute for queue entries for the
>> next * {@code GatewaySender} created. * * @param timeToLive the
>> timeToLive ExpirationAttributes for entries in this region * @return a
>> reference to this GatewaySenderFactory object * @throws
>> IllegalArgumentException if timeToLive is null * @see
>> RegionFactory#setEntryTimeToLive */ public GatewaySenderFactory
>> setEntryTimeToLive(ExpirationAttributes timeToLive);
>> 
>> The exact implementation may not be the same as for Regions since we
>> probably want to expire the oldest entries first and make sure we do so
>> in their order in the queue.
>> 
>> 


Mime
View raw message