[jira] [Created] (GEODE-2211) OQL query shows partial results when data is inserted through REST POST api.

[Amey Barve (JIRA)]

Amey Barve created GEODE-2211:
-

 Summary: OQL query shows partial results when data is inserted 
through REST POST api.
 Key: GEODE-2211
 URL: https://issues.apache.org/jira/browse/GEODE-2211
 Project: Geode
  Issue Type: Bug
  Components: gfsh, querying, rest (dev)
Reporter: Amey Barve
Assignee: Mark Bretl


Steps to Reproduce the Issue
Start a locator
Configure pdx
Start server1 with Developer Rest Enabled.
Start server2
Create Geode Region PARTIONED_PERSISTENENT
Using Swagger UI enter some Key and Values in the Region.
using mash run query "Select * /Region"

Executing - query --query="Select * from /test"

Result : true
startCount : 0
endCount   : 20
Rows   : 4

 1   |  3   |deserializedForReading | 
stringForm | DSFID |  serializedValue   | sizeInBytes | serialized | 
valueSizeInBytes | value
 |  | - | 
-- | - | -- | --- | 
-- |  | --
A| C| org.apache.geode.pdx.internal.PdxInstanceImpl | 
PDX[2,__GEMFIRE_JSON]{2=B} | -65   | org.json.JSONArray | 37  | true
   | 25   | org.json.JSONArray
null | null | org.apache.geode.pdx.internal.PdxInstanceImpl | 
PDX[4,__GEMFIRE_JSON]{4=D} | -65   | org.json.JSONArray | 37  | true
   | 25   | org.json.JSONArray
null | null | null  | null  
 | null  | null   | null| null   | null 
| null
null | null | null  | null  
 | null  | null   | null| null   | null 
| null

NEXT_STEP_NAME : END

It only shows first 2 entries and other as null.

The below script reproduces the issue:

#!/usr/bin/env bash

GEODE_HOME=./geode-assembly/build/install/apache-geode

$GEODE_HOME/bin/gfsh -e "start locator --name=l1 --port=10339" \
-e "configure pdx --read-serialized=true --disk-store" \
-e "start server --name=s1 --server-port=40408 
--J=-Dgemfire.start-dev-rest-api=true --J=-Dgemfire.http-service-port=8080 
--J=-Dgemfire.http-service-bind-address=localhost" \
-e "start server --name=s2 --server-port=40409 " \
-e "create region --name=test --type=PARTITION_PERSISTENT"

tput setaf 3; echo "Inserting the values in persisten region test"
`curl -s -H 'Content-Type: application/json' -H 'Accept: application/json' -X 
POST -d '{"1":"A"}' http://localhost:8080/gemfire-api/v1/test?key=1`
`curl -s -H 'Content-Type: application/json' -H 'Accept: application/json' -X 
POST -d '{"2":"B"}' http://localhost:8080/gemfire-api/v1/test?key=2`
`curl -s -H 'Content-Type: application/json' -H 'Accept: application/json' -X 
POST -d '{"3":"C"}' http://localhost:8080/gemfire-api/v1/test?key=3`
`curl -s -H 'Content-Type: application/json' -H 'Accept: application/json' -X 
POST -d '{"4":"D"}' http://localhost:8080/gemfire-api/v1/test?key=4`

tput setaf 3; echo "The values inserted into the region test are as"
echo `curl -X GET http://localhost:8080/gemfire-api/v1/test?limit=50 
2>/dev/null`

$GEODE_HOME/bin/gfsh -e "connect --locator=localhost[10339]" \
 -e "query --query=\"Select * from /test\"" 
 -e "stop server --name=s1 " \
 -e "stop server --name=s2 " \
 -e "stop locator --name=l1 "





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

[jira] [Created] (GEODE-2212) gfsh http authentication fails when routed through a proxy

[Ben Moss (JIRA)]

Ben Moss created GEODE-2212:
---

 Summary: gfsh http authentication fails when routed through a proxy
 Key: GEODE-2212
 URL: https://issues.apache.org/jira/browse/GEODE-2212
 Project: Geode
  Issue Type: Bug
  Components: core, gfsh
Reporter: Ben Moss
Assignee: Mark Bretl


We encountered a bug with Geode that only reveals itself when routing requests 
through the a proxy that modifies HTTP headers to standardize them in title 
case format.

gfsh uses the security-username and security-password headers to pass 
authentication credentials to the locator, but what we saw is that when these 
go through our proxy and are turned into Security-Username / Security-Password, 
we can no longer authenticate.

This request emulates what gfsh executes when you run "list members" with an 
HTTP connection:

```
curl http://$LOCATOR_IP/gemfire/v1/members -H "security-username: admin" -H 
"security-password: admin"
```

This request emulates what gets sent when going through our proxy. This should 
be the same but will fail:

```
curl http://$LOCATOR_IP/gemfire/v1/members -H "Security-Username: admin" -H 
"Security-Password: admin"
```

