Re: [ANNOUNCE] Apache Geode 1.4.0

[Akihiro Kitada]

Awesome!


-- 
Akihiro Kitada  |  Staff Customer Engineer |  +81 80 3716 3736
Support.Pivotal.io   |  Mon-Fri  9:00am to
5:30pm JST  |  1-877-477-2269
[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]



2018-02-05 19:10 GMT+09:00 Swapnil Bawaskar :

> The Apache Geode community is pleased to announce the availability of
> Apache Geode 1.4.0.
>
> Apache Geode is a data management platform that provides a database-like
> consistency model, reliable transaction processing and a shared-nothing
> architecture to maintain very low latency performance with high concurrency
> processing.
>
> Geode 1.4.0 contains a number of improvements and bug fixes. This release
> includes a simple JDBC connector which enables read-through and write
> behind to any RDBMS without any custom code, enables indexing nested fields
> for lucene indexes, optimizations to reduce memory footprint of compact
> range indexes and optimizations to reduce CPU consumption by eviction
> algorithm. Users are encouraged to upgrade to the latest release.
>
> For the full list of changes please review the release notes:
> https://cwiki.apache.org/confluence/display/GEODE/Release+
> Notes#ReleaseNotes-1.4.0
>
> The release artifacts can be downloaded from the project website:
> http://geode.apache.org/releases/
>
> The release documentation is available at:
> http://geode.apache.org/docs/guide/14/about_geode.html
>
> We would like to thank all the contributors that made the release possible.
>
> Regards,
> Swapnil Bawaskar on behalf of the Apache Geode team
>

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #819 was SUCCESSFUL (with 2324 tests). Change made by John Blum.

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #819 was successful.
---
Scheduled with changes by John Blum.
2326 tests in total.

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




--
Code Changes
--
John Blum (16922269f42af80f3ee0fef572ed522381713744):

>DATAGEODE-80 - Upgrade to Apache Geode 1.4.0.



--
This message is automatically generated by Atlassian Bamboo

Volunteer Request: Write Draft Board Report For February 2018

[Mark Bretl]

Hi Everyone,

Great job on getting 1.4.0 released, which makes it good timing that we are
scheduled to report to the Apache board for the board meeting on February
21st.

Template: https://cwiki.apache.org/confluence/display/GEODE/ASF+Board+Report
+Template

Previous Reports: https://whimsy.apache.org/board/minutes/Geode.html

Would anyone like to volunteer to write a draft of the report?

Best regards,

--Mark

Re: Naming unit tests and integration tests

[Bruce Schuchardt]

Should we make a pass over all of the tests and rename them to follow 
the conventions we come up with?  It would take some time, and maybe 
access to Pivotal's old Trac issue tracker in order to rename files with 
"Bug" and numbers for a name.



On 2/5/18 12:28 PM, Kirk Lund wrote:

I've been using the name FooDistributedTest for new dunit tests. I
should've included that.

For RegressionTests, I've been including the GEODE jira ticket number and
summary in the javadocs on the test class. I'll include that in any changes
I make to the wiki.

On Mon, Feb 5, 2018 at 11:55 AM, Bruce Schuchardt 
wrote:


These seem like sensible ideas to me.  I especially don't like tests named
after bug numbers.  I do like a pointer to relevant tickets in test
comments/javadocs though.

We also have DUnitTest.  Some designation in the name that it's using the
dunit infrastructure is often useful to me.  Having to open a file to see
that it's a DistributedTest vs a regular unit test could make life more
difficult.  Putting them in their own source tree would help with that.


On 2/5/18 11:49 AM, Kirk Lund wrote:


Another valuable naming standard is the use FooRegressionTest for tests
that are specific to reproducing a bug and verifying its fix. Don't use
Bug007IntegrationTest. Use something description like
QueryShouldNotIncludeTXSetsRegressionTest (if you want a separate test
class for the bug which is sometimes better -- otherwise just add new
tests
to existing tests).

On Mon, Feb 5, 2018 at 11:42 AM, Kirk Lund  wrote:

The industry standard names for tests are FooTest and FooIntegrationTest

and I think we should stick to that for UnitTest and IntegrationTest.

The following block is defined in our wiki. I'd like to replace the line
"End with JUnitTest" -- there's no reason to including "JUnit" in the
name
of our JUnit tests. Even if we decide to separate test categories in some
way other than the @Category support in Gradle's junit task, the next
preferred alternative should be different src tests (src/test,
src/integrationTest, src/distributedTest). Adding "JUnit" to the name is
an
outdated convention tied to our previous Ant build system.

JUnit tests should

