[DISCUSS] TTL setting on WAN

[Bruce Schuchardt]

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.

Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch

[Alexander Murmann]

Dale, do I understand correctly that the only concern around the Micrometer
work right now it that it's not useful yet, however it's not harmful either?

Dave, is it correct that if that PR doesn't make it into the newly cut
branch, we'd be shipping with a older version of geode-native? What are the
two versions and what would be the implications of this not making it into
this release?

On Tue, Mar 19, 2019 at 5:29 PM Dave Barnes  wrote:

> The Geode 1.9.0 release includes a source-only release of the geode-native
> repo. There's a pull-request in process to update version numbers and the
> doc build environment in that repo; should be ready to merge tomorrow
> morning.
>
> On Tue, Mar 19, 2019 at 5:20 PM Dale Emery  wrote:
>
> > The Micrometer API is in, and marked as experimental. But we have not yet
> > updated CacheFactory to allow injecting a meter registry (or metrics
> > publishing service) there. So currently the only way to publish is to add
> > metrics publishing service via the ServiceLoader mechanism.
> >
> > —
> > Dale Emery
> > dem...@pivotal.io
> >
> >
> > > On Mar 19, 2019, at 3:29 PM, Dan Smith  wrote:
> > >
> > > Is the geode-managability sub-project and the new micrometer API in a
> > place
> > > where we can cut a release branch? I know a bunch of changes have gone
> in
> > > since the release branch, are we comfortable releasing these new
> > > experimental features as they are right now?
> > >
> > > -Dan
> > >
> > > On Tue, Mar 19, 2019 at 2:38 PM Dick Cavender 
> wrote:
> > >
> > >> +1 to re-cutting the 1.9 release branch off a more stable develop sha
> > >> within the last couple days.
> > >>
> > >> On Tue, Mar 19, 2019 at 1:14 PM Bruce Schuchardt <
> > bschucha...@pivotal.io>
> > >> wrote:
> > >>
> > >>> If we recut the release branch we need to update JIRA tickets marked
> > >>> fixed in 1.10
> > >>>
> > >>> On 3/19/19 12:48 PM, Sai Boorlagadda wrote:
> > > It was known at the time that develop was not as stable as desired,
> >  so we planned to cherry-pick fixes from develop until the release
> >  branch was stable enough to ship.
> >  I want to clarify that we decided to cut the release branch not that
> >  develop was not stable. But really that it is desirable to cut the
> >  branch sooner to avoid any regression risk that can be introduced by
> >  on-going work on develop.
> > 
> >  Nevertheless looks like develop is more stable than release branch
> due
> >  to some test fixes that were not cherry-picked into the release
> > branch.
> >  I think its a good idea to re-cut the branch as our current position
> >  to stabilize release branch before releasing.
> > 
> >  +1 to re-cut.
> > 
> >  Sai
> > 
> >  On Tue, Mar 19, 2019 at 12:19 PM Owen Nichols  >  > wrote:
> > 
> > The Geode 1.9.0 release branch was originally cut 4 weeks ago on
> > Feb 19.  It was known at the time that develop was not as stable
> > as desired, so we planned to cherry-pick fixes from develop until
> > the release branch was stable enough to ship.  While this is a
> > good strategy when starting from a fairly good baseline, it seems
> > in this case it has only added complexity without leading to
> > stability.
> > 
> > Looking at the pipelines over the last week (see attached
> > metrics), it appears we have been far more successful at
> > stabilizing /develop/ than /release/1.9.0/. Rather than trying to
> > cherry-pick more and more fixes to the release branch, I propose
> > we RE-CUT the 1.9.0 release branch later this week in order to
> > start from a much more stable baseline.
> > 
> > -Owen
> > 
> > 
> > 
> > >>>
> > >>
> >
> >
>

Re: [DISCUSS] TTL setting on WAN

[Anilkumar Gingade]

+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 
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.
>
>

Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch

[Dave Barnes]

The geode-native PR will be ready to check in momentarily. Just waiting for
Travis to do its diligence.

On Wed, Mar 20, 2019 at 9:47 AM Alexander Murmann 
wrote:

> Dale, do I understand correctly that the only concern around the Micrometer
> work right now it that it's not useful yet, however it's not harmful
> either?
>
> Dave, is it correct that if that PR doesn't make it into the newly cut
> branch, we'd be shipping with a older version of geode-native? What are the
> two versions and what would be the implications of this not making it into
> this release?
>
> On Tue, Mar 19, 2019 at 5:29 PM Dave Barnes  wrote:
>
> > The Geode 1.9.0 release includes a source-only release of the
> geode-native
> > repo. There's a pull-request in process to update version numbers and the
> > doc build environment in that repo; should be ready to merge tomorrow
> > morning.
> >
> > On Tue, Mar 19, 2019 at 5:20 PM Dale Emery  wrote:
> >
> > > The Micrometer API is in, and marked as experimental. But we have not
> yet
> > > updated CacheFactory to allow injecting a meter registry (or metrics
> > > publishing service) there. So currently the only way to publish is to
> add
> > > metrics publishing service via the ServiceLoader mechanism.
> > >
> > > —
> > > Dale Emery
> > > dem...@pivotal.io
> > >
> > >
> > > > On Mar 19, 2019, at 3:29 PM, Dan Smith  wrote:
> > > >
> > > > Is the geode-managability sub-project and the new micrometer API in a
> > > place
> > > > where we can cut a release branch? I know a bunch of changes have
> gone
> > in
> > > > since the release branch, are we comfortable releasing these new
> > > > experimental features as they are right now?
> > > >
> > > > -Dan
> > > >
> > > > On Tue, Mar 19, 2019 at 2:38 PM Dick Cavender 
> > wrote:
> > > >
> > > >> +1 to re-cutting the 1.9 release branch off a more stable develop
> sha
> > > >> within the last couple days.
> > > >>
> > > >> On Tue, Mar 19, 2019 at 1:14 PM Bruce Schuchardt <
> > > bschucha...@pivotal.io>
> > > >> wrote:
> > > >>
> > > >>> If we recut the release branch we need to update JIRA tickets
> marked
> > > >>> fixed in 1.10
> > > >>>
> > > >>> On 3/19/19 12:48 PM, Sai Boorlagadda wrote:
> > > > It was known at the time that develop was not as stable as
> desired,
> > >  so we planned to cherry-pick fixes from develop until the release
> > >  branch was stable enough to ship.
> > >  I want to clarify that we decided to cut the release branch not
> that
> > >  develop was not stable. But really that it is desirable to cut the
> > >  branch sooner to avoid any regression risk that can be introduced
> by
> > >  on-going work on develop.
> > > 
> > >  Nevertheless looks like develop is more stable than release branch
> > due
> > >  to some test fixes that were not cherry-picked into the release
> > > branch.
> > >  I think its a good idea to re-cut the branch as our current
> position
> > >  to stabilize release branch before releasing.
> > > 
> > >  +1 to re-cut.
> > > 
> > >  Sai
> > > 
> > >  On Tue, Mar 19, 2019 at 12:19 PM Owen Nichols <
> onich...@pivotal.io
> > >  > wrote:
> > > 
> > > The Geode 1.9.0 release branch was originally cut 4 weeks ago
> on
> > > Feb 19.  It was known at the time that develop was not as
> stable
> > > as desired, so we planned to cherry-pick fixes from develop
> until
> > > the release branch was stable enough to ship.  While this is a
> > > good strategy when starting from a fairly good baseline, it
> seems
> > > in this case it has only added complexity without leading to
> > > stability.
> > > 
> > > Looking at the pipelines over the last week (see attached
> > > metrics), it appears we have been far more successful at
> > > stabilizing /develop/ than /release/1.9.0/. Rather than trying
> to
> > > cherry-pick more and more fixes to the release branch, I
> propose
> > > we RE-CUT the 1.9.0 release branch later this week in order to
> > > start from a much more stable baseline.
> > > 
> > > -Owen
> > > 
> > > 
> > > 
> > > >>>
> > > >>
> > >
> > >
> >
>

Re: [DISCUSS] TTL setting on WAN

[Dan Smith]

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 
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 
> 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.
> >
> >
>

Re: [DISCUSS] TTL setting on WAN

[Bruce Schuchardt]

IDK Anil, we'll figure that out in the implementation.  I was thinking 
it would be in the dispatch threads, so if distribution is need that 
will happen as it does now.  I'm hopeful that this won't perturb the 
code too much.


One thing that was brought up to me in person was the Dead Letter Queue 
 
initiative that seems to have stalled.  That seems like a very similar 
idea though it's reacting to errors coming from the receiving side and 
not a local condition.  I like the callback, stats, gfsh and cluster 
config integration in that write-up & think they might be useful here.  
There is also relevant discussion in that page about things like PDX 
registrations.  Is that initiative going to move forward at some point 
or is it off the boards?


On 3/20/19 10:25 AM, Anilkumar Gingade 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 
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.

Re: [DISCUSS] TTL setting on WAN

[Bruce Schuchardt]

Dan, I agree - there shouldn't be a choice of action here.  We can 
change it to just take an int and specify in the docs that it is in 
seconds and will cause timed-out events to not be transmitted to the 
other site.


I think we want to guarantee that time-out happens in queue order.

On 3/20/19 10:32 AM, Dan Smith wrote:

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 
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 
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.

Re: [DISCUSS] TTL setting on WAN

[Udo Kohlmeyer]

-1, I don't believe this is a feature that we should support. IF a 
client is experiencing slow WAN replication and users only care about 
the "latest" data, then maybe the user should use "conflation".


With a TTL model, we are messing with our consistency tenet. I'm am NOT 
in support of a setting that can cause inconsistency.


Dead-letter queues is another area that WILL cause data/site 
inconsistency. I think we really have to take a step back, think about 
WHAT tenets are important to GEODE and then act accordingly.


--Udo

On 3/20/19 10:46, Bruce Schuchardt wrote:
IDK Anil, we'll figure that out in the implementation.  I was thinking 
it would be in the dispatch threads, so if distribution is need that 
will happen as it does now.  I'm hopeful that this won't perturb the 
code too much.


One thing that was brought up to me in person was the Dead Letter 
Queue 
 
