Re: [DISCUSS] Benchmarks module package structure

We'll probably end up writing benchmarks for classes or methods that are package-private, so that would be one reason to not create a special benchmarks package. On Mon, Jan 8, 2018 at 1:40 PM, Dan Smith wrote: > I think this module was specifically added for running JMH

Re: Handling files and user.dir in tests

-directory" which a test could specify. That property value would have to be pushed down to every class that creates a new File. Pull request: https://github.com/apache/geode/pull/1243 On Fri, Jan 5, 2018 at 3:32 PM, Kirk Lund <kl...@apache.org> wrote: > Any calls such as: > >

Handling files and user.dir in tests

Any calls such as: File file = new File("myfile"); ...results in creating a file in the current working directory of IntelliJ or Gradle when executing the test. I previously made a change to Gfsh so that tests can pass in a parent directory which will be used instead. This allowed me to

Re: Using partition resolver via gfsh command vs XML config

According to the context of where that message is used, the specified className is blank. private static Class forName(String className, String neededFor) { if (StringUtils.isBlank(className)) { throw new IllegalArgumentException(CliStrings

Re: PRs should always include tests

..@apache.org> wrote: > > > +1 > > > > > > > > On 12/29/17 12:05, Kirk Lund wrote: > > > >> I think we all need to be very consistent in requiring tests with all > PRs. > >> This goes for committer as well as non-committer contributions. > >&

PRs should always include tests

I think we all need to be very consistent in requiring tests with all PRs. This goes for committer as well as non-committer contributions. A test would both confirm the existence of the bug in the first place and then confirm the fix. Without such a test, any developer could come along later,

Apache Geode repos

Do we have any other repos besides the following? geode-examples.git geode.git geode-native.git geode-site.git The gitbox jira comment changes should now be completed on all of the above. Thanks, Kirk

Re: Geode Jira/GitHub Integration configuration changes

I'm keeping INFRA-15727 to confirm that the changes have also been made to the geode-native and geode-examples repos. On Wed, Dec 27, 2017 at 3:41 PM, Kirk Lund <kl...@apache.org> wrote: > Karen just submitted a PR (#1208). It posted a nice short comment about > the PR to GEODE-

Re: Geode Jira/GitHub Integration configuration changes

, Dave Barnes <dbar...@pivotal.io> wrote: > I must have just missed the cutoff - my PR (#1207), which I created at > 2:48, generated diffs in the JIRA. > > On Wed, Dec 27, 2017 at 3:06 PM, Kirk Lund <kl...@apache.org> wrote: > > > INFRA has made the change. Does anyo

Re: Geode Jira/GitHub Integration configuration changes

INFRA has made the change. Does anyone have a PR ready to submit so I can confirm the behavior on a Jira ticket? On Wed, Dec 27, 2017 at 12:57 PM, Kirk Lund <kl...@apache.org> wrote: > I filed a request with INFRA to exclude pull request diffs from Jira > comments. > > https:/

Re: Geode Jira/GitHub Integration configuration changes

suming we have consensus to get rid of the diffs > > (huge > > > >> +1 > > > >> from me:) > > > >> > > > >> Also, please don't cross post with private@geode. The private list > > > should > > > >> *only* be used fo

Re: [DISCUSS]: Handling of SDTOUT/STDERR and Signals

dify *setenv.txt* and execute *reproduce.sh*) showing that both > approaches fail, the output from *System.out.println()* and > *System.err.println()* is lost, along with the thread dump generated by *kill > -3 PID*. > Hope this is clear now, hope you can answer the questions from my previous &

Re: [DISCUSS]: Handling of SDTOUT/STDERR and Signals

By default Geode redirects stdout and stderr to the value of the log-file property when the Cache starts. If log-file is set to "" then it won't redirect them. When we changed GemFire to use Log4J2 internally, we tried to leave stdout and stderr alone such that the LogWriterAppender would append

Geode Jira/GitHub Integration configuration changes

Since we switched to GitBox for Geode, all Pull Requests are resulting in huge diffs being posted to the comments on Geode Jira tickets. Some of these are resulting in hangs trying to open certain Jira tickets. I'd like to determine what our options are for changing how this is configured. I

Re: Debugging intermittent dunit failures

mberg <prhomb...@pivotal.io> > wrote: > > > Are the AcceptanceTests currently set to fork after every one? It might > be > > apples to oranges, but we could try to look at the cost difference there. > > > > On Thu, Dec 14, 2017 at 4:24 PM, Kirk Lund <kl...@apache.org>

Re: Debugging intermittent dunit failures

gt; On Thu, Dec 14, 2017 at 2:02 PM, Kirk Lund <kl...@apache.org> wrote: > > > Someone needs to try it out. If there are any build-engineer types > working > > on geode, then my suggestion is for them to try this change and report > the > > timing difference. &g

Re: Debugging intermittent dunit failures

ing every time would impact how long tests > run? > > On Tue, Dec 12, 2017 at 1:39 PM, Kirk Lund <kl...@apache.org> wrote: > > > We should just change to fork every 1 instead of 30. Wasting time trying > to > > debug statics is well... it's a waste of time

Re: Debugging intermittent dunit failures

. See JUnit4DistributedTestCase.tearDownVM. > > > > Are the new junit rules also cleaning things up? > > > > -Dan > > > > On Mon, Dec 11, 2017 at 4:16 PM, Kirk Lund <kl...@apache.org> wrote: > > > > > Is there a reason we can't change DistributedTe

Re: Debugging intermittent dunit failures

Is there a reason we can't change DistributedTestCase and subclasses to use TemporaryFolder for all artifacts? We could also disconnectAllFromDS in @AfterClass (or even @After) to get things a bit more separate between dunit test classes. Running dunit tests in parallel is much more important

Re: [DISCUSS] Proposal to Deprecate Hash Index

+1 On Tue, Dec 5, 2017 at 4:34 PM, Dan Smith wrote: > +1 > > -Dan > > On Tue, Dec 5, 2017 at 4:28 PM, Jason Huynh wrote: > > > This is a proposal to deprecate existing Hash Index and deprecate the > > create hash index apis. > > > > > > Currently the Hash

Re: CommandOverHttpDUnitTest seems to be causing a bunch of tests to needlessly be run

CommandOverHttpDUnitTest reruns those tests with the system property CliCommandTestBase.USE_HTTP_SYSTEM_PROPERTY enabled. Using a suite results in the results of these tests being overwritten when the tests rerun using HTTP. An approach that would keep both test results would be to subclass each

Re: [DISCUSS] changes to registerInterest API

go with the new > > API. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Mike Stol

Rename DM and DistributionManager

I'd like to do some renaming to use better class names including: GEODE-3965: Rename DistributionManager to ClusterDistributionManager and DM to DistributionManager The results would be: * interface = DistributionManager * impl for cluster = ClusterDistributionManager * impl for loner =

Re: [DISCUSS] Maximum duration that a class may contain a @Flaky

There's a JUnit annotation in geode-junit called @IgnoreUntil which you provide a deadline for. After the deadline, it starts running again. Unfortunately the test is not run while it is ignored whereas any test with the FlakyTest category is still run. It's up to you when to remove FlakyTest

Re: ':geode-client-protocol' could not be found in project ':geode-assembly'

Precheckin last night failed to compile. On Fri, Nov 3, 2017 at 9:22 AM, Galen O'Sullivan <gosulli...@pivotal.io> wrote: > It may be that we missed one of the places where a module gets linked in. > Where did you see this error? > > On Fri, Nov 3, 2017 at 9:20 AM, Kirk Lund

':geode-client-protocol' could not be found in project ':geode-assembly'

Anyone know why the build is failing in geode-assembly? * What went wrong: A problem occurred evaluating project ':geode-assembly'. > Project with path ':geode-client-protocol' could not be found in project ':geode-assembly'.

Re: Need "edit" access to update Network Best Practices page

Hi Tod, What's your wiki account name? On Wed, Nov 1, 2017 at 11:39 PM, Tod Morrison wrote: > Hello, > > I need *edit* access to https://cwiki.apache.org/confluence/display/GEODE/ > Network+Configuration+Best+Practices to update it with some current > findings. > > Let me

Re: [Discuss] CliStrings

CliStrings has nothing to do with localization. The original authors of GFSH simply stored all GFSH strings as static final constants in that class. As for LocalizedStrings, it was a non-standard way of doing localization and was abandoned by the development team years ago because it's garbage.

Re: [Discuss] CliStrings

I'm all for getting rid of CliStrings. That constant (or the raw string) belongs in CreateRegionCommand instead of in CliStrings. On Thu, Oct 19, 2017 at 3:05 PM, Jared Stewart wrote: > I wanted to kick off a discussion about the usage of CliStrings. For > those

Re: DSFIDNotFoundException: Unknown DataSerializableFixedID: -158

:32771. isDeltaGII is false [vm2] [info 2017/10/17 21:03:47.092 UTC tid=0x1b] Initialization of region PdxTypes completed On Wed, Oct 18, 2017 at 10:03 AM, Kirk Lund <kl...@apache.org> wrote: > My latest sighting of this was in > ResourceManagerDUnitTest.testRemoveDuringGetEntry

Re: DSFIDNotFoundException: Unknown DataSerializableFixedID: -158

ecure UDP test leaving something behind that's > infecting other tests. If we can identify the previously run tests that > might help. > > > > On 10/17/17 4:23 PM, Kirk Lund wrote: > >> At first I was just seeing a couple WAN tests fail with this but just now &g

DSFIDNotFoundException: Unknown DataSerializableFixedID: -158

At first I was just seeing a couple WAN tests fail with this but just now I had GIIDeltaDUnitTest fail due to this suspect string as well. Anyone know what's causing this? org.apache.geode.internal.cache.GIIDeltaDUnitTest > testSavingRVVGC FAILED java.lang.AssertionError: Suspicious strings

Re: version for JIRA tickets?

I have a couple commits from yesterday (and maybe 1 from Wed) that I still need to close the corresponding Jira ticket for. How do I determine if the commit made it into 1.3 or will instead be in 1.4? On Fri, Oct 13, 2017 at 8:35 AM, Bruce Schuchardt wrote: > That was

ClientProtocolService failures in geode-core dunit

After updating to latest develop, whenever I run a dunit test in geode-core, the dunit locator is now throwing ServiceLoadingFailureException because ClientProtocolServiceLoader can't find a ClientProtocolService provider. It doesn't result in dunit failures (unless the dunit uses the dunit

Re: CacheListener invocations in bucket secondaries

gt; > > On Mon, Oct 9, 2017 at 11:48 AM, Kirk Lund <kl...@apache.org> wrote: > > > Does anyone know what the system property is that enables CacheListener > > invocations in bucket secondaries? Or which class I should look in to > find > > it? > > > > Thanks, > > Kirk > > >

CacheListener invocations in bucket secondaries

Does anyone know what the system property is that enables CacheListener invocations in bucket secondaries? Or which class I should look in to find it? Thanks, Kirk

Re: [DISCUSS] CI improvements

+1 no thoughts other than make it so! On Fri, Oct 6, 2017 at 7:08 AM, Anthony Baker wrote: > Hi all, > > I’d like to propose the following that we switch our continuous > integration (CI) system from Jenkins [1] to Concourse [2]. I suggest > this because we continue to

Re: Looking for geode-core dunit using 5 dunit VMs

t 5, 2017 at 10:05 AM, Kirk Lund <kl...@apache.org> wrote: > I need help looking for a geode-core dunit test that is using 5 dunit VMs > instead of 4. I want to review that test and then decide what to do with > the DistributedTest framework tests that might run after it (the tests t

Looking for geode-core dunit using 5 dunit VMs

I need help looking for a geode-core dunit test that is using 5 dunit VMs instead of 4. I want to review that test and then decide what to do with the DistributedTest framework tests that might run after it (the tests that verify that dunit itself is ok). This test is doing something like this:

Re: ExportConfigCommandDUnitTest

.io> wrote: > I haven’t seen that test fail before. If you rerun the precheckin does it > still fail? > > > > On Oct 4, 2017, at 4:55 PM, Kirk Lund <kl...@apache.org> wrote: > > > > ExportConfigCommandDUnitTest failed in my latest precheckin but my > changes &g

ExportConfigCommandDUnitTest

ExportConfigCommandDUnitTest failed in my latest precheckin but my changes don't involve the code this test is testing. Did someone commit break this test or is it failing intermittently? Thanks, Kirk :geode-web:distributedTest

Please don't commit broken javadocs

I'm seeing newly broken javadocs being committed. :geode-core:javadoc /Users/klund/dev/gemfire/open/geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/MessageExecutionContext.java:91: warning - @return tag has no arguments. 1 warning

Minor dunit cleanup being merged to develop

GEODE-3638: cleanup minor issues found while prepping dunit talk My precheckin for PR #802 (GEODE-3638) is GREEN except for *org.apache.geode.internal.cache.tier.sockets.ClientHealthMonitorJUnitTest* which is still failing. #802 introduces DistributedTestRule and fixes DistributedDisconnectRule

DiskSpaceLimitIntegrationTest moved to FlakyTest

I just moved DiskSpaceLimitIntegrationTest because GEODE-3205 continues to intermittently fail. I've already done a lot work to try and make the test pass consistently but it's going to require a lot more tuning to make sure the files are just the right size so that the StatSampler deletes them

CacheConnectionTimeoutJUnitTest and ClientHealthMonitorJUnitTest

These two tests seem to be passing/failing about 50/50% of the time. I recommend marking these as FlakyTest while the authors work on making them pass 100% :geode-protobuf:integrationTest org.apache.geode.protocol.acceptance.CacheConnectionTimeoutJUnitTest >

Re: Return types form methods on Cache

I would vote +1 for a more attractive, professional and user-friendly API. I'm not sure if there's a perf or memory-usage reason for using "std::shared_ptr" to types instead of returning values, but the end result does not look like a professional API to me. I would favor a more user-friendly

Re: How gitbox works

o accept the invite and get the > third box green. I didn't seem to get an email invite either. > > - Jared > > On Sep 18, 2017 12:51 PM, "Kirk Lund" <kl...@apache.org> wrote: > > If I navigate to https://github.com/apache, I see the following at the top > with

Re: How gitbox works

Third box on https://gitbox.apache.org/setup/ still isn't GREEN. On Mon, Sep 18, 2017 at 12:51 PM, Kirk Lund <kl...@apache.org> wrote: > If I navigate to https://github.com/apache, I see the following at the > top with a button to "View invitation" and accept: > >

Re: How gitbox works

I need to accept?! Apache never sent me any email. I even tried removing and re-adding my github account to my Apache Profile. This apache-gitbox integration really isn't ready for prime-time usage is it. Thanks, Kirk On Mon, Sep 18, 2017 at 12:43 PM, Kirk Lund <kl...@apache.org> wrote: >

INFRA Jira URL

Does anyone know the URL for Apache INFRA Jira? Thanks, Kirk

Re: How gitbox works

ntact to restore it? Thanks, Kirk On Mon, Sep 18, 2017 at 10:05 AM, Kirk Lund <kl...@pivotal.io> wrote: > Apparently I no longer have commit access. Anyone know who/how I get > access restored? > > Thanks, > Kirk > > On Mon, Sep 18, 2017 at 9:49 AM, Jacob Barrett <jba

Re: How gitbox works

s the source of authority for our Git repo. Everything is > done on GitHub using the GitHub processes. > > Anyone with write access to GitHub can merge a PR. The PR can be merged > from the PR GitHub website. > > -Jake > > > > On Sep 18, 2017, at 9:43 AM, Kirk Lund <k

Re: Request: Build flag to skip download of previous Geode versions

I filed GEODE-3639: "Request: build flag to skip download of previous Geode versions" for this request. Thanks, Kirk On Mon, Sep 18, 2017 at 9:40 AM, Kirk Lund <kl...@apache.org> wrote: > Turns out the 13% has nothing to do with the download, but I still think a > build f

How gitbox works

I've searched and not found a good summary on how gitbox works. Anyone know of a good resource? The kinds of questions I have are: if other devs approve my PR, do I still need to find another dev to commit for me or can I commit my own PR if has been approved? Thanks, Kirk

Re: Request: Build flag to skip download of previous Geode versions

Turns out the 13% has nothing to do with the download, but I still think a build flag to skip this would be a good idea. On Mon, Sep 18, 2017 at 9:38 AM, Kirk Lund <kl...@apache.org> wrote: > So my build has been stuck on our favorite download for the last 10 > minutes and is o

Request: Build flag to skip download of previous Geode versions

So my build has been stuck on our favorite download for the last 10 minutes and is only up to 13% which tells me it could take 20+ minutes this morning... Download https://www.apache.org/dyn/closer.cgi?action=download=geode/1.2.0/apache-geode-1.2.0.tar.gz <=> 13% EXECUTING >

Re: [DISCUSS] Clean build takes 10minutes to complete now

The actual tests marked with UnitTest category are actually pretty good. They all run in just over one minute and almost all of them use Mockito to isolate one class. I remember seeing one newer Lucene UnitTest that touches File System which should be recategorized as IntegrationTest. If we could

Re: RestServersJUnitTest flickering tests

or skip" route over marking a test flaky, but that > will require some diligence on our part to make sure these tests do end up > eventually running. > > Pull request #771: https://github.com/apache/geode/pull/771 > > On Thu, Sep 14, 2017 at 8:51 AM, Kirk Lund <kl...@apache.org> wrote: >

Re: [DISCUSS] GEODE-3617 Replace gemfire prefix with geode

That's a bigger change and I'm not sure how you would handle backwards compatibility for users using gemfire.properties. On Thu, Sep 14, 2017 at 9:15 AM, Jacob Barrett wrote: > Or better yet, we stop using properties files already. > > On Thu, Sep 14, 2017 at 8:55 AM Dave

Re: [DISCUSS] GEODE-3617 Replace gemfire prefix with geode

Whoever takes this work on will need to spend time figuring out a way to make it pluggable and support multiple prefixes possibly with pluggable order of preference. For example, we would need to support looking for geode.properties and gemfire.properties or it would break backwards compatibility

RestServersJUnitTest flickering tests

These tests have been failing intermittently in the integrationTest target for over a week. I'm going to add the category FlakyTest to these tests. See GEODE-3426. org.apache.geode.rest.internal.web.RestServersJUnitTest > testGet FAILED org.junit.ComparisonFailure: expected:<[200]> but

Flaky failures in Geode Nightly Build

We need to get more serious about getting the Geode Nightly Build back to consistent GREEN. I want to mark these flickering tests as FlakyTest. Please let me know if you have a problem with me doing so: 1) Jetty9CachingClientServerTest 2) ExportLogsStatsOverHttpDUnitTest If you do have a

Re: How to setup 2-phase auth for Github

bar...@pivotal.io> wrote: > It's kind of buried under the "TOTP Mobile App" heading. You connect Google > Authenticator to Github when you shoot a photo of the code square. > > On Tue, Sep 12, 2017 at 10:58 AM, Kirk Lund <kl...@apache.org> wrote: > > > I'm trying to

How to setup 2-phase auth for Github

I'm trying to get setup for gitbox, but a couple details are not panning out correctly for me. Darrel is using Google Authenticator on iphone for 2-phase auth of Github. However, the URL that gives directions for setting up 2-phase auth of Github does NOT have a section for setting up Google

Re: [Discuss] Building objects with the Factory pattern or the Builder pattern. Adding the fluent model?

I don't think we currently have any design directions or architectural rules for Geode documented yet other than for GFSH. As we refactor code, we really should be following some sort of overall design guidelines. +1 for documenting (on the wiki) and promoting fluent style APIs in our design

Re: Review Request 61701: GEODE-3277: Fix error path constructors of Launcher inner State classess

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/61701/#review183875 --- Ship it! Ship It! - Kirk Lund On Aug. 24, 2017, 10:02 p.m

Re: Review Request 61860: GEODE-3510: GfshRule displays output from StdError

eam so they become interleaved chronologically. The downside is you can't differentiate between the two. But there's probably some other way to synchronize the two chronologically using a stream tee or union. - Kirk Lund On Aug. 23, 2017, 8:18 p.m., Jared Stewart

Re: Nightly build failures caused by attempted use of default ports

he tests to be run in similar environment. > > > > > >>> 2) not test default ports? > > > If the product supports default port; we need to have test for > > that...Most > > > of the early product evaluation is done with default port... > > > > >

Visibility of Skipped tests in Jenkins

In local instances of Jenkins, I can see a list of "Skipped" tests -- these are JUnit tests which were skipped because they are marked with @Ignore or because they have an org.junit.Assume check that wasn't satisfied (example: Assume.assumeTrue(isWindows())). I can't figure out where that view is

Re: [DISCUSS] Updating Spotless

I'm for making our spotless better match our style guide, and it's easy enough to update branches with this. On Wed, Aug 23, 2017 at 4:31 PM, Patrick Rhomberg wrote: > [tl;dr:] > - We are inconsistent with our own established style rules. > - We should become not that. > -

Nightly build failures caused by attempted use of default ports

The following nightly build failures are tests that are testing default ports which are failing because the port is not available. Should we: 1) use Docker for AcceptanceTest and IntegrationTest targets? 2) not test default ports? 3) use a hacky System property to force Geode to think that

