[jira] [Assigned] (GEODE-2690) Use a different thread pool for flush operations

[nabarun (JIRA)]

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

nabarun reassigned GEODE-2690:
--

Assignee: nabarun

> Use a different thread pool for flush operations
> 
>
> Key: GEODE-2690
> URL: https://issues.apache.org/jira/browse/GEODE-2690
> Project: Geode
>  Issue Type: Bug
>Reporter: nabarun
>Assignee: nabarun
>
> WaitUntilParallelGatewaySenderFlushedCoordinator's waitUntilFlushed should 
> use a thread pool with a limited number of thread so that the system doesn't 
> create an exceptionally high number of threads while flushing buckets.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native issue #73: GEODE-2513 Unbrand C++ API docs: Getting Started sec...

[davebarnes97]

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode-native/pull/73
  
Round 2 incorporates suggestions from reviewers.
Per PivotalSarge, more consistency in the uses of "Client" and "Geode 
Client".
Per echobravopapa, a lot less system-specific hand-holding. Entire sections 
about running on Linux, Solaris, and Windows have been deleted.


---
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: New Committer And PMC Member: Ernest Burghardt

[Nabarun Nag]

Congrats and welcome !!! :)

On Fri, Mar 24, 2017 at 3:41 PM Bruce Schuchardt 
wrote:

> Welcome to the group Ernie!
>
> Le 3/24/2017 à 3:03 PM, Anthony Baker a écrit :
> > The Apache Geode Project Management Committee has invited Ernest
> > Burghardt to be committer on the project and join the Geode PMC. We
> > are pleased to announce he has accepted.
> >
> > Please join me in welcoming Ernie!
> >
> > Thanks,
> >
> > Anthony
> > On behalf of the Apache Geode PMC
>
>

Re: region with total-max-memory

[Darrel Schneider]

For heap lru you want to set eviction-heap-percentage which you can do when
you start the server. You should also set the initial and max heap sizes.
Read about this here:
https://geode.apache.org/docs/guide/11/managing/heap_use/heap_management.html#configuring_resource_manager_controlling_heap_use

As for "total-max-memory", I just looked over the source code and could not
find any code that does anything interesting with it. All I found was a
bunch of code that validates it but never uses it for anything. I'm going
to file a ticket that this region attribute should be removed.
Hope this helps!

On Fri, Mar 24, 2017 at 5:03 AM, Srikrishan Malik 
wrote:

> While creating a region in geode you can specify --total-max-memory
> which should limit the amount of memory used the the region entries.
> ref: https://geode.apache.org/docs/guide/tools_modules/gfsh/
> command-pages/create.html#topic_54B0985FEC5241CA9D26B0CE0A5EA863
>
> I created a region of type PARTITION_OVERFLOW with total-max-memory
> set, I can see that this attribute is there in the the partition
> attributes for the region on server, but when the amount of data
> crossed the total-max-memory limit it did not start overflowing old
> entries to disk, after some time(memory usage is almost 10x greater
> than total-max-memory) the heap lru(which is based on total jvm head)
> kicks in and starts evicting entries.
>
> Is there any additional setting which has to be done to trigger
> eviction when total-max-memory limit is reached for a region.
>
> -Sri
>

[jira] [Created] (GEODE-2719) The total-max-memory region attribute does not appear to do anything

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2719:
---

 Summary: The total-max-memory region attribute does not appear to 
do anything
 Key: GEODE-2719
 URL: https://issues.apache.org/jira/browse/GEODE-2719
 Project: Geode
  Issue Type: Improvement
  Components: regions
Reporter: Darrel Schneider


I could not find that the "total-max-memory" region partitioned attribute does 
anything. If this is correct then it should be deprecated and removed in a 
future release. A user read the geode docs and expected it cause LRU eviction 
since this docs say this about it:
{quote}
Maximum combined megabytes of memory to be used by all processes hosting this 
region for all copies, primary and redundant.
{quote}




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2472) Oplog.flush method doesn't verify that the entry gets written

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2472:


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

GEODE-2472 changes are made to ensure byte array is completely flushed to oplog 
channel.

The Oplog and OverflowOplog flush(OplogFile olf, ByteBuffer b1, ByteBuffer b2) 
method doesn't check the results of the channel.write() call.

It could so happen partial byte array is written to the channel. The check is 
added to make sure the bytes are completely written to the file channel.


> Oplog.flush method doesn't verify that the entry gets written
> -
>
> Key: GEODE-2472
> URL: https://issues.apache.org/jira/browse/GEODE-2472
> Project: Geode
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Kenneth Howe
>Assignee: Anilkumar Gingade
>
> The Oplog.flush(OplogFile olf, ByteBuffer b1, ByteBuffer b2) method doesn't 
> check the results of the channel.write() call. The other Oplog.flush() method 
> that performs a channel write wraps the write() call in the loop
> {code}
> do {
> ...
> } while (hasRemaining);
> {code}
> to make sure the Oplog entry is written to the OplogFile.
> This method is implemented without the check loop, making the assumption that 
> the write() completely writes everything from both buffers. Defensive 
> programming would suggest that the results of lower level calls are checked.
> Failure to recognize a partial write to the OplogFile can result in a corrupt 
> oplog that isn't found until the persistent disk store is recovered.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #503 was successful.
---
Scheduled
1682 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

[jira] [Created] (GEODE-2718) inconsistent reads during network partition

[Swapnil Bawaskar (JIRA)]

Swapnil Bawaskar created GEODE-2718:
---

 Summary: inconsistent reads during network partition
 Key: GEODE-2718
 URL: https://issues.apache.org/jira/browse/GEODE-2718
 Project: Geode
  Issue Type: Bug
  Components: membership, regions
Reporter: Swapnil Bawaskar


non-persistent partitioned regions exhibit the following behavior:
 In the event of a network partition where all copies of a bucket end up on the 
losing side, a get() operation returns a null. A null can signify that the key 
did not exist, so we should be more explicit about the network partition and 
throw an error like PartitionOfflineException (which is thrown if the region 
was persistent).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: New Committer And PMC Member: Ernest Burghardt

[Bruce Schuchardt]

Welcome to the group Ernie!

Le 3/24/2017 à 3:03 PM, Anthony Baker a écrit :

The Apache Geode Project Management Committee has invited Ernest
Burghardt to be committer on the project and join the Geode PMC. We
are pleased to announce he has accepted.

Please join me in welcoming Ernie!

Thanks,

Anthony
On behalf of the Apache Geode PMC

Re: GEODE-2714 Proposal for new api on Function interface (Please read)

[Jacob Barrett]

Hey guys, take the conversation over to the ticket so context is maintained
with the ticket.

On Fri, Mar 24, 2017 at 3:16 PM Swapnil Bawaskar 
wrote:

> For step 2 above, won't we end up recomputing the list of buckets?
>
> I agree, however,  that we do have the problem of moving primary,
> especially in the middle of iterating over data. We already have an
> optimizeForWrite() method on Function that makes the function execute on
> the primary. Do we want to make locking part of this method, rather than
> introducing a new method?
>
> On Fri, Mar 24, 2017 at 2:10 PM Hitesh Khamesra 
> wrote:
>
> > Hi Swapnil:
> >
> > Right, and then we execute that function on that node. Now assume during
> > that function execution time(first user thread) two things happens
> > simultaneously..
> >
> > 1. we move that bucket to other node.
> > 2. And other user thread execute function with same set of keys on other
> > node, which first  thread is still executing.
> >
> > Basically we need to make sure while function execution we don't move the
> > primary bucket.
> >
> > Thanks.
> > Hitesh
> > --
> > *From:* Swapnil Bawaskar 
> > *To:* dev@geode.apache.org; Hitesh Khamesra 
> > *Sent:* Friday, March 24, 2017 1:55 PM
> > *Subject:* Re: GEODE-2714 Proposal for new api on Function interface
> > (Please read)
> >
> > Here is the link: https://issues.apache.org/jira/browse/GEODE-2714
> >
> > Hi Hitesh,
> >
> > Before executing a function, we build a list of buckets that the function
> > needs to execute on and then we build the function context using only
> those
> > buckets. So, as long as the function is using the context to get the
> local
> > data set, it should not see the data twice, even if rebalance was in
> > progress.
> >
> > When you saw this behavior, was the function using the function context?
> >
> > Thanks!
> >
> >
> > On Fri, Mar 24, 2017 at 1:21 PM Jared Stewart 
> wrote:
> >
> > Can you give a link to the proposal?
> >
> > Thanks,
> > Jared
> > > On Mar 24, 2017, at 12:57 PM, Hitesh Khamesra
> >  wrote:
> > >
> > > Please let us know your opinion on that.
> > > Thanks.Hitesh
> >
> >
> >
> >
>

Re: GEODE-2714 Proposal for new api on Function interface (Please read)

[Swapnil Bawaskar]

For step 2 above, won't we end up recomputing the list of buckets?

I agree, however,  that we do have the problem of moving primary,
especially in the middle of iterating over data. We already have an
optimizeForWrite() method on Function that makes the function execute on
the primary. Do we want to make locking part of this method, rather than
introducing a new method?

On Fri, Mar 24, 2017 at 2:10 PM Hitesh Khamesra  wrote:

> Hi Swapnil:
>
> Right, and then we execute that function on that node. Now assume during
> that function execution time(first user thread) two things happens
> simultaneously..
>
> 1. we move that bucket to other node.
> 2. And other user thread execute function with same set of keys on other
> node, which first  thread is still executing.
>
> Basically we need to make sure while function execution we don't move the
> primary bucket.
>
> Thanks.
> Hitesh
> --
> *From:* Swapnil Bawaskar 
> *To:* dev@geode.apache.org; Hitesh Khamesra 
> *Sent:* Friday, March 24, 2017 1:55 PM
> *Subject:* Re: GEODE-2714 Proposal for new api on Function interface
> (Please read)
>
> Here is the link: https://issues.apache.org/jira/browse/GEODE-2714
>
> Hi Hitesh,
>
> Before executing a function, we build a list of buckets that the function
> needs to execute on and then we build the function context using only those
> buckets. So, as long as the function is using the context to get the local
> data set, it should not see the data twice, even if rebalance was in
> progress.
>
> When you saw this behavior, was the function using the function context?
>
> Thanks!
>
>
> On Fri, Mar 24, 2017 at 1:21 PM Jared Stewart  wrote:
>
> Can you give a link to the proposal?
>
> Thanks,
> Jared
> > On Mar 24, 2017, at 12:57 PM, Hitesh Khamesra
>  wrote:
> >
> > Please let us know your opinion on that.
> > Thanks.Hitesh
>
>
>
>

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[ASF GitHub Bot (JIRA)]

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

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