initiative that seems to have stalled.  That seems like a very similar 
idea though it's reacting to errors coming from the receiving side and 
not a local condition.  I like the callback, stats, gfsh and cluster 
config integration in that write-up & think they might be useful 
here.  There is also relevant discussion in that page about things 
like PDX registrations.  Is that initiative going to move forward at 
some point or is it off the boards?


On 3/20/19 10:25 AM, Anilkumar Gingade 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 


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.

Re: [DISCUSS] TTL setting on WAN

[Bruce Schuchardt]

Udo, in the cases I've looked at the user is okay with inconsistency 
because they don't really care about the old data. They're most 
interested in getting the newest data and keeping the sending site from 
going down.  I guess the docs for TTL should make it very clear that it 
will cause inconsistencies.


Conflation does seem like an appropriate thing to try if the same keys 
are being updated - I'll do some investigation and see why it wasn't 
appropriate.



On 3/20/19 10:51 AM, Udo Kohlmeyer wrote:
-1, I don't believe this is a feature that we should support. IF a 
client is experiencing slow WAN replication and users only care about 
the "latest" data, then maybe the user should use "conflation".


With a TTL model, we are messing with our consistency tenet. I'm am 
NOT in support of a setting that can cause inconsistency.


Dead-letter queues is another area that WILL cause data/site 
inconsistency. I think we really have to take a step back, think about 
WHAT tenets are important to GEODE and then act accordingly.


--Udo

On 3/20/19 10:46, Bruce Schuchardt wrote:
IDK Anil, we'll figure that out in the implementation.  I was 
thinking it would be in the dispatch threads, so if distribution is 
need that will happen as it does now.  I'm hopeful that this won't 
perturb the code too much.


One thing that was brought up to me in person was the Dead Letter 
Queue 
 
initiative that seems to have stalled.  That seems like a very 
similar idea though it's reacting to errors coming from the receiving 
side and not a local condition.  I like the callback, stats, gfsh and 
cluster config integration in that write-up & think they might be 
useful here.  There is also relevant discussion in that page about 
things like PDX registrations.  Is that initiative going to move 
forward at some point or is it off the boards?


On 3/20/19 10:25 AM, Anilkumar Gingade 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 


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.

Re: [DISCUSS] TTL setting on WAN

[Anthony Baker]

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  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 
> 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.
>> 
>> 

Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch

[Dale Emery]

Hi Alexander,


> On Mar 20, 2019, at 9:47 AM, Alexander Murmann  wrote:
> 
> Dale, do I understand correctly that the only concern around the Micrometer
> work right now it that it's not useful yet, however it's not harmful either?

It’s useful, but somewhat less usable than we want it to be. Currently the only 
way to publish the metrics is to implement a service loader. Dan suggested that 
we offer additional ways that are easier for Geode users. For example, passing 
a “publishing registry” to the cache factory. We think that’s a great idea, and 
we promised to do it, but haven’t done it yet.

Cheers,
Dale

—
Dale Emery
dem...@pivotal.io

Re: [DISCUSS] TTL setting on WAN

[Udo Kohlmeyer]

If all that the customer is concerned about is that the receiving side 
gets the "latest" data, conflation is definitely the best bet. How do we 
classify old? The only classification that I have of old (in this 
context) is that there is a newer version of a data entry. This 
classification is not time based, as a TTL approach would require, but 
state.


What is the use of WAN replication if we are proposing to only replicate 
*some* of the data. How would the clusters ever know if they are 
in-sync? I believe we are just opening a door that we will never be able 
to close again and will cause us endless issues.


--Udo

On 3/20/19 10:56, Bruce Schuchardt wrote:
Udo, in the cases I've looked at the user is okay with inconsistency 
because they don't really care about the old data. They're most 
interested in getting the newest data and keeping the sending site 
from going down.  I guess the docs for TTL should make it very clear 
that it will cause inconsistencies.


Conflation does seem like an appropriate thing to try if the same keys 
are being updated - I'll do some investigation and see why it wasn't 
appropriate.



On 3/20/19 10:51 AM, Udo Kohlmeyer wrote:
-1, I don't believe this is a feature that we should support. IF a 
client is experiencing slow WAN replication and users only care about 
the "latest" data, then maybe the user should use "conflation".


With a TTL model, we are messing with our consistency tenet. I'm am 
NOT in support of a setting that can cause inconsistency.


Dead-letter queues is another area that WILL cause data/site 
inconsistency. I think we really have to take a step back, think 
about WHAT tenets are important to GEODE and then act accordingly.


--Udo

On 3/20/19 10:46, Bruce Schuchardt wrote:
IDK Anil, we'll figure that out in the implementation.  I was 
thinking it would be in the dispatch threads, so if distribution is 
need that will happen as it does now.  I'm hopeful that this won't 
perturb the code too much.


One thing that was brought up to me in person was the Dead Letter 
Queue 
 
initiative that seems to have stalled.  That seems like a very 
similar idea though it's reacting to errors coming from the 
receiving side and not a local condition.  I like the callback, 
stats, gfsh and cluster config integration in that write-up & think 
they might be useful here.  There is also relevant discussion in 
that page about things like PDX registrations.  Is that initiative 
going to move forward at some point or is it off the boards?


