https://join.slack.com/t/the-asf/shared_invite/enQtNDQ3OTEwNzE1MDg5LWY2NjkwMTEzMGI2ZTI1NzUzMDk0MzJmMWM1NWVmODg0MzBjNjAxYzUwMjIwNDI3MjlhZWRjNmNhOTM5NmIxNDk
#geode
On Fri, Nov 16, 2018 at 3:22 PM Ernest Burghardt
wrote:
> Hi Geode,
>
> Will there be a GEODE Slack in the near future?
>
> Thanks,
running those microbenchmarks in CI as well!
>
> -Dan
>
> On Fri, Nov 16, 2018 at 9:07 AM Kirk Lund wrote:
>
> > That makes sense for some benchmarks but not others. For example, while
> > working on the Logging changes, I wrote a some benchmarks that directly
> use
>
Fri, Nov 16, 2018 at 12:53 PM Kirk Lund wrote:
>
> > I checked the DUnit grep for suspect strings and it's ignore WARNING log
> > level. So we may DUnit tests that are generating the same warning log
> from
> > org.springframework.shell.core.CommandMarker without causing any
I checked the DUnit grep for suspect strings and it's ignore WARNING log
level. So we may DUnit tests that are generating the same warning log from
org.springframework.shell.core.CommandMarker without causing any tests to
fail.
On Fri, Nov 16, 2018 at 12:43 PM Kirk Lund wrote:
> The new logg
The new logging tests assert that when you create a Cache, there are no
WARN log statements being logged.
Unfortunately, src/tests (unit tests) is in the classpath of integration
tests (CacheWithCustomLogConfigIntegrationTest is an integration test).
Apparently springshell gets kicked on when we
That makes sense for some benchmarks but not others. For example, while
working on the Logging changes, I wrote a some benchmarks that directly use
some new internal code to ensure that the new changes perform well.
+1 to creating a benchmarks repo that has general perf tests that will be
run in
Patrick helped me figure this out! Whew, whatta relief. I'll let him
describe it so others benefit (it has something to do with commit time
instead of push time or changes to head sha)...
Thanks,
Kirk
On Tue, Nov 13, 2018 at 9:31 AM, Kirk Lund wrote:
> Just in case you don't believe
+1 I've had to reorder the list a few times myself to correct the ordering
On Mon, Nov 12, 2018 at 5:28 PM, Galen O'Sullivan
wrote:
> Hi all,
>
> I wrote a PR (GEODE-5800) recently to remove redundant cases from
> DataSerializer.readObject etc. calls. This changed the bytecode size (but
> not
Just in case you don't believe me and want to double-check my answer:
My PR which says there are NO CONFLICTS:
https://github.com/apache/geode/pull/2778
Thanks,
Kirk
On Tue, Nov 13, 2018 at 9:31 AM, Kirk Lund wrote:
> Yes github says it merges cleanly (still does in fact):
>
> This b
org/thread/apwupkbkg3qipygo
> >
> > On Mon, Nov 12, 2018 at 4:18 PM, Owen Nichols
> wrote:
> >
> > > This error usually means it didn’t merge cleanly, not that concourse is
> > > “down"
> > >
> > > > On Nov 12, 2018, at
I'm trying to get my PR to run tests, but the latest concourse jobs are
failing with:
rsync_code_down-OpenJDK8
missing inputs: geode, instance-data
archive-results-OpenJDK8
missing inputs: concourse-metadata-resource, geode, geode-results
delete_instance-OpenJDK8
missing inputs: geode,
GEODE-5943: EvictionDUnitTest failed in jdk11
https://issues.apache.org/jira/browse/GEODE-5943
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/101
org.apache.geode.internal.cache.eviction.EvictionDUnitTest >
Well, we could run it periodically such as weekly rather than as part of
the main pipeline or precheckin.
On Fri, Nov 9, 2018 at 2:32 PM, Aditya Anchuri wrote:
> +1, although I do wonder about the overhead of making PRs increasing more
> than it already feels like to me as a new contributor (as
FindBugs is another one that could potentially help some. I get tired of
adding reviews that say "Please change this member variable to be private"
-- tools like LGTM and FindBugs can help guide us to better code and
prevent us from losing ground in something like the improvements you all
have
ing up properly after your tests. It also make what you are
> really trying to do in the test stand out more in the test code.
>
> On Fri, Nov 9, 2018 at 1:37 PM Kirk Lund wrote:
>
> > We need to pull out the DUnit Blackboard from DistributedTestCase and
> > repackage it as a
+1 I added my approval to your PRs. I don't know if the yml is correct or
not, but I support the overall goal.
On Thu, Nov 8, 2018 at 1:19 PM, Owen Nichols wrote:
> Sounds like the overwhelming consensus is to keep Java11 gating, add
> Java11 to PR, and defer non-gating tests.
>
> I have
thods affects many tests.
>
>
> On 11/9/18 11:31 AM, Kirk Lund wrote:
>
>> *I would like to encourage all Geode developers to start writing tests
>> directly against the Geode User APIs* even in DistributedTests. I'm no
>> longer using *CacheRule, ClientCacheRule, ServerSta
+1
On Fri, Nov 9, 2018 at 12:58 PM, Robert Houghton
wrote:
> +1
>
> On Fri, Nov 9, 2018, 12:55 Dan Smith
> > Hi all,
> >
> > Kirks emails reminded me - I think we are at the point now with our PR
> > checks where we should not be merging anything to develop that doesn't
> pass
> > all of the
:36 AM, Kirk Lund wrote:
> Thanks! I'm waiting for Build #99 to finish (hopefully green) and I'll
> send out one more update on this.
>
> On Fri, Nov 9, 2018 at 11:33 AM, Jinmei Liao wrote:
>
>> It is a flaky test, I have a PR that would give more detailed error
>&g
e/geode/pull/2808
>
> On Fri, Nov 9, 2018 at 10:47 AM Kirk Lund wrote:
>
> > This test has failed in DistributedTestOpenJDK8 #98. Nobody can merge to
> > DEVELOP until I announce that the RED ALARM is turned off and the Build
> is
> > fixed. There is an excepti
*I would like to encourage all Geode developers to start writing tests
directly against the Geode User APIs* even in DistributedTests. I'm no
longer using *CacheRule, ClientCacheRule, ServerStarterRule,
LocatorStarterRule, or ClusterStarterRule* and I'm against encouraging
their use any longer.
Build checkPom has been restored to GREEN.
On Fri, Nov 9, 2018 at 10:21 AM, Kirk Lund wrote:
> PS: The fix for checkPom an be committed to DEVELOP.
>
>
> On Fri, Nov 9, 2018 at 10:14 AM, Kirk Lund wrote:
>
>> Now that I have your attention ;) I'd like to make broken bu
PS: The fix for checkPom an be committed to DEVELOP.
On Fri, Nov 9, 2018 at 10:14 AM, Kirk Lund wrote:
> Now that I have your attention ;) I'd like to make broken builds a BIGGER
> DEAL! Nobody can merge to DEVELOP until I announce that the RED ALARM is
> turned off and the Build
Now that I have your attention ;) I'd like to make broken builds a BIGGER
DEAL! Nobody can merge to DEVELOP until I announce that the RED ALARM is
turned off and the Build is fixed.
Thank you,
Kirk
GEODE-6024: Develop build fails due to checkPom (unknown dependency added)
-1 Personally, I prefer to being able to see and manipulate ALL code. I
hate autogenerated code, and I don't mind boilerplate code. When I see a
class that has too many getters, then I see that as a sign that we need to
do some refactoring and correct the design of that class. Using Lombok
would
Does anyone have a link to a wiki page describing our use of "Fix
Version/s" on Geode Jira tickets?
My understanding is that when we file a ticket we leave it blank. Then when
we commit a fix to develop we change the Jira ticket to "Resolved" and fill
in the "Fix Version/s" with the upcoming
I'm logged into https://concourse.apachegeode-ci.info/ but I can't see
anything but the public pipeline. Can I please get permissions needed to
see and create a personal pipeline?
Thanks,
Kirk
I think we should try really hard to avoid using PowerMock. If you have
some code that you need to use PowerMock to make it testable, please
consider refactoring the code to a) avoid statics, b) pass all dependencies
in via the constructor.
The following was spit out by one of my unit test runs.
gt;>
>> I like this but it might be even better if ServerLauncher gave access to
>>> the CacheServer it launched and CacheServer gave access to its cache.
>>> The
>>> Locator interface, as well, could have a getCache() method and deprecate
>>> the getD
The easiest way to use IgnoredException is as an AutoCloseable in a
try-with-resource block and by specifying the Exception class:
import static
org.apache.geode.test.dunit.IgnoredException.addIgnoredException;
import org.apache.geode.cache.client.ServerOperationException;
@Test
public void
/pull/2768
Thanks,
Kirk
On Fri, Nov 2, 2018 at 10:56 AM, Kirk Lund wrote:
> That's unfortunate, half of the precheckin jobs for my PR started
> correctly and half of them failed with:
>
> /usr/lib/ruby/gems/2.4.0/gems/octokit-4.8.0/lib/octokit/response/raise_error.rb:16:in
> `on_compl
nly restart
> the latest PR, which may not be yours. To restart a PR check you push and
> empty commit to your branch.
>
> -Jake
>
>
> > On Nov 2, 2018, at 10:38 AM, Kirk Lund wrote:
> >
> > I want to be able to restart my precheckin jobs. Specifically, I'd like
I want to be able to restart my precheckin jobs. Specifically, I'd like to
restart the UnitTest job on my latest PR precheckin:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/UnitTest/builds/347
It seems to have hit a snag that's unrelated to my PR:
> those tests surrounding the one you linked.
>
> On Wed, Oct 31, 2018 at 12:36 PM, Kirk Lund wrote:
>
> > Just in case, others hit this: The one I was asking about failed with
> > "missing inputs: geode, instance-data" which Dan said means that
> Concourse
> >
LocatorLauncher provides an API which can be used in-process to create a
Locator. There is no public API on that class to get a reference to the
Locator or its Cache.
Similarly, ServerLauncher provides an API which can be used in-process to
create a Server, but there is no public API in that
oks. We should probably
> investigate if there is a way to add the hooks in the case of a merge
> conflict, to avoid the potential for developer confusion.
>
> On Tue, Oct 30, 2018 at 4:16 PM, Kirk Lund wrote:
>
> > Nevermind. I pushed again and it seems to have triggere
Nevermind. I pushed again and it seems to have triggered this time.
On Tue, Oct 30, 2018 at 2:51 PM, Kirk Lund wrote:
> I have a PR that I updated a while ago, but it's not automatically firing
> a precheckin.
>
> What's the expected behavior? Is it supposed to automatic
I have a PR that I updated a while ago, but it's not automatically firing a
precheckin.
What's the expected behavior? Is it supposed to automatically trigger a
precheckin if I push more changes?
Here's my PR: https://github.com/apache/geode/pull/2730
PS: the PR isn't ready to actually merge,
I noticed the following warning log statement while digging through the
ouput in a dunit.
It's caused by a bug in
org.apache.geode.management.internal.beans.ManagementListener$handleEvent
-- the readLock is acquired under a condition (event !=
ResourceEvent.SYSTEM_ALERT) but released without
I usually create a private static inner class and keep it as small as
possible at the end of the test class that uses it. Some of these these
such as MyCacheListener can be replaced by spy(CacheListener.class) and I
always try to convert these where possible.
If it's a simple class that only
It's possible that I ran build/precheckin with a different version of Java.
Is it possible that would change the bits that
AnalyzeSerializablesJUnitTestBase is looking at and cause an unexpected
failure?
On Thu, Oct 4, 2018 at 1:24 PM, Kirk Lund wrote:
> But I didn't add or touch the cl
; the output directory, so you might check that too.
>
> Output of this test should include a Fatal level log message that tells
> you what the rejected class was:
>
> Serialization filter is rejecting class ClassName
>
>
>
> On 10/3/18 1:10 PM, Kirk Lund wrote:
>
>
Sai and I noticed that the Acceptance style dunit tests that are starting
up locators in vm0 are generating a bunch of log statements about "Unknown
DataSerializableFixedID: 2145" and this looks wrong in several ways. I
reviewed it with Darrel and neither of us are familiar with TcpServer or
with
> If I am using a custom object in a test or something I add it
> as SERIALIZABLE_OBJECT_FILTER property.
>
> Is your branch hosted in github?
>
> Regards
> Nabarun
>
>
> On Wed, Oct 3, 2018 at 10:24 AM Kirk Lund wrote:
>
> > I have a failure on my branch tha
I'm also seeing lots of failure in RedisDistDUnitTest. Is this a known
flaky test?
org.apache.geode.redis.RedisDistDUnitTest > testConcListOps FAILED
java.lang.AssertionError: Suspicious strings were written to the log
during this run.
Fix the strings or use
I have a failure on my branch that doesn't seem related to my changes.
Anyone know what's causing this failure?
Thanks!
java.lang.AssertionError: I was unable to deserialize
org.apache.geode.cache.AttributesFactory$RegionAttributesImpl
at
Spring Data Geode test EnableContinuousQueriesWithClu
sterConfigurationIntegrationTests started failing so I'm assuming someone
changed something in CQ or cluster config?
wrote:
> I am wrong, it is probably eclipse.
>
> On Fri, Sep 28, 2018, 11:12 AM Kirk Lund wrote:
>
> > My intellij appears to be configured to use "out" so I'm not sure how it
> > created "bin" dirs but it's possible. I added "*/bin/*" to the ex
That’s weird—I would expect any generated files to go into build/.
> >> Anyone know why stuff is landing in bin?
> >>
> >> Anthony
> >>
> >>
> >> > On Sep 27, 2018, at 7:25 PM, Kirk Lund wrote:
> >> >
> >> > Command-lin
l - =OFF,
0. null - =TRACE,
0. null - =WARN]>
at
org.apache.geode.management.internal.cli.GfshParserAutoCompletionTest.testCompleteLogLevel(GfshParserAutoCompletionTest.java:258)
On Thu, Sep 27, 2018 at 4:20 PM, Kirk Lund wrote:
> Does anyone know GfshParserRule well enough that w
Command-line build seems to create these bin directories under each module
which is fine.
But now Rat is failing because of the generated files under these bin
directories. This in turn causes my local command-line build to fail.
Does anyone know how to make this problem go away without using
Does anyone know GfshParserRule well enough that we could make the test
failures provide some useful info?
If you could give me some pointers on where/what to improve I'm happy to do
the footwork. Or if you prefer to do that's fine as well.
For example, I have a PR with
when you execute a test
> task:
> >
> > -PtestCategory=org.apache.geode.test.junit.categories.GfshTest
> >
> > Anthony
> >
> >
> > > On Sep 25, 2018, at 2:21 PM, Kirk Lund wrote:
> > >
> > > I've made sure that all logging related tests
I've made sure that all logging related tests have the LoggingTest category
but now I can no longer find any mechanism in our gradle files to execute
all tests of a specific component category. Is there a way to run all tests
with this category or did this get deleted?
Great job, John! The blog write-up is perfect, too.
On Fri, Sep 21, 2018 at 5:54 PM, John Blum wrote:
> It is my pleasure to announce [1] the release of *Spring Boot for Apache
> Geode* 1.0.0.M3.
>
> This release builds on the latest GA version of *Spring Boot*,
> 2.0.5.RELEASE, and adds
uts are unnecessary.
>
> —
> Dale Emery
> dem...@pivotal.io
>
> > On Sep 21, 2018, at 10:34 AM, Kirk Lund wrote:
> >
> > Most of these logWriter or logger usages are in larger end-to-end tests
> > that were written before we could using IDE debuggers o
We killed the Gradle Daemon and pushed a fix for the geode-junit:checkPom
error. Develop should be building cleanly again.
On Fri, Sep 21, 2018 at 11:42 AM, Kirk Lund wrote:
> Develop is broken due to geode-junit:checkPom because we excluded a bad
> dependency.
>
> Now I'm t
Develop is broken due to geode-junit:checkPom because we excluded a bad
dependency.
Now I'm trying to run checkPom but this produces an error for (see below).
How do I run checkPom locally?
/Users/klund/dev/geode [515]$ ./gradlew
geode-junit:checkPom
Starting a Gradle Daemon, 1 incompatible
Most of these logWriter or logger usages are in larger end-to-end tests
that were written before we could using IDE debuggers on our tests. With a
debugger, I don't want to see more output from the test so I tend to delete
all such System.out.printlns or LogWriter/Logger usage.
My recommendation
Please be extra careful when adding new dependencies. Our build is setup to
allow transitive dependencies, so reviews should include looking at the
tree of transitive dependencies that a new dependency pulls into Geode.
I think it would also be a good idea to create a little extra noise on the
; On Fri, Sep 14, 2018 at 5:17 PM Jacob Barrett wrote:
>
> > The concatenation is missing a : in front of the test-jar.
> >
> > > On Sep 14, 2018, at 4:10 PM, Kirk Lund wrote:
> > >
> > > Log4j2 publishes a test jar for log4j-core. The jar includes useful
&
I reviewed your changes and added approval. Thanks Juan!
On Tue, Sep 18, 2018 at 12:46 AM, Juan José Ramos wrote:
> Hello Jinmei and Dan,
>
> Thanks both for the reply!!.
> Regarding pull 2250, I think the changes requested by Galen are outdated
> now, but I'll ping him directly in the *pull
Log4j2 publishes a test jar for log4j-core. The jar includes useful things
like LoggerContextRule.
This blog post shows how to add the dependency for testing to maven:
https://relentlesscoding.com/2018/04/21/unit-test-log4j2-log-output/
This results look like this:
org.apache.logging.log4j
Correction! The wiki page does have a link to
*https://chris.beams.io/posts/git-commit/
<https://chris.beams.io/posts/git-commit/> *at the bottom of the page:
How to write a Git commit message <https://chris.beams.io/posts/git-commit/>
On Fri, Sep 14, 2018 at 3:05 PM, Kirk
*The commit message should follow imperative style.* The wiki page seems to
be missing this even though we agreed to it several times on the dev-list
over the last 3 years. I'll add this to the wiki page.
You can then say *"If I apply this commit, then it will..."* for any of the
git commits. For
Geode currently manipulates Log4J2 at runtime to add/remove Appenders based
on the Cache lifecycle. While working on GEODE-5637, Sai and I tried to add
ListAppender [1] from log4j-core test-jar programmatically at runtime using
the same code that Geode uses for AlertAppender, LogWriterAppender and
I don't care which location (wiki or part of the readme) but I do have
up-to-date instructions that I could update either location with. Maybe a
detailed "Setting up IntelliJ" section on BUILDING.md? Just let me know if
you'd like my version.
On Tue, Sep 11, 2018 at 3:36 PM, Jianxia Chen wrote:
de around the
> > lambdas, extracting the duplication into methods would reduce the number
> of
> > lambdas.
> >
> > > On Sep 10, 2018, at 11:03 AM, Kirk Lund wrote:
> > >
> > > Alright I'm more up-to-date on this thread. Some things to consider:
>
clause from the Geode log statements.
If Log4J2 changed their implementation of debug and trace to be comparable
with hitting a volatile for disabled statements then we could delete
FastLogger and every log statement guard clause.
On Mon, Sep 10, 2018 at 10:12 AM, Kirk Lund wrote:
> The reason
The reason we use these guards is that the Log4j2 implementation is more
expensive than hitting a volatile. Please don't change anything unless you
start writing lots of JMH benchmarks! The existing code went through lots
of iterations of perf testing that isn't part of Geode.
Every Log4j2 Logger
Can everyone please take a moment to check if you have any of these tickets
and then resolved them?
I'm working on fixing some flaky failures in DiskRegionJUnitTest and I plan
to overhaul the entire test. I'll probably extract multiple test classes
from it as well. I recommend avoiding this test to avoid git conflicts!
Jira ticket as been filed for this:
GEODE-5639: Replace usage of CatchException with AssertJ and remove
CatchException dependency
On Thu, Aug 23, 2018 at 4:03 PM, Kirk Lund wrote:
> I goofed on #1. We should be using* org.assertj.core.api.**Assertions*
> directly, not *AssertionsForClas
So
> the test code is in not control to handle or even catch exceptions.
>
> So for a black box test (like this one) may be a tool to assert certain
> exception is logged is the only best option?
>
> On Fri, Aug 24, 2018 at 4:02 PM Kirk Lund wrote:
>
> > Hey Sai, did you see t
I just checked and it looks like you have admin permissions. Not sure if
someone just flipped that on for you or if you were already an admin.
If there's something you can't do, let me know!
On Mon, Aug 27, 2018 at 8:05 AM, Anthony Baker wrote:
> Hi all,
>
> I am working on some housekeeping
Hey Sai, did you see this thread? It might help with your exception testing
that you asked about. DeltaPropagationFailureRegressionTest and
RegisterInterestDistributedTest (mentioned below) are both dunit tests.
On Thu, Aug 23, 2018 at 4:03 PM, Kirk Lund wrote:
> I goofed on #1. We sho
nction' will probably help.
>
> --Jens
>
> On Thu, Aug 23, 2018 at 2:27 PM Dan Smith wrote:
>
> > I think this was replaced with a gfsh command that does the same thing.
> > Unfortunately, we don't have a public java API for gfsh as far as I know.
> >
> > -Dan
>
Tests don't need to catch non-runtime exceptions and rethrow them. The
following:
Awaitility.await().atMost(60, TimeUnit.SECONDS).untilAsserted(() -> {
try {
assertEquals(size, query.findPages().size());
} catch (LuceneQueryException e) {
throw new
/false/.
>
>
>
> On 8/23/18 2:23 PM, Kirk Lund wrote:
>
>> Question about CacheServer.setNotifyBySubscription(boolean) which is
>> deprecated... The default is now TRUE. But I found a test that is setting
>> it to FALSE. What is the preferred non-depr
ate(entryEvent))
.isInstanceOf(IllegalArgumentException.class);
I'll fix JdbcWriterTest's imports. I copied the import to the email without
looking closely at it.
On Thu, Aug 23, 2018 at 4:01 PM, Kirk Lund wrote:
> We have a small number of tests
We have a small number of tests
using com.googlecode.catchexception.CatchException. This project isn't very
active and AssertJ provides better support for testing expected exceptions
and throwables. Most Geode developers are already using AssertJ for
expected exceptions.
I propose we update the
Question about CacheServer.setNotifyBySubscription(boolean) which is
deprecated... The default is now TRUE. But I found a test that is setting
it to FALSE. What is the preferred non-deprecated API for setting this to
FALSE?
* @deprecated as of 6.0.1. This method is no longer in use, by default
I'm seeing this in quite a few newer tests:
1:CacheServer server = cacheRule.getCache().addCacheServer();
2:server.setPort(0);
3:*server.setNotifyBySubscription(true);*
4:server.start();
Just want to point out that line 3 gets flagged as deprecated and is no
longer needed.
There are a few distributed tests that are using deprecated Admin API to
getMissingPersistentMembers.
Does anyone know if there's a non-deprecated way to do this?
vm2.invoke(() -> {
DistributedSystemConfig config = defineDistributedSystem(getSystem(),
"");
AdminDistributedSystem
Lund wrote:
> Looks like it's a feature: https://github.com/google/google-java-format/
> issues/62
>
> Is it too late to down-vote our use of google-java-format?
>
> On Tue, Aug 21, 2018 at 3:43 PM, Kirk Lund wrote:
>
>> I suppose I was using that older format o
still think it's ridiculous that we have spotless configured to
disallow a double-space after sentence terminator.
On Tue, Aug 21, 2018 at 3:39 PM, Kirk Lund wrote:
> I know it's not a bug in spotless. I think we now have the settings a bit
> too strict.
>
> As of 2-3 weeks ago, I was ab
re, not a bug? And we should investigate the
> discrepancies between the format files in /etc, that is, the Eclipse
> file spotless uses and the IntelliJ file that is meant to emulate it.
>
> On Tue, Aug 21, 2018 at 9:48 AM, Kirk Lund wrote:
>
> > This appears to be caused by chan
t I’m willing to go with group consensus
> > on this (aka +0).
> >
> > Anthony
> >
> >
> > > On Aug 21, 2018, at 10:11 AM, Kirk Lund wrote:
> > >
> > > +1 Yes! This naming scheme matches what we already have on the Apache
> > Geode
> > >
run with defaults (including ports).
> So if they aren’t run in containers they can’t be run in parallel.
>
> Anthony
>
>
> > On Aug 21, 2018, at 11:15 AM, Kirk Lund wrote:
> >
> > Oops... I mean "orphaned processes"
> >
> > On Tue, Aug 21, 2018 at 1
s. But I’m willing to go with group
> consensus on this (aka +0).
> >
> > Anthony
> >
> >
> >> On Aug 21, 2018, at 10:11 AM, Kirk Lund wrote:
> >>
> >> +1 Yes! This naming scheme matches what we already have on the Apache
> Geode
> >>
Oops... I mean "orphaned processes"
On Tue, Aug 21, 2018 at 11:13 AM, Kirk Lund wrote:
> So, we need to disable running them in parallel and improve the tearDown
> to make sure these tests don't leave an orphaned tests behind.
>
> On Tue, Aug 21, 2018 at 11:
A good rule of thumb is to never test with default ports unless the test
runs in a container. Otherwise, running tests in parallel will fail
miserably.
On Tue, Aug 21, 2018 at 10:44 AM, Kirk Lund wrote:
> GEODE-5590 would seem to imply that GfshRule does not have an adequate
> safe
on
> > develop. I believe these metrics are from develop CI test runs.
> >
> > On Tue, Aug 21, 2018 at 10:15 AM Kirk Lund wrote:
> >
> >> Those metrics show AcceptanceTests consistently GREEN. Do these metrics
> >> include test failures from pull request prech
reporting these failures, so probably these are due to recent changes on
> develop. I believe these metrics are from develop CI test runs.
>
> On Tue, Aug 21, 2018 at 10:15 AM Kirk Lund wrote:
>
> > Those metrics show AcceptanceTests consistently GREEN. Do these metrics
> > includ
gt; https://concourse.apachegeode-ci.info/teams/main/pipelines/metrics/jobs/
> GeodeAcceptanceTestMetrics/builds/20
>
> On Tue, Aug 21, 2018 at 10:07 AM Kirk Lund wrote:
>
> > Are PutCommandWithJsonTest and DeployWithLargeJarTest known to be flaky?
> >
> > My latest pull
+1 Yes! This naming scheme matches what we already have on the Apache Geode
Wiki [1] for naming tests.
Side note: Looks like we need to update the pages on the Wiki to match our
recent changes involving JUnit categories.
[1] https://cwiki.apache.org/confluence/display/GEODE/Writing+tests
On
This appears to be caused by changes made to the build around August 10?
On Tue, Aug 21, 2018 at 9:38 AM, Kirk Lund wrote:
> Why is spotless now complaining about correct English? By correct English,
> I mean having 2 spaces between sentences in javadoc or comments (in this
>
Why is spotless now complaining about correct English? By correct English,
I mean having 2 spaces between sentences in javadoc or comments (in this
case it's the Apache license header):
-·*·the·License.··You·may·obtain·a·copy·of·the·License·at
Use AssertJ.
If you find test code that's catching Exception and invoking fail with or
without the caught Exception, convert that to something better. Using fail
is itself an epic fail.
1) Tests should never catch unexpected Exceptions
Remove "catch (Exception" and let the test methods throw
ta-
> geode/blob/master/spring-geode/src/test/java/org/
> springframework/geode/config/annotation/DurableClientConfigurationInte
> grationTests.java#L121-L124
> [3] https://github.com/spring-projects/spring-boot-data-geode
>
>
>
> On Fri, Aug 10, 2018 at 9:37 AM, Kirk Lund wrote
401 - 500 of 1832 matches
Mail list logo
