[Discuss] replace jsonToObject method with com.fasterxml.jackson.databind. ObjectMapper ->readValue

[Dinesh Akhand]

Hi Team,

In geode, we are using our own written  parsing method in geode.
Method :
public static  T jsonToObject(String jsonString, Class klass) {

it have custom parsing logic
   while (keys.hasNext()) {
String key = keys.next();
Method method = methodsMap.get("set" + capitalize(key));
if (method != null) {
  Class[] parameterTypes = method.getParameterTypes();
  if (parameterTypes.length == 1) {
Class parameterType = parameterTypes[0];

Object value = jsonObject.get(key);
if (isPrimitiveOrWrapper(parameterType)) {
  value = 
ConvertUtils.convert(getPrimitiveOrWrapperValue(parameterType, 
value),parameterType);
}
// Bug #51175
else if (isArray(parameterType)) {
  value = toArray(value, parameterType);
} else if (isList(parameterType)) {
  value = toList(value, parameterType);
} else if (isMap(parameterType)) {
  value = toMap(value, parameterType);
} else if (isSet(parameterType)) {
  value = toSet(value, parameterType);
} else {
  value = jsonToObject(value.toString(), parameterType);
}
method.invoke(objectFromJson, new Object[] {value});
noOfFields--;
  }

can we use replace this parsing with readValue method of ObjectMapper Class 
call?.

jackson-databind-2.8.6.jar
com.fasterxml.jackson.databind. ObjectMapper class
which have readValue method which works for all data type. It convert json to 
class type object.
What do you think??

Example :
 ObjectMapper mapper = new ObjectMapper();
 String emp_key = mapper.writeValueAsString(key1);
  System.out.println(emp_key);
 Object empkey = mapper.readValue(emp_key, SICKey1.class);


I have seen issue in this method

When key class having the byte[] inside it or method isArray, isList, isMap, 
toMap, toSet when these have byte[] inside it.

Any suggestion to adopt new method.

Thanks,
Dinesh Akhand
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

Re: Return types form methods on Cache

[David Kimura]

I favor values, but we should probably be diligent.

Do any of the objects returned from Cache depend on Cache to out-live the
returned object?  A quick scan suggested no, but we still have a
std::enable_shared_from_this.  Maybe dead code.  In code example, if
this happens (for any cache.get*), could we be in trouble or is this user
error?

Region r = [](){ CacheFactory::create().getRegion("myregion"); }();
// Cache is out of scope.
// What is expected behavior?
r.put("key", "value");

Thanks,
David

On Mon, Sep 18, 2017 at 7:44 PM, Jacob Barrett  wrote:

>
>
> > On Sep 18, 2017, at 7:34 PM, Kirk Lund  wrote:
> >
> > 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.
>
> There really isn’t, especially if you look at what we did dirty
> CacheFactory::getCache by returning a value that can be moved into the heap
> and a shared point of one wants but not being forced into it. RVO tricks
> can event make that move a noop.
>
> auto r = cache.getRegion(...);
> Where decltype(r) == Region
> and
> auto rp = std::make_shared(cache->getRegion());
> Where decltype(rp) == shared_ptr
>
> Would both be valid.
>
>
>

Re: Return types form methods on Cache

[David Kimura]

Err... I missed a return in example above.

Region r = [](){ return CacheFactory::create().getRegion("myregion"); } ();

On Tue, Sep 19, 2017 at 10:19 AM, David Kimura  wrote:

> I favor values, but we should probably be diligent.
>
> Do any of the objects returned from Cache depend on Cache to out-live the
> returned object?  A quick scan suggested no, but we still have a
> std::enable_shared_from_this.  Maybe dead code.  In code example,
> if this happens (for any cache.get*), could we be in trouble or is this
> user error?
>
> Region r = [](){ CacheFactory::create().getRegion("myregion"); }();
> // Cache is out of scope.
> // What is expected behavior?
> r.put("key", "value");
>
> Thanks,
> David
>
> On Mon, Sep 18, 2017 at 7:44 PM, Jacob Barrett 
> wrote:
>
>>
>>
>> > On Sep 18, 2017, at 7:34 PM, Kirk Lund  wrote:
>> >
>> > 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.
>>
>> There really isn’t, especially if you look at what we did dirty
>> CacheFactory::getCache by returning a value that can be moved into the heap
>> and a shared point of one wants but not being forced into it. RVO tricks
>> can event make that move a noop.
>>
>> auto r = cache.getRegion(...);
>> Where decltype(r) == Region
>> and
>> auto rp = std::make_shared(cache->getRegion());
>> Where decltype(rp) == shared_ptr
>>
>> Would both be valid.
>>
>>
>>
>

Re: Return types form methods on Cache

[Jacob Barrett]

Region returned by this would no longer be valid. It’s “references” to interns 
cache/region would be invalid. The behavior is undefined.

> On Sep 19, 2017, at 10:24 AM, David Kimura  wrote:
> 
> Err... I missed a return in example above.
> 
> Region r = [](){ return CacheFactory::create().getRegion("myregion"); } ();
> 
>> On Tue, Sep 19, 2017 at 10:19 AM, David Kimura  wrote:
>> 
>> I favor values, but we should probably be diligent.
>> 
>> Do any of the objects returned from Cache depend on Cache to out-live the
>> returned object?  A quick scan suggested no, but we still have a
>> std::enable_shared_from_this.  Maybe dead code.  In code example,
>> if this happens (for any cache.get*), could we be in trouble or is this
>> user error?
>> 
>> Region r = [](){ CacheFactory::create().getRegion("myregion"); }();
>> // Cache is out of scope.
>> // What is expected behavior?
>> r.put("key", "value");
>> 
>> Thanks,
>> David
>> 
>> On Mon, Sep 18, 2017 at 7:44 PM, Jacob Barrett 
>> wrote:
>> 
>>> 
>>> 
 On Sep 18, 2017, at 7:34 PM, Kirk Lund  wrote:
 
 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.
>>> 
>>> There really isn’t, especially if you look at what we did dirty
>>> CacheFactory::getCache by returning a value that can be moved into the heap
>>> and a shared point of one wants but not being forced into it. RVO tricks
>>> can event make that move a noop.
>>> 
>>> auto r = cache.getRegion(...);
>>> Where decltype(r) == Region
>>> and
>>> auto rp = std::make_shared(cache->getRegion());
>>> Where decltype(rp) == shared_ptr
>>> 
>>> Would both be valid.
>>> 
>>> 
>>> 
>> 

Re: Return types form methods on Cache

[David Kimura]

Oh, man. I hope I didn't just kill the original idea.  Unless we are
somehow using shared_from_this, it shouldn't be a divergence from existing
behavior?

Thanks,
David

On Tue, Sep 19, 2017 at 10:47 AM, Jacob Barrett  wrote:

> Region returned by this would no longer be valid. It’s “references” to
> interns cache/region would be invalid. The behavior is undefined.
>
> > On Sep 19, 2017, at 10:24 AM, David Kimura  wrote:
> >
> > Err... I missed a return in example above.
> >
> > Region r = [](){ return CacheFactory::create().getRegion("myregion"); }
> ();
> >
> >> On Tue, Sep 19, 2017 at 10:19 AM, David Kimura 
> wrote:
> >>
> >> I favor values, but we should probably be diligent.
> >>
> >> Do any of the objects returned from Cache depend on Cache to out-live
> the
> >> returned object?  A quick scan suggested no, but we still have a
> >> std::enable_shared_from_this.  Maybe dead code.  In code
> example,
> >> if this happens (for any cache.get*), could we be in trouble or is this
> >> user error?
> >>
> >> Region r = [](){ CacheFactory::create().getRegion("myregion"); }();
> >> // Cache is out of scope.
> >> // What is expected behavior?
> >> r.put("key", "value");
> >>
> >> Thanks,
> >> David
> >>
> >> On Mon, Sep 18, 2017 at 7:44 PM, Jacob Barrett 
> >> wrote:
> >>
> >>>
> >>>
>  On Sep 18, 2017, at 7:34 PM, Kirk Lund  wrote:
> 
>  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.
> >>>
> >>> There really isn’t, especially if you look at what we did dirty
> >>> CacheFactory::getCache by returning a value that can be moved into the
> heap
> >>> and a shared point of one wants but not being forced into it. RVO
> tricks
> >>> can event make that move a noop.
> >>>
> >>> auto r = cache.getRegion(...);
> >>> Where decltype(r) == Region
> >>> and
> >>> auto rp = std::make_shared(cache->getRegion());
> >>> Where decltype(rp) == shared_ptr
> >>>
> >>> Would both be valid.
> >>>
> >>>
> >>>
> >>
>

Re: Return types form methods on Cache

[Jacob Barrett]

It isn’t. A Region should not outlive cache.

> On Sep 19, 2017, at 10:54 AM, David Kimura  wrote:
> 
> Oh, man. I hope I didn't just kill the original idea.  Unless we are
> somehow using shared_from_this, it shouldn't be a divergence from existing
> behavior?
> 
> Thanks,
> David
> 
>> On Tue, Sep 19, 2017 at 10:47 AM, Jacob Barrett  wrote:
>> 
>> Region returned by this would no longer be valid. It’s “references” to
>> interns cache/region would be invalid. The behavior is undefined.
>> 
>>> On Sep 19, 2017, at 10:24 AM, David Kimura  wrote:
>>> 
>>> Err... I missed a return in example above.
>>> 
>>> Region r = [](){ return CacheFactory::create().getRegion("myregion"); }
>> ();
>>> 
 On Tue, Sep 19, 2017 at 10:19 AM, David Kimura 
>> wrote:
 
 I favor values, but we should probably be diligent.
 
 Do any of the objects returned from Cache depend on Cache to out-live
>> the
 returned object?  A quick scan suggested no, but we still have a
 std::enable_shared_from_this.  Maybe dead code.  In code
>> example,
 if this happens (for any cache.get*), could we be in trouble or is this
 user error?
 
 Region r = [](){ CacheFactory::create().getRegion("myregion"); }();
 // Cache is out of scope.
 // What is expected behavior?
 r.put("key", "value");
 
 Thanks,
 David
 
 On Mon, Sep 18, 2017 at 7:44 PM, Jacob Barrett 
 wrote:
 
> 
> 
>> On Sep 18, 2017, at 7:34 PM, Kirk Lund  wrote:
>> 
>> 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.
> 
> There really isn’t, especially if you look at what we did dirty
> CacheFactory::getCache by returning a value that can be moved into the
>> heap
> and a shared point of one wants but not being forced into it. RVO
>> tricks
> can event make that move a noop.
> 
> auto r = cache.getRegion(...);
> Where decltype(r) == Region
> and
> auto rp = std::make_shared(cache->getRegion());
> Where decltype(rp) == shared_ptr
> 
> Would both be valid.
> 
> 
> 
 
>> 

Re: Return types form methods on Cache

[David Kimura]

Cool. +1 value model.

Thanks,
David

On Tue, Sep 19, 2017 at 11:15 AM, Jacob Barrett  wrote:

> It isn’t. A Region should not outlive cache.
>
> > On Sep 19, 2017, at 10:54 AM, David Kimura  wrote:
> >
> > Oh, man. I hope I didn't just kill the original idea.  Unless we are
> > somehow using shared_from_this, it shouldn't be a divergence from
> existing
> > behavior?
> >
> > Thanks,
> > David
> >
> >> On Tue, Sep 19, 2017 at 10:47 AM, Jacob Barrett 
> wrote:
> >>
> >> Region returned by this would no longer be valid. It’s “references” to
> >> interns cache/region would be invalid. The behavior is undefined.
> >>
> >>> On Sep 19, 2017, at 10:24 AM, David Kimura  wrote:
> >>>
> >>> Err... I missed a return in example above.
> >>>
> >>> Region r = [](){ return CacheFactory::create().getRegion("myregion");
> }
> >> ();
> >>>
>  On Tue, Sep 19, 2017 at 10:19 AM, David Kimura 
> >> wrote:
> 
>  I favor values, but we should probably be diligent.
> 
>  Do any of the objects returned from Cache depend on Cache to out-live
> >> the
>  returned object?  A quick scan suggested no, but we still have a
>  std::enable_shared_from_this.  Maybe dead code.  In code
> >> example,
>  if this happens (for any cache.get*), could we be in trouble or is
> this
>  user error?
> 
>  Region r = [](){ CacheFactory::create().getRegion("myregion"); }();
>  // Cache is out of scope.
>  // What is expected behavior?
>  r.put("key", "value");
> 
>  Thanks,
>  David
> 
>  On Mon, Sep 18, 2017 at 7:44 PM, Jacob Barrett 
>  wrote:
> 
> >
> >
> >> On Sep 18, 2017, at 7:34 PM, Kirk Lund  wrote:
> >>
> >> 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.
> >
> > There really isn’t, especially if you look at what we did dirty
> > CacheFactory::getCache by returning a value that can be moved into
> the
> >> heap
> > and a shared point of one wants but not being forced into it. RVO
> >> tricks
> > can event make that move a noop.
> >
> > auto r = cache.getRegion(...);
> > Where decltype(r) == Region
> > and
> > auto rp = std::make_shared(cache->getRegion());
> > Where decltype(rp) == shared_ptr
> >
> > Would both be valid.
> >
> >
> >
> 
> >>
>

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

[Dave Barnes]

There's no single list of "all properties". Here's one that Tech Pubs last
reviewed about 6 months ago...

https://docs.google.com/spreadsheets/d/1C2D7cpcYMy5bd0aXXReJn6wWsBuLZrCegl7_cevvKo0/edit#gid=0


On Thu, Sep 14, 2017 at 12:06 PM, Bruce Schuchardt 
wrote:

> There are plenty of places besides DistributionConfig that use "gemfire"
> prefixed system properties and there are now also places that use "geode"
> prefixed system properties.  I think the whole mess needs to be managed and
> allow either prefix, or even as someone suggested making it plug-able.
> There is also an HTML file that, now out of date, lists most of these
> system properties.
>
>
>
> On 9/14/17 10:14 AM, Darrel Schneider wrote:
>
>> +1 to having DistributionConfig look for both the "gemfire." and "geode."
>> prefixes.
>> +1 to having DistributionConfig look for both a "gemfire.properties" and
>> "geode.properties" file.
>> Since the geode flavors are newer it should look for them first and only
>> look for the old gemfire flavor if a geode one is not found.
>>
>> On Thu, Sep 14, 2017 at 9:35 AM, Kirk Lund  wrote:
>>
>> 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 Barnes  wrote:

 Is there a possibility that the code might find its way into additional
> contexts with other names? If so, perhaps we should consider a more
>
 generic

> identifier, such as PRODUCT_PREFIX.
>
> On Thu, Sep 14, 2017 at 4:42 AM, Dinesh Akhand 
> wrote:
>
> Hi,
>>
>> Why we are keeping gemfire in current geode 1.2 , Can we replace this
>>
> with
>
>> GEODE
>> File : DistributionConfig.java
>>
>> Current code:
>>String GEMFIRE_PREFIX = "gemfire.";
>>
>> Suggestion to change:
>>   String GEODE_PREFIX = "geode.";
>>
>> Why do you think ?
>> Can we go ahead  and change this ?
>> It will impact lots of files & all configuration will be now using
>>
> with
>>>
 geode.
>>
>> Thanks,
>> Dinesh Akhand
>> This message and the information contained herein is proprietary and
>> confidential and subject to the Amdocs policy statement,
>>
>> you may review at https://www.amdocs.com/about/email-disclaimer <
>> https://www.amdocs.com/about/email-disclaimer>
>>
>>
>

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

[Dave Barnes]

Here's an updated link to the properties spreadsheet that should have wider
viewability:

https://docs.google.com/spreadsheets/d/1C2D7cpcYMy5bd0aXXReJn6wWsBuLZrCegl7_cevvKo0/edit?usp=sharing

On Tue, Sep 19, 2017 at 12:10 PM, Dave Barnes  wrote:

> There's no single list of "all properties". Here's one that Tech Pubs last
> reviewed about 6 months ago...
>
> https://docs.google.com/spreadsheets/d/1C2D7cpcYMy5bd0aXXReJn6wWsBuLZ
> rCegl7_cevvKo0/edit#gid=0
>
>
> On Thu, Sep 14, 2017 at 12:06 PM, Bruce Schuchardt  > wrote:
>
>> There are plenty of places besides DistributionConfig that use "gemfire"
>> prefixed system properties and there are now also places that use "geode"
>> prefixed system properties.  I think the whole mess needs to be managed and
>> allow either prefix, or even as someone suggested making it plug-able.
>> There is also an HTML file that, now out of date, lists most of these
>> system properties.
>>
>>
>>
>> On 9/14/17 10:14 AM, Darrel Schneider wrote:
>>
>>> +1 to having DistributionConfig look for both the "gemfire." and "geode."
>>> prefixes.
>>> +1 to having DistributionConfig look for both a "gemfire.properties" and
>>> "geode.properties" file.
>>> Since the geode flavors are newer it should look for them first and only
>>> look for the old gemfire flavor if a geode one is not found.
>>>
>>> On Thu, Sep 14, 2017 at 9:35 AM, Kirk Lund  wrote:
>>>
>>> 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 Barnes 
> wrote:
>
> Is there a possibility that the code might find its way into additional
>> contexts with other names? If so, perhaps we should consider a more
>>
> generic
>
>> identifier, such as PRODUCT_PREFIX.
>>
>> On Thu, Sep 14, 2017 at 4:42 AM, Dinesh Akhand 
>> wrote:
>>
>> Hi,
>>>
>>> Why we are keeping gemfire in current geode 1.2 , Can we replace this
>>>
>> with
>>
>>> GEODE
>>> File : DistributionConfig.java
>>>
>>> Current code:
>>>String GEMFIRE_PREFIX = "gemfire.";
>>>
>>> Suggestion to change:
>>>   String GEODE_PREFIX = "geode.";
>>>
>>> Why do you think ?
>>> Can we go ahead  and change this ?
>>> It will impact lots of files & all configuration will be now using
>>>
>> with

> geode.
>>>
>>> Thanks,
>>> Dinesh Akhand
>>> This message and the information contained herein is proprietary and
>>> confidential and subject to the Amdocs policy statement,
>>>
>>> you may review at https://www.amdocs.com/about/email-disclaimer <
>>> https://www.amdocs.com/about/email-disclaimer>
>>>
>>>
>>
>

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

[Swapnil Bawaskar]

In the interest of keeping the re-branding tasks together, I took the
liberty to made GEODE-3617 a subtask of
https://issues.apache.org/jira/browse/GEODE-1466.

On Tue, Sep 19, 2017 at 2:05 PM Dave Barnes  wrote:

> Here's an updated link to the properties spreadsheet that should have wider
> viewability:
>
>
> https://docs.google.com/spreadsheets/d/1C2D7cpcYMy5bd0aXXReJn6wWsBuLZrCegl7_cevvKo0/edit?usp=sharing
>
> On Tue, Sep 19, 2017 at 12:10 PM, Dave Barnes  wrote:
>
> > There's no single list of "all properties". Here's one that Tech Pubs
> last
> > reviewed about 6 months ago...
> >
> > https://docs.google.com/spreadsheets/d/1C2D7cpcYMy5bd0aXXReJn6wWsBuLZ
> > rCegl7_cevvKo0/edit#gid=0
> >
> >
> > On Thu, Sep 14, 2017 at 12:06 PM, Bruce Schuchardt <
> bschucha...@pivotal.io
> > > wrote:
> >
> >> There are plenty of places besides DistributionConfig that use "gemfire"
> >> prefixed system properties and there are now also places that use
> "geode"
> >> prefixed system properties.  I think the whole mess needs to be managed
> and
> >> allow either prefix, or even as someone suggested making it plug-able.
> >> There is also an HTML file that, now out of date, lists most of these
> >> system properties.
> >>
> >>
> >>
> >> On 9/14/17 10:14 AM, Darrel Schneider wrote:
> >>
> >>> +1 to having DistributionConfig look for both the "gemfire." and
> "geode."
> >>> prefixes.
> >>> +1 to having DistributionConfig look for both a "gemfire.properties"
> and
> >>> "geode.properties" file.
> >>> Since the geode flavors are newer it should look for them first and
> only
> >>> look for the old gemfire flavor if a geode one is not found.
> >>>
> >>> On Thu, Sep 14, 2017 at 9:35 AM, Kirk Lund  wrote:
> >>>
> >>> 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 Barnes 
> > wrote:
> >
> > Is there a possibility that the code might find its way into
> additional
> >> contexts with other names? If so, perhaps we should consider a more
> >>
> > generic
> >
> >> identifier, such as PRODUCT_PREFIX.
> >>
> >> On Thu, Sep 14, 2017 at 4:42 AM, Dinesh Akhand  >
> >> wrote:
> >>
> >> Hi,
> >>>
> >>> Why we are keeping gemfire in current geode 1.2 , Can we replace
> this
> >>>
> >> with
> >>
> >>> GEODE
> >>> File : DistributionConfig.java
> >>>
> >>> Current code:
> >>>String GEMFIRE_PREFIX = "gemfire.";
> >>>
> >>> Suggestion to change:
> >>>   String GEODE_PREFIX = "geode.";
> >>>
> >>> Why do you think ?
> >>> Can we go ahead  and change this ?
> >>> It will impact lots of files & all configuration will be now using
> >>>
> >> with
> 
> > geode.
> >>>
> >>> Thanks,
> >>> Dinesh Akhand
> >>> This message and the information contained herein is proprietary
> and
> >>> confidential and subject to the Amdocs policy statement,
> >>>
> >>> you may review at https://www.amdocs.com/about/email-disclaimer <
> >>> https://www.amdocs.com/about/email-disclaimer>
> >>>
> >>>
> >>
> >
>

Passed: apache/geode#3910 (develop - 8211f2f)

[Travis CI]

Build Update for apache/geode
-

Build: #3910
Status: Passed

Duration: 13 minutes and 17 seconds
Commit: 8211f2f (develop)
Author: galen-pivotal
Message: GEODE-3609 Small AcceptorImpl refactor (#772)

Use one CommunicationMode variable, not 3.

Also, refactor the selector and not-selector cases into separate
methods.

I'm not changing the `ServerConnectionFactory` because it more or less
passes straight through to `ServerConnection`, and there's too much
legacy code there to change easily.

View the changeset: 
https://github.com/apache/geode/compare/637a685ddb89...8211f2fd26fa

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/277409797?utm_source=email&utm_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #683 was successful.
---
Scheduled
2044 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Build failed in Jenkins: Geode-nightly #959

[Apache Jenkins Server]

See 


Changes:

[nreich] GEODE-3180: Fix flaky test

[huynhja] GEODE-3578: Only DATA:READ permissions are required for 
creating/closing

[kohlmu-pivotal] GEODE-3623 Clean up

[jstewart] GEODE-3426: Ignore RestServersJUnitTest when default port is

[klund] GEODE-3553: Fix @since tag value

[klund] GEODE-3545: rename and cleanup QueryDataFunctionIntegrationTest

[lhughesgodfrey] GEODE-3636: Fixing hang shutting down gateway sender with SSL

[dschneider] GEODE-3619: fix diskTasksWaiting statistic

[dschneider] spotless

[dschneider] GEODE-2719: Deprecated setTotalMaxMemory and getTotalMaxMemory and

[dschneider] GEODE-2719: corrected GEODE versions to 1.3.0 instead of 1.2.2 for 
the

--
[...truncated 385.35 KB...]
java.net.ConnectException: connect() failed: Permission denied: 
/var/run/docker.sock
at io.netty.channel.unix.Errors.throwConnectException(Errors.java:99)
at io.netty.channel.unix.Socket.connect(Socket.java:208)
at 
io.netty.channel.epoll.AbstractEpollStreamChannel.doConnect(AbstractEpollStreamChannel.java:719)
at 
io.netty.channel.epoll.EpollDomainSocketChannel.doConnect(EpollDomainSocketChannel.java:98)
at 
io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.connect(AbstractEpollStreamChannel.java:783)
at 
io.netty.channel.DefaultChannelPipeline$HeadContext.connect(DefaultChannelPipeline.java:1266)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeConnect(AbstractChannelHandlerContext.java:555)
at 
io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:540)
at 
io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.connect(CombinedChannelDuplexHandler.java:494)
at 
io.netty.channel.ChannelOutboundHandlerAdapter.connect(ChannelOutboundHandlerAdapter.java:47)
at 
io.netty.channel.CombinedChannelDuplexHandler.connect(CombinedChannelDuplexHandler.java:295)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeConnect(AbstractChannelHandlerContext.java:555)
at 
io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:540)
at 
io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:522)
at 
io.netty.channel.DefaultChannelPipeline.connect(DefaultChannelPipeline.java:985)
at io.netty.channel.AbstractChannel.connect(AbstractChannel.java:255)
at io.netty.bootstrap.Bootstrap$3.run(Bootstrap.java:252)
at 
io.netty.util.concurrent.SingleThreadEventExecutor.safeExecute(SingleThreadEventExecutor.java:451)
at 
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:418)
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:306)
at 
io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:877)
at 
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
at java.lang.Thread.run(Thread.java:748)
Cannot abort process 'Gradle Test Executor 197' because it is not in started or 
detached state
java.lang.IllegalStateException: Cannot abort process 'Gradle Test Executor 
197' because it is not in started or detached state
at 
com.pedjak.gradle.plugins.dockerizedtest.DockerizedExecHandle.abort(DockerizedExecHandle.java:334)
at org.gradle.process.internal.ExecHandle$abort$3.call(Unknown Source)
at 
com.pedjak.gradle.plugins.dockerizedtest.ExitCodeTolerantExecHandle.abort(ExitCodeTolerantExecHandle.groovy:33)
at 
org.gradle.process.internal.worker.DefaultWorkerProcess.cleanup(DefaultWorkerProcess.java:198)
at 
org.gradle.process.internal.worker.DefaultWorkerProcess.start(DefaultWorkerProcess.java:145)
at 
org.gradle.process.internal.worker.DefaultWorkerProcessBuilder$MemoryRequestingWorkerProcess.start(DefaultWorkerProcessBuilder.java:218)
at 
com.pedjak.gradle.plugins.dockerizedtest.ForkingTestClassProcessor.forkProcess(ForkingTestClassProcessor.java:80)
at 
com.pedjak.gradle.plugins.dockerizedtest.ForkingTestClassProcessor.processTestClass(ForkingTestClassProcessor.java:56)
at 
org.gradle.api.internal.tasks.testing.processors.RestartEveryNTestClassProcessor.processTestClass(RestartEveryNTestClassProcessor.java:47)
at sun.reflect.GeneratedMethodAccessor582.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.dispatch.Failur