. Use Junit 4 Syntax
*. End with JUnitTest*
. Contain an Category annotation of either UnitTest or IntegrationTest.
UnitTests as should complete in milliseconds and test a specific class.

Re: Naming unit tests and integration tests

[Kirk Lund]

I've been using the name FooDistributedTest for new dunit tests. I
should've included that.

For RegressionTests, I've been including the GEODE jira ticket number and
summary in the javadocs on the test class. I'll include that in any changes
I make to the wiki.

On Mon, Feb 5, 2018 at 11:55 AM, Bruce Schuchardt 
wrote:

> These seem like sensible ideas to me.  I especially don't like tests named
> after bug numbers.  I do like a pointer to relevant tickets in test
> comments/javadocs though.
>
> We also have DUnitTest.  Some designation in the name that it's using the
> dunit infrastructure is often useful to me.  Having to open a file to see
> that it's a DistributedTest vs a regular unit test could make life more
> difficult.  Putting them in their own source tree would help with that.
>
>
> On 2/5/18 11:49 AM, Kirk Lund wrote:
>
>> Another valuable naming standard is the use FooRegressionTest for tests
>> that are specific to reproducing a bug and verifying its fix. Don't use
>> Bug007IntegrationTest. Use something description like
>> QueryShouldNotIncludeTXSetsRegressionTest (if you want a separate test
>> class for the bug which is sometimes better -- otherwise just add new
>> tests
>> to existing tests).
>>
>> On Mon, Feb 5, 2018 at 11:42 AM, Kirk Lund  wrote:
>>
>> The industry standard names for tests are FooTest and FooIntegrationTest
>>> and I think we should stick to that for UnitTest and IntegrationTest.
>>>
>>> The following block is defined in our wiki. I'd like to replace the line
>>> "End with JUnitTest" -- there's no reason to including "JUnit" in the
>>> name
>>> of our JUnit tests. Even if we decide to separate test categories in some
>>> way other than the @Category support in Gradle's junit task, the next
>>> preferred alternative should be different src tests (src/test,
>>> src/integrationTest, src/distributedTest). Adding "JUnit" to the name is
>>> an
>>> outdated convention tied to our previous Ant build system.
>>>
>>> JUnit tests should
>>>
>>> . Use Junit 4 Syntax
>>> *. End with JUnitTest*
>>> . Contain an Category annotation of either UnitTest or IntegrationTest.
>>> UnitTests as should complete in milliseconds and test a specific class.
>>>
>>>
>

Re: Naming unit tests and integration tests

[Bruce Schuchardt]

These seem like sensible ideas to me.  I especially don't like tests 
named after bug numbers.  I do like a pointer to relevant tickets in 
test comments/javadocs though.


We also have DUnitTest.  Some designation in the name that it's using 
the dunit infrastructure is often useful to me.  Having to open a file 
to see that it's a DistributedTest vs a regular unit test could make 
life more difficult.  Putting them in their own source tree would help 
with that.



On 2/5/18 11:49 AM, Kirk Lund wrote:

Another valuable naming standard is the use FooRegressionTest for tests
that are specific to reproducing a bug and verifying its fix. Don't use
Bug007IntegrationTest. Use something description like
QueryShouldNotIncludeTXSetsRegressionTest (if you want a separate test
class for the bug which is sometimes better -- otherwise just add new tests
to existing tests).

On Mon, Feb 5, 2018 at 11:42 AM, Kirk Lund  wrote:


The industry standard names for tests are FooTest and FooIntegrationTest
and I think we should stick to that for UnitTest and IntegrationTest.

The following block is defined in our wiki. I'd like to replace the line
"End with JUnitTest" -- there's no reason to including "JUnit" in the name
of our JUnit tests. Even if we decide to separate test categories in some
way other than the @Category support in Gradle's junit task, the next
preferred alternative should be different src tests (src/test,
src/integrationTest, src/distributedTest). Adding "JUnit" to the name is an
outdated convention tied to our previous Ant build system.

JUnit tests should

. Use Junit 4 Syntax
*. End with JUnitTest*
. Contain an Category annotation of either UnitTest or IntegrationTest.
UnitTests as should complete in milliseconds and test a specific class.

Re: Naming unit tests and integration tests

[Kirk Lund]

Another valuable naming standard is the use FooRegressionTest for tests
that are specific to reproducing a bug and verifying its fix. Don't use
Bug007IntegrationTest. Use something description like
QueryShouldNotIncludeTXSetsRegressionTest (if you want a separate test
class for the bug which is sometimes better -- otherwise just add new tests
to existing tests).

