Re: Review Request 44242: GEODE-1025: Replacing direct dependency on spring data gemfire with an SPI

2016-03-01 Thread John Blum 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44242/#review121586
---




geode-core/src/main/java/com/gemstone/gemfire/distributed/ServerLauncher.java 
(line 716)


The assignment to the ServerLauncher.cache instance variable should be done 
here, outside of the createCache(:Properties) method.

This both simplifies (unit) testing as well as subclassing, especially 
since the createCache(..) method is part of the ServerLauncher API.



geode-core/src/main/java/com/gemstone/gemfire/distributed/ServerLauncher.java 
(line 787)


Ideally, the cache creation logic of this method should be consistent, i.e. 
always by way of Service Provider.

In that case, even Geode could provide a "default" implementation based on 
the logic in "startWithGemFireApi(:Properties") rather than the 
createCache(:Properties) method delegating to this method directly.  So, 
replace the startWithGemFireApi(:Properties) with a, for example, 
GeodeApiServerLauncherCacheProvider.

However, you would need additional logic to determine provider precedence, 
which could be based (partially) on which options the user selected in Gfsh 
when calling 'start server' (e.g. gfsh>start server --name=Example 
--spring-xml-location=..., thus use the 
SpringDataGemFireServerLauncherCacheProvider, or gfsh>start server 
--name=AnotherExample --cache-xml-file=..., so use the 
GeodeApiServerLauncherCacheProvider).



geode-core/src/main/java/com/gemstone/gemfire/distributed/ServerLauncher.java 
(line 792)


The "provided" cache instance should be returned rather than assigned to 
the ServerLauncher's state for subclassing/testing purposes.



geode-core/src/main/java/com/gemstone/gemfire/distributed/ServerLauncherCacheProvider.java
 (line 32)


Probably, we can simplify this interface to...

Cache createCache(ServerLauncher serverLauncher);

Since getProperties() as well as 
getDistributedSystemProperties(:Properties) methods are both public, along with 
other public methods, we can access everything we need from the ServerLauncher 
API itself.



geode-core/src/test/java/com/gemstone/gemfire/distributed/MockServerLauncherCacheProvider.java
 (line 36)


Remove unecessary default constructor, especially since it only contains a 
TODO and no actual initialization logic.


- John Blum


On March 2, 2016, 12:57 a.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44242/
> ---
> 
> (Updated March 2, 2016, 12:57 a.m.)
> 
> 
> Review request for geode, Jason Huynh, Jens Deppe, and John Blum.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Removing the direct use of Spring Data Gemfire from within the geode
> code. Replacing it with a SPI that allows the user to override the
> behavior of ServerLauncher.start with their own implementation that
> creates a cache.
> 
> Spring Data Gemfire can provide an implementation that bootstraps the
> cache using spring, if spring-xml-location is specified.
> 
> Users should implement ServerLauncherCacheProvider. The cache will be
> created by the first provider that returns a non null cache. If no
> providers create a cache, the cache will be created by the
> ServerLauncher itself.
> 
> It would be nice to move the spring-xml-location parameter itself into
> the interface, but this is hard to do because gfsh determines the
> parameters to start-server by looking at the arguments in the command
> class. So I left spring-xml-location alone.
> 
> Removing the spring data jar from the compile time dependencies. I've
> moved it to the geode-assembly project, so it is still shipped for the
> moment.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle 14febbdd6b7dd3c05f5c0aa12d86aa7cb7beccd1 
>   geode-core/build.gradle 1aa07eea733204386713e92fe7127c5303cb0d84 
>   
> geode-core/src/main/java/com/gemstone/gemfire/distributed/ServerLauncher.java 
> 4f43370d837542daeb99962cd419fdce937ca5ed 
>   
> geode-core/src/main/java/com/gemstone/gemfire/distributed/ServerLauncherCacheProvider.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/distributed/LauncherTestSuite.java
>  73a23374b82f998780ae8c757d869446dcfaca71 
>   
> geode-core/src/test/java/com/gemstone/gemfire/distributed/MockServerLauncherCacheProvider.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/distributed/ServerLauncherWithSpringJUnitTest.java
>

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #237 was SUCCESSFUL (with 1263 tests). Change made by Dan Smith <upthewatersp...@apache.org> and John Blum <jb...@pivotal.io>.

2016-03-01 Thread Spring CI 

---
Spring Data GemFire > Nightly-ApacheGeode > #237 was successful.
---
Scheduled with changes by Dan Smith , John Blum 
.
1267 tests in total.

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




--
Code Changes
--
John Blum  (a0c8950e1fc4e796448663aa4ad7f75cb56977c8):

>SGF-475 - Add additional logging to the MappingPdxSerializer.
>(cherry picked from commit 6dfd3e7082628f4c05da951ff760861ebb242899)
>Signed-off-by: John Blum 

Dan Smith  
(d1e6b7be5fa6cc18156b97f858ff7cc382041cec):

>SGF-477 - Change compile dependency from gemfire-core to geode-core.



--
This message is automatically generated by Atlassian Bamboo

Review Request 44242: GEODE-1025: Replacing direct dependency on spring data gemfire with an SPI

2016-03-01 Thread Dan Smith 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44242/
---

Review request for geode, Jason Huynh, Jens Deppe, and John Blum.


Repository: geode


Description
---

Removing the direct use of Spring Data Gemfire from within the geode
code. Replacing it with a SPI that allows the user to override the
behavior of ServerLauncher.start with their own implementation that
creates a cache.

Spring Data Gemfire can provide an implementation that bootstraps the
cache using spring, if spring-xml-location is specified.

Users should implement ServerLauncherCacheProvider. The cache will be
created by the first provider that returns a non null cache. If no
providers create a cache, the cache will be created by the
ServerLauncher itself.

It would be nice to move the spring-xml-location parameter itself into
the interface, but this is hard to do because gfsh determines the
parameters to start-server by looking at the arguments in the command
class. So I left spring-xml-location alone.

Removing the spring data jar from the compile time dependencies. I've
moved it to the geode-assembly project, so it is still shipped for the
moment.


Diffs
-

  geode-assembly/build.gradle 14febbdd6b7dd3c05f5c0aa12d86aa7cb7beccd1 
  geode-core/build.gradle 1aa07eea733204386713e92fe7127c5303cb0d84 
  geode-core/src/main/java/com/gemstone/gemfire/distributed/ServerLauncher.java 
