Re: [Proposal] Gfsh Command Feature Flag Annotation

[Swapnil Bawaskar]

This is a great start, however, there may be features that only add options
to gfsh commands rather than adding gfsh commands themselves, we should
accommodate those as and when we encounter them.

Udo, I like the idea of having a more generic solution for feature
flagging, however, if a feature is only introducing public API, I don't see
how we could hide it using an annotation.

On Wed, Mar 21, 2018 at 4:46 PM Swapnil Bawaskar 
wrote:

> I like @Disabled too.
>
> On Mon, Mar 19, 2018 at 12:02 PM Michael William Dodge 
> wrote:
>
>> I kind of like @Disabled instead.
>>
>> Sarge
>>
>> > On 19 Mar, 2018, at 11:58, Udo Kohlmeyer  wrote:
>> >
>> > I wonder if this proposal could not be extended to the greater GEODE
>> product. As this feature flagging is also relevant to other parts of the
>> system and should maybe be consistently applied to all areas.
>> >
>> > Thoughts?
>> >
>> >
>> > On 3/19/18 11:46, Patrick Rhomberg wrote:
>> >> Hello, All
>> >>
>> >>   I am interested in extending annotation functionality on our gfsh
>> >> commands, particularly with respect to feature-flagging commands that
>> are
>> >> mutually-reliant or not yet feature complete.
>> >>   Please review the proposal [1] at your convenience.
>> >>
>> >> Imagination is Change.
>> >> ~Patrick Rhomberg
>> >>
>> >> [1]
>> >>
>> https://cwiki.apache.org/confluence/display/GEODE/Proposal+for+Gfsh+Feature+Flag
>> >>
>> >
>>
>>

Re: [Proposal] Gfsh Command Feature Flag Annotation

[Swapnil Bawaskar]

I like @Disabled too.

On Mon, Mar 19, 2018 at 12:02 PM Michael William Dodge 
wrote:

> I kind of like @Disabled instead.
>
> Sarge
>
> > On 19 Mar, 2018, at 11:58, Udo Kohlmeyer  wrote:
> >
> > I wonder if this proposal could not be extended to the greater GEODE
> product. As this feature flagging is also relevant to other parts of the
> system and should maybe be consistently applied to all areas.
> >
> > Thoughts?
> >
> >
> > On 3/19/18 11:46, Patrick Rhomberg wrote:
> >> Hello, All
> >>
> >>   I am interested in extending annotation functionality on our gfsh
> >> commands, particularly with respect to feature-flagging commands that
> are
> >> mutually-reliant or not yet feature complete.
> >>   Please review the proposal [1] at your convenience.
> >>
> >> Imagination is Change.
> >> ~Patrick Rhomberg
> >>
> >> [1]
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Proposal+for+Gfsh+Feature+Flag
> >>
> >
>
>

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #863 was successful.
---
Scheduled
2381 tests in total.

https://build.spring.io/browse/SGF-NAG-863/





--
This message is automatically generated by Atlassian Bamboo

Re: GEODE Jira Access

[Dan Smith]

Hi Michael - What's your JIRA username? If you don't have one, please go
ahead and create an account.

-Dan

On Wed, Mar 21, 2018 at 3:27 PM, Michael Oleske  wrote:

> Hi all,
>
> I'd like to be able to update GEODE Jira to reflect what I'm working on, so
> was hoping to get access.
>
> Thanks!
> michael
>
> Michael Oleske
> Software Engineer
> Pivotal - Santa Monica
>

GEODE Jira Access

[Michael Oleske]

Hi all,

I'd like to be able to update GEODE Jira to reflect what I'm working on, so
was hoping to get access.

Thanks!
michael

Michael Oleske
Software Engineer
Pivotal - Santa Monica

Re: [VOTE] Apache Geode 1.5.0 RC1

[Dan Smith]

+1

Run geode-release-check. Verified no MD5 files in the distribution.

-Dan

On Wed, Mar 21, 2018 at 11:57 AM, Anthony Baker  wrote:

> +1
>
> - verified signatures and checksums
> - checked source release for binaries
> - basic gfsh testing
> - ran all the examples
>
> Anthony
>
> > On Mar 20, 2018, at 3:09 PM, Swapnil Bawaskar 
> wrote:
> >
> > This is the first release candidate for Apache Geode, version 1.5.0.
> > Thanks to all the community members for their contributions to this
> > release!
> >
> > *** Please download, test and vote by Friday, March 23, 1500 hrs
> > US Pacific. ***
> >
> > It fixes 234 issues. release notes can be found at:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12318420=12342395
> >
> > Note that we are voting upon the source tags: rel/v1.5.0.RC1
> > https://github.com/apache/geode/tree/rel/v1.5.0.RC1
> > https://github.com/apache/geode-examples/tree/rel/v1.5.0.RC1
> >
> > Commit ID:
> > 4ef51dacd79ff69336fb024f3d4b07271e90 (geode)
> > 4941f05c86d928949fbcdb3fb12295ccecc219eb (geode-examples)
> >
> > Source and binary files:
> > https://dist.apache.org/repos/dist/dev/geode/1.5.0.RC1
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachegeode-1038
> >
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> > https://github.com/apache/geode/blob/develop/KEYS
> >
> > Release Signed with Key: pub 4096R/18F902DB 2016-04-07
> > Fingerprint: E1B1 ABE3 4753 E7BA 8097 4285 8F8F 2BCC 18F9 02DB
>
>

Re: Recreate Cache -- is it possible?

[Jinmei Liao]

Sounds like this is a slippery slope. I reworked the strategy: instead of
calling cache.close, I only issue a call to the locator to get the cluster
configuration again and do a reload of the properties and cacheXml. Here is
the PR for this approach:
https://github.com/apache/geode/pull/1656

Basically this is what the reloadClusterConfiguration does:
https://github.com/apache/geode/pull/1656/files#diff-14ace6c5abf2f68c480b55a7c882e18c