We narrowed the bug down to these lines 
(https://github.com/apache/geode/blob/bd229d7681376a11ba2e37747e48844ffe65584c/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/support/LoginHandlerInterceptor.java#L99-L111).
 The HTTP spec specifies that headers should treated as case-insensitive but it 
looks like GemFire is only capable of working with lower-case versions of these 
headers.



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

[jira] [Updated] (GEODE-2212) gfsh http authentication fails when routed through a proxy

[Ben Moss (JIRA)]

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

Ben Moss updated GEODE-2212:

Description: 
We encountered a bug with Geode that only reveals itself when routing requests 
through the a proxy that modifies HTTP headers to standardize them in title 
case format.

gfsh uses the security-username and security-password headers to pass 
authentication credentials to the locator, but what we saw is that when these 
go through our proxy and are turned into Security-Username / Security-Password, 
we can no longer authenticate.

This request emulates what gfsh executes when you run "list members" with an 
HTTP connection:

{code:none}
curl http://$LOCATOR_IP/gemfire/v1/members -H "security-username: admin" -H 
"security-password: admin"
{code}

This request emulates what gets sent when going through our proxy. This should 
be the same but will fail:

{code:none}
curl http://$LOCATOR_IP/gemfire/v1/members -H "Security-Username: admin" -H 
"Security-Password: admin"
{code}

We narrowed the bug down to [these 
lines|https://github.com/apache/geode/blob/bd229d7681376a11ba2e37747e48844ffe65584c/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/support/LoginHandlerInterceptor.java#L99-L111].
 The HTTP spec specifies that headers should treated as case-insensitive but it 
looks like GemFire is only capable of working with lower-case versions of these 
headers.

  was:
We encountered a bug with Geode that only reveals itself when routing requests 
through the a proxy that modifies HTTP headers to standardize them in title 
case format.

gfsh uses the security-username and security-password headers to pass 
authentication credentials to the locator, but what we saw is that when these 
go through our proxy and are turned into Security-Username / Security-Password, 
we can no longer authenticate.

This request emulates what gfsh executes when you run "list members" with an 
HTTP connection:

```
curl http://$LOCATOR_IP/gemfire/v1/members -H "security-username: admin" -H 
"security-password: admin"
```

This request emulates what gets sent when going through our proxy. This should 
be the same but will fail:

```
curl http://$LOCATOR_IP/gemfire/v1/members -H "Security-Username: admin" -H 
"Security-Password: admin"
```

We narrowed the bug down to these lines 
(https://github.com/apache/geode/blob/bd229d7681376a11ba2e37747e48844ffe65584c/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/support/LoginHandlerInterceptor.java#L99-L111).
 The HTTP spec specifies that headers should treated as case-insensitive but it 
looks like GemFire is only capable of working with lower-case versions of these 
headers.


> gfsh http authentication fails when routed through a proxy
> --
>
> Key: GEODE-2212
> URL: https://issues.apache.org/jira/browse/GEODE-2212
> Project: Geode
>  Issue Type: Bug
>  Components: core, gfsh
>Reporter: Ben Moss
>Assignee: Mark Bretl
>
> We encountered a bug with Geode that only reveals itself when routing 
> requests through the a proxy that modifies HTTP headers to standardize them 
> in title case format.
> gfsh uses the security-username and security-password headers to pass 
> authentication credentials to the locator, but what we saw is that when these 
> go through our proxy and are turned into Security-Username / 
> Security-Password, we can no longer authenticate.
> This request emulates what gfsh executes when you run "list members" with an 
> HTTP connection:
> {code:none}
> curl http://$LOCATOR_IP/gemfire/v1/members -H "security-username: admin" -H 
> "security-password: admin"
> {code}
> This request emulates what gets sent when going through our proxy. This 
> should be the same but will fail:
> {code:none}
> curl http://$LOCATOR_IP/gemfire/v1/members -H "Security-Username: admin" -H 
> "Security-Password: admin"
> {code}
> We narrowed the bug down to [these 
> lines|https://github.com/apache/geode/blob/bd229d7681376a11ba2e37747e48844ffe65584c/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/support/LoginHandlerInterceptor.java#L99-L111].
>  The HTTP spec specifies that headers should treated as case-insensitive but 
> it looks like GemFire is only capable of working with lower-case versions of 
> these headers.



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

[jira] [Updated] (GEODE-2212) gfsh http authentication fails when routed through a proxy

[Ben Moss (JIRA)]

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

Ben Moss updated GEODE-2212:

Description: 
We encountered a bug with Geode that only reveals itself when routing requests 
through the a proxy that modifies HTTP headers to standardize them in title 
case format.

gfsh uses the security-username and security-password headers to pass 
authentication credentials to the locator, but what we saw is that when these 
go through our proxy and are turned into Security-Username / Security-Password, 
we can no longer authenticate.

This request emulates what gfsh executes when you run "list members" with an 
HTTP connection:

{code:none}
curl http://$LOCATOR_IP/gemfire/v1/members -H "security-username: admin" -H 
"security-password: admin"
{code}

This request emulates what gets sent when going through our proxy. This should 
be the same but will fail:

{code:none}
curl http://$LOCATOR_IP/gemfire/v1/members -H "Security-Username: admin" -H 
"Security-Password: admin"
{code}

We narrowed the bug down to [these 
lines|https://github.com/apache/geode/blob/bd229d7681376a11ba2e37747e48844ffe65584c/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/support/LoginHandlerInterceptor.java#L99-L111].
 The HTTP spec specifies that headers should treated as case-insensitive but it 
looks like Geode is only capable of working with lower-case versions of these 
headers.

  was:
We encountered a bug with Geode that only reveals itself when routing requests 
through the a proxy that modifies HTTP headers to standardize them in title 
case format.

gfsh uses the security-username and security-password headers to pass 
authentication credentials to the locator, but what we saw is that when these 
go through our proxy and are turned into Security-Username / Security-Password, 
we can no longer authenticate.

This request emulates what gfsh executes when you run "list members" with an 
HTTP connection:

{code:none}
curl http://$LOCATOR_IP/gemfire/v1/members -H "security-username: admin" -H 
"security-password: admin"
{code}

This request emulates what gets sent when going through our proxy. This should 
be the same but will fail:

{code:none}
curl http://$LOCATOR_IP/gemfire/v1/members -H "Security-Username: admin" -H 
"Security-Password: admin"
{code}

We narrowed the bug down to [these 
lines|https://github.com/apache/geode/blob/bd229d7681376a11ba2e37747e48844ffe65584c/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/support/LoginHandlerInterceptor.java#L99-L111].
 The HTTP spec specifies that headers should treated as case-insensitive but it 
looks like GemFire is only capable of working with lower-case versions of these 
headers.


> gfsh http authentication fails when routed through a proxy
> --
>
> Key: GEODE-2212
> URL: https://issues.apache.org/jira/browse/GEODE-2212
> Project: Geode
>  Issue Type: Bug
>  Components: core, gfsh
>Reporter: Ben Moss
>Assignee: Mark Bretl
>
> We encountered a bug with Geode that only reveals itself when routing 
> requests through the a proxy that modifies HTTP headers to standardize them 
> in title case format.
> gfsh uses the security-username and security-password headers to pass 
> authentication credentials to the locator, but what we saw is that when these 
> go through our proxy and are turned into Security-Username / 
> Security-Password, we can no longer authenticate.
> This request emulates what gfsh executes when you run "list members" with an 
> HTTP connection:
> {code:none}
> curl http://$LOCATOR_IP/gemfire/v1/members -H "security-username: admin" -H 
> "security-password: admin"
> {code}
> This request emulates what gets sent when going through our proxy. This 
> should be the same but will fail:
> {code:none}
> curl http://$LOCATOR_IP/gemfire/v1/members -H "Security-Username: admin" -H 
> "Security-Password: admin"
> {code}
> We narrowed the bug down to [these 
> lines|https://github.com/apache/geode/blob/bd229d7681376a11ba2e37747e48844ffe65584c/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/support/LoginHandlerInterceptor.java#L99-L111].
>  The HTTP spec specifies that headers should treated as case-insensitive but 
> it looks like Geode is only capable of working with lower-case versions of 
> these headers.



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

Jenkins build is back to normal : Geode-nightly #685

[Apache Jenkins Server]

See 

[jira] [Created] (GEODE-2213) Deadlock in GMSJoinLeaveJUnitTest

[Bruce Schuchardt (JIRA)]

Bruce Schuchardt created GEODE-2213:
---

 Summary: Deadlock in GMSJoinLeaveJUnitTest
 Key: GEODE-2213
 URL: https://issues.apache.org/jira/browse/GEODE-2213
 Project: Geode
  Issue Type: Bug
  Components: membership
Reporter: Bruce Schuchardt
Assignee: Mark Bretl


My precheckin run hung in integrationTests with this deadlock:

{noformat}
Found one Java-level deadlock:
=
"Geode Membership View Creator":
  waiting to lock monitor 0x153187e8 (object 0xf09102e8, a 
java.util.LinkedList),
  which is held by "Test worker"
"Test worker":
  waiting to lock monitor 0x149d5ad8 (object 0xf09227a8, a 
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator),
  which is held by "Geode Membership View Creator"

Java stack information for the threads listed above:
===
"Geode Membership View Creator":
at 
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.informToPendingJoinRequests(GMSJoinLeave.java:2153)
- waiting to lock <0xf09102e8> (a java.util.LinkedList)
- locked <0xf09227a8> (a 
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator)
at 
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.run(GMSJoinLeave.java:2137)
"Test worker":
at 
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.informToPendingJoinRequests(GMSJoinLeave.java:2143)
- waiting to lock <0xf09227a8> (a 
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator)
at 
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.recordViewRequest(GMSJoinLeave.java:679)
- locked <0xf09102e8> (a java.util.LinkedList)
at 
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveRequest(GMSJoinLeave.java:666)
at 
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1704)
at 
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeaveJUnitTest.testViewNotSentWhenShuttingDown(GMSJoinLeaveJUnitTest.java:1103)
{noformat}

This looks like a pretty straightforward lock inversion that could happen any 
time.



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

[jira] [Updated] (GEODE-2213) Deadlock in GMSJoinLeaveJUnitTest

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt updated GEODE-2213:

Assignee: (was: Mark Bretl)

> Deadlock in GMSJoinLeaveJUnitTest
> -
>
> Key: GEODE-2213
> URL: https://issues.apache.org/jira/browse/GEODE-2213
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>
> My precheckin run hung in integrationTests with this deadlock:
> {noformat}
> Found one Java-level deadlock:
> =
> "Geode Membership View Creator":
>   waiting to lock monitor 0x153187e8 (object 0xf09102e8, a 
> java.util.LinkedList),
>   which is held by "Test worker"
> "Test worker":
>   waiting to lock monitor 0x149d5ad8 (object 0xf09227a8, a 
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator),
>   which is held by "Geode Membership View Creator"
> Java stack information for the threads listed above:
> ===
> "Geode Membership View Creator":
>   at 
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.informToPendingJoinRequests(GMSJoinLeave.java:2153)
>   - waiting to lock <0xf09102e8> (a java.util.LinkedList)
>   - locked <0xf09227a8> (a 
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator)
>   at 
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.run(GMSJoinLeave.java:2137)
> "Test worker":
>   at 
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.informToPendingJoinRequests(GMSJoinLeave.java:2143)
>   - waiting to lock <0xf09227a8> (a 
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator)
>   at 
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.recordViewRequest(GMSJoinLeave.java:679)
>   - locked <0xf09102e8> (a java.util.LinkedList)
>   at 
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveRequest(GMSJoinLeave.java:666)
>   at 
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1704)
>   at 
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeaveJUnitTest.testViewNotSentWhenShuttingDown(GMSJoinLeaveJUnitTest.java:1103)
> {noformat}
> This looks like a pretty straightforward lock inversion that could happen any 
> time.



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

Re: Review Request 54723: GEODE-2208 Document transactions limitation with mixed region types.

[Karen Miller]

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

(Updated Dec. 14, 2016, 4:33 p.m.)


Review request for geode, Dave Barnes, Eric Shu, and Joey McAllister.


Repository: geode


Description
---

- First operation to a transactional system which has colocated
data and replicated/distributed regions must be to a
partitioned region (with colocated data), to set the transaction
host.  Note that this was already documented, but not in a
prominent place.  Now the basics of this info is repeated in
a less-buried location.
- Fixed poorly-working links within the subnav and fixed a
couple of markdown errors.  The errors were improperly
specified anchor tags.


Diffs (updated)
-

  
geode-docs/developing/transactions/data_location_cache_transactions.html.md.erb 
d96de82fa7d5f4074c88863c1732363530c12d39 

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


Testing
---

gradle rat check passes

Geode book builds with no broken links


Thanks,

Karen Miller

Re: Review Request 54723: GEODE-2208 Document transactions limitation with mixed region types.

[Karen Miller]

> On Dec. 13, 2016, 11:11 p.m., Eric Shu wrote:
> > geode-docs/developing/transactions/data_location_cache_transactions.html.md.erb,
> >  line 44
> > 
> >
> > Product may throw TransactionDataRebalancedException instead of 
> > TransactionDataNotColocatedException. Do we need to specify exact exception?

Wording changed to say that there will be an exception, but not which exception.

I'll rebase the second commit before merging to develop.


- Karen


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


On Dec. 14, 2016, 4:33 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54723/
> ---
> 
> (Updated Dec. 14, 2016, 4:33 p.m.)
> 
> 
> Review request for geode, Dave Barnes, Eric Shu, and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - First operation to a transactional system which has colocated
> data and replicated/distributed regions must be to a
> partitioned region (with colocated data), to set the transaction
> host.  Note that this was already documented, but not in a
> prominent place.  Now the basics of this info is repeated in
> a less-buried location.
> - Fixed poorly-working links within the subnav and fixed a
> couple of markdown errors.  The errors were improperly
> specified anchor tags.
> 
> 
> Diffs
> -
> 
>   
> geode-docs/developing/transactions/data_location_cache_transactions.html.md.erb
>  d96de82fa7d5f4074c88863c1732363530c12d39 
> 
> Diff: https://reviews.apache.org/r/54723/diff/
> 
> 
> Testing
> ---
> 
> gradle rat check passes
> 
> Geode book builds with no broken links
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Re: Review Request 54723: GEODE-2208 Document transactions limitation with mixed region types.

[Eric Shu]

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


Ship it!




Ship It!

- Eric Shu


On Dec. 14, 2016, 4:33 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54723/
> ---
> 
> (Updated Dec. 14, 2016, 4:33 p.m.)
> 
> 
> Review request for geode, Dave Barnes, Eric Shu, and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - First operation to a transactional system which has colocated
> data and replicated/distributed regions must be to a
> partitioned region (with colocated data), to set the transaction
> host.  Note that this was already documented, but not in a
> prominent place.  Now the basics of this info is repeated in
> a less-buried location.
> - Fixed poorly-working links within the subnav and fixed a
> couple of markdown errors.  The errors were improperly
> specified anchor tags.
> 
> 
> Diffs
> -
> 
>   
> geode-docs/developing/transactions/data_location_cache_transactions.html.md.erb
>  d96de82fa7d5f4074c88863c1732363530c12d39 
> 
> Diff: https://reviews.apache.org/r/54723/diff/
> 
> 
> Testing
> ---
> 
> gradle rat check passes
> 
> Geode book builds with no broken links
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Re: Review Request 54723: GEODE-2208 Document transactions limitation with mixed region types.

[Joey McAllister]

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


Ship it!




Ship It!

- Joey McAllister


On Dec. 14, 2016, 4:33 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54723/
> ---
> 
> (Updated Dec. 14, 2016, 4:33 p.m.)
> 
> 
> Review request for geode, Dave Barnes, Eric Shu, and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - First operation to a transactional system which has colocated
> data and replicated/distributed regions must be to a
> partitioned region (with colocated data), to set the transaction
> host.  Note that this was already documented, but not in a
> prominent place.  Now the basics of this info is repeated in
> a less-buried location.
> - Fixed poorly-working links within the subnav and fixed a
> couple of markdown errors.  The errors were improperly
> specified anchor tags.
> 
> 
> Diffs
> -
> 
>   
> geode-docs/developing/transactions/data_location_cache_transactions.html.md.erb
>  d96de82fa7d5f4074c88863c1732363530c12d39 
> 
> Diff: https://reviews.apache.org/r/54723/diff/
> 
> 
> Testing
> ---
> 
> gradle rat check passes
> 
> Geode book builds with no broken links
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Review Request 54752: GEODE-2213 Deadlock in GMSJoinLeaveJUnitTest

[Bruce Schuchardt]

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

Review request for geode, Galen O'Sullivan, Jianxia Chen, and Udo Kohlmeyer.


Bugs: GEODE-2213
https://issues.apache.org/jira/browse/GEODE-2213


Repository: geode


Description
---

This removes the informToPendingJoinRequests invocation in recordViewRequest.  
I was already testing this change as I suspected that this invocation was 
causing new members to timeout trying to connect to the distributed system due 
to informToPendingJoinRequests removing join requests from the view creator's 
queue.

I've also made a change to DistributionConfigJUnitTest that was causing the 
MembershipTest suite to fail when run under IntelliJ.  For some reason it does 
not like @Test(expected=xyz.class).


Diffs
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
 4ee3011b18ac309b7f3cff14f6984973b8243d86 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
 080136055feb304ebe6bfe28a0da72e67dfde21f 

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


Testing
---

precheckin, integration testing


Thanks,

Bruce Schuchardt

[jira] [Commented] (GEODE-2196) Write more tests to cover the current behavior of cluster config

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2196:


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

GEODE-2196: add more tests to cover import cluster-configuration and deploy


> Write more tests to cover the current behavior of cluster config
> 
>
> Key: GEODE-2196
> URL: https://issues.apache.org/jira/browse/GEODE-2196
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Mark Bretl
> Fix For: 1.1.0
>
>




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

[jira] [Commented] (GEODE-2208) Document limitation of transactions on mixed region types

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2208:


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

GEODE-2208 Document transactions limitation with mixed
region types.

- First operation to a transactional system which has colocated
data and replicated/distributed regions must be to a
partitioned region (with colocated data), to set the transaction
host.  Note that this was already documented, but not in a
prominent place.  Now the basics of this info is repeated in
a less-buried location.
- Fixed poorly-working links within the subnav and fixed a
couple of markdown errors.  The errors were improperly
specified anchor tags.


> Document limitation of transactions on mixed region types
> -
>
> Key: GEODE-2208
> URL: https://issues.apache.org/jira/browse/GEODE-2208
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> For transactions that run on a mix of replicated and partitioned regions, the 
> first operation needs to be to a partitioned region.  This sets/fixes the 
> host where subsequent operations will run, and it will be where data is 
> colocated if there are multiple partitioned regions involved. If the first 
> operation is to the replicated region, then the host set may be one that is 
> not where the colocated data is, leading to data not colocated exceptions.
> This limitation needs to be documented.



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

Re: Review Request 54723: GEODE-2208 Document transactions limitation with mixed region types.

[Dave Barnes]

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


Ship it!




Ship It!

- Dave Barnes


On Dec. 14, 2016, 4:33 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54723/
> ---
> 
> (Updated Dec. 14, 2016, 4:33 p.m.)
> 
> 
> Review request for geode, Dave Barnes, Eric Shu, and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - First operation to a transactional system which has colocated
> data and replicated/distributed regions must be to a
> partitioned region (with colocated data), to set the transaction
> host.  Note that this was already documented, but not in a
> prominent place.  Now the basics of this info is repeated in
> a less-buried location.
> - Fixed poorly-working links within the subnav and fixed a
> couple of markdown errors.  The errors were improperly
> specified anchor tags.
> 
> 
> Diffs
> -
> 
>   
> geode-docs/developing/transactions/data_location_cache_transactions.html.md.erb
>  d96de82fa7d5f4074c88863c1732363530c12d39 
> 
> Diff: https://reviews.apache.org/r/54723/diff/
> 
> 
> Testing
> ---
> 
> gradle rat check passes
> 
> Geode book builds with no broken links
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

[jira] [Resolved] (GEODE-2092) Security examples should not be in product package

[Kevin Duling (JIRA)]

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

Kevin Duling resolved GEODE-2092.
-
   Resolution: Fixed
Fix Version/s: 1.1.0

> Security examples should not be in product package
> --
>
> Key: GEODE-2092
> URL: https://issues.apache.org/jira/browse/GEODE-2092
> Project: Geode
>  Issue Type: Bug
>  Components: docs, security
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Kevin Duling
> Fix For: 1.1.0
>
>
> These three classes are currently in geode-core product package which implies 
> they are fully supported user API. They cannot be released in a user API 
> package. 
> 1) Move the security examples to examples package within geode-core
> * 
> geode-core/src/main/java/org/apache/geode/security/templates/SampleSecurityManager.java
> * 
> geode-core/src/main/java/org/apache/geode/security/templates/SamplePostProcessor.java
> To:
> * 
> geode-core/src/main/java/org/apache/geode/security/examples/ExampleSecurityManager.java
> * 
> geode-core/src/main/java/org/apache/geode/security/examples/ExamplePostProcessor.java
> Delete this one (it should only exist in some GitHub application for demoing):
> * 
> geode-core/src/main/java/org/apache/geode/security/templates/SimpleSecurityManager.java
> 2) We have geode-core tests that use the security examples. These tests must 
> be altered to use new classes that implement SecurityManager and 
> PostProcessor. These new classes need to live under 
> geode-core/src/tests/java/org/apache/geode/security.
> I also see 
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/controllers/RedactingPostProcessor.java
>  with javadocs indicating that it is an example. Either a) remove the 
> javadocs saying it's an example or b) move it to 
> geode-core/src/main/java/org/apache/geode/security/examples and then create a 
> new implementation of PostProcessor which the rest tests will use.
> End results should be:
> a) all examples live in either geode-examples or 
> geode-core/src/main/java/org/apache/geode/security/examples
> b) no tests should be using the examples, they should be using test specific 
> implementations under geode-core/src/tests/java
> c) no demoing code should be GEODE -- such code belongs in GitHub or other 
> project repos -- for a really good example, please see:
> * https://github.com/spring-projects/spring-gemfire-examples
> * 
> https://github.com/spring-projects/spring-gemfire-examples/tree/master/quickstart/repository
> If anyone needs help creating an example repo outside of GEODE, then please 
> discuss this on geode dev mailing list.



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