4f43370d837542daeb99962cd419fdce937ca5ed 
  
geode-core/src/main/java/com/gemstone/gemfire/distributed/ServerLauncherCacheProvider.java
 PRE-CREATION 
  
geode-core/src/test/java/com/gemstone/gemfire/distributed/LauncherTestSuite.java
 73a23374b82f998780ae8c757d869446dcfaca71 
  
geode-core/src/test/java/com/gemstone/gemfire/distributed/MockServerLauncherCacheProvider.java
 PRE-CREATION 
  
geode-core/src/test/java/com/gemstone/gemfire/distributed/ServerLauncherWithSpringJUnitTest.java
 bf82af8268f0b35c6ed15b26783ef37c9c329c10 
  
geode-core/src/test/resources/META-INF/services/com.gemstone.gemfire.distributed.ServerLauncherCacheProvider
 PRE-CREATION 
  geode-core/src/test/resources/spring/spring-gemfire-context.xml 
a728493be7ee2a960dc3c9e5e8c449686d6b09cd 
  gradle/rat.gradle 68e04c498166d14301d1a257d6097b3b7bf8a029 

Diff: https://reviews.apache.org/r/44242/diff/


Testing
---


Thanks,

Dan Smith

Fixed: apache/incubator-geode#43 (feature/GEODE-949-2 - f9b621d)

2016-03-01 Thread Travis CI 
Build Update for apache/incubator-geode
-

Build: #43
Status: Fixed

Duration: 15 minutes and 6 seconds
Commit: f9b621d (feature/GEODE-949-2)
Author: Kirk Lund
Message: Fix up serialization of exceptions

View the changeset: 
https://github.com/apache/incubator-geode/compare/6ac8fb492f7b...f9b621dc06d9

View the full build log and details: 
https://travis-ci.org/apache/incubator-geode/builds/113003267

--

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

Re: Review Request 44233: GEODE-1029 fixed test issue, where system is not working properly.

2016-03-01 Thread Jianxia Chen 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44233/#review121545
---



I am just curious. Why the test didn't fail previously? Only until recently?

- Jianxia Chen