Re: Gradle Docker Plugin Fails After Upgrading Gradle To 3.5.1

+1 to upgrading both On Wed, Aug 23, 2017 at 10:49 AM, Mark Bretl wrote: > Hi Everyone, > > In the last nightly builds, the builds are not running the distributed > tests due to the Docker plugin not being compatible with Gradle 3.5.1. I > didn't notice this in my testing

Re: [Discuss] FunctionStats over the JMX [GEODE-3462]

at 10:06 AM, Kirk Lund <kl...@apache.org> wrote: > Hi Dinesh, > > Check out this project by Charlie Black: https://github.com/ > charliemblack/geode-exposing-metrics-via-JMX > > We currently have no plans to introduce out-of-the box Geode MXBeans for > every Function or for

Re: Gitbox enables the full GitHub workflow

+1 to move all our repos to gitbox On Tue, Aug 22, 2017 at 11:08 AM, Jacob Barrett wrote: > +1 > > Sent from my iPhone > > > On Aug 22, 2017, at 10:49 AM, Jared Stewart wrote: > > > > +1 for moving the other repos to Gitbox > > > > On Aug 22, 2017

Re: [Discuss] FunctionStats over the JMX [GEODE-3462]

Hi Dinesh, Check out this project by Charlie Black: https://github.com/charliemblack/geode-exposing-metrics-via-JMX We currently have no plans to introduce out-of-the box Geode MXBeans for every Function or for all stats. When you combine this with federating of MBeans to the JMX Manager(s), it