[jira] [Resolved] (GEODE-2119) gfsh user and password visible in clear text

[Kevin Duling (JIRA)]

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

Kevin Duling resolved GEODE-2119.
-
   Resolution: Fixed
Fix Version/s: 1.1.0

> gfsh user and password visible in clear text
> 
>
> Key: GEODE-2119
> URL: https://issues.apache.org/jira/browse/GEODE-2119
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Karen Smoler Miller
>Assignee: Kevin Duling
> Fix For: 1.1.0
>
>
> Both gfsh connect and gfsh start server allow the specification on the 
> command line of a user name and a password for use as credentials in 
> authentication.  Clear text versions of the user name and password are then 
> visible
> 1. if the user runs gfsh history
> 2. in historyfile, if the user runs gfsh history --file=historyfile
> 3. in the output of ps
> It would be worth a check to see if clear text versions of the user or 
> password end up in any locator or server logs.  I don't believe it does for 
> gfsh connect, but it might for the start server case.



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

Re: geode git commit: GEODE-2196: add more tests to cover import cluster-configuration and deploy

[Jason Huynh]

I think this needs a spotlessApply on ClusterConfigDUnitTest.

On Wed, Dec 14, 2016 at 8:46 AM  wrote:

> Repository: geode
> Updated Branches:
>   refs/heads/develop ec6a5b54f -> ddcec4457
>
>
> GEODE-2196: add more tests to cover import cluster-configuration and deploy
>
>
> Project: http://git-wip-us.apache.org/repos/asf/geode/repo
> Commit: http://git-wip-us.apache.org/repos/asf/geode/commit/ddcec445
> Tree: http://git-wip-us.apache.org/repos/asf/geode/tree/ddcec445
> Diff: http://git-wip-us.apache.org/repos/asf/geode/diff/ddcec445
>
> Branch: refs/heads/develop
> Commit: ddcec44574f180ede710aa912f621c96a02f92db
> Parents: ec6a5b5
> Author: Jinmei Liao 
> Authored: Fri Dec 9 16:31:24 2016 -0800
> Committer: Jinmei Liao 
> Committed: Wed Dec 14 08:45:49 2016 -0800
>
> --
>  .../internal/SharedConfiguration.java   |  64 +--
>  ...ortSharedConfigurationArtifactsFunction.java |   3 +-
>  .../ConnectToLocatorSSLDUnitTest.java   |  15 +-
>  .../configuration/ClusterConfigDUnitTest.java   | 472 +++
>  .../security/DeployCommandsSecurityTest.java|   1 -
>  .../dunit/rules/GfshShellConnectionRule.java|  24 +-
>  .../dunit/rules/LocatorServerStartupRule.java   |   1 -
>  .../internal/configuration/cluster.jar  | Bin 0 -> 617 bytes
>  .../internal/configuration/cluster_config.zip   | Bin 4666 -> 4172 bytes
>  .../internal/configuration/group1.jar   | Bin 0 -> 617 bytes
>  .../internal/configuration/group2.jar   | Bin 0 -> 617 bytes
>  11 files changed, 443 insertions(+), 137 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/geode/blob/ddcec445/geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java
> --
> diff --git
> a/geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java
> b/geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java
> index a45e843..3119823 100644
> ---
> a/geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java
> +++
> b/geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java
> @@ -14,40 +14,13 @@
>   */
>  package org.apache.geode.distributed.internal;
>
> -import static org.apache.geode.distributed.ConfigurationProperties.*;
> -
> -import java.io.BufferedWriter;
> -import java.io.File;
> -import java.io.FileInputStream;
> -import java.io.FileWriter;
> -import java.io.FilenameFilter;
> -import java.io.IOException;
> -import java.io.PrintWriter;
> -import java.io.StringWriter;
> -import java.sql.Timestamp;
> -import java.text.SimpleDateFormat;
> -import java.util.Date;
> -import java.util.HashMap;
> -import java.util.HashSet;
> -import java.util.List;
> -import java.util.Map;
> -import java.util.Map.Entry;
> -import java.util.Properties;
> -import java.util.Set;
> -import java.util.concurrent.atomic.AtomicReference;
> -
> -import javax.xml.parsers.ParserConfigurationException;
> -import javax.xml.transform.TransformerException;
> -import javax.xml.transform.TransformerFactoryConfigurationError;
> -import javax.xml.xpath.XPathExpressionException;
> +import static
> org.apache.geode.distributed.ConfigurationProperties.CLUSTER_CONFIGURATION_DIR;
> +import static
> org.apache.geode.distributed.ConfigurationProperties.SECURITY_MANAGER;
> +import static
> org.apache.geode.distributed.ConfigurationProperties.SECURITY_POST_PROCESSOR;
>
>  import org.apache.commons.io.FileUtils;
>  import org.apache.commons.io.FilenameUtils;
>  import org.apache.commons.io.filefilter.DirectoryFileFilter;
> -import org.apache.logging.log4j.Logger;
> -import org.w3c.dom.Document;
> -import org.xml.sax.SAXException;
> -
>  import org.apache.geode.CancelException;
>  import org.apache.geode.cache.AttributesFactory;
>  import org.apache.geode.cache.Cache;
> @@ -82,6 +55,33 @@ import
> org.apache.geode.management.internal.configuration.messages.Configuration
>  import
> org.apache.geode.management.internal.configuration.messages.SharedConfigurationStatusResponse;
>  import org.apache.geode.management.internal.configuration.utils.XmlUtils;
>  import org.apache.geode.management.internal.configuration.utils.ZipUtils;
> +import org.apache.logging.log4j.Logger;
> +import org.w3c.dom.Document;
> +import org.xml.sax.SAXException;
> +
> +import java.io.BufferedWriter;
> +import java.io.File;
> +import java.io.FileInputStream;
> +import java.io.FileWriter;
> +import java.io.FilenameFilter;
> +import java.io.IOException;
> +import java.io.PrintWriter;
> +import java.io.StringWriter;
> +import java.sql.Timestamp;
> +import java.text.SimpleDateFormat;
> +import java.util.Date;
> +import java.util.HashMap;
> +import java.util.HashSet;
> +import java.util.List;
> +import java.util.Map;
> +import java.util

[jira] [Updated] (GEODE-2214) ClassLoaderObjectInputStream should support option to use ClassPathLoader

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2214:
-
Issue Type: Wish  (was: Bug)

> ClassLoaderObjectInputStream should support option to use ClassPathLoader
> -
>
> Key: GEODE-2214
> URL: https://issues.apache.org/jira/browse/GEODE-2214
> Project: Geode
>  Issue Type: Wish
>  Components: extensions
>Reporter: Kirk Lund
>Assignee: Mark Bretl
>
> The Geode Session module uses ClassLoaderObjectInputStream which currently 
> uses Class.forName to resolve a class from a single ClassLoader which is 
> passed in. Some users have expressed desire to support TCCL. The best way to 
> do this is to change ClassLoaderObjectInputStream to support the option to 
> use ClassPathLoader which geode-core uses to scan across all ClassLoaders.



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

[jira] [Created] (GEODE-2214) ClassLoaderObjectInputStream should support option to use ClassPathLoader

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2214:


 Summary: ClassLoaderObjectInputStream should support option to use 
ClassPathLoader
 Key: GEODE-2214
 URL: https://issues.apache.org/jira/browse/GEODE-2214
 Project: Geode
  Issue Type: Bug
  Components: extensions
Reporter: Kirk Lund
Assignee: Mark Bretl


The Geode Session module uses ClassLoaderObjectInputStream which currently uses 
Class.forName to resolve a class from a single ClassLoader which is passed in. 
Some users have expressed desire to support TCCL. The best way to do this is to 
change ClassLoaderObjectInputStream to support the option to use 
ClassPathLoader which geode-core uses to scan across all ClassLoaders.



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

[jira] [Assigned] (GEODE-2214) ClassLoaderObjectInputStream should support option to use ClassPathLoader

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2214:


Assignee: Kirk Lund  (was: Mark Bretl)

> ClassLoaderObjectInputStream should support option to use ClassPathLoader
> -
>
> Key: GEODE-2214
> URL: https://issues.apache.org/jira/browse/GEODE-2214
> Project: Geode
>  Issue Type: Wish
>  Components: extensions
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The Geode Session module uses ClassLoaderObjectInputStream which currently 
> uses Class.forName to resolve a class from a single ClassLoader which is 
> passed in. Some users have expressed desire to support TCCL. The best way to 
> do this is to change ClassLoaderObjectInputStream to support the option to 
> use ClassPathLoader which geode-core uses to scan across all ClassLoaders.



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

[jira] [Commented] (GEODE-1975) CI Failure: SecurityClusterConfigDUnitTest.serverWithDifferentSecurityManagerShouldThrowException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1975:


Commit da00dbd280cdff33e2915af79e52548137eb346a in geode's branch 
refs/heads/feature/GEODE-1930 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=da00dbd ]

GEODE-1975: add FlakyTest category to flaky test


> CI Failure: 
> SecurityClusterConfigDUnitTest.serverWithDifferentSecurityManagerShouldThrowException
> -
>
> Key: GEODE-1975
> URL: https://issues.apache.org/jira/browse/GEODE-1975
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh, security
>Reporter: Barry Oglesby
>  Labels: CI, Flaky
>
> Geode_develop_DistributedTests
> Private Build #4129
> Revision: 0a6e1a5339243b069a04d8010a869bfd1f4172c1
> java.lang.AssertionError: 
> Expecting message:
>  <"A server cannot specify its own security-manager or 
> security-post-processor when using cluster configuration">
> but was:
>  <"cluster configuration service not available">
>   at 
> org.apache.geode.security.SecurityClusterConfigDUnitTest.serverWithDifferentSecurityManagerShouldThrowException(SecurityClusterConfigDUnitTest.java:156)
>   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:497)
>   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.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   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.GeneratedMethodAccessor560.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.GeneratedMethodAccessor559.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect

[jira] [Commented] (GEODE-1027) MBeans should be initialized with current stats when they are created.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1027:


Commit 1f49cbcc8cbaad5c0c2ccb8063a67bd6bb88a9b9 in geode's branch 
refs/heads/feature/GEODE-1930 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=1f49cbc ]

