[jira] [Commented] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege

[Diane Hardman (JIRA)]

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

Diane Hardman commented on GEODE-2605:
--

When I add CLUSTER:READ to my dataAdmin user (which already had DATA:MANAGE, 
DATA:READ, and DATA:WRITE privileges) the Lucene query succeeds.

> Unable to do a Lucene query without CLUSTER:READ privilege
> --
>
> Key: GEODE-2605
> URL: https://issues.apache.org/jira/browse/GEODE-2605
> Project: Geode
>  Issue Type: Bug
>  Components: lucene, security
>Reporter: Diane Hardman
>
> I have configured a small cluster with security and am testing the privileges 
> I need for creating a Lucene index and then executing a query/search using 
> Lucene. 
> I have confirmed that DATA:MANAGE privilege allows me to create a lucene 
> index (similar to creating OQL indexes).
> I assumed I needed DATA:WRITE privilege to execute 'search lucene' because 
> the implementation uses a function. Instead, I am getting an error that I 
> need CLUSTER:READ privilege. I don't know why.
> As an aside, we may want to document that all DATA privileges automatically 
> include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but 
> could not list the indexes I created without CLUSTER:READ... go figure.



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

[jira] [Created] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege

[Diane Hardman (JIRA)]

Diane Hardman created GEODE-2605:


 Summary: Unable to do a Lucene query without CLUSTER:READ privilege
 Key: GEODE-2605
 URL: https://issues.apache.org/jira/browse/GEODE-2605
 Project: Geode
  Issue Type: Bug
  Components: lucene, security
Reporter: Diane Hardman


I have configured a small cluster with security and am testing the privileges I 
need for creating a Lucene index and then executing a query/search using 
Lucene. 
I have confirmed that DATA:MANAGE privilege allows me to create a lucene index 
(similar to creating OQL indexes).
I assumed I needed DATA:WRITE privilege to execute 'search lucene' because the 
implementation uses a function. Instead, I am getting an error that I need 
CLUSTER:READ privilege. I don't know why.

As an aside, we may want to document that all DATA privileges automatically 
include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but 
could not list the indexes I created without CLUSTER:READ... go figure.



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

[jira] [Assigned] (GEODE-2525) Replace random number implementation with C++11 standards

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett reassigned GEODE-2525:
---

Assignee: Jacob S. Barrett

> Replace random number implementation with C++11 standards
> -
>
> Key: GEODE-2525
> URL: https://issues.apache.org/jira/browse/GEODE-2525
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> Remove Mersenne Twister implementation from source. Use C++11 random where 
> appropriate. Refactor random usage to be thread safe as applicable. GsRansom 
> uses spin lock to protect. Consider thread local random.



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

[jira] [Updated] (GEODE-2525) Replace random number implementation with C++11 standards

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett updated GEODE-2525:

Issue Type: Task  (was: Bug)

> Replace random number implementation with C++11 standards
> -
>
> Key: GEODE-2525
> URL: https://issues.apache.org/jira/browse/GEODE-2525
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> Remove Mersenne Twister implementation from source. Use C++11 random where 
> appropriate. Refactor random usage to be thread safe as applicable. GsRansom 
> uses spin lock to protect. Consider thread local random.



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

[jira] [Commented] (GEODE-2509) Build failed at openSUSE LEAP 42.2

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett commented on GEODE-2509:
-

Rather than attaching a patch would you be willing to open a pull request?

> Build failed at openSUSE LEAP 42.2
> --
>
> Key: GEODE-2509
> URL: https://issues.apache.org/jira/browse/GEODE-2509
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Danilo Chang
>Priority: Minor
> Attachments: fix_build_opensuse.patch
>
>
> geode-native C++ client build failed at openSUSE LEAP 42.2, because the 
> library folder name is different at 32bit or 64bit environment (lib64 at 
> 64bit environment and lib at 32bit environment). Now 2 components has this 
> issue, libxml2 and xerces-c.
> The attachment file is the solution I try to fix this issue (use --libdir to 
> specify the path). However, I don't know Geode native C++ client prefer to 
> use the same lib folder name or not. So I create this JIRA item.



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

[jira] [Assigned] (GEODE-2493) Replace the locking and CAS operations provided in HostAsm with C++11 standards

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett reassigned GEODE-2493:
---

Assignee: Jacob S. Barrett

> Replace the locking and CAS operations provided in HostAsm with C++11 
> standards
> ---
>
> Key: GEODE-2493
> URL: https://issues.apache.org/jira/browse/GEODE-2493
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> Several platform specific locking and CAS operations are implemented in 
> HostAsm and related files. These are not portable and require porting 
> efforts. They are also not well tested. Converting the C++11 standards allows 
> the compiler to choose the code or instructions that optimize the behavior 
> required. Most if not all of the functions these files provide can be 
> replaced with C++11 standard functions.
> Some Examples:
> On Solaris SPARC we have inline assembly.
> On Solaris x86 we use Solaris specific runtime functions.
> On Windows we use really old Win32 functions that have some non-standard 
> behavior.



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

[jira] [Resolved] (GEODE-2317) native client cmake build should honor GEODE_HOME environment variable

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett resolved GEODE-2317.
-
Resolution: Fixed

> native client cmake build should honor GEODE_HOME environment variable
> --
>
> Key: GEODE-2317
> URL: https://issues.apache.org/jira/browse/GEODE-2317
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Dan Smith
>Assignee: Jacob S. Barrett
>
> The native client build currently looks for a GEODE_ROOT variable. However, 
> the convention in the java project and the geode-examples is to use a 
> GEODE_HOME environment variable to specify the location of geode. The native 
> client build should look for this environment variable.



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

[jira] [Resolved] (GEODE-2604) Add javadocs comments to LuceneIndexMetrics

[nabarun (JIRA)]

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

nabarun resolved GEODE-2604.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Add javadocs comments to LuceneIndexMetrics 
> 
>
> Key: GEODE-2604
> URL: https://issues.apache.org/jira/browse/GEODE-2604
> Project: Geode
>  Issue Type: Bug
>Reporter: nabarun
> Fix For: 1.2.0
>
>




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

[jira] [Commented] (GEODE-2602) Resolve C++11 and minimum support compilers discrepancies

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett commented on GEODE-2602:
-

feature/GEODE-2602 rolls up the attached blocked tickets.

> Resolve C++11 and minimum support compilers discrepancies
> -
>
> Key: GEODE-2602
> URL: https://issues.apache.org/jira/browse/GEODE-2602
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>
> Referencing BUILDING.md our target language is C++11 and we state:
> {noformat}
> ### Required Tools
> * C++11 compiler *(see platform specific requirements)*
> {noformat}
> The problem is that our platform specific requirements do not meet the 
> minimum standards for C++11 compilers. 
> *Linux - GCC 4.8.1+*
> https://gcc.gnu.org/projects/cxx-status.html#cxx11
> Our Travis CI compiles on Linux using GCC 4.9.1.
> _Current listed minimum, 4.6,  does not support many of the C++11 features 
> currently in our source._
> *MacOS X - clang 3.3+*
> https://clang.llvm.org/cxx_status.html
> *Solaris - Solaris Studio 12.5+*
> https://docs.oracle.com/cd/E60778_01/html/E60746/bkabe.html#OSSCPgnyio
> _Currently listed minimum, 12.4, [does not 
> support|https://docs.oracle.com/cd/E37069_01/html/E37071/gncix.html#scrolltoc]
>  many concurrent features like std::atomic necessary to remove platform 
> specific concurrency code._
> *Windows - Visual Studio 2015*
> https://msdn.microsoft.com/en-us/library/hh567368(v=vs.140).aspx
> _Currently listed minimum, 2013, does not support many of the C++11 features, 
> like std::atomic_flag, necessary to remove platform specific concurrency 
> code._



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

[jira] [Commented] (GEODE-2552) Replace NanoTimer with std::chrono / std::this_thread::sleep_for

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2552:


Commit bf254f39909573bb4fa605c21eda46092acb8420 in geode-native's branch 
refs/heads/feature/GEODE-2602 from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=bf254f3 ]

GEODE-2552: Replaced NanoTimer with std::chrono.


> Replace NanoTimer with std::chrono / std::this_thread::sleep_for
> 
>
> Key: GEODE-2552
> URL: https://issues.apache.org/jira/browse/GEODE-2552
> Project: Geode
>  Issue Type: Task
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> Replace `NanoTimer` with `std::chrono` / `std::this_thread::sleep_for`



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

[jira] [Commented] (GEODE-2604) Add javadocs comments to LuceneIndexMetrics

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Add javadocs comments to LuceneIndexMetrics 
> 
>
> Key: GEODE-2604
> URL: https://issues.apache.org/jira/browse/GEODE-2604
> Project: Geode
>  Issue Type: Bug
>Reporter: nabarun
>




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

[jira] [Commented] (GEODE-2494) Replace SpinLock class with C++11 style BasicLockable class, spinlock_mutex.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2494:


Commit 80fd387e654b7605f660f0f9e97d0e92865ac19d in geode-native's branch 
refs/heads/feature/GEODE-2602 from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=80fd387 ]

GEODE-2494: Removed SpinLock.