On 3/20/19 10:25 AM, Anilkumar Gingade 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 


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.

Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch

[Dave Barnes]

geode-native is ready to into the 1.9 release candidate build.

On Wed, Mar 20, 2019 at 10:42 AM Dave Barnes  wrote:

> The geode-native PR will be ready to check in momentarily. Just waiting
> for Travis to do its diligence.
>
> On Wed, Mar 20, 2019 at 9:47 AM Alexander Murmann 
> wrote:
>
>> Dale, do I understand correctly that the only concern around the
>> Micrometer
>> work right now it that it's not useful yet, however it's not harmful
>> either?
>>
>> Dave, is it correct that if that PR doesn't make it into the newly cut
>> branch, we'd be shipping with a older version of geode-native? What are
>> the
>> two versions and what would be the implications of this not making it into
>> this release?
>>
>> On Tue, Mar 19, 2019 at 5:29 PM Dave Barnes  wrote:
>>
>> > The Geode 1.9.0 release includes a source-only release of the
>> geode-native
>> > repo. There's a pull-request in process to update version numbers and
>> the
>> > doc build environment in that repo; should be ready to merge tomorrow
>> > morning.
>> >
>> > On Tue, Mar 19, 2019 at 5:20 PM Dale Emery  wrote:
>> >
>> > > The Micrometer API is in, and marked as experimental. But we have not
>> yet
>> > > updated CacheFactory to allow injecting a meter registry (or metrics
>> > > publishing service) there. So currently the only way to publish is to
>> add
>> > > metrics publishing service via the ServiceLoader mechanism.
>> > >
>> > > —
>> > > Dale Emery
>> > > dem...@pivotal.io
>> > >
>> > >
>> > > > On Mar 19, 2019, at 3:29 PM, Dan Smith  wrote:
>> > > >
>> > > > Is the geode-managability sub-project and the new micrometer API in
>> a
>> > > place
>> > > > where we can cut a release branch? I know a bunch of changes have
>> gone
>> > in
>> > > > since the release branch, are we comfortable releasing these new
>> > > > experimental features as they are right now?
>> > > >
>> > > > -Dan
>> > > >
>> > > > On Tue, Mar 19, 2019 at 2:38 PM Dick Cavender 
>> > wrote:
>> > > >
>> > > >> +1 to re-cutting the 1.9 release branch off a more stable develop
>> sha
>> > > >> within the last couple days.
>> > > >>
>> > > >> On Tue, Mar 19, 2019 at 1:14 PM Bruce Schuchardt <
>> > > bschucha...@pivotal.io>
>> > > >> wrote:
>> > > >>
>> > > >>> If we recut the release branch we need to update JIRA tickets
>> marked
>> > > >>> fixed in 1.10
>> > > >>>
>> > > >>> On 3/19/19 12:48 PM, Sai Boorlagadda wrote:
>> > > > It was known at the time that develop was not as stable as
>> desired,
>> > >  so we planned to cherry-pick fixes from develop until the release
>> > >  branch was stable enough to ship.
>> > >  I want to clarify that we decided to cut the release branch not
>> that
>> > >  develop was not stable. But really that it is desirable to cut
>> the
>> > >  branch sooner to avoid any regression risk that can be
>> introduced by
>> > >  on-going work on develop.
>> > > 
>> > >  Nevertheless looks like develop is more stable than release
>> branch
>> > due
>> > >  to some test fixes that were not cherry-picked into the release
>> > > branch.
>> > >  I think its a good idea to re-cut the branch as our current
>> position
>> > >  to stabilize release branch before releasing.
>> > > 
>> > >  +1 to re-cut.
>> > > 
>> > >  Sai
>> > > 
>> > >  On Tue, Mar 19, 2019 at 12:19 PM Owen Nichols <
>> onich...@pivotal.io
>> > >  > wrote:
>> > > 
>> > > The Geode 1.9.0 release branch was originally cut 4 weeks ago
>> on
>> > > Feb 19.  It was known at the time that develop was not as
>> stable
>> > > as desired, so we planned to cherry-pick fixes from develop
>> until
>> > > the release branch was stable enough to ship.  While this is a
>> > > good strategy when starting from a fairly good baseline, it
>> seems
>> > > in this case it has only added complexity without leading to
>> > > stability.
>> > > 
>> > > Looking at the pipelines over the last week (see attached
>> > > metrics), it appears we have been far more successful at
>> > > stabilizing /develop/ than /release/1.9.0/. Rather than
>> trying to
>> > > cherry-pick more and more fixes to the release branch, I
>> propose
>> > > we RE-CUT the 1.9.0 release branch later this week in order to
>> > > start from a much more stable baseline.
>> > > 
>> > > -Owen
>> > > 
>> > > 
>> > > 
>> > > >>>
>> > > >>
>> > >
>> > >
>> >
>>
>

Re: [DISCUSS] TTL setting on WAN

[Dan Smith]

> 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?
>
>
This kinda jogged my memory. AsyncEventQueues actually *do* have a boolean
flag to allow you to forward expiration events to the queue. I have no idea
how this interacts with conflation though -
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/asyncqueue/AsyncEventQueueFactory.html#setForwardExpirationDestroy-boolean-

Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch

[Alexander Murmann]