GEODE-1027: add unit test for previously committed fix


> MBeans should be initialized with current stats when they are created.
> --
>
> Key: GEODE-1027
> URL: https://issues.apache.org/jira/browse/GEODE-1027
> Project: Geode
>  Issue Type: Improvement
>  Components: jmx
>Affects Versions: 1.0.0-incubating
>Reporter: Jens Deppe
>Assignee: Kirk Lund
>




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

[jira] [Commented] (GEODE-1334) ClusterConfigurationDUnitTest.testCreateExtensions failed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1334:


Commit 92ef7329ed7247d6283b2ab3c373522269b76bbf in geode's branch 
refs/heads/feature/GEODE-1930 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=92ef732 ]

GEODE-1334: add FlakyTest category to flaky test


> ClusterConfigurationDUnitTest.testCreateExtensions failed
> -
>
> Key: GEODE-1334
> URL: https://issues.apache.org/jira/browse/GEODE-1334
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>  Labels: CI, Flaky
>
> java.lang.AssertionError: expected: but was:
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> com.gemstone.gemfire.management.internal.configuration.ClusterConfigurationDUnitTest.executeAndVerifyCommand(ClusterConfigurationDUnitTest.java:853)
>   at 
> com.gemstone.gemfire.management.internal.configuration.ClusterConfigurationDUnitTest.createRegion(ClusterConfigurationDUnitTest.java:744)
>   at 
> com.gemstone.gemfire.management.internal.configuration.ClusterConfigurationDUnitTest.testCreateExtensions(ClusterConfigurationDUnitTest.java:261)
>   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:497)
>   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.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   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:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.NativeMethodAccessorImpl.

[jira] [Commented] (GEODE-1977) CI Failure: SecurityClusterConfigDUnitTest.testStartServerWithClusterConfig

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1977:


Commit e81ad7c64a16fef1800dfa9b96adc013a2e44797 in geode's branch 
refs/heads/feature/GEODE-1930 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=e81ad7c ]

GEODE-1977: add FlakyTest category to flaky test


> CI Failure: SecurityClusterConfigDUnitTest.testStartServerWithClusterConfig
> ---
>
> Key: GEODE-1977
> URL: https://issues.apache.org/jira/browse/GEODE-1977
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh, security
>Reporter: Barry Oglesby
>  Labels: CI, Flaky
>
> Geode_develop_DistributedTests
> Private Build #4129
> Revision: 0a6e1a5339243b069a04d8010a869bfd1f4172c1
> org.apache.geode.GemFireConfigException: cluster configuration service not 
> available
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
>   at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
>   at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:172)
>   at 
> org.apache.geode.security.SecurityClusterConfigDUnitTest.testStartServerWithClusterConfig(SecurityClusterConfigDUnitTest.java:101)
>   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:497)
>   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.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   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.GeneratedMethodAccessor560.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at c

[jira] [Commented] (GEODE-2144) Improve the error message when a Java client specifies no username/password

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2144:


Commit 80525b7e8414456fe18d1c4c55df48d9c3bf9f71 in geode's branch 
refs/heads/feature/GEODE-1930 from [~jstewart]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=80525b7 ]

[GEODE-2144] Improve error message when no security credentials are provided.

- Improve error message when no security credentials are provided.
- Add tests for the code paths exposing this message.
- Refactor making those code paths more testable.

This closes #310


> Improve the error message when a Java client specifies no username/password
> ---
>
> Key: GEODE-2144
> URL: https://issues.apache.org/jira/browse/GEODE-2144
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> If you set up a secured locator/server and attempt to connect via a Java 
> client which does not specify a username/password, the error message is not 
> very helpful:
> {code}
> Message when no security-username and security-password specified is awful: 
> Exception in thread "main" 
> org.apache.geode.security.AuthenticationRequiredException: No security-* 
> properties are provided
> at 
> org.apache.geode.internal.cache.tier.sockets.HandShake.readMessage(HandShake.java:1473)
> at 
> org.apache.geode.internal.cache.tier.sockets.HandShake.greet(HandShake.java:1327)
> at 
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:108)
> at 
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:135)
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl.initializeConnections(QueueManagerImpl.java:466)
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl.start(QueueManagerImpl.java:312)
> at org.apache.geode.cache.client.internal.PoolImpl.start(PoolImpl.java:320)
> at 
> org.apache.geode.cache.client.internal.PoolImpl.finishCreate(PoolImpl.java:147)
> at org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:133)
> at 
> org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:319)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.determineDefaultPool(GemFireCacheImpl.java:2990)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1338)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1169)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createClient(GemFireCacheImpl.java:746)
> at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
> at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:189)
> at com.jaredjstewart.HelloWorld.main(HelloWorld.java:44)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> {code}
> It would be much nicer to tell the user that they need to specify a 
> username/password.



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

[jira] [Commented] (GEODE-1333) ClusterConfigurationDUnitTest.testDestroyExtensions failed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1333:


Commit c10a788b104b6f4184881219088693b3ebb1d1f9 in geode's branch 
refs/heads/feature/GEODE-1930 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c10a788 ]

GEODE-1333: add FlakyTest category to flaky test


> ClusterConfigurationDUnitTest.testDestroyExtensions failed
> --
>
> Key: GEODE-1333
> URL: https://issues.apache.org/jira/browse/GEODE-1333
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>Assignee: Kirk Lund
>  Labels: CI, Flaky
>
> java.lang.AssertionError: expected: but was:
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> com.gemstone.gemfire.management.internal.configuration.ClusterConfigurationDUnitTest.executeAndVerifyCommand(ClusterConfigurationDUnitTest.java:853)
>   at 
> com.gemstone.gemfire.management.internal.configuration.ClusterConfigurationDUnitTest.createRegion(ClusterConfigurationDUnitTest.java:744)
>   at 
> com.gemstone.gemfire.management.internal.configuration.ClusterConfigurationDUnitTest.testDestroyExtensions(ClusterConfigurationDUnitTest.java:335)
>   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:497)
>   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.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   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:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at s

[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=15748990#comment-15748990
 ] 

ASF subversion and git services commented on GEODE-2099:


Commit 70800f5268382a3aca1b35b4c52ba5a70787e469 in geode's branch 
refs/heads/feature/GEODE-1930 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=70800f5 ]

GEODE-2099: reduce scope of method and vars to prevent spaghetti

If you leave vars and methods public or protected, some day
someone is going to make another test call them (I've seen
it happen repeatedly) so please make them private.


> 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
>  Labels: Flaky
>
> 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-1974) CI Failure: SecurityClusterConfigDUnitTest.serverConnectingToSecuredLocatorMustUseClusterConfig

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1974:


Commit 079542b8189f26a330a6331f79e1cd7edb590067 in geode's branch 
refs/heads/feature/GEODE-1930 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=079542b ]

GEODE-1974: add FlakyTest category to flaky test


> CI Failure: 
> SecurityClusterConfigDUnitTest.serverConnectingToSecuredLocatorMustUseClusterConfig
> ---
>
> Key: GEODE-1974
> URL: https://issues.apache.org/jira/browse/GEODE-1974
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh, security
>Reporter: Barry Oglesby
>  Labels: CI, Flaky
>
> Geode_develop_DistributedTests
> Private Build #4129
> Revision: 0a6e1a5339243b069a04d8010a869bfd1f4172c1
> java.lang.AssertionError: 
> Expecting message:
>  <"A server must use cluster configuration when joining a secured cluster.">
> but was:
>  <"cluster configuration service not available">
>   at 
> org.apache.geode.security.SecurityClusterConfigDUnitTest.serverConnectingToSecuredLocatorMustUseClusterConfig(SecurityClusterConfigDUnitTest.java:206)
>   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:497)
>   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.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   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.GeneratedMethodAccessor560.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.GeneratedMethodAccessor559.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> 

[jira] [Commented] (GEODE-209) CI failure: FailWithTimeoutOfWaitForOutputToMatchJUnitTest.testFailWithTimeoutOfWaitForOutputToMatch

[ASF subversion and git services (JIRA)]

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

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

Commit c48a350e33f4f74cf551ccba119436113bfc8bb2 in geode's branch 
refs/heads/feature/GEODE-1930 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c48a350 ]

GEODE-209: disable broken test until race condition is fixed


> CI failure: 
> FailWithTimeoutOfWaitForOutputToMatchJUnitTest.testFailWithTimeoutOfWaitForOutputToMatch
> 
>
> Key: GEODE-209
> URL: https://issues.apache.org/jira/browse/GEODE-209
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.0.0-incubating.M1
>Reporter: Ashvin
>Assignee: Kirk Lund
>Priority: Minor
>  Labels: CI, Flaky
> Fix For: 1.0.0-incubating.M1
>
>
> FailWithTimeoutOfWaitForOutputToMatchJUnitTest.testFailWithTimeoutOfWaitForOutputToMatch
>  failed 5 times in the last 30 runs. It is failing in the tearDown phase.
> {quote}
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at org.junit.Assert.assertFalse(Assert.java:74)
>   at 
> com.gemstone.gemfire.test.golden.FailWithTimeoutOfWaitForOutputToMatchJUnitTest.subTearDown(FailWithTimeoutOfWaitForOutputToMatchJUnitTest.java:20)
>   at 
> com.gemstone.gemfire.test.golden.GoldenTestCase.tearDownGoldenTest(GoldenTestCase.java:49)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {quote}
> {code}
>   public void subTearDown() throws Exception {
> this.process.waitFor();
> assertFalse(this.process.isAlive());
>   }
> {code}
> Fix to GEODE-127 may have caused this issue.



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

[jira] [Commented] (GEODE-2196) Write more tests to cover the current behavior of cluster config

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2196:


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

GEODE-2196: spotless


> Write more tests to cover the current behavior of cluster config
> 
>
> Key: GEODE-2196
> URL: https://issues.apache.org/jira/browse/GEODE-2196
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Mark Bretl
> Fix For: 1.1.0
>
>




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

[jira] [Resolved] (GEODE-2208) Document limitation of transactions on mixed region types

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller resolved GEODE-2208.

Resolution: Fixed

> Document limitation of transactions on mixed region types
> -
>
> Key: GEODE-2208
> URL: https://issues.apache.org/jira/browse/GEODE-2208
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.1.0
>
>
> For transactions that run on a mix of replicated and partitioned regions, the 
> first operation needs to be to a partitioned region.  This sets/fixes the 
> host where subsequent operations will run, and it will be where data is 
> colocated if there are multiple partitioned regions involved. If the first 
> operation is to the replicated region, then the host set may be one that is 
> not where the colocated data is, leading to data not colocated exceptions.
> This limitation needs to be documented.



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

[jira] [Resolved] (GEODE-1594) CI failure: RestAPIsOnMembersFunctionExecutionDUnitTest.testFunctionExecutionOnAllMembers

[Udo Kohlmeyer (JIRA)]

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

Udo Kohlmeyer resolved GEODE-1594.
--
   Resolution: Fixed
Fix Version/s: 1.1.0

> CI failure: 
> RestAPIsOnMembersFunctionExecutionDUnitTest.testFunctionExecutionOnAllMembers
> -
>
> Key: GEODE-1594
> URL: https://issues.apache.org/jira/browse/GEODE-1594
> Project: Geode
>  Issue Type: Bug
>  Components: rest (dev)
>Reporter: Hitesh Khamesra
>Assignee: Udo Kohlmeyer
>  Labels: CI, flaky
> Fix For: 1.1.0
>
>
> java.lang.AssertionError: unexpected exception
>   at com.gemstone.gemfire.test.dunit.Assert.fail(Assert.java:64)
>   at 
> com.gemstone.gemfire.rest.internal.web.controllers.RestAPITestBase.executeFunctionThroughRestCall(RestAPITestBase.java:151)
>   at 
> com.gemstone.gemfire.rest.internal.web.controllers.RestAPIsOnMembersFunctionExecutionDUnitTest.testFunctionExecutionOnAllMembers(RestAPIsOnMembersFunctionExecutionDUnitTest.java:106)
>   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:497)
>   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.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   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:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   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:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dis

[jira] [Updated] (GEODE-2208) Document limitation of transactions on mixed region types

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller updated GEODE-2208:
---
Fix Version/s: 1.1.0

> Document limitation of transactions on mixed region types
> -
>
> Key: GEODE-2208
> URL: https://issues.apache.org/jira/browse/GEODE-2208
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.1.0
>
>
> For transactions that run on a mix of replicated and partitioned regions, the 
> first operation needs to be to a partitioned region.  This sets/fixes the 
> host where subsequent operations will run, and it will be where data is 
> colocated if there are multiple partitioned regions involved. If the first 
> operation is to the replicated region, then the host set may be one that is 
> not where the colocated data is, leading to data not colocated exceptions.
> This limitation needs to be documented.



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