On March 1, 2016, 10:29 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44233/
> ---
> 
> (Updated March 1, 2016, 10:29 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Darrel Schneider, Jianxia Chen, 
> and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1029 fixed test issue, where system is not working properly.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/CachedDeserializableFactory.java
>  9120e37 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache30/DistributedMulticastRegionDUnitTest.java
>  72b7941 
> 
> Diff: https://reviews.apache.org/r/44233/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hitesh Khamesra
> 
>

Re: Scope for M2 release

2016-03-01 Thread Anthony Baker 
(thumbs up emoji)

> On Mar 1, 2016, at 3:12 PM, Nitin Lamba  wrote:
> 
> Please try the link again...
> 
> 
> From: Nitin Lamba 
> Sent: Tuesday, March 1, 2016 3:07 PM
> To: dev@geode.incubator.apache.org
> Subject: Re: Scope for M2 release
> 
> My bad - let me fix the filter and make it public.
> 
> 
> From: Anthony Baker 
> Sent: Tuesday, March 1, 2016 2:34 PM
> To: dev@geode.incubator.apache.org
> Subject: Re: Scope for M2 release
> 
> Great idea Nitin!  I don’t think we have permissions to see it though:
> 
>JIRA Issues Macro: JIRA project does not exist or you do not have 
> permission to view it.
> 
> Anthony
> 
> 
>> On Mar 1, 2016, at 1:51 PM, Nitin Lamba  wrote:
>> 
>> OK, I've added a couple of JIRA filters to extract all issues loaded in our 
>> M2 sprint. This helps create a data-driven table of issues on the wiki page 
>> [1] instead of manually sync-ing it. Ideally, we should start this 
>> (scope-defined) sprint and close it when M2 is released. Thoughts?
>> 
>> Please check it out and suggest if any specific attributes should be 
>> displayed or if the inclusion/ exclusion criteria should be changed.
>> 
>> Nitin
>> [1] 
>> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
>> 
>> 
>> From: Nitin Lamba 
>> Sent: Tuesday, March 1, 2016 1:17 PM
>> To: dev@geode.incubator.apache.org
>> Subject: Re: Scope for M2 release
>> 
>> +1
>> 
>> I had recently updated the wiki page for completed JIRAs. Ideally, we should 
>> just have one place to update.
>> 
>> Let me quickly research if there's a way to integrate the lists.
>> 
>> Nitin
>> 
>> From: Kirk Lund 
>> Sent: Tuesday, March 1, 2016 11:33 AM
>> To: dev@geode.incubator.apache.org
>> Subject: Re: Scope for M2 release
>> 
>> +1
>> 
>> On Tuesday, March 1, 2016, Anthony Baker  wrote:
>> 
>>> I was discussing the M2 release scope and noticed that the wiki page [1]
>>> differs slightly from the JIRA Geode-Release filter [2] and roadmap [3],
>>> 
>>> Should we update the wiki page to match JIRA based on the prior email
>>> thread [4]?
>>> 
>>> Anthony
>>> 
>>> [1]
>>> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
>>> [2]
>>> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92=planning.nodetail=GEODE-914
>>> [3]
>>> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
>>> [4]
>>> http://mail-archives.apache.org/mod_mbox/geode-dev/201602.mbox/%3ccafh+7k1vf2j8fhj98zqewakhfmid+ssdqjmgdqtdowfbhwt...@mail.gmail.com%3E



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Scope for M2 release

2016-03-01 Thread Nitin Lamba 
Please try the link again...


From: Nitin Lamba 
Sent: Tuesday, March 1, 2016 3:07 PM
To: dev@geode.incubator.apache.org
Subject: Re: Scope for M2 release

My bad - let me fix the filter and make it public.


From: Anthony Baker 
Sent: Tuesday, March 1, 2016 2:34 PM
To: dev@geode.incubator.apache.org
Subject: Re: Scope for M2 release

Great idea Nitin!  I don’t think we have permissions to see it though:

JIRA Issues Macro: JIRA project does not exist or you do not have 
permission to view it.

Anthony


> On Mar 1, 2016, at 1:51 PM, Nitin Lamba  wrote:
>
> OK, I've added a couple of JIRA filters to extract all issues loaded in our 
> M2 sprint. This helps create a data-driven table of issues on the wiki page 
> [1] instead of manually sync-ing it. Ideally, we should start this 
> (scope-defined) sprint and close it when M2 is released. Thoughts?
>
> Please check it out and suggest if any specific attributes should be 
> displayed or if the inclusion/ exclusion criteria should be changed.
>
> Nitin
> [1] 
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
>
> 
> From: Nitin Lamba 
> Sent: Tuesday, March 1, 2016 1:17 PM
> To: dev@geode.incubator.apache.org
> Subject: Re: Scope for M2 release
>
> +1
>
> I had recently updated the wiki page for completed JIRAs. Ideally, we should 
> just have one place to update.
>
> Let me quickly research if there's a way to integrate the lists.
>
> Nitin
> 
> From: Kirk Lund 
> Sent: Tuesday, March 1, 2016 11:33 AM
> To: dev@geode.incubator.apache.org
> Subject: Re: Scope for M2 release
>
> +1
>
> On Tuesday, March 1, 2016, Anthony Baker  wrote:
>
>> I was discussing the M2 release scope and noticed that the wiki page [1]
>> differs slightly from the JIRA Geode-Release filter [2] and roadmap [3],
>>
>> Should we update the wiki page to match JIRA based on the prior email
>> thread [4]?
>>
>> Anthony
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
>> [2]
>> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92=planning.nodetail=GEODE-914
>> [3]
>> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
>> [4]
>> http://mail-archives.apache.org/mod_mbox/geode-dev/201602.mbox/%3ccafh+7k1vf2j8fhj98zqewakhfmid+ssdqjmgdqtdowfbhwt...@mail.gmail.com%3E

Re: Scope for M2 release

2016-03-01 Thread Nitin Lamba 
My bad - let me fix the filter and make it public.


From: Anthony Baker 
Sent: Tuesday, March 1, 2016 2:34 PM
To: dev@geode.incubator.apache.org
Subject: Re: Scope for M2 release

Great idea Nitin!  I don’t think we have permissions to see it though:

JIRA Issues Macro: JIRA project does not exist or you do not have 
permission to view it.

Anthony


> On Mar 1, 2016, at 1:51 PM, Nitin Lamba  wrote:
>
> OK, I've added a couple of JIRA filters to extract all issues loaded in our 
> M2 sprint. This helps create a data-driven table of issues on the wiki page 
> [1] instead of manually sync-ing it. Ideally, we should start this 
> (scope-defined) sprint and close it when M2 is released. Thoughts?
>
> Please check it out and suggest if any specific attributes should be 
> displayed or if the inclusion/ exclusion criteria should be changed.
>
> Nitin
> [1] 
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
>
> 
> From: Nitin Lamba 
> Sent: Tuesday, March 1, 2016 1:17 PM
> To: dev@geode.incubator.apache.org
> Subject: Re: Scope for M2 release
>
> +1
>
> I had recently updated the wiki page for completed JIRAs. Ideally, we should 
> just have one place to update.
>
> Let me quickly research if there's a way to integrate the lists.
>
> Nitin
> 
> From: Kirk Lund 
> Sent: Tuesday, March 1, 2016 11:33 AM
> To: dev@geode.incubator.apache.org
> Subject: Re: Scope for M2 release
>
> +1
>
> On Tuesday, March 1, 2016, Anthony Baker  wrote:
>
>> I was discussing the M2 release scope and noticed that the wiki page [1]
>> differs slightly from the JIRA Geode-Release filter [2] and roadmap [3],
>>
>> Should we update the wiki page to match JIRA based on the prior email
>> thread [4]?
>>
>> Anthony
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
>> [2]
>> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92=planning.nodetail=GEODE-914
>> [3]
>> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
>> [4]
>> http://mail-archives.apache.org/mod_mbox/geode-dev/201602.mbox/%3ccafh+7k1vf2j8fhj98zqewakhfmid+ssdqjmgdqtdowfbhwt...@mail.gmail.com%3E

Re: Review Request 44035: GEODE-1014: PdxSerializationException Error when putall an object from native client withSecurity enabled

2016-03-01 Thread Udo Kohlmeyer 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44035/#review121534
---


Ship it!




Ship It!

- Udo Kohlmeyer


On March 1, 2016, 12:01 a.m., Jianxia Chen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44035/
> ---
> 
> (Updated March 1, 2016, 12:01 a.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Darrel Schneider, Hitesh 
> Khamesra, and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Avoid calling PutAllOperationContext.UpdateOnlyMap.exportValue when the map 
> entry is ExportableEntry. Because calling exportValue will result in 
> unnecessary deserialization in this case. For this case, 
> LocalRegion.verifyPutAllMap only need check whether the key or value is null. 
> No deserialization is required for PutAll map verification.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/PutAllOperationContext.java
>  b05216b 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/internal/UpdateOnlyMap.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/command/PutAll.java
>  5d2f5ca 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/command/PutAll70.java
>  7507299 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/command/PutAll80.java
>  6a2b072 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/ClientAuthorizationDUnitTest.java
>  0e46da5 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/SecurityTestUtil.java 
> ad9b3e1 
>   
> geode-core/src/test/resources/com/gemstone/gemfire/codeAnalysis/excludedClasses.txt
>  2097878 
> 
> Diff: https://reviews.apache.org/r/44035/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jianxia Chen
> 
>

Failed: apache/incubator-geode#42 (feature/GEODE-17-2 - 406a80f)

2016-03-01 Thread Travis CI 
Build Update for apache/incubator-geode
-

Build: #42
Status: Failed

Duration: 19 minutes and 18 seconds
Commit: 406a80f (feature/GEODE-17-2)
Author: Jens Deppe
Message: GEODE-17: Initial integration work

- Fix failing tests

View the changeset: 
https://github.com/apache/incubator-geode/compare/19a8f0a71c41^...406a80f8060f

View the full build log and details: 
https://travis-ci.org/apache/incubator-geode/builds/112983705

--

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

Re: Valid characters in Region names

2016-03-01 Thread William Markito 
That would be changed from now on as it's too much open ended and
troublesome to support in other subsystems such as JMX beans... Note that
"-" is still in the list, other symbols would not be allowed like "+" or
"@" - Which are very odd and should be very rare.

On Tue, Mar 1, 2016 at 2:52 PM, Anilkumar Gingade 
wrote:

> From the existing javadoc it looks like, application can have any chars in
> region name except the "/".
>
> Changing this one may have implication on existing GemFire customers
>
> In the past we had to make changes in OQL to support chars like "+", "-",
> "@"...(since customers used this in their region names)...
>
> -Anil.
>
>
> On Tue, Mar 1, 2016 at 2:44 PM, Udo Kohlmeyer 
> wrote:
>
> > +1
> >
> > On 2/03/2016 9:35 am, William Markito wrote:
> >
> >> Folks, it doesn't look like we have actually finished this thread...
> >>
> >> What do you guys think about the following pattern:
> >> "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz123456-_"  ?
> >>
> >> I'm not specifying a regexp to avoid problems with unicode and to keep
> it
> >> only ASCII-only...  Stackoveflow has some suggestions like
> >> "^\\p{ASCII}*$" but
> >> I'd be careful and try to keep it strict to the ones specified in the
> list
> >> above.
> >>
> >> Thanks
> >>
> >>
> >> On Thu, Feb 18, 2016 at 11:19 AM, Darrel Schneider <
> dschnei...@pivotal.io
> >> >
> >> wrote:
> >>
> >> The public javadocs on Region#getName say:
> >>> Returns the name of this region. A region's name
> >>> * can be any non-empty String providing it does not
> >>> * contain the name separator, a forward slash (/).
> >>>
> >>> Here is the code from LocalRegion that validates the name:
> >>>static void validateRegionName(String name)
> >>>{
> >>>  if (name == null) {
> >>>throw new
> >>>
> >>>
> >>>
> IllegalArgumentException(LocalizedStrings.LocalRegion_NAME_CANNOT_BE_NULL.toLocalizedString());
> >>>  }
> >>>  if (name.length() == 0) {
> >>>throw new
> >>>
> >>>
> >>>
> IllegalArgumentException(LocalizedStrings.LocalRegion_NAME_CANNOT_BE_EMPTY.toLocalizedString());
> >>>  }
> >>>  if (name.indexOf(SEPARATOR) >= 0) {
> >>>throw new
> >>>
> >>>
> >>>
> IllegalArgumentException(LocalizedStrings.LocalRegion_NAME_CANNOT_CONTAIN_THE_SEPARATOR_0.toLocalizedString(SEPARATOR));
> >>>  }
> >>>}
> >>>
> >>>
> >>> On Thu, Feb 18, 2016 at 11:09 AM, William Markito  >
> >>> wrote:
> >>>
> >>> I don't think we should allow non-alphanumeric region names...   And
> 
> >>> would
> >>>
>  be really nice to have a list or a pattern documenting what's valid.
> 
> 
>  On Thu, Feb 18, 2016 at 11:04 AM Kirk Lund  wrote:
> 
>  I was just looking into a ticket filed because /= was used as the
> >
>  Region
> >>>
>  name and this caused problems in JMX ObjectNames. I have two
> questions:
> >
>  1)
> 
> > do we really want /= to be a valid Region name? 2) do we have a
> >
>  complete
> >>>
>  list somewhere of all the non-alphanumeric characters that are usable
> >
>  in
> >>>
>  Region names?
> >
> > -Kirk
> >
> > --
>  ~/William
> 
> 
> >>
> >>
> >
>



