Re: [DISCUSS] TTL setting on WAN
Hi, I think the one approach for a user would be to 'filter' the events while dispatching. If I remember correctly, we can attach a filter at dispatch time and filter the events based on creationTime of the GatewayEvent. We can provide a pre created filter and use it based on some so that user doesn't have to write his/her own. Something like, /** All the events which spend timeToLive or more time in queue will be deleted from the queue and will not be sent to remote site. Possible consequence is that two sites can be inconsistent in case */ public GatewaySenderFactory setEntryTimeToLive(long timeToLive); As queues will be read in LRU way this would be faster too. Only drawback is that there will be only one thread (not sure if we have concurrent dispatcher yet) clearing the queue. As Udo/Dan mentioned above, user needs to be aware of the consequences. On Tue, Mar 26, 2019 at 3:09 AM Bruce Schuchardt wrote: > I've walked through the code to forward expiration actions to async > event listeners & don't see how to apply it to removal of queue entries > for WAN. The current implementation just queues the expiration > actions. If we wanted to remove any queued events associated with the > expired region entry we'd have to scan the whole queue, which would be > too slow if we're overflowing the queue to disk. > > I've also walked through the conflation code. It applies only to the > current batch being processed by the gateway sender. The data structure > used to perform conflation is just a Map that is created in the sender's > batch processing method and then thrown away. > > On 3/20/19 11:15 AM, Dan Smith wrote: > >> 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- > > >
apply for the edit permission of Geode Jira
Hi Geode Dev could you help me to get edit permission of Geode Jira? Thanks and regards Gang Yan（闫钢） GemFire product management team, Beaverton g...@pivotal.io
Re: [DISCUSS] TTL setting on WAN
I've walked through the code to forward expiration actions to async event listeners & don't see how to apply it to removal of queue entries for WAN. The current implementation just queues the expiration actions. If we wanted to remove any queued events associated with the expired region entry we'd have to scan the whole queue, which would be too slow if we're overflowing the queue to disk. I've also walked through the conflation code. It applies only to the current batch being processed by the gateway sender. The data structure used to perform conflation is just a Map that is created in the sender's batch processing method and then thrown away. On 3/20/19 11:15 AM, Dan Smith wrote: 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-
Copying pdx types via client
Does this functionality exist in the Native Client as well as the Java Client? -- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1-631-835-4771
Re: release/1.9.0 branch has been re-cut
I have updated JIRA tickets to 1.9.0 as in "update fixVersion = '1.9.0' where fixVersion = '1.10.0' AND status in (closed, resolved)" On Mon, Mar 25, 2019 at 8:49 AM Sai Boorlagadda wrote: > Hello Everyone, > > As discussed in other email thread I have re-cut a new release branch for > Apache Geode 1.9.0 - "release/1.9.0" off of sha > "ec5a24b78c51b6a29b8bf656f91004d09510d244". > > > We already have an existing pipeline for 1.9.0[1], So I will rename the > current release branch as "release/1.9.0-old" until the pipeline is green and > there are no concerns about the new branch. Also I am still working on > updating LICENSE and NOTICE files, I will cherry-pick these onto release > branch. > > Please do review and raise any concern with the release branch. > If no concerns are raised, we will start with the voting for the release > candidate soon. > > > [1] > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-0-main > > Regards > Sai > >
release/1.9.0 branch has been re-cut
Hello Everyone, As discussed in other email thread I have re-cut a new release branch for Apache Geode 1.9.0 - "release/1.9.0" off of sha "ec5a24b78c51b6a29b8bf656f91004d09510d244". We already have an existing pipeline for 1.9.0[1], So I will rename the current release branch as "release/1.9.0-old" until the pipeline is green and there are no concerns about the new branch. Also I am still working on updating LICENSE and NOTICE files, I will cherry-pick these onto release branch. Please do review and raise any concern with the release branch. If no concerns are raised, we will start with the voting for the release candidate soon. [1] https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-0-main Regards Sai
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Thanks Owen. I am going to re-cut the branch for 1.9.0 and request community to do the sanity check for the new branch. On Fri, Mar 22, 2019 at 4:24 PM Owen Nichols wrote: > @Sai, this discussion has received no objections and enough +1’s to > proceed with re-cutting the release 1.9.0 branch. > > Looking at the pipeline this week, it has been pretty green since SHA > ec5a24b78c51b6a29b8bf656f91004d09510d244. I recommend re-cutting the 1.9.0 > release branch from this SHA. > > -Owen > > > On Mar 21, 2019, at 9:26 AM, Dan Smith wrote: > > > > I'm fine releasing with just the service loader API for micrometer. > > > > I'd just like the folks working on these new public APIs agree that they > > are ok with these APIs getting released to end users and put to use in > the > > state they are right now. > > > > -Dan > > > > 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 < > amurm...@apache.org > >>> > > 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
