[jira] [Commented] (GEODE-11) Lucene Integration

[ASF subversion and git services (JIRA)]

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

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

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

GEODE-11: add Fixed PR dunit tests for gemfire lucene


> Lucene Integration
> --
>
> Key: GEODE-11
> URL: https://issues.apache.org/jira/browse/GEODE-11
> Project: Geode
>  Issue Type: New Feature
>  Components: docs, querying
>Reporter: Dan Smith
>Assignee: xiaojian zhou
>  Labels: experimental
>
> This is a feature that has been under development for GemFire but was not 
> part of the initial drop of code for geode.
> Allow Lucene indexes to be stored in Geode regions allowing users to do text 
> searches on data stored in Geode. 



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

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

[Alyssa Kim (JIRA)]

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

Alyssa Kim commented on GEODE-1577:
---

If the goal is to avoid using generic types, I think it's better to introduce a 
new class as suggested above and refactor all the previous methods with 
generics to be type specific. Once we have release after release and the code 
becomes even more ginormous, the pain to refactor (if someone decides to do it) 
and clean up will be much greater than now... I think.
{code}
  public Execution withFilter(Set filter); /* not 100% sure about this */
  public Execution withArgs(Object args);
  public Execution withCollector(ResultCollector rc);
  public ResultCollector execute(String functionId) throws 
FunctionException;
{code}
I would take the pain if that makes the code better :) !
Thanks for the feedback. I will wait for others' opinion and see what happens.

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



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

Re: Review Request 55956: GEODE-2367: Lucene indexes do not handle ha scenarios

[Dan Smith]

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


Ship it!




Looks good. I think the synchronization issues I mentioned in the last review 
are still present, but maybe it would be good to get this in and continue 
working on cleaning that up.

- Dan Smith


On Jan. 26, 2017, 1:15 a.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55956/
> ---
> 
> (Updated Jan. 26, 2017, 1:15 a.m.)
> 
> 
> Review request for geode, Barry Oglesby, nabarun nag, Dan Smith, and xiaojian 
> zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Added afterSecondary callback to partition listener to allow cleaning up of 
> the index repo when the bucket losses primary
> Added lock prior to creating the bucket indexes to prevent multiple index 
> writers from being available at a time
> Changed single point of lucene index creation, no longer creating on the fly
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/cache/partition/PartitionListener.java
>  a534e50 
>   geode-core/src/main/java/org/apache/geode/internal/cache/BucketAdvisor.java 
> 7b79bfb 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/AbstractPartitionedRepositoryManager.java
>  aa29e1b 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/IndexRepositoryFactory.java
>  c73d64a 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneEventListener.java
>  f2c7c8f 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LucenePrimaryBucketListener.java
>  d17b5f2 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/RawIndexRepositoryFactory.java
>  2afccf9 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/repository/IndexRepositoryImpl.java
>  4e86eb5 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/PartitionedRepositoryManagerJUnitTest.java
>  960d794 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/RawLuceneRepositoryManagerJUnitTest.java
>  9201180 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/distributed/DistributedScoringJUnitTest.java
>  225f6ac 
> 
> Diff: https://reviews.apache.org/r/55956/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Review Request 55976: add Fixed PR dunit tests for lucene

[Dan Smith]

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


Fix it, then Ship it!




Looks good! Nice job extending the existing tests and avoiding duplication.


geode-lucene/src/test/java/org/apache/geode/cache/lucene/test/LuceneTestUtilities.java
 (line 110)


Should these ignored exceptions be here? Why do we need these?



geode-lucene/src/test/java/org/apache/geode/cache/lucene/test/LuceneTestUtilities.java
 (line 156)


Why is this marked @Deprecated?


- Dan Smith


On Jan. 26, 2017, 1:47 a.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55976/
> ---
> 
> (Updated Jan. 26, 2017, 1:47 a.m.)
> 
> 
> Review request for geode and Dan Smith.
> 
> 
> Bugs: GEODE-11
> https://issues.apache.org/jira/browse/GEODE-11
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> add dunit tests for index creation tests and queries tests
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneIndexCreationDUnitTest.java
>  e58f713 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneIndexCreationOnFixedPRDUnitTest.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneQueriesPeerFixedPRDUnitTest.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/test/LuceneTestUtilities.java
>  21c0bbc 
> 
> Diff: https://reviews.apache.org/r/55976/diff/
> 
> 
> Testing
> ---
> 
> precheckin
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

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

[ASF GitHub Bot (JIRA)]

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

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

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/321
  
Hi all,

I'm really sorry I missed this. I was out of town for a while and somehow 
the discussion slipped through the cracks when I was catching up.

These changes are what I had in mind, but I didn't realize that this would 
break existing code that was doing a cast. I know adding a generics should be 
safe, but in this case we're fixing generics that are broken which is why I 
think we are getting into trouble.

I did a little messing around. It looks like we might be able to get away 
with adding generics to Execution. 
The only caveat is that once we add generics to Execution we are stuck with 
them. There is an existing bug to also add an argument type to the 
FunctionContext - see GEODE-2217. So I think maybe the thing to do is to add 
three types parameters to execution. Something like this:

```
/**
 *
 * @param  The type of the argument passed into the function, if any
 * @param  The type of the aggregrated result returned by the 
ResultCollector
 */
public interface Execution {
  Execution withArgs(IN args);
  ResultCollector execute(...)
}
```

What do you think? The other option I suppose is to deprecate the Execution 
class and introduce a new one, or deprecate the execute methods and introduce 
new ones, but that seems painful.


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



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

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

[upthewaterspout]

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/321
  
Hi all,

I'm really sorry I missed this. I was out of town for a while and somehow 
the discussion slipped through the cracks when I was catching up.

These changes are what I had in mind, but I didn't realize that this would 
break existing code that was doing a cast. I know adding a generics should be 
safe, but in this case we're fixing generics that are broken which is why I 
think we are getting into trouble.

I did a little messing around. It looks like we might be able to get away 
with adding generics to Execution. 
The only caveat is that once we add generics to Execution we are stuck with 
them. There is an existing bug to also add an argument type to the 
FunctionContext - see GEODE-2217. So I think maybe the thing to do is to add 
three types parameters to execution. Something like this:

```
/**
 *
 * @param  The type of the argument passed into the function, if any
 * @param  The type of the aggregrated result returned by the 
ResultCollector
 */
public interface Execution {
  Execution withArgs(IN args);
  ResultCollector execute(...)
}
```

What do you think? The other option I suppose is to deprecate the Execution 
class and introduce a new one, or deprecate the execute methods and introduce 
new ones, but that seems painful.


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

Review Request 55976: add Fixed PR dunit tests for lucene

[xiaojian zhou]

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

Review request for geode and Dan Smith.


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


Repository: geode


Description
---

add dunit tests for index creation tests and queries tests


Diffs
-

  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneIndexCreationDUnitTest.java
 e58f713 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneIndexCreationOnFixedPRDUnitTest.java
 PRE-CREATION 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneQueriesPeerFixedPRDUnitTest.java
 PRE-CREATION 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/test/LuceneTestUtilities.java
 21c0bbc 

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


Testing
---

precheckin


Thanks,

xiaojian zhou

[jira] [Commented] (GEODE-2353) Verify no clear-text passwords in documentation

[ASF GitHub Bot (JIRA)]

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

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

GitHub user davebarnes97 opened a pull request:

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

GEODE-2353 Verify no clear-text passwords in documentation



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

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

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

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


commit 7a2485565b512724ca920552f44af3d6ccff5492
Author: Dave Barnes 
Date:   2017-01-26T01:30:05Z

GEODE-2353 Verify no clear-text passwords in documentation




> Verify no clear-text passwords in documentation
> ---
>
> Key: GEODE-2353
> URL: https://issues.apache.org/jira/browse/GEODE-2353
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Joey McAllister
> Fix For: 1.1.0
>
>
> Find locations in the manual where notes were made that the password is 
> recorded or available in clear text, and remove them. GEODE-2119 ticket fixed 
> all of them. Passwords are no longer seen in clear text.



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

[GitHub] geode pull request #364: GEODE-2353 Verify no clear-text passwords in docume...

[davebarnes97]

GitHub user davebarnes97 opened a pull request:

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

GEODE-2353 Verify no clear-text passwords in documentation



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

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

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

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


commit 7a2485565b512724ca920552f44af3d6ccff5492
Author: Dave Barnes 
Date:   2017-01-26T01:30:05Z

GEODE-2353 Verify no clear-text passwords in documentation




---
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-2353) Verify no clear-text passwords in documentation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2353:


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

GEODE-2353 Verify no clear-text passwords in documentation


> Verify no clear-text passwords in documentation
> ---
>
> Key: GEODE-2353
> URL: https://issues.apache.org/jira/browse/GEODE-2353
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Joey McAllister
> Fix For: 1.1.0
>
>
> Find locations in the manual where notes were made that the password is 
> recorded or available in clear text, and remove them. GEODE-2119 ticket fixed 
> all of them. Passwords are no longer seen in clear text.



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

Re: Review Request 55956: GEODE-2367: Lucene indexes do not handle ha scenarios

[Jason Huynh]

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

(Updated Jan. 26, 2017, 1:15 a.m.)


Review request for geode, Barry Oglesby, nabarun nag, Dan Smith, and xiaojian 
zhou.


Changes
---

Applied review suggestions/comments


Repository: geode


Description
---

Added afterSecondary callback to partition listener to allow cleaning up of the 
index repo when the bucket losses primary
Added lock prior to creating the bucket indexes to prevent multiple index 
writers from being available at a time
Changed single point of lucene index creation, no longer creating on the fly


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/cache/partition/PartitionListener.java
 a534e50 
  geode-core/src/main/java/org/apache/geode/internal/cache/BucketAdvisor.java 
7b79bfb 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/AbstractPartitionedRepositoryManager.java
 aa29e1b 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/IndexRepositoryFactory.java
 c73d64a 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneEventListener.java
 f2c7c8f 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LucenePrimaryBucketListener.java
 d17b5f2 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/RawIndexRepositoryFactory.java
 2afccf9 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/repository/IndexRepositoryImpl.java
 4e86eb5 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/PartitionedRepositoryManagerJUnitTest.java
 960d794 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/RawLuceneRepositoryManagerJUnitTest.java
 9201180 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/distributed/DistributedScoringJUnitTest.java
 225f6ac 

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


Testing
---


Thanks,

Jason Huynh

[jira] [Commented] (GEODE-2353) Verify no clear-text passwords in documentation

[ASF GitHub Bot (JIRA)]

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

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

Github user davebarnes97 closed the pull request at:

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


> Verify no clear-text passwords in documentation
> ---
>
> Key: GEODE-2353
> URL: https://issues.apache.org/jira/browse/GEODE-2353
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Joey McAllister
> Fix For: 1.1.0
>
>
> Find locations in the manual where notes were made that the password is 
> recorded or available in clear text, and remove them. GEODE-2119 ticket fixed 
> all of them. Passwords are no longer seen in clear text.



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

