I briefly broke compile on develop with a bungled PR merge. I broke a
constructor in DistributionStats because of a conflict during merge. It's
fixed now.
We need some additional PR reviewers on the following PRs. I've tagged who
I think should review them but it's just a suggestion (or guess in some
cases). Please feel free to review anything you're not tagged on as well.
Some of these just need to be *re*-reviewed after requested changes have
been
Thanks for the very thoughtful and well-worded reply, Bill. I would
certainly welcome further discussion on how and where to consistently use
the final keyword (if that's desirable), especially within the context of
reviewing pull requests.
On Wed, Jun 19, 2019 at 11:23 AM Bill Burcham wrote:
>
According to Effective Java 3rd Edition, all local variables are implicitly
made final by the JVM (and thus receiving the same JVM optimizations as a
final variable) without requiring use of the keyword as long as you only
set the value once. So this becomes an unnecessary use of the keyword
final
+1 Looks good
On Mon, Jun 10, 2019 at 5:13 PM Aaron Lindsey wrote:
> +1
>
> I like this approach compared to the previous proposals because it's
> simpler (doesn't require a custom registry) and makes it more
> straightforward to replace stats with Micrometer meters in the future.
>
> - Aaron
>
Reminder: Please review PR #3650 https://github.com/apache/geode/pull/3650.
Cleanup commits are separated from the fix commits to help facilitate
review.
GEODE-6183: Fix isAttachAPIFound and launcher tests
Thanks,
Kirk
+1 for doing whatever facilitates reviewing and is best for the PR (which
may vary by PR or even reviewers)
-1 to disallowing or even strongly discouraging force pushing in a PR (go
ahead and merge or rebase as each person prefers but don't force that
preference on others)
I prefer to separate cle
I'm -1 for requiring N reviews before merging a commit.
Overall, I support Lazy Consensus. If I post a PR that fixes the flakiness
in a test, the precheckin jobs prove it, and it sits there for 2 weeks
without reviews, then I favor merging it in at that point without any
reviews. I'm not going to
I favor providing a detailed log message that includes the Throwable as an
argument.
I have seen code like the following in Geode:
} catch (Exception exception) {
logger.error(exception.getMessage());
}
...but I consider that to be a naive anti-pattern for informing the user
that a problem occ
Use '--warning-mode all' to show the individual deprecation warnings.
See
https://docs.gradle.org/5.4/userguide/command_line_interface.html#sec:command_line_warnings
*BUILD FAILED* in 57s
389 actionable tasks: 46 executed, 86 from cache, 257 up-to-date
On Wed, May 8, 2019 at 1:
I'll assign the bug to you so you can decide if you want to close it or try
to fix it...
On Wed, May 8, 2019 at 1:26 PM Kirk Lund wrote:
> Other people including Barry have run into it as well.
>
> No, I'm not using --offline, but I will try --refresh-dependencies. The
> o
marks is an external wrapper that
> > executes geode commands, right?
> >
> > On Wed, May 8, 2019, 12:12 Jacob Barrett wrote:
> >
> > > Maven local is necessary for some of our other build processes like
> > > benchmarks.
> > >
> > > Is t
I'd like like to remove mavelLocal the Geode gradle files.
GEODE-6753: Use of mavenLocal in gradle may cause build to fail with
missing tests dependencies
https://issues.apache.org/jira/browse/GEODE-6753
Thanks,
Kirk
Is there a way to run a geode-pulse uiTest on the command-line without it
failing due to "webdriver.chrome.driver system property"? I would expect
the gradle build to be setting this property.
$ ./gradlew geode-pulse:uiTest --tests PulseAuthorizationTest
...
> Task :geode-pulse:uiTest
org.apach
I think I gave you permissions for this. Let me know if it doesn't work for
you. Thanks!
On Mon, Apr 22, 2019 at 7:16 AM Owen Nichols wrote:
> As per Geode release manager instructions, I will need to bulk-transition
> resolved issues to completed (once we have voted to release a 1.9.0 RC).
> Pl
> WaitCriterion extends ThrowingRunnable. So this pattern should still work
> as WaitCriterion did before. But just using an assertion inside of a lambda
> is the better option.
>
> -Dan
>
> On Thu, Apr 11, 2019 at 12:02 PM Kirk Lund wrote:
>
> > Just a quick heads up... I
Just a quick heads up... I'm seeing an Awaitility usage pattern that is
broken and does nothing. Specifically, it's any uses of dunit WaitCriterion
with untilAsserted:
GeodeAwaitility.*await().untilAsserted(new WaitCriterion*() {
@Override
public boolean done() {
r
Done! You should have permissions now. Thanks!
On Wed, Apr 10, 2019 at 3:18 PM Aaron Lindsey wrote:
> Sorry, I forgot to add that my username is aaronlindsey
>
> On Wed, Apr 10, 2019 at 3:17 PM Aaron Lindsey wrote:
>
> > Hi,
> >
> > I would like to request permission to create and edit tickets
Done! You should have edit permissions now. Thanks!
On Wed, Apr 10, 2019 at 3:15 PM Aaron Lindsey wrote:
> Hi,
>
> I would like to be able to edit the wiki here:
> https://cwiki.apache.org/confluence/display/GEODE
>
> My username is aaronlindsey.
>
> Thanks,
> Aaron Lindsey
>
Done! You should have permissions to edit both. Thanks!
On Wed, Apr 10, 2019 at 3:13 PM Alberto Bustamante Reyes
wrote:
> Hi Geode community,
>
>
> I would like to have permissions to edit the wiki and assign me tickets.
> Could someone help me with this?
>
> My username is alberto.bustamante.re
Done! If there's anything you find that doesn't work for you, let me know.
Thanks!
On Wed, Apr 10, 2019 at 11:35 AM Owen Nichols wrote:
> Hi, my Apache LDAP username is onichols.
>
> I would like to request permission to edit
> https://cwiki.apache.org/confluence/display/GEODE <
> https://cwiki.
>> by allowing them to continue to limp along on deprecated, unmaintained
> and
> >>> untested APIs because we missed an arbitrary window to remove the
> symbols.
> >>>
> >>> If however the community agrees with you interpretation then we must
> make
>
missed an arbitrary window to remove the
> symbols.
> >>
> >> If however the community agrees with you interpretation then we must
> make
> >> sure a ticket is created for the next major with a list of deprecated
> items
> >> and updated when new items are deprecated s
1) +1 YES. If we continue to *not* have at least one major release per
year, then I 100% support the removal of deprecated APIs and features in a
minor release such as 1.10. If we decide to have at least one major release
per year, then I'd be willing to revisit this and consider not allowing
remov
ia
> command-line arguments --no-daemon and --no-parallel respectively, if you
> don't want that behavior to be the default as specified in your local
> ~/.gradle/gradle.properties.
>
> On Tue, Mar 26, 2019 at 11:46 AM Kirk Lund wrote:
>
> > I actually have two lines in
on a Mac using gradlew in geode (I don't have my own
> version of gradle installed) and oracle jdk1.8.0_202.
>
> On Tue, Mar 26, 2019 at 10:48 AM Kirk Lund wrote:
>
>> Few more details that might help others...
>>
>> Each Geode module fails in the same way but o
;t have my own
version of gradle installed) and oracle jdk1.8.0_202.
On Tue, Mar 26, 2019 at 10:48 AM Kirk Lund wrote:
> Few more details that might help others...
>
> Each Geode module fails in the same way but obviously on a different .java
> file, and I have not altered these .jav
vocationTargetException
On Tue, Mar 26, 2019 at 10:43 AM Kirk Lund wrote:
> Intermittent build error caused by spotlessJava. My checkout of Geode
> intermittently gets into a state that then fails to build. I've been seeing
> this come and go for the last month or two. I'm n
Intermittent build error caused by spotlessJava. My checkout of Geode
intermittently gets into a state that then fails to build. I've been seeing
this come and go for the last month or two. I'm not sure what puts it into
this state but executing:
$ ./gradlew clean build -x test
...will repeatedly
Please review GEODE-6295: Add Micrometer-based metrics system #3277 if you
have time:
https://github.com/apache/geode/pull/3277
Thanks,
Kirk
Please review our PR. Thanks!
On Fri, Mar 8, 2019 at 4:09 PM Kirk Lund wrote:
> Please review GEODE-6295: Add Micrometer-based metrics system #3277 and
> provide any feedback you have in the PR or feel free to reply to this email
> thread.
>
> https://github.com/apache/
Please review GEODE-6295: Add Micrometer-based metrics system #3277 and
provide any feedback you have in the PR or feel free to reply to this email
thread.
https://github.com/apache/geode/pull/3277
Thanks,
Kirk
Anyone have time to review a PR for me? It fixes up another DUnit rule so
it works with adding and bouncing VMs.
https://github.com/apache/geode/pull/3263
Thanks,
Kirk
on't have to worry about aligning versions of
> what's in the code with potential versions of the outside resource. So my
> vote is for augmenting the comment. Maybe we can do even better and make
> the code or test self-explanatory enough to need even fewer comments?
>
>
Well, the problem is that different people disagree on what's "meaningful"
in this context. For example:
See PersistentPartitionHangsDuringRestartRegressionTest.java
* /***
* * RegressionTest for bug 42226. *
* * 1. Member A has the bucket *
* * 2. Member B starts creating the bucket. It t
org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest
> cannotStopServerAsClusterReaderOverHttp FAILED
org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
Despite our attempts to make precheckin free of flaky failures, I'm still
seeing at least one flaky failure (that does not reproduce and does not
correlate to my PR changes) in every single precheckin launched for my PRs.
For example, the latest one (
https://concourse.apachegeode-ci.info/builds/3
Quite a few Geode stats are currently defined as IntCounters which very
easily wrap past Integer.MAX_VALUE. Some users wanted these stats to not
wrap to negative MAX_VALUE, so my team defined the following two tickets
and changed them to LongCounters on the develop branch:
GEODE-6345: StatSamplerS
Feb 8, 2019 at 2:01 PM Kirk Lund wrote:
> We have a src/main class called UseJacksonForJsonPathRule which uses
> classes from this dependency in geode-junit/build.gradle:
>
> compile('com.jayway.jsonpath:json-path')
>
> I'm trying to write a unit test in src/test
We have a src/main class called UseJacksonForJsonPathRule which uses
classes from this dependency in geode-junit/build.gradle:
compile('com.jayway.jsonpath:json-path')
I'm trying to write a unit test in src/test called
UseJacksonForJsonPathRuleTest but it fails with the following
NoClassDefFoun
> > a doubt go back to our usual flow of merging to develop.
> > >
> > > Thoughts?
> > >
> > > On Thu, Feb 7, 2019 at 2:37 PM Kirk Lund wrote:
> > >
> > >> Hmm, and that was another false search hit in Jira! Searching for
> > >
Yep, I'll ping you later this afternoon to see if you're free. Thanks!
On Thu, Feb 7, 2019 at 4:11 PM Robert Houghton wrote:
> Can I work with you on this tomorrow?
>
> On Thu, Feb 7, 2019, 15:09 Kirk Lund wrote:
>
> > The usual geode src sets like integrationTest
The usual geode src sets like integrationTest don't already exist in some
modules such as geode-dunit.
I'm trying to write a new IntegrationTest but simply creating the
directories and placing a new .java file in it doesn't seem to work.
geode-dunit/src/integrationTest/java/org/apache/geode/test/
Kirk Lund wrote:
> The UpgradeTest failures on your latest commit for this PR are
> WANRollingUpgradeNewSenderProcessOldEvent which seems to be a reoccurrence
> of [GEODE-3967](https://issues.apache.org/jira/browse/GEODE-3967). I
> recommend having Gester take a look at that these failure
://issues.apache.org/jira/browse/GEODE-3967) as resolved
on Jan 9th.
On Thu, Feb 7, 2019 at 12:37 PM Jens Deppe wrote:
> No worries. I think I have a better fix now. At least the builds are moving
> again.
>
> On Thu, Feb 7, 2019 at 12:11 PM Kirk Lund wrote:
>
> > Sorry, go
Sorry, go ahead and revert the commit and reopen the PR.
On Thu, Feb 7, 2019 at 11:36 AM Jens Deppe wrote:
> I was still working on a fix...
>
> On Thu, Feb 7, 2019 at 11:31 AM Kirk Lund wrote:
>
> > I merged it in.
> >
> > On Thu, Feb 7, 2019 at 11:28 AM Kirk Lun
I merged it in.
On Thu, Feb 7, 2019 at 11:28 AM Kirk Lund wrote:
> I think we should go ahead and merge in
> https://github.com/apache/geode/pull/3172 since it resolves the
> GfshConsoleModeUnitTest UnitTest failures.
>
> On Thu, Feb 7, 2019 at 9:57 AM Nabarun Nag wrote:
>
&
I think we should go ahead and merge in
https://github.com/apache/geode/pull/3172 since it resolves the
GfshConsoleModeUnitTest UnitTest failures.
On Thu, Feb 7, 2019 at 9:57 AM Nabarun Nag wrote:
> FYI, I have just merged a ci timeout fix to increase the timeout for
> geode-benchmarks to 4h. Th
Did someone break unit tests?
I have 3 PRs with unit tests failing in GfshConsoleModeUnitTest:
org.apache.geode.management.internal.cli.shell.GfshConsoleModeUnitTest >
consoleModeShouldRedirectOnlyJDKLoggers FAILED
java.lang.AssertionError:
Expecting:
<"org.apache.geode.management.i
Tue, Feb 5, 2019 at 11:55 AM Kirk Lund wrote:
> ExecutorServiceRuleDumpThreads.showsThreadBlockedByOtherThread fails
> intermittently in precheckin.
>
> UnitTestOpenJDK11 failure: [
> https://concourse.apachegeode-ci.info/builds/35684|https://concourse.apachegeode-ci.in
ExecutorServiceRuleDumpThreads.showsThreadBlockedByOtherThread fails
intermittently in precheckin.
UnitTestOpenJDK11 failure: [
https://concourse.apachegeode-ci.info/builds/35684|https://concourse.apachegeode-ci.info/builds/35684
]
*This is one I recently created, so I'll fix it. *Not sure why it
LocatorUDPSecurityDUnitTest failed in one of my PR precheckins. It does not
reproduce on my branch and I cannot find any open Jira tickets for it.
DistributedTestOpenJDK11 failure:
https://concourse.apachegeode-ci.info/builds/35457
I'm not sure who to assign this to. Any suggestions or volunteers
UpgradeTestOpenJDK8 failure:
https://concourse.apachegeode-ci.info/builds/35460
On Tue, Feb 5, 2019 at 9:40 AM Kirk Lund wrote:
> ClientServerMiscBCDUnitTest failed in one of my PR precheckins. It does
> not reproduce on my branch and I cannot find any open Jira tickets for it.
>
>
ClientServerMiscBCDUnitTest failed in one of my PR precheckins. It does not
reproduce on my branch and I cannot find any open Jira tickets for it.
I'm not sure who to assign this to. Any suggestions or volunteers?
Is the test expected to potentially generate and log a ConnectException?
Does the t
Does anyone have time to review PR #3123 for me?
GEODE-6301: Use ThreadInfo.toString in ExecutorServiceRule.dumpThreads
https://github.com/apache/geode/pull/3123
This PR changes ExecutorServiceRule.dumpThreads to use
java.lang.management.ThreadInfo.toString() which includes lock monitors and
sync
+1 to add Micrometer in the described way and I'll add my approval to the
PR as well
On Fri, Feb 1, 2019 at 4:16 PM Dale Emery wrote:
> Hello all,
>
> I've created a PR to add Micrometer to Geode:
> https://github.com/apache/geode/pull/3153
>
> I invite your review.
>
> The Micrometer system inc
I just filed https://issues. apache.org/jira/browse/GEODE-6343 against
ImportClusterConfigTest.importWouldNotShutDownServer because it failed in a
precheckin. I'm not sure who to assign this failure to. Any suggestions or
volunteers?
Failure:
https://concourse.apachegeode-ci.info/builds/34064
Sta
Anyone want to review my PR, please?
GEODE-6313: Make ControllableProcess fail if status is only whitespace #3112
https://github.com/apache/geode/pull/3112
Thanks,
Kirk
ownable synchronizers:
- <0xd0884428> (a
java.util.concurrent.ThreadPoolExecutor$Worker)
On Wed, Jan 23, 2019 at 10:02 AM Kirk Lund wrote:
> I hit a dunit hang in one of my precheckin runs.
>
> The only test mentioned in callstacks/dunit-hangs.txt is
> ClusterC
I hit a dunit hang in one of my precheckin runs.
The only test mentioned in callstacks/dunit-hangs.txt is
ClusterConfigLocatorRestartDUnitTest.
I see some Pooled Message Processor threads that might be hung waiting for
the same
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject
I saw the same problem a few weeks ago. I ended up deleting the directories
in my .m2 repository and rebuilding. That seemed to fix it.
The cause seems to have something to do with that log4j core tests jar, but
I'm not sure why our build would be looking for the corresponding sources
jar. If anyo
ava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
On Fri, Jan 18, 2019 at 2:24 PM Kirk Lund wrote:
> And my description doesn't match the threads again... Just ignore the
> message.
>
> Look at the threads if you care
And my description doesn't match the threads again... Just ignore the
message.
Look at the threads if you care.
On Fri, Jan 18, 2019 at 2:18 PM Kirk Lund wrote:
> Have there been any changes within the last year involving the following?
> Is anyone familiar with getOrCreateDefaultDi
Have there been any changes within the last year involving the following?
Is anyone familiar with getOrCreateDefaultDiskStore and when it's invoked?
When Region creation for a persistent Region does not specify a disk store,
the code call getOrCreateDefaultDiskStore. It then proceeds to create the
tion it will
> use the toString of the member ID. I think that's what's happening to
> you. The getName() method in InternalDistributedMember doesn't return a
> string like you've described. It returns whatever was configured as the
> "name" in the distrib
quire the toString() of an object
> to never change. Let's add another method that returns a Bean
> identifier and is documented to never change.
>
> On 1/15/19 9:45 AM, Kirk Lund wrote:
> > Sorry about the confusion. I meant that the change of membership port
> > resu
owever there is also a "unique ID" in
> > LonerDistributionManager that was supposed to address this problem but
> > apparently didn't.
> >
> > On 1/14/19 4:45 PM, Kirk Lund wrote:
> >> So I was stepping through some WAN tests in IJ debugger (on de
So I was stepping through some WAN tests in IJ debugger (on develop with no
changes) and discovered that any MXBeans that are created before starting a
server port (either using CacheServer or GatewayReceiver) are broken and
fail to be updated after that -- the ObjectNames include the
DistributedMe
I just committed a change to develop which catches the
IllegalStateException caused by JDK-8207200 when the StatSampler samples
JVM memory usage using MemoryMXBean.
commit 1143af997292df0f6d480084ffd2103fa2c17bbf (origin/develop,
origin/HEAD)
Author: Kirk Lund
Date: Mon Jan 7 16:43:34 2019
isable the
merge button, then my PR could potentially be blocked indefinitely.
After we get it more consistently GREEN, I would be willing to change my
vote to +1.
On Fri, Dec 21, 2018 at 10:36 AM Kirk Lund wrote:
> I was responding to Udo's comment:
>
> "Could one not configure
If anyone is free to review a couple PRs, please take a look at mine:
GEODE-3205: Cleanup and reenable DiskSpaceLimitIntegrationTest
https://github.com/apache/geode/pull/3035
- basically, the FILE_SIZE_LIMIT_BYTES was too small, resulting in rolling
too many
- added lots more info in assertion fai
alue that wasn't
> whitelisted. The message would be rejected and the thread issuing the
> function would hang.
>
>
>
> On 12/21/18 2:42 PM, Kirk Lund wrote:
> >
> >
> > I filed GEODE-6202: DUnit should not enable VALIDATE_SERIALIZABLE_OBJECTS
> > b
ded class.
>
> We also have non-default values for cluster configuration in dunit runs.
>
>
> On 3/13/18 10:03 AM, Kirk Lund wrote:
> > I want to propose using the default value for
> validate-serializable-object
> > in dunit tests instead of forcing it on for all dunit t
Just a reminder: please do not @Ignore tests that flicker.
I was pairing on some statistics changes this week and ran across a
disabled test in DiskSpaceLimitIntegrationTest:
@Test
@Ignore("Fails frequently in docker container.")
public void aboveZeroDeletesPreviousFiles() throws Exception
les wrote:
> Kirk, this change would not require you to get someone to merge it. It
> would just require that your PR pass CI before it can be merged.
>
> On Thu, Dec 20, 2018 at 2:38 PM Kirk Lund wrote:
>
> > I have enough trouble just getting other developers to review my PR
ke we forgot to clean
> > up the javadocs. Will make a PR to fix ASAP.
> >
> > -Aditya
> >
> > On Thu, Dec 20, 2018 at 1:57 PM Kirk Lund wrote:
> >
> >> Just a reminder that any classes not behind internal packages need to
> have
> >> functio
I have enough trouble just getting other developers to review my PR. I
don't want to have to struggle to find someone to merge it for me, too.
On Mon, Nov 19, 2018 at 4:09 PM Udo Kohlmeyer wrote:
> I don't believe "name and shame" is a hammer we should wield, but if we
> have use it... use it wi
Just a reminder that any classes not behind internal packages need to have
functional Javadocs.
We have Javadoc errors involving
org/apache/geode/cache/configuration/RegionAttributesType.java referring to
RegionTimeToLive which I can't find when I grep.
> Task :geode-assembly:docs
/Users/klund/de
My other IJ project is now broken after letting IJ update. Anyone know
anything about geode-dependency-management.gradle or why it would cause:
Caused by: org.gradle.api.plugins.UnknownPluginException: Plugin with id
'io.spring.dependency-management' not found.
I tried refreshing from Gradle even
me that these classes would be getting built at all since they're in the
> resources section rather than java. I don't see compiled versions of these
> classes in my geode directory. Perhaps it's an IntelliJ configuration
> issue?
>
> Galen
>
>
> On Mon, Dec 17,
We have a custom annotation in geode-common called @TestingOnly:
geode-common/src/main/java/org/apache/geode/annotations/TestingOnly.java
This annotation was created while pairing with Michael Feathers and the
intention was to annotate non-private constructors or methods that have a
widened visib
IntelliJ just started failing to compile because we have two copies of
ExtendsFunctionAdapter.java. Apparently, IJ was happy enough to ignore
these duplicates for a month or so, but it's now fed up and will no longer
tolerate the duplication so it's failing with:
Error:(21, 8) java: duplicate clas
IntelliJ 2018.3.1 downloads sources jars for the jars of old geode versions
that the geode-old-versions module refers to. The Javadoc {@link class}
editor support in IJ 2018.3.1 then seems to randomly reference some of the
Geode classes in those old geode jars instead of local .java files in the
pr
t wrote:
> It should be in the POM as optional.
>
> > On Dec 6, 2018, at 10:17 AM, Kirk Lund wrote:
> >
> > Is the presence of "ext.optional = true" for spring-shell in
> > geode-core/build.gradle the reason it's missing from the geode-core maven
>
27;aopalliance'
exclude module: 'asm'
exclude module: 'cglib'
exclude module: 'guava'
exclude module: 'spring-aop'
exclude module: 'spring-context-support'
exclude module: 'spring-core'
*ext.optional = true*
}
the contents are as expected. The POM
> is generated from dependencies and transitive dependencies specified in the
> various Gradle files.
>
> > On Dec 6, 2018, at 9:55 AM, Kirk Lund wrote:
> >
> > Is this the only file controlling and testing the dependencies for the
Is this the only file controlling and testing the dependencies for the
geode-core maven pom that we publish?
geode-core/src/test/resources/expected-pom.xml
On Thu, Dec 6, 2018 at 9:52 AM Kirk Lund wrote:
> Can someone please point me at the right place to review and alter
> the depend
Can someone please point me at the right place to review and alter
the dependencies for geode-core that are being published for its maven pom?
Also, are there any tests involving the dependencies of the geode-core
maven pom?
the remaining usages.
> >
> > Ryan
> >
> > On Tue, Dec 4, 2018 at 3:08 PM Kirk Lund wrote:
> >
> > > I filed GEODE-6143: PowerMock should not be used in Geode tests.
> > >
> > > We need everyone to stop using PowerMock in new tests. If anyone
eds
> refactoring more.
>
> -Dan
>
> On Tue, Dec 4, 2018 at 10:27 AM Kirk Lund wrote:
>
> > Anyone have any ideas which unit test is using PowerMock and is
> injecting a
> > mock ClassLoader? This keeps failing in my precheckin runs. I think we
> need
> > to a) remov
Oops, you're right.
On Tue, Dec 4, 2018 at 11:03 AM Jacob Barrett wrote:
> I don’t see how your output indicates the test is running twice. Is there
> more output missing from the clip? Try added ‘—info’ to your Gradle command
> to validate.
>
>
> > On Dec 4, 2018, at
So, based on the output that I see from gradle when I execute this:
$ ./gradlew geode-core:integrationTest --tests AnalyzeSerializablesJUnitTest
...gradle apparently runs the test class twice. I say this because this is
my output:
94% EXECUTING [1m 21s]
geode-core:integrationTest > 3 tests comp
Anyone have any ideas which unit test is using PowerMock and is injecting a
mock ClassLoader? This keeps failing in my precheckin runs. I think we need
to a) remove all uses of PowerMock and b) forbid its use going forward.
2018-12-04 18:11:36,258 Distributed system shutdown hook ERROR Could not
r
Moving internal.logging to geode-logging would involve moving some
internal.logging classes to org.apache.geode.logging. I think that would
help with the logging portion of what you're doing.
On Mon, Dec 3, 2018 at 4:30 PM Kirk Lund wrote:
> I'm iteratively cleaning up geode'
I'm iteratively cleaning up geode's internal logging (specifically our
dependency on log4j core) so that log4j core can be optional and a user
could switch it out for logback or do further customization of our logging.
Even without the modules work you're doing, moving our logging internals to
a n
SampleHandler is in the org.apache.geode.internal.statistics package.
The SampleHandler interface was originally introduced to allow multiple
handlers to receive notification of a statistics sample. Before this
interface, the StatSampler used a StatArchiveWriter directly to write to
the .gfs (Geod
One problem about moving around internal classes is that Geode uses
(proprietary and Java-based) serialization on the wire instead of defining
a wire-format that isn't dependent on class names/structures/packages.
I for one would love to move to a real wire-format with a well-defined
protocol but
ew
SystemOutRule().enableLog();
...then it will repeatedly pass if you run-until-failure in IntelliJ but
only because IJ ends up running it as one test class. It will still fail
when run repeatedly by stressNewTest or if a previous test class caused
Log4J2 to startup within the same JVM.
On Mon, No
Log4J and Logback both capture a reference to System.out and/or System.err
and then use that reference thereafter. This means that any manipulation of
System.out or System.err -- using System.setOut(PrintStream) or
System.setErr(PrintStream) -- probably isn't going to play nicely with
logging in ge
The unit test target has geode-core/src/main/resources in the classpath
which means that Log4J finds our log4j2.xml file and creates/registers our
custom appenders. We might want to have a unit test log4j2.xml that gets
placed earlier on the classpath but only for the unit test target. The
integrat
301 - 400 of 2128 matches
Mail list logo