If you see anything obviously wrong, or even vaguely wrong, please comment
on the PR, we will try to test it out.

Thanks!

On Wed, Mar 21, 2018 at 12:42 PM, Kirk Lund  wrote:

> The non-daemon thread in a process launched with ServerLauncher is looping
> in waitOnServer. When you close the Cache, that loop exits and the
> ServerLauncher process exits.
>
> As Bruce pointed you, JUnit and the DUnit VMs have other non-daemon
> threads.
>
> You might need to alter ServerLauncher.waitOnServer() and
> LocatorLauncher.waitOnLocator() for what you're doing.
>
> On Wed, Mar 21, 2018 at 10:28 AM, Jinmei Liao  wrote:
>
> > Bruce: this sounds like the root cause of the differences between the
> dunit
> > test and reall app test.
> >
> > On Wed, Mar 21, 2018 at 10:22 AM, Bruce Schuchardt <
> bschucha...@pivotal.io
> > >
> > wrote:
> >
> > > It's likely that the JVM is exiting because the AcceptorImpl thread is
> > the
> > > only non-daemon thread and it is stopped when the cache is closed.
> DUnit
> > > JVMs have a non-daemon main() thread that keeps them alive.
> > >
> > >
> > >
> > > On 3/21/18 9:48 AM, Jinmei Liao wrote:
> > >
> > >> We would like to allow users to import a new set of cluster
> > configuration
> > >> with running servers as long as we make sure these servers are vanilla
> > >> servers (servers that are just started with nothing in it). Now since
> > the
> > >> servers are already up, caches are already created, we will need to
> > >> re-create the cache with the new xml received from the locator.
> > Originally
> > >> our implementation on the servers boils down to:
> > >>
> > >> cache.close("Re-create Cache", true, true);
> > >>
> > >> GemFireCacheImpl.create(oldDs, cacheConfig);
> > >>
> > >>
> > >> but the cache.close call eventually leads to a VM exit (somehow in the
> > >> DUunit VM, it doesn not), so this does not work with real application
> > >> environment. Now we are wondering is there a safe to recreate the
> cache
> > >> instance with a new set of properties/cacheXml without triggering the
> > >> entire shutdown sequence?
> > >>
> > >>
> > >>
> > >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>



-- 
Cheers

Jinmei

Re: Recreate Cache -- is it possible?

[Kirk Lund]

The non-daemon thread in a process launched with ServerLauncher is looping
in waitOnServer. When you close the Cache, that loop exits and the
ServerLauncher process exits.

As Bruce pointed you, JUnit and the DUnit VMs have other non-daemon threads.

You might need to alter ServerLauncher.waitOnServer() and
LocatorLauncher.waitOnLocator() for what you're doing.

On Wed, Mar 21, 2018 at 10:28 AM, Jinmei Liao  wrote:

> Bruce: this sounds like the root cause of the differences between the dunit
> test and reall app test.
>
> On Wed, Mar 21, 2018 at 10:22 AM, Bruce Schuchardt  >
> wrote:
>
> > It's likely that the JVM is exiting because the AcceptorImpl thread is
> the
> > only non-daemon thread and it is stopped when the cache is closed.  DUnit
> > JVMs have a non-daemon main() thread that keeps them alive.
> >
> >
> >
> > On 3/21/18 9:48 AM, Jinmei Liao wrote:
> >
> >> We would like to allow users to import a new set of cluster
> configuration
> >> with running servers as long as we make sure these servers are vanilla
> >> servers (servers that are just started with nothing in it). Now since
> the
> >> servers are already up, caches are already created, we will need to
> >> re-create the cache with the new xml received from the locator.
> Originally
> >> our implementation on the servers boils down to:
> >>
> >> cache.close("Re-create Cache", true, true);
> >>
> >> GemFireCacheImpl.create(oldDs, cacheConfig);
> >>
> >>
> >> but the cache.close call eventually leads to a VM exit (somehow in the
> >> DUunit VM, it doesn not), so this does not work with real application
> >> environment. Now we are wondering is there a safe to recreate the cache
> >> instance with a new set of properties/cacheXml without triggering the
> >> entire shutdown sequence?
> >>
> >>
> >>
> >
>
>
> --
> Cheers
>
> Jinmei
>

Geode unit tests completed in 'develop/DistributedTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/216

Re: [VOTE] Apache Geode 1.5.0 RC1

[Anthony Baker]

+1

- verified signatures and checksums
- checked source release for binaries
- basic gfsh testing
- ran all the examples

Anthony

> On Mar 20, 2018, at 3:09 PM, Swapnil Bawaskar  wrote:
> 
> This is the first release candidate for Apache Geode, version 1.5.0.
> Thanks to all the community members for their contributions to this
> release!
> 
> *** Please download, test and vote by Friday, March 23, 1500 hrs
> US Pacific. ***
> 
> It fixes 234 issues. release notes can be found at:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420=12342395
> 
> Note that we are voting upon the source tags: rel/v1.5.0.RC1
> https://github.com/apache/geode/tree/rel/v1.5.0.RC1
> https://github.com/apache/geode-examples/tree/rel/v1.5.0.RC1
> 
> Commit ID:
> 4ef51dacd79ff69336fb024f3d4b07271e90 (geode)
> 4941f05c86d928949fbcdb3fb12295ccecc219eb (geode-examples)
> 
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/geode/1.5.0.RC1
> 
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachegeode-1038
> 
> 
> Geode's KEYS file containing PGP keys we use to sign the release:
> https://github.com/apache/geode/blob/develop/KEYS
> 
> Release Signed with Key: pub 4096R/18F902DB 2016-04-07
> Fingerprint: E1B1 ABE3 4753 E7BA 8097 4285 8F8F 2BCC 18F9 02DB

Re: Recreate Cache -- is it possible?

[Swapnil Bawaskar]

Does this mean auto-reconnect is broken as well?