Dale, is there any downside to making these changes in 1.10 other than
plainly having them later?

On Wed, Mar 20, 2019 at 11:15 AM Dave Barnes  wrote:

> geode-native is ready to into the 1.9 release candidate build.
>
> On Wed, Mar 20, 2019 at 10:42 AM Dave Barnes  wrote:
>
> > The geode-native PR will be ready to check in momentarily. Just waiting
> > for Travis to do its diligence.
> >
> > On Wed, Mar 20, 2019 at 9:47 AM Alexander Murmann 
> > wrote:
> >
> >> Dale, do I understand correctly that the only concern around the
> >> Micrometer
> >> work right now it that it's not useful yet, however it's not harmful
> >> either?
> >>
> >> Dave, is it correct that if that PR doesn't make it into the newly cut
> >> branch, we'd be shipping with a older version of geode-native? What are
> >> the
> >> two versions and what would be the implications of this not making it
> into
> >> this release?
> >>
> >> On Tue, Mar 19, 2019 at 5:29 PM Dave Barnes  wrote:
> >>
> >> > The Geode 1.9.0 release includes a source-only release of the
> >> geode-native
> >> > repo. There's a pull-request in process to update version numbers and
> >> the
> >> > doc build environment in that repo; should be ready to merge tomorrow
> >> > morning.
> >> >
> >> > On Tue, Mar 19, 2019 at 5:20 PM Dale Emery  wrote:
> >> >
> >> > > The Micrometer API is in, and marked as experimental. But we have
> not
> >> yet
> >> > > updated CacheFactory to allow injecting a meter registry (or metrics
> >> > > publishing service) there. So currently the only way to publish is
> to
> >> add
> >> > > metrics publishing service via the ServiceLoader mechanism.
> >> > >
> >> > > —
> >> > > Dale Emery
> >> > > dem...@pivotal.io
> >> > >
> >> > >
> >> > > > On Mar 19, 2019, at 3:29 PM, Dan Smith  wrote:
> >> > > >
> >> > > > Is the geode-managability sub-project and the new micrometer API
> in
> >> a
> >> > > place
> >> > > > where we can cut a release branch? I know a bunch of changes have
> >> gone
> >> > in
> >> > > > since the release branch, are we comfortable releasing these new
> >> > > > experimental features as they are right now?
> >> > > >
> >> > > > -Dan
> >> > > >
> >> > > > On Tue, Mar 19, 2019 at 2:38 PM Dick Cavender 
> >> > wrote:
> >> > > >
> >> > > >> +1 to re-cutting the 1.9 release branch off a more stable develop
> >> sha
> >> > > >> within the last couple days.
> >> > > >>
> >> > > >> On Tue, Mar 19, 2019 at 1:14 PM Bruce Schuchardt <
> >> > > bschucha...@pivotal.io>
> >> > > >> wrote:
> >> > > >>
> >> > > >>> If we recut the release branch we need to update JIRA tickets
> >> marked
> >> > > >>> fixed in 1.10
> >> > > >>>
> >> > > >>> On 3/19/19 12:48 PM, Sai Boorlagadda wrote:
> >> > > > It was known at the time that develop was not as stable as
> >> desired,
> >> > >  so we planned to cherry-pick fixes from develop until the
> release
> >> > >  branch was stable enough to ship.
> >> > >  I want to clarify that we decided to cut the release branch not
> >> that
> >> > >  develop was not stable. But really that it is desirable to cut
> >> the
> >> > >  branch sooner to avoid any regression risk that can be
> >> introduced by
> >> > >  on-going work on develop.
> >> > > 
> >> > >  Nevertheless looks like develop is more stable than release
> >> branch
> >> > due
> >> > >  to some test fixes that were not cherry-picked into the release
> >> > > branch.
> >> > >  I think its a good idea to re-cut the branch as our current
> >> position
> >> > >  to stabilize release branch before releasing.
> >> > > 
> >> > >  +1 to re-cut.
> >> > > 
> >> > >  Sai
> >> > > 
> >> > >  On Tue, Mar 19, 2019 at 12:19 PM Owen Nichols <
> >> onich...@pivotal.io
> >> > >  > wrote:
> >> > > 
> >> > > The Geode 1.9.0 release branch was originally cut 4 weeks
> ago
> >> on
> >> > > Feb 19.  It was known at the time that develop was not as
> >> stable
> >> > > as desired, so we planned to cherry-pick fixes from develop
> >> until
> >> > > the release branch was stable enough to ship.  While this
> is a
> >> > > good strategy when starting from a fairly good baseline, it
> >> seems
> >> > > in this case it has only added complexity without leading to
> >> > > stability.
> >> > > 
> >> > > Looking at the pipelines over the last week (see attached
> >> > > metrics), it appears we have been far more successful at
> >> > > stabilizing /develop/ than /release/1.9.0/. Rather than
> >> trying to
> >> > > cherry-pick more and more fixes to the release branch, I
> >> propose
> >> > > we RE-CUT the 1.9.0 release branch later this week in order
> to
> >> > > start from a much more stable baseline.
> >> > > 
> >> > > -Owen
> >> > > 
> >> > > 
> >> > > 
> >> > > >>>
> >> > > >>
> >> > >
> >> > >
> >> >
> >>
> >
>


