Build failed in Jenkins: Geode-nightly #694

[Apache Jenkins Server]

See 

Changes:

[adongre] GEODE-165: Removed OQL generated files and added the target into

[upthewaterspout] GEODE-2238: Fix how peers discover locators with cluster 
config

[boglesby] GEODE-2234: Query stats are now calculated per member in the

[boglesby] GEODE-2242: Invalid VersionTags are no longer replicated across the 
WAN

[jiliao] GEODE-2099: The GfshConnectorRule has been refactored to use awaitility

[dschneider] GEODE-2240: fix unsafe concurrent access of ArrayList When adding 
to the

[kmiller] CTR: remove incorrect links to Pivotal Native Client product APIs

[upthewaterspout] GEODE-165: Adding support for generated-src in eclipse

--
[...truncated 555 lines...]
: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:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources UP-TO-DATE
:geode-json:testClasses UP-TO-DATE
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json:flakyTest UP-TO-DATE
:geode-json:integrationTest UP-TO-DATE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJava
:geode-junit:processTestResources UP-TO-DATE
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:flakyTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene: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-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
:geode-old-client-support:processTestResources UP-TO-DATE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:flakyTest
:geode-old-client-support:integrationTest
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: 

 uses or overrides 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-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:flakyTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources UP-TO-DATE
:geode-rebalancer:testClasses
:geode-rebalancer:checkMissedTests
:geode-rebalancer:spotlessJavaCheck
:geode-rebalancer:spotlessCheck
:geode-rebalancer:test
:geode-rebalancer:check
:geode-rebalancer:build
:geode-rebalancer:distributedTest
:geode-rebalancer:flakyTest
:geode-rebalancer:integrationTest
:geode-wan:assemble
:geode-wan: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-wan:processTestResources
:geode-wan:testClasses
:geode-wan:checkMissedTests
:geode-wan:spotlessJavaCheck
:geode-wan:spotlessCheck
:geode-wan:test
:geode-wan:check
:geode-wan:build
:geode-wan:distributedTest
:geode-wan:flakyTest
:geode-wan:integrationTest
:geode-web:assemble
:geode-web:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: S

Re: New proposal for type definitons

[Bruce Schuchardt]

I wonder if it would be helpful to use JSON Schema 
 as a starting point for this effort?



Le 12/22/2016 à 6:45 PM, Udo Kohlmeyer a écrit :

Ok, I will try and explain all of this better.

--Udo


On 12/22/16 16:42, Darrel Schneider wrote:
The @refTypeId is hard to understand. It is unclear to me how it 
interacts

with other things like "dataType" and "subType". I think you can either
specify a dataType/subType OR a @refTypeId. Is this correct? The current
spec makes it look like you can specify both but your example just 
show one

or the other.

If so wouldn't it be clearer to just have one of the values of 
"dataType"
or "subType" to be "@n" where n is a number referring to an 
already

defined typeId?

Saying a field has to be of a specific type is much stronger than pdx
currently supports. It only has support for specific basic types and 
then
the generic "Object" type. If you plan on using the existing pdx 
registry

then that type system would need to be expanded to deal with @refTypeId
fields.

Also the "formatter" field seems like a new feature that is not 
described

in your proposal. You have a comment that says it applies to Dates and
Doubles but it seems like your type syntax would allow you to specify 
it on

any field type.

On Thu, Dec 22, 2016 at 4:32 PM, Darrel Schneider 


wrote:

You proposal seems to be only handle types for JSON. I do not see 
that you

support all the pdx field types.
Also you have things like List and "subType" which currently have no
support explicit support in the pdx type system.

So do you intend this proposal to be specific to JSON? If so the 
gfsh and
apis need to make this clear. If not then your proposal should make 
sure it

supports all the existing pdx types.

On Thu, Dec 22, 2016 at 4:27 PM, Darrel Schneider 


wrote:

Something I did not see in your proposal was the rules that would 
be used
when a JSON document uses "@typeId" to determine if that type is 
valid for

the current document.
For example I think you want to allow the type to have a field that 
does

not exist in the document.
I think you also want to say that if the document has a field that 
does

not exist in the type then an exception is thrown.

You may also have exceptions for when the document's field data can 
not
be represented in the type's field. For example the type may say 
the field

is Boolean but the document may have a String whose value is "foobar".
Before the field type was derived from the actual value in the 
document but

now you can have a mismatch.


On Thu, Dec 22, 2016 at 4:16 PM, Darrel Schneider 


wrote:


One danger of this solution is users may think they can modify a
previously defined type. Since they specify the type they may 
think they
can just edit the file and reload the types with modified 
definitions. In
most cases if data has already been serialized using the old type 
then
modifying the type will lead to data that can no longer be 
deserialized.


Are you thinking that these new user defined types would be loaded 
into
the PDX registry and remembered? If you later tried to reload the 
same type
and it differs then the reload fails? If so then I think this 
would keep

users from making illegal changes.

On Thu, Dec 22, 2016 at 4:11 PM, Darrel Schneider 

wrote:
When generating a pdx type for a JSON document couldn't we sort the
field names from the JSON document so that field order would not 
generated

different pdx types?
Also when choosing a pdx field type if we always picked a "wider" 
type
then it would reduce the number of types generated because of 
different

field types.


On Thu, Dec 22, 2016 at 10:02 AM, Udo Kohlmeyer 


wrote:


Hi there Dan,

You are correct, the thought is there to add a flag to the 
registry to
indicate that a definition is custom and thus should not 
conflict with the
existing ids. Even if they types were to be stored with the 
current Pdx
type definitions, upon loading/registration of the custom type 
definitions,
any conflict will be reported and the custom set will not be 
registered

until all issues were addressed.

I also had the opinion of the "if they can provide me a typeId, 
then

surely they can provide me with a fully populated JSON document".
Referencing the example document from the wiki, an user can be 
created with
just a first and surname. It is not required to provide 
currentAddress,
previousAddresses, dob,etc... Whilst one could force the client 
to provide
all fields in the JSON document, it is not always possible nor 
feasible to
do so. In the POJO world we have a structured data definition 
and the

generation of a type definition is simple. This done because from a
serialization perspective we always make sure that all fields are
serialized. BUT if we were to change the serialization, i.e not 
serialize a
field because it is null, the type definition behavior would be 
exactly the
same as JSON. Only, in this case, because we changed the type 
definition
for 

Re: New proposal for type definitons

[Michael Stolz]

This is pretty interesting actually. It brings back the good parts of
formal schema design.

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771

On Fri, Dec 23, 2016 at 11:09 AM, Bruce Schuchardt 
wrote:

> I wonder if it would be helpful to use JSON Schema <
> http://json-schema.org/> as a starting point for this effort?
>
>
>
> Le 12/22/2016 à 6:45 PM, Udo Kohlmeyer a écrit :
>
>> Ok, I will try and explain all of this better.
>>
>> --Udo
>>
>>
>> On 12/22/16 16:42, Darrel Schneider wrote:
>>
>>> The @refTypeId is hard to understand. It is unclear to me how it
>>> interacts
>>> with other things like "dataType" and "subType". I think you can either
>>> specify a dataType/subType OR a @refTypeId. Is this correct? The current
>>> spec makes it look like you can specify both but your example just show
>>> one
>>> or the other.
>>>
>>> If so wouldn't it be clearer to just have one of the values of "dataType"
>>> or "subType" to be "@n" where n is a number referring to an
>>> already
>>> defined typeId?
>>>
>>> Saying a field has to be of a specific type is much stronger than pdx
>>> currently supports. It only has support for specific basic types and then
>>> the generic "Object" type. If you plan on using the existing pdx registry
>>> then that type system would need to be expanded to deal with @refTypeId
>>> fields.
>>>
>>> Also the "formatter" field seems like a new feature that is not described
>>> in your proposal. You have a comment that says it applies to Dates and
>>> Doubles but it seems like your type syntax would allow you to specify it
>>> on
>>> any field type.
>>>
>>> On Thu, Dec 22, 2016 at 4:32 PM, Darrel Schneider >> >
>>> wrote:
>>>
>>> You proposal seems to be only handle types for JSON. I do not see that
 you
 support all the pdx field types.
 Also you have things like List and "subType" which currently have no
 support explicit support in the pdx type system.

 So do you intend this proposal to be specific to JSON? If so the gfsh
 and
 apis need to make this clear. If not then your proposal should make
 sure it
 supports all the existing pdx types.

 On Thu, Dec 22, 2016 at 4:27 PM, Darrel Schneider <
 dschnei...@pivotal.io>
 wrote:

 Something I did not see in your proposal was the rules that would be
