[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #1033 was SUCCESSFUL (with 2432 tests)

--- Spring Data GemFire > Nightly-ApacheGeode > #1033 was successful. --- Scheduled 2434 tests in total. https://build.spring.io/browse/SGF-NAG-1033/ -- Thi

New Committers: Use GitBox to Link Apache Account to GitHub Account

Hi Everyone, I just wanted to relay some information to new committers. We determined that in order to get write access to the Geode repository, you need to go to this site and go through the linking process. https://gitbox.apache.org/setup/ If you don't to do this, you will be added to the "Ap

Re: [DISCUSS] Wrapping log calls in Conditionals like isDebugEnabled, isTraceEnabled, etc.

I was just randomly looking into this a couple of days ago as a tangent to 'observability' and came across this Stack Overflow: https://stackoverflow.com/questions/6504407/is-there-a-need-to-do-a-iflog-isdebugenabled-check where the first answer is the most succinct in my opinion. In the geode cod

Code Reviews

I came across this article a while back but just re-read it recently and thought it would be worth sharing. https://medium.freecodecamp.org/unlearning-toxic-behaviors-in-a-code-review-culture-b7c295452a3c I don't think we're doing much, if any, of the 'toxic' behavior, but it's still good to be r

Re: [DISCUSS] Wrapping log calls in Conditionals like isDebugEnabled, isTraceEnabled, etc.

Check the recommended patterns for java8 [1], I think the lambda syntax makes the conditional less needed. Anthony [1] https://logging.apache.org/log4j/2.0/manual/api.html > On Sep 7, 2018, at 11:38 AM, John Blum wrote: > > Grrr, meant.

Re: [DISCUSS] Wrapping log calls in Conditionals like isDebugEnabled, isTraceEnabled, etc.

Grrr, meant... logger.debug("Logging in user {}", user); On Fri, Sep 7, 2018 at 11:37 AM, John Blum wrote: > Technically, I think that is SLF4J syntax (but maybe Log4J2 supports this > format now as well; anyway). > > Still, you should be careful with log statements like... > > logger.debug(

Re: [DISCUSS] Wrapping log calls in Conditionals like isDebugEnabled, isTraceEnabled, etc.

Technically, I think that is SLF4J syntax (but maybe Log4J2 supports this format now as well; anyway). Still, you should be careful with log statements like... logger.debug("Logging in user {}" + user); Assuming the User class itself and an "informative" and properly constructed toString() meth

Re: [DISCUSS] Wrapping log calls in Conditionals like isDebugEnabled, isTraceEnabled, etc.

Checking with logger.isDebugEnabled() it still a good practice for hot paths to avoid the construction of intermediate object arrays to hold the var-args. Some logging libraries have fixed argument optimizations for var-args up to a specific limit. In very hot paths it is nice to check logger.isDeb

Re: [DISCUSS] Wrapping log calls in Conditionals like isDebugEnabled, isTraceEnabled, etc.

I think this pattern is a holdover from using log4j 1. In that version, you added an if check to avoid unnecessary string concatenation if debug was enabled. 1. if (logger.isDebugEnabled()) { 2. logger.debug("Logging in user " + user.getName() + " with birthday " + user.getBirthdayCalen

[DISCUSS] Wrapping log calls in Conditionals like isDebugEnabled, isTraceEnabled, etc.

Hi all, I've noticed a pattern in Geode where we wrap a log call in a check at the same level, such as: if (logger.isDebugEnabled()) { logger.debug("cleaning up incompletely started DistributionManager due to exception", r); } Is there any reason to do this? To my mind, it'

Re: [DISCUSS] and the NEW Apache Geode 1.7.0 release branch has been created

CORRECTION: if '*no*' concerns are raised, we will start with the voting for the release candidate soon. Regrads Nabarun Nag On Fri, Sep 7, 2018 at 9:08 AM Nabarun Nag wrote: > Hello Geode Dev Community, > > We have created a new release branch for Apache Geode 1.7.0 - > "release/1.7.0" > > Pre

[DISCUSS] and the NEW Apache Geode 1.7.0 release branch has been created

Hello Geode Dev Community, We have created a new release branch for Apache Geode 1.7.0 - "release/1.7.0" Previous branch was deleted and has been replaced with a fresh one. Please do review and raise any concern with the release branch. If concerns are raised, we will start with the voting for