Re: Review Request 61757: GEODE-2859: Fix ShowDeadlockDUnitTest

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/61757/#review183400 --- Ship it! Ship It! - Kirk Lund On Aug. 18, 2017, 9:40 p.m

Re: Review Request 61758: GEODE-3471: Identify NPE in MBeanProxyFactory

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/61758/#review183399 --- Ship it! Ship It! - Kirk Lund On Aug. 18, 2017, 9:55 p.m

Re: Review Request 61802: GEODE-3445: Add gfsh connect option --skip-ssl-validation

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/61802/#review183398 --- Ship it! Ship It! - Kirk Lund On Aug. 21, 2017, 9:06 p.m

Re: geode-old-versions dependencies is slooooowwww

Awesome! Thank you Dan! On Mon, Aug 21, 2017 at 2:26 PM, Dan Smith <dsm...@pivotal.io> wrote: > Hi Kirk, > > I just pushed a fix for this. It should only download geode.1.2.0 the first > time you build. > > -Dan > > On Mon, Aug 21, 2017 at 2:19 PM, Kirk Lund <k

Re: geode-old-versions dependencies is slooooowwww

oken or we should be caching this like other dependencies. I don't see why I need to re-download Geode 1.2.0 EVERY single time I do a clean build. On Mon, Aug 21, 2017 at 2:19 PM, Kirk Lund <kl...@apache.org> wrote: > Why does "geode-old-versions" download previous version