[GitHub] geode issue #363: Feature/geode 2353

[davebarnes97]

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode/pull/363
  
Messy PR, will clean up and resubmit


---
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 #363: Feature/geode 2353

[davebarnes97]

Github user davebarnes97 closed the pull request at:

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


---
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 #363: Feature/geode 2353

[davebarnes97]

GitHub user davebarnes97 opened a pull request:

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

Feature/geode 2353



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

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

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

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






---
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-2353) Verify no clear-text passwords in documentation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2353:


Commit a28d08142856f1e4dae2d6fd9ebe60dee2ed1dc7 in geode's branch 
refs/heads/feature/GEODE-2353 from [~dbarnes97]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=a28d081 ]

GEODE-2353 Verify no clear-text passwords in documentation


> Verify no clear-text passwords in documentation
> ---
>
> Key: GEODE-2353
> URL: https://issues.apache.org/jira/browse/GEODE-2353
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Joey McAllister
> Fix For: 1.1.0
>
>
> Find locations in the manual where notes were made that the password is 
> recorded or available in clear text, and remove them. GEODE-2119 ticket fixed 
> all of them. Passwords are no longer seen in clear text.



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

[GitHub] geode pull request #362: GEODE-2300 Document default names for start locator...

[davebarnes97]

GitHub user davebarnes97 opened a pull request:

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

GEODE-2300 Document default names for start locator/server

Documented new default naming convention for gfsh start locator and start 
server commands. Did not attempt to insert at every occurrence of the commands. 
Focused on introductory sections, and deleted the 'required' designation for 
the '--name' parameter in reference tables.

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

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

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

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






---
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-2300) Document default names for start locator/server

[ASF GitHub Bot (JIRA)]

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

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

GitHub user davebarnes97 opened a pull request:

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

GEODE-2300 Document default names for start locator/server

Documented new default naming convention for gfsh start locator and start 
server commands. Did not attempt to insert at every occurrence of the commands. 
Focused on introductory sections, and deleted the 'required' designation for 
the '--name' parameter in reference tables.

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

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

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

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






> Document default names for start locator/server
> ---
>
> Key: GEODE-2300
> URL: https://issues.apache.org/jira/browse/GEODE-2300
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Joey McAllister
>Assignee: Dave Barnes
> Fix For: 1.1.0
>
>
> Documentation for GEODE-182



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

[jira] [Assigned] (GEODE-2300) Document default names for start locator/server

[Dave Barnes (JIRA)]

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

Dave Barnes reassigned GEODE-2300:
--

Assignee: Dave Barnes

> Document default names for start locator/server
> ---
>
> Key: GEODE-2300
> URL: https://issues.apache.org/jira/browse/GEODE-2300
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Joey McAllister
>Assignee: Dave Barnes
> Fix For: 1.1.0
>
>
> Documentation for GEODE-182



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

[jira] [Commented] (GEODE-2354) Use of security-manager results in UnknownSessionExceptions after 30 minutes idle

[Kirk Lund (JIRA)]

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

Kirk Lund commented on GEODE-2354:
--

I committed the solution described as #1 in my comment above. Now reassigning 
to Jinmei to followup and see if we should make further changes to this or move 
to option #2.

> Use of security-manager results in UnknownSessionExceptions after 30 minutes 
> idle
> -
>
> Key: GEODE-2354
> URL: https://issues.apache.org/jira/browse/GEODE-2354
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
>
> If the User specifies a SecurityManager with security-manager, all authorized 
> operations start to fail with UnknownSessionExceptions after 30 minutes idle 
> which is the default globalSessionTimeout in Apache Shiro.
> Workaround: specify security-shiro-init in gemfire.properties and configure 
> everything via Shiro within a shiro.ini.
> Fixing this will require changes to IntegratedSecurityService to set the 
> globalSessionTimeout higher or to re-authenticate after a timeout.



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

[jira] [Updated] (GEODE-2354) Use of security-manager results in UnknownSessionExceptions after 30 minutes idle

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2354:
-
Assignee: Jinmei Liao  (was: Kirk Lund)

> Use of security-manager results in UnknownSessionExceptions after 30 minutes 
> idle
> -
>
> Key: GEODE-2354
> URL: https://issues.apache.org/jira/browse/GEODE-2354
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
>
> If the User specifies a SecurityManager with security-manager, all authorized 
> operations start to fail with UnknownSessionExceptions after 30 minutes idle 
> which is the default globalSessionTimeout in Apache Shiro.
> Workaround: specify security-shiro-init in gemfire.properties and configure 
> everything via Shiro within a shiro.ini.
> Fixing this will require changes to IntegratedSecurityService to set the 
> globalSessionTimeout higher or to re-authenticate after a timeout.



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

[jira] [Commented] (GEODE-2354) Use of security-manager results in UnknownSessionExceptions after 30 minutes idle

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2354:


Commit 6619a3de9b956d69e3c991f53572595e54ce0549 in geode's branch 
refs/heads/develop from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=6619a3d ]

GEODE-2354: set global session timeout to MAX_VALUE


> Use of security-manager results in UnknownSessionExceptions after 30 minutes 
> idle
> -
>
> Key: GEODE-2354
> URL: https://issues.apache.org/jira/browse/GEODE-2354
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> If the User specifies a SecurityManager with security-manager, all authorized 
> operations start to fail with UnknownSessionExceptions after 30 minutes idle 
> which is the default globalSessionTimeout in Apache Shiro.
> Workaround: specify security-shiro-init in gemfire.properties and configure 
> everything via Shiro within a shiro.ini.
> Fixing this will require changes to IntegratedSecurityService to set the 
> globalSessionTimeout higher or to re-authenticate after a timeout.



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

[jira] [Commented] (GEODE-2354) Use of security-manager results in UnknownSessionExceptions after 30 minutes idle

[Kirk Lund (JIRA)]

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

Kirk Lund commented on GEODE-2354:
--

Options for fixing this:

1) increase globalSessionTimeout indefinitely 
(https://reviews.apache.org/r/55890/)
2) change IntegratedSecurityService.authorize to catch UnknownSessionException 
and re-authenticate

The problem with #2 is we don't currently store the credentials to 
re-authenticate with. This would require keeping a strong reference to 
instances of GeodeAuthenticationToken which contains a reference to the 
Properties containing the credentials. We pass the token to Shiro and that's 
the last we use the token.


> Use of security-manager results in UnknownSessionExceptions after 30 minutes 
> idle
> -
>
> Key: GEODE-2354
> URL: https://issues.apache.org/jira/browse/GEODE-2354
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> If the User specifies a SecurityManager with security-manager, all authorized 
> operations start to fail with UnknownSessionExceptions after 30 minutes idle 
> which is the default globalSessionTimeout in Apache Shiro.
> Workaround: specify security-shiro-init in gemfire.properties and configure 
> everything via Shiro within a shiro.ini.
> Fixing this will require changes to IntegratedSecurityService to set the 
> globalSessionTimeout higher or to re-authenticate after a timeout.



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

Re: Review Request 55781: GEODE-2298: Executing a Function via Swagger without parameters throws an exception

[Kevin Duling]

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

(Updated Jan. 25, 2017, 4:35 p.m.)


Review request for geode, Jinmei Liao, Jared Stewart, and Kirk Lund.


Repository: geode


Description
---

Protection against an empty JSON object being sent as no-arguments in to a 
function within the REST controller.


Diffs
-

  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
 fc2da8b5b164da2f93472ad2dc1dc3a71cf700fd 
  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/controllers/NoArgumentFunction.java
 PRE-CREATION 
  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/controllers/RestAPIsQueryAndFEJUnitTest.java
 f05411049e3342c3ff84cefc329520802370f039 
  
geode-web-api/src/main/java/org/apache/geode/rest/internal/web/controllers/AbstractBaseController.java
 b9d2bf4dec5b8d091207b6a98ff30d11ba7cc822 
  
geode-web-api/src/main/java/org/apache/geode/rest/internal/web/controllers/FunctionAccessController.java
 2169cb28cd80d675764ff185ca1ff7c6dbc2b525 

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


Testing
---

precheckin successful


Thanks,

Kevin Duling

Re: Review Request 55965: GEODE-1930: fix exception messages in DUnitLauncher

[Kevin Duling]

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


Ship it!




Ship It!

- Kevin Duling