> used
> when a JSON document uses "@typeId" to determine if that type is valid
> for
> the current document.
> For example I think you want to allow the type to have a field that
> does
> not exist in the document.
> I think you also want to say that if the document has a field that does
> not exist in the type then an exception is thrown.
>
> You may also have exceptions for when the document's field data can not
> be represented in the type's field. For example the type may say the
> field
> is Boolean but the document may have a String whose value is "foobar".
> Before the field type was derived from the actual value in the
> document but
> now you can have a mismatch.
>
>
> On Thu, Dec 22, 2016 at 4:16 PM, Darrel Schneider <
> dschnei...@pivotal.io>
> wrote:
>
> One danger of this solution is users may think they can modify a
>> previously defined type. Since they specify the type they may think
>> they
>> can just edit the file and reload the types with modified
>> definitions. In
>> most cases if data has already been serialized using the old type then
>> modifying the type will lead to data that can no longer be
>> deserialized.
>>
>> Are you thinking that these new user defined types would be loaded
>> into
>> the PDX registry and remembered? If you later tried to reload the
>> same type
>> and it differs then the reload fails? If so then I think this would
>> keep
>> users from making illegal changes.
>>
>> On Thu, Dec 22, 2016 at 4:11 PM, Darrel Schneider <
>> dschnei...@pivotal.io
>>
>>> wrote:
>>> When generating a pdx type for a JSON document couldn't we sort the
>>> field names from the JSON document so that field order would not
>>> generated
>>> different pdx types?
>>> Also when choosing a pdx field type if we always picked a "wider"
>>> type
>>> then it would reduce the number of types generated because of
>>> different
>>> field types.
>>>
>>>
>>> On Thu, Dec 22, 2016 at 10:02 AM, Udo Kohlmeyer <
>>> ukohlme...@pivotal.io>
>>> wrote:
>>>
>>> Hi there Dan,

 You are correct, the thought is there to add a flag to the registry
 to
 indicate that a definition is custom and thus should not conflict
 with the
 existing ids. Even if they types were to be stored with the current
 Pdx
 type definitions, upon loading/registration of the custom type
 definitions,
 any 