-- 

~/William

Re: Review Request 44233: GEODE-1029 fixed test issue, where system is not working properly.

2016-03-01 Thread Udo Kohlmeyer 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44233/#review121529
---


Ship it!




Ship It!

- Udo Kohlmeyer


On March 1, 2016, 10:29 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44233/
> ---
> 
> (Updated March 1, 2016, 10:29 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Darrel Schneider, Jianxia Chen, 
> and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1029 fixed test issue, where system is not working properly.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/CachedDeserializableFactory.java
>  9120e37 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache30/DistributedMulticastRegionDUnitTest.java
>  72b7941 
> 
> Diff: https://reviews.apache.org/r/44233/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hitesh Khamesra
> 
>

Re: Valid characters in Region names

2016-03-01 Thread Anilkumar Gingade 
>From the existing javadoc it looks like, application can have any chars in
region name except the "/".

Changing this one may have implication on existing GemFire customers

In the past we had to make changes in OQL to support chars like "+", "-",
"@"...(since customers used this in their region names)...

-Anil.


On Tue, Mar 1, 2016 at 2:44 PM, Udo Kohlmeyer  wrote:

> +1
>
> On 2/03/2016 9:35 am, William Markito wrote:
>
>> Folks, it doesn't look like we have actually finished this thread...
>>
>> What do you guys think about the following pattern:
>> "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz123456-_"  ?
>>
>> I'm not specifying a regexp to avoid problems with unicode and to keep it
>> only ASCII-only...  Stackoveflow has some suggestions like
>> "^\\p{ASCII}*$" but
>> I'd be careful and try to keep it strict to the ones specified in the list
>> above.
>>
>> Thanks
>>
>>
>> On Thu, Feb 18, 2016 at 11:19 AM, Darrel Schneider > >
>> wrote:
>>
>> The public javadocs on Region#getName say:
>>> Returns the name of this region. A region's name
>>> * can be any non-empty String providing it does not
>>> * contain the name separator, a forward slash (/).
>>>
>>> Here is the code from LocalRegion that validates the name:
>>>static void validateRegionName(String name)
>>>{
>>>  if (name == null) {
>>>throw new
>>>
>>>
>>> IllegalArgumentException(LocalizedStrings.LocalRegion_NAME_CANNOT_BE_NULL.toLocalizedString());
>>>  }
>>>  if (name.length() == 0) {
>>>throw new
>>>
>>>
>>> IllegalArgumentException(LocalizedStrings.LocalRegion_NAME_CANNOT_BE_EMPTY.toLocalizedString());
>>>  }
>>>  if (name.indexOf(SEPARATOR) >= 0) {
>>>throw new
>>>
>>>
>>> IllegalArgumentException(LocalizedStrings.LocalRegion_NAME_CANNOT_CONTAIN_THE_SEPARATOR_0.toLocalizedString(SEPARATOR));
>>>  }
>>>}
>>>
>>>
>>> On Thu, Feb 18, 2016 at 11:09 AM, William Markito 
>>> wrote:
>>>
>>> I don't think we should allow non-alphanumeric region names...   And

>>> would
>>>
 be really nice to have a list or a pattern documenting what's valid.


 On Thu, Feb 18, 2016 at 11:04 AM Kirk Lund  wrote:

 I was just looking into a ticket filed because /= was used as the
>
 Region
>>>
 name and this caused problems in JMX ObjectNames. I have two questions:
>
 1)