[jira] [Comment Edited] (GEODE-419) javax.net.ssl.* gemfire properties ignored if ssl-enabled is false

[Udo Kohlmeyer (JIRA)]

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

Udo Kohlmeyer edited comment on GEODE-419 at 12/14/16 6:52 PM:
---

I believe that this anomaly has now been fixed with the new 
SSLConfigurationFactory implementation. IF ssl is enabled (by either 
ssl-enabled=true or \*-ssl-enabled=true) the configuration will try all 
possible avenues to configure the ssl properties. As a last resort it will use 
the java.net.ssl.* properties.
Maybe we need to add a test to explicitly test this, but I believe it is now 
resolved.


was (Author: ukohlmeyer):
I believe that this anomaly has now been fixed with the new 
SSLConfigurationFactory implementation. IF ssl is enabled (by either 
ssl-enabled=true or *-ssl-enabled=true) the configuration will try all possible 
avenues to configure the ssl properties. As a last resort it will use the 
java.net.ssl.* properties.
Maybe we need to add a test to explicitly test this, but I believe it is now 
resolved.

> javax.net.ssl.* gemfire properties ignored if ssl-enabled is false
> --
>
> Key: GEODE-419
> URL: https://issues.apache.org/jira/browse/GEODE-419
> Project: Geode
>  Issue Type: Bug
>  Components: configuration
>Reporter: Darrel Schneider
>Priority: Minor
>
> You are supposed to be able to put javax.net.ssl.* system property 
> definitions in your gemfire.properties and have them be used to configure ssl.
> They work ok if ssl-enabled is true and cluster-ssl-enabled is not set. But 
> if you set cluster-ssl-enabled (to true or false) then the javax.net.ssl.* 
> properties are ignored. The same is also true for http-service-ssl-enabled.
> This can be worked around by using the new cluster-ssl-keystore* and 
> cluster-ssl-truststore* gemfire properties instead of javax.net.ssl.*.



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

[jira] [Commented] (GEODE-2183) Region.query behaves differently on client and server when full syntax is passed as a predicate

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2183:


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

GEODE-2183: Region.query now allows full syntax as a predicate on server


> Region.query behaves differently on client and server when full syntax is 
> passed as a predicate
> ---
>
> Key: GEODE-2183
> URL: https://issues.apache.org/jira/browse/GEODE-2183
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.1.0
>
>
> When the full query syntax is passed into region.query(String predicate), the 
> client will allow such executions but when the query is executed on a server, 
> it will throw a compile exception.  
> This should be made consistent, even though full query "select * from 
> /region" technically shouldn't be allowed, due to possible legacy users, we 
> will probably need to keep allowing this to happen for now...?



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

[jira] [Assigned] (GEODE-1272) IndexManager.populateIndexes(Collection) may deserialize pdx to domain objects

[Dan Smith (JIRA)]

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

Dan Smith reassigned GEODE-1272:


Assignee: Dan Smith

> IndexManager.populateIndexes(Collection) may deserialize pdx to domain objects
> --
>
> Key: GEODE-1272
> URL: https://issues.apache.org/jira/browse/GEODE-1272
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Darrel Schneider
>Assignee: Dan Smith
>
> Looking at the IndexManager.populateIndexes I see it iterating over all the 
> entries in a region and adding each entry to each index. What is unclear is 
> if this code correctly calls DefaultQuery.setPdxReadSerialized before 
> accessing the value from the entry. Please verify that when this code is used 
> it will not deserialize pdx to domain object.
> Note that the code currently calls RegionEntry.getValue for every entry and I 
> thought that might be a problem. But since getValue just returns the 
> VMCachedDeserializable and does not try to deserialize the value it wraps it 
> does not cause a problem. So the only issue would be what happens each each 
> entry is passed to AbstractIndex.addIndexMapping.
> I looked the callers of IndexManager.populateIndexes and could not find them 
> calling DefaultQuery.setPdxReadSerialized.



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

[jira] [Commented] (GEODE-1272) IndexManager.populateIndexes(Collection) may deserialize pdx to domain objects

[Dan Smith (JIRA)]

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

Dan Smith commented on GEODE-1272:
--

I have a test that shows that we definitely are *not* calling 
DefaultQuery.setPdxReadSerialized, because I'm seeing entries get deserialized 
when creating an index.

> IndexManager.populateIndexes(Collection) may deserialize pdx to domain objects
> --
>
> Key: GEODE-1272
> URL: https://issues.apache.org/jira/browse/GEODE-1272
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Darrel Schneider
>Assignee: Dan Smith
>
> Looking at the IndexManager.populateIndexes I see it iterating over all the 
> entries in a region and adding each entry to each index. What is unclear is 
> if this code correctly calls DefaultQuery.setPdxReadSerialized before 
> accessing the value from the entry. Please verify that when this code is used 
> it will not deserialize pdx to domain object.
> Note that the code currently calls RegionEntry.getValue for every entry and I 
> thought that might be a problem. But since getValue just returns the 
> VMCachedDeserializable and does not try to deserialize the value it wraps it 
> does not cause a problem. So the only issue would be what happens each each 
> entry is passed to AbstractIndex.addIndexMapping.
> I looked the callers of IndexManager.populateIndexes and could not find them 
> calling DefaultQuery.setPdxReadSerialized.



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

[jira] [Updated] (GEODE-2214) ClassLoaderObjectInputStream should support usage of TCCL

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2214:
-
Description: The Geode Session module uses ClassLoaderObjectInputStream 
which currently uses Class.forName to resolve a class from a single ClassLoader 
which is passed in. Some users have expressed desire to support TCCL.  (was: 
The Geode Session module uses ClassLoaderObjectInputStream which currently uses 
Class.forName to resolve a class from a single ClassLoader which is passed in. 
Some users have expressed desire to support TCCL. The best way to do this is to 
change ClassLoaderObjectInputStream to support the option to use 
ClassPathLoader which geode-core uses to scan across all ClassLoaders.)

> ClassLoaderObjectInputStream should support usage of TCCL
> -
>
> Key: GEODE-2214
> URL: https://issues.apache.org/jira/browse/GEODE-2214
> Project: Geode
>  Issue Type: Wish
>  Components: extensions
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The Geode Session module uses ClassLoaderObjectInputStream which currently 
> uses Class.forName to resolve a class from a single ClassLoader which is 
> passed in. Some users have expressed desire to support TCCL.



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

[jira] [Updated] (GEODE-2214) ClassLoaderObjectInputStream should support usage of TCCL

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2214:
-
Summary: ClassLoaderObjectInputStream should support usage of TCCL  (was: 
ClassLoaderObjectInputStream should support option to use ClassPathLoader)

> ClassLoaderObjectInputStream should support usage of TCCL
> -
>
> Key: GEODE-2214
> URL: https://issues.apache.org/jira/browse/GEODE-2214
> Project: Geode
>  Issue Type: Wish
>  Components: extensions
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The Geode Session module uses ClassLoaderObjectInputStream which currently 
> uses Class.forName to resolve a class from a single ClassLoader which is 
> passed in. Some users have expressed desire to support TCCL. The best way to 
> do this is to change ClassLoaderObjectInputStream to support the option to 
> use ClassPathLoader which geode-core uses to scan across all ClassLoaders.



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

[GitHub] geode pull request #316: GEODE-2188: ExampleSecurityManager references Sampl...

[kjduling]

GitHub user kjduling opened a pull request:

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

GEODE-2188: ExampleSecurityManager references SampleSecurityManager i…

…n javadoc

This corrects some output messages and javadoc entries after the 
ExampleSecurityManager was moved.  It also points the old 
SampleSecurityManagerTest at ExampleSecurityManager.

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

$ git pull https://github.com/kjduling/apache-geode feature/GEODE-2188

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

https://github.com/apache/geode/pull/316.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 #316


commit 135c2c7d268f1b985fc07bac855bc4c2df680281
Author: Kevin J. Duling 
Date:   2016-12-14T21:23:19Z

GEODE-2188: ExampleSecurityManager references SampleSecurityManager in 
javadoc




---
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-2188) ExampleSecurityManager references SampleSecurityManager in javadoc

[ASF GitHub Bot (JIRA)]

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

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

GitHub user kjduling opened a pull request:

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

GEODE-2188: ExampleSecurityManager references SampleSecurityManager i…

…n javadoc

This corrects some output messages and javadoc entries after the 
ExampleSecurityManager was moved.  It also points the old 
SampleSecurityManagerTest at ExampleSecurityManager.

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

$ git pull https://github.com/kjduling/apache-geode feature/GEODE-2188

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

https://github.com/apache/geode/pull/316.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 #316


commit 135c2c7d268f1b985fc07bac855bc4c2df680281
Author: Kevin J. Duling 
Date:   2016-12-14T21:23:19Z

GEODE-2188: ExampleSecurityManager references SampleSecurityManager in 
javadoc




> ExampleSecurityManager references SampleSecurityManager in javadoc
> --
>
> Key: GEODE-2188
> URL: https://issues.apache.org/jira/browse/GEODE-2188
> Project: Geode
>  Issue Type: Bug
>  Components: core, docs
>Reporter: Kevin Duling
>Assignee: Kevin Duling
>Priority: Minor
> Fix For: 1.1.0
>
>
> Example code was moved in GEODE-2092, but some strings need to be updated.
> Javadoc references an incorrect path.
> {{@code security-manager = 
> org.apache.geode.security.examples.SampleSecurityManager}}
> and several strings refer to SampleSecurityManager.
> E.g., 
> {code}
> if (!initializeFromJsonResource(jsonPropertyValue)) {
>   throw new AuthenticationFailedException(
>   "SampleSecurityManager: unable to find json resource \"" + 
> jsonPropertyValue
>   + "\" as specified by [" + SECURITY_JSON + "].");
> }
> {code}



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

[jira] [Created] (GEODE-2215) NPE in ViewCreator thread setting public keys into a NetView

[Bruce Schuchardt (JIRA)]

Bruce Schuchardt created GEODE-2215:
---

 Summary: NPE in ViewCreator thread setting public keys into a 
NetView
 Key: GEODE-2215
 URL: https://issues.apache.org/jira/browse/GEODE-2215
 Project: Geode
  Issue Type: Bug
  Components: membership
Reporter: Bruce Schuchardt
Assignee: Mark Bretl


I saw an NPE in a ViewCreator thread and created this unit test to reproduce 
the problem:

{code}
  public void testNullPublicKeysNotRetained() throws Exception {
NetView view = new NetView(members.get(0), 2, new ArrayList<>(members));
setFailureDetectionPorts(view);

NetView newView = new NetView(view, 3);
for (InternalDistributedMember member: view.getMembers()) {
  view.setPublicKey(member, null);
}
newView.setPublicKeys(view);
for (InternalDistributedMember member: view.getMembers()){
  assertNull(newView.getPublicKey(member));
  assertNull(view.getPublicKey(member));
}
  }
{code}

The problem seems to be that some Maps that NetView uses to hold these keys 
accept null values whlie others do not.



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

Review Request 54761: GEODE-2215 NPE in ViewCreator thread setting public keys into a NetVie

[Bruce Schuchardt]

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

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


Bugs: GEODE-2215
https://issues.apache.org/jira/browse/GEODE-2215


Repository: geode


Description
---

NetView creates a ConcurrentHashmap to hold the public keys when it's 
constructed but it had some methods that were replacing it with a Hashmap.  I 
made the field final and also added checks to avoid putting a null key or value 
into the map.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/NetView.java
 ca62e203985c19068554ff740f6e3d893ebd50a2 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/membership/NetViewJUnitTest.java
 715da474393cbfdd430cc5d54011c8a7739f6aee 

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


Testing
---

precheckin


Thanks,

Bruce Schuchardt

[jira] [Commented] (GEODE-2214) ClassLoaderObjectInputStream should support usage of TCCL

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2214:


Commit f122daeb2d1c9f505ff550cf9ca6ea7d452d5c93 in geode's branch 
refs/heads/feature/GEODE-2214 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=f122dae ]

GEODE-2214: fall back to TCCL if target CL fails to resolve class


> ClassLoaderObjectInputStream should support usage of TCCL
> -
>
> Key: GEODE-2214
> URL: https://issues.apache.org/jira/browse/GEODE-2214
> Project: Geode
>  Issue Type: Wish
>  Components: extensions
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The Geode Session module uses ClassLoaderObjectInputStream which currently 
> uses Class.forName to resolve a class from a single ClassLoader which is 
> passed in. Some users have expressed desire to support TCCL.



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