On Wed, Mar 21, 2018 at 10:28 AM Jinmei Liao  wrote:

> Bruce: this sounds like the root cause of the differences between the dunit
> test and reall app test.
>
> On Wed, Mar 21, 2018 at 10:22 AM, Bruce Schuchardt  >
> wrote:
>
> > It's likely that the JVM is exiting because the AcceptorImpl thread is
> the
> > only non-daemon thread and it is stopped when the cache is closed.  DUnit
> > JVMs have a non-daemon main() thread that keeps them alive.
> >
> >
> >
> > On 3/21/18 9:48 AM, Jinmei Liao wrote:
> >
> >> We would like to allow users to import a new set of cluster
> configuration
> >> with running servers as long as we make sure these servers are vanilla
> >> servers (servers that are just started with nothing in it). Now since
> the
> >> servers are already up, caches are already created, we will need to
> >> re-create the cache with the new xml received from the locator.
> Originally
> >> our implementation on the servers boils down to:
> >>
> >> cache.close("Re-create Cache", true, true);
> >>
> >> GemFireCacheImpl.create(oldDs, cacheConfig);
> >>
> >>
> >> but the cache.close call eventually leads to a VM exit (somehow in the
> >> DUunit VM, it doesn not), so this does not work with real application
> >> environment. Now we are wondering is there a safe to recreate the cache
> >> instance with a new set of properties/cacheXml without triggering the
> >> entire shutdown sequence?
> >>
> >>
> >>
> >
>
>
> --
> Cheers
>
> Jinmei
>

Re: [DISCUSS] New List for Commit and CI Emails

[Galen O'Sullivan]

Yeah, I think I'm sending myself convinced by Swapnil's argument.

How about muting the "nightly build succeeded" email?

On Wed, Mar 21, 2018 at 9:58 AM, Sean Goller  wrote:

> Concourse sends mail whenever a job fails.
>
> On Wed, Mar 21, 2018 at 9:49 AM, Swapnil Bawaskar 
> wrote:
>
> > I know travis is already configured to send emails only when the build
> > breaks and then when it is fixed. Is concourse configured the same?
> >
> > On Wed, Mar 21, 2018 at 9:38 AM Patrick Rhomberg 
> > wrote:
> >
> > > I'm with Swapnil on this one.  I think the way we make it less noisy is
> > to
> > > take the time to fix the failing tests.
> > >
> > > I suppose we could split the difference and give the CI emails a, say,
> > > daily cadence.  No news is good news, or else it gives you all the
> > failures
> > > in the last 24 hours.  Don't know how easy that would be to cache and
> > > report under the existing framework, though.
> > >
> > > On Wed, Mar 21, 2018 at 12:05 AM, Jacob Barrett 
> > > wrote:
> > >
> > > > It’s sad that the most frequent spammer... e... I mean mailer is
> > the
> > > > new CI process. If we aren’t going to send it elsewhere how can we
> make
> > > it
> > > > less noisy?
> > > >
> > > > -Jake
> > > >
> > > >
> > > > > On Mar 20, 2018, at 8:37 PM, Dan Smith  wrote:
> > > > >
> > > > > I was curious about the stats for bot vs. humans on the dev list.
> Out
> > > of
> > > > > 915 messages, looks like we're about 50% robot.
> > > > >
> > > > > I'm still be in favor of not sending these messages to dev@geode.
> > Long
> > > > time
> > > > > members have probably already created a mail filter by now (I know
> I
> > > > have)
> > > > > so we're only hurting newbies by sending a bunch of messages.
> > > > >
> > > > > 1) apac...@gmail.com 241
> > > > > 2) Spring CI 109
> > > > > 3) Kirk Lund 63
> > > > > 4) Apache Jenkins Server 51
> > > > > 5) Anthony Baker 41
> > > > > 6) Dan Smith 40
> > > > > 7) Travis CI 38
> > > >
> > >
> >
>

Re: [VOTE] Apache Geode 1.5.0 RC1

[Anthony Baker]

Yep, the build inserts the username (in this case the release manager) into the 
version properties file.

Anthony


> On Mar 21, 2018, at 10:20 AM, Jens Deppe  wrote:
> 
> Is it normal for the build id to contain an actual username. As in:
> 
>  Build-Date: 2018-03-20 11:43:49 -0700
>  Build-Id: *sbawaskar* 0
>  Build-Java-Version: 1.8.0_121
>  Build-Platform: Mac OS X 10.13.3 x86_64
>  Product-Name: Apache Geode
>  Product-Version: 1.5.0
>  Source-Date: 2018-03-19 10:31:04 -0700
>  Source-Repository: release/1.5.0
>  Source-Revision: 4ef51dacd79ff69336fb024f3d4b07271e90
> 
> --Jens
> 
> On Wed, Mar 21, 2018 at 9:01 AM, Dave Barnes  wrote:
> 
>> +1 User Guide builds correctly from source, javadocs look up-to-date
>> 
>> On Wed, Mar 21, 2018 at 8:27 AM, Jens Deppe  wrote:
>> 
>>> +1 - basic gfsh functionality looks good on Windows.
>>> 
>>> On Tue, Mar 20, 2018 at 5:07 PM, Anthony Baker 
>> wrote:
>>> 
 md5 generation is already removed from geode, just need to do this for
 geode-examples.
 
 Anthony
 
 
> On Mar 20, 2018, at 3:30 PM, Swapnil Bawaskar 
 wrote:
> 
> Removed!
> 
> I also filed a JIRA to not generate the md5 checksum file going
>>> forward:
> https://issues.apache.org/jira/browse/GEODE-4903
> 
> On Tue, Mar 20, 2018 at 3:18 PM Dan Smith  wrote:
> 
>> It looks like we are still generating .md5 files. That doesn't
 necessarily