> do we really want /= to be a valid Region name? 2) do we have a
>
 complete
>>>
 list somewhere of all the non-alphanumeric characters that are usable
>
 in
>>>
 Region names?
>
> -Kirk
>
> --
 ~/William


>>
>>
>

Re: Valid characters in Region names

2016-03-01 Thread Udo Kohlmeyer 

+1

On 2/03/2016 9:35 am, William Markito wrote:

Folks, it doesn't look like we have actually finished this thread...

What do you guys think about the following pattern:
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz123456-_"  ?

I'm not specifying a regexp to avoid problems with unicode and to keep it
only ASCII-only...  Stackoveflow has some suggestions like "^\\p{ASCII}*$" but
I'd be careful and try to keep it strict to the ones specified in the list
above.

Thanks


On Thu, Feb 18, 2016 at 11:19 AM, Darrel Schneider 
wrote:


The public javadocs on Region#getName say:
Returns the name of this region. A region's name
* can be any non-empty String providing it does not
* contain the name separator, a forward slash (/).

Here is the code from LocalRegion that validates the name:
   static void validateRegionName(String name)
   {
 if (name == null) {
   throw new

IllegalArgumentException(LocalizedStrings.LocalRegion_NAME_CANNOT_BE_NULL.toLocalizedString());
 }
 if (name.length() == 0) {
   throw new

IllegalArgumentException(LocalizedStrings.LocalRegion_NAME_CANNOT_BE_EMPTY.toLocalizedString());
 }
 if (name.indexOf(SEPARATOR) >= 0) {
   throw new

IllegalArgumentException(LocalizedStrings.LocalRegion_NAME_CANNOT_CONTAIN_THE_SEPARATOR_0.toLocalizedString(SEPARATOR));
 }
   }


On Thu, Feb 18, 2016 at 11:09 AM, William Markito 
wrote:


I don't think we should allow non-alphanumeric region names...   And

would

be really nice to have a list or a pattern documenting what's valid.


On Thu, Feb 18, 2016 at 11:04 AM Kirk Lund  wrote:


I was just looking into a ticket filed because /= was used as the

Region

name and this caused problems in JMX ObjectNames. I have two questions:

1)

do we really want /= to be a valid Region name? 2) do we have a

complete

list somewhere of all the non-alphanumeric characters that are usable

in

Region names?

-Kirk


--
~/William

Review Request 44233: GEODE-1029 fixed test issue, where system is not working properly.

2016-03-01 Thread Hitesh Khamesra 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44233/
---

Review request for geode, Bruce Schuchardt, Darrel Schneider, Jianxia Chen, and 
Udo Kohlmeyer.


Repository: geode


Description
---

GEODE-1029 fixed test issue, where system is not working properly.


Diffs
-

  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/CachedDeserializableFactory.java
 9120e37 
  
geode-core/src/test/java/com/gemstone/gemfire/cache30/DistributedMulticastRegionDUnitTest.java
 72b7941 

Diff: https://reviews.apache.org/r/44233/diff/


Testing
---


Thanks,

Hitesh Khamesra

Re: Valid characters in Region names

2016-03-01 Thread William Markito 
Folks, it doesn't look like we have actually finished this thread...

What do you guys think about the following pattern:
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz123456-_"  ?

I'm not specifying a regexp to avoid problems with unicode and to keep it
only ASCII-only...  Stackoveflow has some suggestions like "^\\p{ASCII}*$" but
I'd be careful and try to keep it strict to the ones specified in the list
above.

Thanks


On Thu, Feb 18, 2016 at 11:19 AM, Darrel Schneider 
wrote:

> The public javadocs on Region#getName say:
> Returns the name of this region. A region's name
>* can be any non-empty String providing it does not
>* contain the name separator, a forward slash (/).
>
> Here is the code from LocalRegion that validates the name:
>   static void validateRegionName(String name)
>   {
> if (name == null) {
>   throw new
>
> IllegalArgumentException(LocalizedStrings.LocalRegion_NAME_CANNOT_BE_NULL.toLocalizedString());
> }
> if (name.length() == 0) {
>   throw new
>
> IllegalArgumentException(LocalizedStrings.LocalRegion_NAME_CANNOT_BE_EMPTY.toLocalizedString());
> }
> if (name.indexOf(SEPARATOR) >= 0) {
>   throw new
>
> IllegalArgumentException(LocalizedStrings.LocalRegion_NAME_CANNOT_CONTAIN_THE_SEPARATOR_0.toLocalizedString(SEPARATOR));
> }
>   }
>
>
> On Thu, Feb 18, 2016 at 11:09 AM, William Markito 
> wrote:
>
> > I don't think we should allow non-alphanumeric region names...   And
> would
> > be really nice to have a list or a pattern documenting what's valid.
> >
> >
> > On Thu, Feb 18, 2016 at 11:04 AM Kirk Lund  wrote:
> >
> > > I was just looking into a ticket filed because /= was used as the
> Region
> > > name and this caused problems in JMX ObjectNames. I have two questions:
> > 1)
> > > do we really want /= to be a valid Region name? 2) do we have a
> complete
> > > list somewhere of all the non-alphanumeric characters that are usable
> in
> > > Region names?
> > >
> > > -Kirk
> > >
> > --
> > ~/William
> >
>



-- 

~/William

Re: Scope for M2 release

2016-03-01 Thread Anthony Baker 
Great idea Nitin!  I don’t think we have permissions to see it though:

JIRA Issues Macro: JIRA project does not exist or you do not have 
permission to view it.

Anthony