[jira] [Created] (GEODE-2216) PartitionedRegion.createIndexes ignores exceptions, resulting in corrupt indexes

[Dan Smith (JIRA)]

Dan Smith created GEODE-2216:


 Summary: PartitionedRegion.createIndexes ignores exceptions, 
resulting in corrupt indexes
 Key: GEODE-2216
 URL: https://issues.apache.org/jira/browse/GEODE-2216
 Project: Geode
  Issue Type: Bug
  Components: querying
Reporter: Dan Smith
Assignee: Mark Bretl


I tried to create an index on a region with objects that could not be 
deserialized (it was a mistake in my code). I found that it actually *allowed* 
me to create the index, but my values were not actually indexed.

Looking at the code in PartitionedRegion.createIndexes, it has some interesting 
code to maintain a boolean flag that an exception should be thrown. However, it 
keeps losing the value of the flag. Here's some of the code:

{code}
boolean throwException = false;
...
throwException =
createEmptyIndexes(indexDefinitions, remotelyOriginated, indexes, 
exceptionsMap);

...
//This overwrites the value of throwException
if (unpopulatedIndexes != null && unpopulatedIndexes.size() > 0) {
  throwException = populateEmptyIndexes(unpopulatedIndexes, exceptionsMap);
}

//Same thing here 
throwException =
sendCreateIndexesMessage(remotelyOriginated, indexDefinitions, indexes, 
exceptionsMap);
{code}

This method should always throw an exception if the index creation failed.



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

[jira] [Resolved] (GEODE-2156) Remove incubating references

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-2156.
--
Resolution: Fixed

> Remove incubating references
> 
>
> Key: GEODE-2156
> URL: https://issues.apache.org/jira/browse/GEODE-2156
> Project: Geode
>  Issue Type: Task
>Reporter: Anthony Baker
> Fix For: 1.1.0
>
>
> With the completion of GEODE-1, we need to update the following:
> 1) Project name references no longer need to include "(incubating)"
> 2) Project website references should remove ".incubator"
> 3) Project email lists should remove ".incubator"
> 4) DISCLAIMER no longer applies
> 5) Git repo references should remove "incubator-"



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

[jira] [Updated] (GEODE-2169) Subclasses of OperationContext should also be deprecated

[Anthony Baker (JIRA)]

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

Anthony Baker updated GEODE-2169:
-
Fix Version/s: (was: 1.1.0)

> Subclasses of OperationContext should also be deprecated
> 
>
> Key: GEODE-2169
> URL: https://issues.apache.org/jira/browse/GEODE-2169
> Project: Geode
>  Issue Type: Task
>  Components: docs, management, security
>Reporter: Kevin Duling
>
> Because org.apache.geode.cache.operations.OperationContext is deprecated, the 
> subclasses should also be.



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

[jira] [Commented] (GEODE-1955) JMX suspect string causes tests to fail

[Anthony Baker (JIRA)]

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

Anthony Baker commented on GEODE-1955:
--

Has this issue been fixed?

> JMX suspect string causes tests to fail
> ---
>
> Key: GEODE-1955
> URL: https://issues.apache.org/jira/browse/GEODE-1955
> Project: Geode
>  Issue Type: Bug
>  Components: jmx
>Reporter: Bruce Schuchardt
>Assignee: Jinmei Liao
>  Labels: ci
> Fix For: 1.1.0
>
>
> This suspect string is causing periodic failures in a number of unit tests:
> Error Message
> java.lang.AssertionError: Suspicious strings were written to the log during 
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 283
> [fatal 2016/09/29 12:12:03.891 PDT  tid=0x18d] 
> (tid=397 msgId=39) No longer connected to cc6-co6.gemstone.com[27162].



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

[GitHub] geode pull request #317: [GEODE-2196] Add test for exportClusterConfig.

[jaredjstewart]

GitHub user jaredjstewart opened a pull request:

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

[GEODE-2196] Add test for exportClusterConfig.

- Break ClusterConfigDUnitTest out into multiple test classes.
- Refactor ClusterConfigDUnitTest.ExpectedConfig into a standalone 
ClusterConfig class.
- Refactor GfshShellConnectionRule to use Awaitility instead of Thread.sleep

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

$ git pull https://github.com/jaredjstewart/geode addExportClusterConfigTest

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

https://github.com/apache/geode/pull/317.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 #317


commit 371ca74550e10bae5562dc300129d54318e22811
Author: Jared Stewart 
Date:   2016-12-15T00:39:07Z

[GEODE-2196] Add test for exportClusterConfig.

- Break ClusterConfigDUnitTest out into multiple test classes.
- Refactor ClusterConfigDUnitTest.ExpectedConfig into a standalone 
ClusterConfig class.
- Refactor GfshShellConnectionRule to use Awaitility instead of Thread.sleep




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

[GitHub] geode issue #317: [GEODE-2196] Add test for exportClusterConfig.

[jaredjstewart]

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/317
  
precheckin started


---
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-2196) Write more tests to cover the current behavior of cluster config

[ASF GitHub Bot (JIRA)]

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

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

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/317
  
precheckin started


> Write more tests to cover the current behavior of cluster config
> 
>
> Key: GEODE-2196
> URL: https://issues.apache.org/jira/browse/GEODE-2196
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Mark Bretl
> Fix For: 1.1.0
>
>




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

[jira] [Commented] (GEODE-2196) Write more tests to cover the current behavior of cluster config

[ASF GitHub Bot (JIRA)]

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

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

GitHub user jaredjstewart opened a pull request:

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

[GEODE-2196] Add test for exportClusterConfig.

- Break ClusterConfigDUnitTest out into multiple test classes.
- Refactor ClusterConfigDUnitTest.ExpectedConfig into a standalone 
ClusterConfig class.
- Refactor GfshShellConnectionRule to use Awaitility instead of Thread.sleep

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

$ git pull https://github.com/jaredjstewart/geode addExportClusterConfigTest

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

https://github.com/apache/geode/pull/317.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 #317


commit 371ca74550e10bae5562dc300129d54318e22811
Author: Jared Stewart 
Date:   2016-12-15T00:39:07Z

[GEODE-2196] Add test for exportClusterConfig.

- Break ClusterConfigDUnitTest out into multiple test classes.
- Refactor ClusterConfigDUnitTest.ExpectedConfig into a standalone 
ClusterConfig class.
- Refactor GfshShellConnectionRule to use Awaitility instead of Thread.sleep




> Write more tests to cover the current behavior of cluster config
> 
>
> Key: GEODE-2196
> URL: https://issues.apache.org/jira/browse/GEODE-2196
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Mark Bretl
> Fix For: 1.1.0
>
>




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

[jira] [Resolved] (GEODE-711) Provide Apache Lucene/Solr integration for data in Geode

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-711.
-
Resolution: Duplicate

> Provide Apache Lucene/Solr integration for data in Geode
> 
>
> Key: GEODE-711
> URL: https://issues.apache.org/jira/browse/GEODE-711
> Project: Geode
>  Issue Type: Wish
>  Components: extensions
>Reporter: Sumit Agarwal
>
> Provide the ability to index the data stored in Geode using Apache Lucene/Solr



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

[jira] [Closed] (GEODE-711) Provide Apache Lucene/Solr integration for data in Geode

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-711.
---

> Provide Apache Lucene/Solr integration for data in Geode
> 
>
> Key: GEODE-711
> URL: https://issues.apache.org/jira/browse/GEODE-711
> Project: Geode
>  Issue Type: Wish
>  Components: extensions
>Reporter: Sumit Agarwal
>
> Provide the ability to index the data stored in Geode using Apache Lucene/Solr



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

[jira] [Resolved] (GEODE-868) Auto generate NOTICE for binary distribution

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-868.
-
Resolution: Won't Fix

Given the complexity of determining correctness, I think it's better to review 
the NOTICE files manually.

> Auto generate NOTICE for binary distribution
> 
>
> Key: GEODE-868
> URL: https://issues.apache.org/jira/browse/GEODE-868
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Anthony Baker
>
> It would be nice to automatically generate the NOTICE file for the binary 
> distribution based on the dependencies included in the lib directory and in 
> the war files.  This will take the manual labor out of creating the NOTICE 
> file correctly when dependencies are added, removed, or changed (incl 
> transitive deps).
> The binary NOTICE file should be based on the source NOTICE file.
> The maven shade plugin does something like this:
> https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ApacheNoticeResourceTransformer
> There is also a gradle shadow plugin:
> https://github.com/johnrengelman/shadow
> However it appears to have some bugs that cause it to skip some NOTICE files 
> (needs further investigation).



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

[jira] [Closed] (GEODE-868) Auto generate NOTICE for binary distribution

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-868.
---

> Auto generate NOTICE for binary distribution
> 
>
> Key: GEODE-868
> URL: https://issues.apache.org/jira/browse/GEODE-868
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Anthony Baker
>
> It would be nice to automatically generate the NOTICE file for the binary 
> distribution based on the dependencies included in the lib directory and in 
> the war files.  This will take the manual labor out of creating the NOTICE 
> file correctly when dependencies are added, removed, or changed (incl 
> transitive deps).
> The binary NOTICE file should be based on the source NOTICE file.
> The maven shade plugin does something like this:
> https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ApacheNoticeResourceTransformer
> There is also a gradle shadow plugin:
> https://github.com/johnrengelman/shadow
> However it appears to have some bugs that cause it to skip some NOTICE files 
> (needs further investigation).



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

[jira] [Resolved] (GEODE-995) Release page is missing Geode logo

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-995.
-
Resolution: Not A Problem

This appears to be fixed.

> Release page is missing Geode logo
> --
>
> Key: GEODE-995
> URL: https://issues.apache.org/jira/browse/GEODE-995
> Project: Geode
>  Issue Type: Bug
>  Components: web-content
>Reporter: Anthony Baker
>
> The Geode Releases page is missing the logo from the left hand side of the 
> top navigation bar.  The area is still linked but it's a bit confusing for 
> the user.
> http://geode.incubator.apache.org/releases/



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

[jira] [Closed] (GEODE-995) Release page is missing Geode logo

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-995.
---

> Release page is missing Geode logo
> --
>
> Key: GEODE-995
> URL: https://issues.apache.org/jira/browse/GEODE-995
> Project: Geode
>  Issue Type: Bug
>  Components: web-content
>Reporter: Anthony Baker
>
> The Geode Releases page is missing the logo from the left hand side of the 
> top navigation bar.  The area is still linked but it's a bit confusing for 
> the user.
> http://geode.incubator.apache.org/releases/



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

[GitHub] geode pull request #305: [GEODE-1923] Fix a test race condition.

[jaredjstewart]

Github user jaredjstewart commented on a diff in the pull request:

https://github.com/apache/geode/pull/305#discussion_r92525359
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/internal/cache/FixedPRSinglehopDUnitTest.java
 ---