[jira] [Created] (GEODE-2245) CI Failure: beforeConnectMBeans and registeredMBeans mismatch Diff : [GemFire:service=CacheService,name=LuceneService,type=Member,member=managinggemfire2_rs-OperationsBTT

[Kevin Duling (JIRA)]

Kevin Duling created GEODE-2245:
---

 Summary: CI Failure: beforeConnectMBeans and registeredMBeans 
mismatch Diff : 
[GemFire:service=CacheService,name=LuceneService,type=Member,member=managinggemfire2_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19965]
 Key: GEODE-2245
 URL: https://issues.apache.org/jira/browse/GEODE-2245
 Project: Geode
  Issue Type: Bug
  Components: management
Reporter: Kevin Duling


Test run (from CIRegression run #88 and hydra runId 1153) is located here:
   /export/monaco1/users/lhughes/xfer/cacheStopStart-1222-231102

*** errors.txt ***
CLIENT 
vm_6_thr_7_managing1_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19961
TASK[0] management.test.jmx.JMXTest.HydraTask_jmxOperations
ERROR util.TestException: Error running test cacheStopStart

util.TestException: Error running test cacheStopStart
at 
management.util.HydraUtil.logErrorAndRaiseException(HydraUtil.java:84)
at 
management.operations.ops.jmx.AbstractTestMBean.runMethod(AbstractTestMBean.java:286)
at 
management.operations.ops.jmx.AbstractTestMBean.executeTest(AbstractTestMBean.java:301)
at 
management.operations.ops.JMXOperations.doJMXTest(JMXOperations.java:105)
at management.test.jmx.JMXTest.doJMXOps(JMXTest.java:841)
at management.test.jmx.JMXTest.HydraTask_jmxOperations(JMXTest.java:214)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at hydra.MethExecutor.execute(MethExecutor.java:182)
at hydra.MethExecutor.execute(MethExecutor.java:150)
at hydra.TestTask.execute(TestTask.java:192)
at hydra.RemoteTestModule$1.run(RemoteTestModule.java:212)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
management.operations.ops.jmx.AbstractTestMBean.runMethod(AbstractTestMBean.java:280)
... 12 more
Caused by: util.TestException: beforeConnectMBeans and registeredMBeans 
mismatch Diff : 
[GemFire:service=CacheService,name=LuceneService,type=Member,member=managinggemfire2_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19965]
at management.test.jmx.JMXTest.cacheStopStart(JMXTest.java:377)
at 
management.operations.ops.jmx.MemberTestMbean.cacheStopStart(MemberTestMbean.java:400)
... 17 more





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2245) CI Failure: beforeConnectMBeans and registeredMBeans mismatch Diff : [GemFire:service=CacheService,name=LuceneService,type=Member,member=managinggemfire2_rs-OperationsBTT

[Kevin Duling (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Duling updated GEODE-2245:

Attachment: 
vm_6_managing1_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19961.log

> CI Failure: beforeConnectMBeans and registeredMBeans mismatch Diff : 
> [GemFire:service=CacheService,name=LuceneService,type=Member,member=managinggemfire2_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19965]
> -
>
> Key: GEODE-2245
> URL: https://issues.apache.org/jira/browse/GEODE-2245
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Kevin Duling
> Attachments: 
> vm_6_managing1_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19961.log
>
>
> Test run (from CIRegression run #88 and hydra runId 1153) is located here:
>/export/monaco1/users/lhughes/xfer/cacheStopStart-1222-231102
> *** errors.txt ***
> CLIENT 
> vm_6_thr_7_managing1_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19961
> TASK[0] management.test.jmx.JMXTest.HydraTask_jmxOperations
> ERROR util.TestException: Error running test cacheStopStart
> util.TestException: Error running test cacheStopStart
> at 
> management.util.HydraUtil.logErrorAndRaiseException(HydraUtil.java:84)
> at 
> management.operations.ops.jmx.AbstractTestMBean.runMethod(AbstractTestMBean.java:286)
> at 
> management.operations.ops.jmx.AbstractTestMBean.executeTest(AbstractTestMBean.java:301)
> at 
> management.operations.ops.JMXOperations.doJMXTest(JMXOperations.java:105)
> at management.test.jmx.JMXTest.doJMXOps(JMXTest.java:841)
> at 
> management.test.jmx.JMXTest.HydraTask_jmxOperations(JMXTest.java:214)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at hydra.MethExecutor.execute(MethExecutor.java:182)
> at hydra.MethExecutor.execute(MethExecutor.java:150)
> at hydra.TestTask.execute(TestTask.java:192)
> at hydra.RemoteTestModule$1.run(RemoteTestModule.java:212)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> management.operations.ops.jmx.AbstractTestMBean.runMethod(AbstractTestMBean.java:280)
> ... 12 more
> Caused by: util.TestException: beforeConnectMBeans and registeredMBeans 
> mismatch Diff : 
> [GemFire:service=CacheService,name=LuceneService,type=Member,member=managinggemfire2_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19965]
> at management.test.jmx.JMXTest.cacheStopStart(JMXTest.java:377)
> at 
> management.operations.ops.jmx.MemberTestMbean.cacheStopStart(MemberTestMbean.java:400)
> ... 17 more
> 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2245) CI Failure: beforeConnectMBeans and registeredMBeans mismatch Diff : [GemFire:service=CacheService,name=LuceneService,type=Member,member=managinggemfire2_rs-OperationsBTT

[Kevin Duling (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Duling updated GEODE-2245:

Description: 
{code}
CLIENT 
vm_6_thr_7_managing1_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19961
TASK[0] management.test.jmx.JMXTest.HydraTask_jmxOperations
ERROR util.TestException: Error running test cacheStopStart

util.TestException: Error running test cacheStopStart
at 
management.util.HydraUtil.logErrorAndRaiseException(HydraUtil.java:84)
at 
management.operations.ops.jmx.AbstractTestMBean.runMethod(AbstractTestMBean.java:286)
at 
management.operations.ops.jmx.AbstractTestMBean.executeTest(AbstractTestMBean.java:301)
at 
management.operations.ops.JMXOperations.doJMXTest(JMXOperations.java:105)
at management.test.jmx.JMXTest.doJMXOps(JMXTest.java:841)
at management.test.jmx.JMXTest.HydraTask_jmxOperations(JMXTest.java:214)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at hydra.MethExecutor.execute(MethExecutor.java:182)
at hydra.MethExecutor.execute(MethExecutor.java:150)
at hydra.TestTask.execute(TestTask.java:192)
at hydra.RemoteTestModule$1.run(RemoteTestModule.java:212)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
management.operations.ops.jmx.AbstractTestMBean.runMethod(AbstractTestMBean.java:280)
... 12 more
Caused by: util.TestException: beforeConnectMBeans and registeredMBeans 
mismatch Diff : 
[GemFire:service=CacheService,name=LuceneService,type=Member,member=managinggemfire2_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19965]
at management.test.jmx.JMXTest.cacheStopStart(JMXTest.java:377)
at 
management.operations.ops.jmx.MemberTestMbean.cacheStopStart(MemberTestMbean.java:400)
... 17 more
{code}

  was:
Test run (from CIRegression run #88 and hydra runId 1153) is located here:
   /export/monaco1/users/lhughes/xfer/cacheStopStart-1222-231102

*** errors.txt ***
CLIENT 
vm_6_thr_7_managing1_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19961
TASK[0] management.test.jmx.JMXTest.HydraTask_jmxOperations
ERROR util.TestException: Error running test cacheStopStart

util.TestException: Error running test cacheStopStart
at 
management.util.HydraUtil.logErrorAndRaiseException(HydraUtil.java:84)
at 
management.operations.ops.jmx.AbstractTestMBean.runMethod(AbstractTestMBean.java:286)
at 
management.operations.ops.jmx.AbstractTestMBean.executeTest(AbstractTestMBean.java:301)
at 
management.operations.ops.JMXOperations.doJMXTest(JMXOperations.java:105)
at management.test.jmx.JMXTest.doJMXOps(JMXTest.java:841)
at management.test.jmx.JMXTest.HydraTask_jmxOperations(JMXTest.java:214)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at hydra.MethExecutor.execute(MethExecutor.java:182)
at hydra.MethExecutor.execute(MethExecutor.java:150)
at hydra.TestTask.execute(TestTask.java:192)
at hydra.RemoteTestModule$1.run(RemoteTestModule.java:212)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
management.operations.ops.jmx.AbstractTestMBean.runMethod(AbstractTestMBean.java:280)
... 12 more
Caused by: util.TestException: beforeConnectMBeans and registeredMBeans 
mismatch Diff : 
[GemFire:service=CacheService,name=LuceneService,type=Member,member=managinggemfire2_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19965]
at management.test.jmx.JMXTest.cacheStopStart(JMXTest.java:377)
at 
management.operations.ops.jmx.MemberTestMbean.cacheStopStart(MemberTestMbean.java:400)
... 17 more




> CI Failure: beforeConne

WAN Get-Initial-Image

[Michael Stolz]

One way to get a new site populated with data would be through a WAN
gateway by doing a put(k, get(k)) on every local entry in a Partitioned
Region via a server side function. That has the unfortunate side-effect of
firing CacheWriters, CacheListeners and AsyncEventListeners though.

Is there a mechanism by which we could force all data in a Region to be
pushed across the WAN gateway without invoking CacheWriters, CacheListeners
and AsyncEventListeners?

This would make cloud-bursting scenarios work really well.

It would also help anybody who is trying to bring up an additional site or
additional cluster for any production workload.

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771

[jira] [Updated] (GEODE-2245) CI Failure: beforeConnectMBeans and registeredMBeans mismatch Diff : [GemFire:service=CacheService,name=LuceneService,type=Member,member=managinggemfire2_rs-OperationsBTT

[Kevin Duling (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Duling updated GEODE-2245:

Component/s: (was: management)

> CI Failure: beforeConnectMBeans and registeredMBeans mismatch Diff : 
> [GemFire:service=CacheService,name=LuceneService,type=Member,member=managinggemfire2_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19965]
> -
>
> Key: GEODE-2245
> URL: https://issues.apache.org/jira/browse/GEODE-2245
> Project: Geode
>  Issue Type: Bug
>Reporter: Kevin Duling
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2245) CI Failure: beforeConnectMBeans and registeredMBeans mismatch Diff : [GemFire:service=CacheService,name=LuceneService,type=Member,member=managinggemfire2_rs-OperationsBTT

[Kevin Duling (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Duling updated GEODE-2245:

Description: (was: {code}
CLIENT 
vm_6_thr_7_managing1_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19961
TASK[0] management.test.jmx.JMXTest.HydraTask_jmxOperations
ERROR util.TestException: Error running test cacheStopStart

util.TestException: Error running test cacheStopStart
at 
management.util.HydraUtil.logErrorAndRaiseException(HydraUtil.java:84)
at 
management.operations.ops.jmx.AbstractTestMBean.runMethod(AbstractTestMBean.java:286)
at 
management.operations.ops.jmx.AbstractTestMBean.executeTest(AbstractTestMBean.java:301)
at 
management.operations.ops.JMXOperations.doJMXTest(JMXOperations.java:105)
at management.test.jmx.JMXTest.doJMXOps(JMXTest.java:841)
at management.test.jmx.JMXTest.HydraTask_jmxOperations(JMXTest.java:214)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at hydra.MethExecutor.execute(MethExecutor.java:182)
at hydra.MethExecutor.execute(MethExecutor.java:150)
at hydra.TestTask.execute(TestTask.java:192)
at hydra.RemoteTestModule$1.run(RemoteTestModule.java:212)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
management.operations.ops.jmx.AbstractTestMBean.runMethod(AbstractTestMBean.java:280)
... 12 more
Caused by: util.TestException: beforeConnectMBeans and registeredMBeans 
mismatch Diff : 
[GemFire:service=CacheService,name=LuceneService,type=Member,member=managinggemfire2_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19965]
at management.test.jmx.JMXTest.cacheStopStart(JMXTest.java:377)
at 
management.operations.ops.jmx.MemberTestMbean.cacheStopStart(MemberTestMbean.java:400)
... 17 more
{code})

> CI Failure: beforeConnectMBeans and registeredMBeans mismatch Diff : 
> [GemFire:service=CacheService,name=LuceneService,type=Member,member=managinggemfire2_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19965]
> -
>
> Key: GEODE-2245
> URL: https://issues.apache.org/jira/browse/GEODE-2245
> Project: Geode
>  Issue Type: Bug
>Reporter: Kevin Duling
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2245) CI Failure: beforeConnectMBeans and registeredMBeans mismatch Diff : [GemFire:service=CacheService,name=LuceneService,type=Member,member=managinggemfire2_rs-OperationsBTT

[Kevin Duling (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Duling updated GEODE-2245:

Attachment: (was: 
vm_6_managing1_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19961.log)

> CI Failure: beforeConnectMBeans and registeredMBeans mismatch Diff : 
> [GemFire:service=CacheService,name=LuceneService,type=Member,member=managinggemfire2_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19965]
> -
>
> Key: GEODE-2245
> URL: https://issues.apache.org/jira/browse/GEODE-2245
> Project: Geode
>  Issue Type: Bug
>Reporter: Kevin Duling
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2245) .

[Kevin Duling (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Duling updated GEODE-2245:

Summary: .  (was: CI Failure: beforeConnectMBeans and registeredMBeans 
mismatch Diff : 
[GemFire:service=CacheService,name=LuceneService,type=Member,member=managinggemfire2_rs-OperationsBTTest-2016-12-22-22-37-12-client-1_19965])

> .
> -
>
> Key: GEODE-2245
> URL: https://issues.apache.org/jira/browse/GEODE-2245
> Project: Geode
>  Issue Type: Bug
>Reporter: Kevin Duling
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-2245) .

[Kevin Duling (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Duling resolved GEODE-2245.
-
Resolution: Done

> .
> -
>
> Key: GEODE-2245
> URL: https://issues.apache.org/jira/browse/GEODE-2245
> Project: Geode
>  Issue Type: Bug
>Reporter: Kevin Duling
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (GEODE-2245) .

[Kevin Duling (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Duling closed GEODE-2245.
---

> .
> -
>
> Key: GEODE-2245
> URL: https://issues.apache.org/jira/browse/GEODE-2245
> Project: Geode
>  Issue Type: Bug
>Reporter: Kevin Duling
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] geode pull request #325: merge new version

[zmyer]

GitHub user zmyer opened a pull request:

https://github.com/apache/geode/pull/325

merge new version



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/zmyer/incubator-geode develop

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/325.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #325


commit a3e78ce36157f61ee2b5d1c0d7b6fe4f20016d6a
Author: zmyer 
Date:   2016-09-11T14:34:51Z

this is a test

commit cbb0744f2c9e204fe5978139dfb69acc167bb1da
Author: zmyer 
Date:   2016-09-12T15:48:23Z

add author

commit a51905877ad8e049d5f69ef1846998a56ad7a341
Author: zmyer 
Date:   2016-10-01T17:48:57Z

refactor AbstractOp class

commit ecfcf0d5eca39224d683caf5ac54a883d0f0e4ff
Author: zmyer 
Date:   2016-10-02T13:24:22Z

refactor




---
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: WAN Get-Initial-Image

[Anthony Baker]

I don’t know of anyway current API that behaves the way you want.  Snapshot 
imports (`gfsh import data`) avoid firing listeners AND wan replication.  
Getting that working correctly was pretty hairy :-)

I think you would want to avoid local replication costs associated with a put() 
as well.  Perhaps a Region-level API would make more sense.

Anthony

> On Dec 23, 2016, at 9:29 AM, Michael Stolz  wrote:
> 
> One way to get a new site populated with data would be through a WAN
> gateway by doing a put(k, get(k)) on every local entry in a Partitioned
> Region via a server side function. That has the unfortunate side-effect of
> firing CacheWriters, CacheListeners and AsyncEventListeners though.
> 
> Is there a mechanism by which we could force all data in a Region to be
> pushed across the WAN gateway without invoking CacheWriters, CacheListeners
> and AsyncEventListeners?
> 
> This would make cloud-bursting scenarios work really well.
> 
> It would also help anybody who is trying to bring up an additional site or
> additional cluster for any production workload.
> 
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: 631-835-4771

[GitHub] geode issue #325: merge new version

[metatype]

Github user metatype commented on the issue:

https://github.com/apache/geode/pull/325
  
Thanks for the contribution.  However, I'm currently -1 until you clarify 
the purpose of the change and follow some of the recommendations included in 
our project contribution guidelines such as:

- You need to file a JIRA for any change to the code base.  This helps 
drive discussion / consensus and makes it easy to do release notes.
- Separate code reformatting changes from actual logic changes.  This makes 
it easier to review.
- Don't include \@author tags
- Use `git rebase -i` to squash commits like 'this is a test'.  We only 
want to see useful commits in our git history
- We use spotless to manage the source code formatting.  If you want to 
change the format, please start a discussion on the dev@geode list.

See the wiki pages for more details:
https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute

Thanks again!


---
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.
---

Review Request 55017: cleaning up code in a few places

[Bruce Schuchardt]

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

Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo Kohlmeyer.


Repository: geode


Description
---

While investigating a couple of failures I ran across a few things that needed 
to be fixed.

1. EndpointManagerImpl was skipping notification of listeners if there was no 
member ID in an endpoint but the member ID is no longer used.  I removed the 
check.
2. During a Forced Disconnect CacheClientProxy was skipping a lot of clean-up 
because it was expecting a CacheClosedException instead of a CancelException.  
We should never catch CacheClosedException - always catch CancelException.
3. When SSL is being used the P2P Reader Threads were not setting connection 
attributes in the thread's name like we do with non-SSL reader threads.  This 
made debugging an SSL failure a bit more difficult.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/cache/client/internal/EndpointManagerImpl.java
 6d5d9d689bab90895e8035b3055a2fb543b29f54 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/CacheClientProxy.java
 6e31fe5488b64f9c5b4a4c867e72fc2c60e40591 
  geode-core/src/main/java/org/apache/geode/internal/tcp/Connection.java 
d44476f2f6f9387b390ea7e3758a057e43edef5a 

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


Testing
---

precheckin, integration testing


Thanks,

Bruce Schuchardt

Re: WAN Get-Initial-Image

[Michael Stolz]

Oh yeah, I meant to mention local replication too but forgot.

What kind of Region-level API are you thinking of?

Something that the new cluster could call via a pool to pull the data for a
region?

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771

On Fri, Dec 23, 2016 at 12:48 PM, Anthony Baker  wrote:

> I don’t know of anyway current API that behaves the way you want.
> Snapshot imports (`gfsh import data`) avoid firing listeners AND wan
> replication.  Getting that working correctly was pretty hairy :-)
>
> I think you would want to avoid local replication costs associated with a
> put() as well.  Perhaps a Region-level API would make more sense.
>
> Anthony
>
> > On Dec 23, 2016, at 9:29 AM, Michael Stolz  wrote:
> >
> > One way to get a new site populated with data would be through a WAN
> > gateway by doing a put(k, get(k)) on every local entry in a Partitioned
> > Region via a server side function. That has the unfortunate side-effect
> of
> > firing CacheWriters, CacheListeners and AsyncEventListeners though.
> >
> > Is there a mechanism by which we could force all data in a Region to be
> > pushed across the WAN gateway without invoking CacheWriters,
> CacheListeners
> > and AsyncEventListeners?
> >
> > This would make cloud-bursting scenarios work really well.
> >
> > It would also help anybody who is trying to bring up an additional site
> or
> > additional cluster for any production workload.
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: 631-835-4771
>
>

Re: Review Request 54943: GEODE-2197: refactor cluster config

[Kirk Lund]

> On Dec. 21, 2016, 8:52 p.m., Bruce Schuchardt wrote:
> > geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java,
> >  line 743
> > 
> >
> > I can't tell from the diff if this method is rolling-upgrade safe.  If 
> > it's just used during jar deployment then there's no problem.  If it's used 
> > during locator start-up then it will not work during rolling upgrade and 
> > backward-compatibility needs to be addressed.
> > 
> > If it's just used during jar deployment then you can ignore this 
> > comment.
> 
> Jinmei Liao wrote:
> This is used in locator start-up. So in rolling-upgrade scenario, we 
> would have a locator in 9.1 trying to start up and contacting locator in 9.0 
> which doesn't have this function?
> 
> Jinmei Liao wrote:
> In this case, we should be fine. Locator A before shutting down, should 
> have all the deployed jars in its cluster_config directory, when it starts up 
> with newer version, it shouldn't be trying to contact other locators to get 
> the jars because all the deployed jars it knows of is already in it's working 
> dir (it only goes to download jars from other locator when the jar is not in 
> it's own file system).
> 
> This code is run when a new locator gets started up. we won't run into 
> problems as long as we finish rolling upgrade all the existing locators 
> before starting up new locator.

It would be safest to write a rolling-upgrade test that involves cluster config 
and jar deployment (even if we write that test as a follow-up to this change).


- Kirk


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


On Dec. 22, 2016, 6:48 a.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54943/
> ---
> 
> (Updated Dec. 22, 2016, 6:48 a.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Jared Stewart, John Blum, Kevin 
> Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * not to save the xml, properties in the file system, only in the internal 
> region.
> * the cc region's change listener is to download the jar from other locators
> 
> 
> GEODE-2197: refactor cluster config and fix the test failures
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java
>  3119823d6b8886cf893fd38ed58ca90b0c28eeb5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportSharedConfigurationFunction.java
>  821e04b2c590bddd28b0727e504c6460d77cf709 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ImportSharedConfigurationArtifactsFunction.java
>  2ddeda69177b2aea41ee1d1318d8fdb19324a20b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/SharedConfigurationWriter.java
>  3af55874282d380e340874a24860fafad7ace126 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/callbacks/ConfigurationChangeListener.java
>  c08ba924b652c05436f921c19d65392fd7f6859b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/domain/Configuration.java
>  4adf2110c4a270127adda1a5090d537a5e2de8c1 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/ModifyPropertiesFunction.java
>  075993716c1afe47ca116727994a3a3661d35a61 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/utils/XmlUtils.java
>  0b4e0f617cf4b5b91f49dc185d7c02b6b7fe0472 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/SharedConfigurationJUnitTest.java
>  4787c6665cb62eb3dbfe18f3e0128f572d5a36b4 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
>  63c88dd1aa521a6781a8e07567df661cd42fb6f7 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
>  da4fcf9be6637ddd79403f0a01cb2ba1823f7bd4 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
>  c135f3d9b3370b4a756a2c7688530c63a4e06d77 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
>  cfcbeed86ade004eb305d9a01d6fb128132a21ac 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/sanctionedSerializables.txt
>  d6b770f6c9b18e8c090045a66864a027f0ad8062 
> 
> Diff: https://reviews.apache.org/r/54943/diff/
> 
> 
> Testing
> ---
> 
> precheckin successful
> 
> 
> Thanks,
> 
> Jinmei Lia

Re: Review Request 54945: GEODE-419: Added test to test fail over to javax properties if ssl enabled but relevant properties are not set

[Kirk Lund]

> On Dec. 22, 2016, 6:34 p.m., Bruce Schuchardt wrote:
> > I think you should save the system properties in a @Before and restore them 
> > in an @After

Just add RestoreSystemProperties as a JUnit Rule:

@Rule
public RestoreSystemProperties restoreSystemProperties = new 
RestoreSystemProperties();

The Rule takes a snapshot of the system properties in before and restores them 
in after.


- Kirk


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


On Dec. 21, 2016, 7:25 p.m., Udo Kohlmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54945/
> ---
> 
> (Updated Dec. 21, 2016, 7:25 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> If ssl is enabled but neither ssl-keystore or cluster-ssl-keystore properties 
> are set, the ssl configuration behavior should be to fail over to javas 
> properties (if provided). This seemed not to work in the previous ssl 
> configuration implementation, but seems to be now fixed in the newer 
> SSLConfiguration implementation.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/net/SSLConfigurationFactory.java
>  aa61ca36e 
>   
> geode-core/src/test/java/org/apache/geode/internal/net/SSLConfigurationFactoryJUnitTest.java
>  38d4d87b3 
> 
> Diff: https://reviews.apache.org/r/54945/diff/
> 
> 
> Testing
> ---
> 
> Added test to test scenario. No code was changed for this.
> 
> 
> Thanks,
> 
> Udo Kohlmeyer
> 
>

Re: Review Request 54945: GEODE-419: Added test to test fail over to javax properties if ssl enabled but relevant properties are not set

[Kirk Lund]

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


Ship it!




Add use of RestoreSystemProperties rule and then Ship It!

- Kirk Lund


On Dec. 21, 2016, 7:25 p.m., Udo Kohlmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54945/
> ---
> 
> (Updated Dec. 21, 2016, 7:25 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> If ssl is enabled but neither ssl-keystore or cluster-ssl-keystore properties 
> are set, the ssl configuration behavior should be to fail over to javas 
> properties (if provided). This seemed not to work in the previous ssl 
> configuration implementation, but seems to be now fixed in the newer 
> SSLConfiguration implementation.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/net/SSLConfigurationFactory.java
>  aa61ca36e 
>   
> geode-core/src/test/java/org/apache/geode/internal/net/SSLConfigurationFactoryJUnitTest.java
>  38d4d87b3 
> 
> Diff: https://reviews.apache.org/r/54945/diff/
> 
> 
> Testing
> ---
> 
> Added test to test scenario. No code was changed for this.
> 
> 
> Thanks,
> 
> Udo Kohlmeyer
> 
>

Re: snappy-java dependency version

[Kirk Lund]

Just to tie this thread up, use of SnappyCompressor (using org.iq80.snappy)
does work on Solaris:

gfsh>create region --type=REPLICATE --name=region1
--compressor=org.apache.geode.compression.SnappyCompressor
Member  | Status
--- | --
server1 | Region "/region1" created on "server1"

And the resulting region seems to work fine.

-Kirk


On Wed, Dec 21, 2016 at 10:36 AM, Dan Smith  wrote:

> We switched to org.iq80.snappy because that's a pure java implementation,
> as opposed to just a wrapper around the C++ implementation. See GEODE-1573
>  for some details.
>
> I'm kinda surprised it doesn't work on Solaris. We switched to the new
> version to avoid these sort of cross platform compatibility issues. How is
> it failing on Solaris?
>
> Here's the github page for this new snappy implementation:
> https://github.com/dain/snappy/
>
> -Dan
>
> On Wed, Dec 21, 2016 at 9:40 AM, Kirk Lund  wrote:
>
> > More info: I'm looking at the snappy dependency in Apache Geode because a
> > user reported that SnappyCompressor in Apache 1.0.0-incubating doesn't
> work
> > on Solaris x86.
> >
> > Hmm, I see that Geode uses org.iq80.snappy (latest version is 0.4):
> >
> > org.iq80.snappy:snappy:0.4
> >
> > Previous versions of GemFire used org.xerial.snappy (latest version is
> > 1.1.2.6):
> >
> > org.xerial.snappy:snappy-java:1.0.4.1
> >
> > Additional questions:
> >
> > Do we know why we changed from org.xerial.snappy to org.iq80.snappy? Was
> > this change made because org.xerial.snappy is not compatible with Apache
> > licenses? And does this change the platforms that SnappyCompressor will
> > work on?
> >
> > Thanks,
> > Kirk
> >
> >
> > On Wed, Dec 21, 2016 at 9:28 AM, Kirk Lund  wrote:
> >
> > > I'm looking at gradle/dependency-versions.properties and I'm not sure
> > the
> > > snappy-java.version is correct:
> > >
> > > snappy-java.version=0.4
> > >
> > > 0.4 would be a very old version. GemFire 8.x uses 1.0.4.1:
> > >
> > > 
> > > 
> > >
> > > Anyone know why it would be set to 0.4 in Geode? Or is 0.4 some weird
> > > alias for 1.0.4.1??
> > >
> > > Thanks,
> > > Kirk
> > >
> > >
> >
>

[jira] [Commented] (GEODE-2235) test is missing @Test: PrCqUsingPoolDUnitTest.testCqOnAccessorServerWithUpdatesResultingInDestroyedCQEvents

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773532#comment-15773532
 ] 

ASF subversion and git services commented on GEODE-2235:


Commit b41c152d286780153e5fee1471838bc50930309f in geode's branch 
refs/heads/develop from shankar
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=b41c152 ]

GEODE-2235: add missing test annotation

Added @test annotation to 
testCqOnAccessorServerWithUpdatesResultingInDestroyedCQEvents test

This closes #324


> test is missing @Test: 
> PrCqUsingPoolDUnitTest.testCqOnAccessorServerWithUpdatesResultingInDestroyedCQEvents
> ---
>
> Key: GEODE-2235
> URL: https://issues.apache.org/jira/browse/GEODE-2235
> Project: Geode
>  Issue Type: Test
>  Components: cq
>Reporter: Bruce Schuchardt
>
> I noticed that this test is missing @Test.  It wasn't added when we switched 
> to JUnit4 so it's no longer being executed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] geode pull request #324: GEODE-2235 : Adding missing test annotation

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/324


---
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.
---

[jira] [Commented] (GEODE-2235) test is missing @Test: PrCqUsingPoolDUnitTest.testCqOnAccessorServerWithUpdatesResultingInDestroyedCQEvents

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773534#comment-15773534
 ] 

ASF GitHub Bot commented on GEODE-2235:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/324


> test is missing @Test: 
> PrCqUsingPoolDUnitTest.testCqOnAccessorServerWithUpdatesResultingInDestroyedCQEvents
> ---
>
> Key: GEODE-2235
> URL: https://issues.apache.org/jira/browse/GEODE-2235
> Project: Geode
>  Issue Type: Test
>  Components: cq
>Reporter: Bruce Schuchardt
>
> I noticed that this test is missing @Test.  It wasn't added when we switched 
> to JUnit4 so it's no longer being executed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Strategy for Updating Public API Changes

[Darrel Schneider]

If changing an external API would break existing applications I think it
would be better to introduce a new API that has the improved behavior.
Deprecate the old external API with a comment saying that you should use
the new one instead. Then in the next release we can remove the old
external deprecated API since users had a release to switch to the new one.


On Thu, Dec 22, 2016 at 6:57 PM, Alyssa Kim  wrote:

> Hi,
>
> Related Jira : https://issues.apache.org/jira/browse/GEODE-1577
>
> Summary : Replacing wildcards with generic types requires changes in
> applications that use this method. Probably there are other jiras that
> update public APIs too. How do we to handle this?
> 1. Just update the API whenever it's completed.
> 2. Wait until a significant number of API changes are made and update at
> once.
> 3. Other ideas
>
> Description:
>
>  We have GEODE-1577 in which we replaced wildcard return types of execute
> method with generic types. This will break the existing applications that
> use this method at the compilation level which is what happens every time
> we update a public API. So, it is suggested that "we might want to tackle
> all the function API improvements at once" to minimize complexity of
> updates.
>
>   If we do want to update all the function APIs at once, I believe we need
> a list of all APIs that are expected to be updated and put on hold for
> dev-completed jiras related to public API chenages until most of them are
> ready to be updated. (probably somebody has to keep the track of those
> issues via jira tag or label)
>
>  Alternatively, if anyone has a good strategy to handle this (or if there
> is already one), please let me know.
>
>
> Best Regards,
> Alyssa Kim
>

[GitHub] geode issue #321: [GEODE-1577] Unhelpful generic types on Execution.execute

[kirklund]

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/321
  
@dalyssakim @metatype @upthewaterspout GEODE-1577 is interesting because 
Dan labelled it "starter" which would imply that a new contributor should be 
able to pick it up and run with it without having a dev-list discussion about 
public API changes. I'm curious what Dan's expectation was in comparison to 
Anthony's feedback -- it looks like Alyssa's changes are exactly what Dan had 
in mind. Let's see what Dan's feedback is (he may be on holiday leave right 
now).


---
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.
---

[jira] [Commented] (GEODE-1577) Unhelpful generic types on Execution.execute

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773558#comment-15773558
 ] 

ASF GitHub Bot commented on GEODE-1577:
---

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/321
  
@dalyssakim @metatype @upthewaterspout GEODE-1577 is interesting because 
Dan labelled it "starter" which would imply that a new contributor should be 
able to pick it up and run with it without having a dev-list discussion about 
public API changes. I'm curious what Dan's expectation was in comparison to 
Anthony's feedback -- it looks like Alyssa's changes are exactly what Dan had 
in mind. Let's see what Dan's feedback is (he may be on holiday leave right 
now).


> Unhelpful generic types on Execution.execute
> 
>
> Key: GEODE-1577
> URL: https://issues.apache.org/jira/browse/GEODE-1577
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Dan Smith
>Assignee: Alyssa Kim
>  Labels: starter
>
> The execute methods of the function service Execution class returns a 
> ResultCollector with wildcards for the type.
> {code}  
> public ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> Wildcards are supposed to be used in APIs where the type doesn't matter, for 
> example counting the elements in a list. By returning a ResultCollector with 
> wildcards, we're essentially forcing the user to cast the result collector.
> At a minimum they should be able to pick the type of result collector
> {code}
>   public  ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> But maybe it would make more sense to parameterize Execution itself. Then the 
> compiler could ensure that the types used by withCollector and the types used 
> by execute match.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Nightly build takes too long

[Kirk Lund]

Geode-nightly #694 failed again because it took too long (over 12 hours).

What can we do to break up the nightly build to avoid this? Divide it into
two jobs: 1) test and integrationTest, 2) distributedTest?

Thanks,
Kirk

Re: Nightly build takes too long

[Kirk Lund]

Nevermind. This one failed due to a BindException.

It's still probably a good idea to break up the nightly build since it's
taking over 12 hours.

-Kirk


On Fri, Dec 23, 2016 at 11:51 AM, Kirk Lund  wrote:

> Geode-nightly #694 failed again because it took too long (over 12 hours).
>
> What can we do to break up the nightly build to avoid this? Divide it into
> two jobs: 1) test and integrationTest, 2) distributedTest?
>
> Thanks,
> Kirk
>
>

Re: Strategy for Updating Public API Changes

[Michael Stolz]

+1 that's exactly what deprecation is for

--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771
On Dec 23, 2016 2:37 PM, "Darrel Schneider"  wrote:

> If changing an external API would break existing applications I think it
> would be better to introduce a new API that has the improved behavior.
> Deprecate the old external API with a comment saying that you should use
> the new one instead. Then in the next release we can remove the old
> external deprecated API since users had a release to switch to the new one.
>
>
> On Thu, Dec 22, 2016 at 6:57 PM, Alyssa Kim  wrote:
>
> > Hi,
> >
> > Related Jira : https://issues.apache.org/jira/browse/GEODE-1577
> >
> > Summary : Replacing wildcards with generic types requires changes in
> > applications that use this method. Probably there are other jiras that
> > update public APIs too. How do we to handle this?
> > 1. Just update the API whenever it's completed.
> > 2. Wait until a significant number of API changes are made and update at
> > once.
> > 3. Other ideas
> >
> > Description:
> >
> >  We have GEODE-1577 in which we replaced wildcard return types of execute
> > method with generic types. This will break the existing applications that
> > use this method at the compilation level which is what happens every time
> > we update a public API. So, it is suggested that "we might want to tackle
> > all the function API improvements at once" to minimize complexity of
> > updates.
> >
> >   If we do want to update all the function APIs at once, I believe we
> need
> > a list of all APIs that are expected to be updated and put on hold for
> > dev-completed jiras related to public API chenages until most of them are
> > ready to be updated. (probably somebody has to keep the track of those
> > issues via jira tag or label)
> >
> >  Alternatively, if anyone has a good strategy to handle this (or if there
> > is already one), please let me know.
> >
> >
> > Best Regards,
> > Alyssa Kim
> >
>

[jira] [Commented] (GEODE-2239) CI failure: org.apache.geode.pdx.JSONFormatterJUnitTest.testJSONFormatterAPIs

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773599#comment-15773599
 ] 

Darrel Schneider commented on GEODE-2239:
-

I think this test can be safely changed to not bind on a specific port. I 
commented out these two lines and the test still passes:
diff --git 
a/geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java 
b/geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java
index 979da13..95d112c 100755
--- a/geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java
+++ b/geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java
@@ -55,8 +55,8 @@ public class JSONFormatterJUnitTest {
 
 // start cache-server
 CacheServer server = c.addCacheServer();
-final int serverPort = 40405;
-server.setPort(serverPort);
+//final int serverPort = 40405;
+//server.setPort(serverPort);
 server.start();
 
 // Create region, primitiveKVStore


> CI failure: org.apache.geode.pdx.JSONFormatterJUnitTest.testJSONFormatterAPIs
> -
>
> Key: GEODE-2239
> URL: https://issues.apache.org/jira/browse/GEODE-2239
> Project: Geode
>  Issue Type: Bug
>  Components: serialization
>Reporter: Bruce Schuchardt
>  Labels: ci, flaky
>
> This test failed in Jenkins build #692.  It has a hard-coded port 40405 and 
> fails if the port isn't available.  
> https://builds.apache.org/job/Geode-nightly/692/testReport/
> {noformat}
>  org.apache.geode.pdx.JSONFormatterJUnitTest.testJSONFormatterAPIs
>  Error Details
> java.net.BindException: Failed to create server socket on  null[40,405]
>  Stack Trace
> java.net.BindException: Failed to create server socket on  null[40,405]
>   at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:782)
>   at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:744)
>   at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:711)
>   at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:436)
>   at 
> org.apache.geode.internal.cache.CacheServerImpl.start(CacheServerImpl.java:318)
>   at 
> org.apache.geode.pdx.JSONFormatterJUnitTest.setUp(JSONFormatterJUnitTest.java:59)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   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 
> 

Re: Nightly build takes too long

[Kevin Duling]

+1  Twelve hours is a long time.

On Fri, Dec 23, 2016 at 11:55 AM, Kirk Lund  wrote:

> Nevermind. This one failed due to a BindException.
>
> It's still probably a good idea to break up the nightly build since it's
> taking over 12 hours.
>
> -Kirk
>
>
> On Fri, Dec 23, 2016 at 11:51 AM, Kirk Lund  wrote:
>
> > Geode-nightly #694 failed again because it took too long (over 12 hours).
> >
> > What can we do to break up the nightly build to avoid this? Divide it
> into
> > two jobs: 1) test and integrationTest, 2) distributedTest?
> >
> > Thanks,
> > Kirk
> >
> >
>

[jira] [Commented] (GEODE-2231) Create new partitioning example

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773683#comment-15773683
 ] 

ASF subversion and git services commented on GEODE-2231:


Commit fd82ea1650a9692d3a8101f84369e799036d704f in geode's branch 
refs/heads/feature/GEODE-2231 from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=fd82ea1 ]

GEODE-2231 package path component rename for consistency


> Create new partitioning example
> ---
>
> Key: GEODE-2231
> URL: https://issues.apache.org/jira/browse/GEODE-2231
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>Priority: Minor
>
> Add a new example to the geode-examples that demonstrates partitioning.
> The example will use the same structure as the replicated example, starting 2 
> servers that host a partitioned region (with no redundant copies).  Run the 
> producer to populate the region.  Run the consumer to see the contents of the 
> region. Then, stop one of the servers and run the consumer again to notice 
> that only roughly half (with 2 servers and hopefully a reasonable hash) of 
> the entries are present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2231) Create new partitioning example

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773684#comment-15773684
 ] 

ASF subversion and git services commented on GEODE-2231:


Commit b440f4de2f51eda5369df4542003ab1237740f1e in geode's branch 
refs/heads/feature/GEODE-2231 from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=b440f4d ]

GEODE-2231 spelling fix and better specification of a path


> Create new partitioning example
> ---
>
> Key: GEODE-2231
> URL: https://issues.apache.org/jira/browse/GEODE-2231
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>Priority: Minor
>
> Add a new example to the geode-examples that demonstrates partitioning.
> The example will use the same structure as the replicated example, starting 2 
> servers that host a partitioned region (with no redundant copies).  Run the 
> producer to populate the region.  Run the consumer to see the contents of the 
> region. Then, stop one of the servers and run the consumer again to notice 
> that only roughly half (with 2 servers and hopefully a reasonable hash) of 
> the entries are present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2109) calling submit on ExecutionService can cause exceptions to be lost

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773690#comment-15773690
 ] 