geode-old-versions dependencies is slooooowwww

Why does "geode-old-versions" download previous versions every time I rebuild from the command-line? And why is it s slow? Can't we cache these like other dependencies? :geode-old-versions:compileJava UP-TO-DATE :geode-old-versions:downloadSHAtest120 Download

Re: [Discuss] Compatibility with Apache Xerces

I think it's fine to add Xerces as a test runtime dependency. The fix to CacheXmlParser.java looks good to me! On Thu, Aug 17, 2017 at 11:35 PM, Darren Foong wrote: > Hi all, > > I'm

Re: Review Request 61701: GEODE-3277: Fix error path constructors of Launcher inner State classess

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/61701/#review183168 --- Ship it! Ship It! - Kirk Lund On Aug. 16, 2017, 9:21 p.m

Re: Review Request 61694: GEODE-3235: Deploy jar registers functions which extend FunctionAdapter

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/61694/#review183167 --- Ship it! Ship It! - Kirk Lund On Aug. 17, 2017, 8:21 p.m

Re: Review Request 61563: GEODE-3383: Refactor deploy tests

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/61563/#review183006 --- Ship it! Ship It! - Kirk Lund On Aug. 11, 2017, 9:52 p.m

Re: Review Request 61627: GEODE-3437: Fix list and describe region tests

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/61627/#review183007 --- Ship it! Ship It! - Kirk Lund On Aug. 14, 2017, 10:40 p.m

