[PROPOSAL]: Improve OQL Method Invocation Security
Hello everyone, I've just published in the Wiki a new proposal <https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security> to improve the current behaviour regarding how we allow/deny certain method to be invoked on objects as part of the OQL execution. It's still in early stages and some of the suggested implementations might not even be possible, but please go ahead and submit any feedback and/or ideas you might have about it, every contribution is welcome. Best regards. -- Ju@N
Proposal to Include GEODE-7079 in 1.10.0
Hello team, I'd like to propose including the *fix [1]* for *GEODE-7079 [2]* in release 1.10.0. Long story short: a *NullPointerException* can be continuously thrown and flood the member's logs if a serial event processor (either *async-event-queue* or *gateway-sender*) starts processing events from a recovered persistent queue before the actual region to which it was attached is fully operational. Note: *no events are lost (even without the fix)* but, if the region takes a while to recover, the logs for the member can grow pretty quickly due to the continuously thrown *NPEs.* Best regards. [1]: https://github.com/apache/geode/commit/6f4bbbd96bcecdb82cf7753ce1dae9fa6baebf9b [2]: https://issues.apache.org/jira/browse/GEODE-7079 -- Ju@N
[DISCUSS]: Commit Message Format too Short?
Hello devs, I've notice that, lately, not everybody is following the guidelines we have highlighted in our Wiki under *Commit Message Format [1]*, specially the first requirement: *GEODE-nn: Capitalized, 50 chars or less summary. *As an example, out of the last 33 commits in develop, only 11 follow the 50 chars max rule. Even though I've always followed this "rule", I often find it hard to provide a summary of the commit in less than 50 chars, that's probably the reason why other people are just ignoring this part of the guidelines?. Should we increase the maximum amount of characters from 50 to something else?, should we add a hard check in order to automatically enforce the rule?, should we delete the rule altogether?, thoughts?. Best regards. [1]: https://cwiki.apache.org/confluence/display/GEODE/Commit+Message+Format -- Ju@N
Re: [DISCUSS] Blocking merge button in PR
+10 to Naba's proposal, it seems the right thing to do and will help us to prevent accidentally breaking *develop* while keeping focus on people instead of processes. I'd add, however, that the *Merge Pull Request* button should remain disabled until *all CIs have finished*, and only enable it once the *Build, Unit, Stress Tests and LGTM are green *(that is, force the committer to wait at least until all CIs are done)*. *I also agree in that that we should require *at least one* official approval. Cheers.
Re: [VOTE] Apache Geode 1.9.2.RC1
+1, Downloaded and built from source, created two clusters with multiple members and verified WAN replication (along with some gateway related commands) work properly. Best regards. On Mon, Oct 21, 2019 at 8:04 PM Udo Kohlmeyer wrote: > +1, > > Checked that WAR's are generated for geode-web and geode-web-api. > > Also ran set of examples and tests from Spring Data Geode (Moore), to > confirm that it has not broken functionality. > > --Udo > > On 10/21/19 8:20 AM, Jens Deppe wrote: > > Since the deadline has expired without enough votes, I am going to extend > > it for another 48(ish) hours until 8am PST, Wednesday , 23rd October. > > > > Thanks > > --Jens > > > > On Tue, Oct 15, 2019 at 10:47 AM Jens Deppe > wrote: > > > >> Hello Geode Dev Community, > >> > >> This is a release candidate for Apache Geode version 1.9.2.RC1. > >> Thanks to all the community members for their contributions to this > >> release! > >> > >> Please do a review and give your feedback, including the checks you > >> performed. > >> > >> Voting deadline: > >> 3PM PST Sun, October 20 2019. > >> > >> Please note that we are voting upon the source tag: > >> rel/v1.9.2.RC1 > >> > >> Release notes: > >> > >> > https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.2 > >> > >> Source and binary distributions: > >> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1/ > >> > >> Maven staging repo: > >> https://repository.apache.org/content/repositories/orgapachegeode-1060 > >> > >> GitHub: > >> https://github.com/apache/geode/tree/rel/v1.9.2.RC1 > >> https://github.com/apache/geode-examples/tree/rel/v1.9.2.RC1 > >> https://github.com/apache/geode-native/tree/rel/v1.9.2.RC1 > >> > >> Pipelines: > >> > >> > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-main > >> > >> > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-rc > >> > >> Geode's KEYS file containing PGP keys we use to sign the release: > >> https://github.com/apache/geode/blob/develop/KEYS > >> > >> Command to run geode-examples: > >> ./gradlew -PgeodeReleaseUrl= > >> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1 > >> -PgeodeRepositoryUrl= > >> https://repository.apache.org/content/repositories/orgapachegeode-1060 > >> build runAll > >> > >> Regards > >> --Jens > >> > -- Ju@N
Re: [DISCUSS] Tweak to branch protection rules
Question: this only applies for *approvals*, not for *refusals*, right?; I mean, the *merge pull request* button will remain blocked if there were some changes requested by reviewers and the author of the PR adds new commits (either addressing those requested changes or not)?. If the answer to the above is "yes", then +1. On Wed, Oct 30, 2019 at 1:44 AM Nabarun Nag wrote: > +1 > > On Tue, Oct 29, 2019 at 6:21 PM Darrel Schneider > wrote: > > > +1 > > > > On Tue, Oct 29, 2019 at 6:08 PM Owen Nichols > wrote: > > > > > +1 …this has already bitten me a few times > > > > > > > On Oct 29, 2019, at 6:01 PM, Dan Smith wrote: > > > > > > > > Hi all, > > > > > > > > It seems we've configured our branch protection rules such that > > pushing a > > > > change to a PR that has been approved invalidates the previous > > approval. > > > > > > > > I think we should turn this off - it looks like it's an optional > > feature. > > > > We should trust people to rerequest reviews if needed. Right now this > > is > > > > adding busywork for people to reapprove minor changes (Fixing merge > > > > conflicts, spotless, etc.) > > > > > > > > If you all agree I'll ask infra to uncheck "Dismiss stale pull > request > > > > approvals when new commits are pushed." in our branch protection > rules. > > > > > > > > -Dan > > > > > > > > > -- Ju@N
Re: [DISCUSS] Tweak to branch protection rules
Perfect Naba, thanks for answering this. My vote is +1 then. On Wed, Oct 30, 2019 at 2:37 PM Nabarun Nag wrote: > The check box Dan is mentioning will just not invalidate any approved > review if the code is changed. > If a change is requested, the button will remain disabled. > > Regards > Naba > > > On Wed, Oct 30, 2019 at 6:27 AM Joris Melchior > wrote: > > > +1 > > > > On Wed, Oct 30, 2019 at 5:27 AM Ju@N wrote: > > > > > Question: this only applies for *approvals*, not for *refusals*, > right?; > > I > > > mean, the *merge pull request* button will remain blocked if there were > > > some changes requested by reviewers and the author of the PR adds new > > > commits (either addressing those requested changes or not)?. > > > If the answer to the above is "yes", then +1. > > > > > > On Wed, Oct 30, 2019 at 1:44 AM Nabarun Nag wrote: > > > > > > > +1 > > > > > > > > On Tue, Oct 29, 2019 at 6:21 PM Darrel Schneider < > > dschnei...@pivotal.io> > > > > wrote: > > > > > > > > > +1 > > > > > > > > > > On Tue, Oct 29, 2019 at 6:08 PM Owen Nichols > > > > wrote: > > > > > > > > > > > +1 …this has already bitten me a few times > > > > > > > > > > > > > On Oct 29, 2019, at 6:01 PM, Dan Smith > > wrote: > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > It seems we've configured our branch protection rules such that > > > > > pushing a > > > > > > > change to a PR that has been approved invalidates the previous > > > > > approval. > > > > > > > > > > > > > > I think we should turn this off - it looks like it's an > optional > > > > > feature. > > > > > > > We should trust people to rerequest reviews if needed. Right > now > > > this > > > > > is > > > > > > > adding busywork for people to reapprove minor changes (Fixing > > merge > > > > > > > conflicts, spotless, etc.) > > > > > > > > > > > > > > If you all agree I'll ask infra to uncheck "Dismiss stale pull > > > > request > > > > > > > approvals when new commits are pushed." in our branch > protection > > > > rules. > > > > > > > > > > > > > > -Dan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Ju@N > > > > > > > > > -- > > *Joris Melchior * > > CF Engineering > > Pivotal Toronto > > 416 877 5427 > > > > “Programs must be written for people to read, and only incidentally for > > machines to execute.” – *Hal Abelson* > > <https://en.wikipedia.org/wiki/Hal_Abelson> > > > -- Ju@N
Re: [DISCUSS] - Upgrading from Spring 4 to Spring 5
Hello Udo, Big +1 for the proposal!. That said, I believe it was agreed a couple of months ago in the *Lightweight RFC Process [1] *that the whole discussion should be done in the [DISCUSS] email thread directly and not as comments within the proposal itself, you might want to double check that and reply to the thread so the entire discussion remains in one single place. Cheers. [1]: https://cwiki.apache.org/confluence/display/GEODE/Lightweight+RFC+Process On Wed, Oct 30, 2019 at 5:54 PM Udo Kohlmeyer wrote: > Hi there fellow Apache Geode Devs, > > We would like to propose the upgrade of the Spring libraries within > Geode Project. > > Currently the project is using Spring 4, which is EOL Q1 2020. > > The link the proposal can be found here > < > https://cwiki.apache.org/confluence/display/GEODE/%5BDiscussion%5D+-+Upgrade+Spring+version+from+Spring+4+to+Spring+5.x>. > > > > Please provide feedback on this proposal as comments on the proposal's > comment section within Apache Geode wiki. Feedback will closed on 8 > November 2019. > > --Udo > > > [1] > > https://cwiki.apache.org/confluence/display/GEODE/%5BDiscussion%5D+-+Upgrade+Spring+version+from+Spring+4+to+Spring+5.x > > -- Ju@N
Re: [DISCUSS] is overriding a PR check ever justified?
-1 for allowing overrides. If there's an edge case on which it's required, then we could use it at the very last resources *if and only if* it's been discussed and approved through the dev list for that particular case. Cheers. On Wed, Oct 30, 2019 at 11:35 PM Robert Houghton wrote: > Any committer has the 'status' permission on apache/geode.git. Some API > tokens have it as well. Its curl + github API reasoning to do this. > > On Wed, Oct 30, 2019 at 2:02 PM Jason Huynh wrote: > > > If we are going to allow overrides, then maybe what Owen is describing > > should occur. Make a request on the dev list and explain the reasoning. > > > > I don't think this has been done and a few have already been overridden. > > > > Also who has the capability to override and knows how. How is that > > determined? > > > > On Wed, Oct 30, 2019 at 1:59 PM Owen Nichols > wrote: > > > > > > How do you override a check, anyway? > > > > > > Much like asking for jira permissions, wiki permissions, etc, just ask > on > > > the dev list ;) > > > > > > Presumably this type of request would be made as a “last resort” > > following > > > a dev list discussion wherein all other reasonable options had been > > > exhausted (reworking or splitting up the PR, pushing empty commits, > > > rebasing the PR, etc) > > > > > > > On Oct 30, 2019, at 1:42 PM, Dan Smith wrote: > > > > > > > > +1 for allowing overrides. I think we should avoid backing ourselves > > > into a > > > > corner where we can't get anything into develop without talking to > > apache > > > > infra. Some infrastructure things we can't even fix without pushing a > > > > change develop! > > > > > > > > How do you override a check, anyway? > > > > > > > > -Dan > > > > > > > > On Wed, Oct 30, 2019 at 12:58 PM Donal Evans > > wrote: > > > > > > > >> -1 to overriding from me. > > > >> > > > >> The question I have here is what's the rush? Is anything ever so > > > >> time-sensitive that you can't even wait the 15 minutes it takes for > it > > > to > > > >> build and run unit tests? If some infrastructure problem is > preventing > > > >> builds or tests from completing then that should be fixed before any > > new > > > >> changes are added, otherwise what's the point in even having the pre > > > >> check-in process? > > > >> > > > >> -Donal > > > >> > > > >> On Wed, Oct 30, 2019 at 11:44 AM Nabarun Nag > wrote: > > > >> > > > >>> @Aaron > > > >>> It's okay to wait for at least the build, and unit tests to > complete, > > > to > > > >>> cover all the bases. [There may have been commits in between which > > may > > > >>> result in failure because of the revert] And it's not hard to get > a > > PR > > > >>> approval. > > > >>> > > > >>> -1 on overriding. If the infrastructure is down, which is the test > > > >>> framework designed to ensure that we are not checking in unwanted > > > changes > > > >>> into Apache Geode, wait for the infrastructure to be up, get your > > > changes > > > >>> verified, get the review from a fellow committer and then check-in > > your > > > >>> changes. > > > >>> > > > >>> I still don't understand why will anyone not wait for unit tests > and > > > >> build > > > >>> to be successful. > > > >>> > > > >>> Regards > > > >>> Nabarun Nag > > > >>> > > > >>> On Wed, Oct 30, 2019 at 11:32 AM Aaron Lindsey < > alind...@pivotal.io> > > > >>> wrote: > > > >>> > > > >>>> One case when it might be acceptable to overrule a PR check is > > > >> reverting > > > >>> a > > > >>>> commit. Before the branch protection was enabled, a committer > could > > > >>> revert > > > >>>> a commit without a PR. Now that PRs are mandatory, we have to wait > > for > > > >>> the > > > >>>> checks to run in order to revert a commit. Usually we are > reverting > > a > > > >>>> commit because it's causing problems, so I think overruling the PR > > > >> checks > > > >>>> may be acceptable in that case. > > > >>>> > > > >>>> - Aaron > > > >>>> > > > >>>> > > > >>>> On Wed, Oct 30, 2019 at 11:11 AM Owen Nichols < > onich...@pivotal.io> > > > >>> wrote: > > > >>>> > > > >>>>> Our new branch-protection rules can sometimes lead to unexpected > > > >>>> obstacles > > > >>>>> when infrastructure issues impede the intended process. Should > we > > > >>>> discuss > > > >>>>> such cases as they come up, and should overruling the result of a > > PR > > > >>>> check > > > >>>>> ever be an option on the table? > > > >>>>> > > > >>>>> -Owen > > > >>>> > > > >>> > > > >> > > > > > > > > > -- Ju@N
[IGNORE]: Test Email
Ignore this email, I've previously replied to a thread in the list and I'm not seeing that reply anywhere, trying to see if it's a general issue or just a problem with my account. Cheers. -- Ju@N
Re: Special certificates for multisite
Hello Alberto, I'm not particularly knowledgeable on this subject so I might be missing something, but with Geode you can independently configure SSL for specific system components, can't you just use multiple alias to achieve your use case as described here [1]?. *>> The situation is the following: when SSL is enabled, we would like to use multiple certificates in locators and servers: one certificate for communication inside one geographical site, and another for the communication happening between geographical sites. The approach we took is to use the default SSL context and implement our own Java Security Provider.* Here you would use *cluster *as the alias to configure the SSL settings used for communications within one geographical site, and *gateway *as the alias to configure the particular SSL settings to be used for communications across sites. Would that work for you?. Cheers. [1]: https://geode.apache.org/docs/guide/110/managing/security/implementing_ssl.html On Fri, Nov 1, 2019 at 1:37 PM Anthony Baker wrote: > Just checking, is anyone familiar enough with SSL to comment on the > proposed change? > > Anthony > > > > On Oct 29, 2019, at 2:44 AM, Mario Ivanac wrote: > > > > Hi, > > > > We are trying to find a solution for an situation we have. Below is the > explanation of the issue, as well as a proposed way forward. We would > appreciate comments from the community regarding this approach. Also, > suggestions for a different approach to solve this issue would be welcome. > > > > The situation is the following: when SSL is enabled, we would like to > use multiple certificates in locators and servers: one certificate for > communication inside one geographical site, and another for the > communication happening between geographical sites. The approach we took is > to use the default SSL context and implement our own Java Security Provider. > > > > The client side can, from the security provider, easily distinguish > which certificate to use (just check if you are initiating a connection > towards an IP listed in gemfire.remote-locators). The thing we are missing > is a criteria based on which we can choose the certificate on the server > side of the connection. Explanation: Once the handshake starts, a > ClientHello message is sent from the peer acting as a client in that > connection (be it a geode server or a geode locator). When the ClientHello > is received on the server side, we can’t always read the real originating > IP (keeping the originating IP is sometimes not possible in cloud native > environments), so we can’t be sure whether the message originated from the > same geographical site or from another. We are left only with the > information inside the ClientHello message. The default ClientHello message > doesn’t contain information based on which we can conclude which site the > message came from and which certificate to use. > > > > Our proposal is to add the server_name extension in the ClientHello > message. The content of that extension would be the distributed system ID > of the site where the ClientHello originated. This way we could compare the > distributed system ID in the ClientHello message with the ID of the site > where the message is received. > > > > One issue with this approach is that the usage of the extension wouldn’t > be completely in line with the RFC< > https://tools.ietf.org/html/rfc6066#page-6> description: we would be > inserting client information instead of the targeted server name. Still, > since this extension is otherwise of no use in Geode, and this approach > doesn’t present a security risk (we would be sharing the distributed system > ID, which doesn’t look dangerous), we see this as a potential way to go. > > > > > > > > -- Ju@N
Re: [DISCUSS] Proposal to require linear commit history on develop
rself. > >>>>>>> > >>>>>>> If we want to change the way we have agreed upon we > >>>> submit/commit/merge > >>>>>>> changes back into develop... Then this is another discussion > thread, > >>>>>>> until then, I think we should all remind ourselves on our agreed > >>>>>>> contributions code of conduct. > >>>>>>> > >>>>>>> --Udo > >>>>>>> > >>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote: > >>>>>>>> Kirk, I believe that creating a Pull Request with multiple > commits is > >>>>> ok. > >>>>>>>> It's just in the end that when it's being pushed to develop > branch, > >>>> it > >>>>>>>> needs to be squash merged. I believe that is what you have > mentioned > >>>> in > >>>>>>> the > >>>>>>>> first paragraph, and I am more than happy with that. > >>>>>>>> If you can see in the first screenshot comparison that I had > attached > >>>>> in > >>>>>>>> the first email in this thread is what I want to avoid. > >>>>>>>> > >>>>>>>> Thank you for your feedback. > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> Naba > >>>>>>>> > >>>>>>>> > >>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund > wrote: > >>>>>>>> > >>>>>>>>> Whenever I submit a PR with multiple commits that I intend to > rebase > >>>>> to > >>>>>>>>> develop, I always try to ensure that each commit stands alone as > is > >>>>>>>>> (compiles and passes tests). Separating file renames and > refactoring > >>>>>>> from > >>>>>>>>> behavior changes into different commits seems very valuable to > me, > >>>> and > >>>>>>> I've > >>>>>>>>> had trouble getting people to review PRs without this separation > >>>> (but > >>>>> it > >>>>>>>>> could be squashed as it's merged to develop). > >>>>>>>>> > >>>>>>>>> It sounds to me like the real problem is (a) some PRs have > multiple > >>>>>>> commits > >>>>>>>>> that don't compile or don't pass tests, and (b) some PRs that > should > >>>>> be > >>>>>>>>> merged with squash are not (by accident most likely). > >>>>>>>>> > >>>>>>>>> I can submit multiple PRs instead of one PR with multiple > commits. > >>>> So > >>>>>>> I'll > >>>>>>>>> change my response to -0 if that helps prevent commits to develop > >>>> that > >>>>>>>>> don't compile or pass tests. Without preventing rebase or merge > >>>>> commits > >>>>>>>>> from github, I'm not sure how we can really enforce this or > prevent > >>>>> (b) > >>>>>>>>> above. > >>>>>>>>> > >>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann < > >>>>> amurm...@pivotal.io> > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at > odds. > >>>>>>>>>> > >>>>>>>>>> Make the change easy (warning: this may be hard), then make the > >>>> easy > >>>>>>>>>>> change." > >>>>>>>>>> -Kent Beck > >>>>>>>>>> > >>>>>>>>>> Following Kent Beck's advise might reasonably split into two > >>>> commits. > >>>>>>> One > >>>>>>>>>> refactor commit and a separate commit that introduces the actual > >>>>>>> change. > >>>>>>>>>> They should be individually revertible and might be easier > >>>> understood > >>>>>>> if > >>>>>>>>>> split out. I vividly remember a change on our code base where > >>>> someone > >>>>>>>>> did a > >>>>>>>>>> huge amount of refactoring that resulted than in one parameter > >>>>> changing > >>>>>>>>> in > >>>>>>>>>> order to get the desired functionality change. If that was in > one > >>>>>>> commit, > >>>>>>>>>> it would be hard to see the actual change. If split out, it's > >>>>> beautiful > >>>>>>>>> and > >>>>>>>>>> crystal clear. > >>>>>>>>>> > >>>>>>>>>> I am unsure how that would be reflected in terms of JIRA ticket > >>>>>>>>> references. > >>>>>>>>>> Usually we assume that if there is a commit with the ticket > number, > >>>>> the > >>>>>>>>>> issue is resolved. Maybe the key here is to create a separate > >>>>>>> refactoring > >>>>>>>>>> ticket. > >>>>>>>>>> > >>>>>>>>>> Would that allow us to have our cake and eat it too? > >>>>>>>>>> > >>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag > >>>> wrote: > >>>>>>>>>>> It is to help with bisect operations when things start failing > ... > >>>>>>>>> helps > >>>>>>>>>> us > >>>>>>>>>>> it revert and build faster. > >>>>>>>>>>> also with cherry picking features / fixes to previous versions > . > >>>>>>>>>>> And keeping the git history clean with no unnecessary “merge > >>>>> commits”. > >>>>>>>>>>> Regards > >>>>>>>>>>> Naba > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund > >>>> wrote: > >>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a PR > and > >>>>>>>>> keep > >>>>>>>>>>> them > >>>>>>>>>>>> separate when they merge to develop > >>>>>>>>>>>> > >>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag > >>>>> wrote: > >>>>>>>>>>>>> Hi Geode Committers, > >>>>>>>>>>>>> > >>>>>>>>>>>>> A kind request for using squash commit instead of using > merge. > >>>>>>>>>>>>> This will really help us in our bisect operations when a > >>>>>>>>>>>>> regression/flakiness in the product is introduced. We can > >>>> automate > >>>>>>>>>> and > >>>>>>>>>>> go > >>>>>>>>>>>>> through fewer commits faster, avoiding commits like "spotless > >>>> fix" > >>>>>>>>>> and > >>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the merged > >>>>>>>>> branch. > >>>>>>>>>>>>> Also, please use the commit format : (helps us to know who > >>>> worked > >>>>>>>>> on > >>>>>>>>>>> it, > >>>>>>>>>>>>> what is the history) > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> *GEODE-: > >>>>>>>>>>>>> * explanation line 1* > >>>> explanation > >>>>>>>>>> line > >>>>>>>>>>> 2* > >>>>>>>>>>>>> This is not a rule or anything, but a request to help out > your > >>>>>>>>> fellow > >>>>>>>>>>>>> committers in quickly detecting a problem. > >>>>>>>>>>>>> > >>>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark where > >>>> they > >>>>>>>>>> have > >>>>>>>>>>> a > >>>>>>>>>>>>> complete linear graph for their main branch HEAD [see > >>>> attachment] > >>>>>>>>>>>>> Regards > >>>>>>>>>>>>> Naba. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>> > > -- Ju@N
Re: [DISCUSS] Proposal to require linear commit history on develop
t;>>>> > >>>>>>>>> Just FWIW, the situation described of having multiple commits > >> in > >>> a > >>>>>>>>> > >>>>>>>>> single > >>>>>>>>> > >>>>>>>>> PR with separate associated JIRA tickets is still kind of > >>>>> problematic. > >>>>>>>>> > >>>>>>>>> It > >>>>>>>>> > >>>>>>>>> could well be the case that the commits are interdependent, > >> thus > >>>> when > >>>>>>>>> bisecting etc it's still not possible to revert the fix for a > >>>> single > >>>>>>>>> bug/feature/whatever atomically. It's all good, though, I'm > >>>>> satisfied > >>>>>>>>> > >>>>>>>>> no > >>>>>>>>> > >>>>>>>>> one's forcing me to adopt practice I'm opposed to. Apologies > >> for > >>>>>>>>> > >>>>>>>>> getting > >>>>>>>>> > >>>>>>>>> my feathers a little ruffled, or if I ruffled anyone else's in > >>>>> return. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> > >>>>>>>>> Blake > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag > >>>>> wrote: > >>>>>>>>> > >>>>>>>>> Hi Dan, > >>>>>>>>> > >>>>>>>>> When we do squash merge all the commit messages are preserved > >> and > >>>>> also > >>>>>>>>> > >>>>>>>>> the > >>>>>>>>> > >>>>>>>>> co-authored tag works when we do squash merge. > >>>>>>>>> So the authorship and history are preserved. > >>>>>>>>> > >>>>>>>>> In my own personal experience and reverts and pinpointing > >>>> regression > >>>>>>>>> failures are tough when the commits are spread out. Also, > >> reverts > >>>> are > >>>>>>>>> easier when it is just one commit while we are bisecting > >>> failures. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Regards > >>>>>>>>> Naba > >>>>>>>>> > >>>>>>>>> On Fri, Dec 20, 2019 at 12:07 PM Dan Smith > >>>>> wrote: > >>>>>>>>> > >>>>>>>>> I'll change to -0. > >>>>>>>>> > >>>>>>>>> I think merge commits are a nice way to record history in some > >>>> cases, > >>>>>>>>> > >>>>>>>>> and > >>>>>>>>> > >>>>>>>>> can also be a way to avoid messy conflicts that come with > >> rebase. > >>>>>>>>> > >>>>>>>>> Merge > >>>>>>>>> > >>>>>>>>> commits also preserve authorship of commits (compared to > >>>>>>>>> > >>>>>>>>> squash-merge), > >>>>>>>>> > >>>>>>>>> which I think is valuable as an open source community that is > >>>> trying > >>>>>>>>> > >>>>>>>>> to > >>>>>>>>> > >>>>>>>>> keep track of outside contributions. > >>>>>>>>> > >>>>>>>>> That said, if the rest of y'all feel it will help to disable > >> the > >>>>>>>>> > >>>>>>>>> button, > >>>>>>>>> > >>>>>>>>> I > >>>>>>>>> > >>>>>>>>> won't sta
Re: Odg: RFC - Logging to Standard Out
+1 On Thu, Jan 9, 2020 at 8:02 AM Mario Ivanac wrote: > +1 > > Šalje: Jacob Barrett > Poslano: 8. siječnja 2020. 21:39 > Prima: dev@geode.apache.org > Predmet: RFC - Logging to Standard Out > > Please see RFC for Logging to Standard Out. > > https://cwiki.apache.org/confluence/display/GEODE/Logging+to+Standard+Out > <https://cwiki.apache.org/confluence/display/GEODE/Logging+to+Standard+Out > > > > Please comment by 1/21/2020. > > Thanks, > Jake > > -- Ju@N
[PROPOSAL]: Include GEODE-7728 in Release 1.12.0
Hello devs, I'd like to include the fix for GEODE-7728 [1] in release 1.12.0. The change is basically to avoid throwing an exception and return the correct result whenever a query has more than one condition and one of them compares two indexed fields. This is not a new issue but it can be hit by any user under the conditions I've mentioned, it is also considered critical for one of the customers I work for, thus I'm eagerly asking to include the fix in the next release. The SHA is 6e35c201ea605075433203d4e64ca887bafd8fcb [2]. Best regards. [1]: https://issues.apache.org/jira/browse/GEODE-7728 [2]: https://github.com/apache/geode/commit/6e35c201ea605075433203d4e64ca887bafd8fcb -- Ju@N
[PROPOSAL]: Include GEODE-7789 in Release 1.12.0
Hello devs, I'd like to include the fix for GEODE-7789 [1] in release 1.12.0. The change prevents a performance degradation introduced in Geode 1.11, it basically shows up on clusters where there's at least one client with subscription enabled. The SHA is 71e156a55228d89efafd048e1533debba606c064 [2]. Best regards. [1]: https://issues.apache.org/jira/browse/GEODE-7789 [2]: https://github.com/apache/geode/commit/71e156a55228d89efafd048e1533debba606c064 -- Ju@N
[PROPOSAL]: Include GEODE-7756 in Release 1.12.0
Hello devs, I'd like to include the fix for GEODE-7756 [1] in release 1.12.0. The change prevents a performance degradation introduced in Geode 1.11 through to the OQL Method Invocation authorization feature, for which regular cache operations are slowed down on clusters where there are running CQs. The SHA is 5dd7a8420bbe43657abc82e5b8d073eb01b51d8d [2]. Best regards. [1]: https://issues.apache.org/jira/browse/GEODE-7756 [2]: https://github.com/apache/geode/commit/5dd7a8420bbe43657abc82e5b8d073eb01b51d8d -- Ju@N
[PROPOSAL]: Include GEODE-7814 in Release 1.12.0
Hello devs, I'd like to include the fix for GEODE-7814 [1] in release 1.12.0. The change prevents a huge amount of unnecessary allocation of objects while sending/receiving messages, improving the overall performance. The SHA is db86faec699aca67c02325bca22dcd5b913ddfed [2]. Best regards. [1]: https://issues.apache.org/jira/browse/GEODE-7814 [2]: https://github.com/apache/geode/commit/db86faec699aca67c02325bca22dcd5b913ddfed -- Ju@N
[PROPOSAL]: Include GEODE-7820 in Release 1.12.0
Hello devs, I'd like to include the fix for GEODE-7820 [1] in release 1.12.0. The change avoid unnecessary transformations between java collections and primitive arrays for every message sent within a Geode cluster (see the Geode tickets for further details). The SHA is ca7ccbce73d436005fe027f31ee910ee9beeb769 [2]. My apologies for keep asking to merge changes into an already cut release, we found a performance degradation (around 7%) within our internal testings and we're trying to solve it step by step before version 1.12 is released (we are 3% away from the baseline, Geode 1.10, right now). Best regards. [1]: https://issues.apache.org/jira/browse/GEODE-7820 [2]: https://github.com/apache/geode/commit/ca7ccbce73d436005fe027f31ee910ee9beeb769 -- Ju@N
Re: [PROPOSAL] StressNewTest in Pull Request Pipeline to be made optional.
+1 to what Owen said, I don't think disabling *StressNewTest* is a good idea. On Fri, 28 Feb 2020 at 18:35, Owen Nichols wrote: > -1 to making StressNew not required > > +1 to eliminating the current loophole — StressNew should never give a > free pass. > > Any time your PR is having trouble passing StressNew, please bring it up > on the dev list. We can review on a case-by-case basis and decide whether > to try increasing the timeout, changing the repeat count, refactoring the > PR, or as an absolute last resort requesting authorization for an override > (for example, a change to spotless rules might touch a huge number of files > but carry no risk). > > One bug we should fix is that StressNew sometimes counts more files > touched than really were, especially if you had many commits or merges or > rebases on your PR branch. Possible workarounds there include squashing > and/or creating a new PR and/or splitting into multiple PRs. I’ve spent > some time trying to reproduce why files are mis-counted, with no success, > but perhaps someone cleverer with git could provide a fix. > > Another issue is that StressNew is only in the PR pipeline, not the main > develop pipeline. This feels like an asymmetry where PRs must pass a > “higher” standard. We should consider adding some form of StressNew to the > main pipeline as well (maybe compare to the previous SHA that passed?). > > The original motivation for the 25-file limit was an attempt to limit how > long StressNew might run for. Since concourse already applies a timeout, > that check is unnecessary. However, a compromise solution might be to use > the number of files changed to dial back the number of repeats, e.g. stay > with 50 repeats if fewer than 25 files changed, otherwise compute 1250 / > <#-files-changed> and do only that many repeats (e.g. if 50 files changed, > run all tests 25x instead of 50x). > > While StressNew is intended to catch new flaky tests, it can also catch > poorly-designed tests that fail just by running twice in the same VM. This > may be a sign that the test does not clean up properly and could be > polluting other tests in unexpected ways? It might be useful to run a > “StressNew” with repeats=2 over a much broader scope, maybe even all tests, > at least once in a while? > > > > On Feb 28, 2020, at 9:51 AM, Mark Hanson wrote: > > > > Hi All, > > > > Proposal: Force StressNewTest to fail a change with 25 or more files > rather than pass it without running it. > > > > Currently, the StressNewTest job in the pipeline will just pass a job > that has more than 25 files changed. It will be marked as green with no > work done. There are reasons, relating to run time being too long to be > tracked by concourse, so we just let it through as a pass. I think this is > a bad signal. I think that this should automatically be a failure in the > short term. As a result, I also think it should not be required. It is a > bad signal, and I think that by making it a fail, this will at least not > give us a false sense of security. I understand that this opens the flood > gates so to speak, but I don’t think as a community it is a big problem > because we can still say that you should not merge if the StressNewTest > fails because of your test. > > > > I personally find the false sense of security more troubling than > anything. Hence the reason, I would like this to be > > > > Let me know what you think.. > > > > Thanks, > > Mark > > -- Ju@N
Re: [PROPOSAL]: Include GEODE-7820 in Release 1.12.0
Hello Owen, Unfortunately I don't have the answer to that question... I never worked through the Geode Benchmarks so I don't know exactly what they're testing/validating. Best regards. On Fri, 28 Feb 2020 at 18:52, Owen Nichols wrote: > Thanks Juan, this is fantastic work discovering and mitigating this! > > The Benchmarks tests in our pipeline are supposed to catch performance > degradations exceeding 5%. We should all be concerned, how did a 7% > degradation slip through? > > > On Feb 28, 2020, at 3:48 AM, Ju@N wrote: > > > > Hello devs, > > > > I'd like to include the fix for GEODE-7820 [1] in release 1.12.0. > > The change avoid unnecessary transformations between java collections and > > primitive arrays for every message sent within a Geode cluster (see the > > Geode tickets for further details). > > The SHA is ca7ccbce73d436005fe027f31ee910ee9beeb769 [2]. > > My apologies for keep asking to merge changes into an already cut > release, > > we found a performance degradation (around 7%) within our internal > testings > > and we're trying to solve it step by step before version 1.12 is released > > (we are 3% away from the baseline, Geode 1.10, right now). > > Best regards. > > > > [1]: https://issues.apache.org/jira/browse/GEODE-7820 > > [2]: > > > https://github.com/apache/geode/commit/ca7ccbce73d436005fe027f31ee910ee9beeb769 > > > > -- > > Ju@N > > -- Ju@N
[PROPOSAL]: Include GEODE-7832, GEODE-7853 & GEODE-7863 in Geode 1.12.0
Hello devs, I'd like to propose including the fixes for *GEODE-7832 [1]*, *GEODE-7853 [2]* and *GEODE-7863 [3]* in release 1.12.0. All the changes are related to the work we have been doing in order to bring the performance closer to the baseline (*Geode 1.10*), we are not quite there yet but it would be good to include these fixes into the release anyways. Best regards. [1]: https://issues.apache.org/jira/browse/GEODE-7832 [2]: https://issues.apache.org/jira/browse/GEODE-7853 [3]: https://issues.apache.org/jira/browse/GEODE-7863 -- Ju@N -- Ju@N
Re: [VOTE] Using Github issues and wiki for geode-kafka-connector project
+1 On Sun, 22 Mar 2020 at 16:26, Jacob Barrett wrote: > > > > On Mar 22, 2020, at 9:23 AM, Anthony Baker wrote: > > > > Check out [1] for a list of projects that are moving to GitHub issues. > As long as the PMC approves, INFRA will support the switch. > > > Awesome!! > > > Once we see how that goes, I’m in favor of having a larger conversation > about migrating entirely from JIRA to Github. I’ve been thinking about > doing this for awhile so thanks for taking the first step Naba! I think it > will be a better experience for all and really help all contributors not > have to deal with multiple systems to get stuff done. > > +1 > > > -Jake > > -- Ju@N
Re: Proposal to bring GEODE-7969 to support/1.12
+1 On Wed, 8 Apr 2020 at 17:21, Owen Nichols wrote: > Recently it’s been noticed that netty-all-4.1.42.Final.jar is getting > flagged for “high" security vulnerability CVE-2019-20444 and CVE-2019-20445. > > Analysis shows that Geode does not use Netty in a manner that would expose > this vulnerability. > > The risk of bringing GEODE-7969 is very low. Netty is only imported for > some I/O libraries in geode-redis, not used as a server. GEODE-7969 has > passed all PR checks on support/1.12, and the same version bump to > 4.1.45.Final has been on develop since February via GEODE-7798. > > This fix is critical to avoid false positives in automated vulnerability > scans. > > -Owen -- Ju@N
[PROPOSAL]: GEODE-7940 to support/1.12
Hello devs, I'd like to propose bringing *GEODE-7940 [1]* to the *support/1.12* branch. The bug is not new, seems quite old actually, but still seems pretty critical as it can lead to data loss in WAN topologies. Long story short: when there are multiple parallel *gateway-senders* attached to the same region and the user decides to stop, detach and *destroy* one of the senders (the destroy part is what actually causes the problem), the rest of the senders attached will silently stop replicating events to the the remote clusters and all these events will be lost. The fix has been merged into develop through commit *bfbb398 [2]*. Best regards. [1]: https://issues.apache.org/jira/browse/GEODE-7940 [2]: https://github.com/apache/geode/commit/bfbb398891c5d96fa3a5975365b29d71bd849ad6 -- Ju@N
Re: [PROPOSAL]: GEODE-7940 to support/1.12
Sounds good Owen, thanks!. On Fri, 17 Apr 2020 at 09:50, Owen Nichols wrote: > Hi Juan, this looks like a great fix and definitely meets the “critical > fix" standard. Also thanks for the detailed description. > > I noticed it was just merged to develop very recently. I would like to > see that it gets through all tests and spends a couple days on develop, > then I will be happy to give this a +1 on Monday if no surprises turn up. > > > On Apr 17, 2020, at 1:41 AM, Ju@N wrote: > > > > Hello devs, > > > > I'd like to propose bringing *GEODE-7940 [1]* to the *support/1.12* > branch. > > The bug is not new, seems quite old actually, but still seems pretty > > critical as it can lead to data loss in WAN topologies. > > Long story short: when there are multiple parallel *gateway-senders* > attached > > to the same region and the user decides to stop, detach and *destroy* one > > of the senders (the destroy part is what actually causes the problem), > the > > rest of the senders attached will silently stop replicating events to the > > the remote clusters and all these events will be lost. > > The fix has been merged into develop through commit *bfbb398 [2]*. > > Best regards. > > > > [1]: https://issues.apache.org/jira/browse/GEODE-7940 > > [2]: > > > https://github.com/apache/geode/commit/bfbb398891c5d96fa3a5975365b29d71bd849ad6 > > > > -- > > Ju@N > > -- Ju@N
Re: [PROPOSAL]: GEODE-7940 to support/1.12
Hello all, Thanks for the feedback. There seems to be enough consensus in that this is a critical fix, so I've cherry-picked the commit to the support/1.12 branch already (and updated the Fixed Versions field in JIRA). Best regards. On Mon, 20 Apr 2020 at 18:41, Owen Nichols wrote: > Weekend testing looks good to me > > +1 > > > On Apr 17, 2020, at 3:26 PM, Robert Houghton > wrote: > > > > Conditional +1 from me too, pending a few days on develop with happy > > results :) > > > > Thanks Juan! > > > > On Fri, Apr 17, 2020 at 1:41 AM Ju@N wrote: > > > >> Hello devs, > >> > >> I'd like to propose bringing *GEODE-7940 [1]* to the *support/1.12* > branch. > >> The bug is not new, seems quite old actually, but still seems pretty > >> critical as it can lead to data loss in WAN topologies. > >> Long story short: when there are multiple parallel *gateway-senders* > >> attached > >> to the same region and the user decides to stop, detach and *destroy* > one > >> of the senders (the destroy part is what actually causes the problem), > the > >> rest of the senders attached will silently stop replicating events to > the > >> the remote clusters and all these events will be lost. > >> The fix has been merged into develop through commit *bfbb398 [2]*. > >> Best regards. > >> > >> [1]: https://issues.apache.org/jira/browse/GEODE-7940 > >> [2]: > >> > >> > https://github.com/apache/geode/commit/bfbb398891c5d96fa3a5975365b29d71bd849ad6 > >> > >> -- > >> Ju@N > >> > > -- Ju@N
Re: Reconfiguring our notifications and more
+1 On Tue, 21 Apr 2020 at 17:02, Dan Smith wrote: > +1 > > -Dan > > On Tue, Apr 21, 2020 at 9:00 AM Owen Nichols wrote: > > > +1 > > > > > On Apr 21, 2020, at 8:54 AM, Anthony Baker wrote: > > > > > > I’d like a quick round of feedback so we can stop the dev@ spamming > [1]. > > > > > > ASF has implemented a cool way to give projects control of lots of > > things [2]. In short, you provide a .asf.yml in each and every GitHub > repo > > to control lots of interesting things. For us the most immediately > > relevant are: > > > > > > notifications: > > > commits: comm...@geode.apache.org > > > issues: iss...@geode.apache.org > > > pullrequests: notificati...@geode.apache.org > > > jira_options: link label comment > > > > > > I’d like to commit this to /develop and cherry-pick over to /master > > ASAP. Later on we can explore the website and GitHub sections. Let me > > know what you think. > > > > > > Anthony > > > > > > > > > [1] https://issues.apache.org/jira/browse/INFRA-20156 > > > [2] > > > https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Notificationsettingsforrepositories > > > > > -- Ju@N
Re: [DISCUSS] etiquette around breaking the pipeline
t, no shame” > >>> revert-first-then-fix culture benefit our community, or is our current > >>> easygoing approach working just fine? > >>> > >>> [1] > >>> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-develop-main&data=02%7C01%7Chansonm%40vmware.com%7C631cbe6f65c14bbb030108d7ec931267%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637237988725318710&sdata=2ecuh535cj7G9i8STCT32zyunsnrcupg4c8dowrGwvo%3D&reserved=0 > < > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-develop-main&data=02%7C01%7Chansonm%40vmware.com%7C631cbe6f65c14bbb030108d7ec931267%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637237988725318710&sdata=2ecuh535cj7G9i8STCT32zyunsnrcupg4c8dowrGwvo%3D&reserved=0 > > > > -- Ju@N
[PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13
Hello devs, I'd like to propose bringing GEODE-8071 [1] to the *support/1.12* and *support/1.13* branches. The bug was introduced in Geode 1.8.0 and, long story short, prevents locators from gracefully shutting down whenever a rebalance operation is launched from gfsh (doesn't matter whether the rebalance is successful or not). The fix has been merged into develop through commit d8e86cb720c054b154a16cc88fee88e73db709f3 [2]. Best regards. [1]: https://issues.apache.org/jira/browse/GEODE-8071 [2:] https://github.com/apache/geode/commit/d8e86cb720c054b154a16cc88fee88e73db709f3 -- Ju@N
Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13
Thanks all for the replies. The fix has been back ported to support/1.12 [1] and support/1.13 [2] already. Best regards. [1]: https://github.com/apache/geode/commit/5a3a24e4724ba7278bc2f9482d25302ede964319 [2]: https://github.com/apache/geode/commit/193a98a1975a2df417e50755d7badd320c7cb8af On Thu, 7 May 2020 at 19:13, Dave Barnes wrote: > Looks like you have the votes, Juan. > Go ahead and contribute this fix to support/1.13 and support/1.12. > Thanks, > Dave > Geode 1.13 release manager > > On Thu, May 7, 2020 at 10:44 AM Eric Shu wrote: > > > +1 > > > > > > On Thu, May 7, 2020 at 10:22 AM Jianxia Chen wrote: > > > > > +1 > > > > > > On Thu, May 7, 2020 at 7:47 AM Ju@N wrote: > > > > > > > Hello devs, > > > > > > > > I'd like to propose bringing GEODE-8071 [1] to the *support/1.12* and > > > > *support/1.13* branches. > > > > The bug was introduced in Geode 1.8.0 and, long story short, prevents > > > > locators from gracefully shutting down whenever a rebalance operation > > is > > > > launched from gfsh (doesn't matter whether the rebalance is > successful > > or > > > > not). > > > > The fix has been merged into develop through commit > > > > d8e86cb720c054b154a16cc88fee88e73db709f3 [2]. > > > > Best regards. > > > > > > > > [1]: https://issues.apache.org/jira/browse/GEODE-8071 > > > > [2:] > > > > > > > > > > > > > > https://github.com/apache/geode/commit/d8e86cb720c054b154a16cc88fee88e73db709f3 > > > > > > > > -- > > > > Ju@N > > > > > > > > > > -- Ju@N
Re: [DISCUSS] enable GitHub PR blocking on API breaking changes
+1 On Thu, 14 May 2020 at 22:19, Mark Hanson wrote: > +1. The more we can automate this types of checks the better. > > Thanks, > Mark > > -- Ju@N
Re: Question about version checks inside fromData method in GatewaySenderEventImpl
Hello Alberto,
It looks like the property *isConcurrencyConflict* was added as part of
*GEODE-3967* [1] and this was released as part of Geode 1.9.0; that seems
to the reason why the check is in place: if we get an instance of
*GatewaySenderEventImpl* from a member running a version higher than 1.9.0
then we are 100% sure that the serialized form will contain the new field
so we can parse it, if the serialized *GatewaySenderEventImpl *comes from
an older member the filed won't be there so we don't even try to parse it.
Hope I didn't miss anything.
Cheers.
[1]: https://issues.apache.org/jira/browse/GEODE-3967
On Tue, 19 May 2020 at 13:14, Alberto Gomez wrote:
> Hi,
>
> Looking at the fromData method of GatewaySenderEventImpl I see that it
> contains a conditional reading of the isConcurrencyConflict when version is
> greater than Geode 1.9.0 one. See below:
>
> @Override
> public void fromData(DataInput in,
> DeserializationContext context) throws IOException,
> ClassNotFoundException {
> fromDataPre_GEODE_1_9_0_0(in, context);
> if (version >= Version.GEODE_1_9_0.ordinal()) {
> this.isConcurrencyConflict = DataSerializer.readBoolean(in);
> }
> }
>
> I have looked at the implementation of this method in other classes and
> have not seen this checking of version pattern. I have also observed that
> if the "if" is removed some backward compatibility tests fail.
>
> Could anybody tell me why this check (the if) is necessary given that
> there is already a fromDataPre_GEODE_1_9_0 method in the class?
>
> Thanks in advance,
>
> -Alberto G.
>
--
Ju@N
Re: Question about version checks inside fromData method in GatewaySenderEventImpl
I misunderstood the question, sorry about that.
I'm not entirely familiar with the serialization versioning mechanism, so
I'll leave somebody else with deeper knowledge to answer.
Cheers.
On Tue, 19 May 2020 at 14:30, Alberto Gomez wrote:
> Hi Juan,
>
> Thanks for your answer.
>
> According to
> https://cwiki.apache.org/confluence/display/GEODE/Managing+Backward+Compatibility
> there are two ways to manage backward compatibility for classes that
> implement SerializationVersions.
>
> Either implementing `toDataPre/fromDataPre` methods that Data
> Serialization will invoke based on the version of the sender/receiver
> (preferred way), or using `fromData/toData` methods using
> `InternalDataSerializer.getVersionForDataStream`.
>
> In the case of this class, we have `toDataPre/fromDataPre` methods
> implemented so, according to what is described in the wiki, it should not
> be necessary to add any extra check to the `fromData/toData`methods. But
> there is this check I mentioned which is necessary according to some
> backward compatibility tests in Geode. So my question is why is it
> necessary?
>
> Thanks,
>
> -Alberto
>
>
>
> From: Ju@N
> Sent: Tuesday, May 19, 2020 2:54 PM
> To: dev@geode.apache.org
> Subject: Re: Question about version checks inside fromData method in
> GatewaySenderEventImpl
>
> Hello Alberto,
>
> It looks like the property *isConcurrencyConflict* was added as part of
> *GEODE-3967* [1] and this was released as part of Geode 1.9.0; that seems
> to the reason why the check is in place: if we get an instance of
> *GatewaySenderEventImpl* from a member running a version higher than 1.9.0
> then we are 100% sure that the serialized form will contain the new field
> so we can parse it, if the serialized *GatewaySenderEventImpl *comes from
> an older member the filed won't be there so we don't even try to parse it.
> Hope I didn't miss anything.
> Cheers.
>
> [1]: https://issues.apache.org/jira/browse/GEODE-3967
>
> On Tue, 19 May 2020 at 13:14, Alberto Gomez
> wrote:
>
> > Hi,
> >
> > Looking at the fromData method of GatewaySenderEventImpl I see that it
> > contains a conditional reading of the isConcurrencyConflict when version
> is
> > greater than Geode 1.9.0 one. See below:
> >
> > @Override
> > public void fromData(DataInput in,
> > DeserializationContext context) throws IOException,
> > ClassNotFoundException {
> > fromDataPre_GEODE_1_9_0_0(in, context);
> > if (version >= Version.GEODE_1_9_0.ordinal()) {
> > this.isConcurrencyConflict = DataSerializer.readBoolean(in);
> > }
> > }
> >
> > I have looked at the implementation of this method in other classes and
> > have not seen this checking of version pattern. I have also observed that
> > if the "if" is removed some backward compatibility tests fail.
> >
> > Could anybody tell me why this check (the if) is necessary given that
> > there is already a fromDataPre_GEODE_1_9_0 method in the class?
> >
> > Thanks in advance,
> >
> > -Alberto G.
> >
>
>
> --
> Ju@N
>
--
Ju@N
[PROPOSAL]: GEODE-8150 into support/1.13
Hello devs, I'd like to propose bringing *GEODE-8150 [1] *to the *support/1.13* branch. The ticket is basically to revert the upgrade of the *classgraph* [2] library, we found some performance issues that are not addressed even when using the latest released version, the full details can be seen in the ticket. The fix has been merged into develop through commit 07bf3dd827f29a5deb8619f79203d94847a1a823 [3]. Best regards. [1]: https://issues.apache.org/jira/browse/GEODE-8150 [2]: https://github.com/classgraph/classgraph [3]: https://github.com/apache/geode/commit/07bf3dd827f29a5deb8619f79203d94847a1a823 -- Ju@N
Re: Proposal to backport GEODE-8167
+1 On Thu, 21 May 2020 at 16:53, Anthony Baker wrote: > +1 > > > On May 21, 2020, at 8:51 AM, Owen Nichols wrote: > > > > Some automated scans have flagged Geode Pulse as potentially containing > “high" security vulnerability CVE-2020-5407. > > > > Analysis shows that this saml vulnerability is not applicable to Geode > Pulse. > > > > It is low risk to bump the spring-security dependency to the latest > version to avoid false positives in automated scans. This change is > already on develop and all tests have passed. It would be nice to include > this in 1.13. > > > > -Owen > > -- Ju@N
Re: [PROPOSAL]: GEODE-8150 into support/1.13
Looks like there's enough consensus already (three +1s), so I've cherry picked the commit into support/1.13 branch [1]. Best regards. [1]: https://github.com/apache/geode/commit/281937d17df639cd416f0e6ce47dd73ed9e8595f On Thu, 21 May 2020 at 17:16, Udo Kohlmeyer wrote: > +1.. > On May 21, 2020, 8:12 AM -0700, Ju@N , wrote: > Hello devs, > > I'd like to propose bringing *GEODE-8150 [1] *to the *support/1.13* branch. > The ticket is basically to revert the upgrade of the *classgraph* [2] > library, we found some performance issues that are not addressed even when > using the latest released version, the full details can be seen in the > ticket. > The fix has been merged into develop through commit > 07bf3dd827f29a5deb8619f79203d94847a1a823 [3]. > Best regards. > > [1]: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8150&data=02%7C01%7Cudo%40vmware.com%7C2dac2ec3d111496df0f008d7fd9964d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637256707567034068&sdata=lQ8z8eamQCEzKNwJal0W0k%2B5vjJWguzL8M7vrPPfQhQ%3D&reserved=0 > [2]: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fclassgraph%2Fclassgraph&data=02%7C01%7Cudo%40vmware.com%7C2dac2ec3d111496df0f008d7fd9964d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637256707567044068&sdata=vZzkQPvUe7vw2iMxt79rd4cTh6dAjesbrqy8urNVOlA%3D&reserved=0 > [3]: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fcommit%2F07bf3dd827f29a5deb8619f79203d94847a1a823&data=02%7C01%7Cudo%40vmware.com%7C2dac2ec3d111496df0f008d7fd9964d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637256707567044068&sdata=iuR%2FW3bNjI7LvDlbvo1vxLyoGwp8IS4GyDYsWb%2FuabM%3D&reserved=0 > > -- > Ju@N > -- Ju@N
Re: Creating Regions Dynamically
Hello there, The regions manually created using the Geode API are not persisted to the *cluster-configuration-service [1]*, that's basically the reason why you don't see them after the server is restarted. It's possible to dig into the source code and persist the changes yourself (have a look at the *CreateRegionCommand [2]* class), but it's also something I wouldn't recommend... Instead of that, I'd suggest to use the *Geode SHell [2]* to manage your regions directly. Hope this helps. Best regards. [1]: https://geode.apache.org/docs/guide/112/configuring/cluster_config/gfsh_persist.html [2]: https://github.com/apache/geode/blob/develop/geode-gfsh/src/main/java/org/apache/geode/management/internal/cli/commands/CreateRegionCommand.java [3]: https://geode.apache.org/docs/guide/112/tools_modules/gfsh/chapter_overview.html On Fri, 22 May 2020 at 04:42, 18911098...@163.com <18911098...@163.com> wrote: > dear: > Dynamically Create Region Demo ，When Geode Server Reboot ,Lost > Region instance > > https://geode.apache.org/docs/guide/112/developing/region_options/dynamic_region_creation.html > > I don't know why? Hope to help me, thanks! > > > > 18911098...@163.com > -- Ju@N
[PROPOSAL]: BackPort GEODE-8029 to support/1.12 and support/1.13
Hello devs, I'd like to propose bringing GEODE-8029 [1] to the *support/1.12* and *support/1.13* branches. The fix has been merged into develop through commit bc0090dc93643fd4d09c79a4b0c29d883172b546 [2], and it's basically to make sure we delete unused drfs upon initialization to prevent the proliferation of unused records and files within the file system, which could cause members to fail during startup while recovering disk-stores. Best regards. [1]: https://issues.apache.org/jira/browse/GEODE-8029 [2:] https://github.com/apache/geode/commit/bc0090dc93643fd4d09c79a4b0c29d883172b546 -- Ju@N
Re: [PROPOSAL]: BackPort GEODE-8029 to support/1.12 and support/1.13
Thanks everyone!. I've cherry picked the commit into branches support/1.12[1] and support/1.13[2]. Best regards. [1]: https://github.com/apache/geode/commit/bdeff9d6144c47ea687cf3b7d25f12598228 [2]: https://github.com/apache/geode/commit/7c1ffd528ff72b920dd606604de2a744c1728b23 On Wed, 10 Jun 2020 at 18:51, Dave Barnes wrote: > Looks like the community approves, Ju@n. Go ahead and merge. > Thanks, > Dave > > On Wed, Jun 10, 2020 at 10:37 AM Joris Melchior > wrote: > > > +1 > > ________ > > From: Ju@N > > Sent: June 10, 2020 6:18 > > To: dev@geode.apache.org > > Subject: [PROPOSAL]: BackPort GEODE-8029 to support/1.12 and support/1.13 > > > > Hello devs, > > > > I'd like to propose bringing GEODE-8029 [1] to the *support/1.12* and > > *support/1.13* branches. > > The fix has been merged into develop through commit > > bc0090dc93643fd4d09c79a4b0c29d883172b546 [2], and it's basically to make > > sure we delete unused drfs upon initialization to prevent the > proliferation > > of unused records and files within the file system, which could cause > > members to fail during startup while recovering disk-stores. > > Best regards. > > > > [1]: > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8029&data=02%7C01%7Cjmelchior%40vmware.com%7C96432ff1699a4d2ed2a508d80d27a970%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637273811288277601&sdata=kw1jFlsIIdlhh%2FTxW%2BcZD2BVmfQzGSCgoW1xyRdKE4E%3D&reserved=0 > > [2:] > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fcommit%2Fbc0090dc93643fd4d09c79a4b0c29d883172b546&data=02%7C01%7Cjmelchior%40vmware.com%7C96432ff1699a4d2ed2a508d80d27a970%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637273811288277601&sdata=R412kMw3EXKl6%2FOgKP3OEZDuJJs%2F3uRIT0AZljdlpDo%3D&reserved=0 > > > > -- > > Ju@N > > > -- Ju@N
Re: [PROPOSAL] merge GEODE-8195 to support/1.13 and support/1.12
+1 On Fri, 26 Jun 2020 at 15:51, Bruce Schuchardt wrote: > This small fix avoids a failure of one cluster to communicate with the > locators of another cluster, ensuring that a proper handshake for WAN > communications occurs. Without the fix it’s possible that WAN connections > will not be formed and updates will not be transmitted between sites. > > https://github.com/apache/geode/pull/5306 > > -- Ju@N
Re: Proposal to bring GEODE-8315 (shiro upgrade) to support branches
+1 On Tue, 30 Jun 2020 at 17:03, Owen Nichols wrote: > Recently shiro-1.5.2.jar is getting flagged for critical security > vulnerability CVE-2020-11989. > > Analysis shows that Geode does not use Shiro in a manner that would expose > this vulnerability. > > The risk of bringing GEODE-8315 is very low (difference between Shiro > 1.5.2 and 1.5.3 is bugfix only). GEODE-8315 has been on develop for 2 days > and passed the pipeline. > > This fix is critical to avoid false positives in automated vulnerability > scans, so it would be nice to bring before 1.13.0 release. > -- Ju@N
Re: Question about gateway sender stopped and memory consumption
I recall some discussion about this in the past, there even was an "RFC" that never got implemented: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=80452478. Best regards. On Thu, 2 Jul 2020 at 18:41, Kirk Lund wrote: > I would have expected unsent events to be stored in a queue that is backed > by a persistent region or something on disk. If that's not currently true, > then it seems like a good direction might be to make tmpDroppedEvents use a > durable queue of some sort that overflows to disk. > > > > On Thu, Jul 2, 2020 at 10:33 AM Alberto Gomez > wrote: > > > Hi, > > > > We have observed that when a gateway sender is stopped in a site, all the > > events received while it is stopped are stored in the > > 'AbstractGatewaySender.tmpDroppedEvents' queue of the primary sender. The > > elements of this queue are not removed from this queue until the sender > is > > started back again. > > > > This behavior implies that if the gateway sender is stopped for a long > > time, there is a risk of heap exhaustion in the members hosting primary > > senders. > > > > Under split brain situations, if lasting long enough, there could be heap > > exhaustion problems in servers due to the memory used by the gateway > sender > > queues, even if overflow to disk is used -given that part of the event is > > always stored in memory. > > For those situations we had thought about stopping gateway senders when > > the memory used by the gateway sender queues reached a certain memory > > threshold. But according to the above, stopping the gateway senders would > > only make things worse. > > > > Would it make sense for the gateway sender not to store the received > > events in tmpDroppedEvents while it is stopped? > > > > Any suggestion on how to approach the problem of heap exhaustion due to > > the growth of gateway sender queues in long lasting split brain > situations? > > > > Thanks in advance, > > > > Alberto G. > > > > > > > -- Ju@N
[PROPOSAL]: Backport GEODE-8029 to support/1.12 and support/1.13
Hello devs, I'd like to propose bringing GEODE-8029 [1] to the support/1.12 and support/1.13 branches. No, you're not having deja vú (neither this is an error within the Matrix): a couple of weeks ago I've backported another fix for the same ticket to the mentioned branches and sent the proposal to the list with exactly the same subject, but it has proven to be problematic and introduced some regressions... sorry about that. The new fix uses a different approach, solves the original issue and doesn't introduce any new problems (feel free to have a look at the ticket for further details); it has been merged into develop already through commit fdc4401 [2]. As a side note, I've also created a new ticket (GEODE-8325 [3]) to improve the internal behavior and implement a long term solution to avoid the proliferation of unused drf files. Best regards. [1]: https://issues.apache.org/jira/browse/GEODE-8029 [2]: https://github.com/apache/geode/commit/fdc440131f0d562d97f2340d2e7ba5aacf935d62 [3]: https://issues.apache.org/jira/browse/GEODE-8325 -- Ju@N
Re: [PROPOSAL]: Backport GEODE-8029 to support/1.12 and support/1.13
Looks like there's enough votes already, so I've merged the changes into support/1.12 [1] and support/1.13 [2]. Have a nice weekend everyone!. Cheers. [1]: https://github.com/apache/geode/commit/4be10d6a2892cdad7f42ae32f34e0863149f342c [2]: https://github.com/apache/geode/commit/acf14743915d5e8db7adc880e98287209f7299a5 On Fri, 3 Jul 2020 at 17:17, Dick Cavender wrote: > +1 > > -Original Message- > From: Joris Melchior > Sent: Friday, July 3, 2020 9:09 AM > To: dev@geode.apache.org > Subject: Re: [PROPOSAL]: Backport GEODE-8029 to support/1.12 and > support/1.13 > > +1 > > On 2020-07-03, 9:06 AM, "Ju@N" wrote: > > Hello devs, > > I'd like to propose bringing GEODE-8029 [1] to the support/1.12 and > support/1.13 branches. > No, you're not having deja vú (neither this is an error within the > Matrix): > a couple of weeks ago I've backported another fix for the same ticket > to > the mentioned branches and sent the proposal to the list with exactly > the > same subject, but it has proven to be problematic and introduced some > regressions... sorry about that. > The new fix uses a different approach, solves the original issue and > doesn't introduce any new problems (feel free to have a look at the > ticket > for further details); it has been merged into develop already through > commit fdc4401 [2]. As a side note, I've also created a new ticket > (GEODE-8325 [3]) to improve the internal behavior and implement a long > term > solution to avoid the proliferation of unused drf files. > Best regards. > > [1]: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8029&data=02%7C01%7Cdickc%40vmware.com%7C1eda36ff648b4814d5ae08d81f6b5d74%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637293893277285211&sdata=4tamZzomlNfaLufOzWXTT1SYvZmp9s7pGHXPUcV4lsY%3D&reserved=0 > [2]: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fcommit%2Ffdc440131f0d562d97f2340d2e7ba5aacf935d62&data=02%7C01%7Cdickc%40vmware.com%7C1eda36ff648b4814d5ae08d81f6b5d74%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637293893277285211&sdata=oAC9uDq4%2FlB%2FLV%2BzZnECyu4kZdc9c8enf%2BFzOxKgqCs%3D&reserved=0 > [3]: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8325&data=02%7C01%7Cdickc%40vmware.com%7C1eda36ff648b4814d5ae08d81f6b5d74%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637293893277295208&sdata=tLOcaPQVmWQSaOqWLN%2Fx5WkqcRSUriLd5ilo5Bmc4xg%3D&reserved=0 > > > -- > Ju@N > > -- Ju@N
Re: [VOTE] change Default branch for geode-examples to 'develop'
+1 On Fri, 10 Jul 2020 at 15:52, Alberto Bustamante Reyes wrote: > +1 > > De: Joris Melchior > Enviado: viernes, 10 de julio de 2020 15:54 > Para: dev@geode.apache.org > Asunto: Re: [VOTE] change Default branch for geode-examples to 'develop' > > +1 > > On 2020-07-10, 12:39 AM, "Owen Nichols" wrote: > > A fresh checkout of geode and all but one geode- repos > checks out develop as the Default branch. > > The lone exception is geode-examples. Please vote +1 if you are in > favor of changing its Default branch to develop for consistency with the > other repos and other reasons as per recent discussion[1]. > > [1] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fx%2Fthread.html%2Frfec15c0a7d5d6d57beed90868dbb53e3bfcaabca67589b28585556ee%40%253Cdev.geode.apache.org%253E&data=02%7C01%7Cjmelchior%40vmware.com%7C458c4abf934b43480f2308d8248b403a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637299527784977071&sdata=7CRcXQYAkbVtQ5CMFZgKZCMtfyqHw2UxkNPA4KwSl8k%3D&reserved=0 > > -- Ju@N
Re: [PROPOSAL] one-time cleanup of stray and obsolete tags in geode repo
+1 On Thu 30 Jul 2020 at 08:21, Owen Nichols wrote: > Tags in the rel/ namespace should be created by the Geode release manager > as part of an official Geode release only, yet we seem to have some extra > ones somehow. > Further, I don't see any value in keeping RC tags forever long after the > release is final. > > Please vote +1 in favor of trimming the current list of 110 tags down to > 20 to make it nice and easy for newcomers (as well as the rest of us) to > find and checkout a specific version of Geode; otherwise vote -1. If the > majority vote is +1 at 3PM PDT Fri Aug 7, I will proceed to archive and > delete the 90 unnecessary tags as detailed below. > > I propose to KEEP only the following tags, corresponding to official Geode > releases: > > rel/v1.12.0 > rel/v1.11.0 > rel/v1.10.0 > rel/v1.9.2 > rel/v1.9.1 > rel/v1.9.0 > rel/v1.8.0 > rel/v1.7.0 > rel/v1.6.0 > rel/v1.5.0 > rel/v1.4.0 > rel/v1.3.0 > rel/v1.2.1 > rel/v1.2.0 > rel/v1.1.1 > rel/v1.1.0 > rel/v1.0.0-incubating > rel/v1.0.0-incubating.M3 > rel/v1.0.0-incubating.M2 > rel/v1.0.0-incubating.M1 > > I propose a one-time cleanup to DELETE all other tags, specifically: > > develop/highwater > modules-pre-merge > rel/v1.0.0-incubating.M1.RC1 > rel/v1.0.0-incubating.M1.RC2 > rel/v1.0.0-incubating.M2.RC1 > rel/v1.0.0-incubating.M2.RC2 > rel/v1.0.0-incubating.M3.RC1 > rel/v1.0.0-incubating.M3.RC2 > rel/v1.0.0-incubating.M3.RC3 > rel/v1.0.0-incubating.M3.RC4 > rel/v1.0.0-incubating.M3.RC5 > rel/v1.0.0-incubating.M3.RC6 > rel/v1.0.0-incubating.M3.RC7 > rel/v1.0.0-incubating.RC1 > rel/v1.0.0-incubating.RC2 > rel/v1.1.0.RC1 > rel/v1.1.0.RC2 > rel/v1.1.0manualrev-2017-02-16 > rel/v1.1.0manualrev-2017-10-19 > rel/v1.1.1.RC1 > rel/v1.1.1.RC2 > rel/v1.10.0.1 > rel/v1.10.0.1.RC1 > rel/v1.10.0.2 > rel/v1.10.0.RC1 > rel/v1.10.0.RC2 > rel/v1.11.0.1 > rel/v1.11.0.2 > rel/v1.11.0.23755 > rel/v1.11.0.23755_2 > rel/v1.11.0.23755_3 > rel/v1.11.0.3 > rel/v1.11.0.4 > rel/v1.11.0.5 > rel/v1.11.0.6 > rel/v1.11.0.7 > rel/v1.11.0.7565 > rel/v1.11.0.8 > rel/v1.11.0.RC1 > rel/v1.11.0.RC2 > rel/v1.11.0.RC3 > rel/v1.11.0.RC4 > rel/v1.12.0.1 > rel/v1.12.0.1234 > rel/v1.12.0.2 > rel/v1.12.0.23755 > rel/v1.12.0.3 > rel/v1.12.0.4 > rel/v1.12.0.5 > rel/v1.12.0.6 > rel/v1.12.0.RC1 > rel/v1.12.0.RC2 > rel/v1.12.0.RC3 > rel/v1.12.0.RC4 > rel/v1.14.0.23755 > rel/v1.2.0.RC1 > rel/v1.2.0.RC2 > rel/v1.2.1.RC1 > rel/v1.2.1.RC2 > rel/v1.2.1.RC3 > rel/v1.2.1.RC4 > rel/v1.2.1manualrev-2017-10-19 > rel/v1.3.0.RC1 > rel/v1.3.0.RC2 > rel/v1.3.0.RC3 > rel/v1.3.0.RC4 > rel/v1.4.0.RC1 > rel/v1.4.0.RC2 > rel/v1.5.0.RC1 > rel/v1.5.0.RC2 > rel/v1.6.0.RC1 > rel/v1.7.0.RC1 > rel/v1.7.0.RC2 > rel/v1.8.0.RC1 > rel/v1.8.0.RC2 > rel/v1.9.0.1 > rel/v1.9.0.1.RC1 > rel/v1.9.0.2 > rel/v1.9.0.RC1 > rel/v1.9.0.RC2 > rel/v1.9.0.RC3 > rel/v1.9.0.RC4 > rel/v1.9.1-nordix > rel/v1.9.1.RC1 > rel/v1.9.1.RC2 > rel/v1.9.1.RC3 > rel/v1.9.2.RC1 > sga2-core > v1.1.0manualrev-2017-10-19 > v9.0.0-beta.1 > -- Ju@N
Re: [PROPOSAL] Remove "Fix Version/s" and "Sprint" from Jira "Create Issue" dialogue and include "Affects Version/s"
+1 On Tue, 18 Aug 2020 at 06:23, Dave Barnes wrote: > +1 esp addition of "Affects Version/s". > > On Mon, Aug 17, 2020 at 3:07 PM Kirk Lund wrote: > > > +1 if it's possible > > > > On Mon, Aug 17, 2020 at 12:04 PM Donal Evans wrote: > > > > > Looking at the dialogue that opens when you attempt to create a new > > ticket > > > in the GEODE Jira[1], there are two fields included that aren't really > > > necessary and may cause confusion. The "Fix Version/s" field should > > > presumably not be filled out until the issue has actually been fixed, > > > rather than at the time of ticket creation. The "Sprint" field seems to > > no > > > longer serve any purpose at all that I can discern, having only been > > filled > > > in 13 tickets, the most recent of which was created in December > 2018[2]. > > > With the expansion of the community contributing to the Geode project, > > it's > > > important to provide a straightforward experience for people who are > new > > to > > > the project and wish to file tickets, so the presence of these fields > may > > > cause issues. > > > > > > I propose that these two fields be removed from the "Create Issue" > > > dialogue and that the "Affects Version/s" field be added, since that > > field > > > is far more important at time of ticket creation. There are currently > > 3851 > > > bug tickets in the Jira with no "Affects Version/s" value entered at > > > all[3], which I suspect is in part due to that field not being an > option > > in > > > the "Create Issue" dialogue, meaning you have to remember to go back > > after > > > creating the ticket and enter it. With Geode moving to a model of > having > > > support branches and patch releases, properly capturing the versions > > > affected by a given issue becomes even more important. > > > > > > [1] https://i.imgur.com/oQ8CW87.png > > > [2] > > > > > > https://issues.apache.org/jira/projects/GEODE/issues/GEODE-8433?filter=allissues&orderby=cf%5B12310921%5D+ASC%2C+created+DESC > > > [3] > > > > > > https://issues.apache.org/jira/browse/GEODE-8433?jql=project%20%3D%20GEODE%20AND%20issuetype%20%3D%20Bug%20AND%20affectedVersion%20%3D%20EMPTY%20ORDER%20BY%20created%20DESC%2C%20affectedVersion%20ASC%2C%20cf%5B12310921%5D%20ASC > > > > > > -- Ju@N
Re: How to shutdown cluster in non-interactive mode using gfsh
Hello Avinash,
What Geode version are you referring to?.
I've just tried a simple scenario with Geode 1.12.0 and the command works
just fine, even when using non-interactive mode.
You can see the output from in the image below, when I try to shutdown the
cluster within the interactive mode gfsh asks for confirmation but, right
afterwards when I execute the command in non-interactive mode ("-e"), no
confirmation is displayed and the cluster correctly shuts down.
[image: Screenshot 2020-08-31 at 09.24.22.jpg]
Hope this helps.
Best regards.
On Mon, 31 Aug 2020 at 05:15, Avinash Dongre wrote:
> When I try using gfsh I get following
>
> gfsh>shutdown --include-locators=yes --time-out=5
> As a lot of data in memory will be lost, including possibly events in
> queues, do you really want to shutdown the entire distributed system?
> (Y/n): n
>
> And command line version hangs, probably waiting for input
>
> bin/gfsh -e "connect" -e "shutdown --include-locators=yes"
>
> Any clue how I can bypass this
>
> Thanks
> Avinash
>
--
Ju@N
Re: Proposal to bring GEODE-8456 (shiro upgrade) to support branches
+1 On Tue, 1 Sep 2020 at 01:11, Donal Evans wrote: > +1 > > We still have outstanding release blockers for 1.13, so getting this fix > in now just prevents extra work in the future without slowing us down now. > > From: Owen Nichols > Sent: Monday, August 31, 2020 4:19 PM > To: dev@geode.apache.org > Subject: Proposal to bring GEODE-8456 (shiro upgrade) to support branches > > Recently shiro-1.5.3.jar is getting flagged for ‘high’ security > vulnerability CVE-2020-13933. > > Analysis shows that Geode does not use Shiro in a manner that would expose > this vulnerability. > > The risk of bringing GEODE-8456 is low (difference between Shiro 1.5.3 and > 1.6.0 is bugfix and dependency bump only). GEODE-8456 has been on develop > for 6 days and passed all tests. > > This fix is critical to avoid false positives in automated vulnerability > scans. It would be nice to bring to support branches before 1.13.0 is > released. > > Please vote “+1” to approve including this in 1.13.0. If there are any -1 > votes, I’ll wait until after 1.13.0 is done to propose this again. > -- Ju@N
Re: [Discussion] - ClassLoaderService RFC proposal
Looks good to me Udo, thanks for putting it together!. On Mon, 14 Sep 2020 at 11:42, Udo Kohlmeyer wrote: > Hi there Apache Geode Devs, (try 2) > > Please find attached a proposal for a ClassLoaderService. Please review > and ponder on it. > > > https://cwiki.apache.org/confluence/display/GEODE/Introduction+of+ClassLoaderService+into+Geode > > All comments are please to be made in this mail thread. > > —Udo > -- Ju@N
Re: Geode Kafka Connector Verification and availability on Confluent Hub
Amazing work, congratulations to everyone involved! On Fri, 16 Oct 2020 at 04:14, Udo Kohlmeyer wrote: > Nice work everyone!! > > > > Good effort and even better result! > > > > --Udo > > > > *From: *Nabarun Nag > *Date: *Friday, October 16, 2020 at 6:07 AM > *To: *dev@geode.apache.org , u...@geode.apache.org < > u...@geode.apache.org> > *Subject: *Geode Kafka Connector Verification and availability on > Confluent Hub > > Hello everyone, > > > > I would like to inform you that Confluent Inc. has completed its > evaluation of the Geode-Kafka connector and has certified it as a "*Verified > Gold*" level connector. They are also hosting it on the Confluent Hub and > available at https://www.confluent.io/hub/apache/kafka-connect-geode > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.confluent.io%2Fhub%2Fapache%2Fkafka-connect-geode&data=04%7C01%7Cudo%40vmware.com%7C10f6699a9f4c4dd7912508d8713d8412%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637383856307832408%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y4aAayyWyudU53hXFS8YXq9a1I7LzKJKHI6Wv3Gf1G0%3D&reserved=0> > > > > The source code is open-sourced and is being hosted in Apache Software > Foundation repositories: https://github.com/apache/geode-kafka-connector > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-kafka-connector&data=04%7C01%7Cudo%40vmware.com%7C10f6699a9f4c4dd7912508d8713d8412%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637383856307842403%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8Hz6xKJRwFVr5jFNp754Yj6KyLPiH5e%2Bqx5Pz0Y79J0%3D&reserved=0> > > > > This effort was spearheaded by Jason Huynh, with code contributions from > Donal Evans, Anthony Baker, and Nabarun Nag > > Thank you all for the great contributions. > > > > We have a couple of upcoming features > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-kafka-connector%23possible-upcoming-featured&data=04%7C01%7Cudo%40vmware.com%7C10f6699a9f4c4dd7912508d8713d8412%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637383856307852396%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VRL6ZwDnuqKtbnmh5wYfFJO5M9FudhX14yGJK%2BNLUNs%3D&reserved=0> > and would love contributions from the community. > > > > Regards > > Nabarun Nag > > > > Geode-Kafka Connector Quickstart > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-kafka-connector%2Fwiki%2FQuickstart&data=04%7C01%7Cudo%40vmware.com%7C10f6699a9f4c4dd7912508d8713d8412%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637383856307852396%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qW5zwYYx4SNf0ojGY4n32P%2BKJuTZUgdhCU3yf%2FfwnSU%3D&reserved=0> > > Deploying Kafka connect Geode on Confluent Platform > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-kafka-connector%2Fwiki%2FDeploying-Kafka-connect-Geode-on-Confluent-Platform&data=04%7C01%7Cudo%40vmware.com%7C10f6699a9f4c4dd7912508d8713d8412%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637383856307862391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7VqsGxwEDN4tuFQa5%2FGQqcE6s2z%2FZrSFEU7DzdzT8ew%3D&reserved=0> > -- Ju@N
Re: [PROPOSAL] Backport fix for GEODE-8620 to 1.13.1
+1 On Wed, 21 Oct 2020 at 17:10, Joris Melchior wrote: > +1 > > From: Donal Evans > Date: Wednesday, October 21, 2020 at 12:00 PM > To: dev@geode.apache.org > Subject: [PROPOSAL] Backport fix for GEODE-8620 to 1.13.1 > Hi Geode dev, > > I would like to backport the fix for > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8620&data=04%7C01%7Cjmelchior%40vmware.com%7C59104257e7d346cd291f08d875da76a5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637388928459906084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=alM8ABmKV3xtQqfKnJPzT113isvPbGr%2B7Mh3g11QwM4%3D&reserved=0 > to the 1.13.1 branch. This bug causes incorrect redundancy levels to be > reported for regions in which not all buckets have been created when using > the Restore/StatusRedundancy features introduced in 1.13.0. The fix is > minimal and has passed all tests run against the develop pipeline. > > Thanks, > Donal > -- Ju@N
Re: [PROPOSAL] Change the default value of conserve-sockets to false
ge the setting to what is almost always the "correct" value. > > I have done some experimenting to see what it would take to make this > proposal a reality, and the changes required are very minimal, with only > two existing DUnit tests that need to be modified to explicitly set the > value of conserve-sockets that were previously relying on the default being > true. > > Any feedback on this proposal would be very welcome, and if the response > is positive, I can create a PR with the changes as soon as a decision is > reached. > > Thanks, > Donal > > [1] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F113%2Fmanaging%2Fmonitor_tune%2Fperformance_controls_controlling_socket_use.html&data=04%7C01%7Cjblum%40vmware.com%7C87fe2b03a77045e6335408d88c3037b3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637413486010510705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dSxkBw04EOxr8vw1HP7u0oKMf%2FmNED6lVmaoV6FezGY%3D&reserved=0 > [2] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F113%2Fmanaging%2Fmonitor_tune%2Fsockets_and_gateways.html&data=04%7C01%7Cjblum%40vmware.com%7C87fe2b03a77045e6335408d88c3037b3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637413486010510705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3tOT2lJPdd%2B1xBf4km5iQR6pVYIZVwcA6MelXyTbQ%2Bc%3D&reserved=0 > -- Ju@N
JIRA Assignment Permissions Request
Hello team, Can I get permissions to assign Geode Tickets to myself in JIRA?. Cheers. -- Ju@N
[DISCUSS]: Handling of SDTOUT/STDERR and Signals
Hello Geode devs,
Currently GEODE is "swallowing" all output sent to stdout and stderr by
default and there's no way of changing this behavior when starting members
through *gfsh*.
This, between other things, prevents users, between other things, from
playing around with *System.out.println()* during development phases and
getting thread dumps by executing a plain *kill -3* or *kill -QUIT* using
the processId, which is critical in troubleshooting.
Currently there are two internal flags that can be used to prevent this
default behavior, both have to be used at the same time and both are very
counterintuitive: *gemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true* and
*gemfire.OSProcess.DISABLE_OUTPUT_REDIRECTION=false*. These flags, however,
don't work when starting members through *gfsh*, and that's because the
relevant commands wrongly assume that the flags are already part of the
system properties too early in the lifecycle execution of the command:
*StartXCommand.java*
@CliCommand(value = CliStrings.START_X, help = CliStrings.START_X__HELP)
@CliMetaData(shellOnly = true, relatedTopic =
{CliStrings.TOPIC_GEODE_X, CliStrings.TOPIC_GEODE_LIFECYCLE})
public Result startX(...) throws Exception {
(...)
final boolean redirectOutput =
Boolean.getBoolean(OSProcess.ENABLE_OUTPUT_REDIRECTION_PROPERTY);
XLauncher.Builder serverXBuilder =
new XLauncher.Builder()
.setRedirectOutput(redirectOutput)
(...)
}
At this stage during the execution, the system properties used when
starting the members haven't been fully parsed yet and the flags are only
present within the sun.java.command system property, so
*Boolean.getBoolean(OSProcess.ENABLE_OUTPUT_REDIRECTION_PROPERTY)* will
always return *false*. There's a JIRA created with this same description,
and I've started to work on a fix for it: GEODE-4101
.
The proposal would be to add a new flag, *--redirect-ouput*, to the start
commands in GFSH and deprecate the properties
*OSProcess.DISABLE_OUTPUT_REDIRECTION* and
*OSProcess.ENABLE_OUTPUT_REDIRECTION*. To avoid major code changes the
start commands will have this new flag as a parameter and will also set as
*true* a new internal system property
*OSProcess.DISABLE_REDIRECTION_CONFIGURATION* which, as it names implies,
will disable the other two properties when set. In the next major release,
the three properties should be deleted without major changes. Do you see
any flaws here?.
I've tested these changes and the output from *System.out.println()* (from
a function or listener, as an example) goes to the member's log file as
expected. However, no matter what I do, I can't get the output from *kill
-3 / kill -QUIT*, nor can I find a place within the source code where this
signal is caught to explain why the thread dump is not printed in the
member's log file. Am I missing something?.
Last, but not least, when redirecting *stdout/stderr* within a locator with
pulse embedded, all of the deploy steps get logged using a different format
(*this was being swallowed before*):
...
[info 2017/12/19 11:12:12.123 ART locator1 tid=0x1]
Initializing Spring root WebApplicationContext
Dec 19, 2017 11:12:12 AM org.springframework.web.context.ContextLoader
initWebApplicationContext
INFO: Root WebApplicationContext: initialization started
Dec 19, 2017 11:12:12 AM
org.springframework.web.context.support.XmlWebApplicationContext
prepareRefresh
INFO: Refreshing Root WebApplicationContext: startup date [Tue Dec 19
11:12:12 ART 2017]; root of context hierarchy
Dec 19, 2017 11:12:12 AM
org.springframework.beans.factory.xml.XmlBeanDefinitionReader
loadBeanDefinitions
INFO: Loading XML bean definitions from ServletContext resource
[/WEB-INF/mvc-dispatcher-servlet.xml]
Dec 19, 2017 11:12:12 AM
org.springframework.beans.factory.xml.XmlBeanDefinitionReader
loadBeanDefinitions
INFO: Loading XML bean definitions from ServletContext resource
[/WEB-INF/spring-security.xml]
...
This probably happens because jetty uses *StdErrLog* by default and
*log4j2* gets
reconfigured using the *log4j2.xml* file from pulse (ignoring the format
and options defined by *org.apache.geode.internal.logging.LogService*).
What would be the recommended approach here?, add *geode-core* as a compile
dependency of *geode-pulse *and directly use *LogService* instead of the
default *LogManager*?, define a custom *LogService* in *geode-pulse *to
check (JMX maybe?) whether there's a parent context defined already and use
it instead of *LogManager*?, tweak *JettyHelper* to, somehow, threat
*pulse* differently
and disable this deploy logging as it happens today?, leave it as it is and
create a new JIRA to address this separately (maybe moving the internal
logging to a separate module)?.
Best regards
[PROPOSAL]: configure pdx command mandatory flags
d.java:498) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357) at sun.rmi.transport.Transport$1.run(Transport.java:200) at sun.rmi.transport.Transport$1.run(Transport.java:197) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:196) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Currently the configure pdx command only allows the user to configure the ReflectionBasedAutoSerializer class, which requires a decision on whether the check-portability flag is set as true or false. This, in turn, enforces the usage of either the portable-auto-serializable-classes(check-portability=true) or auto-serializable-classes(check-portability=false) so that the command knows exactly which of ReflectionBasedAutoSerializer should create. Within the command we could easily create an empty ReflectionBasedAutoSerializer, but it won't match any classes so it doesn't make any sense at all... The proposal is to make the flags portable-auto-serializable-classes and auto-serializable-classes mandatory, mutually exclusive. Please let me know your thoughts. Best regards. -- Ju@N
Reviews and Conflicts in Pull Requests
Hello geode devs, The Geode Wiki has a lot of useful information, not only about the usage/internal architecture of Geode, but also explanations and guidelines about how Code Contributions [1] should be made. However, some common cases are not explained in detail and, as such, contributors (and also reviewers) might have a hard time trying to deal with these situations in an *standardize* manner. In particular, I'm referring to the following two scenarios, which can happen for every single pull request: - *Reviewers request a change: *do contributors have to make the changes and just add another commit to the original pull request?. Do contributors have to make changes and squash everything in one single commit (executing a *push --force *afterwards)?. Do contributors have to close the pull request and open a new one with everything squashed?. - *Pull Request looks good but, after a while without being merged, somebody else makes a change in develop, causing the original pull request to become conflictive with the current develop branch: *should the committer merging the pull request solve these conflicts as well?. Do contributors have to solve the conflict locally?, if so, do they have to add a new commit to the pull request or squash everything in one single commit (executing a *push --force *afterwards)?. It would be good if we could add these details to the Wiki so everyone knows how to proceed whenever they hit this situations (git commands will also be helpful). Would anyone be able to add this to the Wiki?, or reply to this thread so the approved/recommended process is documented somewhere?. Cheers. [1]: https://cwiki.apache.org/confluence/display/GEODE/Code+contributions -- Ju@N
[PROPOSAL]: Finer Grained Security When Invoking Methods in OQL
Hello all, The current approach used to authorize methods during OQL execution seems to be way too restrictive, I've drafted a proposal to change the current behavior and allow further customization: https://cwiki.apache.org/confluence/display/GEODE/Customizable+Security+When+Invoking+Methods+in+OQL Please have a look and provide your feedback on the proposal. Best regards. -- Ju@N
Steps to follow after becoming a Geode committer
Hello all, My apache account is already created and everything seems to be working just fine, I've already linked my account through https://gitbox.apache.org/setup/ and I can see the option *Merge pull request* in the *GitHub* interface (disabled in the past when I didn't have commit privileges on the project). I have two old pull requests (2376 <https://github.com/apache/geode/pull/2376> for GEODE-5353 <https://issues.apache.org/jira/browse/GEODE-5353> and 2250 <https://github.com/apache/geode/pull/2250> for GEODE-5314 <https://issues.apache.org/jira/browse/GEODE-5314>) already approved by other committers, am I ready to go and merge them myself?, or should I wait for an announcement or something else?. I've already gone through Becoming a Committer <https://cwiki.apache.org/confluence/display/GEODE/Becoming+a+committer> and Code Contributions <https://cwiki.apache.org/confluence/display/GEODE/Code+contributions> but couldn't find a definitive answer about how/when to merge a *pull request* opened by yourself when you're a committer, how does this process work?, should I ask in this list for reviews before merging the changes?, should I wait X amount of days before asking for reviewers?, etc. As a side note, I've received an email from *r...@apache.org * with a link to the vote reference in the *private.apache.geode.org <http://private.apache.geode.org/>* list. I believe that list is only for *PMC* members, so I don't (and won't) have access to that list, am I right?. Sorry for the long email and the amount of questions, just trying to make sure I get things right from the very beginning :-). Best regards. -- Ju@N
Help With ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest
Hello all, Working through GEODE-5739 <https://issues.apache.org/jira/browse/GEODE-5739> I've modified *ServerStarterRule* and *LocatorStarterRule* to use the public *ServerLauncher* and *LocatorLauncher* classes respectively, instead of the internal APIs to start up the members. As part of the changes, I've modified the accessibility of some methods to be *public* instead of *private/protected* (like *getLogFile* so member's logs are redirected to console) and made use of some methods not present at all in older versions (like *setDeletePidFileOnStop*). This causes the test of the subject to fail <http://files.apachegeode-ci.info/builds/geode-pr-2604/test-results/distributedTest/1539612211/> when trying to invoke those if the user requested using older versions of Geode (*IllegalAccessError*, *NoSuchMethodError*, etc.)... Considering that these changes don't actually break the backward compatibility for the product itself, what would be the best solution here?: - Discard the changes and leave the rules as they currently are (rules will continue to use internal APIs instead of launchers). - Extend the current rules, deprecate the old ones, and tweak the *ClusterStartupRule* to choose the correct rule instance when starting members based on the requested version. - Modify the rules to use the old approach (internal APIs) whenever they detect that the user has requested to start a member using an older version of the product. - Other?. Best regards. -- Ju@N
Re: Help With ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest
Hello all, Looks like the JIRA must not be fixed (see this thread [1]) and that the rules should not be modified to use LocatorLauncher/ServerLauncher instead of the internal API, so I'll close both the pull request [1] and GEODE-5739 [2]. Jason: you opened the original JIRA a couple of weeks ago, let me know if you still think it should be fixed and I'll create a DISCUSS thread to move forward. Best regards. [1]: https://github.com/apache/geode/pull/2604 [2]: https://issues.apache.org/jira/browse/GEODE-5739 On Mon, Oct 15, 2018 at 3:14 PM Ju@N wrote: > Hello all, > > Working through GEODE-5739 > <https://issues.apache.org/jira/browse/GEODE-5739> I've modified > *ServerStarterRule* and *LocatorStarterRule* to use the public > *ServerLauncher* and *LocatorLauncher* classes respectively, instead of > the internal APIs to start up the members. As part of the changes, I've > modified the accessibility of some methods to be *public* instead of > *private/protected* (like *getLogFile* so member's logs are redirected to > console) and made use of some methods not present at all in older versions > (like *setDeletePidFileOnStop*). This causes the test of the subject to > fail > <http://files.apachegeode-ci.info/builds/geode-pr-2604/test-results/distributedTest/1539612211/> > when trying to invoke those if the user requested using older versions of > Geode (*IllegalAccessError*, *NoSuchMethodError*, etc.)... > Considering that these changes don't actually break the backward > compatibility for the product itself, what would be the best solution here?: > >- Discard the changes and leave the rules as they currently are (rules >will continue to use internal APIs instead of launchers). >- Extend the current rules, deprecate the old ones, and tweak the >*ClusterStartupRule* to choose the correct rule instance when starting >members based on the requested version. >- Modify the rules to use the old approach (internal APIs) whenever >they detect that the user has requested to start a member using an older >version of the product. >- Other?. > > Best regards. > > -- > Ju@N > -- Ju@N
Build Jobs not accessible?
Hello team, I've submitted https://github.com/apache/geode/pull/2822 a couple of hours ago and the concourse-ci/IntegrationTest failed, even when *./gradlew integrationTest* runs fine locally. I've tried to access the failed build ( https://concourse.apachegeode-ci.info/builds/14585) to see the output and check what's happening but, after logging in, I only see the empty page with the *loading* message: [image: Screen Shot 2018-11-09 at 1.42.17 PM.png] I've also tried to access other failures from other *pull requests* (not mine) and the result is exactly the same. Is everyone having the same issue?, is it just my user?. Best regards. -- Ju@N
Develop Compilation Failure
Hello devs, Compilation in *develop* is failing after my latest commit. Long story short: the *concourse-ci* tests were all green but the *commons-lang* version was upgraded in develop *AFTER* the build finished but *BEFORE* the merge was executed, so the import is currently outdated (should be *org.apache.commons.lang3.ArrayUtils* instead of *org.apache.commons.lang.ArrayUtils*). I've already submitted a PR with the fix, I'll merge it once the *concourse-ci *finishes. BTW: even when the chances of this happening again are quite low, is there anything we can do to automatically prevent the problem?. Cheers. -- Ju@N
[PROPOSAL]: Add GEODE-9000 as Geode 1.14.0 Blocker
Hello team, I'd like to propose adding a newly created ticket, *GEODE-9000 [1]*, to the *1.14.0 Blocker Board* [2] The issue has been recently introduced and, long story short, it prevents members from automatically reconnecting to a distributed system after a full network split - usage of PERSISTENT regions makes things worse as other joining members might get stuck waiting to recover the latest data -. Best regards. [1]: https://issues.apache.org/jira/browse/GEODE-9000 [2]: https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12336052 -- Ju@N
Re: [PROPOSAL] Remove warning logs from FunctionException
Hello all, What about something in the middle?: log a WARNING level message stating that the Function named XXX failed and also log the details (including the stack trace) using DEBUG log level?. This would reduce the amount of logs for functions that fail frequently, and will also allow the person troubleshooting/debugging issues to easily tell that something is wrong with function XXX. Cheers. On Wed, 30 Mar 2022 at 17:52, Jacob Barrett wrote: > > > On Mar 30, 2022, at 9:45 AM, Alberto Gomez alberto.go...@est.tech>> wrote: > > The idea would not be to remove the logs but rather to change the level of > these logs from warning to debug level. > > I agree, if any exception is expected as part user provided action it > should not produce verbose logging. > > -Jake > > -- Ju@N