-- 
Alexander J. Murmann
(650) 2

Re: [DISCUSS] TTL setting on WAN

[Bruce Schuchardt]

I don't know why the users didn't use conflation but I suspect they're 
generating events with new keys.  Conflation only applies if you're 
operating on the same keys all the time.  If you're generating new keys 
it doesn't help at all.


On 3/20/19 11:10 AM, Udo Kohlmeyer wrote:
If all that the customer is concerned about is that the receiving side 
gets the "latest" data, conflation is definitely the best bet. How do 
we classify old? The only classification that I have of old (in this 
context) is that there is a newer version of a data entry. This 
classification is not time based, as a TTL approach would require, but 
state.


What is the use of WAN replication if we are proposing to only 
replicate *some* of the data. How would the clusters ever know if they 
are in-sync? I believe we are just opening a door that we will never 
be able to close again and will cause us endless issues.


--Udo

On 3/20/19 10:56, Bruce Schuchardt wrote:
Udo, in the cases I've looked at the user is okay with inconsistency 
because they don't really care about the old data. They're most 
interested in getting the newest data and keeping the sending site 
from going down.  I guess the docs for TTL should make it very clear 
that it will cause inconsistencies.


Conflation does seem like an appropriate thing to try if the same 
keys are being updated - I'll do some investigation and see why it 
wasn't appropriate.



On 3/20/19 10:51 AM, Udo Kohlmeyer wrote:
-1, I don't believe this is a feature that we should support. IF a 
client is experiencing slow WAN replication and users only care 
about the "latest" data, then maybe the user should use "conflation".


With a TTL model, we are messing with our consistency tenet. I'm am 
NOT in support of a setting that can cause inconsistency.


Dead-letter queues is another area that WILL cause data/site 
inconsistency. I think we really have to take a step back, think 
about WHAT tenets are important to GEODE and then act accordingly.


--Udo

On 3/20/19 10:46, Bruce Schuchardt wrote:
IDK Anil, we'll figure that out in the implementation.  I was 
thinking it would be in the dispatch threads, so if distribution is 
need that will happen as it does now.  I'm hopeful that this won't 
perturb the code too much.


One thing that was brought up to me in person was the Dead Letter 
Queue 
 
initiative that seems to have stalled.  That seems like a very 
similar idea though it's reacting to errors coming from the 
receiving side and not a local condition.  I like the callback, 
stats, gfsh and cluster config integration in that write-up & think 
they might be useful here.  There is also relevant discussion in 
that page about things like PDX registrations.  Is that initiative 
going to move forward at some point or is it off the boards?


On 3/20/19 10:25 AM, Anilkumar Gingade 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 


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.

Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch

[Dale Emery]

> On Mar 20, 2019, at 11:25 AM, Alexander Murmann  wrote:
> 
> Dale, is there any downside to making these changes in 1.10 other than
> plainly having them later?

I don’t think so, but I’d want to hear Dan’s opinion on that, given that his 
approval of our PR was contingent on our promise to do it.

FYI, the additional work to improve usability is non-trivial, which is why we 
haven’t done it already.

—
Dale Emery
dem...@pivotal.io



> On Mar 20, 2019, at 11:25 AM, Alexander Murmann  wrote:
> 
> Dale, is there any downside to making these changes in 1.10 other than
> plainly having them later?
> 
> On Wed, Mar 20, 2019 at 11:15 AM Dave Barnes  wrote:
> 
>> geode-native is ready to into the 1.9 release candidate build.
>> 
>> On Wed, Mar 20, 2019 at 10:42 AM Dave Barnes  wrote:
>> 
>>> The geode-native PR will be ready to check in momentarily. Just waiting
>>> for Travis to do its diligence.
>>> 
>>> On Wed, Mar 20, 2019 at 9:47 AM Alexander Murmann 
>>> wrote:
>>> 
 Dale, do I understand correctly that the only concern around the
 Micrometer
 work right now it that it's not useful yet, however it's not harmful
 either?
 
 Dave, is it correct that if that PR doesn't make it into the newly cut
 branch, we'd be shipping with a older version of geode-native? What are
 the
 two versions and what would be the implications of this not making it
>> into
 this release?
 
 On Tue, Mar 19, 2019 at 5:29 PM Dave Barnes  wrote:
 
> The Geode 1.9.0 release includes a source-only release of the
 geode-native
> repo. There's a pull-request in process to update version numbers and
 the
> doc build environment in that repo; should be ready to merge tomorrow
> morning.
> 
> On Tue, Mar 19, 2019 at 5:20 PM Dale Emery  wrote:
> 
>> The Micrometer API is in, and marked as experimental. But we have
>> not
 yet
>> updated CacheFactory to allow injecting a meter registry (or metrics
>> publishing service) there. So currently the only way to publish is
>> to
 add
>> metrics publishing service via the ServiceLoader mechanism.
>> 
>> —
>> Dale Emery
>> dem...@pivotal.io
>> 
>> 
>>> On Mar 19, 2019, at 3:29 PM, Dan Smith  wrote:
>>> 
>>> Is the geode-managability sub-project and the new micrometer API
>> in
 a