Re: Review Request 61671: GEODE-3328: fix testAddGemFirePropertyFileToCommandLineNew on Windows

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/61671/#review182999 --- On Aug. 15, 2017, 7:29 p.m., Kirk Lund wrote: > > --- > Thi

Review Request 61671: GEODE-3328: fix testAddGemFirePropertyFileToCommandLineNew on Windows

Emily's changes. Diffs - geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/GfshCommandJUnitTest.java da60c7aa481954be0acc8c7e2b88717cf8bc9c37 Diff: https://reviews.apache.org/r/61671/diff/1/ Testing --- precheckin in progress Thanks, Kirk Lund

Re: Reverting all Commands changes

On Sun, Aug 13, 2017 at 3:29 PM, Kirk Lund <kl...@apache.org> wrote: > Please do NOT commit any further changes to GFSH Commands classes or their > tests. > > I have a commit ready to vert all Commands changes from Friday. > Unfortunately two more commits are now adding to

Reverting all Commands changes

Please do NOT commit any further changes to GFSH Commands classes or their tests. I have a commit ready to vert all Commands changes from Friday. Unfortunately two more commits are now adding to the problems and now I'm going to have to revert these as well in order to revert the other commits I

Re: Management tests failing on develop

I tried to revert just a few of the commits. That didn't work so now I'm testing a branch where I've reverted all of the commits I pulled in yesterday. Hope to have that ready later this morning. On Fri, Aug 11, 2017 at 8:13 PM, Kirk Lund <kl...@apache.org> wrote: > I merged in 16