Build failed in Jenkins: Geode-nightly-flaky #126

[Apache Jenkins Server]

See 


Changes:

[nreich] GEODE-3180: Fix flaky test

[huynhja] GEODE-3578: Only DATA:READ permissions are required for 
creating/closing

[kohlmu-pivotal] GEODE-3623 Clean up

[jstewart] GEODE-3426: Ignore RestServersJUnitTest when default port is

[klund] GEODE-3553: Fix @since tag value

[klund] GEODE-3545: rename and cleanup QueryDataFunctionIntegrationTest

[lhughesgodfrey] GEODE-3636: Fixing hang shutting down gateway sender with SSL

[dschneider] GEODE-3619: fix diskTasksWaiting statistic

[dschneider] spotless

[dschneider] GEODE-2719: Deprecated setTotalMaxMemory and getTotalMaxMemory and

[dschneider] GEODE-2719: corrected GEODE versions to 1.3.0 instead of 1.2.2 for 
the

[github] GEODE-2818 Document gfsh aliases (#775)

[dschneider] GEODE-3626: Fix relative path support for snapshots

[gosullivan] GEODE-3548 Add logging to new protocol code

[github] GEODE-3609 Small AcceptorImpl refactor (#772)

[gosullivan] GEODE-3083: Fix geode-protobuf stats. - Enhance and rename test of 
basic

--
[...truncated 111.44 KB...]
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-metadata/1.2.0.RELEASE/spring-plugin-metadata-1.2.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct/1.0.0.Final/mapstruct-1.0.0.Final.jar
Download 
https://repo1.maven.org/maven2/com/thoughtworks/paranamer/paranamer/2.8/paranamer-2.8.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-core/2.6.1/springfox-core-2.6.1.jar
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:geode-web-api:processResources
:geode-web-api:classes
:geode-assembly:docs:101:
 warning - Tag @link: reference not found: BasicTypes.Entry

1 warning
:geode-assembly:gfshDepsJar
:geode-common:javadocJar
:geode-common:sourcesJar
:geode-common:signArchives SKIPPED
:geode-core:javadocJar
:geode-core:raJar
:geode-core:jcaJar
:geode-core:sourcesJar
:geode-core:signArchives SKIPPED
:geode-core:webJar
:geode-cq:jar
:geode-cq:javadoc
:geode-cq:javadocJar
:geode-cq:sourcesJar
:geode-cq:signArchives SKIPPED
:geode-json:javadocJar
:geode-json:sourcesJar
:geode-json:signArchives SKIPPED
:geode-lucene:jar
:geode-lucene:javadoc
:geode-lucene:javadocJar
:geode-lucene:sourcesJar
:geode-lucene:signArchives SKIPPED
:geode-old-client-support:jar
:geode-old-client-support:javadoc
:geode-old-client-support:javadocJar
:geode-old-client-support:sourcesJar
:geode-old-client-support:signArchives SKIPPED
:geode-protobuf:jar
:geode-protobuf:javadoc:101:
 warning - Tag @link: reference not found: BasicTypes.Entry

1 warning
:geode-protobuf:javadocJar
:geode-protobuf:sourcesJar
:geode-protobuf:signArchives SKIPPED
:geode-pulse:javadoc
:geode-pulse:javadocJar
:geode-pulse:sourcesJar
:geode-pulse:war
:geode-pulse:signArchives SKIPPED
:geode-rebalancer:jar
:geode-rebalancer:javadoc
:geode-rebalancer:javadocJar
:geode-rebalancer:sourcesJar
:geode-rebalancer:signArchives SKIPPED
:geode-wan:jar
:geode-wan:javadoc
:geode-wan:javadocJar
:geode-wan:sourcesJar
:geode-wan:signArchives SKIPPED
:geode-web:javadoc NO-SOURCE
:geode-web:javadocJar
:geode-web:sourcesJar
:geode-web:war
:geode-web:signArchives SKIPPED
:geode-web-api:javadoc
:geode-web-api:javadocJar
:geode-web-api:sourcesJar
:geode-web-api:war
:geode-web-api:signArchives SKIPPED
:geode-assembly:installDist
:geode-pulse:jar
:geode-assembly:compileTestJava
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core-uberjar/1.6.3/cargo-core-uberjar-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core/1.6.3/cargo-core-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/codehaus-cargo/1.6.3/codehaus-cargo-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core-uberjar/1.6.3/cargo-core-uberjar-1.6.3.jar
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:geode-assembly:processTestResources
:geode-assembly:testClasses
:geode-assembly:flakyTest
:geode-benchmarks:compileTestJava NO-SOURCE
:geode-benchmarks:processTestResources NO-SOURCE
:geode-benchmarks:testClasses UP-TO-DATE
:geode-benchmarks:flakyTest NO-SOURCE
:geode-common:compileTestJava
:geode-common:processTestResources NO-SOURCE
:geode-common:testClasses
:geode-common:flakyTest
:geode-core:flakyTest

org.apache.geode.management.RegionManagementDUnitTest > testNavigationAPIS 
FAILED
org.apache.geod