GitHub user karensmolermiller opened a pull request:

https://github.com/apache/geode-native/pull/75

GEODE-2513 Unbrand .NET API docs section

- Remove references to GemFire
- Namespace updates
- Correct typos and capitalization
- Use .NET scoping operator (not C++)
- Avoid duplication in the manual of QuickStart code

@davebarnes97 @joeymcallister @PivotalSarge @echobravopapa @dgkimura 
@mmartell 
Please give this PR a careful review.  The namespace change for .NET 
clients was tricky, and I'm not sure if the 'Generic' exists for Geode.  There 
were also a few places in the docs that used the C++ scoping operator (::) 
instead of a period; I think that those were typos in the original 
documentation.

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

$ git pull https://github.com/karensmolermiller/geode-native 
feature/GEODE-2513-14

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

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


commit 0f8f9913a8251f5bba60acf22624d9d5b513689a
Author: Karen Miller 
Date:   2017-03-24T21:20:13Z

GEODE-2513 Unbrand .NET API docs section

- Remove references to GemFire
- Namespace updates
- Correct typos and capitalization
- Use .NET scoping operator (not C++)
- Avoid duplication in the manual of QuickStart code




> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #75: GEODE-2513 Unbrand .NET API docs section

[karensmolermiller]

GitHub user karensmolermiller opened a pull request:

https://github.com/apache/geode-native/pull/75

GEODE-2513 Unbrand .NET API docs section

- Remove references to GemFire
- Namespace updates
- Correct typos and capitalization
- Use .NET scoping operator (not C++)
- Avoid duplication in the manual of QuickStart code

@davebarnes97 @joeymcallister @PivotalSarge @echobravopapa @dgkimura 
@mmartell 
Please give this PR a careful review.  The namespace change for .NET 
clients was tricky, and I'm not sure if the 'Generic' exists for Geode.  There 
were also a few places in the docs that used the C++ scoping operator (::) 
instead of a period; I think that those were typos in the original 
documentation.

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

$ git pull https://github.com/karensmolermiller/geode-native 
feature/GEODE-2513-14

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

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


commit 0f8f9913a8251f5bba60acf22624d9d5b513689a
Author: Karen Miller 
Date:   2017-03-24T21:20:13Z

GEODE-2513 Unbrand .NET API docs section

- Remove references to GemFire
- Namespace updates
- Correct typos and capitalization
- Use .NET scoping operator (not C++)
- Avoid duplication in the manual of QuickStart code




---
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: New Committer And PMC Member: Ernest Burghardt

[Joey McAllister]

Woot! Congrats, Ernie!

On Fri, Mar 24, 2017 at 3:03 PM Anthony Baker  wrote:

> The Apache Geode Project Management Committee has invited Ernest
> Burghardt to be committer on the project and join the Geode PMC. We
> are pleased to announce he has accepted.
>
> Please join me in welcoming Ernie!
>
> Thanks,
>
> Anthony
> On behalf of the Apache Geode PMC
>

New Committer And PMC Member: Ernest Burghardt

[Anthony Baker]

The Apache Geode Project Management Committee has invited Ernest
Burghardt to be committer on the project and join the Geode PMC. We
are pleased to announce he has accepted.

Please join me in welcoming Ernie!

Thanks,

Anthony
On behalf of the Apache Geode PMC

[jira] [Commented] (GEODE-2713) Function execution can lead to passing the address of a stack variable

[ASF GitHub Bot (JIRA)]

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

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

Github user pivotal-jbarrett commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/74#discussion_r108006315
  
--- Diff: src/cppcache/src/ThinClientRegion.cpp ---
@@ -3350,7 +3350,8 @@ bool ThinClientRegion::executeFunctionSH(
 HashMapT* locationMap,
 CacheableHashSetPtr& failedNodes, uint32_t timeout, bool allBuckets) {
   bool reExecute = false;
-  ACE_Recursive_Thread_Mutex resultCollectorLock;
+  std::shared_ptr resultCollectorLock(
+  new ACE_Recursive_Thread_Mutex());
--- End diff --

See comment above about `std::make_shared`.


> Function execution can lead to passing the address of a stack variable
> --
>
> Key: GEODE-2713
> URL: https://issues.apache.org/jira/browse/GEODE-2713
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>
> In ThinClientRegion::executeFunctionSH(), the address of a stack variable 
> (the result collector lock) is passed to the workers. If an exception occurs 
> with any of the workers, the function will return, causing the stack variable 
> to be destructed. Since the workers have the raw address, it is now a 
> dangling pointer situation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2713) Function execution can lead to passing the address of a stack variable

[ASF GitHub Bot (JIRA)]

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

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

Github user pivotal-jbarrett commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/74#discussion_r108006001
  
--- Diff: src/cppcache/src/ThinClientPoolDM.cpp ---
@@ -609,7 +609,8 @@ GfErrType ThinClientPoolDM::sendRequestToAllServers(
   HostAsm::atomicAdd(m_clientOps, 1);
   getStats().setCurClientOps(m_clientOps);
 
-  ACE_Recursive_Thread_Mutex resultCollectorLock;
+  std::shared_ptr resultCollectorLock(
+  new ACE_Recursive_Thread_Mutex());
--- End diff --

The proper way to allocate a new object into a shared pointer:
```
auto resultCollectorLock = std::make_shared();
```

This results in a single allocations (combined control block and object) 
rather than two (control block and object).



> Function execution can lead to passing the address of a stack variable
> --
>
> Key: GEODE-2713
> URL: https://issues.apache.org/jira/browse/GEODE-2713
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>
> In ThinClientRegion::executeFunctionSH(), the address of a stack variable 
> (the result collector lock) is passed to the workers. If an exception occurs 
> with any of the workers, the function will return, causing the stack variable 
> to be destructed. Since the workers have the raw address, it is now a 
> dangling pointer situation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2713) Function execution can lead to passing the address of a stack variable

[ASF GitHub Bot (JIRA)]

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

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

Github user pivotal-jbarrett commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/74#discussion_r108006539
  
--- Diff: src/cppcache/src/ThinClientRegion.hpp ---
@@ -407,17 +407,21 @@ class ChunkedFunctionExecutionResponse : public 
TcrChunkedResult {
   // CacheableVectorPtr  m_functionExecutionResults;
   bool m_getResult;
   ResultCollectorPtr m_rc;
-  ACE_Recursive_Thread_Mutex* m_resultCollectorLock;
+  std::shared_ptr m_resultCollectorLock;
 
   // disabled
   ChunkedFunctionExecutionResponse(const 
ChunkedFunctionExecutionResponse&);
   ChunkedFunctionExecutionResponse& operator=(
   const ChunkedFunctionExecutionResponse&);
 
  public:
+  inline ChunkedFunctionExecutionResponse(TcrMessage& msg, bool getResult,
+  ResultCollectorPtr rc)
+  : TcrChunkedResult(), m_msg(msg), m_getResult(getResult), m_rc(rc) {}
+
   inline ChunkedFunctionExecutionResponse(
   TcrMessage& msg, bool getResult, ResultCollectorPtr rc,
-  ACE_Recursive_Thread_Mutex* resultCollectorLock = NULL)
+  std::shared_ptr resultCollectorLock)
--- End diff --

Same comment about `const &`.


> Function execution can lead to passing the address of a stack variable
> --
>
> Key: GEODE-2713
> URL: https://issues.apache.org/jira/browse/GEODE-2713
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>
> In ThinClientRegion::executeFunctionSH(), the address of a stack variable 
> (the result collector lock) is passed to the workers. If an exception occurs 
> with any of the workers, the function will return, causing the stack variable 
> to be destructed. Since the workers have the raw address, it is now a 
> dangling pointer situation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2713) Function execution can lead to passing the address of a stack variable

[ASF GitHub Bot (JIRA)]

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

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

Github user pivotal-jbarrett commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/74#discussion_r108006260
  