Management tests failing on develop

I merged in 16 PRs today and precheckin was clean for each individually. I launched a precheckin after all were merged in and that seems to have tons of Management test failures. So on Monday, I'll try to identify which PRs aren't playing nicely with each other and start backing them out. Sorry

Re: BCSnapshotDUnitTest failing

-Mark > > On Fri, Aug 11, 2017 at 4:09 PM, Kirk Lund <kl...@apache.org> wrote: > > > BCSnapshotDUnitTest seems to be failing intermittently(?) on develop. > > > > :pivotalgf-assembly:distributedTest > > > > org.apache.geode.BCSnapshotDUnitTest > testSn

Re: [DISCUSS] New annotation to identify Functions whose class hierarchy spans multiple jar files

I can't even say "RegisterableFunction" flibble flobble ;) On Fri, Aug 11, 2017 at 4:09 PM, Jared Stewart wrote: > Hi John, > > Thanks for the suggestions. I like “@RegisterableFunction” better than > “@RegisterFunction". I think that we don’t want @RegisterableFunction to

BCSnapshotDUnitTest failing

BCSnapshotDUnitTest seems to be failing intermittently(?) on develop. :pivotalgf-assembly:distributedTest org.apache.geode.BCSnapshotDUnitTest > testSnapshot[0] FAILED org.apache.geode.test.dunit.RMIException: While invoking org.apache.geode.BCSnapshotDUnitTest$1.run in VM 0 running on Host