> On Mar 1, 2016, at 1:51 PM, Nitin Lamba  wrote:
> 
> OK, I've added a couple of JIRA filters to extract all issues loaded in our 
> M2 sprint. This helps create a data-driven table of issues on the wiki page 
> [1] instead of manually sync-ing it. Ideally, we should start this 
> (scope-defined) sprint and close it when M2 is released. Thoughts?
> 
> Please check it out and suggest if any specific attributes should be 
> displayed or if the inclusion/ exclusion criteria should be changed.
> 
> Nitin
> [1] 
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
> 
> 
> From: Nitin Lamba 
> Sent: Tuesday, March 1, 2016 1:17 PM
> To: dev@geode.incubator.apache.org
> Subject: Re: Scope for M2 release
> 
> +1
> 
> I had recently updated the wiki page for completed JIRAs. Ideally, we should 
> just have one place to update.
> 
> Let me quickly research if there's a way to integrate the lists.
> 
> Nitin
> 
> From: Kirk Lund 
> Sent: Tuesday, March 1, 2016 11:33 AM
> To: dev@geode.incubator.apache.org
> Subject: Re: Scope for M2 release
> 
> +1
> 
> On Tuesday, March 1, 2016, Anthony Baker  wrote:
> 
>> I was discussing the M2 release scope and noticed that the wiki page [1]
>> differs slightly from the JIRA Geode-Release filter [2] and roadmap [3],
>> 
>> Should we update the wiki page to match JIRA based on the prior email
>> thread [4]?
>> 
>> Anthony
>> 
>> [1]
>> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
>> [2]
>> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92=planning.nodetail=GEODE-914
>> [3]
>> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
>> [4]
>> http://mail-archives.apache.org/mod_mbox/geode-dev/201602.mbox/%3ccafh+7k1vf2j8fhj98zqewakhfmid+ssdqjmgdqtdowfbhwt...@mail.gmail.com%3E



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Scope for M2 release

2016-03-01 Thread Nitin Lamba 
OK, I've added a couple of JIRA filters to extract all issues loaded in our M2 
sprint. This helps create a data-driven table of issues on the wiki page [1] 
instead of manually sync-ing it. Ideally, we should start this (scope-defined) 
sprint and close it when M2 is released. Thoughts?

Please check it out and suggest if any specific attributes should be displayed 
or if the inclusion/ exclusion criteria should be changed.

Nitin
[1] 
https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release


From: Nitin Lamba 
Sent: Tuesday, March 1, 2016 1:17 PM
To: dev@geode.incubator.apache.org
Subject: Re: Scope for M2 release

+1

I had recently updated the wiki page for completed JIRAs. Ideally, we should 
just have one place to update.

Let me quickly research if there's a way to integrate the lists.

Nitin

From: Kirk Lund 
Sent: Tuesday, March 1, 2016 11:33 AM
To: dev@geode.incubator.apache.org
Subject: Re: Scope for M2 release

+1

On Tuesday, March 1, 2016, Anthony Baker  wrote:

> I was discussing the M2 release scope and noticed that the wiki page [1]
> differs slightly from the JIRA Geode-Release filter [2] and roadmap [3],
>
> Should we update the wiki page to match JIRA based on the prior email
> thread [4]?
>
> Anthony
>
> [1]
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
> [2]
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92=planning.nodetail=GEODE-914
> [3]
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
> [4]
> http://mail-archives.apache.org/mod_mbox/geode-dev/201602.mbox/%3ccafh+7k1vf2j8fhj98zqewakhfmid+ssdqjmgdqtdowfbhwt...@mail.gmail.com%3E
>

Re: Scope for M2 release

2016-03-01 Thread Nitin Lamba 
+1

I had recently updated the wiki page for completed JIRAs. Ideally, we should 
just have one place to update.

Let me quickly research if there's a way to integrate the lists.

Nitin

From: Kirk Lund 
Sent: Tuesday, March 1, 2016 11:33 AM
To: dev@geode.incubator.apache.org
Subject: Re: Scope for M2 release

+1

On Tuesday, March 1, 2016, Anthony Baker  wrote:

> I was discussing the M2 release scope and noticed that the wiki page [1]
> differs slightly from the JIRA Geode-Release filter [2] and roadmap [3],
>
> Should we update the wiki page to match JIRA based on the prior email
> thread [4]?
>
> Anthony
>
> [1]
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
> [2]
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92=planning.nodetail=GEODE-914
> [3]
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
> [4]
> http://mail-archives.apache.org/mod_mbox/geode-dev/201602.mbox/%3ccafh+7k1vf2j8fhj98zqewakhfmid+ssdqjmgdqtdowfbhwt...@mail.gmail.com%3E
>

Re: Scope for M2 release

2016-03-01 Thread Kirk Lund 
+1

On Tuesday, March 1, 2016, Anthony Baker  wrote:

> I was discussing the M2 release scope and noticed that the wiki page [1]
> differs slightly from the JIRA Geode-Release filter [2] and roadmap [3],
>
> Should we update the wiki page to match JIRA based on the prior email
> thread [4]?
>
> Anthony
>
> [1]
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
> [2]
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92=planning.nodetail=GEODE-914
> [3]
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
> [4]
> http://mail-archives.apache.org/mod_mbox/geode-dev/201602.mbox/%3ccafh+7k1vf2j8fhj98zqewakhfmid+ssdqjmgdqtdowfbhwt...@mail.gmail.com%3E
>

Re: Conributors.md

2016-03-01 Thread Kenneth Howe 
+1 to provide a link on the Geode Community web page to the cwiki How to 
Contribute, with the cwiki being the one place to keep the info current.

Ken

