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 <aging...@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 <bschucha...@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.
>>
>>