Re: ParallelSnapshotFileMapper broke AnalyzeSerializablesJUnitTest

Looks like it was this commit... commit 7072f8ef7b764d1507e26cca8ed0c4d184ccc81a Author: Nick Reich <nre...@pivotal.io> Date: Fri Jul 28 16:47:10 2017 -0700 GEODE-3300: Complete and expose parallel export feature for use This closes #704 On Fri, Aug 11, 2017 at 3:40 PM, Kir

ParallelSnapshotFileMapper broke AnalyzeSerializablesJUnitTest

Looks like one of the recent commits to develop resulted in this failure involving org/apache/geode/internal/cache/snapshot/ParallelSnapshotFileMapper... :geode-core:integrationTest org.apache.geode.codeAnalysis.AnalyzeSerializablesJUnitTest > testSerializables FAILED

Re: Geode Native - All your globals are belong to us

Congratulations and thank you! On Fri, Aug 11, 2017 at 1:23 PM, Jacob Barrett wrote: > In case you missed the big commit recently, the Geode Native components has > removed all globals.* > > The biggest win here is that we can more easily unit test sections of the > code

Re: []DISCUSS] Using package names to identify public API's

One nice thing about releasing new code in *internal* packages is that we can always move them out of the *internal* packages at a later date but we cannot move non-deprecated code from external API packages into *internal* packages without worrying about backwards compatibility. On Fri, Aug 11,

Re: []DISCUSS] Using package names to identify public API's

+1 to continue using *internal* to differentiate code from external APIs The alternative would require Geode to be more modular, in which we have the external API in API- or SPI-specific jars and then the "internal" packages go into an implementation jar that needs to be on the classpath during

<    2   3   4   5   6   7   8   9   10   11   >