>> need to hold up this release (you could just delete them from SVN),
>>> but
>> we're not supposed to be distributing .md5 files anymore.
>> 
>> http://www.apache.org/dev/release-distribution#sigs-and-sums
>> 
>> -Dan
>> 
>> On Tue, Mar 20, 2018 at 3:09 PM, Swapnil Bawaskar <
>>> sbawas...@pivotal.io
> 
>> wrote:
>> 
>>> This is the first release candidate for Apache Geode, version
>> 1.5.0.
>>> Thanks to all the community members for their contributions to this
>>> release!
>>> 
>>> *** Please download, test and vote by Friday, March 23, 1500 hrs
>>> US Pacific. ***
>>> 
>>> It fixes 234 issues. release notes can be found at:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>> projectId=12318420=12342395
>>> 
>>> Note that we are voting upon the source tags: rel/v1.5.0.RC1
>>> https://github.com/apache/geode/tree/rel/v1.5.0.RC1
>>> https://github.com/apache/geode-examples/tree/rel/v1.5.0.RC1
>>> 
>>> Commit ID:
>>> 4ef51dacd79ff69336fb024f3d4b07271e90 (geode)
>>> 4941f05c86d928949fbcdb3fb12295ccecc219eb (geode-examples)
>>> 
>>> Source and binary files:
>>> https://dist.apache.org/repos/dist/dev/geode/1.5.0.RC1
>>> 
>>> Maven staging repo:
>>> https://repository.apache.org/content/repositories/
>>> orgapachegeode-1038
>>> 
>>> 
>>> Geode's KEYS file containing PGP keys we use to sign the release:
>>> https://github.com/apache/geode/blob/develop/KEYS
>>> 
>>> Release Signed with Key: pub 4096R/18F902DB 2016-04-07
>>> Fingerprint: E1B1 ABE3 4753 E7BA 8097 4285 8F8F 2BCC 18F9 02DB
>>> 
>> 
 
 
>>> 
>> 

Re: [DISCUSS] gradle checks for test categories.

[Anthony Baker]

We could always have a backstop job that executes uncategorized tests…?

Anthony


> On Mar 21, 2018, at 10:29 AM, Nabarun Nag  wrote:
> 
> Yes, Jens. The new module level categorization like LuceneTests, WanTests.
> I am worried that a test may be checked in but it is never executed as a
> part of module category test pipelines because we missed to add the module
> category to the test.
> 
> Regards
> Naba
> 
> On Wed, Mar 21, 2018 at 10:14 AM Jens Deppe  wrote:
> 
>> The build already fails if a test is added without @Category. Do you mean
>> it should fail if the test also does not have one of these newer
>> categories?
>> 
>> --Jens
>> 
>> On Wed, Mar 21, 2018 at 9:51 AM, Nabarun Nag  wrote:
>> 
>>> Hi,
>>> 
>>> As we have now categorized our tests to categories like LuceneTests,
>>> WanTests, OQLQueriesTests, should we modify our gradle script to fail the
>>> build if a new test class was added without a test category. This will
>>> prevent test classes to be added without a fine level test category by
>>> mistake.
>>> 
>>> Regards
>>> Nabarun
>>> 
>> 

Re: [DISCUSS] gradle checks for test categories.

[Nabarun Nag]

Yes, Jens. The new module level categorization like LuceneTests, WanTests.
I am worried that a test may be checked in but it is never executed as a
part of module category test pipelines because we missed to add the module
category to the test.

Regards
Naba

On Wed, Mar 21, 2018 at 10:14 AM Jens Deppe  wrote:

> The build already fails if a test is added without @Category. Do you mean
> it should fail if the test also does not have one of these newer
> categories?
>
> --Jens
>
> On Wed, Mar 21, 2018 at 9:51 AM, Nabarun Nag  wrote:
>
> > Hi,
> >
> > As we have now categorized our tests to categories like LuceneTests,
> > WanTests, OQLQueriesTests, should we modify our gradle script to fail the
> > build if a new test class was added without a test category. This will
> > prevent test classes to be added without a fine level test category by
> > mistake.
> >
> > Regards
> > Nabarun
> >
>

Re: Recreate Cache -- is it possible?

[Jinmei Liao]

Bruce: this sounds like the root cause of the differences between the dunit
test and reall app test.

On Wed, Mar 21, 2018 at 10:22 AM, Bruce Schuchardt 
wrote:

> It's likely that the JVM is exiting because the AcceptorImpl thread is the
> only non-daemon thread and it is stopped when the cache is closed.  DUnit
> JVMs have a non-daemon main() thread that keeps them alive.
>
>
>
> On 3/21/18 9:48 AM, Jinmei Liao wrote:
>
>> We would like to allow users to import a new set of cluster configuration
>> with running servers as long as we make sure these servers are vanilla
>> servers (servers that are just started with nothing in it). Now since the
>> servers are already up, caches are already created, we will need to
>> re-create the cache with the new xml received from the locator. Originally
>> our implementation on the servers boils down to:
>>
>> cache.close("Re-create Cache", true, true);
>>
>> GemFireCacheImpl.create(oldDs, cacheConfig);
>>
>>
>> but the cache.close call eventually leads to a VM exit (somehow in the
>> DUunit VM, it doesn not), so this does not work with real application
>> environment. Now we are wondering is there a safe to recreate the cache
>> instance with a new set of properties/cacheXml without triggering the
>> entire shutdown sequence?
>>
>>
>>
>


-- 
Cheers

Jinmei

Re: Recreate Cache -- is it possible?

[Jinmei Liao]

Kirk: good call. I will see if I can add an interface method to the
InternalCache.

On Wed, Mar 21, 2018 at 10:13 AM, Kirk Lund  wrote:

> I'm actively working to remove direct usage of GemFireCacheImpl from all of
> our code. Is there a reason you have to directly use GemFireCacheImpl? This
> is going to add one more thing that I have to change.
>
> Maybe the VM exit is happening because you've forked a new VM with
> ServerLauncher or LocatorLauncher? I think those launchers create a loop in
> the main thread which keeps the process alive -- if something causes that
> main thread to terminate then the VM will go away.
>
> On Wed, Mar 21, 2018 at 10:08 AM, Anilkumar Gingade 
> wrote:
>
> > Instead of adding new feature; can we address the issue with VM exit. The
> > auto-reconnect feature does cache close without exiting the VM.
> >
> > -Anil.
> >
> >
> >
> >
> > On Wed, Mar 21, 2018 at 9:48 AM, Jinmei Liao  wrote:
> >
> > > We would like to allow users to import a new set of cluster
> configuration
> > > with running servers as long as we make sure these servers are vanilla
> > > servers (servers that are just started with nothing in it). Now since
> the
> > > servers are already up, caches are already created, we will need to
> > > re-create the cache with the new xml received from the locator.
> > Originally
> > > our implementation on the servers boils down to:
> > >
> > > cache.close("Re-create Cache", true, true);
> > >
> > > GemFireCacheImpl.create(oldDs, cacheConfig);
> > >
> > >
> > > but the cache.close call eventually leads to a VM exit (somehow in the
> > > DUunit VM, it doesn not), so this does not work with real application
> > > environment. Now we are wondering is there a safe to recreate the cache
> > > instance with a new set of properties/cacheXml without triggering the
> > > entire shutdown sequence?
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>



-- 
Cheers

Jinmei

Re: Recreate Cache -- is it possible?

[Bruce Schuchardt]

It's likely that the JVM is exiting because the AcceptorImpl thread is 
the only non-daemon thread and it is stopped when the cache is closed.  
DUnit JVMs have a non-daemon main() thread that keeps them alive.



On 3/21/18 9:48 AM, Jinmei Liao wrote:

We would like to allow users to import a new set of cluster configuration
with running servers as long as we make sure these servers are vanilla
servers (servers that are just started with nothing in it). Now since the
servers are already up, caches are already created, we will need to
re-create the cache with the new xml received from the locator. Originally
our implementation on the servers boils down to:

cache.close("Re-create Cache", true, true);

GemFireCacheImpl.create(oldDs, cacheConfig);


but the cache.close call eventually leads to a VM exit (somehow in the
DUunit VM, it doesn not), so this does not work with real application
environment. Now we are wondering is there a safe to recreate the cache
instance with a new set of properties/cacheXml without triggering the
entire shutdown sequence?

Geode unit tests completed in 'develop/IntegrationTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/299

Re: [VOTE] Apache Geode 1.5.0 RC1

[Jens Deppe]

Is it normal for the build id to contain an actual username. As in:

  Build-Date: 2018-03-20 11:43:49 -0700
  Build-Id: *sbawaskar* 0
  Build-Java-Version: 1.8.0_121
  Build-Platform: Mac OS X 10.13.3 x86_64
  Product-Name: Apache Geode
  Product-Version: 1.5.0
  Source-Date: 2018-03-19 10:31:04 -0700
  Source-Repository: release/1.5.0
  Source-Revision: 4ef51dacd79ff69336fb024f3d4b07271e90

--Jens

On Wed, Mar 21, 2018 at 9:01 AM, Dave Barnes  wrote:

> +1 User Guide builds correctly from source, javadocs look up-to-date
>
> On Wed, Mar 21, 2018 at 8:27 AM, Jens Deppe  wrote:
>
> > +1 - basic gfsh functionality looks good on Windows.
> >
> > On Tue, Mar 20, 2018 at 5:07 PM, Anthony Baker 
> wrote:
> >
> > > md5 generation is already removed from geode, just need to do this for
> > > geode-examples.
> > >
> > > Anthony
> > >
> > >
> > > > On Mar 20, 2018, at 3:30 PM, Swapnil Bawaskar 
> > > wrote:
> > > >
> > > > Removed!
> > > >
> > > > I also filed a JIRA to not generate the md5 checksum file going
> > forward:
> > > > https://issues.apache.org/jira/browse/GEODE-4903
> > > >
> > > > On Tue, Mar 20, 2018 at 3:18 PM Dan Smith  wrote:
> > > >
> > > >> It looks like we are still generating .md5 files. That doesn't
> > > necessarily
> > > >> need to hold up this release (you could just delete them from SVN),
> > but
> > > >> we're not supposed to be distributing .md5 files anymore.
> > > >>
> > > >> http://www.apache.org/dev/release-distribution#sigs-and-sums
> > > >>
> > > >> -Dan
> > > >>
> > > >> On Tue, Mar 20, 2018 at 3:09 PM, Swapnil Bawaskar <
> > sbawas...@pivotal.io
> > > >
> > > >> wrote:
> > > >>
> > > >>> This is the first release candidate for Apache Geode, version
> 1.5.0.
> > > >>> Thanks to all the community members for their contributions to this
> > > >>> release!
> > > >>>
> > > >>> *** Please download, test and vote by Friday, March 23, 1500 hrs
> > > >>> US Pacific. ***
> > > >>>
> > > >>> It fixes 234 issues. release notes can be found at:
> > > >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > >>> projectId=12318420=12342395
> > > >>>
> > > >>> Note that we are voting upon the source tags: rel/v1.5.0.RC1
> > > >>> https://github.com/apache/geode/tree/rel/v1.5.0.RC1
> > > >>> https://github.com/apache/geode-examples/tree/rel/v1.5.0.RC1
> > > >>>
> > > >>> Commit ID:
> > > >>> 4ef51dacd79ff69336fb024f3d4b07271e90 (geode)
> > > >>> 4941f05c86d928949fbcdb3fb12295ccecc219eb (geode-examples)
> > > >>>
> > > >>> Source and binary files:
> > > >>> https://dist.apache.org/repos/dist/dev/geode/1.5.0.RC1
> > > >>>
> > > >>> Maven staging repo:
> > > >>> https://repository.apache.org/content/repositories/
> > orgapachegeode-1038
> > > >>>
> > > >>>
> > > >>> Geode's KEYS file containing PGP keys we use to sign the release:
> > > >>> https://github.com/apache/geode/blob/develop/KEYS
> > > >>>
> > > >>> Release Signed with Key: pub 4096R/18F902DB 2016-04-07
> > > >>> Fingerprint: E1B1 ABE3 4753 E7BA 8097 4285 8F8F 2BCC 18F9 02DB
> > > >>>
> > > >>
> > >
> > >
> >
>