> On Mar 1, 2016, at 10:57 AM, Dave Barnes  wrote:
> 
> +1 to providing a more obvious path to the "how to contribute" info. This
> thread suggests two possibilities:
> 
>   - add a CONTRIBUTING.md (or CONTRIBUTORS.md) file to the sources, or
>   - Add a link to the cwiki page (
>   https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute).
> 
> I like the second, the cwiki link, because we can update the information in
> a single place without having to check in new sources.
> Anyone else have a preference?
> 
> 
> On Tue, Mar 1, 2016 at 8:19 AM, Nitin Lamba  wrote:
> 
>> Hi Dor,
>> 
>> From the e-mail subject, is this question about capturing the list of
>> contributors on the Geode project? The website has a list of committers on
>> the community page [1]; perhaps a link to contribution guidelines (wiki)
>> can be created from there.
>> 
>> Nitin
>> [1] http://geode.incubator.apache.org/community/
>> 
>> From: Anthony Baker 
>> Sent: Thursday, February 25, 2016 9:42 AM
>> To: dev@geode.incubator.apache.org
>> Subject: Re: Conributors.md
>> 
>> Hi Dor,
>> 
>> We have some information on that subject in the wiki:
>> https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute
>> 
>> What would like to see added to a ‘CONTRIBUTING.md’ file?
>> 
>> Anthony
>> 
>>> On Feb 24, 2016, at 10:28 AM, Dor Ben Dov 
>> wrote:
>>> 
>>> Hi ,
>>> 
>>> 
>>> Any possible way that you will add the contributing.md file to the root
>> folder ?
>>> 
>>> 
>>> Regards,
>>> Dor Ben Dov
>>> 
>>> This message and the information contained herein is proprietary and
>> confidential and subject to the Amdocs policy statement,
>>> you may review at http://www.amdocs.com/email_disclaimer.asp
>>

Re: Conributors.md

2016-03-01 Thread Dave Barnes 
+1 to providing a more obvious path to the "how to contribute" info. This
thread suggests two possibilities:

   - add a CONTRIBUTING.md (or CONTRIBUTORS.md) file to the sources, or
   - Add a link to the cwiki page (
   https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute).

I like the second, the cwiki link, because we can update the information in
a single place without having to check in new sources.
Anyone else have a preference?


On Tue, Mar 1, 2016 at 8:19 AM, Nitin Lamba  wrote:

> Hi Dor,
>
> From the e-mail subject, is this question about capturing the list of
> contributors on the Geode project? The website has a list of committers on
> the community page [1]; perhaps a link to contribution guidelines (wiki)
> can be created from there.
>
> Nitin
> [1] http://geode.incubator.apache.org/community/
> 
> From: Anthony Baker 
> Sent: Thursday, February 25, 2016 9:42 AM
> To: dev@geode.incubator.apache.org
> Subject: Re: Conributors.md
>
> Hi Dor,
>
> We have some information on that subject in the wiki:
> https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute
>
> What would like to see added to a ‘CONTRIBUTING.md’ file?
>
> Anthony
>
> > On Feb 24, 2016, at 10:28 AM, Dor Ben Dov 
> wrote:
> >
> > Hi ,
> >
> >
> > Any possible way that you will add the contributing.md file to the root
> folder ?
> >
> >
> > Regards,
> > Dor Ben Dov
> >
> > This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> > you may review at http://www.amdocs.com/email_disclaimer.asp
>

[GitHub] incubator-geode pull request: Feature/geode 856.1

2016-03-01 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/incubator-geode/pull/108


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Review Request 44107: GEDOE-856: Unit tests for TinyMemoryBlock

2016-03-01 Thread Sai Boorlagadda 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44107/#review121461
---


Ship it!




Ship It!

- Sai Boorlagadda


On Feb. 26, 2016, 11:40 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44107/
> ---
> 
> (Updated Feb. 26, 2016, 11:40 p.m.)
> 
> 
> Review request for geode, Darrel Schneider and Sai Boorlagadda.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> To give testing access to the class, the access modifier of
> TinyMemoryBlock and it's constructor has been changed from private to 
> protected.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/FreeListManager.java
>  a716f144d4d248a346ebf10e6826888c482eef09 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/TinyMemoryBlockJUnitTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/44107/diff/
> 
> 
> Testing
> ---
> 
> Precheckin is in progress
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

Re: Review Request 44125: GEODE-996: OffheapStats - fragmentation percentage calculation has to be revisited.

2016-03-01 Thread Sai Boorlagadda 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44125/
---

(Updated March 1, 2016, 6:26 p.m.)


Review request for geode and Darrel Schneider.


Repository: geode


Description
---

GEODE-996: OffheapStats - fragmentation percentage calculation has to be 
revisited.


Diffs (updated)
-

  
geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/FreeListManager.java
 a716f144d4d248a346ebf10e6826888c482eef09 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/OffHeapStorage.java
 bb5cdebfd0b85f7160e00d383058ab5acfb27bc6 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/FreeListManagerTest.java
 64032cc768d06148c9c8b476aa047874a8e634eb 
  
geode-core/src/test/java/com/gemstone/gemfire/management/OffHeapManagementDUnitTest.java
 acafada0b7040d2c4f74acea24fd952294d13aa1 

Diff: https://reviews.apache.org/r/44125/diff/


Testing (updated)
---

precheckin


Thanks,

Sai Boorlagadda

Scope for M2 release

2016-03-01 Thread Anthony Baker 
I was discussing the M2 release scope and noticed that the wiki page [1] 
differs slightly from the JIRA Geode-Release filter [2] and roadmap [3],

Should we update the wiki page to match JIRA based on the prior email thread 
[4]?

Anthony

[1] 
https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
[2] 
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92=planning.nodetail=GEODE-914
[3] 
https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
[4] 
http://mail-archives.apache.org/mod_mbox/geode-dev/201602.mbox/%3ccafh+7k1vf2j8fhj98zqewakhfmid+ssdqjmgdqtdowfbhwt...@mail.gmail.com%3E


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Review Request 44125: GEODE-996: OffheapStats - fragmentation percentage calculation has to be revisited.

2016-03-01 Thread Darrel Schneider 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44125/#review121451
---




geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/FreeListManager.java
 (line 476)


I think "getFragmentCount" is better than "getFragmentsCount".



geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/FreeListManager.java
 (line 494)


I'd get rid of the abbreviations in this comment.
In fact I think this block is clear enough that you don't need a comment.



geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/FreeListManager.java
 (line 496)


A better assertion is
freeMemory >= ObjectChunk.MIN_CHUNK_SIZE


- Darrel Schneider