On Mon, Feb 5, 2018 at 11:42 AM, Kirk Lund  wrote:

> The industry standard names for tests are FooTest and FooIntegrationTest
> and I think we should stick to that for UnitTest and IntegrationTest.
>
> The following block is defined in our wiki. I'd like to replace the line
> "End with JUnitTest" -- there's no reason to including "JUnit" in the name
> of our JUnit tests. Even if we decide to separate test categories in some
> way other than the @Category support in Gradle's junit task, the next
> preferred alternative should be different src tests (src/test,
> src/integrationTest, src/distributedTest). Adding "JUnit" to the name is an
> outdated convention tied to our previous Ant build system.
>
> JUnit tests should
>
> . Use Junit 4 Syntax
> *. End with JUnitTest*
> . Contain an Category annotation of either UnitTest or IntegrationTest.
> UnitTests as should complete in milliseconds and test a specific class.
>

Re: MigrationClient and MigrationServer

[Michael Stolz]

Yeah we made a change to our diskstore format right around 6.0 that caused
customers to have to migrate all their persistent stores.
I don't think we have any plans to attempt any migrations from pre-6.0 any
more ;)

+1 for deleting these

--
Mike Stolz
Principal Engineer, GemFire Product Lead
Mobile: +1-631-835-4771
Download the new GemFire book here.


On Mon, Feb 5, 2018 at 1:08 PM, Anilkumar Gingade 
wrote:

> Its used for data migration from one version to another...Don't see any
> mention of this in docs or any tools built around it.
>
> +1 for removal.
>
> -Anil.
>
>
> On Fri, Feb 2, 2018 at 4:38 PM, Kirk Lund  wrote:
>
> > I just ran across two classes in org.apache.geode.internal package:
> > * MigrationClient
> > * MigrationServer
> >
> > They have the javadoc @since GemFire 6.0.1 so I suspect these are no
> longer
> > useful or relevant. Can I delete these classes?
> >
> > Thanks,
> > Kirk
> >
>

Re: MigrationClient and MigrationServer

[Udo Kohlmeyer]

+1 to remove. UNLESS we want to start a migration module, which could
contain all the scripts or classes we require to do some migration on/off
line...

--Udo

On Mon, Feb 5, 2018 at 10:08 AM, Anilkumar Gingade 
wrote:

> Its used for data migration from one version to another...Don't see any
> mention of this in docs or any tools built around it.
>
> +1 for removal.
>
> -Anil.
>
>
> On Fri, Feb 2, 2018 at 4:38 PM, Kirk Lund  wrote:
>
> > I just ran across two classes in org.apache.geode.internal package:
> > * MigrationClient
> > * MigrationServer
> >
> > They have the javadoc @since GemFire 6.0.1 so I suspect these are no
> longer
> > useful or relevant. Can I delete these classes?
> >
> > Thanks,
> > Kirk
> >
>

Re: MigrationClient and MigrationServer

[Anilkumar Gingade]

Its used for data migration from one version to another...Don't see any
mention of this in docs or any tools built around it.

+1 for removal.

-Anil.


On Fri, Feb 2, 2018 at 4:38 PM, Kirk Lund  wrote:

> I just ran across two classes in org.apache.geode.internal package:
> * MigrationClient
> * MigrationServer
>
> They have the javadoc @since GemFire 6.0.1 so I suspect these are no longer
> useful or relevant. Can I delete these classes?
>
> Thanks,
> Kirk
>

[ANNOUNCE] Apache Geode 1.4.0

[Swapnil Bawaskar]

The Apache Geode community is pleased to announce the availability of
Apache Geode 1.4.0.

Apache Geode is a data management platform that provides a database-like
consistency model, reliable transaction processing and a shared-nothing
architecture to maintain very low latency performance with high concurrency
processing.

Geode 1.4.0 contains a number of improvements and bug fixes. This release
includes a simple JDBC connector which enables read-through and write
behind to any RDBMS without any custom code, enables indexing nested fields
for lucene indexes, optimizations to reduce memory footprint of compact
range indexes and optimizations to reduce CPU consumption by eviction
algorithm. Users are encouraged to upgrade to the latest release.

For the full list of changes please review the release notes:
https://cwiki.apache.org/confluence/display/GEODE/
Release+Notes#ReleaseNotes-1.4.0

The release artifacts can be downloaded from the project website:
http://geode.apache.org/releases/

The release documentation is available at:
http://geode.apache.org/docs/guide/14/about_geode.html

We would like to thank all the contributors that made the release possible.

Regards,
Swapnil Bawaskar on behalf of the Apache Geode team