--- Diff: src/cppcache/src/ThinClientPoolDM.hpp ---
@@ -625,7 +626,7 @@ class OnRegionFunctionExecution : public 
PooledWork {
   OnRegionFunctionExecution(
   const char* func, const Region* region, CacheablePtr args,
   CacheableHashSetPtr routingObj, uint8_t getResult, uint32_t timeout,
-  ThinClientPoolDM* poolDM, ACE_Recursive_Thread_Mutex* rCL,
+  ThinClientPoolDM* poolDM, 
std::shared_ptr rCL,
--- End diff --

See comment about about passing as `const &`.


> Function execution can lead to passing the address of a stack variable
> --
>
> Key: GEODE-2713
> URL: https://issues.apache.org/jira/browse/GEODE-2713
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>
> In ThinClientRegion::executeFunctionSH(), the address of a stack variable 
> (the result collector lock) is passed to the workers. If an exception occurs 
> with any of the workers, the function will return, causing the stack variable 
> to be destructed. Since the workers have the raw address, it is now a 
> dangling pointer situation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2713) Function execution can lead to passing the address of a stack variable

[ASF GitHub Bot (JIRA)]

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

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

Github user pivotal-jbarrett commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/74#discussion_r108006150
  
--- Diff: src/cppcache/src/ThinClientPoolDM.hpp ---
@@ -463,7 +463,8 @@ class FunctionExecution : public PooledWork {
 
   void setParameters(const char* func, uint8_t getResult, uint32_t timeout,
  CacheablePtr args, TcrEndpoint* ep,
- ThinClientPoolDM* poolDM, ACE_Recursive_Thread_Mutex* 
rCL,
+ ThinClientPoolDM* poolDM,
+ std::shared_ptr rCL,
--- End diff --

Why not `const std::shared_ptr& rCL`?


> Function execution can lead to passing the address of a stack variable
> --
>
> Key: GEODE-2713
> URL: https://issues.apache.org/jira/browse/GEODE-2713
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>
> In ThinClientRegion::executeFunctionSH(), the address of a stack variable 
> (the result collector lock) is passed to the workers. If an exception occurs 
> with any of the workers, the function will return, causing the stack variable 
> to be destructed. Since the workers have the raw address, it is now a 
> dangling pointer situation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #74: GEODE-2713: Wrap result collector lock in sha...

[pivotal-jbarrett]

Github user pivotal-jbarrett commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/74#discussion_r108006315
  
--- Diff: src/cppcache/src/ThinClientRegion.cpp ---
@@ -3350,7 +3350,8 @@ bool ThinClientRegion::executeFunctionSH(
 HashMapT* locationMap,
 CacheableHashSetPtr& failedNodes, uint32_t timeout, bool allBuckets) {
   bool reExecute = false;
-  ACE_Recursive_Thread_Mutex resultCollectorLock;
+  std::shared_ptr resultCollectorLock(
+  new ACE_Recursive_Thread_Mutex());
--- End diff --

See comment above about `std::make_shared`.


---
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-native pull request #74: GEODE-2713: Wrap result collector lock in sha...

[pivotal-jbarrett]

Github user pivotal-jbarrett commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/74#discussion_r108006539
  
--- Diff: src/cppcache/src/ThinClientRegion.hpp ---
@@ -407,17 +407,21 @@ class ChunkedFunctionExecutionResponse : public 
TcrChunkedResult {
   // CacheableVectorPtr  m_functionExecutionResults;
   bool m_getResult;
   ResultCollectorPtr m_rc;
-  ACE_Recursive_Thread_Mutex* m_resultCollectorLock;
+  std::shared_ptr m_resultCollectorLock;
 
   // disabled
   ChunkedFunctionExecutionResponse(const 
ChunkedFunctionExecutionResponse&);
   ChunkedFunctionExecutionResponse& operator=(
   const ChunkedFunctionExecutionResponse&);
 
  public:
+  inline ChunkedFunctionExecutionResponse(TcrMessage& msg, bool getResult,
+  ResultCollectorPtr rc)
+  : TcrChunkedResult(), m_msg(msg), m_getResult(getResult), m_rc(rc) {}
+
   inline ChunkedFunctionExecutionResponse(
   TcrMessage& msg, bool getResult, ResultCollectorPtr rc,
-  ACE_Recursive_Thread_Mutex* resultCollectorLock = NULL)
+  std::shared_ptr resultCollectorLock)
--- End diff --

Same comment about `const &`.


---
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-native pull request #74: GEODE-2713: Wrap result collector lock in sha...

[pivotal-jbarrett]

Github user pivotal-jbarrett commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/74#discussion_r108006150
  
--- Diff: src/cppcache/src/ThinClientPoolDM.hpp ---
@@ -463,7 +463,8 @@ class FunctionExecution : public PooledWork {
 
   void setParameters(const char* func, uint8_t getResult, uint32_t timeout,
  CacheablePtr args, TcrEndpoint* ep,
- ThinClientPoolDM* poolDM, ACE_Recursive_Thread_Mutex* 
rCL,
+ ThinClientPoolDM* poolDM,
+ std::shared_ptr rCL,
--- End diff --

Why not `const std::shared_ptr& rCL`?


---
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-native pull request #74: GEODE-2713: Wrap result collector lock in sha...

[pivotal-jbarrett]

Github user pivotal-jbarrett commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/74#discussion_r108006001
  
--- Diff: src/cppcache/src/ThinClientPoolDM.cpp ---
@@ -609,7 +609,8 @@ GfErrType ThinClientPoolDM::sendRequestToAllServers(
   HostAsm::atomicAdd(m_clientOps, 1);
   getStats().setCurClientOps(m_clientOps);
 
-  ACE_Recursive_Thread_Mutex resultCollectorLock;
+  std::shared_ptr resultCollectorLock(
+  new ACE_Recursive_Thread_Mutex());
--- End diff --

The proper way to allocate a new object into a shared pointer:
```
auto resultCollectorLock = std::make_shared();
```

This results in a single allocations (combined control block and object) 
rather than two (control block and object).



---
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-2714) Proposal for new api on Function interface

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett commented on GEODE-2714:
-

How about an annotation rather than an interface change?

{noformat}
@AquirePrimaryBucketReadLock
class MyFunction  {
}
{noformat}

Whatever the name is, be explicit about what it does in the name.
Other options are more generic annotation 
{{@AquirePrimaryBucketLock(Read|Write))}}.



> Proposal for new api on Function interface
> --
>
> Key: GEODE-2714
> URL: https://issues.apache.org/jira/browse/GEODE-2714
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Hitesh Khamesra
>
> Function execution is the most useful feature of Geode. It allows you to 
> execute a user-defined function on the node which holds the primary bucket of 
> the partition region. In many cases application has colocated partition 
> regions and using function application can operate on all the colocated 
> primary buckets.
> In that function, the application makes sure that no other thread is 
> operating on same colocated keys. But during bucket rebalance there is a 
> possibility that two thread might be executing a function on the same set of 
> keys on different nodes.
> It can happen as we don't take the lock(read-lock) on a primary bucket while 
> executing the function. That allows Geode to move bucket for rebalancing.
> Proposal: Introduce the following api on Function interface to indicate the 
> need to primariness.
> boolean needPrimaryLock(); // name suggestion?
> The application would return true if they need a lock on the primary bucket. 
> Default would be false.
> Geode would call the interface and try to take readLock before executing the 
> function on that node. Otherwise, it will throw the exception and let app 
> re-execute that function.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2660) Mark Redis Adapter as Experimental

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Mark Redis Adapter as Experimental
> --
>
> Key: GEODE-2660
> URL: https://issues.apache.org/jira/browse/GEODE-2660
> Project: Geode
>  Issue Type: Bug
>Reporter: Galen O'Sullivan
>
> I put this up for a vote recently. The Redis adapter is really not ready for 
> prime time at this point. We should mark it experimental so people don't 
> mistakenly think it's ready, and so that we can change it more readily on 
> develop.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #426: GEODE-2660 Add @Experimental to the Redis adapter.

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #426: GEODE-2660 Add @Experimental to the Redis adapter.

[bschuchardt]

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/426
  
got it


---
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-2660) Mark Redis Adapter as Experimental

[ASF GitHub Bot (JIRA)]

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

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

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/426
  
got it


> Mark Redis Adapter as Experimental
> --
>
> Key: GEODE-2660
> URL: https://issues.apache.org/jira/browse/GEODE-2660
> Project: Geode
>  Issue Type: Bug
>Reporter: Galen O'Sullivan
>
> I put this up for a vote recently. The Redis adapter is really not ready for 
> prime time at this point. We should mark it experimental so people don't 
> mistakenly think it's ready, and so that we can change it more readily on 
> develop.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #426: GEODE-2660 Add @Experimental to the Redis adapter.

[galen-pivotal]

Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/426
  
@bschuchardt Check it out again; I force-pushed with just the annotation on 
GeodeRedisServer.


---
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-2660) Mark Redis Adapter as Experimental

[ASF GitHub Bot (JIRA)]

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

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

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/426
  
my bad - I checkout out ggreen's branch by mistake.  I don't see any 
@Experimental at all in your branch.  It looks like your second commit removed 
it from GeodeRedisServer.java when you meant to only remove it from the other 
classes.


> Mark Redis Adapter as Experimental
> --
>
> Key: GEODE-2660
> URL: https://issues.apache.org/jira/browse/GEODE-2660
> Project: Geode
>  Issue Type: Bug
>Reporter: Galen O'Sullivan
>
> I put this up for a vote recently. The Redis adapter is really not ready for 
> prime time at this point. We should mark it experimental so people don't 
> mistakenly think it's ready, and so that we can change it more readily on 
> develop.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #426: GEODE-2660 Add @Experimental to the Redis adapter.

[bschuchardt]

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/426
  
my bad - I checkout out ggreen's branch by mistake.  I don't see any 
@Experimental at all in your branch.  It looks like your second commit removed 
it from GeodeRedisServer.java when you meant to only remove it from the other 
classes.


---
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-2715) Move Pulse to its own repo

[Mark Bretl (JIRA)]

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

Mark Bretl commented on GEODE-2715:
---

This should be discussed on the dev list before any other actions take place

> Move Pulse to its own repo
> --
>
> Key: GEODE-2715
> URL: https://issues.apache.org/jira/browse/GEODE-2715
> Project: Geode
>  Issue Type: Improvement
>  Components: pulse
>Reporter: Swapnil Bawaskar
>
> Pulse should be moved to a separate repository so that it can be 
> independently released. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2717) export logs should honor the log level set on the server

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar resolved GEODE-2717.
-
Resolution: Duplicate

> export logs should honor the log level set on the server
> 
>
> Key: GEODE-2717
> URL: https://issues.apache.org/jira/browse/GEODE-2717
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Swapnil Bawaskar
>
> When no log level is specified, {{export logs}} gets only the info level 
> logs. This is confusing; export logs should get the entire log file from the 
> server when log level is not specified.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: GEODE-2714 Proposal for new api on Function interface (Please read)

[Hitesh Khamesra]

Hi Swapnil:
Right, and then we execute that function on that node. Now assume during that 
function execution time(first user thread) two things happens simultaneously..
1. we move that bucket to other node. 
2. And other user thread execute function with same set of keys on other node, 
which first  thread is still executing. 

Basically we need to make sure while function execution we don't move the 
primary bucket.
Thanks.Hitesh


  From: Swapnil Bawaskar 
 To: dev@geode.apache.org; Hitesh Khamesra  
 Sent: Friday, March 24, 2017 1:55 PM
 Subject: Re: GEODE-2714 Proposal for new api on Function interface (Please 
read)
   
Here is the link: https://issues.apache.org/jira/browse/GEODE-2714
Hi Hitesh,
Before executing a function, we build a list of buckets that the function needs 
to execute on and then we build the function context using only those buckets. 
So, as long as the function is using the context to get the local data set, it 
should not see the data twice, even if rebalance was in progress.
When you saw this behavior, was the function using the function context?
Thanks!

On Fri, Mar 24, 2017 at 1:21 PM Jared Stewart  wrote:

Can you give a link to the proposal?

Thanks,
Jared
> On Mar 24, 2017, at 12:57 PM, Hitesh Khamesra  
> wrote:
>
> Please let us know your opinion on that.
> Thanks.Hitesh




   

[jira] [Created] (GEODE-2717) export logs should honor the log level set on the server

[Swapnil Bawaskar (JIRA)]

Swapnil Bawaskar created GEODE-2717:
---

 Summary: export logs should honor the log level set on the server
 Key: GEODE-2717
 URL: https://issues.apache.org/jira/browse/GEODE-2717
 Project: Geode
  Issue Type: Sub-task