On Jan. 25, 2017, 3:58 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55965/
> ---
> 
> (Updated Jan. 25, 2017, 3:58 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Jared Stewart, and Kevin Duling.
> 
> 
> Bugs: GEODE-1930
> https://issues.apache.org/jira/browse/GEODE-1930
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This is for a follow-up commit to my latest commit for GEODE-1930. I had 
> fixed a couple Exceptions strings in DUnitLauncher. When I merged that commit 
> to develop, it combined in a strange way with a commit that Bruce made. This 
> is my attempt to fix up DUnitLauncher back to what Bruce had. The other 
> option is to revert my commit and repeat the merge but leave out 
> DUnitLauncher.
> 
> For reference, here are the two constants used in the modified code:
> ```java
>   static final long STARTUP_TIMEOUT = 120 * 1000;
>   private static final String STARTUP_TIMEOUT_MESSAGE =
>   "VMs did not start up within " + (STARTUP_TIMEOUT / 1000) + " seconds";
> ```
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/standalone/DUnitLauncher.java
>  92a7c46950dd9d0a0029ba511b187e36169accbc 
> 
> Diff: https://reviews.apache.org/r/55965/diff/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

[jira] [Assigned] (GEODE-2354) Use of security-manager results in UnknownSessionExceptions after 30 minutes idle

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2354:


Assignee: Kirk Lund

> Use of security-manager results in UnknownSessionExceptions after 30 minutes 
> idle
> -
>
> Key: GEODE-2354
> URL: https://issues.apache.org/jira/browse/GEODE-2354
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> If the User specifies a SecurityManager with security-manager, all authorized 
> operations start to fail with UnknownSessionExceptions after 30 minutes idle 
> which is the default globalSessionTimeout in Apache Shiro.
> Workaround: specify security-shiro-init in gemfire.properties and configure 
> everything via Shiro within a shiro.ini.
> Fixing this will require changes to IntegratedSecurityService to set the 
> globalSessionTimeout higher or to re-authenticate after a timeout.



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

[jira] [Commented] (GEODE-2355) CI failure: RollingUpgrade2DUnitTest.testOplogMagicSeqBackwardCompatibility fails consistently

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2355:


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

Adding JIRA ticket numbers for disabled tests

GEODE-2356: CI failure: 
RollingUpgradePart2DUnitTest.testQueryMixedServersOnPartitionedRegions
 fails consistently
GEODE-2355: CI failure: 
RollingUpgrade2DUnitTest.testOplogMagicSeqBackwardCompatibility
 fails consistently


> CI failure: RollingUpgrade2DUnitTest.testOplogMagicSeqBackwardCompatibility 
> fails consistently
> --
>
> Key: GEODE-2355
> URL: https://issues.apache.org/jira/browse/GEODE-2355
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Bruce Schuchardt
>  Labels: backwards-compatibility, ci
>
> This test fails with the following assertion and is current @Ignored
> {noformat}
>  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
>  
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgrade2DUnitTest.verifyOplogHeader(RollingUpgrade2DUnitTest.java:633)
>  at
>  
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgrade2DUnitTest.testOplogMagicSeqBackwardCompactibility(RollingUpgrade2DUnitTest.java:568)
> {noformat}



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

[jira] [Commented] (GEODE-2356) CI failure: RollingUpgrade2DUnitTest.testQueryMixedServersOnPartitionedRegions fails consistently

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2356:


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

Adding JIRA ticket numbers for disabled tests

GEODE-2356: CI failure: 
RollingUpgradePart2DUnitTest.testQueryMixedServersOnPartitionedRegions
 fails consistently
GEODE-2355: CI failure: 
RollingUpgrade2DUnitTest.testOplogMagicSeqBackwardCompatibility
 fails consistently


> CI failure: 
> RollingUpgrade2DUnitTest.testQueryMixedServersOnPartitionedRegions fails 
> consistently
> -
>
> Key: GEODE-2356
> URL: https://issues.apache.org/jira/browse/GEODE-2356
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Bruce Schuchardt
>  Labels: backwards-compatibility, ci
>
> This test fails consistently when index creation is expected to fail but 
> unexpectedly succeeds.



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

[jira] [Commented] (GEODE-2230) LuceneIndex.waitUntilFlushed should not have to wait for the queue to be completely empty

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2230:


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

GEODE-2230: Added AsyncEventQueue and GatewaySender waitUntilFlushed API


> LuceneIndex.waitUntilFlushed should not have to wait for the queue to be 
> completely empty
> -
>
> Key: GEODE-2230
> URL: https://issues.apache.org/jira/browse/GEODE-2230
> Project: Geode
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Dan Smith
>
> We added a function to LuceneIndex to wait until updates are flushed to the 
> index with GEODE-1351.
> Unfortunately, the current approach has a few problems. It just waits in a 
> loop polling the size of the queue until it reaches zero. If someone uses 
> this method while the system is constantly receiving updates, the queue may 
> never reach zero.
> It would be better if this method could wait until any data at the time the 
> method was called was completely flushed.
> One way to accomplish this might be to send a function or message to all of 
> the members holding the async event queue for the lucene index. The function 
> could capture the current tail of the queue and wait until that event is 
> dispatched.



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

[jira] [Commented] (GEODE-2325) Improve tests for JarDeployer

[ASF GitHub Bot (JIRA)]

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

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

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/361
  
Precheckin passed (other than an unrelated failure in 
`PRClientServerRegionFunctionExecutionFailoverDUnitTest. 
testServerFailoverWithTwoServerAliveHA`)


> Improve tests for JarDeployer
> -
>
> Key: GEODE-2325
> URL: https://issues.apache.org/jira/browse/GEODE-2325
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> org.apache.geode.internal.JarDeployer only has a DUnit test right now.  Many 
> of those test methods are really just unit tests, and should be extracted to 
> run as such.  The tests can also be cleaned up a lot with AssertJ.  



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

[jira] [Commented] (GEODE-2325) Improve tests for JarDeployer

[ASF GitHub Bot (JIRA)]

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

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

GitHub user jaredjstewart opened a pull request:

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

GEODE-2325: Improve tests for JarDeployer



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

$ git pull https://github.com/jaredjstewart/geode GEODE-2325

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

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






> Improve tests for JarDeployer
> -
>
> Key: GEODE-2325
> URL: https://issues.apache.org/jira/browse/GEODE-2325
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> org.apache.geode.internal.JarDeployer only has a DUnit test right now.  Many 
> of those test methods are really just unit tests, and should be extracted to 
> run as such.  The tests can also be cleaned up a lot with AssertJ.  



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

[GitHub] geode pull request #361: GEODE-2325: Improve tests for JarDeployer

[jaredjstewart]

GitHub user jaredjstewart opened a pull request:

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

GEODE-2325: Improve tests for JarDeployer



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

$ git pull https://github.com/jaredjstewart/geode GEODE-2325

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

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






---
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 #361: GEODE-2325: Improve tests for JarDeployer

[jaredjstewart]

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/361
  
Precheckin passed (other than an unrelated failure in 
`PRClientServerRegionFunctionExecutionFailoverDUnitTest. 
testServerFailoverWithTwoServerAliveHA`)


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

Review Request 55965: GEODE-1930: fix exception messages in DUnitLauncher

[Kirk Lund]

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

Review request for geode, Bruce Schuchardt, Jared Stewart, and Kevin Duling.


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


Repository: geode


Description
---

This is for a follow-up commit to my latest commit for GEODE-1930. I had fixed 
a couple Exceptions strings in DUnitLauncher. When I merged that commit to 
develop, it combined in a strange way with a commit that Bruce made. This is my 
attempt to fix up DUnitLauncher back to what Bruce had. The other option is to 
revert my commit and repeat the merge but leave out DUnitLauncher.

For reference, here are the two constants used in the modified code:
```java
  static final long STARTUP_TIMEOUT = 120 * 1000;
  private static final String STARTUP_TIMEOUT_MESSAGE =
  "VMs did not start up within " + (STARTUP_TIMEOUT / 1000) + " seconds";
```


Diffs
-

  
geode-core/src/test/java/org/apache/geode/test/dunit/standalone/DUnitLauncher.java
 92a7c46950dd9d0a0029ba511b187e36169accbc 

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


Testing
---

precheckin in progress


Thanks,

Kirk Lund

[jira] [Closed] (GEODE-1923) CI Failure: FixedPRSinglehopDUnitTest.test_FPAmetadataFetch

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-1923.
--

> 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
>Affects Versions: 1.0.0-incubating
>Reporter: Eric Shu
>Assignee: Galen O'Sullivan
>  Labels: ci, flaky
> Fix For: 1.1.0
>
>
> 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.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.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.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> 

[jira] [Commented] (GEODE-2295) LocatorCancelException ignores string passed in constructor

[ASF GitHub Bot (JIRA)]

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

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

GitHub user galen-pivotal opened a pull request:

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

[GEODE-2295] Add constructors for `LocatorCancelException`.

[GEODE-2295] Add constructors for `LocatorCancelException`.

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

$ git pull https://github.com/galen-pivotal/incubator-geode 
feature/GEODE-2295

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

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


commit 41034c6b420b4c290012c787bfd46f0acf540030
Author: Galen O'Sullivan 
Date:   2017-01-12T01:00:05Z

[GEODE-2295] Add constructors for LocatorCancelException

and update one place where it's used.

commit 3e82a59d3fe2a38a32f118db4ede21a647444ad6
Author: Galen O'Sullivan 
Date:   2017-01-16T19:51:52Z

[GEODE-2295] Add super() to empty constructor,

remove final to be consistent.




> LocatorCancelException ignores string passed in constructor
> ---
>
> Key: GEODE-2295
> URL: https://issues.apache.org/jira/browse/GEODE-2295
> Project: Geode
>  Issue Type: Bug
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>Priority: Minor
>
> The` LocatorCancelException` class has a constructor that takes a String and 
> fails to call `super`. This should be fixed so that the exception produces a 
> useful message.



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

Re: Review Request 55890: GEODE-2354: set global session timeout to MAX_VALUE

[Kirk Lund]

> On Jan. 25, 2017, 9:59 p.m., Swapnil Bawaskar wrote:
> > Form this page (https://shiro.apache.org/session-management.html):
> > "By default, Shiro’s SessionManager implementations default to a 30 minute 
> > session timeout. That is, if any Session created remains idle (unused, 
> > where its lastAccessedTime isn’t updated) for 30 minutes or more, the 
> > Session is considered expired and will not be allowed to be used anymore.
> > You can set the default SessionManager implementation’s 
> > globalSessionTimeout property to define the default timeout value for all 
> > sessions. For example, if you wanted the timeout to be an hour instead of 
> > 30 minutes."
> > 
> > Given that wouldn't a better fix be to update lastAccessedTime as apposed 
> > to never expiring a session?

We'd have to create a thread that would need to wake up periodically before the 
session would expire and have that thread update lastAccessedTime. The thread 
would have to be located inside the server process. It would be more work. I'm 
more tempted to put this change in and then review the problem with Jinmei or 
others to see if we should change the fix.


- Kirk


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


On Jan. 25, 2017, 7:01 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55890/
> ---
> 
> (Updated Jan. 25, 2017, 7:01 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, and 
> Swapnil Bawaskar.
> 
> 
> Bugs: GEODE-2354
> https://issues.apache.org/jira/browse/GEODE-2354
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Use of security-manager results in 
> org.apache.shiro.session.UnknownSessionExceptions being thrown from protected 
> operations after 30 minutes idle (the default global session timeout in 
> Apache Shiro).
> 
> GFSH connects to the JMX Manager but this connection has no timeout even if 
> the cluster is secured. So after 30 minutes of being idle, GFSH will remain 
> connected to the JMX Manager but all commands that are protected will result 
> in an UnknownSessionException.
> 
> The changes in the change set simply set the global session timeout to 
> MAX_VALUE if the user has specified a security-manager. If the user specifies 
> security-shiro-init (for a custom shiro.ini) then we leave the global session 
> configuration to the user's shiro.ini.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  73d051f834425f1cf2c2164925f890bf42d36a9d 
> 
> Diff: https://reviews.apache.org/r/55890/diff/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

[jira] [Created] (GEODE-2369) Exporting cluster-config with just a filename throws an NPE

[Kevin Duling (JIRA)]

Kevin Duling created GEODE-2369:
---

 Summary: Exporting cluster-config with just a filename throws an 
NPE
 Key: GEODE-2369
 URL: https://issues.apache.org/jira/browse/GEODE-2369
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Kevin Duling


When running export cluster-configuration from gfsh and providing just a 
filename rather than an absolute path, or a filename and the --dir parameter, 
an exception is thrown.

The {{--dir}} option appears to be unused.

{noformat}
[info 2017/01/25 13:10:08.436 PST locator1  
tid=0x46] (tid=70 msgId=67) Could not execute "export
 cluster-configuration --zip-file-name=cluster.zip --dir=/tmp".
java.lang.NullPointerException
at 
org.apache.geode.management.internal.cli.commands.ExportImportClusterConfigurationCommands.exportSharedConfig(ExportImport
ClusterConfigurationCommands.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
at 
org.apache.geode.management.internal.cli.remote.RemoteExecutionStrategy.execute(RemoteExecutionStrategy.java:91)
at 
org.apache.geode.management.internal.cli.remote.CommandProcessor.executeCommand(CommandProcessor.java:117)
at 
org.apache.geode.management.internal.cli.remote.CommandStatementImpl.process(CommandStatementImpl.java:71)
at 
org.apache.geode.management.internal.cli.remote.MemberCommandService.processCommand(MemberCommandService.java:52)
at 
org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1639)
at 
org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:404)
at 
org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:397)
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 sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
at 
com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
at 
com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
at 
com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
at 
com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
at 
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at 
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
at 
javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
at 
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
at 
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
at 
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
{noformat}

*Work Around*
Provide a fully qualified path
{noformat}
gfsh>export cluster-configuration --zip-file-name=/tmp/cluster.zip
Downloading cluster configuration : 

[jira] [Created] (GEODE-2368) Need to fix log message in DirectChannel

[Hitesh Khamesra (JIRA)]

Hitesh Khamesra created GEODE-2368:
--

 Summary: Need to fix log message in DirectChannel
 Key: GEODE-2368
 URL: https://issues.apache.org/jira/browse/GEODE-2368
 Project: Geode
  Issue Type: Bug
  Components: membership
Reporter: Hitesh Khamesra


gemfire1_21824/system.log:[info 2017/01/22 09:05:57.047 UTC 
gemfire1_rs-wipCIRegrFull-client-22_21824 
 tid=0x14] GemFire P2P 
Listener started on  null

While printing this log, memberid is not initialized need to fix this.



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

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #450 has FAILED (11 tests failed, no failures were new)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #450 failed.
---
Scheduled
11/1666 tests failed, no failures were new.

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

-
Currently Responsible
-

John Blum 



--
Failing Jobs
--
  - Default Job (Default Stage): 11 of 1666 tests failed.




--
Tests
--
Existing Test Failures (11)
   - ClientSubRegionTest: Org.springframework.data.gemfire.client. client sub 
region test
   - GemFireDataSourceTest: Org.springframework.data.gemfire.client. gem fire 
data source test
   - GemFireDataSourceWithLocalRegionTest: 
Org.springframework.data.gemfire.client. gem fire data source with local region 
test
   - ContinuousQueryListenerContainerNamespaceTest: 
Org.springframework.data.gemfire.config.xml. continuous query listener 
container namespace test
   - ClientCacheFunctionExecutionWithPdxIntegrationTest: 
Org.springframework.data.gemfire.function. client cache function execution with 
pdx integration test
   - FunctionExecutionTests: 
Org.springframework.data.gemfire.function.execution. function execution tests
   - FunctionIntegrationTests: 
Org.springframework.data.gemfire.function.execution. function integration tests
   - GemfireFunctionTemplateTests: 
Org.springframework.data.gemfire.function.execution. gemfire function template 
tests
   - ListenerContainerTests: Org.springframework.data.gemfire.listener. 
listener container tests
   - ContainerXmlSetupTest: Org.springframework.data.gemfire.listener.adapter. 
container xml setup test
   - RepositoryClientRegionTests: 
Org.springframework.data.gemfire.repository.config. repository client region 
tests

--
This message is automatically generated by Atlassian Bamboo

Re: Review Request 55956: GEODE-2367: Lucene indexes do not handle ha scenarios

[Dan Smith]

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



Hey,

Looks like this is a big improvement on the reliability of this stuff. I have 
some comments, but if we need to tackle this incrementally thats fine.


geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/AbstractPartitionedRepositoryManager.java
 (line 122)


Why is this doing a second get?



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/AbstractPartitionedRepositoryManager.java
 (line 132)


Maybe this should be remove instead of get?



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/IndexRepositoryFactory.java
 (line 64)


This may somehow need to be synchronized with the cleanup code, to handle 
race conditions where we lose the primary status in the middle of this code.

Maybe add all of these tasks to an a thread pool with a single thread? If 
you do that, make sure the thread pool is fair and garuantees the tasks will be 
executed in order.



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LucenePrimaryBucketListener.java
 (line 58)


Should probably be logged or something?



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/repository/IndexRepositoryImpl.java
 (line 167)


It would probably be better to pass in the lock service and the key to 
avoid casting and having this class know about a concrete bucket.



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/repository/IndexRepositoryImpl.java
 (line 174)


Maybe the unlock should be the last thing that happens, so that another 
member can't create a writer until after this member closes the writer.


- Dan Smith


On Jan. 25, 2017, 8:46 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55956/
> ---
> 
> (Updated Jan. 25, 2017, 8:46 p.m.)
> 
> 
> Review request for geode, Barry Oglesby, nabarun nag, Dan Smith, and xiaojian 
> zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Added afterSecondary callback to partition listener to allow cleaning up of 
> the index repo when the bucket losses primary
> Added lock prior to creating the bucket indexes to prevent multiple index 
> writers from being available at a time
> Changed single point of lucene index creation, no longer creating on the fly
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/cache/partition/PartitionListener.java
>  a534e50 
>   geode-core/src/main/java/org/apache/geode/internal/cache/BucketAdvisor.java 
> 7b79bfb 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/AbstractPartitionedRepositoryManager.java
>  aa29e1b 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/IndexRepositoryFactory.java
>  c73d64a 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneEventListener.java
>  f2c7c8f 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LucenePrimaryBucketListener.java
>  d17b5f2 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/repository/IndexRepositoryImpl.java
>  4e86eb5 
> 
> Diff: https://reviews.apache.org/r/55956/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Review Request 55890: GEODE-2354: set global session timeout to MAX_VALUE

[Swapnil Bawaskar]

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



Form this page (https://shiro.apache.org/session-management.html):
"By default, Shiro’s SessionManager implementations default to a 30 minute 
session timeout. That is, if any Session created remains idle (unused, where 
its lastAccessedTime isn’t updated) for 30 minutes or more, the Session is 
considered expired and will not be allowed to be used anymore.
You can set the default SessionManager implementation’s globalSessionTimeout 
property to define the default timeout value for all sessions. For example, if 
you wanted the timeout to be an hour instead of 30 minutes."

Given that wouldn't a better fix be to update lastAccessedTime as apposed to 
never expiring a session?

- Swapnil Bawaskar


On Jan. 25, 2017, 7:01 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55890/
> ---
> 
> (Updated Jan. 25, 2017, 7:01 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, and 
> Swapnil Bawaskar.
> 
> 
> Bugs: GEODE-2354
> https://issues.apache.org/jira/browse/GEODE-2354
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Use of security-manager results in 
> org.apache.shiro.session.UnknownSessionExceptions being thrown from protected 
> operations after 30 minutes idle (the default global session timeout in 
> Apache Shiro).
> 
> GFSH connects to the JMX Manager but this connection has no timeout even if 
> the cluster is secured. So after 30 minutes of being idle, GFSH will remain 
> connected to the JMX Manager but all commands that are protected will result 
> in an UnknownSessionException.
> 
> The changes in the change set simply set the global session timeout to 
> MAX_VALUE if the user has specified a security-manager. If the user specifies 
> security-shiro-init (for a custom shiro.ini) then we leave the global session 
> configuration to the user's shiro.ini.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  73d051f834425f1cf2c2164925f890bf42d36a9d 
> 
> Diff: https://reviews.apache.org/r/55890/diff/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

[jira] [Commented] (GEODE-2351) Update cpp quickstarts

[ASF GitHub Bot (JIRA)]

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

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

Github user mmartell closed the pull request at:

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


> Update cpp quickstarts
> --
>
> Key: GEODE-2351
> URL: https://issues.apache.org/jira/browse/GEODE-2351
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Ernest Burghardt
>
> Transform Gemfire => Geode as appropriate



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

[jira] [Commented] (GEODE-2351) Update cpp quickstarts

[ASF GitHub Bot (JIRA)]

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

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

Github user pivotal-jbarrett commented on the issue:

https://github.com/apache/geode/pull/356
  
Rejecting.

Path "pivotal-gemfire-*" should be "apache-geode-*".


> Update cpp quickstarts
> --
>
> Key: GEODE-2351
> URL: https://issues.apache.org/jira/browse/GEODE-2351
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Ernest Burghardt
>
> Transform Gemfire => Geode as appropriate



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

[GitHub] geode issue #357: GEODE-2351: Update the cpp quickstarts to use geode instea...

[pivotal-jbarrett]

Github user pivotal-jbarrett commented on the issue:

https://github.com/apache/geode/pull/357
  
rejecting as duplicate of #356 


---
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] [Updated] (GEODE-2364) gfsh cannot connect to a remote locator

[Kevin Duling (JIRA)]

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

Kevin Duling updated GEODE-2364:

Priority: Minor  (was: Major)

> gfsh cannot connect to a remote locator
> ---
>
> Key: GEODE-2364
> URL: https://issues.apache.org/jira/browse/GEODE-2364
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kevin Duling
>Priority: Minor
>
> *Environment*
> locator running on Ubuntu 64-bit (192.168.1.45)
> server running on OSX (192.168.1.187)
> *Steps to Reproduce*
> 1. Start locator on ubuntu: 
> {noformat}gfsh start locator --name=locator1 
> --bind-address=192.168.1.45{noformat}
> 2. Start server on Mac: 
> {noformat}gfsh start server --name=server1 
> --locators=192.168.1.45[10334]{noformat}
> 3. Start gfsh on Mac and try to connect to the locator: 
> {noformat}
> > gfsh
> gfsh> connect --locator=192.168.1.45[10334]{noformat}
> *Validate*
> {noformat}
> gfsh>list members
>   Name   | Id
>  | -
> server1  | 192.168.1.187(server1:4242):1024
> locator1 | 192.168.1.45(locator1:12646:locator):1024
> {noformat}
> *Result*
> {code}
> gfsh>connect --locator=192.168.1.45[10334]
> Connecting to Locator at [host=192.168.1.45, port=10334] ..
> Connecting to Manager at [host=192.168.1.45, port=1099] ..
> Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
> host: 127.0.1.1; nested exception is: 
> java.net.ConnectException: Operation timed out
> Input/output error
> Exiting... 
> Exception in thread "main" java.lang.NullPointerException
>   at 
> org.apache.geode.management.internal.cli.Launcher.parseOptions(Launcher.java:252)
>   at 
> org.apache.geode.management.internal.cli.Launcher.parseCommandLine(Launcher.java:260)
>   at 
> org.apache.geode.management.internal.cli.Launcher.main(Launcher.java:107)
> Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
> host: 127.0.1.1; nested exception is: 
> java.net.ConnectException: Operation timed out
> {code}
> *Work Around*
> Start the locator up with additional flags to return the correct address of 
> the JMX server.
> {noformat}
> gfsh start locator --name=locator1 --bind-address=192.168.1.45 
> --J=-Dgemfire.jmx-manager-hostname-for-clients=192.168.1.45 
> --J=-Djava.rmi-server.hostname=192.168.1.45
> {noformat}
> The error should be more informative, guiding the user to these parameters 
> that need to be specified on startup of the locator.  Or the locator should 
> bind to the JMX port, honoring the {{--bind-address}} flag.



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

[jira] [Updated] (GEODE-2364) gfsh cannot connect to a remote locator

[Kevin Duling (JIRA)]

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

Kevin Duling updated GEODE-2364:

Description: 
*Environment*
locator running on Ubuntu 64-bit (192.168.1.45)
server running on OSX (192.168.1.187)

*Steps to Reproduce*
1. Start locator on ubuntu: 
{noformat}gfsh start locator --name=locator1 
--bind-address=192.168.1.45{noformat}
2. Start server on Mac: 
{noformat}gfsh start server --name=server1 
--locators=192.168.1.45[10334]{noformat}
3. Start gfsh on Mac and try to connect to the locator: 
{noformat}
> gfsh
gfsh> connect --locator=192.168.1.45[10334]{noformat}

*Validate*
{noformat}
gfsh>list members
  Name   | Id
 | -
server1  | 192.168.1.187(server1:4242):1024
locator1 | 192.168.1.45(locator1:12646:locator):1024
{noformat}

*Result*
{code}
gfsh>connect --locator=192.168.1.45[10334]
Connecting to Locator at [host=192.168.1.45, port=10334] ..
Connecting to Manager at [host=192.168.1.45, port=1099] ..
Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
host: 127.0.1.1; nested exception is: 
java.net.ConnectException: Operation timed out

Input/output error
Exiting... 
Exception in thread "main" java.lang.NullPointerException
at 
org.apache.geode.management.internal.cli.Launcher.parseOptions(Launcher.java:252)
at 
org.apache.geode.management.internal.cli.Launcher.parseCommandLine(Launcher.java:260)
at 
org.apache.geode.management.internal.cli.Launcher.main(Launcher.java:107)
Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
host: 127.0.1.1; nested exception is: 
java.net.ConnectException: Operation timed out
{code}

  was:
*Environment*
locator running on Ubuntu 64-bit (192.168.1.45)
server running on OSX (192.168.1.187)

*Steps to Reproduce*
1. Start locator on ubuntu: 
.bq gfsh start locator --name=locator1 --bind-address=192.168.1.45
2. Start server on Mac: _gfsh start server --name=server1 
--locators=192.168.1.45[10334]_
3. Start gfsh on Mac and try to connect to the locator: _connect 
--locator=192.168.1.45[10334]_

*Validate*
{code}
gfsh>list members
  Name   | Id
 | -
server1  | 192.168.1.187(server1:4242):1024
locator1 | 192.168.1.45(locator1:12646:locator):1024
{code}

*Result*
{code}
gfsh>connect --locator=192.168.1.45[10334]
Connecting to Locator at [host=192.168.1.45, port=10334] ..
Connecting to Manager at [host=192.168.1.45, port=1099] ..
Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
host: 127.0.1.1; nested exception is: 
java.net.ConnectException: Operation timed out

Input/output error
Exiting... 
Exception in thread "main" java.lang.NullPointerException
at 
org.apache.geode.management.internal.cli.Launcher.parseOptions(Launcher.java:252)
at 
org.apache.geode.management.internal.cli.Launcher.parseCommandLine(Launcher.java:260)
at 
org.apache.geode.management.internal.cli.Launcher.main(Launcher.java:107)
Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
host: 127.0.1.1; nested exception is: 
java.net.ConnectException: Operation timed out
{code}


> gfsh cannot connect to a remote locator
> ---
>
> Key: GEODE-2364
> URL: https://issues.apache.org/jira/browse/GEODE-2364
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kevin Duling
>
> *Environment*
> locator running on Ubuntu 64-bit (192.168.1.45)
> server running on OSX (192.168.1.187)
> *Steps to Reproduce*
> 1. Start locator on ubuntu: 
> {noformat}gfsh start locator --name=locator1 
> --bind-address=192.168.1.45{noformat}
> 2. Start server on Mac: 
> {noformat}gfsh start server --name=server1 
> --locators=192.168.1.45[10334]{noformat}
> 3. Start gfsh on Mac and try to connect to the locator: 
> {noformat}
> > gfsh
> gfsh> connect --locator=192.168.1.45[10334]{noformat}
> *Validate*
> {noformat}
> gfsh>list members
>   Name   | Id
>  | -
> server1  | 192.168.1.187(server1:4242):1024
> locator1 | 192.168.1.45(locator1:12646:locator):1024
> {noformat}
> *Result*
> {code}
> gfsh>connect --locator=192.168.1.45[10334]
> Connecting to Locator at [host=192.168.1.45, port=10334] ..
> Connecting to Manager at [host=192.168.1.45, port=1099] ..
> Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
> host: 127.0.1.1; nested exception is: 
> java.net.ConnectException: Operation timed out
> Input/output error
> Exiting... 
> Exception in thread "main" java.lang.NullPointerException
>   at 
> org.apache.geode.management.internal.cli.Launcher.parseOptions(Launcher.java:252)
>   at 
> 

[jira] [Updated] (GEODE-2364) gfsh cannot connect to a remote locator

[Kevin Duling (JIRA)]

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

Kevin Duling updated GEODE-2364:

Description: 
*Environment*
locator running on Ubuntu 64-bit (192.168.1.45)
server running on OSX (192.168.1.187)

*Steps to Reproduce*
1. Start locator on ubuntu: 
.bq gfsh start locator --name=locator1 --bind-address=192.168.1.45
2. Start server on Mac: _gfsh start server --name=server1 
--locators=192.168.1.45[10334]_
3. Start gfsh on Mac and try to connect to the locator: _connect 
--locator=192.168.1.45[10334]_

*Validate*
{code}
gfsh>list members
  Name   | Id
 | -
server1  | 192.168.1.187(server1:4242):1024
locator1 | 192.168.1.45(locator1:12646:locator):1024
{code}

*Result*
{code}
gfsh>connect --locator=192.168.1.45[10334]
Connecting to Locator at [host=192.168.1.45, port=10334] ..
Connecting to Manager at [host=192.168.1.45, port=1099] ..
Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
host: 127.0.1.1; nested exception is: 
java.net.ConnectException: Operation timed out

Input/output error
Exiting... 
Exception in thread "main" java.lang.NullPointerException
at 
org.apache.geode.management.internal.cli.Launcher.parseOptions(Launcher.java:252)
at 
org.apache.geode.management.internal.cli.Launcher.parseCommandLine(Launcher.java:260)
at 
org.apache.geode.management.internal.cli.Launcher.main(Launcher.java:107)
Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
host: 127.0.1.1; nested exception is: 
java.net.ConnectException: Operation timed out
{code}

  was:
*Environment*
locator running on Ubuntu 64-bit (192.168.1.45)
server running on OSX (192.168.1.187)

*Steps to Reproduce*
1. Start locator on ubuntu: {{gfsh start locator --name=locator1}}
2. Start server on Mac: {{gfsh start server --name=server1 
--locators=x.x.x.x[10334]}}
3. Start gfsh on Mac and try to connect to the locator: {{connect 
--locator=x.x.x.x[10334]}}

*Result*
{code}
gfsh>connect --locator=192.168.1.45[10334]
Connecting to Locator at [host=192.168.1.45, port=10334] ..
Connecting to Manager at [host=192.168.1.45, port=1099] ..
Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
host: 127.0.1.1; nested exception is: 
java.net.ConnectException: Operation timed out

Input/output error
Exiting... 
Exception in thread "main" java.lang.NullPointerException
at 
org.apache.geode.management.internal.cli.Launcher.parseOptions(Launcher.java:252)
at 
org.apache.geode.management.internal.cli.Launcher.parseCommandLine(Launcher.java:260)
at 
org.apache.geode.management.internal.cli.Launcher.main(Launcher.java:107)
Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
host: 127.0.1.1; nested exception is: 
java.net.ConnectException: Operation timed out
{code}


> gfsh cannot connect to a remote locator
> ---
>
> Key: GEODE-2364
> URL: https://issues.apache.org/jira/browse/GEODE-2364
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kevin Duling
>
> *Environment*
> locator running on Ubuntu 64-bit (192.168.1.45)
> server running on OSX (192.168.1.187)
> *Steps to Reproduce*
> 1. Start locator on ubuntu: 
> .bq gfsh start locator --name=locator1 --bind-address=192.168.1.45
> 2. Start server on Mac: _gfsh start server --name=server1 
> --locators=192.168.1.45[10334]_
> 3. Start gfsh on Mac and try to connect to the locator: _connect 
> --locator=192.168.1.45[10334]_
> *Validate*
> {code}
> gfsh>list members
>   Name   | Id
>  | -
> server1  | 192.168.1.187(server1:4242):1024
> locator1 | 192.168.1.45(locator1:12646:locator):1024
> {code}
> *Result*
> {code}
> gfsh>connect --locator=192.168.1.45[10334]
> Connecting to Locator at [host=192.168.1.45, port=10334] ..
> Connecting to Manager at [host=192.168.1.45, port=1099] ..
> Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
> host: 127.0.1.1; nested exception is: 
> java.net.ConnectException: Operation timed out
> Input/output error
> Exiting... 
> Exception in thread "main" java.lang.NullPointerException
>   at 
> org.apache.geode.management.internal.cli.Launcher.parseOptions(Launcher.java:252)
>   at 
> org.apache.geode.management.internal.cli.Launcher.parseCommandLine(Launcher.java:260)
>   at 
> org.apache.geode.management.internal.cli.Launcher.main(Launcher.java:107)
> Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
> host: 127.0.1.1; nested exception is: 
> java.net.ConnectException: Operation timed out
> {code}



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

[jira] [Created] (GEODE-2367) Lucene Index does not handle ha scenarios

[Jason Huynh (JIRA)]

Jason Huynh created GEODE-2367:
--

 Summary: Lucene Index does not handle ha scenarios
 Key: GEODE-2367
 URL: https://issues.apache.org/jira/browse/GEODE-2367
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Jason Huynh


In ha scenarios or during rebalance, the lucene index listeners allow multiple 
nodes to write to the file/chunk regions.  

The Index repositories are also not being cleaned up when a bucket goes from 
primary to secondary.

This work will need to refactor the creation of the Lucene index to not create 
one on the "fly" when a get/or query function is executed.  Otherwise a 
function execution on a node that has just been turned secondary, may cause it 
to create an index repo that it should not create.





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

[jira] [Created] (GEODE-2366) update clicache/integration-test

[Michael Martell (JIRA)]

Michael Martell created GEODE-2366:
--

 Summary: update clicache/integration-test 
 Key: GEODE-2366
 URL: https://issues.apache.org/jira/browse/GEODE-2366
 Project: Geode
  Issue Type: Sub-task
  Components: native client
Reporter: Michael Martell
 Fix For: 1.1.0






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

[jira] [Created] (GEODE-2365) update clicache/src

[Michael Martell (JIRA)]

Michael Martell created GEODE-2365:
--

 Summary: update clicache/src
 Key: GEODE-2365
 URL: https://issues.apache.org/jira/browse/GEODE-2365
 Project: Geode
  Issue Type: Sub-task
  Components: native client
Reporter: Michael Martell
 Fix For: 1.1.0


Update all sources below src/clicache/src from gemfire to geode



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

[jira] [Updated] (GEODE-2364) gfsh cannot connect to a remote locator

[Kevin Duling (JIRA)]

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

Kevin Duling updated GEODE-2364:

Description: 
*Environment*
locator running on Ubuntu 64-bit (192.168.1.45)
server running on OSX (192.168.1.187)

*Steps to Reproduce*
1. Start locator on ubuntu: {{gfsh start locator --name=locator1}}
2. Start server on Mac: {{gfsh start server --name=server1 
--locators=x.x.x.x[10334]}}
3. Start gfsh on Mac and try to connect to the locator: {{connect 
--locator=x.x.x.x[10334]}}

*Result*
{code}
gfsh>connect --locator=192.168.1.45[10334]
Connecting to Locator at [host=192.168.1.45, port=10334] ..
Connecting to Manager at [host=192.168.1.45, port=1099] ..
Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
host: 127.0.1.1; nested exception is: 
java.net.ConnectException: Operation timed out

Input/output error
Exiting... 
Exception in thread "main" java.lang.NullPointerException
at 
org.apache.geode.management.internal.cli.Launcher.parseOptions(Launcher.java:252)
at 
org.apache.geode.management.internal.cli.Launcher.parseCommandLine(Launcher.java:260)
at 
org.apache.geode.management.internal.cli.Launcher.main(Launcher.java:107)
Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
host: 127.0.1.1; nested exception is: 
java.net.ConnectException: Operation timed out
{code}

  was:
*Environment*
locator running on Ubuntu 64-bit
server running on OSX

*Steps to Reproduce*
1. Start locator on ubuntu: {{gfsh start locator --name=locator1}}
2. Start server on Mac: {{gfsh start server --name=server1 
--locators=x.x.x.x[10334]}}
3. Start gfsh on Mac and try to connect to the locator: {{connect 
--locator=x.x.x.x[10334]}}

*Result*
{code}
gfsh>connect --locator=192.168.1.45[10334]
Connecting to Locator at [host=192.168.1.45, port=10334] ..
Connecting to Manager at [host=192.168.1.45, port=1099] ..
Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
host: 127.0.1.1; nested exception is: 
java.net.ConnectException: Operation timed out

Input/output error
Exiting... 
Exception in thread "main" java.lang.NullPointerException
at 
org.apache.geode.management.internal.cli.Launcher.parseOptions(Launcher.java:252)
at 
org.apache.geode.management.internal.cli.Launcher.parseCommandLine(Launcher.java:260)
at 
org.apache.geode.management.internal.cli.Launcher.main(Launcher.java:107)
Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
host: 127.0.1.1; nested exception is: 
java.net.ConnectException: Operation timed out
{code}


> gfsh cannot connect to a remote locator
> ---
>
> Key: GEODE-2364
> URL: https://issues.apache.org/jira/browse/GEODE-2364
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kevin Duling
>
> *Environment*
> locator running on Ubuntu 64-bit (192.168.1.45)
> server running on OSX (192.168.1.187)
> *Steps to Reproduce*
> 1. Start locator on ubuntu: {{gfsh start locator --name=locator1}}
> 2. Start server on Mac: {{gfsh start server --name=server1 
> --locators=x.x.x.x[10334]}}
> 3. Start gfsh on Mac and try to connect to the locator: {{connect 
> --locator=x.x.x.x[10334]}}
> *Result*
> {code}
> gfsh>connect --locator=192.168.1.45[10334]
> Connecting to Locator at [host=192.168.1.45, port=10334] ..
> Connecting to Manager at [host=192.168.1.45, port=1099] ..
> Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
> host: 127.0.1.1; nested exception is: 
> java.net.ConnectException: Operation timed out
> Input/output error
> Exiting... 
> Exception in thread "main" java.lang.NullPointerException
>   at 
> org.apache.geode.management.internal.cli.Launcher.parseOptions(Launcher.java:252)
>   at 
> org.apache.geode.management.internal.cli.Launcher.parseCommandLine(Launcher.java:260)
>   at 
> org.apache.geode.management.internal.cli.Launcher.main(Launcher.java:107)
> Could not connect to : [host=192.168.1.45, port=1099]. Connection refused to 
> host: 127.0.1.1; nested exception is: 
> java.net.ConnectException: Operation timed out
> {code}



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

Re: Karma to Delete JIRAs

[Kirk Lund]

Done.

On Wed, Jan 25, 2017 at 11:20 AM, Jacob Barrett  wrote:

> Does anyone have enough karma to delete JIRAs? Someone created a clone of a
> ticket with lots of sub tickets and I would like to make it go away. If you
> can delete GEODE-2359 through GEODE-2363 please. If there isn't anyone with
> karma then I will just close them but that looks gross.
>
> Thanks,
> Jake
>

[jira] [Deleted] (GEODE-2361) CLONE - Update GemfireStatisticsFactory

[Kirk Lund (JIRA)]

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

Kirk Lund deleted GEODE-2361:
-


> CLONE - Update  GemfireStatisticsFactory
> 
>
> Key: GEODE-2361
> URL: https://issues.apache.org/jira/browse/GEODE-2361
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Michael Martell
>
> Gem fire => Geode transformation
> the following files are called Gemfire* let's make them Geode*
> src//cppcache/src/statistics/GemfireStatisticsFactory.cpp
> src//cppcache/src/statistics/GemfireStatisticsFactory.hpp
> Also, update inclusions usage and named components as appropriate.



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

[jira] [Deleted] (GEODE-2363) CLONE - Update cli quickstarts

[Kirk Lund (JIRA)]

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

Kirk Lund deleted GEODE-2363:
-


> CLONE - Update cli quickstarts
> --
>
> Key: GEODE-2363
> URL: https://issues.apache.org/jira/browse/GEODE-2363
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Michael Martell
>
> Transform Gemfire => Geode as appropriate



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

[jira] [Deleted] (GEODE-2362) CLONE - Update cpp quickstarts

[Kirk Lund (JIRA)]

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

Kirk Lund deleted GEODE-2362:
-


> CLONE - Update cpp quickstarts
> --
>
> Key: GEODE-2362
> URL: https://issues.apache.org/jira/browse/GEODE-2362
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Michael Martell
>
> Transform Gemfire => Geode as appropriate



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

[jira] [Deleted] (GEODE-2359) CLONE - Update GemfireCppCache

[Kirk Lund (JIRA)]

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

Kirk Lund deleted GEODE-2359:
-


> CLONE - Update GemfireCppCache
> --
>
> Key: GEODE-2359
> URL: https://issues.apache.org/jira/browse/GEODE-2359
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Michael Martell
>
> the following files are called Gemfire* let's make them Geode*
> src//cppcache/include/gfcpp/GemfireCppCache.hpp
> src//cppcache/include/gfcpp/GemfireCppCache.inl
> Also, update inclusions usage and named components as appropriate.



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

[jira] [Deleted] (GEODE-2360) CLONE - Update GemfireTypeIds

[Kirk Lund (JIRA)]

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

Kirk Lund deleted GEODE-2360:
-


> CLONE - Update GemfireTypeIds
> -
>
> Key: GEODE-2360
> URL: https://issues.apache.org/jira/browse/GEODE-2360
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Michael Martell
>
> Gem fire => Geode transformation
> the following files are called Gemfire* let's make them Geode*
> src//cppcache/include/gfcpp/GemfireTypeIds.hpp
> src//cppcache/src/GemfireTypeIdsImpl.hpp
> Also, update inclusions usage and named components as appropriate.



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

Karma to Delete JIRAs

[Jacob Barrett]

Does anyone have enough karma to delete JIRAs? Someone created a clone of a
ticket with lots of sub tickets and I would like to make it go away. If you
can delete GEODE-2359 through GEODE-2363 please. If there isn't anyone with
karma then I will just close them but that looks gross.

Thanks,
Jake

[jira] [Commented] (GEODE-2342) Update GemfireTypeIds

[ASF GitHub Bot (JIRA)]

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

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

GitHub user mmartell opened a pull request:

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

GEODE-2342: Rename GemfireTypeIds class to GeodeTypeIds to match corr…

…esponding file name change. Note, this was missed in the intitial commit.

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

$ git pull https://github.com/mmartell/geode feature/GEODE-2342

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

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


commit a9d28634d4f21b5bd34e28d5fa3c0d75b080c634
Author: Mike Martell 
Date:   2017-01-25T19:11:46Z

GEODE-2342: Rename GemfireTypeIds class to GeodeTypeIds to match 
corresponding file name change. Note, this was missed in the intitial commit.




> Update GemfireTypeIds
> -
>
> Key: GEODE-2342
> URL: https://issues.apache.org/jira/browse/GEODE-2342
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Ernest Burghardt
> Fix For: 1.1.0
>
>
> Gem fire => Geode transformation
> the following files are called Gemfire* let's make them Geode*
> src//cppcache/include/gfcpp/GemfireTypeIds.hpp
> src//cppcache/src/GemfireTypeIdsImpl.hpp
> Also, update inclusions usage and named components as appropriate.



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

[GitHub] geode pull request #358: GEODE-2342: Rename GemfireTypeIds class to GeodeTyp...

[mmartell]

GitHub user mmartell opened a pull request:

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

GEODE-2342: Rename GemfireTypeIds class to GeodeTypeIds to match corr…

…esponding file name change. Note, this was missed in the intitial commit.

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

$ git pull https://github.com/mmartell/geode feature/GEODE-2342

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

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


commit a9d28634d4f21b5bd34e28d5fa3c0d75b080c634
Author: Mike Martell 
Date:   2017-01-25T19:11:46Z

GEODE-2342: Rename GemfireTypeIds class to GeodeTypeIds to match 
corresponding file name change. Note, this was missed in the intitial commit.




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

Re: Review Request 55890: GEODE-2354: set global session timeout to MAX_VALUE

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On Jan. 25, 2017, 7:01 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55890/
> ---
> 
> (Updated Jan. 25, 2017, 7:01 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, and 
> Swapnil Bawaskar.
> 
> 
> Bugs: GEODE-2354
> https://issues.apache.org/jira/browse/GEODE-2354
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Use of security-manager results in 
> org.apache.shiro.session.UnknownSessionExceptions being thrown from protected 
> operations after 30 minutes idle (the default global session timeout in 
> Apache Shiro).
> 
> GFSH connects to the JMX Manager but this connection has no timeout even if 
> the cluster is secured. So after 30 minutes of being idle, GFSH will remain 
> connected to the JMX Manager but all commands that are protected will result 
> in an UnknownSessionException.
> 
> The changes in the change set simply set the global session timeout to 
> MAX_VALUE if the user has specified a security-manager. If the user specifies 
> security-shiro-init (for a custom shiro.ini) then we leave the global session 
> configuration to the user's shiro.ini.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  73d051f834425f1cf2c2164925f890bf42d36a9d 
> 
> Diff: https://reviews.apache.org/r/55890/diff/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 55890: GEODE-2354: set global session timeout to MAX_VALUE

[Kirk Lund]

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

(Updated Jan. 25, 2017, 7:01 p.m.)


Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, and Swapnil 
Bawaskar.


Changes
---

Added a couple checks and log custom error messages if unable to increase 
global session timeout.


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


Repository: geode


Description
---

Use of security-manager results in 
org.apache.shiro.session.UnknownSessionExceptions being thrown from protected 
operations after 30 minutes idle (the default global session timeout in Apache 
Shiro).

GFSH connects to the JMX Manager but this connection has no timeout even if the 
cluster is secured. So after 30 minutes of being idle, GFSH will remain 
connected to the JMX Manager but all commands that are protected will result in 
an UnknownSessionException.

The changes in the change set simply set the global session timeout to 
MAX_VALUE if the user has specified a security-manager. If the user specifies 
security-shiro-init (for a custom shiro.ini) then we leave the global session 
configuration to the user's shiro.ini.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
 73d051f834425f1cf2c2164925f890bf42d36a9d 

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


Testing
---

precheckin in progress


Thanks,

Kirk Lund

Re: To Spring or Not

[Jacob Barrett]

So what you are trying to do is to define types for formats that don't have
rich types (JSON, CSV, XML without Schema/DTD) and rigid structure for
formats without rigid structure structure (JSON is unordered, CSV has no
hierarchy, XML may not be strongly ordered) to map into a format that has
rich types and structure (PDX).

I worked through this problem some with the Greenplum database
synchronization work since the parallel transport mechanism is CSV. I
didn't really deal with ordering and forced order to match the query order
but I did have to tackle type conversion. I had a set of default
conversions from text to PDX but I had the added benefit of knowing the
schema of the fields in the database, so mapping rules were easier. What I
mean is that if a read text that was a whole number I didn't have to guess
if the field was nullable, long, short, etc. since that was defined in the
database. I did however provide some overrides for those fields to coerce
them into specific types, like DECIMAL to long rather than BigDecimal, etc.

I think what is really need, less than the primitive type converters is
really a way to describe the schema on both ends of the conversation. Both
JSON an CSV lack any form of formal schema. So then I ask myself does any
formal schema for these make sense because then we form on the end user the
need to use something special when talking to Geode to formally describe
their data. I feel it makes more sense to pick a strict "standard" we will
follow and let the end user convert around that if they need something
different.

The best example is time is JSON. JSON does not describe a time type. There
are some common standards, like ISO 8601 or long count from Unix epoch UTC.
Personally I would pick the epoch solution since conversions are a lot
easier from that to other representations than parsing text again from ISO
8601. Providing plugins for custom conversions strikes me as good way to
screw up something as complicated as date. So if our REST api presented the
date of one object in format X and the other in format Y but lacks any
formal exposed schema how is the consumer of the REST service to determine
the format rules and conversation to their local time format.

The other types in JSON don't concern me since 9/10 you are talking
JavaScript which doesn't support more types than JSON anyway, so number and
strings are good enough. When converting that from JSON to PDX the formal
schema of the PDX should be sufficient. The trick there may be getting the
formal schema of the PDX if no type has been defined yet. So what I would
argue for is a more configurable way to define PDX types that doesn't
require the implementation of a POJO first. In your "deployment" you could
use some XML or other configuration to formal describe a complex PDX
object.

-Jake


On Wed, Jan 25, 2017 at 10:34 AM Udo Kohlmeyer 
wrote:

> The thought was to have a framework that could convert any incoming
> format, provided you have a converter for it.
>
> Be it JSON,XML,CSV... maybe even eventually POJO -> PDX...
>
> Yes, the starting point is humble... but it can be grown to be a service
> that will convert data formats...
>
>
> On 1/25/17 10:29, Jacob Barrett wrote:
> > Does JAXB/JAX-RS not provide what yo are looking for to define JSON to
> > Object mapping?
> >
> >
> > On Wed, Jan 25, 2017 at 7:59 AM Udo Kohlmeyer  wrote:
> >
> >> Hi there,
> >>
> >> I'm currently working on a proposal on a Data Conversion Service. This
> >> service would primarily replace the ailing JSONFormatter, with the
> >> ability to provide some rules around how fields are converted (String ->
> >> Date, String -> Numeric, different Date formats). This of course could
> >> be extended to not only JSON but any format or any type that we have
> >> converters for.
> >>
> >> As I'm working through this process it was brought to my attention that
> >> Spring also had a great converter and formatter service, which has many
> >> more miles of proven capability under the belt, than what a custom
> >> written Data conversion service would bring.
> >>
> >> Pros:
> >>
> >>* Already written and proven framework
> >>* Tapping into knowledge of Spring users to write custom data
> >>  converters if the default converters don't match their needs
> >>* Dependent on a framework that is actively being worked on, thus
> less
> >>  chance of "stale" frameworks/libs
> >>
> >> Cons:
> >>
> >>* Write and maintain data conversion framework
> >>* Potentially having to deal with users and their Spring version
> >> conflicts
> >>* Core dependency on another framework outside of Geode
> >>
> >> Thoughts?!?
> >>
> >> --Udo
> >>
> >>
>
>

Re: To Spring or Not

[Udo Kohlmeyer]

The thought was to have a framework that could convert any incoming 
format, provided you have a converter for it.


Be it JSON,XML,CSV... maybe even eventually POJO -> PDX...

Yes, the starting point is humble... but it can be grown to be a service 
that will convert data formats...



On 1/25/17 10:29, Jacob Barrett wrote:

Does JAXB/JAX-RS not provide what yo are looking for to define JSON to
Object mapping?


On Wed, Jan 25, 2017 at 7:59 AM Udo Kohlmeyer  wrote:


Hi there,

I'm currently working on a proposal on a Data Conversion Service. This
service would primarily replace the ailing JSONFormatter, with the
ability to provide some rules around how fields are converted (String ->
Date, String -> Numeric, different Date formats). This of course could
be extended to not only JSON but any format or any type that we have
converters for.

As I'm working through this process it was brought to my attention that
Spring also had a great converter and formatter service, which has many
more miles of proven capability under the belt, than what a custom
written Data conversion service would bring.

Pros:

   * Already written and proven framework
   * Tapping into knowledge of Spring users to write custom data
 converters if the default converters don't match their needs
   * Dependent on a framework that is actively being worked on, thus less
 chance of "stale" frameworks/libs

Cons:

   * Write and maintain data conversion framework
   * Potentially having to deal with users and their Spring version
conflicts
   * Core dependency on another framework outside of Geode

Thoughts?!?

--Udo

Re: Review Request 55890: GEODE-2354: set global session timeout to MAX_VALUE

[Kirk Lund]

> On Jan. 24, 2017, 10:22 p.m., Jared Stewart wrote:
> > Do you think we ought to add a test to make sure the session timeout 
> > actually got set?  E.g. if `shiroManager.getSessionManager()` is not 
> > returning us a `DefaultSessionManager` then we won't have set a timeout

I like the idea of logging a warning if IntegratedSecurityService is unable to 
get the DefaultSessionManager or set the global session timeout. New diff 
coming soon.


- Kirk


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


On Jan. 24, 2017, 8:55 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55890/
> ---
> 
> (Updated Jan. 24, 2017, 8:55 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, and 
> Swapnil Bawaskar.
> 
> 
> Bugs: GEODE-2354
> https://issues.apache.org/jira/browse/GEODE-2354
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Use of security-manager results in 
> org.apache.shiro.session.UnknownSessionExceptions being thrown from protected 
> operations after 30 minutes idle (the default global session timeout in 
> Apache Shiro).
> 
> GFSH connects to the JMX Manager but this connection has no timeout even if 
> the cluster is secured. So after 30 minutes of being idle, GFSH will remain 
> connected to the JMX Manager but all commands that are protected will result 
> in an UnknownSessionException.
> 
> The changes in the change set simply set the global session timeout to 
> MAX_VALUE if the user has specified a security-manager. If the user specifies 
> security-shiro-init (for a custom shiro.ini) then we leave the global session 
> configuration to the user's shiro.ini.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  73d051f 
> 
> Diff: https://reviews.apache.org/r/55890/diff/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 55742: [GEODE-2324] and what look like a few other bugs in the same method.

[Bruce Schuchardt]

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




geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/AcceptorImplDUnitTest.java
 (line 87)


You could use ThreadUtils.dumpMyThreads() here



geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/AcceptorImplDUnitTest.java
 (line 128)


Is this a sufficient check to determine that the problem has been fixed?  
isRunning() looks at the variable "shutdown", which is set to true at the top 
of the close() method.  I think this code needs to check & ensure that both of 
the AcceptorImpl thread pools have been shut down.



geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/AcceptorImplDUnitTest.java
 (line 160)


If the test fails this code won't be executed.  Move it to an @After


- Bruce Schuchardt


On Jan. 24, 2017, 11:31 p.m., Galen O'Sullivan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55742/
> ---
> 
> (Updated Jan. 24, 2017, 11:31 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Hitesh Khamesra, and Udo 
> Kohlmeyer.
> 
> 
> Bugs: GEODE-2324
> https://issues.apache.org/jira/browse/GEODE-2324
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> [GEODE-2324] fix AcceptorImpl cleanup.
> 
> * Catch InterruptedException so cleanup continues.
> * Remove top-level exception handler to avoid similar mistakes in the future.
> * Fix a synchronization bug that could cause AcceptorImpl to try to shut down 
> twice.
> * Fix what looks like a bug where if closing the socket throws and 
> IOException, we fail to shut anything else down, though we still have 
> ourselves marked as shut down.
> 
> I'm a little skeptical of whether we're waiting at all for the queue to shut 
> down, as the thread could have been marked as interrupted for quite a while 
> before and never noticed it until the thread got parked. This may warrant 
> more investigation.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/AcceptorImpl.java
>  060683de6 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/AcceptorImplObserver.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/AcceptorImplDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/AcceptorImplJUnitTest.java
>  7aa11b7ca 
> 
> Diff: https://reviews.apache.org/r/55742/diff/
> 
> 
> Testing
> ---
> 
> precheckin passed on (3), will run on (5).
> 
> 
> Thanks,
> 
> Galen O'Sullivan
> 
>

[jira] [Commented] (GEODE-2351) Update cpp quickstarts

[ASF GitHub Bot (JIRA)]

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

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

GitHub user mmartell opened a pull request:

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

GEODE-2351: Update the cpp quickstarts to use geode instead of gemfire



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

$ git pull https://github.com/mmartell/geode feature/GEODE-2357

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

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






> Update cpp quickstarts
> --
>
> Key: GEODE-2351
> URL: https://issues.apache.org/jira/browse/GEODE-2351
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Ernest Burghardt
>
> Transform Gemfire => Geode as appropriate



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

[GitHub] geode pull request #357: GEODE-2351: Update the cpp quickstarts to use geode...

[mmartell]

GitHub user mmartell opened a pull request:

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

GEODE-2351: Update the cpp quickstarts to use geode instead of gemfire



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

$ git pull https://github.com/mmartell/geode feature/GEODE-2357

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

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






---
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-2230) LuceneIndex.waitUntilFlushed should not have to wait for the queue to be completely empty

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2230:


Commit 44cd72d8502d278a9a328a2b0a825c2460f8a383 in geode's branch 
refs/heads/develop from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=44cd72d ]

GEODE-2230: Added AsyncEventQueue and GatewaySender waitUntilFlushed API


> LuceneIndex.waitUntilFlushed should not have to wait for the queue to be 
> completely empty
> -
>
> Key: GEODE-2230
> URL: https://issues.apache.org/jira/browse/GEODE-2230
> Project: Geode
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Dan Smith
>
> We added a function to LuceneIndex to wait until updates are flushed to the 
> index with GEODE-1351.
> Unfortunately, the current approach has a few problems. It just waits in a 
> loop polling the size of the queue until it reaches zero. If someone uses 
> this method while the system is constantly receiving updates, the queue may 
> never reach zero.
> It would be better if this method could wait until any data at the time the 
> method was called was completely flushed.
> One way to accomplish this might be to send a function or message to all of 
> the members holding the async event queue for the lucene index. The function 
> could capture the current tail of the queue and wait until that event is 
> dispatched.



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

Re: Review Request 55890: GEODE-2354: set global session timeout to MAX_VALUE

[Kevin Duling]

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


Ship it!




Ship It!

- Kevin Duling


On Jan. 24, 2017, 12:55 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55890/
> ---
> 
> (Updated Jan. 24, 2017, 12:55 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, and 
> Swapnil Bawaskar.
> 
> 
> Bugs: GEODE-2354
> https://issues.apache.org/jira/browse/GEODE-2354
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Use of security-manager results in 
> org.apache.shiro.session.UnknownSessionExceptions being thrown from protected 
> operations after 30 minutes idle (the default global session timeout in 
> Apache Shiro).
> 
> GFSH connects to the JMX Manager but this connection has no timeout even if 
> the cluster is secured. So after 30 minutes of being idle, GFSH will remain 
> connected to the JMX Manager but all commands that are protected will result 
> in an UnknownSessionException.
> 
> The changes in the change set simply set the global session timeout to 
> MAX_VALUE if the user has specified a security-manager. If the user specifies 
> security-shiro-init (for a custom shiro.ini) then we leave the global session 
> configuration to the user's shiro.ini.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  73d051f 
> 
> Diff: https://reviews.apache.org/r/55890/diff/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

[jira] [Updated] (GEODE-2358) Fix Quickstart run scripts for Geode

[Michael Martell (JIRA)]

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

Michael Martell updated GEODE-2358:
---
Priority: Minor  (was: Major)

> Fix Quickstart run scripts for Geode
> 
>
> Key: GEODE-2358
> URL: https://issues.apache.org/jira/browse/GEODE-2358
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Martell
>Priority: Minor
>
> Parent task



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

Re: build problem in new module

[Jens Deppe]

Bruce, the message is just informational as this is the first time the
upload is happening for this module. It was successful:

https://repository.apache.org/content/repositories/snapshots/org/apache/geode/geode-old-versions/

--Jens

On Wed, Jan 25, 2017 at 8:22 AM, Bruce Schuchardt 
wrote:

> I need help in fixing this build problem in Jenkins:
>
>:geode-old-versions:uploadArchivesCould not find metadata
> org.apache.geode:geode-old-versions:1.1.0-SNAPSHOT/maven-metadata.xml in
> remote (https://repository.apache.org/content/repositories/snapshots)
>Could not find metadata 
> org.apache.geode:geode-old-versions/maven-metadata.xml
> in remote (https://repository.apache.org/content/repositories/snapshots)
>
> The geode-old-versions module is new.  It's just for testing and has no
> actual sources.  Its purpose is to create the dependencies needed to run
> tests with old versions of Geode.
>
>

[jira] [Created] (GEODE-2362) CLONE - Update cpp quickstarts

[Michael Martell (JIRA)]

Michael Martell created GEODE-2362:
--

 Summary: CLONE - Update cpp quickstarts
 Key: GEODE-2362
 URL: https://issues.apache.org/jira/browse/GEODE-2362
 Project: Geode
  Issue Type: Sub-task
  Components: native client
Reporter: Michael Martell


Transform Gemfire => Geode as appropriate



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

[jira] [Created] (GEODE-2363) CLONE - Update cli quickstarts

[Michael Martell (JIRA)]

Michael Martell created GEODE-2363:
--

 Summary: CLONE - Update cli quickstarts
 Key: GEODE-2363
 URL: https://issues.apache.org/jira/browse/GEODE-2363
 Project: Geode
  Issue Type: Sub-task
  Components: native client
Reporter: Michael Martell


Transform Gemfire => Geode as appropriate



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

[jira] [Created] (GEODE-2359) CLONE - Update GemfireCppCache

[Michael Martell (JIRA)]

Michael Martell created GEODE-2359:
--

 Summary: CLONE - Update GemfireCppCache
 Key: GEODE-2359
 URL: https://issues.apache.org/jira/browse/GEODE-2359
 Project: Geode
  Issue Type: Sub-task
  Components: native client
Reporter: Michael Martell
 Fix For: 1.1.0


the following files are called Gemfire* let's make them Geode*

src//cppcache/include/gfcpp/GemfireCppCache.hpp
src//cppcache/include/gfcpp/GemfireCppCache.inl

Also, update inclusions usage and named components as appropriate.



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

[jira] [Created] (GEODE-2361) CLONE - Update GemfireStatisticsFactory

[Michael Martell (JIRA)]

Michael Martell created GEODE-2361:
--

 Summary: CLONE - Update  GemfireStatisticsFactory
 Key: GEODE-2361
 URL: https://issues.apache.org/jira/browse/GEODE-2361
 Project: Geode
  Issue Type: Sub-task
  Components: native client
Reporter: Michael Martell



Gem fire => Geode transformation
the following files are called Gemfire* let's make them Geode*
src//cppcache/src/statistics/GemfireStatisticsFactory.cpp
src//cppcache/src/statistics/GemfireStatisticsFactory.hpp
Also, update inclusions usage and named components as appropriate.



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

[jira] [Created] (GEODE-2360) CLONE - Update GemfireTypeIds

[Michael Martell (JIRA)]

Michael Martell created GEODE-2360:
--

 Summary: CLONE - Update GemfireTypeIds
 Key: GEODE-2360
 URL: https://issues.apache.org/jira/browse/GEODE-2360
 Project: Geode
  Issue Type: Sub-task
  Components: native client
Reporter: Michael Martell
 Fix For: 1.1.0


Gem fire => Geode transformation
the following files are called Gemfire* let's make them Geode*


src//cppcache/include/gfcpp/GemfireTypeIds.hpp
src//cppcache/src/GemfireTypeIdsImpl.hpp

Also, update inclusions usage and named components as appropriate.



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

build problem in new module

[Bruce Schuchardt]

I need help in fixing this build problem in Jenkins:

   :geode-old-versions:uploadArchivesCould not find metadata 
org.apache.geode:geode-old-versions:1.1.0-SNAPSHOT/maven-metadata.xml in remote 
(https://repository.apache.org/content/repositories/snapshots)
   Could not find metadata 
org.apache.geode:geode-old-versions/maven-metadata.xml in remote 
(https://repository.apache.org/content/repositories/snapshots)

The geode-old-versions module is new.  It's just for testing and has no 
actual sources.  Its purpose is to create the dependencies needed to run 
tests with old versions of Geode.

Build failed in Jenkins: Geode-nightly #727

[Apache Jenkins Server]

See 

Changes:

[ukohlmeyer] [GEODE-1407] Change a FlakyTest to distributedTest.

[ukohlmeyer] [GEODE-1407] Use lambdas instead of Serializable/Callable

[ukohlmeyer] [GEODE-1923] Fix a test race condition.

[ukohlmeyer] [GEODE-1923] Remove FlakyTest and apply Spotless.

[ukohlmeyer] Change several RMI calls from closures to static methods.

[ukohlmeyer] This closes #305

[ukohlmeyer] [GEODE-2191] Test randomized string serialization/deserialization.

[ukohlmeyer] [GEM-2191] Fixes for code review.

[ukohlmeyer] [GEODE-2191] Fix long string serialization test. This closes #306

[bschuchardt] GEODE-2137 client membership IDs contain 17 bytes of useless 
information

[bschuchardt] GEODE-1965 Create backward-compatibility unit test framework

[klund] GEODE-2313: Fix PulseDataExportTest

[bschuchardt] Adding JIRA ticket numbers for disabled tests

--
[...truncated 560 lines...]
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.access$000(ClearTXLockingDUnitTest.java:67)

Caused by:
java.lang.NullPointerException
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.lambda$releaseRegionOperation$b6506259$1(ClearTXLockingDUnitTest.java:324)

6781 tests completed, 1 failed, 599 skipped
:geode-core:distributedTest FAILED
:geode-core:flakyTest
:geode-core:integrationTest
:geode-cq:assemble
:geode-cq:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources UP-TO-DATE
:geode-json:testClasses UP-TO-DATE
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json:flakyTest UP-TO-DATE
:geode-json:integrationTest UP-TO-DATE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJava
:geode-junit:processTestResources UP-TO-DATE
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:flakyTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJavaNote: Some input files use or override a 
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
:geode-old-client-support:processTestResources UP-TO-DATE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:flakyTest
:geode-old-client-support:integrationTest
:geode-old-versions:javadoc UP-TO-DATE
:geode-old-versions:javadocJar
:geode-old-versions:sourcesJar
:geode-old-versions:signArchives SKIPPED
:geode-old-versions:assemble
:geode-old-versions:compileTestJava UP-TO-DATE
:geode-old-versions:processTestResources UP-TO-DATE
:geode-old-versions:testClasses UP-TO-DATE
:geode-old-versions:checkMissedTests UP-TO-DATE
:geode-old-versions:spotlessJavaCheck
:geode-old-versions:spotlessCheck
:geode-old-versions:test UP-TO-DATE
:geode-old-versions:check
:geode-old-versions:build
:geode-old-versions:distributedTest UP-TO-DATE
:geode-old-versions:flakyTest UP-TO-DATE
:geode-old-versions:integrationTest UP-TO-DATE
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: 

[jira] [Created] (GEODE-2357) Update cli quickstarts

[Michael Martell (JIRA)]

Michael Martell created GEODE-2357:
--

 Summary: Update cli quickstarts
 Key: GEODE-2357
 URL: https://issues.apache.org/jira/browse/GEODE-2357
 Project: Geode
  Issue Type: Sub-task
  Components: native client
Reporter: Michael Martell


Transform Gemfire => Geode as appropriate



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