@@ -293,18 +294,23 @@ public void test_FPAmetadataFetch() {
   putIntoPartitionedRegionsThreeQs();
 
   getFromPartitionedRegionsFor3Qs();
-  Wait.pause(2000);
+  // Server 1 is actually primary for both Q1 and Q2, since there is 
no FPA server with
+  // primary set to true.
+  Awaitility.await().atMost(15, TimeUnit.SECONDS).until(
+  () -> (server1.invoke(() -> 
FixedPRSinglehopDUnitTest.primaryBucketsOnServer()) == 6)
--- End diff --

I think you can simplify the lambda expression passed to `server1.invoke()` 
by using a method reference instead:
```
() -> (server1.invoke(FixedPRSinglehopDUnitTest::primaryBucketsOnServer) == 
6)
```

If `primaryBucketsOnServer` was not a static method, it would look even 
shorter:
```
() -> (server1.invoke(this::primaryBucketsOnServer) == 6)
```


---
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-1923) CI Failure: FixedPRSinglehopDUnitTest.test_FPAmetadataFetch

[ASF GitHub Bot (JIRA)]

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

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

Github user jaredjstewart commented on a diff in the pull request:

https://github.com/apache/geode/pull/305#discussion_r92525359
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/internal/cache/FixedPRSinglehopDUnitTest.java
 ---
@@ -293,18 +294,23 @@ public void test_FPAmetadataFetch() {
   putIntoPartitionedRegionsThreeQs();
 
   getFromPartitionedRegionsFor3Qs();
-  Wait.pause(2000);
+  // Server 1 is actually primary for both Q1 and Q2, since there is 
no FPA server with
+  // primary set to true.
+  Awaitility.await().atMost(15, TimeUnit.SECONDS).until(
+  () -> (server1.invoke(() -> 
FixedPRSinglehopDUnitTest.primaryBucketsOnServer()) == 6)
--- End diff --

I think you can simplify the lambda expression passed to `server1.invoke()` 
by using a method reference instead:
```
() -> (server1.invoke(FixedPRSinglehopDUnitTest::primaryBucketsOnServer) == 
6)
```

If `primaryBucketsOnServer` was not a static method, it would look even 
shorter:
```
() -> (server1.invoke(this::primaryBucketsOnServer) == 6)
```


> CI Failure: FixedPRSinglehopDUnitTest.test_FPAmetadataFetch
> ---
>
> Key: GEODE-1923
> URL: https://issues.apache.org/jira/browse/GEODE-1923
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Eric Shu
>Assignee: Bruce Schuchardt
>  Labels: ci, flaky
>
> java.lang.AssertionError: expected: but was:
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> org.apache.geode.internal.cache.FixedPRSinglehopDUnitTest.updateIntoSinglePR(FixedPRSinglehopDUnitTest.java:765)
>   at 
> org.apache.geode.internal.cache.FixedPRSinglehopDUnitTest.test_FPAmetadataFetch(FixedPRSinglehopDUnitTest.java:339)
>   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:497)
>   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.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   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.Meth

Review Request 54767: GEODE-2214: fall back to TCCL if target CL fails to resolve class

[Jason Huynh]

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

Review request for geode, Kirk Lund and Dan Smith.


Repository: geode


Description
---

Use the tccl if the regular classloader fails


Diffs
-

  extensions/geode-modules/build.gradle 0ac8c9a 
  
extensions/geode-modules/src/main/java/org/apache/geode/modules/util/ClassLoaderObjectInputStream.java
 d5ebbab 
  
extensions/geode-modules/src/test/java/org/apache/geode/modules/util/ClassLoaderObjectInputStreamTest.java
 PRE-CREATION 

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


Testing
---


Thanks,

Jason Huynh

Re: [DRAFT] Geode Board Report for December 2016

[Mark Bretl]

Thanks Dan!

Report has been submitted.

--Mark

On Tue, Dec 13, 2016 at 10:48 AM, Dan Smith  wrote:

> Updated draft below with feedback from Mark and Anthony incorporated.
>
> -Dan
>
>
> ## Description:
>  - Apache Geode provides a database-like consistency model, reliable
>transaction processing and a shared-nothing architecture to maintain
>very low latency performance with high concurrency.
>
> ## Issues:
>  - No issues requiring board attention at this time
>
> ## Activity:
>  - Graduated from the incubator November 21, 2016!
>  - Released our first non-milestone release, 1.0.0-incubating.
>  - Transitioned project resources from incubator to TLP namespace.
>  - Started discussions about our first release as a TLP.
>  - Jinmei Liao presented a talk at apachecon Europe: "Implementing
> Security in Apache Geode Using Apache Shiro."
>
> ## Health report:
>  - Geode is still seeing active development. With our first
> non-milestone release we're hoping to settle into a more regular
> release cadence. We're still working to attract more contributors from
> outside of Pivotal and since graduation we're seeing more
> contributions coming in from other sources which is a good sign.
>
> ## PMC changes:
>
>  - No PMC changes since the last report to the incubator board.
>
> ## Committer base changes:
>
>  - Ken Howe joined as a committer Nov 15th.
>
> ## Releases:
>
>  - 1.0.0-incubating October 25, 2016
>  - 1.0.0-incubating.M3 August 23, 2016
>  - 1.0.0-incubating.M2 April 22, 2016
>  - 1.0.0-incubating.M1 Feb 8, 2016
>
> ## Mailing list activity:
>
>  - dev@geode.apache.org:
>
> - 154 subscribers (down -3 in the last 3 months):
> - 2258 emails sent to list (1529 in previous quarter)
>
>  - iss...@geode.apache.org:
>
> - 55 subscribers (up 0 in the last 3 months):
> - 2977 emails sent to list (2751 in previous quarter)
>
>  - u...@geode.apache.org:
>
> - 194 subscribers (up 13 in the last 3 months):
> - 187 emails sent to list (157 in previous quarter)
>
> ## JIRA activity:
>
>  - 320 JIRA tickets created in the last 3 months
>  - 279 JIRA tickets closed/resolved in the last 3 months
>

[GitHub] geode issue #296: GEODE-2109 : Calling submit on ExecutionService can cause ...

[deepakddixit]

Github user deepakddixit commented on the issue:

https://github.com/apache/geode/pull/296
  
Precheckin and ./gradlew test passed on my machine.  @upthewaterspout 
Kindly have a look over updated PR.


---
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-2109) calling submit on ExecutionService can cause exceptions to be lost

[ASF GitHub Bot (JIRA)]

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

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

Github user deepakddixit commented on the issue:

https://github.com/apache/geode/pull/296
  
Precheckin and ./gradlew test passed on my machine.  @upthewaterspout 
Kindly have a look over updated PR.


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

[GitHub] geode pull request #316: GEODE-2188: ExampleSecurityManager references Sampl...

[jinmeiliao]

Github user jinmeiliao commented on a diff in the pull request:

https://github.com/apache/geode/pull/316#discussion_r92544045
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/examples/security/ExampleSecurityManager.java
 ---
@@ -257,15 +257,65 @@ private void readUsers(final Map 
rolesToUsers, final JsonNode node
 return roleMap;
   }
 
-  static class Role {
+  public static class Role {
 List permissions = new ArrayList<>();
+
--- End diff --

These methods are not used anywhere, why do we need to add them?


---
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-2188) ExampleSecurityManager references SampleSecurityManager in javadoc

[ASF GitHub Bot (JIRA)]

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

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

Github user jinmeiliao commented on a diff in the pull request:

https://github.com/apache/geode/pull/316#discussion_r92544045
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/examples/security/ExampleSecurityManager.java
 ---
@@ -257,15 +257,65 @@ private void readUsers(final Map 
rolesToUsers, final JsonNode node
 return roleMap;
   }
 
-  static class Role {
+  public static class Role {
 List permissions = new ArrayList<>();
+
--- End diff --

These methods are not used anywhere, why do we need to add them?


> ExampleSecurityManager references SampleSecurityManager in javadoc
> --
>
> Key: GEODE-2188
> URL: https://issues.apache.org/jira/browse/GEODE-2188
> Project: Geode
>  Issue Type: Bug
>  Components: core, docs
>Reporter: Kevin Duling
>Assignee: Kevin Duling
>Priority: Minor
> Fix For: 1.1.0
>
>
> Example code was moved in GEODE-2092, but some strings need to be updated.
> Javadoc references an incorrect path.
> {{@code security-manager = 
> org.apache.geode.security.examples.SampleSecurityManager}}
> and several strings refer to SampleSecurityManager.
> E.g., 
> {code}
> if (!initializeFromJsonResource(jsonPropertyValue)) {
>   throw new AuthenticationFailedException(
>   "SampleSecurityManager: unable to find json resource \"" + 
> jsonPropertyValue
>   + "\" as specified by [" + SECURITY_JSON + "].");
> }
> {code}



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

[GitHub] geode pull request #317: [GEODE-2196] Add test for exportClusterConfig.

[jinmeiliao]

Github user jinmeiliao commented on a diff in the pull request:

https://github.com/apache/geode/pull/317#discussion_r92544596
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/test/dunit/rules/ConfigGroup.java ---
@@ -0,0 +1,102 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * thisright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * this of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ *
+ */
+
+package org.apache.geode.test.dunit.rules;
--- End diff --

Same as before, probably move to another more specific package


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

[GitHub] geode pull request #317: [GEODE-2196] Add test for exportClusterConfig.

[jinmeiliao]

Github user jinmeiliao commented on a diff in the pull request:

https://github.com/apache/geode/pull/317#discussion_r92545081
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
 ---
@@ -0,0 +1,144 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ *
+ */
+
+package org.apache.geode.management.internal.configuration;
+
+import static org.apache.geode.distributed.ConfigurationProperties.GROUPS;
+import static org.assertj.core.api.Assertions.assertThat;
+
+import org.apache.geode.management.cli.Result;
+import org.apache.geode.management.internal.cli.result.CommandResult;
+import org.apache.geode.test.dunit.rules.ClusterConfig;
+import org.apache.geode.test.dunit.rules.ConfigGroup;
+import org.apache.geode.test.dunit.rules.GfshShellConnectionRule;
+import org.apache.geode.test.dunit.rules.Locator;
+import org.apache.geode.test.dunit.rules.Server;
+import org.apache.geode.test.junit.categories.DistributedTest;
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+
+import java.io.File;
+import java.nio.file.Path;
+import java.util.HashSet;
+import java.util.Set;
+import java.util.stream.Collectors;
+import java.util.zip.ZipEntry;
+import java.util.zip.ZipFile;
+
+@Category(DistributedTest.class)
+public class ClusterConfigImportDUnitTest extends ClusterConfigBaseTest {
+  private GfshShellConnectionRule gfshConnector;
+
+  public static final ClusterConfig INITIAL_CONFIG = new ClusterConfig(new 
ConfigGroup("cluster"));
+
+  private Locator locator;
+
+  @Before
+  public void before() throws Exception {
+super.before();
+locator = lsRule.startLocatorVM(0, locatorProps);
+INITIAL_CONFIG.verify(locator);
+
+gfshConnector = new GfshShellConnectionRule(locator);
+gfshConnector.connect();
+assertThat(gfshConnector.isConnected()).isTrue();
+  }
+
+
+  @After
+  public void after() throws Exception {
+if (gfshConnector != null) {
+  gfshConnector.close();
+}
+  }
+
+  @Test
+  public void testImportWithRunningServer() throws Exception {
+Server server1 = lsRule.startServerVM(1, serverProps, 
locator.getPort());
+
+CommandResult result = gfshConnector.executeCommand(
+"import cluster-configuration --zip-file-name=" + 
EXPORTED_CLUSTER_CONFIG_PATH);
+
+assertThat(result.getStatus()).isEqualTo(Result.Status.ERROR);
+  }
+
+  @Test
+  public void testImportClusterConfig() throws Exception {
+CommandResult result = gfshConnector.executeCommand(
+"import cluster-configuration --zip-file-name=" + 
EXPORTED_CLUSTER_CONFIG_PATH);
+assertThat(result.getStatus()).isEqualTo(Result.Status.OK);
+
+// verify that the previous folder is backed up to 
"cluster_configxx".
+assertThat(locator.getWorkingDir().listFiles())
+.filteredOn((File file) -> 
!file.getName().equals("cluster_config"))
+.filteredOn((File file) -> 
file.getName().startsWith("cluster_config")).isNotEmpty();
+CONFIG_FROM_ZIP.verify(locator);
+
+// start server1 with no group
+Server server1 = lsRule.startServerVM(1, serverProps, 
locator.getPort());
+new ClusterConfig(CLUSTER).verify(server1);
+
+// start server2 in group1
+serverProps.setProperty(GROUPS, "group1");
+Server server2 = lsRule.startServerVM(2, serverProps, 
locator.getPort());
+new ClusterConfig(CLUSTER, GROUP1).verify(server2);
+
+// start server3 in group1 and group2
+serverProps.setProperty(GROUPS, "group1,group2");
+Server server3 = lsRule.startServerVM(3, serverProps, 
locator.getPort());
+new ClusterConfig(CLUSTER, GROUP1, GROUP2).verify(server3);
+  }
+
+  @Test
+  public void testExportClusterConfig() throws Exception {
   

[GitHub] geode pull request #317: [GEODE-2196] Add test for exportClusterConfig.

[jinmeiliao]

Github user jinmeiliao commented on a diff in the pull request:

https://github.com/apache/geode/pull/317#discussion_r92544538
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/test/dunit/rules/ClusterConfig.java 
---
@@ -0,0 +1,183 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ *
+ */
+
+package org.apache.geode.test.dunit.rules;
--- End diff --

Do we want to put this in the rules package or should we moved into the 
cluster config test package?


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

[GitHub] geode pull request #317: [GEODE-2196] Add test for exportClusterConfig.

[jinmeiliao]

Github user jinmeiliao commented on a diff in the pull request:

https://github.com/apache/geode/pull/317#discussion_r92544410
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 ---
@@ -85,19 +91,17 @@ public void connect(String... options) throws Exception 
{
 // javax.naming.CommunicationException [Root exception is 
java.rmi.NoSuchObjectException: no
 // such object in table]" Exception.
 // Tried to wait on jmx connector server being ready, but it doesn't 
work.
-// Add the retry logic here to try at most 10 times for connection.
-CommandResult result = null;
-for (int i = 0; i < 50; i++) {
-  System.out.println("trying to connect, attempt " + i);
+Awaitility.await().atMost(2, TimeUnit.MINUTES).pollDelay(2, 
TimeUnit.SECONDS).until(() -> {
   gfsh.executeCommand(connectCommand.toString());
-  result = (CommandResult) gfsh.getResult();
-  System.out.println(gfsh.outputString);
-  if (!gfsh.outputString.contains("no such object in table")) {
-break;
-  }
-  Thread.currentThread().sleep(2000);
-}
-connected = (result.getStatus() == Result.Status.OK);
+  CommandResult result = (CommandResult) gfsh.getResult();
+  return !gfsh.outputString.contains("no such object in table")
--- End diff --

We only want to retry connecting when we get "no such object in table" 
message. This would wait for 2 minutes even if the JMX connector is ready but 
the connection failed due to some other reason like invalid username/password 
etc. 




---
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-2196) Write more tests to cover the current behavior of cluster config

[ASF GitHub Bot (JIRA)]

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

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

Github user jinmeiliao commented on a diff in the pull request:

https://github.com/apache/geode/pull/317#discussion_r92545081
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
 ---
@@ -0,0 +1,144 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ *
+ */
+
+package org.apache.geode.management.internal.configuration;
+
+import static org.apache.geode.distributed.ConfigurationProperties.GROUPS;
+import static org.assertj.core.api.Assertions.assertThat;
+
+import org.apache.geode.management.cli.Result;
+import org.apache.geode.management.internal.cli.result.CommandResult;
+import org.apache.geode.test.dunit.rules.ClusterConfig;
+import org.apache.geode.test.dunit.rules.ConfigGroup;
+import org.apache.geode.test.dunit.rules.GfshShellConnectionRule;
+import org.apache.geode.test.dunit.rules.Locator;
+import org.apache.geode.test.dunit.rules.Server;
+import org.apache.geode.test.junit.categories.DistributedTest;
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+
+import java.io.File;
+import java.nio.file.Path;
+import java.util.HashSet;
+import java.util.Set;
+import java.util.stream.Collectors;
+import java.util.zip.ZipEntry;
+import java.util.zip.ZipFile;
+
+@Category(DistributedTest.class)
+public class ClusterConfigImportDUnitTest extends ClusterConfigBaseTest {
+  private GfshShellConnectionRule gfshConnector;
+
+  public static final ClusterConfig INITIAL_CONFIG = new ClusterConfig(new 
ConfigGroup("cluster"));
+
+  private Locator locator;
+
+  @Before
+  public void before() throws Exception {
+super.before();
+locator = lsRule.startLocatorVM(0, locatorProps);
+INITIAL_CONFIG.verify(locator);
+
+gfshConnector = new GfshShellConnectionRule(locator);
+gfshConnector.connect();
+assertThat(gfshConnector.isConnected()).isTrue();
+  }
+
+
+  @After
+  public void after() throws Exception {
+if (gfshConnector != null) {
+  gfshConnector.close();
+}
+  }
+
+  @Test
+  public void testImportWithRunningServer() throws Exception {
+Server server1 = lsRule.startServerVM(1, serverProps, 
locator.getPort());
+
+CommandResult result = gfshConnector.executeCommand(
+"import cluster-configuration --zip-file-name=" + 
EXPORTED_CLUSTER_CONFIG_PATH);
+
+assertThat(result.getStatus()).isEqualTo(Result.Status.ERROR);
+  }
+
+  @Test
+  public void testImportClusterConfig() throws Exception {
+CommandResult result = gfshConnector.executeCommand(
+"import cluster-configuration --zip-file-name=" + 
EXPORTED_CLUSTER_CONFIG_PATH);
+assertThat(result.getStatus()).isEqualTo(Result.Status.OK);
+
+// verify that the previous folder is backed up to 
"cluster_configxx".
+assertThat(locator.getWorkingDir().listFiles())
+.filteredOn((File file) -> 
!file.getName().equals("cluster_config"))
+.filteredOn((File file) -> 
file.getName().startsWith("cluster_config")).isNotEmpty();
+CONFIG_FROM_ZIP.verify(locator);
+
+// start server1 with no group
+Server server1 = lsRule.startServerVM(1, serverProps, 
locator.getPort());
+new ClusterConfig(CLUSTER).verify(server1);
+
+// start server2 in group1
+serverProps.setProperty(GROUPS, "group1");
+Server server2 = lsRule.startServerVM(2, serverProps, 
locator.getPort());
+new ClusterConfig(CLUSTER, GROUP1).verify(server2);
+
+// start server3 in group1 and group2
+serverProps.setProperty(GROUPS, "group1,gr

[jira] [Commented] (GEODE-2196) Write more tests to cover the current behavior of cluster config

[ASF GitHub Bot (JIRA)]

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

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

Github user jinmeiliao commented on a diff in the pull request:

https://github.com/apache/geode/pull/317#discussion_r92544538
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/test/dunit/rules/ClusterConfig.java 
---
@@ -0,0 +1,183 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ *
+ */
+
+package org.apache.geode.test.dunit.rules;
--- End diff --

Do we want to put this in the rules package or should we moved into the 
cluster config test package?


> Write more tests to cover the current behavior of cluster config
> 
>
> Key: GEODE-2196
> URL: https://issues.apache.org/jira/browse/GEODE-2196
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Mark Bretl
> Fix For: 1.1.0
>
>




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

[GitHub] geode pull request #317: [GEODE-2196] Add test for exportClusterConfig.

[jinmeiliao]

Github user jinmeiliao commented on a diff in the pull request:

https://github.com/apache/geode/pull/317#discussion_r92544631
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
 ---
@@ -44,32 +46,32 @@
   /**
* This is only available in each Locator/Server VM, not in the 
controller (test) VM.
*/
-  public static ServerStarterRule serverStarter;
+  public static transient ServerStarterRule serverStarter;
--- End diff --

I think all static variables are transient by default.


---
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-2196) Write more tests to cover the current behavior of cluster config

[ASF GitHub Bot (JIRA)]

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

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

Github user jinmeiliao commented on a diff in the pull request:

https://github.com/apache/geode/pull/317#discussion_r92544756
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/test/dunit/rules/Locator.java ---
@@ -0,0 +1,28 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ *
+ */
+
+package org.apache.geode.test.dunit.rules;
+
+import org.apache.geode.test.dunit.VM;
+
+import java.io.File;
+
+public class Locator extends Member {
--- End diff --

Why are we not using Member for both locator/server? The child class does 
not provide anything else the abstract class doesn't do.


> Write more tests to cover the current behavior of cluster config
> 
>
> Key: GEODE-2196
> URL: https://issues.apache.org/jira/browse/GEODE-2196
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Mark Bretl
> Fix For: 1.1.0
>
>




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

[GitHub] geode pull request #317: [GEODE-2196] Add test for exportClusterConfig.

[jinmeiliao]

Github user jinmeiliao commented on a diff in the pull request:

https://github.com/apache/geode/pull/317#discussion_r92544756
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/test/dunit/rules/Locator.java ---
@@ -0,0 +1,28 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ *
+ */
+
+package org.apache.geode.test.dunit.rules;
+
+import org.apache.geode.test.dunit.VM;
+
+import java.io.File;
+
+public class Locator extends Member {
--- End diff --

Why are we not using Member for both locator/server? The child class does 
not provide anything else the abstract class doesn't do.


---
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-2196) Write more tests to cover the current behavior of cluster config

[ASF GitHub Bot (JIRA)]

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

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

Github user jinmeiliao commented on a diff in the pull request:

https://github.com/apache/geode/pull/317#discussion_r92544631
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
 ---
@@ -44,32 +46,32 @@
   /**
* This is only available in each Locator/Server VM, not in the 
controller (test) VM.
*/
-  public static ServerStarterRule serverStarter;
+  public static transient ServerStarterRule serverStarter;
--- End diff --

I think all static variables are transient by default.


> Write more tests to cover the current behavior of cluster config
> 
>
> Key: GEODE-2196
> URL: https://issues.apache.org/jira/browse/GEODE-2196
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Mark Bretl
> Fix For: 1.1.0
>
>




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

[jira] [Commented] (GEODE-2196) Write more tests to cover the current behavior of cluster config

[ASF GitHub Bot (JIRA)]

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

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

Github user jinmeiliao commented on a diff in the pull request:

https://github.com/apache/geode/pull/317#discussion_r92544410
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 ---
@@ -85,19 +91,17 @@ public void connect(String... options) throws Exception 
{
 // javax.naming.CommunicationException [Root exception is 
java.rmi.NoSuchObjectException: no
 // such object in table]" Exception.
 // Tried to wait on jmx connector server being ready, but it doesn't 
work.
-// Add the retry logic here to try at most 10 times for connection.
-CommandResult result = null;
-for (int i = 0; i < 50; i++) {
-  System.out.println("trying to connect, attempt " + i);
+Awaitility.await().atMost(2, TimeUnit.MINUTES).pollDelay(2, 
TimeUnit.SECONDS).until(() -> {
   gfsh.executeCommand(connectCommand.toString());
-  result = (CommandResult) gfsh.getResult();
-  System.out.println(gfsh.outputString);
-  if (!gfsh.outputString.contains("no such object in table")) {
-break;
-  }
-  Thread.currentThread().sleep(2000);
-}
-connected = (result.getStatus() == Result.Status.OK);
+  CommandResult result = (CommandResult) gfsh.getResult();
+  return !gfsh.outputString.contains("no such object in table")
--- End diff --

We only want to retry connecting when we get "no such object in table" 
message. This would wait for 2 minutes even if the JMX connector is ready but 
the connection failed due to some other reason like invalid username/password 
etc. 




> Write more tests to cover the current behavior of cluster config
> 
>
> Key: GEODE-2196
> URL: https://issues.apache.org/jira/browse/GEODE-2196
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Mark Bretl
> Fix For: 1.1.0
>
>




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

[jira] [Commented] (GEODE-2196) Write more tests to cover the current behavior of cluster config

[ASF GitHub Bot (JIRA)]

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

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

Github user jinmeiliao commented on a diff in the pull request:

https://github.com/apache/geode/pull/317#discussion_r92544596
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/test/dunit/rules/ConfigGroup.java ---
@@ -0,0 +1,102 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * thisright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * this of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ *
+ */
+
+package org.apache.geode.test.dunit.rules;
--- End diff --

Same as before, probably move to another more specific package


> Write more tests to cover the current behavior of cluster config
> 
>
> Key: GEODE-2196
> URL: https://issues.apache.org/jira/browse/GEODE-2196
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Mark Bretl
> Fix For: 1.1.0
>
>




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

Review Request 54772: GEODE-2212: request headers are case-insensitive

[Jinmei Liao]

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

Review request for geode.


Repository: geode


Description
---

GEODE-2212: request headers are case-insensitive


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/support/LoginHandlerInterceptor.java
 ccc2856edde96eef9ae43bf81f48e893182f404d 
  
geode-web/src/test/java/org/apache/geode/management/internal/web/controllers/support/LoginHandlerInterceptorRequestHeaderJUnitTest.java
 PRE-CREATION 

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


Testing
---

the added test


Thanks,

Jinmei Liao

[jira] [Commented] (GEODE-789) Create and clear define index shouldn't be available on disconnected GFSH

[ASF subversion and git services (JIRA)]

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

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

Commit 96949ef53b3a9cc0ffd88501cdfcc213fa762bc7 in geode's branch 
refs/heads/develop from [~abarve]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=96949ef ]

GEODE-789: Added 'create defined indexes', 'clear defined indexes', and
'define index' gfsh commands for indexes in CliAvailabilityIndicator so
that they would not be available on a disconnected gfsh session. Fixed
testOfflineHelp.


> Create and clear define index shouldn't be available on disconnected GFSH
> -
>
> Key: GEODE-789
> URL: https://issues.apache.org/jira/browse/GEODE-789
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, tools
>Reporter: William Markito Oliveira
>Assignee: Amey Barve
>
> The following gfsh commands for indexes shouldn't be available on a 
> disconnected gfsh session. 
> {code}
> gfsh>create defined indexes --
> Can't execute a remote command without connection. Use 'connect' first to 
> connect.
> gfsh>clear defined indexes
> Can't execute a remote command without connection. Use 'connect' first to 
> connect.
> gfsh>
> {code} 



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