ASF subversion and git services commented on GEODE-2109:


Commit bb3d20f41d8b9f4e663d6ae7ddbd83ad8de01e77 in geode's branch 
refs/heads/feature/GEODE-2231 from [~deepak.dixit]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=bb3d20f ]

GEODE-2109: Replacing ExecutorService.submit calls with ExecutorService.execute 
call.

This will allow exceptions from those threads to be logged.

Refactored DiskStore task for delayed writes, we cannot replace
expensive writes tasks submit call with execute as later we check if
write call is completed or not.  Replaced submit call by execute in case
of DiskStore tasks like compactions, creating KRF's.

Replaced submit call for GIITask and RemoveMember tasks. GIITask is used
when adding member or starting managing activity when node becomes
managing node. While adding member we can make the
ExecutorService.execute call. Did not change the call for GIITask when
invoked from managing activity as possible exception is handled.

Added LoggingThreadGroup for SingleHopClientExecutor

This closes #296


> calling submit on ExecutionService can cause exceptions to be lost
> --
>
> Key: GEODE-2109
> URL: https://issues.apache.org/jira/browse/GEODE-2109
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
> Fix For: 1.1.0
>
>
> Geode has a number of places that call submit on ExecutionService. The submit 
> method returns a Future object. If the caller makes sure it calls "get" on 
> the Future then all is well. But in many places geode is not calling get. In 
> that case if the Runnable that was submitted throws an exception it gets 
> stored in the get and never logged. This can make it very hard to diagnose 
> problems.
> If the caller does not want to call get on the returned Future then it should 
> instead call the "execute" method. In that case the exception will be 
> unhandled and the unhandled exception handler code we have on the 
> LoggingThreadGroup class will cause the exception to be logged.
> Here are the places that should be changed to use execute instead of submit:
> org.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap.clear()
> org.apache.geode.internal.cache.DiskStoreImpl.executeDiskStoreTask(Runnable)
> org.apache.geode.internal.cache.lru.HeapEvictor.onEvent(MemoryEvent)
> org.apache.geode.distributed.internal.InternalLocator.restartWithDS(InternalDistributedSystem,
>  GemFireCacheImpl)
> org.apache.geode.distributed.internal.FunctionExecutionPooledExecutor.FunctionExecutionPooledExecutor(BlockingQueue,
>  int, PoolStatHelper, ThreadFactory, int, boolean)
> org.apache.geode.internal.cache.PRHARedundancyProvider.scheduleCreateMissingBuckets()
> org.apache.geode.distributed.internal.InternalLocator.startSharedConfigurationService(GemFireCacheImpl)
> org.apache.geode.cache.client.internal.SingleHopClientExecutor.submitTask(Runnable)
> org.apache.geode.management.internal.FederatingManager.submitTask(Callable)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2242) Destroy operations on PRELOADED regions are not applied in the receiving WAN site

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773697#comment-15773697
 ] 