Re: [DISCUSS] gradle checks for test categories.

[Jens Deppe]

The build already fails if a test is added without @Category. Do you mean
it should fail if the test also does not have one of these newer categories?

--Jens

On Wed, Mar 21, 2018 at 9:51 AM, Nabarun Nag  wrote:

> Hi,
>
> As we have now categorized our tests to categories like LuceneTests,
> WanTests, OQLQueriesTests, should we modify our gradle script to fail the
> build if a new test class was added without a test category. This will
> prevent test classes to be added without a fine level test category by
> mistake.
>
> Regards
> Nabarun
>

Re: Recreate Cache -- is it possible?

[Kirk Lund]

I'm actively working to remove direct usage of GemFireCacheImpl from all of
our code. Is there a reason you have to directly use GemFireCacheImpl? This
is going to add one more thing that I have to change.

Maybe the VM exit is happening because you've forked a new VM with
ServerLauncher or LocatorLauncher? I think those launchers create a loop in
the main thread which keeps the process alive -- if something causes that
main thread to terminate then the VM will go away.

On Wed, Mar 21, 2018 at 10:08 AM, Anilkumar Gingade 
wrote:

> Instead of adding new feature; can we address the issue with VM exit. The
> auto-reconnect feature does cache close without exiting the VM.
>
> -Anil.
>
>
>
>
> On Wed, Mar 21, 2018 at 9:48 AM, Jinmei Liao  wrote:
>
> > We would like to allow users to import a new set of cluster configuration
> > with running servers as long as we make sure these servers are vanilla
> > servers (servers that are just started with nothing in it). Now since the
> > servers are already up, caches are already created, we will need to
> > re-create the cache with the new xml received from the locator.
> Originally
> > our implementation on the servers boils down to:
> >
> > cache.close("Re-create Cache", true, true);
> >
> > GemFireCacheImpl.create(oldDs, cacheConfig);
> >
> >
> > but the cache.close call eventually leads to a VM exit (somehow in the
> > DUunit VM, it doesn not), so this does not work with real application
> > environment. Now we are wondering is there a safe to recreate the cache
> > instance with a new set of properties/cacheXml without triggering the
> > entire shutdown sequence?
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>

Re: Recreate Cache -- is it possible?

[Jinmei Liao]

Great, how do we trigger cache.close indicating auto-reconnect?

On Wed, Mar 21, 2018 at 10:08 AM, Anilkumar Gingade 
wrote:

> Instead of adding new feature; can we address the issue with VM exit. The
> auto-reconnect feature does cache close without exiting the VM.
>
> -Anil.
>
>
>
>
> On Wed, Mar 21, 2018 at 9:48 AM, Jinmei Liao  wrote:
>
> > We would like to allow users to import a new set of cluster configuration
> > with running servers as long as we make sure these servers are vanilla
> > servers (servers that are just started with nothing in it). Now since the
> > servers are already up, caches are already created, we will need to
> > re-create the cache with the new xml received from the locator.
> Originally
> > our implementation on the servers boils down to:
> >
> > cache.close("Re-create Cache", true, true);
> >
> > GemFireCacheImpl.create(oldDs, cacheConfig);
> >
> >
> > but the cache.close call eventually leads to a VM exit (somehow in the
> > DUunit VM, it doesn not), so this does not work with real application
> > environment. Now we are wondering is there a safe to recreate the cache
> > instance with a new set of properties/cacheXml without triggering the
> > entire shutdown sequence?
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>



-- 
Cheers

Jinmei

Re: Recreate Cache -- is it possible?

[Anilkumar Gingade]

Instead of adding new feature; can we address the issue with VM exit. The
auto-reconnect feature does cache close without exiting the VM.

-Anil.




On Wed, Mar 21, 2018 at 9:48 AM, Jinmei Liao  wrote:

> We would like to allow users to import a new set of cluster configuration
> with running servers as long as we make sure these servers are vanilla
> servers (servers that are just started with nothing in it). Now since the
> servers are already up, caches are already created, we will need to
> re-create the cache with the new xml received from the locator. Originally
> our implementation on the servers boils down to:
>
> cache.close("Re-create Cache", true, true);
>
> GemFireCacheImpl.create(oldDs, cacheConfig);
>
>
> but the cache.close call eventually leads to a VM exit (somehow in the
> DUunit VM, it doesn not), so this does not work with real application
> environment. Now we are wondering is there a safe to recreate the cache
> instance with a new set of properties/cacheXml without triggering the
> entire shutdown sequence?
>
>
> --
> Cheers
>
> Jinmei
>

Re: [DISCUSS] New List for Commit and CI Emails

[Sean Goller]

Concourse sends mail whenever a job fails.

On Wed, Mar 21, 2018 at 9:49 AM, Swapnil Bawaskar 
wrote:

> I know travis is already configured to send emails only when the build
> breaks and then when it is fixed. Is concourse configured the same?
>
> On Wed, Mar 21, 2018 at 9:38 AM Patrick Rhomberg 
> wrote:
>
> > I'm with Swapnil on this one.  I think the way we make it less noisy is
> to
> > take the time to fix the failing tests.
> >
> > I suppose we could split the difference and give the CI emails a, say,
> > daily cadence.  No news is good news, or else it gives you all the
> failures
> > in the last 24 hours.  Don't know how easy that would be to cache and
> > report under the existing framework, though.
> >
> > On Wed, Mar 21, 2018 at 12:05 AM, Jacob Barrett 
> > wrote:
> >
> > > It’s sad that the most frequent spammer... e... I mean mailer is
> the
> > > new CI process. If we aren’t going to send it elsewhere how can we make
> > it
> > > less noisy?
> > >
> > > -Jake
> > >
> > >
> > > > On Mar 20, 2018, at 8:37 PM, Dan Smith  wrote:
> > > >
> > > > I was curious about the stats for bot vs. humans on the dev list. Out
> > of
> > > > 915 messages, looks like we're about 50% robot.
> > > >
> > > > I'm still be in favor of not sending these messages to dev@geode.
> Long
> > > time
> > > > members have probably already created a mail filter by now (I know I
> > > have)
> > > > so we're only hurting newbies by sending a bunch of messages.
> > > >
> > > > 1) apac...@gmail.com 241
> > > > 2) Spring CI 109
> > > > 3) Kirk Lund 63
> > > > 4) Apache Jenkins Server 51
> > > > 5) Anthony Baker 41
> > > > 6) Dan Smith 40
> > > > 7) Travis CI 38
> > >
> >
>

[DISCUSS] gradle checks for test categories.

[Nabarun Nag]

Hi,

As we have now categorized our tests to categories like LuceneTests,
WanTests, OQLQueriesTests, should we modify our gradle script to fail the
build if a new test class was added without a test category. This will
prevent test classes to be added without a fine level test category by
mistake.

Regards
Nabarun

Re: [DISCUSS] New List for Commit and CI Emails

[Swapnil Bawaskar]

I know travis is already configured to send emails only when the build
breaks and then when it is fixed. Is concourse configured the same?

On Wed, Mar 21, 2018 at 9:38 AM Patrick Rhomberg 
wrote:

> I'm with Swapnil on this one.  I think the way we make it less noisy is to
> take the time to fix the failing tests.
>
> I suppose we could split the difference and give the CI emails a, say,
> daily cadence.  No news is good news, or else it gives you all the failures
> in the last 24 hours.  Don't know how easy that would be to cache and
> report under the existing framework, though.
>
> On Wed, Mar 21, 2018 at 12:05 AM, Jacob Barrett 
> wrote:
>
> > It’s sad that the most frequent spammer... e... I mean mailer is the
> > new CI process. If we aren’t going to send it elsewhere how can we make
> it
> > less noisy?
> >
> > -Jake
> >
> >
> > > On Mar 20, 2018, at 8:37 PM, Dan Smith  wrote:
> > >
> > > I was curious about the stats for bot vs. humans on the dev list. Out
> of
> > > 915 messages, looks like we're about 50% robot.
> > >
> > > I'm still be in favor of not sending these messages to dev@geode. Long
> > time
> > > members have probably already created a mail filter by now (I know I
> > have)
> > > so we're only hurting newbies by sending a bunch of messages.
> > >
> > > 1) apac...@gmail.com 241
> > > 2) Spring CI 109
> > > 3) Kirk Lund 63
> > > 4) Apache Jenkins Server 51
> > > 5) Anthony Baker 41
> > > 6) Dan Smith 40
> > > 7) Travis CI 38
> >
>

Recreate Cache -- is it possible?

[Jinmei Liao]

We would like to allow users to import a new set of cluster configuration
with running servers as long as we make sure these servers are vanilla
servers (servers that are just started with nothing in it). Now since the
servers are already up, caches are already created, we will need to
re-create the cache with the new xml received from the locator. Originally
our implementation on the servers boils down to:

cache.close("Re-create Cache", true, true);

GemFireCacheImpl.create(oldDs, cacheConfig);


but the cache.close call eventually leads to a VM exit (somehow in the
DUunit VM, it doesn not), so this does not work with real application
environment. Now we are wondering is there a safe to recreate the cache
instance with a new set of properties/cacheXml without triggering the
entire shutdown sequence?


-- 
Cheers

Jinmei

Re: [DISCUSS] New List for Commit and CI Emails

[Patrick Rhomberg]

I'm with Swapnil on this one.  I think the way we make it less noisy is to
take the time to fix the failing tests.

I suppose we could split the difference and give the CI emails a, say,
daily cadence.  No news is good news, or else it gives you all the failures
in the last 24 hours.  Don't know how easy that would be to cache and
report under the existing framework, though.

On Wed, Mar 21, 2018 at 12:05 AM, Jacob Barrett  wrote:

> It’s sad that the most frequent spammer... e... I mean mailer is the
> new CI process. If we aren’t going to send it elsewhere how can we make it
> less noisy?
>
> -Jake
>
>
> > On Mar 20, 2018, at 8:37 PM, Dan Smith  wrote:
> >
> > I was curious about the stats for bot vs. humans on the dev list. Out of
> > 915 messages, looks like we're about 50% robot.
> >
> > I'm still be in favor of not sending these messages to dev@geode. Long
> time
> > members have probably already created a mail filter by now (I know I
> have)
> > so we're only hurting newbies by sending a bunch of messages.
> >
> > 1) apac...@gmail.com 241
> > 2) Spring CI 109
> > 3) Kirk Lund 63
> > 4) Apache Jenkins Server 51
> > 5) Anthony Baker 41
> > 6) Dan Smith 40
> > 7) Travis CI 38
>

Re: [VOTE] Apache Geode 1.5.0 RC1

[Dave Barnes]

+1 User Guide builds correctly from source, javadocs look up-to-date

On Wed, Mar 21, 2018 at 8:27 AM, Jens Deppe  wrote:

> +1 - basic gfsh functionality looks good on Windows.
>
> On Tue, Mar 20, 2018 at 5:07 PM, Anthony Baker  wrote:
>
> > md5 generation is already removed from geode, just need to do this for
> > geode-examples.
> >
> > Anthony
> >
> >
> > > On Mar 20, 2018, at 3:30 PM, Swapnil Bawaskar 
> > wrote:
> > >
> > > Removed!
> > >
> > > I also filed a JIRA to not generate the md5 checksum file going
> forward:
> > > https://issues.apache.org/jira/browse/GEODE-4903
> > >
> > > On Tue, Mar 20, 2018 at 3:18 PM Dan Smith  wrote:
> > >
> > >> It looks like we are still generating .md5 files. That doesn't
> > necessarily
> > >> need to hold up this release (you could just delete them from SVN),
> but
> > >> we're not supposed to be distributing .md5 files anymore.
> > >>
> > >> http://www.apache.org/dev/release-distribution#sigs-and-sums
> > >>
> > >> -Dan
> > >>
> > >> On Tue, Mar 20, 2018 at 3:09 PM, Swapnil Bawaskar <
> sbawas...@pivotal.io
> > >
> > >> wrote:
> > >>
> > >>> This is the first release candidate for Apache Geode, version 1.5.0.
> > >>> Thanks to all the community members for their contributions to this
> > >>> release!
> > >>>
> > >>> *** Please download, test and vote by Friday, March 23, 1500 hrs
> > >>> US Pacific. ***
> > >>>
> > >>> It fixes 234 issues. release notes can be found at:
> > >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > >>> projectId=12318420=12342395
> > >>>
> > >>> Note that we are voting upon the source tags: rel/v1.5.0.RC1
> > >>> https://github.com/apache/geode/tree/rel/v1.5.0.RC1
> > >>> https://github.com/apache/geode-examples/tree/rel/v1.5.0.RC1
> > >>>
> > >>> Commit ID:
> > >>> 4ef51dacd79ff69336fb024f3d4b07271e90 (geode)
> > >>> 4941f05c86d928949fbcdb3fb12295ccecc219eb (geode-examples)
> > >>>
> > >>> Source and binary files:
> > >>> https://dist.apache.org/repos/dist/dev/geode/1.5.0.RC1
> > >>>
> > >>> Maven staging repo:
> > >>> https://repository.apache.org/content/repositories/
> orgapachegeode-1038
> > >>>
> > >>>
> > >>> Geode's KEYS file containing PGP keys we use to sign the release:
> > >>> https://github.com/apache/geode/blob/develop/KEYS
> > >>>
> > >>> Release Signed with Key: pub 4096R/18F902DB 2016-04-07
> > >>> Fingerprint: E1B1 ABE3 4753 E7BA 8097 4285 8F8F 2BCC 18F9 02DB
> > >>>
> > >>
> >
> >
>

Re: [VOTE] Apache Geode 1.5.0 RC1

[Jens Deppe]

+1 - basic gfsh functionality looks good on Windows.

On Tue, Mar 20, 2018 at 5:07 PM, Anthony Baker  wrote:

> md5 generation is already removed from geode, just need to do this for
> geode-examples.
>
> Anthony
>
>
> > On Mar 20, 2018, at 3:30 PM, Swapnil Bawaskar 
> wrote:
> >
> > Removed!
> >
> > I also filed a JIRA to not generate the md5 checksum file going forward:
> > https://issues.apache.org/jira/browse/GEODE-4903
> >
> > On Tue, Mar 20, 2018 at 3:18 PM Dan Smith  wrote:
> >
> >> It looks like we are still generating .md5 files. That doesn't
> necessarily
> >> need to hold up this release (you could just delete them from SVN), but
> >> we're not supposed to be distributing .md5 files anymore.
> >>
> >> http://www.apache.org/dev/release-distribution#sigs-and-sums
> >>
> >> -Dan
> >>
> >> On Tue, Mar 20, 2018 at 3:09 PM, Swapnil Bawaskar  >
> >> wrote:
> >>
> >>> This is the first release candidate for Apache Geode, version 1.5.0.
> >>> Thanks to all the community members for their contributions to this
> >>> release!
> >>>
> >>> *** Please download, test and vote by Friday, March 23, 1500 hrs
> >>> US Pacific. ***
> >>>
> >>> It fixes 234 issues. release notes can be found at:
> >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> >>> projectId=12318420=12342395
> >>>
> >>> Note that we are voting upon the source tags: rel/v1.5.0.RC1
> >>> https://github.com/apache/geode/tree/rel/v1.5.0.RC1
> >>> https://github.com/apache/geode-examples/tree/rel/v1.5.0.RC1
> >>>
> >>> Commit ID:
> >>> 4ef51dacd79ff69336fb024f3d4b07271e90 (geode)
> >>> 4941f05c86d928949fbcdb3fb12295ccecc219eb (geode-examples)
> >>>
> >>> Source and binary files:
> >>> https://dist.apache.org/repos/dist/dev/geode/1.5.0.RC1
> >>>
> >>> Maven staging repo:
> >>> https://repository.apache.org/content/repositories/orgapachegeode-1038
> >>>
> >>>
> >>> Geode's KEYS file containing PGP keys we use to sign the release:
> >>> https://github.com/apache/geode/blob/develop/KEYS
> >>>
> >>> Release Signed with Key: pub 4096R/18F902DB 2016-04-07
> >>> Fingerprint: E1B1 ABE3 4753 E7BA 8097 4285 8F8F 2BCC 18F9 02DB
> >>>
> >>
>
>

Re: [DISCUSS] New List for Commit and CI Emails

[Jacob Barrett]

It’s sad that the most frequent spammer... e... I mean mailer is the new CI 
process. If we aren’t going to send it elsewhere how can we make it less noisy?

-Jake


> On Mar 20, 2018, at 8:37 PM, Dan Smith  wrote:
> 
> I was curious about the stats for bot vs. humans on the dev list. Out of
> 915 messages, looks like we're about 50% robot.
> 
> I'm still be in favor of not sending these messages to dev@geode. Long time
> members have probably already created a mail filter by now (I know I have)
> so we're only hurting newbies by sending a bunch of messages.
> 
> 1) apac...@gmail.com 241
> 2) Spring CI 109
> 3) Kirk Lund 63
> 4) Apache Jenkins Server 51
> 5) Anthony Baker 41
> 6) Dan Smith 40
> 7) Travis CI 38