On Feb. 29, 2016, 6 p.m., Sai Boorlagadda wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44125/
> ---
> 
> (Updated Feb. 29, 2016, 6 p.m.)
> 
> 
> Review request for geode and Darrel Schneider.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-996: OffheapStats - fragmentation percentage calculation has to be 
> revisited.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/FreeListManager.java
>  a716f144d4d248a346ebf10e6826888c482eef09 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/OffHeapStorage.java
>  bb5cdebfd0b85f7160e00d383058ab5acfb27bc6 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/FreeListManagerTest.java
>  64032cc768d06148c9c8b476aa047874a8e634eb 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/OffHeapManagementDUnitTest.java
>  acafada0b7040d2c4f74acea24fd952294d13aa1 
> 
> Diff: https://reviews.apache.org/r/44125/diff/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Sai Boorlagadda
> 
>

Re: Conributors.md

2016-03-01 Thread Nitin Lamba 
Hi Dor,

>From the e-mail subject, is this question about capturing the list of 
>contributors on the Geode project? The website has a list of committers on the 
>community page [1]; perhaps a link to contribution guidelines (wiki) can be 
>created from there.

Nitin
[1] http://geode.incubator.apache.org/community/

From: Anthony Baker 
Sent: Thursday, February 25, 2016 9:42 AM
To: dev@geode.incubator.apache.org
Subject: Re: Conributors.md

Hi Dor,

We have some information on that subject in the wiki:
https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute

What would like to see added to a ‘CONTRIBUTING.md’ file?

Anthony

> On Feb 24, 2016, at 10:28 AM, Dor Ben Dov  wrote:
>
> Hi ,
>
>
> Any possible way that you will add the contributing.md file to the root 
> folder ?
>
>
> Regards,
> Dor Ben Dov
>
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp

Build failed in Jenkins: Geode-nightly #395

2016-03-01 Thread Apache Jenkins Server 
See 

Changes:

[ukohlmeyer] GEODE-870: Rejecting of old view

[ukohlmeyer] GEODE-870: Handling multiple concurrent locator restarts. Elder 
locator

[ukohlmeyer] GEODE-870: Handling multiple concurrent locator restarts. Elder 
locator

[ukohlmeyer] GEODE-870: Handling multiple concurrent locator restarts. Elder 
locator

[ukohlmeyer] GEODE-870: Amending code as per code review Adding wait on

[ukohlmeyer] GEODE-870: test case fixes.

[ukohlmeyer] GEODE-870: Adding GMSJoinLeaveTestHelper back after gemfire/geode 
merge

[ukohlmeyer] GEODE-870: Rejecting of old view

[ukohlmeyer] GEODE-870: Handling multiple concurrent locator restarts. Elder 
locator

[ukohlmeyer] GEODE-870: Handling multiple concurrent locator restarts. Elder 
locator

[ukohlmeyer] GEODE-870: Amending code as per code review Adding wait on

[ukohlmeyer] GEODE-870: Adding GMSJoinLeaveTestHelper back after gemfire/geode 
merge

[gzhou] GEODE-774

[klund] GEODE-953: Cleanup geode-junit

[klund] GEODE-953: Fix missing junit category

[jchen] GEODE-1014: PdxSerializationException Error when putall an object from

--
[...truncated 470 lines...]
:geode-common:processTestResources UP-TO-DATE
:geode-common:testClasses
:geode-common:checkMissedTests
:geode-common:test
:geode-common:check
:geode-common:build
:geode-common:distributedTest
:geode-common:integrationTest
:geode-core:assemble
:geode-core:checkMissedTests
:geode-core:test
:geode-core:check
:geode-core:build
:geode-core:distributedTest

com.gemstone.gemfire.internal.cache.wan.asyncqueue.AsyncEventListenerOffHeapDUnitTest
 > testParallelAsyncEventQueueHA_Scenario2 FAILED
com.gemstone.gemfire.test.dunit.RMIException: While invoking 
com.gemstone.gemfire.internal.cache.wan.asyncqueue.AsyncEventListenerDUnitTest$$Lambda$43/1833748685.run
 in VM 6 running on Host asf906.gq1.ygridcore.net with 8 VMs

Caused by:
java.lang.IndexOutOfBoundsException: Index: 4, Size: 4

com.gemstone.gemfire.cache30.DistributedMulticastRegionDUnitTest > 
testMulticastWithRegionOpsException FAILED
com.gemstone.gemfire.test.dunit.RMIException: While invoking 
com.gemstone.gemfire.cache30.DistributedMulticastRegionDUnitTest$9.run in VM 0 
running on Host asf906.gq1.ygridcore.net with 4 VMs
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:379)
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:321)
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:272)
at 
com.gemstone.gemfire.cache30.DistributedMulticastRegionDUnitTest.testMulticastWithRegionOpsException(DistributedMulticastRegionDUnitTest.java:212)

Caused by:
junit.framework.AssertionFailedError: We should have got ReplyEception 

com.gemstone.gemfire.distributed.internal.DistributionAdvisorDUnitTest > 
testGenericAdvice FAILED
junit.framework.AssertionFailedError: expected:<4> but was:<5>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:234)
at junit.framework.Assert.assertEquals(Assert.java:241)
at junit.framework.TestCase.assertEquals(TestCase.java:409)
at 
com.gemstone.gemfire.distributed.internal.DistributionAdvisorDUnitTest.setUp(DistributionAdvisorDUnitTest.java:69)

com.gemstone.gemfire.distributed.internal.streaming.StreamingOperationManyDUnitTest
 > testStreamingManyProvidersNoExceptions FAILED
junit.framework.AssertionFailedError: expected:<4> but was:<5>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:234)
at junit.framework.Assert.assertEquals(Assert.java:241)
at junit.framework.TestCase.assertEquals(TestCase.java:409)
at 
com.gemstone.gemfire.distributed.internal.streaming.StreamingOperationManyDUnitTest.testStreamingManyProvidersNoExceptions(StreamingOperationManyDUnitTest.java:67)

6991 tests completed, 4 failed, 18 skipped
:geode-core:distributedTest FAILED
:geode-core:integrationTest
:geode-cq:assemble
:geode-cq:compileTestJavaNote: 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-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:integrationTest
:geode-joptsimple:assemble
:geode-joptsimple:compileTestJava UP-TO-DATE
:geode-joptsimple:processTestResources UP-TO-DATE
:geode-joptsimple:testClasses UP-TO-DATE
:geode-joptsimple:checkMissedTests UP-TO-DATE