Sounds like a good feature. I'm interested to see what ordering guarantees
we want to implement - if we can expire things in the order they were added
to the queue that seems like a good way to go.
As Anil pointed out - do you really want to let the user pass in an
ExpirationAttributes object? That allows the user to control the
ExpirationAction (destroy, invalidate, etc.). I don't think the
ExpirationAction makes sense for a GatewaySender?
-Dan
On Wed, Mar 20, 2019 at 10:26 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.
> >
> >
>