ASF subversion and git services commented on GEODE-2242:


Commit e8b03881317aaa254af641ce1d4d554b239ab002 in geode's branch 
refs/heads/feature/GEODE-2231 from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=e8b0388 ]

GEODE-2242: Invalid VersionTags are no longer replicated across the WAN


> Destroy operations on PRELOADED regions are not applied in the receiving WAN 
> site
> -
>
> Key: GEODE-2242
> URL: https://issues.apache.org/jira/browse/GEODE-2242
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
> Fix For: 1.1.0
>
>
> In the receiving site, all the processing in 
> AbstractRegionEntry.processGatewayTag fails for the destroy event, a 
> ConcurrentCacheModificationException is thrown, and the destroy event is not 
> applied.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-165) Add build support for generating antlr classes from grammar

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773694#comment-15773694
 ] 

ASF subversion and git services commented on GEODE-165:
---

Commit 16e2cfcdd9fc0fb9c7e5213cf68c68257cba7780 in geode's branch 
refs/heads/feature/GEODE-2231 from [~adongre]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=16e2cfc ]

GEODE-165: Removed OQL generated files and added the target into 
geode-core/build.gradle.

GEODE-165 : Updating spotless configuration to exclude 'generated-src' 
directory.


> Add build support for generating antlr classes from grammar
> ---
>
> Key: GEODE-165
> URL: https://issues.apache.org/jira/browse/GEODE-165
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Avinash Dongre
>
> The OQL engine currently uses antlr to generate some parsing classes from 
> gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/oql.g
> These are the generated classes. They are currently checked into the source.
> OQLLexer.java
> OQLLexerTokenTypes.java
> OQLLexerTokenTypes.txt
> OQLParser.java
> They can be generated manually by running antlr.Tool on the provided grammar.
> cd gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/
> java -cp antlr.jar antlr.Tool oql.g
> We should add support to the gradle build to generate these classes.
> In my opinion we should also remove the checked in classes. With gradle we 
> can configure things so that the gradle eclipse target will generate these 
> classes and make them available to the IDE as well. Look at 
> gemfire-core/build.gradle for how we do this with the version properties file:
> sourceSets {
>   main {
> output.dir(generatedResources, builtBy: 'createVersionPropertiesFile')
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-165) Add build support for generating antlr classes from grammar

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773693#comment-15773693
 ] 