Reporter: Swapnil Bawaskar


When no log level is specified, {{export logs}} gets only the info level logs. 
This is confusing; export logs should get the entire log file from the server 
when log level is not specified.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2716) export logs should honor the log level set on the server

[Swapnil Bawaskar (JIRA)]

Swapnil Bawaskar created GEODE-2716:
---

 Summary: export logs should honor the log level set on the server
 Key: GEODE-2716
 URL: https://issues.apache.org/jira/browse/GEODE-2716
 Project: Geode
  Issue Type: Sub-task
Reporter: Swapnil Bawaskar


When no log level is specified, {{export logs}} gets only the info level logs. 
This is confusing; export logs should get the entire log file from the server 
when log level is not specified.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2660) Mark Redis Adapter as Experimental

[ASF GitHub Bot (JIRA)]

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

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

Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/426
  
@bschuchardt This is just the experimental annotation, not changes.


> Mark Redis Adapter as Experimental
> --
>
> Key: GEODE-2660
> URL: https://issues.apache.org/jira/browse/GEODE-2660
> Project: Geode
>  Issue Type: Bug
>Reporter: Galen O'Sullivan
>
> I put this up for a vote recently. The Redis adapter is really not ready for 
> prime time at this point. We should mark it experimental so people don't 
> mistakenly think it's ready, and so that we can change it more readily on 
> develop.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #426: GEODE-2660 Add @Experimental to the Redis adapter.

[galen-pivotal]

Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/426
  
@bschuchardt This is just the experimental annotation, not changes.


---
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] [Created] (GEODE-2715) Move Pulse to its own repo

[Swapnil Bawaskar (JIRA)]

Swapnil Bawaskar created GEODE-2715:
---

 Summary: Move Pulse to its own repo
 Key: GEODE-2715
 URL: https://issues.apache.org/jira/browse/GEODE-2715
 Project: Geode
  Issue Type: Improvement
  Components: pulse
Reporter: Swapnil Bawaskar


Pulse should be moved to a separate repository so that it can be independently 
released. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: GEODE-2714 Proposal for new api on Function interface (Please read)

[Swapnil Bawaskar]

Here is the link: https://issues.apache.org/jira/browse/GEODE-2714

Hi Hitesh,

Before executing a function, we build a list of buckets that the function
needs to execute on and then we build the function context using only those
buckets. So, as long as the function is using the context to get the local
data set, it should not see the data twice, even if rebalance was in
progress.

When you saw this behavior, was the function using the function context?

Thanks!


On Fri, Mar 24, 2017 at 1:21 PM Jared Stewart  wrote:

> Can you give a link to the proposal?
>
> Thanks,
> Jared
> > On Mar 24, 2017, at 12:57 PM, Hitesh Khamesra
>  wrote:
> >
> > Please let us know your opinion on that.
> > Thanks.Hitesh
>
>

[jira] [Commented] (GEODE-2713) Function execution can lead to passing the address of a stack variable

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/74#discussion_r107995174
  
--- Diff: src/cppcache/src/ThinClientRegion.hpp ---
@@ -416,14 +416,21 @@ class ChunkedFunctionExecutionResponse : public 
TcrChunkedResult {
 
  public:
   inline ChunkedFunctionExecutionResponse(
-  TcrMessage& msg, bool getResult, ResultCollectorPtr rc,
-  ACE_Recursive_Thread_Mutex* resultCollectorLock = NULL)
+  TcrMessage& msg, bool getResult, ResultCollectorPtr rc)
   : TcrChunkedResult(),
 m_msg(msg),
 m_getResult(getResult),
-m_rc(rc),
-m_resultCollectorLock(resultCollectorLock) {}
-
+m_rc(rc) {}
+
+inline ChunkedFunctionExecutionResponse(
+TcrMessage& msg, bool 
getResult, ResultCollectorPtr rc,
+
std::shared_ptr resultCollectorLock)
+: TcrChunkedResult(),
+m_msg(msg),
+m_getResult(getResult),
+m_rc(rc),
+m_resultCollectorLock(resultCollectorLock) {}
+
--- End diff --

fun fact: line 433 has dangling white space that the Github diff tool is 
choosing to ignore


> Function execution can lead to passing the address of a stack variable
> --
>
> Key: GEODE-2713
> URL: https://issues.apache.org/jira/browse/GEODE-2713
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>
> In ThinClientRegion::executeFunctionSH(), the address of a stack variable 
> (the result collector lock) is passed to the workers. If an exception occurs 
> with any of the workers, the function will return, causing the stack variable 
> to be destructed. Since the workers have the raw address, it is now a 
> dangling pointer situation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #74: GEODE-2713: Wrap result collector lock in sha...

[PivotalSarge]

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

https://github.com/apache/geode-native/pull/74#discussion_r107995262
  
--- Diff: src/cppcache/src/ThinClientRegion.hpp ---
@@ -416,14 +416,21 @@ class ChunkedFunctionExecutionResponse : public 
TcrChunkedResult {
 
  public:
   inline ChunkedFunctionExecutionResponse(
-  TcrMessage& msg, bool getResult, ResultCollectorPtr rc,
-  ACE_Recursive_Thread_Mutex* resultCollectorLock = NULL)
+  TcrMessage& msg, bool getResult, ResultCollectorPtr rc)
   : TcrChunkedResult(),
 m_msg(msg),
 m_getResult(getResult),
-m_rc(rc),
-m_resultCollectorLock(resultCollectorLock) {}
-
+m_rc(rc) {}
+
+inline ChunkedFunctionExecutionResponse(
--- End diff --

There are two constructors now because the previous solitary constructor 
had the last parameter defaulted to `NULL`. Now that it's a smart pointer, I 
split the constructor into two pieces, one with the lock and one without.


---
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-2713) Function execution can lead to passing the address of a stack variable

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/74#discussion_r107994818
  
--- Diff: src/cppcache/src/ThinClientRegion.hpp ---
@@ -416,14 +416,21 @@ class ChunkedFunctionExecutionResponse : public 
TcrChunkedResult {
 
  public:
   inline ChunkedFunctionExecutionResponse(
-  TcrMessage& msg, bool getResult, ResultCollectorPtr rc,
-  ACE_Recursive_Thread_Mutex* resultCollectorLock = NULL)
+  TcrMessage& msg, bool getResult, ResultCollectorPtr rc)
   : TcrChunkedResult(),
 m_msg(msg),
 m_getResult(getResult),