> Replace SpinLock class with C++11 style BasicLockable class, spinlock_mutex.
> 
>
> Key: GEODE-2494
> URL: https://issues.apache.org/jira/browse/GEODE-2494
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> Replace {{SpinLock}} class with C++11 style 
> {{[BasicLockable|http://en.cppreference.com/w/cpp/concept/BasicLockable]}} 
> class, {{spinlock_mutex}}. You can find several public domain examples of how 
> to implement a {{spinlock_mutex}} that can be used with 
> {{[std::lock_guard|http://en.cppreference.com/w/cpp/thread/lock_guard]}}.



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

[jira] [Commented] (GEODE-2494) Replace SpinLock class with C++11 style BasicLockable class, spinlock_mutex.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2494:


Commit 2822ed29841c8c8eb8057ac0cbabcf7e3a42924f in geode-native's branch 
refs/heads/feature/GEODE-2602 from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=2822ed2 ]

GEODE-2494: Reverts conversion to pointer from ref.


> Replace SpinLock class with C++11 style BasicLockable class, spinlock_mutex.
> 
>
> Key: GEODE-2494
> URL: https://issues.apache.org/jira/browse/GEODE-2494
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> Replace {{SpinLock}} class with C++11 style 
> {{[BasicLockable|http://en.cppreference.com/w/cpp/concept/BasicLockable]}} 
> class, {{spinlock_mutex}}. You can find several public domain examples of how 
> to implement a {{spinlock_mutex}} that can be used with 
> {{[std::lock_guard|http://en.cppreference.com/w/cpp/thread/lock_guard]}}.



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

[jira] [Commented] (GEODE-2604) Add javadocs comments to LuceneIndexMetrics

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2604:


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

GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java


> Add javadocs comments to LuceneIndexMetrics 
> 
>
> Key: GEODE-2604
> URL: https://issues.apache.org/jira/browse/GEODE-2604
> Project: Geode
>  Issue Type: Bug
>Reporter: nabarun
>




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

[jira] [Commented] (GEODE-2552) Replace NanoTimer with std::chrono / std::this_thread::sleep_for

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2552:


Commit e7280b236beaadd9d92712a8c941edae74abe495 in geode-native's branch 
refs/heads/feature/GEODE-2602 from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=e7280b2 ]

GEODE-2552: Replaced NanoTimer with std::chrono.


> Replace NanoTimer with std::chrono / std::this_thread::sleep_for
> 
>
> Key: GEODE-2552
> URL: https://issues.apache.org/jira/browse/GEODE-2552
> Project: Geode
>  Issue Type: Task
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> Replace `NanoTimer` with `std::chrono` / `std::this_thread::sleep_for`



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

[jira] [Commented] (GEODE-2494) Replace SpinLock class with C++11 style BasicLockable class, spinlock_mutex.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2494:


Commit eb4fd82cba5ab0a664a880c32b8c7f6e16dbeb23 in geode-native's branch 
refs/heads/feature/GEODE-2602 from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=eb4fd82 ]

GEODE-2494: Replace global statics with class scoped statics.


> Replace SpinLock class with C++11 style BasicLockable class, spinlock_mutex.
> 
>
> Key: GEODE-2494
> URL: https://issues.apache.org/jira/browse/GEODE-2494
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> Replace {{SpinLock}} class with C++11 style 
> {{[BasicLockable|http://en.cppreference.com/w/cpp/concept/BasicLockable]}} 
> class, {{spinlock_mutex}}. You can find several public domain examples of how 
> to implement a {{spinlock_mutex}} that can be used with 
> {{[std::lock_guard|http://en.cppreference.com/w/cpp/thread/lock_guard]}}.



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

[jira] [Commented] (GEODE-2494) Replace SpinLock class with C++11 style BasicLockable class, spinlock_mutex.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2494:


Commit a3d90c10acf026044fde86ff31007c92b3d3773e in geode-native's branch 
refs/heads/feature/GEODE-2602 from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=a3d90c1 ]

GEODE-2494: Remove dead code.


> Replace SpinLock class with C++11 style BasicLockable class, spinlock_mutex.
> 
>
> Key: GEODE-2494
> URL: https://issues.apache.org/jira/browse/GEODE-2494
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> Replace {{SpinLock}} class with C++11 style 
> {{[BasicLockable|http://en.cppreference.com/w/cpp/concept/BasicLockable]}} 
> class, {{spinlock_mutex}}. You can find several public domain examples of how 
> to implement a {{spinlock_mutex}} that can be used with 
> {{[std::lock_guard|http://en.cppreference.com/w/cpp/thread/lock_guard]}}.



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

[jira] [Commented] (GEODE-2531) Replace HostAsm::atomic* and AtomicInc with std::atomic

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2531:


Commit 3eaf10c8a385b4c86a81cbb87c9913854a004cc3 in geode-native's branch 
refs/heads/feature/GEODE-2602 from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=3eaf10c ]

GEODE-2531: Replace HostAsm::atomic with std::atomic.


> Replace HostAsm::atomic* and AtomicInc with std::atomic
> ---
>
> Key: GEODE-2531
> URL: https://issues.apache.org/jira/browse/GEODE-2531
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> Replace {{HostAsm::atomic*}} and {{AtomicInc}} with 
> {{[std::atomic|http://en.cppreference.com/w/cpp/atomic/atomic]}}.



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

[jira] [Commented] (GEODE-2494) Replace SpinLock class with C++11 style BasicLockable class, spinlock_mutex.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2494:


Commit ce512697330d3ce7d052bbeba2110f48c56a12b3 in geode-native's branch 
refs/heads/feature/GEODE-2602 from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=ce51269 ]

GEODE-2494: Fixes missing include for strlen.


> Replace SpinLock class with C++11 style BasicLockable class, spinlock_mutex.
> 
>
> Key: GEODE-2494
> URL: https://issues.apache.org/jira/browse/GEODE-2494
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> Replace {{SpinLock}} class with C++11 style 
> {{[BasicLockable|http://en.cppreference.com/w/cpp/concept/BasicLockable]}} 
> class, {{spinlock_mutex}}. You can find several public domain examples of how 
> to implement a {{spinlock_mutex}} that can be used with 
> {{[std::lock_guard|http://en.cppreference.com/w/cpp/thread/lock_guard]}}.



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

[jira] [Commented] (GEODE-2552) Replace NanoTimer with std::chrono / std::this_thread::sleep_for

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2552:


Commit c79cb05b065099f0015025eadd179c790cb4cd47 in geode-native's branch 
refs/heads/feature/GEODE-2602 from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=c79cb05 ]

GEODE-2552: Removed NanoTimer

- Replaced millisleep with std::this_thread::sleep_for.


> Replace NanoTimer with std::chrono / std::this_thread::sleep_for
> 
>
> Key: GEODE-2552
> URL: https://issues.apache.org/jira/browse/GEODE-2552
> Project: Geode
>  Issue Type: Task
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> Replace `NanoTimer` with `std::chrono` / `std::this_thread::sleep_for`



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

[jira] [Commented] (GEODE-2604) Add javadocs comments to LuceneIndexMetrics

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2604:


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

GEODE-2604: Added measurement units to the javadoc comments

This closes #415


> Add javadocs comments to LuceneIndexMetrics 
> 
>
> Key: GEODE-2604
> URL: https://issues.apache.org/jira/browse/GEODE-2604
> Project: Geode
>  Issue Type: Bug
>Reporter: nabarun
>




--
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 subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2513:


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

GEODE-2513 Unbrand statistics section of geode-native manual


> 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] [Updated] (GEODE-2602) Resolve C++11 and minimum support compilers discrepancies

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett updated GEODE-2602:

Description: 
Referencing BUILDING.md our target language is C++11 and we state:
{noformat}
### Required Tools
* C++11 compiler *(see platform specific requirements)*
{noformat}

The problem is that our platform specific requirements do not meet the minimum 
standards for C++11 compilers. 

*Linux - GCC 4.8.1+*
https://gcc.gnu.org/projects/cxx-status.html#cxx11
Our Travis CI compiles on Linux using GCC 4.9.1.
_Current listed minimum, 4.6,  does not support many of the C++11 features 
currently in our source._

*MacOS X - clang 3.3+*
https://clang.llvm.org/cxx_status.html

*Solaris - Solaris Studio 12.5+*
https://docs.oracle.com/cd/E60778_01/html/E60746/bkabe.html#OSSCPgnyio
_Currently listed minimum, 12.4, [does not 
support|https://docs.oracle.com/cd/E37069_01/html/E37071/gncix.html#scrolltoc] 
many concurrent features like std::atomic necessary to remove platform specific 
concurrency code._

*Windows - Visual Studio 2015*
https://msdn.microsoft.com/en-us/library/hh567368(v=vs.140).aspx
_Currently listed minimum, 2013, does not support many of the C++11 features, 
like std::atomic_flag, necessary to remove platform specific concurrency code._

  was:
Referencing BUILDING.md our target language is C++11 and we state:
{noformat}
### Required Tools
* C++11 compiler *(see platform specific requirements)*
{noformat}

The problem is that our platform specific requirements do not meet the minimum 
standards for C++11 compilers. 

*Linux - GCC 4.8.1+*
https://gcc.gnu.org/projects/cxx-status.html#cxx11
Our Travis CI compiles on Linux using GCC 4.9.1.
_Current listed minimum, 4.6,  does not support many of the C++11 features 
currently in our source._

*MacOS X - clang 3.3+*
https://clang.llvm.org/cxx_status.html

*Solaris - Solaris Studio 12.5+*
https://docs.oracle.com/cd/E60778_01/html/E60746/bkabe.html#OSSCPgnyio
_Currently listed minimum, 12.4, [does not 
support|https://docs.oracle.com/cd/E37069_01/html/E37071/gncix.html#scrolltoc] 
many concurrent features like std::atomic necessary to remove platform specific 
concurrency code._

*Windows - Visual Studio 2015*
https://msdn.microsoft.com/en-us/library/hh567368(v=vs.140).aspx
_Currently listed minimum, 2013, does not support many of the C++11 features 
necessary necessary to remove platform specific concurrency code._


> Resolve C++11 and minimum support compilers discrepancies
> -
>
> Key: GEODE-2602
> URL: https://issues.apache.org/jira/browse/GEODE-2602
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>
> Referencing BUILDING.md our target language is C++11 and we state:
> {noformat}
> ### Required Tools
> * C++11 compiler *(see platform specific requirements)*
> {noformat}
> The problem is that our platform specific requirements do not meet the 
> minimum standards for C++11 compilers. 
> *Linux - GCC 4.8.1+*
> https://gcc.gnu.org/projects/cxx-status.html#cxx11
> Our Travis CI compiles on Linux using GCC 4.9.1.
> _Current listed minimum, 4.6,  does not support many of the C++11 features 
> currently in our source._
> *MacOS X - clang 3.3+*
> https://clang.llvm.org/cxx_status.html
> *Solaris - Solaris Studio 12.5+*
> https://docs.oracle.com/cd/E60778_01/html/E60746/bkabe.html#OSSCPgnyio
> _Currently listed minimum, 12.4, [does not 
> support|https://docs.oracle.com/cd/E37069_01/html/E37071/gncix.html#scrolltoc]
>  many concurrent features like std::atomic necessary to remove platform 
> specific concurrency code._
> *Windows - Visual Studio 2015*
> https://msdn.microsoft.com/en-us/library/hh567368(v=vs.140).aspx
> _Currently listed minimum, 2013, does not support many of the C++11 features, 
> like std::atomic_flag, necessary to remove platform specific concurrency 
> code._



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

[jira] [Commented] (GEODE-2604) Add javadocs comments to LuceneIndexMetrics

[ASF GitHub Bot (JIRA)]

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

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

GitHub user nabarunnag opened a pull request:

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

GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java

@upthewaterspout @jhuynh1 @gesterzhou @boglesby @ladyVader 

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

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2604

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

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


commit 9d597dce47c3f9edc52cab0b70d9ca912a0c94d2
Author: nabarun 
Date:   2017-03-07T00:51:01Z

GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java




> Add javadocs comments to LuceneIndexMetrics 
> 
>
> Key: GEODE-2604
> URL: https://issues.apache.org/jira/browse/GEODE-2604
> Project: Geode
>  Issue Type: Bug
>Reporter: nabarun
>




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

[GitHub] geode pull request #415: GEODE-2604: Added javadoc comments to LuceneIndexMe...

[nabarunnag]

GitHub user nabarunnag opened a pull request:

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

GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java

@upthewaterspout @jhuynh1 @gesterzhou @boglesby @ladyVader 

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

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2604

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

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


commit 9d597dce47c3f9edc52cab0b70d9ca912a0c94d2
Author: nabarun 
Date:   2017-03-07T00:51:01Z

GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java




---
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] [Resolved] (GEODE-2596) Moving LuceneIndexMetrics and LuceneServiceMXBean to public API

[nabarun (JIRA)]

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

nabarun resolved GEODE-2596.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Moving LuceneIndexMetrics and LuceneServiceMXBean to public API
> ---
>
> Key: GEODE-2596
> URL: https://issues.apache.org/jira/browse/GEODE-2596
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>Assignee: nabarun
> Fix For: 1.2.0
>
>
> These classes should be part of the public API, so people and monitor lucene 
> indexes with JMX. They probably should go to 
> org.apache.geode.lucene.management.



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

[jira] [Commented] (GEODE-2596) Moving LuceneIndexMetrics and LuceneServiceMXBean to public API

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2596:


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

GEODE-2596: Lucene metrics moved to public API

* LuceneIndexMetrics and LuceneServiceMXBean were moved to 
org.apache.geode.cache.lucene.management
* They are now public API

This closes #414


> Moving LuceneIndexMetrics and LuceneServiceMXBean to public API
> ---
>
> Key: GEODE-2596
> URL: https://issues.apache.org/jira/browse/GEODE-2596
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>Assignee: nabarun
>
> These classes should be part of the public API, so people and monitor lucene 
> indexes with JMX. They probably should go to 
> org.apache.geode.lucene.management.



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

[jira] [Commented] (GEODE-2596) Moving LuceneIndexMetrics and LuceneServiceMXBean to public API

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Moving LuceneIndexMetrics and LuceneServiceMXBean to public API
> ---
>
> Key: GEODE-2596
> URL: https://issues.apache.org/jira/browse/GEODE-2596
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>Assignee: nabarun
>
> These classes should be part of the public API, so people and monitor lucene 
> indexes with JMX. They probably should go to 
> org.apache.geode.lucene.management.



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

[GitHub] geode pull request #414: GEODE-2596: Lucene metrics moved to public API

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2604) Add javadocs comments to LuceneIndexMetrics

[nabarun (JIRA)]

nabarun created GEODE-2604:
--

 Summary: Add javadocs comments to LuceneIndexMetrics 
 Key: GEODE-2604
 URL: https://issues.apache.org/jira/browse/GEODE-2604
 Project: Geode
  Issue Type: Bug
Reporter: nabarun






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

Re: Building geode-native for release

[Anthony Baker]

> On Mar 6, 2017, at 10:29 AM, Jacob Barrett  wrote:
> 
> On Mon, Mar 6, 2017 at 9:56 AM Anthony Baker  wrote:
> 
> - The distributions don’t include the version in the top-level directory.
> We should include that.
> 
> I believe you are looking for `make package_source`. No care has been taken
> yet for a src target. Some CMakeList.txt work needs to be tackled. The
> first thing is that the root CMakeLists.txt needs to be moved to the root
> of the repo. In fact the whole src directory is probably ready to be moved
> to the root. It was under a sub directory for migration purposes only.
> 
> 

I’d prefer the top-level directory in the archives to be named something like 
'apache-geode-native-1.2.0-Linux-x64bit' instead of ‘apache-geode-native’.  Is 
that hard in cmake?

> - It looks like src/cppcache/src/version.cmake.in relies on the presence of
> a git repo.  That will not be present for a source release, see [1].
> 
> 
> This should be easy to change to fallback to something if .git is not
> found. It currently pulls the revisions SHA out of the repo. Personally I
> think that is silly and we should just remove it altogether. The other
> option is that a src distribution would just ship version.h and not cmake
> bits to determine it.
> 

Is version.h dumped to the log anywhere?  That info can be really useful.

> 
> We also need to generate signatures and hashes for each of the distribution
> artifacts.  How hard is that to do in cmake?  Should we just create a
> simple gradle wrapper script to do this so we have a common release toolset
> across geode, geode-examples, and geode-native?
> 
> 
> I really dislike having yet another build tool. CMake 3.7.2 and newer
> supports hashing directly in CPack. Older versions of CMake support hashing
> directly in the FILE command.
> Signatures are easy enough to achieve with a custom target call to openssl
> or pgp.

Ok, sounds good.


Anthony

[GitHub] geode-native pull request #46: GEODE-2603 Docs: geode-native user guide >> S...

[davebarnes97]

GitHub user davebarnes97 opened a pull request:

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

GEODE-2603 Docs: geode-native user guide >> Security >> SSL setup nee…

…ds update

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

$ git pull https://github.com/davebarnes97/geode-native feature/GEODE-2603

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

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


commit 6b73495fd355f3ef730185eb78b7a343b2196510
Author: Dave Barnes 
Date:   2017-03-06T23:45:33Z

GEODE-2603 Docs: geode-native user guide >> Security >> SSL setup needs 
update




---
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: Building geode-native for release

[Anthony Baker]

I believe there are some differences between these schemas (not to say that we 
should fix that over time).

Anthony

> On Mar 6, 2017, at 11:46 AM, Michael William Dodge  wrote:
> 
> Can we not just use http://geode.apache.org/schema/cache/cache-1.0.xsd 
>  which is already there?
> 
> Sarge
> 
>> On 6 Mar, 2017, at 09:56, Anthony Baker  wrote:
>> 
>> 2) Schema
>> 
>> We need to move gfcpp-cache-9.0.xsd to http://geode.apache.org/schema 
>> .
> 

[jira] [Commented] (GEODE-2539) Upgrading Jetty causes RestSecurityIntegrationTest to fail

[Kevin Duling (JIRA)]

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

Kevin Duling commented on GEODE-2539:
-

Upgrading to 9.4.2.v20170220 causes an assertion failure because 
application/json;charset=utf-8 is now all lower case.


> Upgrading Jetty causes RestSecurityIntegrationTest to fail
> --
>
> Key: GEODE-2539
> URL: https://issues.apache.org/jira/browse/GEODE-2539
> Project: Geode
>  Issue Type: Bug
>  Components: rest (admin), security, tests
>Reporter: Kirk Lund
>Assignee: Kevin Duling
>
> Upgrading our jetty dependency in gradle/dependency-versions.properties:
> -jetty.version = 9.3.6.v20151106
> +jetty.version = 9.4.0.v20161208
> Causes these RestSecurityIntegrationTest tests to fail (possibly 
> intermittently):
> {noformat}
> :geode-assembly:integrationTest
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > headRegion 
> FAILED
> org.apache.http.NoHttpResponseException: localhost:21423 failed to respond
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doHEAD(GeodeRestClient.java:104)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.headRegion(RestSecurityIntegrationTest.java:246)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > testServers 
> FAILED
> org.apache.http.client.ClientProtocolException
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doGet(GeodeRestClient.java:125)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.testServers(RestSecurityIntegrationTest.java:165)
> Caused by:
> org.apache.http.ProtocolException: The server failed to respond with 
> a valid HTTP response
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:151)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> ... 4 more
> 38 tests completed, 2 failed
> 

[jira] [Created] (GEODE-2603) Docs: geode-native user guide >> Security >> SSL setup needs update

[Dave Barnes (JIRA)]

Dave Barnes created GEODE-2603:
--

 Summary: Docs: geode-native user guide >> Security >> SSL setup 
needs update
 Key: GEODE-2603
 URL: https://issues.apache.org/jira/browse/GEODE-2603
 Project: Geode
  Issue Type: Improvement
  Components: docs
Reporter: Dave Barnes


Update SSL setup to refer to OpenSSL's own installation procedures.



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

[jira] [Assigned] (GEODE-2603) Docs: geode-native user guide >> Security >> SSL setup needs update

[Dave Barnes (JIRA)]

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

Dave Barnes reassigned GEODE-2603:
--

Assignee: Dave Barnes

> Docs: geode-native user guide >> Security >> SSL setup needs update
> ---
>
> Key: GEODE-2603
> URL: https://issues.apache.org/jira/browse/GEODE-2603
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Update SSL setup to refer to OpenSSL's own installation procedures.



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

[jira] [Assigned] (GEODE-2539) Upgrading Jetty causes RestSecurityIntegrationTest to fail

[Kevin Duling (JIRA)]

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

Kevin Duling reassigned GEODE-2539:
---

Assignee: Kevin Duling

> Upgrading Jetty causes RestSecurityIntegrationTest to fail
> --
>
> Key: GEODE-2539
> URL: https://issues.apache.org/jira/browse/GEODE-2539
> Project: Geode
>  Issue Type: Bug
>  Components: rest (admin), security, tests
>Reporter: Kirk Lund
>Assignee: Kevin Duling
>
> Upgrading our jetty dependency in gradle/dependency-versions.properties:
> -jetty.version = 9.3.6.v20151106
> +jetty.version = 9.4.0.v20161208
> Causes these RestSecurityIntegrationTest tests to fail (possibly 
> intermittently):
> {noformat}
> :geode-assembly:integrationTest
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > headRegion 
> FAILED
> org.apache.http.NoHttpResponseException: localhost:21423 failed to respond
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doHEAD(GeodeRestClient.java:104)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.headRegion(RestSecurityIntegrationTest.java:246)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > testServers 
> FAILED
> org.apache.http.client.ClientProtocolException
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doGet(GeodeRestClient.java:125)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.testServers(RestSecurityIntegrationTest.java:165)
> Caused by:
> org.apache.http.ProtocolException: The server failed to respond with 
> a valid HTTP response
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:151)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> ... 4 more
> 38 tests completed, 2 failed
> :geode-assembly:integrationTest FAILED
> {noformat}



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

[jira] [Assigned] (GEODE-2552) Replace NanoTimer with std::chrono / std::this_thread::sleep_for

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett reassigned GEODE-2552:
---

Assignee: Jacob S. Barrett

> Replace NanoTimer with std::chrono / std::this_thread::sleep_for
> 
>
> Key: GEODE-2552
> URL: https://issues.apache.org/jira/browse/GEODE-2552
> Project: Geode
>  Issue Type: Task
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> Replace `NanoTimer` with `std::chrono` / `std::this_thread::sleep_for`



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

[jira] [Updated] (GEODE-2602) Resolve C++11 and minimum support compilers discrepancies

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett updated GEODE-2602:

Description: 
Referencing BUILDING.md our target language is C++11 and we state:
{noformat}
### Required Tools
* C++11 compiler *(see platform specific requirements)*
{noformat}

The problem is that our platform specific requirements do not meet the minimum 
standards for C++11 compilers. 

*Linux - GCC 4.8.1+*
https://gcc.gnu.org/projects/cxx-status.html#cxx11
Our Travis CI compiles on Linux using GCC 4.9.1.
_Current listed minimum, 4.6,  does not support many of the C++11 features 
currently in our source._

*MacOS X - clang 3.3+*
https://clang.llvm.org/cxx_status.html

*Solaris - Solaris Studio 12.5+*
https://docs.oracle.com/cd/E60778_01/html/E60746/bkabe.html#OSSCPgnyio
_Currently listed minimum, 12.4, [does not 
support|https://docs.oracle.com/cd/E37069_01/html/E37071/gncix.html#scrolltoc] 
many concurrent features like std::atomic necessary to remove platform specific 
concurrency code._

*Windows - Visual Studio 2015*
https://msdn.microsoft.com/en-us/library/hh567368(v=vs.140).aspx
_Currently listed minimum, 2013, does not support many of the C++11 features 
necessary necessary to remove platform specific concurrency code._

  was:
Referencing BUILDING.md our target language is C++11 and we state:
{noformat}
### Required Tools
* C++11 compiler *(see platform specific requirements)*
{noformat}

The problem is that our platform specific requirements do not meet the minimum 
standards for C++11 compilers. 

*Linux - GCC 4.8.1+*
https://gcc.gnu.org/projects/cxx-status.html#cxx11
Our Travis CI compiles on Linux using GCC 4.9.1.
_Current listed minimum, 4.6,  does not support many of the C++11 features 
currently in our source._

*MacOS X - clang 3.3+*
https://clang.llvm.org/cxx_status.html

*Solaris - Solaris Studio 12.5+*
https://docs.oracle.com/cd/E60778_01/html/E60746/bkabe.html#OSSCPgnyio
_Currently listed minimum, 12.4, [does not 
support|https://docs.oracle.com/cd/E37069_01/html/E37071/gncix.html#scrolltoc] 
many concurrent features like std::atomic necessary to remove platform specific 
concurrency code._

Windows - Visual Studio 2015
https://msdn.microsoft.com/en-us/library/hh567368(v=vs.140).aspx



> Resolve C++11 and minimum support compilers discrepancies
> -
>
> Key: GEODE-2602
> URL: https://issues.apache.org/jira/browse/GEODE-2602
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>
> Referencing BUILDING.md our target language is C++11 and we state:
> {noformat}
> ### Required Tools
> * C++11 compiler *(see platform specific requirements)*
> {noformat}
> The problem is that our platform specific requirements do not meet the 
> minimum standards for C++11 compilers. 
> *Linux - GCC 4.8.1+*
> https://gcc.gnu.org/projects/cxx-status.html#cxx11
> Our Travis CI compiles on Linux using GCC 4.9.1.
> _Current listed minimum, 4.6,  does not support many of the C++11 features 
> currently in our source._
> *MacOS X - clang 3.3+*
> https://clang.llvm.org/cxx_status.html
> *Solaris - Solaris Studio 12.5+*
> https://docs.oracle.com/cd/E60778_01/html/E60746/bkabe.html#OSSCPgnyio
> _Currently listed minimum, 12.4, [does not 
> support|https://docs.oracle.com/cd/E37069_01/html/E37071/gncix.html#scrolltoc]
>  many concurrent features like std::atomic necessary to remove platform 
> specific concurrency code._
> *Windows - Visual Studio 2015*
> https://msdn.microsoft.com/en-us/library/hh567368(v=vs.140).aspx
> _Currently listed minimum, 2013, does not support many of the C++11 features 
> necessary necessary to remove platform specific concurrency code._



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

[jira] [Created] (GEODE-2602) Resolve C++11 and minimum support compilers discrepancies

[Jacob S. Barrett (JIRA)]

Jacob S. Barrett created GEODE-2602:
---

 Summary: Resolve C++11 and minimum support compilers discrepancies
 Key: GEODE-2602
 URL: https://issues.apache.org/jira/browse/GEODE-2602
 Project: Geode
  Issue Type: Task
  Components: native client
Reporter: Jacob S. Barrett


Referencing BUILDING.md our target language is C++11 and we state:
{noformat}
### Required Tools
* C++11 compiler *(see platform specific requirements)*
{noformat}

The problem is that our platform specific requirements do not meet the minimum 
standards for C++11 compilers. 

*Linux - GCC 4.8.1+*
https://gcc.gnu.org/projects/cxx-status.html#cxx11
Our Travis CI compiles on Linux using GCC 4.9.1.
_Current listed minimum, 4.6,  does not support many of the C++11 features 
currently in our source._

*MacOS X - clang 3.3+*
https://clang.llvm.org/cxx_status.html

*Solaris - Solaris Studio 12.5+*
https://docs.oracle.com/cd/E60778_01/html/E60746/bkabe.html#OSSCPgnyio
_Currently listed minimum, 12.4, [does not 
support|https://docs.oracle.com/cd/E37069_01/html/E37071/gncix.html#scrolltoc] 
many concurrent features like std::atomic necessary to remove platform specific 
concurrency code._

Windows - Visual Studio 2015
https://msdn.microsoft.com/en-us/library/hh567368(v=vs.140).aspx




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

Re: [GitHub] geode pull request #404: Geode 2469

[Wes Williams]

And correcting the spelling of "SEPERATOR" would be a plus while changing
the code.

*Wes Williams | Pivotal Advisory **Data Engineer*
781.606.0325
http://pivotal.io/big-data/pivotal-gemfire

On Mon, Mar 6, 2017 at 6:14 PM, galen-pivotal  wrote:

> Github user galen-pivotal commented on a diff in the pull request:
>
> https://github.com/apache/geode/pull/404#discussion_r104549703
>
> --- Diff: geode-core/src/main/java/org/apache/geode/redis/internal/
> executor/hash/HashInterpreter.java ---
> @@ -0,0 +1,126 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> contributor license
> + * agreements. See the NOTICE file distributed with this work for
> additional information regarding
> + * copyright ownership. The ASF licenses this file to You under the
> Apache License, Version 2.0 (the
> + * "License"); you may not use this file except in compliance with
> the License. You may obtain a
> + * copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing,
> software distributed under the License
> + * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR
> CONDITIONS OF ANY KIND, either express
> + * or implied. See the License for the specific language governing
> permissions and limitations under
> + * the License.
> + */
> +package org.apache.geode.redis.internal.executor.hash;
> +
> +import java.util.Map;
> +
> +import org.apache.geode.cache.Region;
> +import org.apache.geode.redis.GeodeRedisServer;
> +import org.apache.geode.redis.internal.ByteArrayWrapper;
> +import org.apache.geode.redis.internal.Coder;
> +import org.apache.geode.redis.internal.ExecutionHandlerContext;
> +import org.apache.geode.redis.internal.RedisDataType;
> +
> +/**
> + * Utility class for interpreting and processing Redis Hash data
> structure
> + *
> + *
> + */
> +public class HashInterpreter {
> +
> +  /**
> +   * 
> +   * The region:key separator.
> +   *
> +   *  REGION_KEY_SEPERATOR = ":"
> +   *
> +   * See Hash section of  +  "https://redis.io/topics/data-types;>https://redis.io/
> topics/data-types#Hashes
> +   * 
> +   */
> +  public static final String REGION_KEY_SEPERATOR = ":";
> +
> +  /**
> +   * The default hash region name REGION_HASH_REGION = Coder.
> stringToByteArrayWrapper("ReDiS_HASH")
> +   */
> +  public static final ByteArrayWrapper REGION_HASH_REGION =
> +  Coder.stringToByteArrayWrapper(GeodeRedisServer.HASH_REGION);
> +
> +  /**
> +   * Return the region presenting the hash
> +   *
> +   * @param key the raw Redis command key that may contain the
> region:key formation
> +   * @param context the exception handler context
> +   * @return the region were the command's data will be processed
> +   */
> +  @SuppressWarnings("unchecked")
> +  public static Region ByteArrayWrapper>> getRegion(
> --- End diff --
>
> @ggreen yeah, I'd put everything in one region because I think it's
> easier to understand, and because it's much cheaper to create new hash
> objects in a region than it is to create new regions. Though if you want to
> see my hidden agenda, look ahead:
>
> if I were to redesign data storage in the Redis adapter, I think I
> would do away with the separate region per type and a metadata region that
> just stores types, and implement the whole thing as one region that stored
> collections of all the types we support. During the lookup we could catch a
> `ClassCastException` if the key is the wrong type, and then we'd propagate
> that up as the same error Redis throws when you try to modify a key that is
> of the wrong type.
>
> Storing collections as Java objects rather than via some translation
> to a Region means that as the objects get larger, the cost of transferring
> them between members in the system increases as well. Geode contains a
> `Delta` interface that I think we could use to avoid the overhead of
> transferring the whole object every time. Then the only downside is that we
> can't scale a single hash/set/list across servers, which I think is fine --
> do you really need to store a list in Redis that takes more than however
> many gigabytes of RAM are in a single Geode instance? Some folks on the
> user/dev lists seem to disagree with this view, though, so take it with a
> bit of salt.
>
> The other thing I'd like to look at to implement this is how we want
> to store and process data -- the whole `ByteArrayWrapper`/`String` thing
> could be simplified, but I think that's fairly orthogonal to the region and
> command interpreter implementation.
>
> I don't know that much about the end users of Redis, though, so I'm
> curious: what 

[jira] [Created] (GEODE-2601) Banner is logged twice during locator startup

[Patrick Rhomberg (JIRA)]

Patrick Rhomberg created GEODE-2601:
---

 Summary: Banner is logged twice during locator startup
 Key: GEODE-2601
 URL: https://issues.apache.org/jira/browse/GEODE-2601
 Project: Geode
  Issue Type: Bug
  Components: logging
Reporter: Patrick Rhomberg


In locator log file, starting a locator in gfsh yields a log file containing 
"Licensed to the Apache [...]"

First banner ends with:
{noformat}[info 2017/03/06 14:29:29.995 PST loc1  tid=0x1] Starting peer 
location for Distribution Locator on 10.118.33.239{noformat}

Second banner ends with:
{noformat}[info 2017/03/06 14:29:30.160 PST loc1  tid=0x1] Starting 
membership services{noformat}



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

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

[Spring CI]

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

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





--
This message is automatically generated by Atlassian Bamboo

[jira] [Updated] (GEODE-2600) Inconsistent spacing of headers in Startup Configuration log

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg updated GEODE-2600:

Affects Version/s: 1.2.0

> Inconsistent spacing of headers in Startup Configuration log
> 
>
> Key: GEODE-2600
> URL: https://issues.apache.org/jira/browse/GEODE-2600
> Project: Geode
>  Issue Type: Bug
>  Components: logging
>Affects Versions: 1.2.0
>Reporter: Patrick Rhomberg
>
> Note the extra space before the initial ###.
> {noformat}
> [info 2017/03/06 14:29:30.003 PST loc1  tid=0x1] Startup Configuration:
>### GemFire Properties defined with system property ###
>   enable-cluster-configuration=true
>   load-cluster-configuration-from-dir=false
>   ### GemFire Properties defined with api ###
> {noformat}



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

[jira] [Created] (GEODE-2600) Inconsistent spacing of headers in Startup Configuration log

[Patrick Rhomberg (JIRA)]

Patrick Rhomberg created GEODE-2600:
---

 Summary: Inconsistent spacing of headers in Startup Configuration 
log
 Key: GEODE-2600
 URL: https://issues.apache.org/jira/browse/GEODE-2600
 Project: Geode
  Issue Type: Bug
  Components: logging
Reporter: Patrick Rhomberg


Note the extra space before the initial ###.
{noformat}
[info 2017/03/06 14:29:30.003 PST loc1  tid=0x1] Startup Configuration:
   ### GemFire Properties defined with system property ###
  enable-cluster-configuration=true
  load-cluster-configuration-from-dir=false
  ### GemFire Properties defined with api ###
{noformat}



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

[jira] [Updated] (GEODE-2599) `start locator` prints `null` in startup dots.

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg updated GEODE-2599:

Affects Version/s: 1.2.0

> `start locator` prints `null` in startup dots.
> --
>
> Key: GEODE-2599
> URL: https://issues.apache.org/jira/browse/GEODE-2599
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.2.0
>Reporter: Patrick Rhomberg
>  Labels: gfsh
>
> {noformat}
> gfsh>start locator --name=loc1
> Starting a Geode Locator in /Users/prhomberg/workspace/gemfire/open/loc1...
> ..
> null
> .
> Locator in /Users/prhomberg/workspace/gemfire/open/loc1 on 
> 10.118.33.239[10334] as loc1 is currently online.
> Process ID: 41909
> Uptime: 2 seconds
> Geode Version: 0.0.0
> Java Version: 1.8.0_121
> Log File: /Users/prhomberg/workspace/gemfire/open/loc1/loc1.log
> JVM Arguments: -Dgemfire.enable-cluster-configuration=true 
> -Dgemfire.load-cluster-configuration-from-dir=false 
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true 
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path: 
> /Users/prhomberg/workspace/gemfire/open/geode-assembly/build/install/apache-geode/lib/geode-core-0.0.0.jar:/Users/prhomberg/workspace/gemfire/open/geode-assembly/build/install/apache-geode/lib/geode-dependencies.jar
> Successfully connected to: JMX Manager [host=10.118.33.239, port=1099]
> Cluster configuration service is up and running.
> {noformat}



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

[jira] [Created] (GEODE-2599) `start locator` prints `null` in startup dots.

[Patrick Rhomberg (JIRA)]

Patrick Rhomberg created GEODE-2599:
---

 Summary: `start locator` prints `null` in startup dots.
 Key: GEODE-2599
 URL: https://issues.apache.org/jira/browse/GEODE-2599
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Patrick Rhomberg


{noformat}
gfsh>start locator --name=loc1
Starting a Geode Locator in /Users/prhomberg/workspace/gemfire/open/loc1...
..
null
.
Locator in /Users/prhomberg/workspace/gemfire/open/loc1 on 10.118.33.239[10334] 
as loc1 is currently online.
Process ID: 41909
Uptime: 2 seconds
Geode Version: 0.0.0
Java Version: 1.8.0_121
Log File: /Users/prhomberg/workspace/gemfire/open/loc1/loc1.log
JVM Arguments: -Dgemfire.enable-cluster-configuration=true 
-Dgemfire.load-cluster-configuration-from-dir=false 
-Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true 
-Dsun.rmi.dgc.server.gcInterval=9223372036854775806
Class-Path: 
/Users/prhomberg/workspace/gemfire/open/geode-assembly/build/install/apache-geode/lib/geode-core-0.0.0.jar:/Users/prhomberg/workspace/gemfire/open/geode-assembly/build/install/apache-geode/lib/geode-dependencies.jar

Successfully connected to: JMX Manager [host=10.118.33.239, port=1099]

Cluster configuration service is up and running.
{noformat}



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

[jira] [Commented] (GEODE-2488) Netstat command fails with OutOfMemoryError

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2488:


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

GEODE-2488: Remove test from flaky category

Removed FlakyTest category.
Made note of this JIRA in the @Ignore annoations. This annotation can be
removed when the underlying problem (accumulating large repsonse data on
remote casuing OOME) is fixed.


> Netstat command fails with OutOfMemoryError
> ---
>
> Key: GEODE-2488
> URL: https://issues.apache.org/jira/browse/GEODE-2488
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Reporter: Kirk Lund
>Assignee: Kenneth Howe
>  Labels: MiscellaneousCommands, NetstatCommand, netstat
>
> Note: this can occur outside of dunit tests as well. Just using the gfsh 
> netstat command on locator or server with too little heap space will hit 
> this. See the 1st comment about not streaming the netstat output -- the 
> entire output is held in memory in a string and two byte arrays before 
> sending the result back from NetstatFunction.
> The JUnit controller JVM for NetstatDUnitTest fails with something like the 
> follow stack. The cause appears to be one of the DUnit VMs running out of 
> memory (see the OOME stack down further in this description.
> {noformat}
> org.junit.ComparisonFailure: [{"errorCode":505,"message":["Could not process 
> command due to GemFire error. Error occurred while executing netstat on 
> [server-1]"]}] expected:<[OK]> but was:<[ERROR]>
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at 
> org.apache.geode.test.dunit.rules.GfshShellConnectionRule.executeAndVerifyCommand(GfshShellConnectionRule.java:163)
>   at 
> org.apache.geode.management.internal.cli.NetstatDUnitTest.testConnectToJmxManagerOne(NetstatDUnitTest.java:81)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:37)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>   at 
> 

[jira] [Commented] (GEODE-2578) Query string limited to 64 KiB

[ASF GitHub Bot (JIRA)]

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

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

Github user PivotalSarge commented on the issue:

https://github.com/apache/geode-native/pull/44
  
The unit tests failed on Linux but not other platforms. It turns out that 
DataOutput has some not-very-obvious (and apparently platform-specific) 
behavior around buffer management that results in the return values from 
getBufferLength() and getRemainingBufferLength() depending on the behavior of 
other unit tests that may precede them. Hence, the test of ginormous query 
strings was causing the return values of those methods to differ from what 
would be returned if that test was *not* run. So I reworked how the DataOutput 
cursor advancement unit tests work and created GEODE-2598 to understand and 
test how DataOutput's buffer management works.


> Query string limited to 64 KiB
> --
>
> Key: GEODE-2578
> URL: https://issues.apache.org/jira/browse/GEODE-2578
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> The serialization of query strings uses a 16-bit unsigned integer to 
> represent the length of the query string. Query strings with more than 65535 
> characters are silently truncated. Use of a 32-bit unsigned integer to 
> represent the length would greatly increase the size of query strings that 
> may be used.



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

[GitHub] geode-native issue #44: GEODE-2578: Remove 64 KiB limit on query strings.

[PivotalSarge]

Github user PivotalSarge commented on the issue:

https://github.com/apache/geode-native/pull/44
  
The unit tests failed on Linux but not other platforms. It turns out that 
DataOutput has some not-very-obvious (and apparently platform-specific) 
behavior around buffer management that results in the return values from 
getBufferLength() and getRemainingBufferLength() depending on the behavior of 
other unit tests that may precede them. Hence, the test of ginormous query 
strings was causing the return values of those methods to differ from what 
would be returned if that test was *not* run. So I reworked how the DataOutput 
cursor advancement unit tests work and created GEODE-2598 to understand and 
test how DataOutput's buffer management works.


---
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-2598) Verify buffer allocation behavior of apache::geode::client::DataOutput

[Michael Dodge (JIRA)]

Michael Dodge created GEODE-2598:


 Summary: Verify buffer allocation behavior of 
apache::geode::client::DataOutput
 Key: GEODE-2598
 URL: https://issues.apache.org/jira/browse/GEODE-2598
 Project: Geode
  Issue Type: Test
  Components: native client
Reporter: Michael Dodge


The class apache::geode::client::DataOutput manages some internal buffers that 
contribute to the return values of getBufferLength() and 
getRemainingBufferLength(). The behavior appears to differ between platforms 
and is not immediately obvious from external observation. This behavior should 
be unit-tested to ensure that it does not regress.



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

Re: Building geode-native for release

[Jacob Barrett]

That is for the java client. It would be nice if they were the same plus
some platform specific namespaces extensions. Sadly that isn't the case...
yet.
On Mon, Mar 6, 2017 at 11:54 AM Michael William Dodge 
wrote:

> Can we not just use http://geode.apache.org/schema/cache/cache-1.0.xsd <
> http://geode.apache.org/schema/cache/cache-1.0.xsd> which is already
> there?
>
> Sarge
>
> > On 6 Mar, 2017, at 09:56, Anthony Baker  wrote:
> >
> > 2) Schema
> >
> > We need to move gfcpp-cache-9.0.xsd to http://geode.apache.org/schema <
> http://geode.apache.org/schema>.
>
>

Re: Review Request 57345: GEODE-2579: ClassCastException cannot cast CompiledIn to CompiledJunction when querying with a junction containing an in clause

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On March 6, 2017, 7:38 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57345/
> ---
> 
> (Updated March 6, 2017, 7:38 p.m.)
> 
> 
> Review request for geode, nabarun nag and Dan Smith.
> 
> 
> Bugs: GEODE-2579
> https://issues.apache.org/jira/browse/GEODE-2579
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> instanceof check added for CompiledIn.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/AbstractGroupOrRangeJunction.java
>  a499346 
>   geode-core/src/test/java/org/apache/geode/cache/query/QueryJUnitTest.java 
> 7333212 
> 
> 
> Diff: https://reviews.apache.org/r/57345/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

[jira] [Resolved] (GEODE-2571) CacheClosedException during LuceneQueryFunction should be handled with a retry

[Jason Huynh (JIRA)]

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

Jason Huynh resolved GEODE-2571.

   Resolution: Fixed
Fix Version/s: 1.2.0

> CacheClosedException during LuceneQueryFunction should be handled with a retry
> --
>
> Key: GEODE-2571
> URL: https://issues.apache.org/jira/browse/GEODE-2571
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.2.0
>
>
> There are multiple spots in LuceneQueryFunction that can throw a 
> CacheClosedException.  The query function should handle this and allow the 
> function service to retry instead of returning a CacheClosedException to the 
> user.



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

[jira] [Commented] (GEODE-2596) Moving LuceneIndexMetrics and LuceneServiceMXBean to public API

[ASF GitHub Bot (JIRA)]

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

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

GitHub user nabarunnag opened a pull request:

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

GEODE-2596: Lucene metrics moved to public API

* LuceneIndexMetrics and LuceneServiceMXBean were moved to 
org.apache.geode.cache.lucene.management


-- Lucene precheckin passed

@upthewaterspout @jhuynh1 @ladyVader @gesterzhou @boglesby 

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

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2596

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

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


commit f832d15d2b3152b93fb09933a42b90aeae8f92da
Author: nabarun 
Date:   2017-03-06T19:59:33Z

GEODE-2596: Lucene metrics moved to public API

* LuceneIndexMetrics and LuceneServiceMXBean were moved to 
org.apache.geode.cache.lucene.management
* They are now public API




> Moving LuceneIndexMetrics and LuceneServiceMXBean to public API
> ---
>
> Key: GEODE-2596
> URL: https://issues.apache.org/jira/browse/GEODE-2596
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>Assignee: nabarun
>
> These classes should be part of the public API, so people and monitor lucene 
> indexes with JMX. They probably should go to 
> org.apache.geode.lucene.management.



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

[GitHub] geode pull request #414: GEODE-2596: Lucene metrics moved to public API

[nabarunnag]

GitHub user nabarunnag opened a pull request:

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

GEODE-2596: Lucene metrics moved to public API

* LuceneIndexMetrics and LuceneServiceMXBean were moved to 
org.apache.geode.cache.lucene.management


-- Lucene precheckin passed

@upthewaterspout @jhuynh1 @ladyVader @gesterzhou @boglesby 

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

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2596

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

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


commit f832d15d2b3152b93fb09933a42b90aeae8f92da
Author: nabarun 
Date:   2017-03-06T19:59:33Z

GEODE-2596: Lucene metrics moved to public API

* LuceneIndexMetrics and LuceneServiceMXBean were moved to 
org.apache.geode.cache.lucene.management
* They are now public API




---
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: Building geode-native for release

[Michael William Dodge]

Can we not just use http://geode.apache.org/schema/cache/cache-1.0.xsd 
 which is already there?

Sarge

> On 6 Mar, 2017, at 09:56, Anthony Baker  wrote:
> 
> 2) Schema
> 
> We need to move gfcpp-cache-9.0.xsd to http://geode.apache.org/schema 
> .

Re: Gemfire proxy cache race condition bug?

[Darrel Schneider]

This is a known limitation of CacheListeners on a PROXY region. On other
types of regions the local region entry that the operation is modifying is
synchronized during the operation and during the CacheListener invocation.
That is what the javadocs on the CacheListener calls "holding a lock on the
entry." But since a PROXY region has none of its own state it has no local
region entry to hold a lock on. The javadocs should be changed to mention
this. Did you see this in some other place in the docs?

Another thing to keep in mind is that even when the entry is locked during
CacheListener invocation this does not guarantee a total ordering across
the distributed system. In particular the events you receive on a client
are async with those that occur on the server. You best bet is to use a
CacheListener on the server side on a partitioned region. All the modify
ops go through the single primary.

Another odd thing about a PROXY is that "get" will call afterCreate on a
listener on the proxy even when the get was a hit on the server. This is
because our PROXY logic always looks at the local state (not the server
state) when deciding on what CacheListener method to call. Ideally you
would only have "get" deliver afterCreate when the "get" does a load.

On Mon, Mar 6, 2017 at 8:55 AM, Michael Stolz  wrote:

> If you always do whatever processing you are planning to do inside the
> CacheListener and use the "newValue" field that is supplied to that
> callback you will always begin processing in the order the data was
> received. I suppose if you want to ensure that you are completing
> processing in the correct order you would need to synchronize on your
> callback as you said.
>
> To "prime the pump" you can use get as you are now, or registerInterest
> with a list of keys or wildcard on string-based keys. Register interest can
> optionally deliver the initial value followed by all updates in the correct
> order.
>
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771 <(631)%20835-4771>
>
> On Sat, Mar 4, 2017 at 7:58 AM, David Wales 
> wrote:
>
>> Hi there,
>>
>> I have a client proxy cache with an associated cache listener. An
>> invocation of the region get method will trigger the afterCreate callback.
>> I realized this call back was on the same thread that called get and is
>> different to the thread that dispatches the region updates. So I had a
>> look
>> at the code and there seems to be no synchronization. I could mark the
>> cache listener methods as synchronized but this doesn't fully mitigate the
>> race. How does one get the initial state of an entry in a region in a way
>> that synchronizes with updates on. Is this a known limitation or a bug as
>> the documentation talks about cache listener methods being mutually
>> exclusive?
>>
>> Much appreciated
>> Thank you
>> David
>>
>
>

[jira] [Resolved] (GEODE-2597) Redis adapter doesn't handle UTF-8 properly.

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan resolved GEODE-2597.
-
Resolution: Invalid

> Redis adapter doesn't handle UTF-8 properly.
> 
>
> Key: GEODE-2597
> URL: https://issues.apache.org/jira/browse/GEODE-2597
> Project: Geode
>  Issue Type: Sub-task
>  Components: redis
>Reporter: Galen O'Sullivan
>




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

[jira] [Updated] (GEODE-2597) Redis adapter doesn't handle UTF-8 properly.

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan updated GEODE-2597:

Description: 
{code}
127.0.0.1:6379> hset foo å å
(integer) 1
(2.09s)
127.0.0.1:6379> hget foo å
"\xc3\xa5"
{code}

I thought this was inconsistent with the way Redis works, but it doesn't seem 
to be. Probably worth testing before GA.

> Redis adapter doesn't handle UTF-8 properly.
> 
>
> Key: GEODE-2597
> URL: https://issues.apache.org/jira/browse/GEODE-2597
> Project: Geode
>  Issue Type: Sub-task
>  Components: redis
>Reporter: Galen O'Sullivan
>
> {code}
> 127.0.0.1:6379> hset foo å å
> (integer) 1
> (2.09s)
> 127.0.0.1:6379> hget foo å
> "\xc3\xa5"
> {code}
> I thought this was inconsistent with the way Redis works, but it doesn't seem 
> to be. Probably worth testing before GA.



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

[jira] [Created] (GEODE-2597) Redis adapter doesn't handle UTF-8 properly.

[Galen O'Sullivan (JIRA)]

Galen O'Sullivan created GEODE-2597:
---

 Summary: Redis adapter doesn't handle UTF-8 properly.
 Key: GEODE-2597
 URL: https://issues.apache.org/jira/browse/GEODE-2597
 Project: Geode
  Issue Type: Sub-task
Reporter: Galen O'Sullivan






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

Review Request 57345: GEODE-2579: ClassCastException cannot cast CompiledIn to CompiledJunction when querying with a junction containing an in clause

[Jason Huynh]

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

Review request for geode, nabarun nag and Dan Smith.


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


Repository: geode


Description
---

instanceof check added for CompiledIn.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/cache/query/internal/AbstractGroupOrRangeJunction.java
 a499346 
  geode-core/src/test/java/org/apache/geode/cache/query/QueryJUnitTest.java 
7333212 


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


Testing
---

precheckin


Thanks,

Jason Huynh

[jira] [Assigned] (GEODE-2596) Moving LuceneIndexMetrics and LuceneServiceMXBean to public API

[nabarun (JIRA)]

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

nabarun reassigned GEODE-2596:
--

Assignee: nabarun

> Moving LuceneIndexMetrics and LuceneServiceMXBean to public API
> ---
>
> Key: GEODE-2596
> URL: https://issues.apache.org/jira/browse/GEODE-2596
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>Assignee: nabarun
>
> These classes should be part of the public API, so people and monitor lucene 
> indexes with JMX. They probably should go to 
> org.apache.geode.lucene.management.



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

[jira] [Created] (GEODE-2596) Moving LuceneIndexMetrics and LuceneServiceMXBean to public API

[nabarun (JIRA)]

nabarun created GEODE-2596:
--

 Summary: Moving LuceneIndexMetrics and LuceneServiceMXBean to 
public API
 Key: GEODE-2596
 URL: https://issues.apache.org/jira/browse/GEODE-2596
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: nabarun


These classes should be part of the public API, so people and monitor lucene 
indexes with JMX. They probably should go to org.apache.geode.lucene.management.



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

[jira] [Updated] (GEODE-2595) Change LuceneService.createIndex to use a factory pattern

[Dan Smith (JIRA)]

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

Dan Smith updated GEODE-2595:
-
Issue Type: Improvement  (was: Bug)

> Change LuceneService.createIndex to use a factory pattern
> -
>
> Key: GEODE-2595
> URL: https://issues.apache.org/jira/browse/GEODE-2595
> Project: Geode
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Dan Smith
>
> Before we remove the Experimental annotation from the LuceneService, we 
> should change createIndex to use a factory pattern rather than having a 
> single method with parameters to create the index. In other words, the method 
> needs to change from:
> {code}
> luceneService.createIndex(region, index, ...)
> {code}
> to
> {code}
> luceneService.createIndexFactory()
>   .setXXX()
>   .setYYY()
>   .create()
> {code}
> This will allow us to add additional set methods in the future to configure 
> other things like the async event queue batch size, etc.



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

[jira] [Created] (GEODE-2595) Change LuceneService.createIndex to use a factory pattern

[Dan Smith (JIRA)]

Dan Smith created GEODE-2595:


 Summary: Change LuceneService.createIndex to use a factory pattern
 Key: GEODE-2595
 URL: https://issues.apache.org/jira/browse/GEODE-2595
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Dan Smith


Before we remove the Experimental annotation from the LuceneService, we should 
change createIndex to use a factory pattern rather than having a single method 
with parameters to create the index. In other words, the method needs to change 
from:

{code}
luceneService.createIndex(region, index, ...)
{code}
to
{code}
luceneService.createIndexFactory()
  .setXXX()
  .setYYY()
  .create()
{code}

This will allow us to add additional set methods in the future to configure 
other things like the async event queue batch size, etc.




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

[jira] [Resolved] (GEODE-2588) OQL's ORDER BY takes 13x (1300%) more time compared to plain java sort for the same amount of data and same resources

[nabarun (JIRA)]

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

nabarun resolved GEODE-2588.

Resolution: Duplicate

> OQL's ORDER BY takes 13x (1300%) more time compared to plain java sort for 
> the same amount of data and same resources
> -
>
> Key: GEODE-2588
> URL: https://issues.apache.org/jira/browse/GEODE-2588
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Christian Tzolov
> Attachments: flight_recording_OQL_ORDER_BY.jfr, 
> gemfire_OQL_ORDER_BY.log, 
> gemfire-oql-orderby-vs-on-client-sort-test-cases.zip, 
> myStats_OQL_ORDER_BY.gfs, oql_with_order_by_hot_methods.png
>
>
> For Partition Region with 1 500 000 entries running on a single Geode member.
> The OQL query *SELECT DISTINCT a, b FROM /region ORDER BY b* takes *13x* 
> times (*1300%*) more time compared to OQL *SELECT a, b FROM /region* +  
> manual Java sort of the result for the same dataset.
> Setup: Geode 1.0.0 with Partition region with 1 500 000 objects, 4GB memory
> 1. OQL with DISTINCT/ORDER BY
> {code}SELECT DISTINCT e.key,e.day FROM /partitionRegion e ORDER BY e.day{code}
> OQL execution time: 64899 ms = *~65 sec*
> 2. OQL with manual sort
> {code}SELECT e.key,e.day FROM /partitionRegion e{code}
> and then
> {code}
> //OQL all -> 3058 ms
> SelectResults result = (SelectResults) query.execute(bindings);
> //Client-side sort -> 1830 ms
> List result2 = (List) result.asList().parallelStream().sorted((o1, o2) 
> -> {
> Struct st1 = (Struct) o1;
> Struct st2 = (Struct) o2;
> return ((Date) st1.get("day")).compareTo((Date) st2.get("day"));
> }).collect(toList());
> {code}
> OQL execution time: 3058 ms,
> Client-side sort time: 1830 ms
> Total time: 4888 ms = *~5 sec*
> Attached [^gemfire-oql-orderby-vs-on-client-sort-test-cases.zip] can demo the 
> problem (check the comments below).
> Attached are also the JMC profiler [^flight_recording_OQL_ORDER_BY.jfr], logs 
> and vsd stats
> The profiler suggests that most  of the CPU goes to the 
> *OrderByComparator#evaluateSortCriteria* method:
> !oql_with_order_by_hot_methods.png!



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

Re: Export Control for Geode

[Anthony Baker]

Thanks Mark!  Let me know if you have any questions.

Anthony

> On Mar 6, 2017, at 10:32 AM, Mark Bretl  wrote:
> 
> Looks good. Unless there are any other comments/issues, I will start this
> tomorrow.
> 
> --Mark
> 
> On Thu, Mar 2, 2017 at 10:29 PM, Anthony Baker  wrote:
> 
>> After reviewing [1], I think we need to record and report our use of
>> cryptographic libraries that fall under US export control.
>> 
>> This means:
>> 
>> 1) Updating the eccnmatrix.xml [2] in svn and publishing the change [3].
>> 2) Sending an email [4].
>> 3) Updating README.md [5].
>> 
>> Mark, #1 and #2 need to be done by the PMC Chair.  Can you review this
>> and let me know what you think?  I can tackle #3 after.
>> 
>> Thanks,
>> Anthony
>> 
>> [1] http://www.apache.org/dev/crypto.html
>> [2] https://gist.github.com/metatype/96da9d928f20d5ae638cc16dd4ee9a85
>> [3] https://cms.apache.org/www/publish
>> [4] https://gist.github.com/metatype/24b4462af6319cbf568b63ad3a56464e
>> [5] https://gist.githubusercontent.com/metatype/
>> b50b49a4c2a7a99793029b3ea0cde8c3/raw/40aca011a65c12d6fbec73fce60f57
>> f43323d36f/README.md
>> 

Re: Export Control for Geode

[Mark Bretl]

Looks good. Unless there are any other comments/issues, I will start this
tomorrow.

--Mark

On Thu, Mar 2, 2017 at 10:29 PM, Anthony Baker  wrote:

> After reviewing [1], I think we need to record and report our use of
> cryptographic libraries that fall under US export control.
>
> This means:
>
> 1) Updating the eccnmatrix.xml [2] in svn and publishing the change [3].
> 2) Sending an email [4].
> 3) Updating README.md [5].
>
> Mark, #1 and #2 need to be done by the PMC Chair.  Can you review this
> and let me know what you think?  I can tackle #3 after.
>
> Thanks,
> Anthony
>
> [1] http://www.apache.org/dev/crypto.html
> [2] https://gist.github.com/metatype/96da9d928f20d5ae638cc16dd4ee9a85
> [3] https://cms.apache.org/www/publish
> [4] https://gist.github.com/metatype/24b4462af6319cbf568b63ad3a56464e
> [5] https://gist.githubusercontent.com/metatype/
> b50b49a4c2a7a99793029b3ea0cde8c3/raw/40aca011a65c12d6fbec73fce60f57
> f43323d36f/README.md
>

Re: Building geode-native for release

[Jacob Barrett]

On Mon, Mar 6, 2017 at 9:56 AM Anthony Baker  wrote:

GEODE-1416 lays out the tasks needed to prepare geode-native to be included
in a geode release.  I spent some time reviewing the source and found
several other things to consider:

3) Build

The cmake build can produce source and binary distributions though it’s not
very obvious how to do so.  Here’s how to create the binary distribution:

cmake ../src -DPRODUCT_VERSION=1.2.0-SNAPSHOT
cmake --build .
cmake --build . —target docs
cmake --build . --target package

-rw-r--r--   1 abaker  staff  25355797 Mar  6 08:48
apache-geode-native-1.2.0-SNAPSHOT-Linux-64bit.tar.gz
-rw-r--r--   1 abaker  staff  27074260 Mar  6 08:54
apache-geode-native-1.2.0-SNAPSHOT-Linux-64bit.zip

$ cmake --build .
Invokes built-in target `all`.

I would update this to be a little faster...
$ cmake ../src -DPRODUCT_VERSION=1.2.0-SNAPSHOT
$ make all docs -j
$ make package -j
( cmake --build is just an wrapper around the generator's build executable,
on Linux this will likely be make, but is limited to a single target.)
$ cmake ../src -DPRODUCT_VERSION=1.2.0-SNAPSHOT
$ cmake --build --target all -- -j
$ cmake --build --target docs -- -j
$ cmake --build --target package -- -j

An open ticket exists with CMake project to allow targets to be
dependencies on built-in targets so that in the future package will be
dependent on all and docs.
One could create a custom target, `do-package`, that depends on all, docs
and package if having a single target is necessary.



Here’s how to create the source distribution:

cpack --config CPackSourceConfig.cmake

Comments:

- The distributions don’t include the version in the top-level directory.
We should include that.

I believe you are looking for `make package_source`. No care has been taken
yet for a src target. Some CMakeList.txt work needs to be tackled. The
first thing is that the root CMakeLists.txt needs to be moved to the root
of the repo. In fact the whole src directory is probably ready to be moved
to the root. It was under a sub directory for migration purposes only.


- The binary distributions include cmake files and several *.in files.  Are
those necessary?

Depends. There are some necessary for the quickstarts and plug-in examples.


- The source distribution only includes files from src/.  It should capture
everything in the geode-native/ root dir.
- It looks like src/cppcache/src/version.cmake.in relies on the presence of
a git repo.  That will not be present for a source release, see [1].


This should be easy to change to fallback to something if .git is not
found. It currently pulls the revisions SHA out of the repo. Personally I
think that is silly and we should just remove it altogether. The other
option is that a src distribution would just ship version.h and not cmake
bits to determine it.


We also need to generate signatures and hashes for each of the distribution
artifacts.  How hard is that to do in cmake?  Should we just create a
simple gradle wrapper script to do this so we have a common release toolset
across geode, geode-examples, and geode-native?


I really dislike having yet another build tool. CMake 3.7.2 and newer
supports hashing directly in CPack. Older versions of CMake support hashing
directly in the FILE command.
Signatures are easy enough to achieve with a custom target call to openssl
or pgp.

-Jake

[jira] [Updated] (GEODE-2594) Remove optional usage of Attach API

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2594:
-
Labels: gfsh  (was: )

> Remove optional usage of Attach API
> ---
>
> Key: GEODE-2594
> URL: https://issues.apache.org/jira/browse/GEODE-2594
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Kirk Lund
>  Labels: gfsh
>
> This is a request to remove our optional usage of Attach API.
> Users keep running into issues caused by GFSH using the Attach API. If the 
> user kills a GemFire process that was started by GFSH, the Attach API leaves 
> a java_pid file in /tmp which prevents the Attach API from working with any 
> future JVMs that reuse that pid. Most users also want to use a JRE without 
> the tools.jar.
> The only functionality that will be removed is status and stop command 
> support for --pid option.



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

[jira] [Created] (GEODE-2594) Remove optional usage of Attach API

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2594:


 Summary: Remove optional usage of Attach API
 Key: GEODE-2594
 URL: https://issues.apache.org/jira/browse/GEODE-2594
 Project: Geode
  Issue Type: Improvement
  Components: gfsh
Reporter: Kirk Lund


This is a request to remove our optional usage of Attach API.

Users keep running into issues caused by GFSH using the Attach API. If the user 
kills a GemFire process that was started by GFSH, the Attach API leaves a 
java_pid file in /tmp which prevents the Attach API from working with any 
future JVMs that reuse that pid. Most users also want to use a JRE without the 
tools.jar.

The only functionality that will be removed is status and stop command support 
for --pid option.



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

Re: Review Request 57342: GEODE-2267: mark local time sensitive tests as flaky

[Kirk Lund]

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


Ship it!




Ship It!

- Kirk Lund


On March 6, 2017, 5:03 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57342/
> ---
> 
> (Updated March 6, 2017, 5:03 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2267: mark local time sensitive tests as flaky
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
>  19198f2e22056e221f6476eaf1a495cffdc02f7b 
> 
> 
> Diff: https://reviews.apache.org/r/57342/diff/1/
> 
> 
> Testing
> ---
> 
> this is a flaky test because it is local time senstive. It fails sometimes on 
> nightly and CI, but not always.
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

[jira] [Commented] (GEODE-2267) Add gfsh command to export stat files

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2267:


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

GEODE-2267: mark local time sensitive tests as flaky


> Add gfsh command to export stat files
> -
>
> Key: GEODE-2267
> URL: https://issues.apache.org/jira/browse/GEODE-2267
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration, gfsh
>Reporter: Diane Hardman
>Assignee: Kirk Lund
>  Labels: ExportClusterArtifacts, export, gfsh, logging, statistics
>
> We would like a single gfsh command to collect and export all logfiles and 
> stat files into a single package that will be returned to the gfsh client 
> machine. This package (zipfile) can then be saved and attached to emails and 
> Jira tickets to help evaluate the Geode cluster status.



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

Re: ACE version for C++ client (not grant)

[Jacob Barrett]

Geode Native will be release with Geode in the future. It has never been
release with Geode using ACE 6.3.3.


On Mon, Mar 6, 2017 at 8:27 AM Avital Amity  wrote:

> Well We took it when it was compiled with ACE 6.3.3
> C++ client isn't an official part of GEODE? It is a mandatory part for us.
>
> Thanks
> Avital
>
> -Original Message-
> From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> Sent: Monday, March 06, 2017 6:12 PM
> To: dev@geode.apache.org
> Subject: Re: ACE version for C++ client (not grant)
>
> There was no previous release of Geode Native. In fact there have not been
> any releases of Geode Native.
>
> On Mon, Mar 6, 2017 at 8:07 AM Avital Amity 
> wrote:
>
> > This is on the grant, I have the previous version, there in this file
> > I can see it's 6.3.3...
> > Anyway I will check the flags there
> >
> > Thanks
> > Avital
> >
> > -Original Message-
> > From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> > Sent: Monday, March 06, 2017 6:00 PM
> > To: dev@geode.apache.org
> > Subject: Re: ACE version for C++ client (not grant)
> >
> > Geode is not compiling against ACE 6.3.3. It is currently compiling
> > against ACE 6.4.1. The src/dependencies/ACE/CMakeLists.text project
> > will show you all the flags used to compile the ACE library. The
> > library is statically linked to Geode to produce the Geode dynamic
> library.
> >
> > -Jake
> >
> >
> > On Mon, Mar 6, 2017 at 6:50 AM Avital Amity 
> > wrote:
> >
> > > Yes, it is 6.3.3 - but is the product (ACE dll) part of the GEODE?
> > > How can I know its compilation flags?
> > >
> > > -Original Message-
> > > From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> > > Sent: Monday, March 06, 2017 4:07 PM
> > > To: dev@geode.apache.org
> > > Subject: Re: ACE version for C++ client (not grant)
> > >
> > > The version used in Geode is compiled using the dependency CMake files.
> > > See src/dependencies/ACE.
> > > On Mon, Mar 6, 2017 at 5:22 AM Avital Amity
> > > 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > We are currently using GEODE C++ client (not grant version) I see
> > > > it was compiled with ACE 6.3.3 - anyone knows if the specific ACE
> > > > that was used is part of the GEODE sources How can I get the
> > > > specific lib it was compiled with (for Windows)
> > > >
> > > >
> > > > Thanks
> > > > Avital
> > > > This message and the information contained herein is proprietary
> > > > and confidential and subject to the Amdocs policy statement,
> > > >
> > > > you may review at http://www.amdocs.com/email_disclaimer.asp
> > > >
> > > This message and the information contained herein is proprietary and
> > > confidential and subject to the Amdocs policy statement,
> > >
> > > you may review at http://www.amdocs.com/email_disclaimer.asp
> > >
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement,
> >
> > you may review at http://www.amdocs.com/email_disclaimer.asp
> >
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>

Review Request 57342: GEODE-2267: mark local time sensitive tests as flaky

[Jinmei Liao]

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

Review request for geode.


Repository: geode


Description
---

GEODE-2267: mark local time sensitive tests as flaky


Diffs
-

  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
 19198f2e22056e221f6476eaf1a495cffdc02f7b 


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


Testing
---

this is a flaky test because it is local time senstive. It fails sometimes on 
nightly and CI, but not always.


Thanks,

Jinmei Liao

Re: Gemfire proxy cache race condition bug?

[Michael Stolz]

If you always do whatever processing you are planning to do inside the
CacheListener and use the "newValue" field that is supplied to that
callback you will always begin processing in the order the data was
received. I suppose if you want to ensure that you are completing
processing in the correct order you would need to synchronize on your
callback as you said.

To "prime the pump" you can use get as you are now, or registerInterest
with a list of keys or wildcard on string-based keys. Register interest can
optionally deliver the initial value followed by all updates in the correct
order.


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

On Sat, Mar 4, 2017 at 7:58 AM, David Wales 
wrote:

> Hi there,
>
> I have a client proxy cache with an associated cache listener. An
> invocation of the region get method will trigger the afterCreate callback.
> I realized this call back was on the same thread that called get and is
> different to the thread that dispatches the region updates. So I had a look
> at the code and there seems to be no synchronization. I could mark the
> cache listener methods as synchronized but this doesn't fully mitigate the
> race. How does one get the initial state of an entry in a region in a way
> that synchronizes with updates on. Is this a known limitation or a bug as
> the documentation talks about cache listener methods being mutually
> exclusive?
>
> Much appreciated
> Thank you
> David
>

Re: ACE version for C++ client (not grant)

[Anthony Baker]

We’re continuing to work on several improvements needed to meet ASF and Geode 
release standards.  This work is being tracked on GEODE-1416 (see 
https://issues.apache.org/jira/browse/GEODE-1416 
).  I plan to send out an 
update later today.  And as always, you’re welcome to jump in and contribute :-)

Anthony

> On Mar 6, 2017, at 8:26 AM, Avital Amity  wrote:
> 
> Well We took it when it was compiled with ACE 6.3.3
> C++ client isn't an official part of GEODE? It is a mandatory part for us.
> 
> Thanks
> Avital
> 
> -Original Message-
> From: Jacob Barrett [mailto:jbarr...@pivotal.io] 
> Sent: Monday, March 06, 2017 6:12 PM
> To: dev@geode.apache.org
> Subject: Re: ACE version for C++ client (not grant)
> 
> There was no previous release of Geode Native. In fact there have not been 
> any releases of Geode Native.
> 
> On Mon, Mar 6, 2017 at 8:07 AM Avital Amity  wrote:
> 
>> This is on the grant, I have the previous version, there in this file 
>> I can see it's 6.3.3...
>> Anyway I will check the flags there
>> 
>> Thanks
>> Avital
>> 
>> -Original Message-
>> From: Jacob Barrett [mailto:jbarr...@pivotal.io]
>> Sent: Monday, March 06, 2017 6:00 PM
>> To: dev@geode.apache.org
>> Subject: Re: ACE version for C++ client (not grant)
>> 
>> Geode is not compiling against ACE 6.3.3. It is currently compiling 
>> against ACE 6.4.1. The src/dependencies/ACE/CMakeLists.text project 
>> will show you all the flags used to compile the ACE library. The 
>> library is statically linked to Geode to produce the Geode dynamic library.
>> 
>> -Jake
>> 
>> 
>> On Mon, Mar 6, 2017 at 6:50 AM Avital Amity 
>> wrote:
>> 
>>> Yes, it is 6.3.3 - but is the product (ACE dll) part of the GEODE?
>>> How can I know its compilation flags?
>>> 
>>> -Original Message-
>>> From: Jacob Barrett [mailto:jbarr...@pivotal.io]
>>> Sent: Monday, March 06, 2017 4:07 PM
>>> To: dev@geode.apache.org
>>> Subject: Re: ACE version for C++ client (not grant)
>>> 
>>> The version used in Geode is compiled using the dependency CMake files.
>>> See src/dependencies/ACE.
>>> On Mon, Mar 6, 2017 at 5:22 AM Avital Amity 
>>> 
>>> wrote:
>>> 
 Hi,
 
 We are currently using GEODE C++ client (not grant version) I see 
 it was compiled with ACE 6.3.3 - anyone knows if the specific ACE 
 that was used is part of the GEODE sources How can I get the 
 specific lib it was compiled with (for Windows)
 
 
 Thanks
 Avital
 This message and the information contained herein is proprietary 
 and confidential and subject to the Amdocs policy statement,
 
 you may review at http://www.amdocs.com/email_disclaimer.asp
 
>>> This message and the information contained herein is proprietary and 
>>> confidential and subject to the Amdocs policy statement,
>>> 
>>> you may review at http://www.amdocs.com/email_disclaimer.asp
>>> 
>> This message and the information contained herein is proprietary and 
>> confidential and subject to the Amdocs policy statement,
>> 
>> you may review at http://www.amdocs.com/email_disclaimer.asp
>> 
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
> 
> you may review at http://www.amdocs.com/email_disclaimer.asp

Re: Review Request 57311: GEODE-2593: add port range to AvailablePortHelper to fix testUDPPortRange

[Ken Howe]

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




geode-core/src/test/java/org/apache/geode/internal/AvailablePortHelper.java
Lines 18 (patched)


Code Style guidleines are to not use wildcard imports.



geode-core/src/test/java/org/apache/geode/internal/AvailablePortHelper.java
Lines 113-114 (patched)


Is the upper_bound a useable port? If so then the outer loop test should be 
'<='. Also in the test condition, the upper_bound should be reduced by the 
count to enusre that i + j doesn't exceed the upper_bound.


- Ken Howe


On March 4, 2017, 1:57 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57311/
> ---
> 
> (Updated March 4, 2017, 1:57 a.m.)
> 
> 
> Review request for geode, Anthony Baker, Bruce Schuchardt, Jinmei Liao, Jared 
> Stewart, Ken Howe, and Mark Bretl.
> 
> 
> Bugs: GEODE-2593
> https://issues.apache.org/jira/browse/GEODE-2593
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2593: add port range to AvailablePortHelper to fix testUDPPortRange
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/distributed/DistributedSystemDUnitTest.java
>  c57ad1760a9de45b10a0298d601d57c4fce97633 
>   geode-core/src/test/java/org/apache/geode/internal/AvailablePortHelper.java 
> e09a7a06a46adbae56eadce5f63039d7bbeb886d 
>   
> geode-core/src/test/java/org/apache/geode/internal/AvailablePortHelperIntegrationTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/57311/diff/1/
> 
> 
> Testing
> ---
> 
> AvailablePortHelperIntegrationTest
> DistributedSystemDUnitTest
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Build failed in Jenkins: Geode-nightly #768

[Apache Jenkins Server]

See 

--
[...truncated 100.05 KB...]
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
testExportWithStartAndEndDateTimeFiltering FAILED
java.lang.AssertionError: 
Expected size:<3> but was:<2> in:
<[/tmp/junit3567663348023277052/unzippedLogs/server-1,
/tmp/junit3567663348023277052/unzippedLogs/server-2]>
at 
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:225)
at 
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:155)

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

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

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

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

 uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:flakyTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources UP-TO-DATE
:geode-rebalancer:testClasses
:geode-rebalancer:checkMissedTests
:geode-rebalancer:spotlessJavaCheck

Re: ACE version for C++ client (not grant)

[Ernest Burghardt]

Avital,

If by "grant" you mean the  'next-gen-native-client-software-grant’ branch
then you are in the wrong repo.

You will want to use:

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

Geode Native will be included in a future release of Geode, but you are
welcome to use what is there currently.

Best,
EB

On Mon, Mar 6, 2017 at 8:07 AM, Avital Amity 
wrote:

> This is on the grant, I have the previous version, there in this file I
> can see it's 6.3.3...
> Anyway I will check the flags there
>
> Thanks
> Avital
>
> -Original Message-
> From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> Sent: Monday, March 06, 2017 6:00 PM
> To: dev@geode.apache.org
> Subject: Re: ACE version for C++ client (not grant)
>
> Geode is not compiling against ACE 6.3.3. It is currently compiling
> against ACE 6.4.1. The src/dependencies/ACE/CMakeLists.text project will
> show you all the flags used to compile the ACE library. The library is
> statically linked to Geode to produce the Geode dynamic library.
>
> -Jake
>
>
> On Mon, Mar 6, 2017 at 6:50 AM Avital Amity 
> wrote:
>
> > Yes, it is 6.3.3 - but is the product (ACE dll) part of the GEODE?
> > How can I know its compilation flags?
> >
> > -Original Message-
> > From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> > Sent: Monday, March 06, 2017 4:07 PM
> > To: dev@geode.apache.org
> > Subject: Re: ACE version for C++ client (not grant)
> >
> > The version used in Geode is compiled using the dependency CMake files.
> > See src/dependencies/ACE.
> > On Mon, Mar 6, 2017 at 5:22 AM Avital Amity 
> > wrote:
> >
> > > Hi,
> > >
> > > We are currently using GEODE C++ client (not grant version) I see it
> > > was compiled with ACE 6.3.3 - anyone knows if the specific ACE that
> > > was used is part of the GEODE sources How can I get the specific
> > > lib it was compiled with (for Windows)
> > >
> > >
> > > Thanks
> > > Avital
> > > This message and the information contained herein is proprietary and
> > > confidential and subject to the Amdocs policy statement,
> > >
> > > you may review at http://www.amdocs.com/email_disclaimer.asp
> > >
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement,
> >
> > you may review at http://www.amdocs.com/email_disclaimer.asp
> >
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>

RE: ACE version for C++ client (not grant)

[Avital Amity]

Well We took it when it was compiled with ACE 6.3.3
C++ client isn't an official part of GEODE? It is a mandatory part for us.

Thanks
Avital

-Original Message-
From: Jacob Barrett [mailto:jbarr...@pivotal.io] 
Sent: Monday, March 06, 2017 6:12 PM
To: dev@geode.apache.org
Subject: Re: ACE version for C++ client (not grant)

There was no previous release of Geode Native. In fact there have not been any 
releases of Geode Native.

On Mon, Mar 6, 2017 at 8:07 AM Avital Amity  wrote:

> This is on the grant, I have the previous version, there in this file 
> I can see it's 6.3.3...
> Anyway I will check the flags there
>
> Thanks
> Avital
>
> -Original Message-
> From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> Sent: Monday, March 06, 2017 6:00 PM
> To: dev@geode.apache.org
> Subject: Re: ACE version for C++ client (not grant)
>
> Geode is not compiling against ACE 6.3.3. It is currently compiling 
> against ACE 6.4.1. The src/dependencies/ACE/CMakeLists.text project 
> will show you all the flags used to compile the ACE library. The 
> library is statically linked to Geode to produce the Geode dynamic library.
>
> -Jake
>
>
> On Mon, Mar 6, 2017 at 6:50 AM Avital Amity 
> wrote:
>
> > Yes, it is 6.3.3 - but is the product (ACE dll) part of the GEODE?
> > How can I know its compilation flags?
> >
> > -Original Message-
> > From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> > Sent: Monday, March 06, 2017 4:07 PM
> > To: dev@geode.apache.org
> > Subject: Re: ACE version for C++ client (not grant)
> >
> > The version used in Geode is compiled using the dependency CMake files.
> > See src/dependencies/ACE.
> > On Mon, Mar 6, 2017 at 5:22 AM Avital Amity 
> > 
> > wrote:
> >
> > > Hi,
> > >
> > > We are currently using GEODE C++ client (not grant version) I see 
> > > it was compiled with ACE 6.3.3 - anyone knows if the specific ACE 
> > > that was used is part of the GEODE sources How can I get the 
> > > specific lib it was compiled with (for Windows)
> > >
> > >
> > > Thanks
> > > Avital
> > > This message and the information contained herein is proprietary 
> > > and confidential and subject to the Amdocs policy statement,
> > >
> > > you may review at http://www.amdocs.com/email_disclaimer.asp
> > >
> > This message and the information contained herein is proprietary and 
> > confidential and subject to the Amdocs policy statement,
> >
> > you may review at http://www.amdocs.com/email_disclaimer.asp
> >
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at http://www.amdocs.com/email_disclaimer.asp

Re: [GitHub] geode-native issue #44: GEODE-2578: Remove 64 KiB limit on query strings.

[Michael William Dodge]

They didn't for me before I committed the code. Let me try them again.

> On 6 Mar, 2017, at 08:03, pivotal-jbarrett  wrote:
> 
> Github user pivotal-jbarrett commented on the issue:
> 
>https://github.com/apache/geode-native/pull/44
> 
>@PivotalSarge looks like some unit tests are failing.
> 
> 
> ---
> 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: ACE version for C++ client (not grant)

[Jacob Barrett]

There was no previous release of Geode Native. In fact there have not been
any releases of Geode Native.

On Mon, Mar 6, 2017 at 8:07 AM Avital Amity  wrote:

> This is on the grant, I have the previous version, there in this file I
> can see it's 6.3.3...
> Anyway I will check the flags there
>
> Thanks
> Avital
>
> -Original Message-
> From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> Sent: Monday, March 06, 2017 6:00 PM
> To: dev@geode.apache.org
> Subject: Re: ACE version for C++ client (not grant)
>
> Geode is not compiling against ACE 6.3.3. It is currently compiling
> against ACE 6.4.1. The src/dependencies/ACE/CMakeLists.text project will
> show you all the flags used to compile the ACE library. The library is
> statically linked to Geode to produce the Geode dynamic library.
>
> -Jake
>
>
> On Mon, Mar 6, 2017 at 6:50 AM Avital Amity 
> wrote:
>
> > Yes, it is 6.3.3 - but is the product (ACE dll) part of the GEODE?
> > How can I know its compilation flags?
> >
> > -Original Message-
> > From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> > Sent: Monday, March 06, 2017 4:07 PM
> > To: dev@geode.apache.org
> > Subject: Re: ACE version for C++ client (not grant)
> >
> > The version used in Geode is compiled using the dependency CMake files.
> > See src/dependencies/ACE.
> > On Mon, Mar 6, 2017 at 5:22 AM Avital Amity 
> > wrote:
> >
> > > Hi,
> > >
> > > We are currently using GEODE C++ client (not grant version) I see it
> > > was compiled with ACE 6.3.3 - anyone knows if the specific ACE that
> > > was used is part of the GEODE sources How can I get the specific
> > > lib it was compiled with (for Windows)
> > >
> > >
> > > Thanks
> > > Avital
> > > This message and the information contained herein is proprietary and
> > > confidential and subject to the Amdocs policy statement,
> > >
> > > you may review at http://www.amdocs.com/email_disclaimer.asp
> > >
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement,
> >
> > you may review at http://www.amdocs.com/email_disclaimer.asp
> >
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>

[GitHub] geode-native issue #44: GEODE-2578: Remove 64 KiB limit on query strings.

[pivotal-jbarrett]

Github user pivotal-jbarrett commented on the issue:

https://github.com/apache/geode-native/pull/44
  
@PivotalSarge looks like some unit tests are failing.


---
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-2578) Query string limited to 64 KiB

[ASF GitHub Bot (JIRA)]

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

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

Github user pivotal-jbarrett commented on the issue:

https://github.com/apache/geode-native/pull/44
  
@PivotalSarge looks like some unit tests are failing.


> Query string limited to 64 KiB
> --
>
> Key: GEODE-2578
> URL: https://issues.apache.org/jira/browse/GEODE-2578
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> The serialization of query strings uses a 16-bit unsigned integer to 
> represent the length of the query string. Query strings with more than 65535 
> characters are silently truncated. Use of a 32-bit unsigned integer to 
> represent the length would greatly increase the size of query strings that 
> may be used.



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

RE: ACE version for C++ client (not grant)

[Avital Amity]

This is on the grant, I have the previous version, there in this file I can see 
it's 6.3.3... 
Anyway I will check the flags there

Thanks
Avital

-Original Message-
From: Jacob Barrett [mailto:jbarr...@pivotal.io] 
Sent: Monday, March 06, 2017 6:00 PM
To: dev@geode.apache.org
Subject: Re: ACE version for C++ client (not grant)

Geode is not compiling against ACE 6.3.3. It is currently compiling against ACE 
6.4.1. The src/dependencies/ACE/CMakeLists.text project will show you all the 
flags used to compile the ACE library. The library is statically linked to 
Geode to produce the Geode dynamic library.

-Jake


On Mon, Mar 6, 2017 at 6:50 AM Avital Amity  wrote:

> Yes, it is 6.3.3 - but is the product (ACE dll) part of the GEODE?  
> How can I know its compilation flags?
>
> -Original Message-
> From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> Sent: Monday, March 06, 2017 4:07 PM
> To: dev@geode.apache.org
> Subject: Re: ACE version for C++ client (not grant)
>
> The version used in Geode is compiled using the dependency CMake files.
> See src/dependencies/ACE.
> On Mon, Mar 6, 2017 at 5:22 AM Avital Amity 
> wrote:
>
> > Hi,
> >
> > We are currently using GEODE C++ client (not grant version) I see it 
> > was compiled with ACE 6.3.3 - anyone knows if the specific ACE that 
> > was used is part of the GEODE sources How can I get the specific 
> > lib it was compiled with (for Windows)
> >
> >
> > Thanks
> > Avital
> > This message and the information contained herein is proprietary and 
> > confidential and subject to the Amdocs policy statement,
> >
> > you may review at http://www.amdocs.com/email_disclaimer.asp
> >
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at http://www.amdocs.com/email_disclaimer.asp

Re: ACE version for C++ client (not grant)

[Jacob Barrett]

Geode is not compiling against ACE 6.3.3. It is currently compiling against
ACE 6.4.1. The src/dependencies/ACE/CMakeLists.text project will show you
all the flags used to compile the ACE library. The library is statically
linked to Geode to produce the Geode dynamic library.

-Jake


On Mon, Mar 6, 2017 at 6:50 AM Avital Amity  wrote:

> Yes, it is 6.3.3 - but is the product (ACE dll) part of the GEODE?  How
> can I know its compilation flags?
>
> -Original Message-
> From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> Sent: Monday, March 06, 2017 4:07 PM
> To: dev@geode.apache.org
> Subject: Re: ACE version for C++ client (not grant)
>
> The version used in Geode is compiled using the dependency CMake files.
> See src/dependencies/ACE.
> On Mon, Mar 6, 2017 at 5:22 AM Avital Amity 
> wrote:
>
> > Hi,
> >
> > We are currently using GEODE C++ client (not grant version) I see it
> > was compiled with ACE 6.3.3 - anyone knows if the specific ACE that
> > was used is part of the GEODE sources How can I get the specific
> > lib it was compiled with (for Windows)
> >
> >
> > Thanks
> > Avital
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement,
> >
> > you may review at http://www.amdocs.com/email_disclaimer.asp
> >
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>

Re: Feature branch cleanup

[Anthony Baker]

Last chance to comment:  I’ll be cleaning up these branches over the next few 
days.

Anthony

> On Feb 27, 2017, at 8:58 AM, Dan Smith  wrote:
> 
> +1
> 
> -Dan
> 
> On Fri, Feb 24, 2017 at 10:35 PM, Anthony Baker  wrote:
> 
>> 
>> The following 100+ feature branches are related to closed bugs.  I think
>> these can safely be deleted (the branch names aren’t exact but pretty
>> close):
>> 
>> GEODE-1017: "Closed"
>> GEODE-1040: "Closed"
>> GEODE-1050: "Closed"
>> GEODE-1056: "Closed"
>> GEODE-1072: "Closed"
>> GEODE-1096: "Closed"
>> GEODE-1109: "Closed"
>> GEODE-1162: "Closed"
>> GEODE-1186: "Closed"
>> GEODE-1199: "Closed"
>> GEODE-12: "Closed"
>> GEODE-1204: "Closed"
>> GEODE-1233: "Closed"
>> GEODE-124: "Closed"
>> GEODE-1252: "Closed"
>> GEODE-1255: "Closed"
>> GEODE-1257: "Closed"
>> GEODE-1276: "Closed"
>> GEODE-1369: "Closed"
>> GEODE-1370: "Closed"
>> GEODE-1371: "Closed"
>> GEODE-1372: "Closed"
>> GEODE-1374: "Closed"
>> GEODE-1376: "Closed"
>> GEODE-1392: "Closed"
>> GEODE-14: "Closed"
>> GEODE-14: "Closed"
>> GEODE-1400: "Closed"
>> GEODE-1420: "Closed"
>> GEODE-1426: "Closed"
>> GEODE-1452: "Closed"
>> GEODE-1464: "Closed"
>> GEODE-1493: "Closed"
>> GEODE-151: "Closed"
>> GEODE-1565: "Closed"
>> GEODE-1567: "Closed"
>> GEODE-1571: "Closed"
>> GEODE-1573: "Closed"
>> GEODE-1593: "Closed"
>> GEODE-160: "Closed"
>> GEODE-1673: "Closed"
>> GEODE-17: "Closed"
>> GEODE-17: "Closed"
>> GEODE-1701: "Closed"
>> GEODE-1714: "Closed"
>> GEODE-1835: "Closed"
>> GEODE-1861: "Closed"
>> GEODE-1874: "Closed"
>> GEODE-1886: "Closed"
>> GEODE-189: "Closed"
>> GEODE-1952: "Closed"
>> GEODE-1952: "Closed"
>> GEODE-1952: "Closed"
>> GEODE-1983: "Closed"
>> GEODE-1985: "Closed"
>> GEODE-2012: "Closed"
>> GEODE-2026: "Closed"
>> GEODE-2104: "Closed"
>> GEODE-2157: "Closed"
>> GEODE-217: "Closed"
>> GEODE-2196: "Closed"
>> GEODE-2197: "Closed"
>> GEODE-2207: "Closed"
>> GEODE-2214: "Closed"
>> GEODE-227: "Closed"
>> GEODE-2277: "Closed"
>> GEODE-2297: "Closed"
>> GEODE-2297: "Closed"
>> GEODE-2297: "Closed"
>> GEODE-233: "Closed"
>> GEODE-2386: "Closed"
>> GEODE-280: "Closed"
>> GEODE-291: "Closed"
>> GEODE-33: "Closed"
>> GEODE-37: "Closed"
>> GEODE-372: "Closed"
>> GEODE-374: "Closed"
>> GEODE-377: "Closed"
>> GEODE-37: "Closed"
>> GEODE-37: "Closed"
>> GEODE-38: "Closed"
>> GEODE-392: "Closed"
>> GEODE-409: "Closed"
>> GEODE-41: "Closed"
>> GEODE-417: "Closed"
>> GEODE-420: "Closed"
>> GEODE-52: "Closed"
>> GEODE-523: "Closed"
>> GEODE-523: "Closed"
>> GEODE-53: "Closed"
>> GEODE-54: "Closed"
>> GEODE-542: "Closed"
>> GEODE-544: "Closed"
>> GEODE-546: "Closed"
>> GEODE-563: "Closed"
>> GEODE-564: "Closed"
>> GEODE-574: "Closed"
>> GEODE-578: "Closed"
>> GEODE-580: "Closed"
>> GEODE-584: "Closed"
>> GEODE-607: "Closed"
>> GEODE-608: "Closed"
>> GEODE-610: "Closed"
>> GEODE-611: "Closed"
>> GEODE-622: "Closed"
>> GEODE-637: "Closed"
>> GEODE-639: "Closed"
>> GEODE-678: "Closed"
>> GEODE-681: "Closed"
>> GEODE-714: "Closed"
>> GEODE-715: "Closed"
>> GEODE-734: "Closed"
>> GEODE-77: "Closed"
>> GEODE-773: "Closed"
>> GEODE-773: "Closed"
>> GEODE-781: "Closed"
>> GEODE-805: "Closed"
>> GEODE-819: "Closed"
>> GEODE-831: "Closed"
>> GEODE-835: "Closed"
>> GEODE-835: "Closed"
>> GEODE-837: "Closed"
>> GEODE-840: "Closed"
>> GEODE-866: "Closed"
>> GEODE-870: "Closed"
>> GEODE-917: "Closed"
>> GEODE-92: "Closed"
>> GEODE-93: "Closed"
>> GEODE-949: "Closed"
>> GEODE-949: "Closed"
>> GEODE-951: "Closed"
>> GEODE-953: "Closed"
>> GEODE-996: "Closed"
>> 
>> Once you’ve merged a feature branch to develop, please make sure to delete
>> the remote branch.  If you created one of these branches and you DON”T want
>> it deleted, please let me know.  Otherwise I plan to clean these up in a
>> week or so.
>> 
>> Anthony
>> 
>> 

Re: Review Request 57311: GEODE-2593: add port range to AvailablePortHelper to fix testUDPPortRange

[Kevin Duling]

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


Ship it!




Ship It!

- Kevin Duling


On March 3, 2017, 5:57 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57311/
> ---
> 
> (Updated March 3, 2017, 5:57 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Bruce Schuchardt, Jinmei Liao, Jared 
> Stewart, Ken Howe, and Mark Bretl.
> 
> 
> Bugs: GEODE-2593
> https://issues.apache.org/jira/browse/GEODE-2593
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2593: add port range to AvailablePortHelper to fix testUDPPortRange
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/distributed/DistributedSystemDUnitTest.java
>  c57ad1760a9de45b10a0298d601d57c4fce97633 
>   geode-core/src/test/java/org/apache/geode/internal/AvailablePortHelper.java 
> e09a7a06a46adbae56eadce5f63039d7bbeb886d 
>   
> geode-core/src/test/java/org/apache/geode/internal/AvailablePortHelperIntegrationTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/57311/diff/1/
> 
> 
> Testing
> ---
> 
> AvailablePortHelperIntegrationTest
> DistributedSystemDUnitTest
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

[GSoC] Interested in GSoC 2017 ideas

[Kai Jiang]

Hi All,

I am Kai, a master student majoring in CS from Portland State University,
highly interested in Big data and Distributed System. I have contributed to
Apache Spark as a GSoC project last year.

I've been contributing to Geode codebase. Some my Pull Requests are here.(
https://github.com/apache/geode/pulls?q=is%3Apr+author%3Avectorijk+is%3Aclosed
)
Also, I did some experiments on last year GSoC idea (GEODE-194
 Geode Spark Connector
does not support Spark 2.0) on my branch (
https://github.com/vectorijk/geode/commits/spark2). I would like to extend
my work with Geode as a GSoC project this year and look forward to writing
something meaningful and impactful.

Is there any Geode Committer who's going to sign up as a mentor for GSoC
this year? Maybe you could tell me about the projects you are going to
mentor and give me some suggestions about what issues I could fix now to
get involved. If community has anything else in mind, I am very willing to
work on some issues before GSoC and get started with something new during
GSoC.

Looking forward!

Best,
Kai Jiang
github.com/vectorijk

[jira] [Commented] (GEODE-1702) Release transaction lock before calling AsyncEventListener

[Christian Tzolov (JIRA)]

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

Christian Tzolov commented on GEODE-1702:
-

[~amb] AFAIK this behavior is in: 
[TXState.java#L481-L500|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/TXState.java#L481-L500]
 where the events are send  before transactional lock is released. E.g. the (1) 
enqueuing and (2) sending happen within the sender's transaction.

If the user's AEQ dispatch and modify an entry before the sender has released 
the transaction lock a _CommitConflictException_ is thrown. Something like:
{code}
Caused by: org.apache.geode.cache.CommitConflictException: Concurrent 
transaction commit detected The key de2d691e-a585-4394-893a-f37922afa084 in 
region /complexRegion1 was being modified by another transaction locally.
{code}

The only workaround available at the moment is to use *Try-Catch-Wait-Retry* 
inside the AEListener




> Release transaction lock before calling AsyncEventListener
> --
>
> Key: GEODE-1702
> URL: https://issues.apache.org/jira/browse/GEODE-1702
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Swapnil Bawaskar
>
> The relavent workflow of transaction commit processing is as follows:
> 1. Grab transaction locks
> 2. perform conflict checks
> 3. apply changes to locally
> 4. enqueue events in AsyncEventQueue
> 5. release transaction locks
> However this is problematic since the AsyncEventListener could be called 
> while the tx locks are held. This prevents same entry from being modified in 
> the AsyncEventListener (within a transaction). 
> Transaction locks cannot be released before the events are enqueued to 
> prevent out-of-order events.



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

RE: ACE version for C++ client (not grant)

[Avital Amity]

Yes, it is 6.3.3 - but is the product (ACE dll) part of the GEODE?  How can I 
know its compilation flags?

-Original Message-
From: Jacob Barrett [mailto:jbarr...@pivotal.io] 
Sent: Monday, March 06, 2017 4:07 PM
To: dev@geode.apache.org
Subject: Re: ACE version for C++ client (not grant)

The version used in Geode is compiled using the dependency CMake files. See 
src/dependencies/ACE.
On Mon, Mar 6, 2017 at 5:22 AM Avital Amity  wrote:

> Hi,
>
> We are currently using GEODE C++ client (not grant version) I see it 
> was compiled with ACE 6.3.3 - anyone knows if the specific ACE that 
> was used is part of the GEODE sources How can I get the specific 
> lib it was compiled with (for Windows)
>
>
> Thanks
> Avital
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at http://www.amdocs.com/email_disclaimer.asp

Re: ACE version for C++ client (not grant)

[Jacob Barrett]

The version used in Geode is compiled using the dependency CMake files. See
src/dependencies/ACE.
On Mon, Mar 6, 2017 at 5:22 AM Avital Amity  wrote:

> Hi,
>
> We are currently using GEODE C++ client (not grant version)
> I see it was compiled with ACE 6.3.3 - anyone knows if the specific ACE
> that was used is part of the GEODE sources How can I get the specific
> lib it was compiled with (for Windows)
>
>
> Thanks
> Avital
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>

ACE version for C++ client (not grant)

[Avital Amity]

Hi,

We are currently using GEODE C++ client (not grant version)
I see it was compiled with ACE 6.3.3 - anyone knows if the specific ACE that 
was used is part of the GEODE sources How can I get the specific lib it was 
compiled with (for Windows)


Thanks
Avital
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at http://www.amdocs.com/email_disclaimer.asp

[GitHub] geode pull request #404: Geode 2469

[ggreen]

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

https://github.com/apache/geode/pull/404#discussion_r104402728
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/redis/internal/executor/hash/HashInterpreter.java
 ---
@@ -0,0 +1,126 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.redis.internal.executor.hash;
+
+import java.util.Map;
+
+import org.apache.geode.cache.Region;
+import org.apache.geode.redis.GeodeRedisServer;
+import org.apache.geode.redis.internal.ByteArrayWrapper;
+import org.apache.geode.redis.internal.Coder;
+import org.apache.geode.redis.internal.ExecutionHandlerContext;
+import org.apache.geode.redis.internal.RedisDataType;
+
+/**
+ * Utility class for interpreting and processing Redis Hash data structure
+ * 
+ *
+ */
+public class HashInterpreter {
+
+  /**
+   * 
+   * The region:key separator.
+   * 
+   *  REGION_KEY_SEPERATOR = ":"
+   * 
+   * See Hash section of https://redis.io/topics/data-types;>https://redis.io/topics/data-types#Hashes
+   * 
+   */
+  public static final String REGION_KEY_SEPERATOR = ":";
+
+  /**
+   * The default hash region name REGION_HASH_REGION = 
Coder.stringToByteArrayWrapper("ReDiS_HASH")
+   */
+  public static final ByteArrayWrapper REGION_HASH_REGION =
+  Coder.stringToByteArrayWrapper(GeodeRedisServer.HASH_REGION);
+
+  /**
+   * Return the region presenting the hash
+   * 
+   * @param key the raw Redis command key that may contain the region:key 
formation
+   * @param context the exception handler context
+   * @return the region were the command's data will be processed
+   */
+  @SuppressWarnings("unchecked")
+  public static Region> getRegion(
--- End diff --

@galen-pivotal I will look to implement your recommendations. One 
clarification question, You are recommending that we do not create a separate 
region for hash objects, but store everything in /ReDiS_HASH with the region 
key of object:key, correct?


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