ASF subversion and git services commented on GEODE-165:
---

Commit 16e2cfcdd9fc0fb9c7e5213cf68c68257cba7780 in geode's branch 
refs/heads/feature/GEODE-2231 from [~adongre]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=16e2cfc ]

GEODE-165: Removed OQL generated files and added the target into 
geode-core/build.gradle.

GEODE-165 : Updating spotless configuration to exclude 'generated-src' 
directory.


> Add build support for generating antlr classes from grammar
> ---
>
> Key: GEODE-165
> URL: https://issues.apache.org/jira/browse/GEODE-165
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Avinash Dongre
>
> The OQL engine currently uses antlr to generate some parsing classes from 
> gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/oql.g
> These are the generated classes. They are currently checked into the source.
> OQLLexer.java
> OQLLexerTokenTypes.java
> OQLLexerTokenTypes.txt
> OQLParser.java
> They can be generated manually by running antlr.Tool on the provided grammar.
> cd gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/
> java -cp antlr.jar antlr.Tool oql.g
> We should add support to the gradle build to generate these classes.
> In my opinion we should also remove the checked in classes. With gradle we 
> can configure things so that the gradle eclipse target will generate these 
> classes and make them available to the IDE as well. Look at 
> gemfire-core/build.gradle for how we do this with the version properties file:
> sourceSets {
>   main {
> output.dir(generatedResources, builtBy: 'createVersionPropertiesFile')
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2099) Race condition in ConnectToLocatorSSLDUnitTest

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773698#comment-15773698
 ] 