-m_rc(rc),
-m_resultCollectorLock(resultCollectorLock) {}
-
+m_rc(rc) {}
+
+inline ChunkedFunctionExecutionResponse(
--- End diff --

I was expecting to see the new version of ChunkedFunctionExecutionResponse 
used somewhere...


> Function execution can lead to passing the address of a stack variable
> --
>
> Key: GEODE-2713
> URL: https://issues.apache.org/jira/browse/GEODE-2713
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>
> In ThinClientRegion::executeFunctionSH(), the address of a stack variable 
> (the result collector lock) is passed to the workers. If an exception occurs 
> with any of the workers, the function will return, causing the stack variable 
> to be destructed. Since the workers have the raw address, it is now a 
> dangling pointer situation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #74: GEODE-2713: Wrap result collector lock in sha...

[echobravopapa]

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

https://github.com/apache/geode-native/pull/74#discussion_r107994818
  
--- Diff: src/cppcache/src/ThinClientRegion.hpp ---
@@ -416,14 +416,21 @@ class ChunkedFunctionExecutionResponse : public 
TcrChunkedResult {
 
  public:
   inline ChunkedFunctionExecutionResponse(
-  TcrMessage& msg, bool getResult, ResultCollectorPtr rc,
-  ACE_Recursive_Thread_Mutex* resultCollectorLock = NULL)
+  TcrMessage& msg, bool getResult, ResultCollectorPtr rc)
   : TcrChunkedResult(),
 m_msg(msg),
 m_getResult(getResult),
-m_rc(rc),
-m_resultCollectorLock(resultCollectorLock) {}
-
+m_rc(rc) {}
+
+inline ChunkedFunctionExecutionResponse(
--- End diff --

I was expecting to see the new version of ChunkedFunctionExecutionResponse 
used somewhere...


---
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-2713) Function execution can lead to passing the address of a stack variable

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/74#discussion_r107993045
  
--- Diff: src/cppcache/src/ThinClientRegion.hpp ---
@@ -416,14 +416,21 @@ class ChunkedFunctionExecutionResponse : public 
TcrChunkedResult {
 
  public:
   inline ChunkedFunctionExecutionResponse(
-  TcrMessage& msg, bool getResult, ResultCollectorPtr rc,
-  ACE_Recursive_Thread_Mutex* resultCollectorLock = NULL)
+  TcrMessage& msg, bool getResult, ResultCollectorPtr rc)
   : TcrChunkedResult(),
 m_msg(msg),
 m_getResult(getResult),
-m_rc(rc),
-m_resultCollectorLock(resultCollectorLock) {}
-
+m_rc(rc) {}
+
+inline ChunkedFunctionExecutionResponse(
--- End diff --

This code is exercised during function execution (ExecutionImpl.cpp and 
ThinClientPoolDM.hpp) and thus is covered by the function execution tests.


> Function execution can lead to passing the address of a stack variable
> --
>
> Key: GEODE-2713
> URL: https://issues.apache.org/jira/browse/GEODE-2713
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>
> In ThinClientRegion::executeFunctionSH(), the address of a stack variable 
> (the result collector lock) is passed to the workers. If an exception occurs 
> with any of the workers, the function will return, causing the stack variable 
> to be destructed. Since the workers have the raw address, it is now a 
> dangling pointer situation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #74: GEODE-2713: Wrap result collector lock in sha...

[PivotalSarge]

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

https://github.com/apache/geode-native/pull/74#discussion_r107993045
  
--- Diff: src/cppcache/src/ThinClientRegion.hpp ---
@@ -416,14 +416,21 @@ class ChunkedFunctionExecutionResponse : public 
TcrChunkedResult {
 
  public:
   inline ChunkedFunctionExecutionResponse(
-  TcrMessage& msg, bool getResult, ResultCollectorPtr rc,
-  ACE_Recursive_Thread_Mutex* resultCollectorLock = NULL)
+  TcrMessage& msg, bool getResult, ResultCollectorPtr rc)
   : TcrChunkedResult(),
 m_msg(msg),
 m_getResult(getResult),
-m_rc(rc),
-m_resultCollectorLock(resultCollectorLock) {}
-
+m_rc(rc) {}
+
+inline ChunkedFunctionExecutionResponse(
--- End diff --

This code is exercised during function execution (ExecutionImpl.cpp and 
ThinClientPoolDM.hpp) and thus is covered by the function execution tests.


---
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-2713) Function execution can lead to passing the address of a stack variable

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/74#discussion_r107992569
  
--- Diff: src/cppcache/src/ThinClientRegion.hpp ---
@@ -416,14 +416,21 @@ class ChunkedFunctionExecutionResponse : public 
TcrChunkedResult {
 
  public:
   inline ChunkedFunctionExecutionResponse(
-  TcrMessage& msg, bool getResult, ResultCollectorPtr rc,
-  ACE_Recursive_Thread_Mutex* resultCollectorLock = NULL)
+  TcrMessage& msg, bool getResult, ResultCollectorPtr rc)
   : TcrChunkedResult(),
 m_msg(msg),
 m_getResult(getResult),
-m_rc(rc),
-m_resultCollectorLock(resultCollectorLock) {}
-
+m_rc(rc) {}
+
+inline ChunkedFunctionExecutionResponse(
--- End diff --

@PivotalSarge where is this code exercised?  any test coverage for it?


> Function execution can lead to passing the address of a stack variable
> --
>
> Key: GEODE-2713
> URL: https://issues.apache.org/jira/browse/GEODE-2713
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>
> In ThinClientRegion::executeFunctionSH(), the address of a stack variable 
> (the result collector lock) is passed to the workers. If an exception occurs 
> with any of the workers, the function will return, causing the stack variable 
> to be destructed. Since the workers have the raw address, it is now a 
> dangling pointer situation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #74: GEODE-2713: Wrap result collector lock in sha...

[echobravopapa]

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

https://github.com/apache/geode-native/pull/74#discussion_r107992569
  
--- Diff: src/cppcache/src/ThinClientRegion.hpp ---
@@ -416,14 +416,21 @@ class ChunkedFunctionExecutionResponse : public 
TcrChunkedResult {
 
  public:
   inline ChunkedFunctionExecutionResponse(
-  TcrMessage& msg, bool getResult, ResultCollectorPtr rc,
-  ACE_Recursive_Thread_Mutex* resultCollectorLock = NULL)
+  TcrMessage& msg, bool getResult, ResultCollectorPtr rc)
   : TcrChunkedResult(),
 m_msg(msg),
 m_getResult(getResult),
-m_rc(rc),
-m_resultCollectorLock(resultCollectorLock) {}
-
+m_rc(rc) {}
+
+inline ChunkedFunctionExecutionResponse(
--- End diff --

@PivotalSarge where is this code exercised?  any test coverage for it?


---
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: GEODE-2714 Proposal for new api on Function interface (Please read)

[Jared Stewart]

Can you give a link to the proposal?

Thanks,
Jared
> On Mar 24, 2017, at 12:57 PM, Hitesh Khamesra  
> wrote:
> 
> Please let us know your opinion on that.
> Thanks.Hitesh

GEODE-2714 Proposal for new api on Function interface (Please read)

[Hitesh Khamesra]

Please let us know your opinion on that.
Thanks.Hitesh

[jira] [Created] (GEODE-2714) Proposal for new api on Function interface

[Hitesh Khamesra (JIRA)]

Hitesh Khamesra created GEODE-2714:
--

 Summary: Proposal for new api on Function interface
 Key: GEODE-2714
 URL: https://issues.apache.org/jira/browse/GEODE-2714
 Project: Geode
  Issue Type: Bug
  Components: functions
Reporter: Hitesh Khamesra


Function execution is the most useful feature of Geode. It allows you to 
execute a user-defined function on the node which holds the primary bucket of 
the partition region. In many cases application has colocated partition regions 
and using function application can operate on all the colocated primary buckets.

In that function, the application makes sure that no other thread is operating 
on same colocated keys. But during bucket rebalance there is a possibility that 
two thread might be executing a function on the same set of keys on different 
nodes.

It can happen as we don't take the lock(read-lock) on a primary bucket while 
executing the function. That allows Geode to move bucket for rebalancing.

Proposal: Introduce the following api on Function interface to indicate the 
need to primariness.

boolean needPrimaryLock(); // name suggestion?

The application would return true if they need a lock on the primary bucket. 
Default would be false.

Geode would call the interface and try to take readLock before executing the 
function on that node. Otherwise, it will throw the exception and let app 
re-execute that function.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2713) Function execution can lead to passing the address of a stack variable

[ASF GitHub Bot (JIRA)]

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

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

GitHub user PivotalSarge opened a pull request:

https://github.com/apache/geode-native/pull/74

GEODE-2713: Wrap result collector lock in shared_ptr.



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

$ git pull https://github.com/PivotalSarge/geode-native feature/GEODE-2713

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

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


commit 422b9dbe1e59621019c971b111322a9b49b431d7
Author: Sarge 
Date:   2017-03-24T18:06:29Z

GEODE-2713: Wrap result collector lock in shared_ptr.




> Function execution can lead to passing the address of a stack variable
> --
>
> Key: GEODE-2713
> URL: https://issues.apache.org/jira/browse/GEODE-2713
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>
> In ThinClientRegion::executeFunctionSH(), the address of a stack variable 
> (the result collector lock) is passed to the workers. If an exception occurs 
> with any of the workers, the function will return, causing the stack variable 
> to be destructed. Since the workers have the raw address, it is now a 
> dangling pointer situation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #74: GEODE-2713: Wrap result collector lock in sha...

[PivotalSarge]

GitHub user PivotalSarge opened a pull request:

https://github.com/apache/geode-native/pull/74

GEODE-2713: Wrap result collector lock in shared_ptr.



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

$ git pull https://github.com/PivotalSarge/geode-native feature/GEODE-2713

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

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


commit 422b9dbe1e59621019c971b111322a9b49b431d7
Author: Sarge 
Date:   2017-03-24T18:06:29Z

GEODE-2713: Wrap result collector lock in shared_ptr.




---
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-2687) create a test for failed SSL auth

[ASF GitHub Bot (JIRA)]

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

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

Github user PivotalSarge commented on the issue:

https://github.com/apache/geode-native/pull/71
  
This closes #71


> create a test for failed SSL auth
> -
>
> Key: GEODE-2687
> URL: https://issues.apache.org/jira/browse/GEODE-2687
> Project: Geode
>  Issue Type: Test
>  Components: native client
>Reporter: Ernest Burghardt
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2687) create a test for failed SSL auth

[ASF GitHub Bot (JIRA)]

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

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

Github user PivotalSarge closed the pull request at:

https://github.com/apache/geode-native/pull/71


> create a test for failed SSL auth
> -
>
> Key: GEODE-2687
> URL: https://issues.apache.org/jira/browse/GEODE-2687
> Project: Geode
>  Issue Type: Test
>  Components: native client
>Reporter: Ernest Burghardt
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

region with total-max-memory

[Srikrishan Malik]

While creating a region in geode you can specify --total-max-memory
which should limit the amount of memory used the the region entries.
ref: 
https://geode.apache.org/docs/guide/tools_modules/gfsh/command-pages/create.html#topic_54B0985FEC5241CA9D26B0CE0A5EA863

I created a region of type PARTITION_OVERFLOW with total-max-memory
set, I can see that this attribute is there in the the partition
attributes for the region on server, but when the amount of data
crossed the total-max-memory limit it did not start overflowing old
entries to disk, after some time(memory usage is almost 10x greater
than total-max-memory) the heap lru(which is based on total jvm head)
kicks in and starts evicting entries.

Is there any additional setting which has to be done to trigger
eviction when total-max-memory limit is reached for a region.

-Sri

[jira] [Created] (GEODE-2713) Function execution can lead to passing the address of a stack variable

[Michael Dodge (JIRA)]

Michael Dodge created GEODE-2713:


 Summary: Function execution can lead to passing the address of a 
stack variable
 Key: GEODE-2713
 URL: https://issues.apache.org/jira/browse/GEODE-2713
 Project: Geode
  Issue Type: Bug
  Components: native client
Reporter: Michael Dodge


In ThinClientRegion::executeFunctionSH(), the address of a stack variable (the 
result collector lock) is passed to the workers. If an exception occurs with 
any of the workers, the function will return, causing the stack variable to be 
destructed. Since the workers have the raw address, it is now a dangling 
pointer situation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 57894: GEODE-2670: do not use local mbs server connection even when pulse is in embeded mode.

[Jinmei Liao]

> On March 24, 2017, 4:23 p.m., Anthony Baker wrote:
> > Did you test Pulse in non-embedded mode w/ security?

Haven't. Will try it out. Theoretically, we didn't change anythign in that 
aspect. It should behave the same.


> On March 24, 2017, 4:23 p.m., Anthony Baker wrote:
> > geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/PulseAppListener.java
> > Line 495 (original)
> > 
> >
> > Will this break pulse when not run in embedded mode?

I don't quite know why previously we need to get the username/password from a 
proerty file. I thought user log in with a username/password and we use the 
same username/password to connect to jmx. This is probably before Integrated 
security where you need two different sets of credentials


> On March 24, 2017, 4:23 p.m., Anthony Baker wrote:
> > geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/IClusterUpdater.java
> > Lines 36 (patched)
> > 
> >
> > Seems like it would be better for connect to return a JMXConnection.

True. realized that too after I committed it.


> On March 24, 2017, 4:23 p.m., Anthony Baker wrote:
> > geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/IClusterUpdater.java
> > Lines 38 (patched)
> > 
> >
> > I don't think a default implementation should return null.

won't need this anymore.


> On March 24, 2017, 4:23 p.m., Anthony Baker wrote:
> > geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/security/GemFireAuthenticationProvider.java
> > Line 67 (original)
> > 
> >
> > Why is this case removed?

It's just unnessary, the exception is caught by the catch block immediatly 
below, so eventually, it's throwing a BadCredentialsException.


- Jinmei


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


On March 24, 2017, 4:03 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57894/
> ---
> 
> (Updated March 24, 2017, 4:03 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Jared Stewart, Kevin Duling, Ken 
> Howe, Kirk Lund, and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * using local mbs server connection will bypass all the mbean security checks
> * do not update the mbean attribute since pulse user has no cluster:write 
> privilege at all
> * Created EmbeddedPulseRule for tests
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
>  PRE-CREATION 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/HttpClientRule.java
>  d0b54b9de5759e1ba3ce78f4efaa547d391c29cf 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseVerificationTest.java
>  0b3b1cef8fa54c8dcb4d2ec2e4f49e9f10d729a7 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/PulseAppListener.java
>  e1666ecf38331983d8c47c4b46b3b7e87faaf854 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/controllers/PulseController.java
>  12b6172cbbc79651e972179532f2b79623a1992e 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/Cluster.java
>  e71388d134c96549ee9995c4c874615ee66fe7c1 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/IClusterUpdater.java
>  3ec820769a897bfb4f10a76a86dd2ce54fba3b70 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/JMXDataUpdater.java
>  9633b9a1f50df051b8fb9b4f4787a1d25a0ab019 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/Repository.java
>  b228e4a754100fe07c9dbec232d5e88809aefeef 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/security/GemFireAuthenticationProvider.java
>  4d300f04ff82f701509d44b83dd46698dbc6035e 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/controllers/PulseControllerJUnitTest.java
>  ddd799f5158e1f4213b0b6b2de8e1853ba65ab74 
> 
> 
> Diff: https://reviews.apache.org/r/57894/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin successful, manul pulse testing
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/73#discussion_r107950013
  
--- Diff: docs/geode-native-docs/introduction/developing-linux.html.md.erb 
---
@@ -19,48 +19,48 @@ See the License for the specific language governing 
permissions and
 limitations under the License.
 -->
 
-This section describes how to build and run a native client application on 
Linux.
+This section describes how to build and run a client application on Linux.
 
-**Note:** When compiling external projects or applications that are used 
or referenced by the Geode native client, make sure that you compile them for 
the same target architecture as your native client installation. For example, 
if you installed the 64-bit (x86) version of the native client, compile your 
external projects for 64-bit (x86) architecture.
+**Note:** When compiling external projects or applications that are used 
or referenced by the Geode client, make sure that you compile them for the same 
target architecture as your client installation. For example, if you installed 
the 64-bit (x86) version of the client, compile your external projects for 
64-bit (x86) architecture.
 
 ## Step 1. Set Environment Variables
 
-Set the native client environment variables on each Linux host. For each 
case, *product-dir* is the path to the native client product directory.
+Set the client environment variables on each Linux host. For each case, 
*product-dir* is the path to the client product directory.
 
 **For Bourne and Korn shells (sh, ksh, bash)**
 
 
-GFCPP=_product-dir_;export GFCPP
-PATH=$GFCPP/bin:$PATH;export PATH
-LD\_LIBRARY\_PATH=$GFCPP/lib:$LD\_LIBRARY\_PATH;export LD\_LIBRARY\_PATH
+GEODE=_product-dir_;export GEODE
+PATH=$GEODE/bin:$PATH;export PATH
+LD\_LIBRARY\_PATH=$GEODE/lib:$LD\_LIBRARY\_PATH;export LD\_LIBRARY\_PATH
 
 
-## Step 2. Compile C++ Clients and Dynamically Link Them 
to the GemFire Library
+## Step 2. Compile C++ Clients and Dynamically Link Them 
to the Geode Library
 
-On Linux, the `g++` compiler is supported. To build and link a C++ client 
to GemFire on Linux, the compilation command line must include the arguments 
listed in the following table.
+On Linux, the `g++` compiler is supported. To build and link a C++ client 
to Geode on Linux, the compilation command line must include the arguments 
listed in the following table.
 
 
 
 | Argument   | Explanation 
 |
 
||--|
 | `-D_REENTRANT` | Required to compile Linux programs in a thread-safe 
way. |
 | `-m32` or `-m64`   | Enables 32-bit or 64-bit compilation.   
 |
-| `-I$GFCPP/include` | Specifies the native client `include` directory.
 |
+| `-I$GEODE/include` | Specifies the client `include` directory. |
 
 
-The following table lists the linker switches that must be present on the 
command line when dynamically linking to the GemFire library.
+The following table lists the linker switches that must be present on the 
command line when dynamically linking to the Geode library.
 
 
 
 | Argument| Explanation
|
 
|-||
-| `-rpath $GFCPP/lib` | Tells the linker to look in `$GFCPP/lib` for 
libraries on which the native client library depends. |
-| `-L$GFCPP/lib`  | Tells the linker where to find the named 
libraries.|
+| `-rpath $GEODE/lib` | Tells the linker to look in `$GEODE/lib` for 
libraries on which the client library depends. |
+| `-L$GEODE/lib`  | Tells the linker where to find the named 
libraries.|
 | `-o durableclient`  | Tells the linker to output an object file named 
'durableclient'.   |
-| `-lgfcppcache`  | Links the native client C++ cache library to the 
compiled executable.  |
+| `-lgfcppcache`  | Links the client C++ cache library to the compiled 
executable.  |
 
 
-The following examples compile and link the 
`$GFCPP/SampleCode/quickstart/cpp/DurableClient.cpp` client to the 
`durableclient` output file.
+The following examples compile and link 

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/73#discussion_r107950857
  
--- Diff: 
docs/geode-native-docs/introduction/developing-windows.html.md.erb ---
@@ -21,18 +21,18 @@ limitations under the License.
 
 Geode uses the Visual Studio 2010 Service Pack 1 compiler for C++ programs 
on Windows, which invokes Microsoft® `cl.exe` from the command line 
at compile time.
 
-The Geode native client supports .NET 4.0 and Visual Studio 2010. For 
advantages and more information on the features of .NET 4.0 and Visual Studio 
2010 SP1, see 
[http://msdn.microsoft.com/en-us/library/dd831853(v=vs.100).aspx](http://msdn.microsoft.com/en-us/library/dd831853(v=vs.100).aspx)
 and 
[http://msdn.microsoft.com/en-us/library/vstudio/w0x726c2(v=vs.100).aspx](http://msdn.microsoft.com/en-us/library/vstudio/w0x726c2(v=vs.100).aspx).
+The Geode client supports .NET 4.0 and Visual Studio 2010. For advantages 
and more information on the features of .NET 4.0 and Visual Studio 2010 SP1, 
see 
[http://msdn.microsoft.com/en-us/library/dd831853(v=vs.100).aspx](http://msdn.microsoft.com/en-us/library/dd831853(v=vs.100).aspx)
 and 
[http://msdn.microsoft.com/en-us/library/vstudio/w0x726c2(v=vs.100).aspx](http://msdn.microsoft.com/en-us/library/vstudio/w0x726c2(v=vs.100).aspx).
 
 Visual Studio 2010 SP1 is the recommended compiler. If you are using any 
other compiler, contact technical support for assistance.
--- End diff --

This section might be removable as well, this is an old version of 
VisualStudio and if the community wants to update/maintain this to match what 
they are using that's cool



> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/73#discussion_r107950987
  
--- Diff: 
docs/geode-native-docs/introduction/developing-windows.html.md.erb ---
@@ -21,18 +21,18 @@ limitations under the License.
 
 Geode uses the Visual Studio 2010 Service Pack 1 compiler for C++ programs 
on Windows, which invokes Microsoft® `cl.exe` from the command line 
at compile time.
 
-The Geode native client supports .NET 4.0 and Visual Studio 2010. For 
advantages and more information on the features of .NET 4.0 and Visual Studio 
2010 SP1, see 
[http://msdn.microsoft.com/en-us/library/dd831853(v=vs.100).aspx](http://msdn.microsoft.com/en-us/library/dd831853(v=vs.100).aspx)
 and 
[http://msdn.microsoft.com/en-us/library/vstudio/w0x726c2(v=vs.100).aspx](http://msdn.microsoft.com/en-us/library/vstudio/w0x726c2(v=vs.100).aspx).
+The Geode client supports .NET 4.0 and Visual Studio 2010. For advantages 
and more information on the features of .NET 4.0 and Visual Studio 2010 SP1, 
see 
[http://msdn.microsoft.com/en-us/library/dd831853(v=vs.100).aspx](http://msdn.microsoft.com/en-us/library/dd831853(v=vs.100).aspx)
 and 
[http://msdn.microsoft.com/en-us/library/vstudio/w0x726c2(v=vs.100).aspx](http://msdn.microsoft.com/en-us/library/vstudio/w0x726c2(v=vs.100).aspx).
 
 Visual Studio 2010 SP1 is the recommended compiler. If you are using any 
other compiler, contact technical support for assistance.
--- End diff --

Let's remove any references to "contacting tech support" as this is not a 
concept in an Apache project.


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/73#discussion_r107950403
  
--- Diff: 
docs/geode-native-docs/introduction/developing-solaris.html.md.erb ---
@@ -19,25 +19,25 @@ See the License for the specific language governing 
permissions and
 limitations under the License.
 -->
 
-This section describes how to build and run a native client application on 
Solaris.
+This section describes how to build and run a client application on 
Solaris.
 
 ## Step 1. Set Environment Variables
 
-**Note:** When compiling external projects or applications that are used 
or referenced by the native client, make sure that you compile them for the 
same target architecture as your native client installation. For example, if 
you installed the 32-bit (x86) version of the native client, compile your 
external projects for 32-bit (x86) architecture.
+**Note:** When compiling external projects or applications that are used 
or referenced by the client, make sure that you compile them for the same 
target architecture as your client installation. For example, if you installed 
the 32-bit (x86) version of the client, compile your external projects for 
32-bit (x86) architecture.
 
-Set the native client environment variables on each Solaris host. For each 
case, *product-dir* is the path to the native client product directory.
+Set the client environment variables on each Solaris host. For each case, 
*product-dir* is the path to the client product directory.
 
 **For Bourne and Korn shells (sh, ksh, bash)**
 
 
-GFCPP=_product-dir_; export GFCPP
-PATH=$GFCPP/bin:$PATH;export PATH
-LD\_LIBRARY\_PATH=$GFCPP/lib:$LD\_LIBRARY\_PATH;export LD\_LIBRARY\_PATH
+GEODE=_product-dir_; export GEODE
+PATH=$GEODE/bin:$PATH;export PATH
+LD\_LIBRARY\_PATH=$GEODE/lib:$LD\_LIBRARY\_PATH;export LD\_LIBRARY\_PATH
 
 
--- End diff --

The future life of Solaris is very much up in the air, this section could 
be removed as I don't think it is regarding the "current" version of SunStudio


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #73: GEODE-2513 Unbrand C++ API docs: Getting Star...

[echobravopapa]

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

https://github.com/apache/geode-native/pull/73#discussion_r107950987
  
--- Diff: 
docs/geode-native-docs/introduction/developing-windows.html.md.erb ---
@@ -21,18 +21,18 @@ limitations under the License.
 
 Geode uses the Visual Studio 2010 Service Pack 1 compiler for C++ programs 
on Windows, which invokes Microsoft® `cl.exe` from the command line 
at compile time.
 
-The Geode native client supports .NET 4.0 and Visual Studio 2010. For 
advantages and more information on the features of .NET 4.0 and Visual Studio 
2010 SP1, see 
[http://msdn.microsoft.com/en-us/library/dd831853(v=vs.100).aspx](http://msdn.microsoft.com/en-us/library/dd831853(v=vs.100).aspx)
 and 
[http://msdn.microsoft.com/en-us/library/vstudio/w0x726c2(v=vs.100).aspx](http://msdn.microsoft.com/en-us/library/vstudio/w0x726c2(v=vs.100).aspx).
+The Geode client supports .NET 4.0 and Visual Studio 2010. For advantages 
and more information on the features of .NET 4.0 and Visual Studio 2010 SP1, 
see 
[http://msdn.microsoft.com/en-us/library/dd831853(v=vs.100).aspx](http://msdn.microsoft.com/en-us/library/dd831853(v=vs.100).aspx)
 and 
[http://msdn.microsoft.com/en-us/library/vstudio/w0x726c2(v=vs.100).aspx](http://msdn.microsoft.com/en-us/library/vstudio/w0x726c2(v=vs.100).aspx).
 
 Visual Studio 2010 SP1 is the recommended compiler. If you are using any 
other compiler, contact technical support for assistance.
--- End diff --

Let's remove any references to "contacting tech support" as this is not a 
concept in an Apache project.


---
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-native pull request #73: GEODE-2513 Unbrand C++ API docs: Getting Star...

[echobravopapa]

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

https://github.com/apache/geode-native/pull/73#discussion_r107950403
  
--- Diff: 
docs/geode-native-docs/introduction/developing-solaris.html.md.erb ---
@@ -19,25 +19,25 @@ See the License for the specific language governing 
permissions and
 limitations under the License.
 -->
 
-This section describes how to build and run a native client application on 
Solaris.
+This section describes how to build and run a client application on 
Solaris.
 
 ## Step 1. Set Environment Variables
 
-**Note:** When compiling external projects or applications that are used 
or referenced by the native client, make sure that you compile them for the 
same target architecture as your native client installation. For example, if 
you installed the 32-bit (x86) version of the native client, compile your 
external projects for 32-bit (x86) architecture.
+**Note:** When compiling external projects or applications that are used 
or referenced by the client, make sure that you compile them for the same 
target architecture as your client installation. For example, if you installed 
the 32-bit (x86) version of the client, compile your external projects for 
32-bit (x86) architecture.
 
-Set the native client environment variables on each Solaris host. For each 
case, *product-dir* is the path to the native client product directory.
+Set the client environment variables on each Solaris host. For each case, 
*product-dir* is the path to the client product directory.
 
 **For Bourne and Korn shells (sh, ksh, bash)**
 
 
-GFCPP=_product-dir_; export GFCPP
-PATH=$GFCPP/bin:$PATH;export PATH
-LD\_LIBRARY\_PATH=$GFCPP/lib:$LD\_LIBRARY\_PATH;export LD\_LIBRARY\_PATH
+GEODE=_product-dir_; export GEODE
+PATH=$GEODE/bin:$PATH;export PATH
+LD\_LIBRARY\_PATH=$GEODE/lib:$LD\_LIBRARY\_PATH;export LD\_LIBRARY\_PATH
 
 
--- End diff --

The future life of Solaris is very much up in the air, this section could 
be removed as I don't think it is regarding the "current" version of SunStudio


---
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-native pull request #73: GEODE-2513 Unbrand C++ API docs: Getting Star...

[echobravopapa]

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

https://github.com/apache/geode-native/pull/73#discussion_r107950013
  
--- Diff: docs/geode-native-docs/introduction/developing-linux.html.md.erb 
---
@@ -19,48 +19,48 @@ See the License for the specific language governing 
permissions and
 limitations under the License.
 -->
 
-This section describes how to build and run a native client application on 
Linux.
+This section describes how to build and run a client application on Linux.
 
-**Note:** When compiling external projects or applications that are used 
or referenced by the Geode native client, make sure that you compile them for 
the same target architecture as your native client installation. For example, 
if you installed the 64-bit (x86) version of the native client, compile your 
external projects for 64-bit (x86) architecture.
+**Note:** When compiling external projects or applications that are used 
or referenced by the Geode client, make sure that you compile them for the same 
target architecture as your client installation. For example, if you installed 
the 64-bit (x86) version of the client, compile your external projects for 
64-bit (x86) architecture.
 
 ## Step 1. Set Environment Variables
 
-Set the native client environment variables on each Linux host. For each 
case, *product-dir* is the path to the native client product directory.
+Set the client environment variables on each Linux host. For each case, 
*product-dir* is the path to the client product directory.
 
 **For Bourne and Korn shells (sh, ksh, bash)**
 
 
-GFCPP=_product-dir_;export GFCPP
-PATH=$GFCPP/bin:$PATH;export PATH
-LD\_LIBRARY\_PATH=$GFCPP/lib:$LD\_LIBRARY\_PATH;export LD\_LIBRARY\_PATH
+GEODE=_product-dir_;export GEODE
+PATH=$GEODE/bin:$PATH;export PATH
+LD\_LIBRARY\_PATH=$GEODE/lib:$LD\_LIBRARY\_PATH;export LD\_LIBRARY\_PATH
 
 
-## Step 2. Compile C++ Clients and Dynamically Link Them 
to the GemFire Library
+## Step 2. Compile C++ Clients and Dynamically Link Them 
to the Geode Library
 
-On Linux, the `g++` compiler is supported. To build and link a C++ client 
to GemFire on Linux, the compilation command line must include the arguments 
listed in the following table.
+On Linux, the `g++` compiler is supported. To build and link a C++ client 
to Geode on Linux, the compilation command line must include the arguments 
listed in the following table.
 
 
 
 | Argument   | Explanation 
 |
 
||--|
 | `-D_REENTRANT` | Required to compile Linux programs in a thread-safe 
way. |
 | `-m32` or `-m64`   | Enables 32-bit or 64-bit compilation.   
 |
-| `-I$GFCPP/include` | Specifies the native client `include` directory.
 |
+| `-I$GEODE/include` | Specifies the client `include` directory. |
 
 
-The following table lists the linker switches that must be present on the 
command line when dynamically linking to the GemFire library.
+The following table lists the linker switches that must be present on the 
command line when dynamically linking to the Geode library.
 
 
 
 | Argument| Explanation
|
 
|-||
-| `-rpath $GFCPP/lib` | Tells the linker to look in `$GFCPP/lib` for 
libraries on which the native client library depends. |
-| `-L$GFCPP/lib`  | Tells the linker where to find the named 
libraries.|
+| `-rpath $GEODE/lib` | Tells the linker to look in `$GEODE/lib` for 
libraries on which the client library depends. |
+| `-L$GEODE/lib`  | Tells the linker where to find the named 
libraries.|
 | `-o durableclient`  | Tells the linker to output an object file named 
'durableclient'.   |
-| `-lgfcppcache`  | Links the native client C++ cache library to the 
compiled executable.  |
+| `-lgfcppcache`  | Links the client C++ cache library to the compiled 
executable.  |
 
 
-The following examples compile and link the 
`$GFCPP/SampleCode/quickstart/cpp/DurableClient.cpp` client to the 
`durableclient` output file.
+The following examples compile and link the 
`$GEODE/SampleCode/quickstart/cpp/DurableClient.cpp` client to the 
`durableclient` output file.
 
 **Compiling and Dynamically Linking on Linux for 32-bit**
--- End diff --

It would be better to have the examples 

Re: Review Request 57894: GEODE-2670: do not use local mbs server connection even when pulse is in embeded mode.

[Anthony Baker]

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



Did you test Pulse in non-embedded mode w/ security?


geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/PulseAppListener.java
Line 495 (original)


Will this break pulse when not run in embedded mode?



geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/IClusterUpdater.java
Lines 36 (patched)


Seems like it would be better for connect to return a JMXConnection.



geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/IClusterUpdater.java
Lines 38 (patched)


I don't think a default implementation should return null.



geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/security/GemFireAuthenticationProvider.java
Line 67 (original)


Why is this case removed?


- Anthony Baker


On March 24, 2017, 4:03 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57894/
> ---
> 
> (Updated March 24, 2017, 4:03 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Jared Stewart, Kevin Duling, Ken 
> Howe, Kirk Lund, and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * using local mbs server connection will bypass all the mbean security checks
> * do not update the mbean attribute since pulse user has no cluster:write 
> privilege at all
> * Created EmbeddedPulseRule for tests
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
>  PRE-CREATION 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/HttpClientRule.java
>  d0b54b9de5759e1ba3ce78f4efaa547d391c29cf 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseVerificationTest.java
>  0b3b1cef8fa54c8dcb4d2ec2e4f49e9f10d729a7 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/PulseAppListener.java
>  e1666ecf38331983d8c47c4b46b3b7e87faaf854 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/controllers/PulseController.java
>  12b6172cbbc79651e972179532f2b79623a1992e 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/Cluster.java
>  e71388d134c96549ee9995c4c874615ee66fe7c1 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/IClusterUpdater.java
>  3ec820769a897bfb4f10a76a86dd2ce54fba3b70 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/JMXDataUpdater.java
>  9633b9a1f50df051b8fb9b4f4787a1d25a0ab019 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/Repository.java
>  b228e4a754100fe07c9dbec232d5e88809aefeef 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/security/GemFireAuthenticationProvider.java
>  4d300f04ff82f701509d44b83dd46698dbc6035e 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/controllers/PulseControllerJUnitTest.java
>  ddd799f5158e1f4213b0b6b2de8e1853ba65ab74 
> 
> 
> Diff: https://reviews.apache.org/r/57894/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin successful, manul pulse testing
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

[jira] [Commented] (GEODE-2660) Mark Redis Adapter as Experimental

[ASF GitHub Bot (JIRA)]

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

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

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/426
  
Also, since we're talking about releasing v 1.2 soon it would be nice to 
add the Experimental annotation with this same commit since it is breaking 
compatibility with v 1.1.


> Mark Redis Adapter as Experimental
> --
>
> Key: GEODE-2660
> URL: https://issues.apache.org/jira/browse/GEODE-2660
> Project: Geode
>  Issue Type: Bug
>Reporter: Galen O'Sullivan
>
> I put this up for a vote recently. The Redis adapter is really not ready for 
> prime time at this point. We should mark it experimental so people don't 
> mistakenly think it's ready, and so that we can change it more readily on 
> develop.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #426: GEODE-2660 Add @Experimental to the Redis adapter.

[bschuchardt]

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/426
  
Also, since we're talking about releasing v 1.2 soon it would be nice to 
add the Experimental annotation with this same commit since it is breaking 
compatibility with v 1.1.


---
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 57822: GEODE-1274: Migration from PulseLogWriter to Log4j standard.

[Jinmei Liao]

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



We will need to verify that the logs went to the same place as before, or at 
least went to a reasonable place.

- Jinmei Liao


On March 22, 2017, 10:33 p.m., Patrick Rhomberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57822/
> ---
> 
> (Updated March 22, 2017, 10:33 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Ken Howe, 
> Kirk Lund, and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> To avoid dependency on geode-core, the pulse loggers are instantiated 
> directly from LogManager, rather than canonical LogService (which itself 
> extends LogManager).
> 
> Significant reduction of logging level state checks, relying on Log4j 
> handling.
> Significant reduction of string concatenation, relying on Log4j2 string 
> substitutions.
> Reduction of logging using an exception e.getMessage, favoring instead 
> passing the exception itself for the stacktrace.
> Multiple identical exception blocks collapsed.
> 
> 
> 
> Explicitly not addressed in this ticket:
> - A great deal of logging could do with localization.
> - A number of exception blocks catch one or more types of exception and only 
> log the exception before moving.  These are specific exceptions and not the 
> general `Exception` class.  The catches could be simplified, but could that 
> lead to a catch an error that would otherwise be raised?
> 
> The original ticket was not about updating from a depreciated class, but 
> about how logs were not being collected.  The answer to this was that Log4j 
> wasn't tracking them, so they weren't being gathered; extending Log4j to do 
> Pulse tracking should resolve the issue, but is it okay that this is only 
> tangentally answering the problem?
> 
> 
> Diffs
> -
> 
>   geode-pulse/build.gradle a038f734266939f3c12b713ce0745c013b4adb91 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/PulseAppListener.java
>  e1666ecf38331983d8c47c4b46b3b7e87faaf854 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/controllers/ExceptionHandlingAdvice.java
>  80a3c63b5d9170cf9933c43edf56da78dc62bf46 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/controllers/PulseController.java
>  12b6172cbbc79651e972179532f2b79623a1992e 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/Cluster.java
>  e71388d134c96549ee9995c4c874615ee66fe7c1 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/DataBrowser.java
>  03077c27003811718e3974575a15b6892f6d8e2f 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/JMXDataUpdater.java
>  9633b9a1f50df051b8fb9b4f4787a1d25a0ab019 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/JmxManagerFinder.java
>  fa2b5b79f40a95b0a20be38c20e61d9e94a39688 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/PulseConfig.java
>  dc643b49462af9365859d899f2c798f0f2448b72 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/PulseConstants.java
>  b36c283630fcd3d143c1398ac0fecf45eec0eb54 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/Repository.java
>  b228e4a754100fe07c9dbec232d5e88809aefeef 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/log/LogWriter.java
>  6f90e7a48a10ab2778ee00cf3d707a476ebe91eb 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/log/MessageFormatter.java
>  924520d3ba70a48379bd6ff9a6ce4d6e0d4ed804 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/log/PulseLogWriter.java
>  241b34bfe5bc56e062c43944ec7aaf1cfaa657c7 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/log/PulseLogger.java
>  d22f188248d2d8fb685074523e22eac7c26f5e20 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/security/GemFireAuthentication.java
>  884e51fa71b79de9e5ab9e7f0f933e37b6031438 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/security/GemFireAuthenticationProvider.java
>  4d300f04ff82f701509d44b83dd46698dbc6035e 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/security/LogoutHandler.java
>  e18e35d596552a40715ee772e559ffc2d077af5e 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/service/ClusterSelectedRegionService.java
>  a088ccb4176db19f9ec0ec3570ad23d286609f7b 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/service/ClusterSelectedRegionsMemberService.java
>  

[jira] [Commented] (GEODE-2660) Mark Redis Adapter as Experimental

[ASF GitHub Bot (JIRA)]

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

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

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/426
  
I don't think we can merge these changes until the lock-service variables 
in ExeuctionHandlerContext are made static.  As it's currently implemented 
every ExecutionContextHandler has its own lock service, so concurrent 
operations aren't protected.  This also calls into question any performance 
figures obtained with this code since it isn't functioning properly.


> Mark Redis Adapter as Experimental
> --
>
> Key: GEODE-2660
> URL: https://issues.apache.org/jira/browse/GEODE-2660
> Project: Geode
>  Issue Type: Bug
>Reporter: Galen O'Sullivan
>
> I put this up for a vote recently. The Redis adapter is really not ready for 
> prime time at this point. We should mark it experimental so people don't 
> mistakenly think it's ready, and so that we can change it more readily on 
> develop.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #426: GEODE-2660 Add @Experimental to the Redis adapter.

[bschuchardt]

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/426
  
I don't think we can merge these changes until the lock-service variables 
in ExeuctionHandlerContext are made static.  As it's currently implemented 
every ExecutionContextHandler has its own lock service, so concurrent 
operations aren't protected.  This also calls into question any performance 
figures obtained with this code since it isn't functioning properly.


---
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 57522: check for string "null" in server/locator status message

[Jinmei Liao]

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


Ship it!




Ship It!

- Jinmei Liao


On March 13, 2017, 10:31 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57522/
> ---
> 
> (Updated March 13, 2017, 10:31 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Kirk 
> Lund, Patrick Rhomberg, and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Restored original functionality when launcher process exits. Unintentionally 
> omitted this when refactoring from using exitValue() to isAlive()
> 
> Check for string "null" in server/locator status message to prevent 
> interrupting the string of dots.
> 
> Refactored server and locator start commands to use JDK 1.8 Process.isAlive 
> instead of a try/catch with Process.exitValue
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
>  d42d75e 
> 
> 
> Diff: https://reviews.apache.org/r/57522/diff/2/
> 
> 
> Testing
> ---
> 
> Ran spotlessApply
> Re-started precheckin
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/73#discussion_r107939092
  
--- Diff: 
docs/geode-native-book/master_middleman/source/subnavs/geode-nc-nav.erb ---
@@ -20,26 +20,26 @@ limitations under the License.
 
 
 
-Pivotal 
GemFire Native Client 9.0 Documentation
+Apache Geode 
Client Documentation
 
 
 
-
-Supported
 Configurations and System Requirements
-
+   
+   System 
Configurations
+   
 
 
 
-Getting 
Started with a Native Client
+Getting 
Started with the Client
 
 
-About the 
Native Client
+About the 
Client
 
 
-Installing the 
Native Client
+Installing the 
Geode Client
--- End diff --

Elsewhere it's just "Client", not "Geode Client".


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #73: GEODE-2513 Unbrand C++ API docs: Getting Star...

[PivotalSarge]

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

https://github.com/apache/geode-native/pull/73#discussion_r107939092
  
--- Diff: 
docs/geode-native-book/master_middleman/source/subnavs/geode-nc-nav.erb ---
@@ -20,26 +20,26 @@ limitations under the License.
 
 
 
-Pivotal 
GemFire Native Client 9.0 Documentation
+Apache Geode 
Client Documentation
 
 
 
-
-Supported
 Configurations and System Requirements
-
+   
+   System 
Configurations
+   
 
 
 
-Getting 
Started with a Native Client
+Getting 
Started with the Client
 
 
-About the 
Native Client
+About the 
Client
 
 
-Installing the 
Native Client
+Installing the 
Geode Client
--- End diff --

Elsewhere it's just "Client", not "Geode Client".


---
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 57894: GEODE-2670: do not use local mbs server connection even when pulse is in embeded mode.

[Jinmei Liao]

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

(Updated March 24, 2017, 4:03 p.m.)


Review request for geode, Anthony Baker, Jared Stewart, Kevin Duling, Ken Howe, 
Kirk Lund, and Patrick Rhomberg.


Repository: geode


Description
---

* using local mbs server connection will bypass all the mbean security checks
* do not update the mbean attribute since pulse user has no cluster:write 
privilege at all
* Created EmbeddedPulseRule for tests


Diffs
-

  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
 PRE-CREATION 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/HttpClientRule.java
 d0b54b9de5759e1ba3ce78f4efaa547d391c29cf 
  
geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseVerificationTest.java
 0b3b1cef8fa54c8dcb4d2ec2e4f49e9f10d729a7 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/PulseAppListener.java
 e1666ecf38331983d8c47c4b46b3b7e87faaf854 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/controllers/PulseController.java
 12b6172cbbc79651e972179532f2b79623a1992e 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/Cluster.java
 e71388d134c96549ee9995c4c874615ee66fe7c1 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/IClusterUpdater.java
 3ec820769a897bfb4f10a76a86dd2ce54fba3b70 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/JMXDataUpdater.java
 9633b9a1f50df051b8fb9b4f4787a1d25a0ab019 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/Repository.java
 b228e4a754100fe07c9dbec232d5e88809aefeef 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/security/GemFireAuthenticationProvider.java
 4d300f04ff82f701509d44b83dd46698dbc6035e 
  
geode-pulse/src/test/java/org/apache/geode/tools/pulse/controllers/PulseControllerJUnitTest.java
 ddd799f5158e1f4213b0b6b2de8e1853ba65ab74 


Diff: https://reviews.apache.org/r/57894/diff/1/


Testing (updated)
---

precheckin successful, manul pulse testing


Thanks,

Jinmei Liao

JIRA karma

[Anthony Baker]

Hi, I’d like to be able to edit versions in JIRA.  Can someone adjust 
permissions so I can do this?  

Otherwise I’m going to keep bugging y’all for help :-)

Thanks,
Anthony