>> place
>>> where we can cut a release branch? I know a bunch of changes have
 gone
> in
>>> since the release branch, are we comfortable releasing these new
>>> experimental features as they are right now?
>>> 
>>> -Dan
>>> 
>>> On Tue, Mar 19, 2019 at 2:38 PM Dick Cavender 
> wrote:
>>> 
 +1 to re-cutting the 1.9 release branch off a more stable develop
 sha
 within the last couple days.
 
 On Tue, Mar 19, 2019 at 1:14 PM Bruce Schuchardt <
>> bschucha...@pivotal.io>
 wrote:
 
> If we recut the release branch we need to update JIRA tickets
 marked
> fixed in 1.10
> 
> On 3/19/19 12:48 PM, Sai Boorlagadda wrote:
>>> It was known at the time that develop was not as stable as
 desired,
>> so we planned to cherry-pick fixes from develop until the
>> release
>> branch was stable enough to ship.
>> I want to clarify that we decided to cut the release branch not
 that
>> develop was not stable. But really that it is desirable to cut
 the
>> branch sooner to avoid any regression risk that can be
 introduced by
>> on-going work on develop.
>> 
>> Nevertheless looks like develop is more stable than release
 branch
> due
>> to some test fixes that were not cherry-picked into the release
>> branch.
>> I think its a good idea to re-cut the branch as our current
 position
>> to stabilize release branch before releasing.
>> 
>> +1 to re-cut.
>> 
>> Sai
>> 
>> On Tue, Mar 19, 2019 at 12:19 PM Owen Nichols <
 onich...@pivotal.io
>> > wrote:
>> 
>>   The Geode 1.9.0 release branch was originally cut 4 weeks
>> ago
 on
>>   Feb 19.  It was known at the time that develop was not as
 stable
>>   as desired, so we planned to cherry-pick fixes from develop
 until
>>   the release branch was stable enough to ship.  While this
>> is a
>>   good strategy when starting from a fairly good baseline, it
 seems
>>   in this case it has only added complexity without leading to
>>   stability.
>> 
>>   Looking at the pipelines over the last week (see attached
>>   metrics), it appears we have been far more successful at
>>   stabilizing /develop/ than /release/1.9.0/. Rather than
 trying to
>>   cherry-pick more and more fixes to the re

Re: [DISCUSS] TTL setting on WAN

[Anthony Baker]

An important use case for this is session caching.  Obviously it’s pointless to 
replicate an expired session—the user has already gone away.  Copying the bits 
to the remote cluster is just creating unnecessary work.

> On Mar 20, 2019, at 11:22 AM, Bruce Schuchardt  wrote:
> 
> I don't know why the users didn't use conflation but I suspect they're 
> generating events with new keys.  Conflation only applies if you're operating 
> on the same keys all the time.  If you're generating new keys it doesn't help 
> at all.
> 
> On 3/20/19 11:10 AM, Udo Kohlmeyer wrote:
>> If all that the customer is concerned about is that the receiving side gets 
>> the "latest" data, conflation is definitely the best bet. How do we classify 
>> old? The only classification that I have of old (in this context) is that 
>> there is a newer version of a data entry. This classification is not time 
>> based, as a TTL approach would require, but state.
>> 
>> What is the use of WAN replication if we are proposing to only replicate 
>> *some* of the data. How would the clusters ever know if they are in-sync? I 
>> believe we are just opening a door that we will never be able to close again 
>> and will cause us endless issues.
>> 
>> --Udo
>> 
>> On 3/20/19 10:56, Bruce Schuchardt wrote:
>>> Udo, in the cases I've looked at the user is okay with inconsistency 
>>> because they don't really care about the old data. They're most interested 
>>> in getting the newest data and keeping the sending site from going down.  I 
>>> guess the docs for TTL should make it very clear that it will cause 
>>> inconsistencies.
>>> 
>>> Conflation does seem like an appropriate thing to try if the same keys are 
>>> being updated - I'll do some investigation and see why it wasn't 
>>> appropriate.
>>> 
>>> 
>>> On 3/20/19 10:51 AM, Udo Kohlmeyer wrote:
 -1, I don't believe this is a feature that we should support. IF a client 
 is experiencing slow WAN replication and users only care about the 
 "latest" data, then maybe the user should use "conflation".
 
 With a TTL model, we are messing with our consistency tenet. I'm am NOT in 
 support of a setting that can cause inconsistency.
 
 Dead-letter queues is another area that WILL cause data/site 
 inconsistency. I think we really have to take a step back, think about 
 WHAT tenets are important to GEODE and then act accordingly.
 
 --Udo
 
 On 3/20/19 10:46, Bruce Schuchardt wrote:
> IDK Anil, we'll figure that out in the implementation.  I was thinking it 
> would be in the dispatch threads, so if distribution is need that will 
> happen as it does now.  I'm hopeful that this won't perturb the code too 
> much.
> 
> One thing that was brought up to me in person was the Dead Letter Queue 
> 
>  initiative that seems to have stalled.  That seems like a very similar 
> idea though it's reacting to errors coming from the receiving side and 
> not a local condition.  I like the callback, stats, gfsh and cluster 
> config integration in that write-up & think they might be useful here.  
> There is also relevant discussion in that page about things like PDX 
> registrations.  Is that initiative going to move forward at some point or 
> is it off the boards?
> 
> On 3/20/19 10:25 AM, Anilkumar Gingade 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 
>> 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 w

Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch

[Sai Boorlagadda]

I would like to resolve the issue around NOTICE and LICENSE files related
to new/removed dependencies on develop, which I have a PR[1] open and would
need some guidance.
There is some feedback provided by Dick earlier this week and I would like
to see if I can get some help.

[1] https://github.com/apache/geode/pull/3313

On Wed, Mar 20, 2019 at 12:43 PM Dale Emery  wrote:

> > On Mar 20, 2019, at 11:25 AM, Alexander Murmann 
> wrote:
> >
> > Dale, is there any downside to making these changes in 1.10 other than
> > plainly having them later?
>
> I don’t think so, but I’d want to hear Dan’s opinion on that, given that
> his approval of our PR was contingent on our promise to do it.
>
> FYI, the additional work to improve usability is non-trivial, which is why
> we haven’t done it already.
>
> —
> Dale Emery
> dem...@pivotal.io
>
>
>
> > On Mar 20, 2019, at 11:25 AM, Alexander Murmann 
> wrote:
> >
> > Dale, is there any downside to making these changes in 1.10 other than
> > plainly having them later?
> >
> > On Wed, Mar 20, 2019 at 11:15 AM Dave Barnes  wrote:
> >
> >> geode-native is ready to into the 1.9 release candidate build.
> >>
> >> On Wed, Mar 20, 2019 at 10:42 AM Dave Barnes 
> wrote:
> >>
> >>> The geode-native PR will be ready to check in momentarily. Just waiting
> >>> for Travis to do its diligence.
> >>>
> >>> On Wed, Mar 20, 2019 at 9:47 AM Alexander Murmann  >
> >>> wrote:
> >>>
>  Dale, do I understand correctly that the only concern around the
>  Micrometer
>  work right now it that it's not useful yet, however it's not harmful
>  either?
> 
>  Dave, is it correct that if that PR doesn't make it into the newly cut
>  branch, we'd be shipping with a older version of geode-native? What
> are
>  the
>  two versions and what would be the implications of this not making it
> >> into
>  this release?
> 
>  On Tue, Mar 19, 2019 at 5:29 PM Dave Barnes 
> wrote:
> 
> > The Geode 1.9.0 release includes a source-only release of the
>  geode-native
> > repo. There's a pull-request in process to update version numbers and
>  the
> > doc build environment in that repo; should be ready to merge tomorrow
> > morning.
> >
> > On Tue, Mar 19, 2019 at 5:20 PM Dale Emery 
> wrote:
> >
> >> The Micrometer API is in, and marked as experimental. But we have
> >> not
>  yet
> >> updated CacheFactory to allow injecting a meter registry (or metrics
> >> publishing service) there. So currently the only way to publish is
> >> to
>  add
> >> metrics publishing service via the ServiceLoader mechanism.
> >>
> >> —
> >> Dale Emery
> >> dem...@pivotal.io
> >>
> >>
> >>> On Mar 19, 2019, at 3:29 PM, Dan Smith  wrote:
> >>>
> >>> Is the geode-managability sub-project and the new micrometer API
> >> in
>  a
> >> place
> >>> where we can cut a release branch? I know a bunch of changes have
>  gone
> > in
> >>> since the release branch, are we comfortable releasing these new
> >>> experimental features as they are right now?
> >>>
> >>> -Dan
> >>>
> >>> On Tue, Mar 19, 2019 at 2:38 PM Dick Cavender 
> > wrote:
> >>>
>  +1 to re-cutting the 1.9 release branch off a more stable develop
>  sha
>  within the last couple days.
> 
>  On Tue, Mar 19, 2019 at 1:14 PM Bruce Schuchardt <
> >> bschucha...@pivotal.io>
>  wrote:
> 
> > If we recut the release branch we need to update JIRA tickets
>  marked
> > fixed in 1.10
> >
> > On 3/19/19 12:48 PM, Sai Boorlagadda wrote:
> >>> It was known at the time that develop was not as stable as
>  desired,
> >> so we planned to cherry-pick fixes from develop until the
> >> release
> >> branch was stable enough to ship.
> >> I want to clarify that we decided to cut the release branch not
>  that
> >> develop was not stable. But really that it is desirable to cut
>  the
> >> branch sooner to avoid any regression risk that can be
>  introduced by
> >> on-going work on develop.
> >>
> >> Nevertheless looks like develop is more stable than release
>  branch
> > due
> >> to some test fixes that were not cherry-picked into the release
> >> branch.
> >> I think its a good idea to re-cut the branch as our current
>  position
> >> to stabilize release branch before releasing.
> >>
> >> +1 to re-cut.
> >>
> >> Sai
> >>
> >> On Tue, Mar 19, 2019 at 12:19 PM Owen Nichols <
>  onich...@pivotal.io
> >> > wrote:
> >>
> >>   The Geode 1.9.0 release branch was originally cut 4 weeks
> >> ago
>  on
> >>   Feb 19.  It was known at the time that develop was not as
>  stable
> >>>