ASF subversion and git services commented on GEODE-2099:


Commit 577bda1844e7b4dbb90626ae2fdd539f3c45ac6a in geode's branch 
refs/heads/feature/GEODE-2231 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=577bda1 ]

GEODE-2099: The GfshConnectorRule has been refactored to use awaitility to wait 
and retry till connection is ready.

* remove the flaky category


> Race condition in ConnectToLocatorSSLDUnitTest
> --
>
> Key: GEODE-2099
> URL: https://issues.apache.org/jira/browse/GEODE-2099
> Project: Geode
>  Issue Type: Bug
>  Components: management, tests
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>  Labels: Flaky
> Fix For: 1.1.0
>
>
> This test contains 3 tests, if put a long enough wait or a break point in 
> between the tests, the tests would pass, otherwise the last two tests would 
> fail. Need to get to the bottom of this. For the last tests are ignored. This 
> is happening after we have to put "disconnect" after each connect to properly 
> close the jmx thread so that it wouldn't pollute other tests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2234) Lucene query hit stats shows number higher than number of calls

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773696#comment-15773696
 ] 

ASF subversion and git services commented on GEODE-2234:


Commit 32b8a004f16a9bc6ac44ee62ad64f863a131dd35 in geode's branch 
refs/heads/feature/GEODE-2231 from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=32b8a00 ]

GEODE-2234: Query stats are now calculated per member in the LuceneFunction


> Lucene query hit stats shows number higher than number of calls
> ---
>
> Key: GEODE-2234
> URL: https://issues.apache.org/jira/browse/GEODE-2234
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
> Fix For: 1.1.0
>
>
> Scenario:
> System with 0 entries
> Add 2 entries
> Query 1 time.
> Add the same 2 entries (update)
> Query 1 time.
> Result:
> {noformat}
> gfsh>list lucene indexes --with-stats
> Index Name | Region Path | Indexed Fields | Field Analyzer | Query Executions 
> | Updates | Commits | Documents
> -- | --- | -- | -- |  
> | --- | --- | -
> customerF1 | /Customer   | [f1]   | {} | 0
> | 0   | 0   | 0
> customerF1 | /Customer   | [f1]   | {} | 0
> | 0   | 0   | 0
> gfsh>list lucene indexes --with-stats
> Index Name | Region Path | Indexed Fields | Field Analyzer | Query Executions 
> | Updates | Commits | Documents
> -- | --- | -- | -- |  
> | --- | --- | -
> customerF1 | /Customer   | [f1]   | {} | 112  
> | 2   | 2   | 1
> customerF1 | /Customer   | [f1]   | {} | 114  
> | 2   | 2   | 1
> gfsh>list lucene indexes --with-stats
> Index Name | Region Path | Indexed Fields | Field Analyzer | Query Executions 
> | Updates | Commits | Documents
> -- | --- | -- | -- |  
> | --- | --- | -
> customerF1 | /Customer   | [f1]   | {} | 224  
> | 3   | 3   | 1
> customerF1 | /Customer   | [f1]   | {} | 228  
> | 3   | 3   | 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2243) Modify path to spotless formatter

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773691#comment-15773691
 ] 

ASF subversion and git services commented on GEODE-2243:


Commit f1846b1cd30624809a95c8ae7d7c053c15818564 in geode's branch 
refs/heads/feature/GEODE-2231 from [~jens.deppe]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=f1846b1 ]

GEODE-2243: Adjust path of spotless formatter

- This allows projects which depend on Geode to use Geode's formatter

Signed-off-by: Scott Jewell 


> Modify path to spotless formatter
> -
>
> Key: GEODE-2243
> URL: https://issues.apache.org/jira/browse/GEODE-2243
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>
> Modify path to spotless formatter xml slightly so that it can be used from 
> closed side.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2243) Modify path to spotless formatter

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773692#comment-15773692
 ] 

ASF subversion and git services commented on GEODE-2243:


Commit 24097a8de481c3c3b09d7b84944d740f932d58f4 in geode's branch 
refs/heads/feature/GEODE-2231 from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=24097a8 ]

Revert "GEODE-2243: Adjust path of spotless formatter"

This reverts commit c1998d7398b837ee1e699bfd1952719443045d71.


> Modify path to spotless formatter
> -
>
> Key: GEODE-2243
> URL: https://issues.apache.org/jira/browse/GEODE-2243
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>
> Modify path to spotless formatter xml slightly so that it can be used from 
> closed side.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2240) unexpected NullPointerException from Tombstone service

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773699#comment-15773699
 ] 

ASF subversion and git services commented on GEODE-2240:


Commit 7fe382342c17f938c67da29472218ecda41d410e in geode's branch 
refs/heads/feature/GEODE-2231 from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=7fe3823 ]

GEODE-2240: fix unsafe concurrent access of ArrayList
When adding to the expiredTombstones ArrayList the code
now holds a sync on getBlockGCLock.


> unexpected NullPointerException from Tombstone service
> --
>
> Key: GEODE-2240
> URL: https://issues.apache.org/jira/browse/GEODE-2240
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.1.0
>
>
> A test failed and the logs were found to be full of NPEs from the tombstone 
> service:[severe 2016/12/20 02:04:35.605 UTC 
> dataStoregemfire7_rs-StorageBTTest-2016-12-19-23-35-42-client-14_19508 
>  tid=0x44] GemFire garbage 
> collection service encountered an unexpected exception
> java.lang.NullPointerException
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.lambda$purgeObsoleteTombstones$1(TombstoneService.java:938)
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.removeExpiredIf(TombstoneService.java:479)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.removeIf(TombstoneService.java:823)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.purgeObsoleteTombstones(TombstoneService.java:937)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:880)
> at java.lang.Thread.run(Thread.java:745)
> [severe 2016/12/20 02:05:45.987 UTC 
> dataStoregemfire7_rs-StorageBTTest-2016-12-19-23-35-42-client-14_19508 
>  tid=0x44] GemFire garbage 
> collection service encountered an unexpected exception
> java.lang.NullPointerException
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.expireBatch(TombstoneService.java:524)
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.checkExpiredTombstoneGC(TombstoneService.java:594)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:878)
> at java.lang.Thread.run(Thread.java:745)
> Both of these stacks indicate that the "expiredTombstones" ArrayList somehow 
> has nulls in it. It is an ArrayList of Tombstone instances and the only code 
> that adds to it first tests that the item it is adding is not null. The only 
> other modify operation done on it is to remove an item.
> Perhaps unsafe concurrent access is happening causing this code to see nulls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2238) Member may fail to receive cluster configuration from locator

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773695#comment-15773695
 ] 

ASF subversion and git services commented on GEODE-2238:


Commit 93994481e361d590ae201e7cbecfd18ee45603b4 in geode's branch 
refs/heads/feature/GEODE-2231 from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=9399448 ]

GEODE-2238: Fix how peers discover locators with cluster config

Call super.process last in StartupResponseWithVersionMessage, so that
that threads waiting on the response will have the results of
dm.addHostedLocators.


> Member may fail to receive cluster configuration from locator
> -
>
> Key: GEODE-2238
> URL: https://issues.apache.org/jira/browse/GEODE-2238
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>  Labels: Flaky
>
> LuceneClusterConfigurationDUnitTest.indexWithAnalyzerGetsCreatedUsingClusterConfiguration
>  is failing frequently in precheckin. I'm going to mark it as FlakyTest. 
> Below is the stack trace:
> {noformat}
> :geode-lucene:distributedTest
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest
>  > indexWithAnalyzerGetsCreatedUsingClusterConfiguration FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest$$Lambda$29/613305101.run
>  in VM 2 running on Host 3fb23bc375ef with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
> at org.apache.geode.test.dunit.rules.Member.invoke(Member.java:60)
> at 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest.indexWithAnalyzerGetsCreatedUsingClusterConfiguration(LuceneClusterConfigurationDUnitTest.java:102)
> Caused by:
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest.lambda$indexWithAnalyzerGetsCreatedUsingClusterConfiguration$bb17a952$1(LuceneClusterConfigurationDUnitTest.java:105)
> 94 tests completed, 1 failed
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2231) Create new partitioning example

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773723#comment-15773723
 ] 

ASF subversion and git services commented on GEODE-2231:


Commit c46209ae8fa11b88637e0b46073d9446ea4f62aa in geode's branch 
refs/heads/feature/GEODE-2231 from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c46209a ]

GEODE-2231 Add a partitioned region example


> Create new partitioning example
> ---
>
> Key: GEODE-2231
> URL: https://issues.apache.org/jira/browse/GEODE-2231
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>Priority: Minor
>
> Add a new example to the geode-examples that demonstrates partitioning.
> The example will use the same structure as the replicated example, starting 2 
> servers that host a partitioned region (with no redundant copies).  Run the 
> producer to populate the region.  Run the consumer to see the contents of the 
> region. Then, stop one of the servers and run the consumer again to notice 
> that only roughly half (with 2 servers and hopefully a reasonable hash) of 
> the entries are present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2243) Modify path to spotless formatter

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773752#comment-15773752
 ] 

ASF subversion and git services commented on GEODE-2243:


Commit 92a76dc50e0d7772dc9b1476a756f287a1bf9fa2 in geode's branch 
refs/heads/develop from [~jens.deppe]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=92a76dc ]

GEODE-2243: reference the formatter relative to geode-core and not the root 
project


> Modify path to spotless formatter
> -
>
> Key: GEODE-2243
> URL: https://issues.apache.org/jira/browse/GEODE-2243
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>
> Modify path to spotless formatter xml slightly so that it can be used from 
> closed side.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 54943: GEODE-2197: refactor cluster config

[Kirk Lund]

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


Ship it!




Ship It!

- Kirk Lund


On Dec. 22, 2016, 6:48 a.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54943/
> ---
> 
> (Updated Dec. 22, 2016, 6:48 a.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Jared Stewart, John Blum, Kevin 
> Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * not to save the xml, properties in the file system, only in the internal 
> region.
> * the cc region's change listener is to download the jar from other locators
> 
> 
> GEODE-2197: refactor cluster config and fix the test failures
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java
>  3119823d6b8886cf893fd38ed58ca90b0c28eeb5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportSharedConfigurationFunction.java
>  821e04b2c590bddd28b0727e504c6460d77cf709 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ImportSharedConfigurationArtifactsFunction.java
>  2ddeda69177b2aea41ee1d1318d8fdb19324a20b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/SharedConfigurationWriter.java
>  3af55874282d380e340874a24860fafad7ace126 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/callbacks/ConfigurationChangeListener.java
>  c08ba924b652c05436f921c19d65392fd7f6859b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/domain/Configuration.java
>  4adf2110c4a270127adda1a5090d537a5e2de8c1 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/ModifyPropertiesFunction.java
>  075993716c1afe47ca116727994a3a3661d35a61 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/utils/XmlUtils.java
>  0b4e0f617cf4b5b91f49dc185d7c02b6b7fe0472 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/SharedConfigurationJUnitTest.java
>  4787c6665cb62eb3dbfe18f3e0128f572d5a36b4 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
>  63c88dd1aa521a6781a8e07567df661cd42fb6f7 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
>  da4fcf9be6637ddd79403f0a01cb2ba1823f7bd4 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
>  c135f3d9b3370b4a756a2c7688530c63a4e06d77 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
>  cfcbeed86ade004eb305d9a01d6fb128132a21ac 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/sanctionedSerializables.txt
>  d6b770f6c9b18e8c090045a66864a027f0ad8062 
> 
> Diff: https://reviews.apache.org/r/54943/diff/
> 
> 
> Testing
> ---
> 
> precheckin successful
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

[jira] [Assigned] (GEODE-2103) start locator command should include --http-service-port and --http-service-bind-address

[Deepak Dixit (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Deepak Dixit reassigned GEODE-2103:
---

Assignee: Deepak Dixit

> start locator command should include --http-service-port and 
> --http-service-bind-address
> 
>
> Key: GEODE-2103
> URL: https://issues.apache.org/jira/browse/GEODE-2103
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Deepak Dixit
>
> To facilitate starting the Admin REST API on a Locator, start locator command 
> should include --http-service-port and --http-service-bind-address.
> Workaround is to specify these configuration properties with --J:
> --J=-Dgemfire.http-service-port=
> --J=-Dgemfire.http-service-bind-address=



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)