Build failed in Jenkins: Geode-nightly #839

[Apache Jenkins Server]

See 


Changes:

[klund] GEODE-1279: rename Bug51193DUnitTest to

[klund] GEODE-2934: refactor AnalyzeSerializablesJUnitTest and subclasses

[klund] GEODE-2934: fix typos

[nnag] GEODE-2587: Refactored the OrderByComparator's compare method

--
[...truncated 100.04 KB...]
:geode-assembly:defaultDistributionConfig
:geode-assembly:depsJar
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-analyzers-common/6.4.1/lucene-analyzers-common-6.4.1.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-parent/6.4.1/lucene-parent-6.4.1.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-solr-grandparent/6.4.1/lucene-solr-grandparent-6.4.1.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-core/6.4.1/lucene-core-6.4.1.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-queries/6.4.1/lucene-queries-6.4.1.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-queryparser/6.4.1/lucene-queryparser-6.4.1.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-analyzers-common/6.4.1/lucene-analyzers-common-6.4.1.jar
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-core/6.4.1/lucene-core-6.4.1.jar
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-queries/6.4.1/lucene-queries-6.4.1.jar
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-queryparser/6.4.1/lucene-queryparser-6.4.1.jar
Download 
https://repo1.maven.org/maven2/org/springframework/spring-aspects/4.3.6.RELEASE/spring-aspects-4.3.6.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/spring-oxm/4.3.6.RELEASE/spring-oxm-4.3.6.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/spring-aop/4.3.6.RELEASE/spring-aop-4.3.6.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/spring-aspects/4.3.6.RELEASE/spring-aspects-4.3.6.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/springframework/spring-oxm/4.3.6.RELEASE/spring-oxm-4.3.6.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/springframework/spring-aop/4.3.6.RELEASE/spring-aop-4.3.6.RELEASE.jar
:geode-benchmarks:compileJava UP-TO-DATE
:geode-benchmarks:processResources UP-TO-DATE
:geode-benchmarks:classes UP-TO-DATE
:geode-cq:compileJavaNote: 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:processResources
:geode-cq:classes
:geode-lucene:compileJavaNote: 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:processResources
:geode-lucene:classes
:geode-old-client-support:compileJavaNote: Some input files use or override a 
deprecated API.
Note: Recompile with -Xlint:deprecation for details.

:geode-old-client-support:processResources
:geode-old-client-support:classes
:geode-pulse:compileJava
Download 
https://repo1.maven.org/maven2/commons-digester/commons-digester/2.1/commons-digester-2.1.pom
Download 
https://repo1.maven.org/maven2/org/springframework/ldap/spring-ldap-core/2.3.1.RELEASE/spring-ldap-core-2.3.1.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/security/spring-security-config/4.2.1.RELEASE/spring-security-config-4.2.1.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/spring-framework-bom/4.3.5.RELEASE/spring-framework-bom-4.3.5.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/security/spring-security-ldap/4.2.1.RELEASE/spring-security-ldap-4.2.1.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/security/spring-security-web/4.2.1.RELEASE/spring-security-web-4.2.1.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/spring-tx/4.3.6.RELEASE/spring-tx-4.3.6.RELEASE.pom
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-annotations/2.8.6/jackson-annotations-2.8.6.pom
Download 
https://repo1.maven.org/maven2/org/springframework/security/spring-security-core/4.2.1.RELEASE/spring-security-core-4.2.1.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/ldap/spring-ldap-core/2.3.1.RELEASE/spring-ldap-core-2.3.1.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/springframework/security/spring-security-config/4.2.1.RELEASE/spring-security-config-4.2.1.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/springframework/security/spring-security-ldap/4.2.1.RELEASE/spring-security-ldap-4.2.1.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/springframework/security/spring-security-web/4.2.1.RELEASE/spring-security-web-4.2.1.RELEASE.jar
Download 

[jira] [Commented] (GEODE-2913) Update Lucene documentation

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/518#discussion_r117387903
  
--- Diff: geode-docs/tools_modules/lucene_integration.html.md.erb ---
@@ -219,7 +219,7 @@ at TestClient.main(TestClient.java:59)
 ```
 - If the Lucene index is not created prior to creating the region,
 an exception will be thrown while attempting to create the region,
--- End diff --

Please change 'create the region' to 'create a Lucene index'


> Update Lucene documentation
> ---
>
> Key: GEODE-2913
> URL: https://issues.apache.org/jira/browse/GEODE-2913
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Improvements to the code base that need to be reflected in the docs:
> * Change LuceneService.createIndex to use a factory pattern
> {code:java}
> luceneService.createIndex(region, index, ...)
> {code}
> changes to
> {code:java}
> luceneService.createIndexFactory()
> .addField("field1name")
> .addField("field2name")
> .create()
> {code}
> *  Lucene indexes will *NOT* be stored in off-heap memory.
> * Document how to configure an index on accessors - you still need to create 
> the Lucene index before creating the region, even though this member does not 
> hold any region data.
> If the index is not defined on the accessor, an exception like this will be 
> thrown while attempting to create the region:
> {quote}
> [error 2017/05/02 15:19:26.018 PDT  tid=0x1] 
> java.lang.IllegalStateException: Must create Lucene index full_index on 
> region /data because it is defined in another member.
> Exception in thread "main" java.lang.IllegalStateException: Must create 
> Lucene index full_index on region /data because it is defined in another 
> member.
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
> {quote}
> * Do not need to create a Lucene index on a client with a Proxy cache. The 
> Lucene search will always be done on the server.  Besides, _you can't create 
> an index on a client._
> * If you configure Invalidates for region entries (alone or as part of 
> expiration), these will *NOT* invalidate the Lucene indexes.
> The problem with this is the index contains the keys, but the region doesn't, 
> so the query produces results that don't exist.
> In this test, the first time the query is run, it produces N valid results. 
> The second time it is run it produces N empty results:
> ** load entries
> ** run query
> ** invalidate entries
> ** run query again
> *  Destroying a region will *NOT* automatically destroy any Lucene index 
> associated with that region. Instead, attempting to destroy a region with a 
> Lucene index will throw a colocated region exception. 
> An IllegalStateException is thrown:
> {quote}
> java.lang.IllegalStateException: The parent region [/data] in colocation 
> chain cannot be destroyed, unless all its children 
> [[/cusip_index#_data.files]] are destroyed
> at 
> org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
> at 
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
> at 
> DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
> {quote}
> * The process to change a Lucene index using gfsh: 
>   1. export region data
>   2. destroy Lucene index, destroy region 
>   3. create new index, create new region without user-defined business 
> logic callbacks
>   4. import data with option to turn on callbacks (to invoke Lucene Async 
> Event Listener to index the data)
>   5. alter region to add user-defined business logic callbacks
> * Make sure there are no references to replicated regions as they are not 
> supported.
> * Document security implementation and defaults.  If a user has security 
> configured for their cluster, creating a Lucene index requires DATA:MANAGE 
> privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE 
> privilege because a function is called (different from OQL which requires 
> only DATA:READ privilege). Here are all the required privileges for the gfsh 
> commands:
> ** create index requires DATA:MANAGE:region
> ** describe index requires CLUSTER:READ
> ** list indexes requires CLUSTER:READ
> ** 

[GitHub] geode pull request #518: GEODE-2913 Update Lucene index documentation

[dihardman]

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

https://github.com/apache/geode/pull/518#discussion_r117387903
  
--- Diff: geode-docs/tools_modules/lucene_integration.html.md.erb ---
@@ -219,7 +219,7 @@ at TestClient.main(TestClient.java:59)
 ```
 - If the Lucene index is not created prior to creating the region,
 an exception will be thrown while attempting to create the region,
--- End diff --

Please change 'create the region' to 'create a Lucene index'


---
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: Last call on 1.2.0 (and fixing test failures)

[Diane Rose Hardman]

Q team found a bug today during a gfsh bug hunt that needs to be fixed:
GEODE-2943. Lynn may have also found another data consistency bug, but I
don't have the bug number yet.
I also need to learn how to build the docs so I can review Karen's pull
request. Any help would be very much appreciated.

Diane

On Tue, May 16, 2017 at 5:10 PM, Darrel Schneider 
wrote:

>  FixedPRSinglehopDUnitTest. testMetadataInClientWithFixedPartitions seems
> like a problem that could cause lots of tests to fail intermittently.
> It looks like a race with the cluster config service starting up async in
> the locator.
> I added this failure to GEODE-2238.
>
> On Tue, May 16, 2017 at 3:17 PM, Bruce Schuchardt 
> wrote:
>
> > The fix for GEODE-2915 is on the develop branch.
> >
> >
> > Le 5/16/2017 à 10:10 AM, Anthony Baker a écrit :
> >
> >> On May 14, 2017, at 6:47 PM, Anthony Baker  wrote:
> >>>
> >>> Hi everyone,
> >>>
> >>> Our last release was v1.1.1 in March.  We have made a lot of great
> >>> progress on the develop branch with over 250 issues fixed.  It would be
> >>> great to get those changes into a release.  What’s left before we are
> ready
> >>> to release 1.2.0?
> >>>
> >>> Note that we need a clean test run before releasing (except for “flaky"
> >>> tests).  We haven’t had one of those in awhile [1].
> >>>
> >>> Anthony
> >>>
> >>> [1] https://builds.apache.org/job/Geode-nightly/lastCompletedBui
> >>> ld/testReport/
> >>>
> >>> Thanks for all the responses.  To summarize:
> >>
> >> GEODE-2913:  Update Lucene documentation
> >> GEODE-2836:  CacheLoader should extend Declarable
> >> GEODE-2912:  Real hot deploy of functions via gfsh [DONE]
> >> GEODE-2900:  BucketRegionQueue transitions from
> primary/secondary/primary
> >> can lead to events lingering in queue [DONE]
> >> GEODE-2915:  Messages rejected due to unknown “vmkind"
> >> (backwards compatibility and rolling upgrades against v1.1.1
> also
> >> covered by this issue)
> >>
> >> The last Jenkins run shows these failures:
> >>
> >> org.apache.geode.management.internal.cli.commands.ShowDeadlo
> >> ckDUnitTest.testDistributedDeadlockWithFunction
> >> org.apache.geode.management.internal.cli.commands.ShowDeadlo
> >> ckDUnitTest.testNoDeadlock
> >> org.apache.geode.management.internal.cli.commands.Concurrent
> >> DeployDUnitTest.testMultipleGfshClientToOneServer
> >>
> >> The v1.2.0 version in JIRA has these unresolved issues:
> >>
> >> GEODE-2428:  Add support for LinkedHashMap in DataSerializer
> >> This was reopened to clean up some Javadocs.
> >>
> >> GEODE-2855:  Document Rename Execution.withArgs to
> Execution.setArguments
> >> This is a documentation task for an API change.
> >>
> >> GEODE-2880:  value auto complete for member and file names does not work
> >> This appears to be non-critical bug fix.  I think we could skip
> >> this one.
> >>
> >>
> >> Anything else?
> >>
> >> Anthony
> >>
> >>
> >
>

Review Request 59386: GEODE-2929: remove superfluous uses of final to facilitate mocking

[Kirk Lund]

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

Review request for geode, Anthony Baker, Bruce Schuchardt, Darrel Schneider, 
Jinmei Liao, Jared Stewart, Ken Howe, Patrick Rhomberg, and Dan Smith.


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


Repository: geode


Description
---

This is the last batch of changes to remove final modifiers from methods so 
they can be mocked in unit tests. I also added new unit tests for some of the 
classes to verify that the class and its previously-final methods can be mocked.


Diffs
-

  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestInterfaceJUnitTest.java
 324284e6bcddcbfe312d10629db2215b019b8769 
  geode-core/src/main/java/org/apache/geode/CancelCriterion.java 
fec38272b75fe8081e140784a13ff76eb5c6bbf4 
  geode-core/src/main/java/org/apache/geode/CanonicalInstantiator.java 
10e6f164ca9dcd444ce722d14cc514c170c33a92 
  geode-core/src/main/java/org/apache/geode/DataSerializer.java 
34501f8496707843b7e9546e4fb486466f16001a 
  geode-core/src/main/java/org/apache/geode/Instantiator.java 
e4da556ed398b73c21dcfd975db03194b03a7e18 
  geode-core/src/main/java/org/apache/geode/admin/RegionSubRegionSnapshot.java 
19f89b251f2ccf4a553c619500a855217b9ee064 
  geode-core/src/main/java/org/apache/geode/cache/DiskAccessException.java 
e77e485f7349a0179eb31b80f30ea6ccecf982fa 
  geode-core/src/main/java/org/apache/geode/cache/DynamicRegionFactory.java 
9bf14cdfe2fc22965a9b929e927c4ff50dd115d3 
  geode-core/src/main/java/org/apache/geode/cache/EvictionAction.java 
a8513d96cf91599b182844a32b960ec6f5e77b4b 
  geode-core/src/main/java/org/apache/geode/cache/EvictionAlgorithm.java 
96b55b6af048bfa1ab487a70e85d456d9d1d9dd7 
  geode-core/src/main/java/org/apache/geode/cache/EvictionAttributes.java 
8c30b30a224b54e3d059a5191473833982f4561b 
  geode-core/src/main/java/org/apache/geode/cache/FixedPartitionAttributes.java 
dd8bd94ed983b99ae35529dfc5816e363340d6e3 
  geode-core/src/main/java/org/apache/geode/cache/MembershipAttributes.java 
79f7d8aaeef89590fdd5290d6c403eb13da21589 
  
geode-core/src/main/java/org/apache/geode/cache/client/internal/AbstractOp.java 
593375e62bbe34aa129643d27472bc9d6dea2460 
  
geode-core/src/main/java/org/apache/geode/cache/execute/FunctionException.java 
3198b0d17b962b538e3c207274c28d7c5b3358a9 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/ObjectIntHashMap.java
 d0cf5dbae0777522fa1436e73a0d50ceb9110502 
  geode-core/src/main/java/org/apache/geode/compression/SnappyCompressor.java 
63248235d7eb6990101fdb6532d72cee44b40ac5 
  geode-core/src/main/java/org/apache/geode/distributed/AbstractLauncher.java 
feba8937b216d374acd8357775d5d1806568b355 
  geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
641e009d5e9fe646684fe65d91110805fe589b91 
  geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
b2d01511e4868b7055521901d378aa5efaefe203 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionAdvisor.java
 4eb988836ca44257c8f5248d4fe08ce321b73896 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
 f4e547fa3d196e20844b00f0f10bd2ca51a2069a 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionMessage.java
 403b4205f74a919e58648227937e68b90f681215 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/ReplyProcessor21.java
 7e87c8c8b4bdded4a15fa4ce7e71ebfd519f717e 
  geode-core/src/main/java/org/apache/geode/internal/AbstractConfig.java 
101ee63a138b64e82d87968b3fd2012888dbc1ca 
  geode-core/src/main/java/org/apache/geode/internal/HeapDataOutputStream.java 
ae281200384387440d6fdd9dcd8532a78f5a7198 
  geode-core/src/main/java/org/apache/geode/internal/ObjIdConcurrentMap.java 
17894ad51428112c4c635b307a25047a8420621a 
  geode-core/src/main/java/org/apache/geode/internal/SharedLibrary.java 
7faebe9de784946f29cd062c7fda492071e1d7c7 
  geode-core/src/main/java/org/apache/geode/internal/SystemTimer.java 
16227d25b467012e5c121de243d775a467ce1808 
  
geode-core/src/main/java/org/apache/geode/internal/cache/AbstractDiskRegion.java
 81011d3a2863e5d387b0c4ac8b55d17437287836 
  
geode-core/src/main/java/org/apache/geode/internal/cache/AbstractLRURegionMap.java
 bcaa0d08ef430f530abb4323ef2e5dbf40265b32 
  
geode-core/src/main/java/org/apache/geode/internal/cache/AbstractOplogDiskRegionEntry.java
 866ff036860eec8410728779d157ff22ac50f61b 
  geode-core/src/main/java/org/apache/geode/internal/cache/AbstractRegion.java 
ac5fb37fa76c6ab5fd0832fb7a72bbc73fcfa7f1 
  
geode-core/src/main/java/org/apache/geode/internal/cache/AbstractRegionMap.java 
5dcf3bca28f3e1e6af8ad13a9d6ee18d3b8a342d 
  geode-core/src/main/java/org/apache/geode/internal/cache/BucketAdvisor.java 
04a48d09d1920adbcf688f86ec6943cda3603706 
  

[jira] [Commented] (GEODE-2913) Update Lucene documentation

[ASF GitHub Bot (JIRA)]

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

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

Github user karensmolermiller commented on the issue:

https://github.com/apache/geode/pull/518
  
Thanks joeymcallister.  All suggested corrections have been made.


> Update Lucene documentation
> ---
>
> Key: GEODE-2913
> URL: https://issues.apache.org/jira/browse/GEODE-2913
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Improvements to the code base that need to be reflected in the docs:
> * Change LuceneService.createIndex to use a factory pattern
> {code:java}
> luceneService.createIndex(region, index, ...)
> {code}
> changes to
> {code:java}
> luceneService.createIndexFactory()
> .addField("field1name")
> .addField("field2name")
> .create()
> {code}
> *  Lucene indexes will *NOT* be stored in off-heap memory.
> * Document how to configure an index on accessors - you still need to create 
> the Lucene index before creating the region, even though this member does not 
> hold any region data.
> If the index is not defined on the accessor, an exception like this will be 
> thrown while attempting to create the region:
> {quote}
> [error 2017/05/02 15:19:26.018 PDT  tid=0x1] 
> java.lang.IllegalStateException: Must create Lucene index full_index on 
> region /data because it is defined in another member.
> Exception in thread "main" java.lang.IllegalStateException: Must create 
> Lucene index full_index on region /data because it is defined in another 
> member.
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
> {quote}
> * Do not need to create a Lucene index on a client with a Proxy cache. The 
> Lucene search will always be done on the server.  Besides, _you can't create 
> an index on a client._
> * If you configure Invalidates for region entries (alone or as part of 
> expiration), these will *NOT* invalidate the Lucene indexes.
> The problem with this is the index contains the keys, but the region doesn't, 
> so the query produces results that don't exist.
> In this test, the first time the query is run, it produces N valid results. 
> The second time it is run it produces N empty results:
> ** load entries
> ** run query
> ** invalidate entries
> ** run query again
> *  Destroying a region will *NOT* automatically destroy any Lucene index 
> associated with that region. Instead, attempting to destroy a region with a 
> Lucene index will throw a colocated region exception. 
> An IllegalStateException is thrown:
> {quote}
> java.lang.IllegalStateException: The parent region [/data] in colocation 
> chain cannot be destroyed, unless all its children 
> [[/cusip_index#_data.files]] are destroyed
> at 
> org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
> at 
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
> at 
> DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
> {quote}
> * The process to change a Lucene index using gfsh: 
>   1. export region data
>   2. destroy Lucene index, destroy region 
>   3. create new index, create new region without user-defined business 
> logic callbacks
>   4. import data with option to turn on callbacks (to invoke Lucene Async 
> Event Listener to index the data)
>   5. alter region to add user-defined business logic callbacks
> * Make sure there are no references to replicated regions as they are not 
> supported.
> * Document security implementation and defaults.  If a user has security 
> configured for their cluster, creating a Lucene index requires DATA:MANAGE 
> privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE 
> privilege because a function is called (different from OQL which requires 
> only DATA:READ privilege). Here are all the required privileges for the gfsh 
> commands:
> ** create index requires DATA:MANAGE:region
> ** describe index requires CLUSTER:READ
> ** list indexes requires CLUSTER:READ
> ** search index requires DATA:WRITE
> ** destroy index requires DATA:MANAGE:region
> * A user cannot create a Lucene index on a region that has eviction 
> configured with local destroy. If using Lucene indexing, eviction can only be 
> configured with overflow to disk. In this case, only the region data is 
> overflowed to disk, *NOT* the 

[GitHub] geode issue #518: GEODE-2913 Update Lucene index documentation

[karensmolermiller]

Github user karensmolermiller commented on the issue:

https://github.com/apache/geode/pull/518
  
Thanks joeymcallister.  All suggested corrections have been made.


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

Review Request 59384: GEODE-1930: temporarily disable verifySystemNotifications

[Kirk Lund]

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

Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
Rhomberg.


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


Repository: geode


Description
---

I'm consistently seeing RegionManagementDUnitTest.testRegionAggregate fail in 
verifySystemNotifications which is at the very end of the test. I think there 
must be something async going on that we need to find and Await on.

Until one of us has time to fix verifySystemNotifications, I'd like to comment 
out that one line so we aren't seeing this fail every precheckin.

I used GEODE-1930 which is a ticket to refactor the Management DUnit tests 
because it's still open until we can finish refactoring the last couple 
Management DUnit tests which includes RegionManagementDUnitTest.


Diffs
-

  
geode-core/src/test/java/org/apache/geode/management/RegionManagementDUnitTest.java
 7dabd61d51f8598640537b661ecbb076b212cd0d 


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


Testing
---

precheckin in progress


Thanks,

Kirk Lund

What to do with Singletons

[Kirk Lund]

I've been digging through our code with close attention to the singletons.
I believe the majority of singletons in Geode exist for two main reasons:

1) Insufficient context or lack of service lookup for Function,
DistributionMessage and (Client)Command implementations.

2) Poor OO design. This is where you see code in one class invoking
concrete methods on another class outside of its concerns. Many of these
need to be teased apart and replaced with some sort of Observer that
isolates the reaction from the source of the originating event.

Right now my focus is on #1 because that's the area that's currently an
obstacle for me.

Function, DistributionMessage and (Client)Command classes need to have more
context provided to them (Cache, Security, etc) or they need a better
mechanism to look up these services. Currently these classes reach out to
singletons in order to "get" what they need.

*A) Function*

The main entry-point which injects services into the Function is:

public void execute(FunctionContext context);

The FunctionContext needs to provide the service(s) that any Function might
require. This could include Cache, DistributionManager and maybe
SecurityService (anything else?).

*B) (Peer-to-peer) DistributionMessage*

The main entry-point which injects services into the DistributionMessage is:

protected abstract void process(DistributionManager dm);

We could provide multiple arguments or a single new DistributionContext
which then provides DistributionManager and Cache (anything else?).

*C) (Client) Command*

The main entry-point which injects services into the Command is:

public void execute(Message msg, ServerConnection servConn);

ServerConnection is huge but it does already expose Cache. BaseCommand is
the only Command that implements "execute" and it defines a new entry-point
for injection:

abstract public void cmdExecute(Message msg, ServerConnection servConn,
long start) throws IOException, ClassNotFoundException,
InterruptedException;

We might want to clean that up and define a new CommandContext which
provides the Cache or anything else that the Command may need.

Thoughts or additional ideas?

[jira] [Commented] (GEODE-1994) Change geode StringUtils to extend commons StringUtils

[ASF GitHub Bot (JIRA)]

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

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

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/521
  
precheckin has cleared most tests.  Waiting on DistributedTest to finish.  
:geode-core cleared, currently waiting on :geode-wan.  I've seen some 
:geode-wan failures on a fresh develop (a lot of Connection Refused), but will 
reply to this thread tomorrow with the DUnit results.


> Change geode StringUtils to extend commons StringUtils
> --
>
> Key: GEODE-1994
> URL: https://issues.apache.org/jira/browse/GEODE-1994
> Project: Geode
>  Issue Type: Wish
>  Components: general, management
>Reporter: Kirk Lund
>Assignee: Patrick Rhomberg
>
> org.apache.geode.internal.lang.StringUtils duplicates some of the methods in 
> org.apache.commons.lang.StringUtils with some inconsistencies.
> isBlank is implemented identically
> isEmpty is inconsistent -- commons version returns true if string is null, 
> while geode version returns false if string is null



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

[GitHub] geode issue #521: GEODE-1994: Overhaul of internal.lang.StringUtils to exten...

[PurelyApplied]

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/521
  
precheckin has cleared most tests.  Waiting on DistributedTest to finish.  
:geode-core cleared, currently waiting on :geode-wan.  I've seen some 
:geode-wan failures on a fresh develop (a lot of Connection Refused), but will 
reply to this thread tomorrow with the DUnit results.


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

[jira] [Updated] (GEODE-2948) Inconsistency in gfsh prompts related to lucene commands

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey updated GEODE-2948:
---
Affects Version/s: 1.2.0

> Inconsistency in gfsh prompts related to lucene commands
> 
>
> Key: GEODE-2948
> URL: https://issues.apache.org/jira/browse/GEODE-2948
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>
> There are some inconsistencies in how we present parameters and establish 
> settings within the lucene gfsh commands.
> For example, with `list lucene indexes` the user is prompted with the 
> optional parameter 'with-stats'.  However, on `import data`, the user is only 
> prompted with the required parameters (which does not include 
> invoke-callbacks).  This is probably because there are no required parameters 
> for list lucene indexes ... and import data does show you the 
> invoke-callbacks after all required fields have been provided. 
> In addition, with `list lucene indexes`, specifying --with-stats is the same 
> thing as entering --with-stats=true.  However, on `import data`, the 
> --invoke-callbacks REQUIRES the full specification of 
> --invoke-callbacks=true.  Otherwise, the following error results:
> {noformat}
> gfsh>import data --file=./testRegion.gfd --region=testRegion3 
> --member=server50505 --invoke-callbacks
> Nulls cannot be presented to primitive type boolean for option 
> 'invoke-callbacks'
> {noformat}
> help text
> {noformat}
> gfsh>help import data
> NAME
> import data
> IS AVAILABLE
> true
> SYNOPSIS
> Import user data from a file to a region.
> SYNTAX
> import data --region=value --file=value --member=value 
> [--invoke-callbacks=value]
> PARAMETERS
> region
> Region into which data will be imported.
> Required: true
> file
> File from which the imported data will be read. The file must have an 
> extension of ".gfd".
> Required: true
> member
> Name/Id of a member which hosts the region. The data will be imported 
> from the specified file on the host where the member is running.
> Required: true
> invoke-callbacks
> Whether callbacks should be invoked
> Required: false
> Default (if the parameter is not specified): false
> gfsh>help list lucene indexes
> NAME
> list lucene indexes
> IS AVAILABLE
> true
> SYNOPSIS
> Display the list of lucene indexes created for all members.
> SYNTAX
> list lucene indexes [--with-stats(=value)?]
> PARAMETERS
> with-stats
> Display lucene index stats
> Required: false
> Default (if the parameter is specified without value): true
> Default (if the parameter is not specified): false
> {noformat}



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

[jira] [Created] (GEODE-2948) Inconsistency in gfsh prompts related to lucene commands

[Shelley Lynn Hughes-Godfrey (JIRA)]

Shelley Lynn Hughes-Godfrey created GEODE-2948:
--

 Summary: Inconsistency in gfsh prompts related to lucene commands
 Key: GEODE-2948
 URL: https://issues.apache.org/jira/browse/GEODE-2948
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Shelley Lynn Hughes-Godfrey


There are some inconsistencies in how we present parameters and establish 
settings within the lucene gfsh commands.

For example, with `list lucene indexes` the user is prompted with the optional 
parameter 'with-stats'.  However, on `import data`, the user is only prompted 
with the required parameters (which does not include invoke-callbacks).  This 
is probably because there are no required parameters for list lucene indexes 
... and import data does show you the invoke-callbacks after all required 
fields have been provided. 

In addition, with `list lucene indexes`, specifying --with-stats is the same 
thing as entering --with-stats=true.  However, on `import data`, the 
--invoke-callbacks REQUIRES the full specification of --invoke-callbacks=true.  
Otherwise, the following error results:

{noformat}
gfsh>import data --file=./testRegion.gfd --region=testRegion3 
--member=server50505 --invoke-callbacks
Nulls cannot be presented to primitive type boolean for option 
'invoke-callbacks'
{noformat}

help text
{noformat}
gfsh>help import data
NAME
import data
IS AVAILABLE
true
SYNOPSIS
Import user data from a file to a region.
SYNTAX
import data --region=value --file=value --member=value 
[--invoke-callbacks=value]
PARAMETERS
region
Region into which data will be imported.
Required: true
file
File from which the imported data will be read. The file must have an 
extension of ".gfd".
Required: true
member
Name/Id of a member which hosts the region. The data will be imported 
from the specified file on the host where the member is running.
Required: true
invoke-callbacks
Whether callbacks should be invoked
Required: false
Default (if the parameter is not specified): false


gfsh>help list lucene indexes
NAME
list lucene indexes
IS AVAILABLE
true
SYNOPSIS
Display the list of lucene indexes created for all members.
SYNTAX
list lucene indexes [--with-stats(=value)?]
PARAMETERS
with-stats
Display lucene index stats
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): false
{noformat}



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

[jira] [Commented] (GEODE-1994) Change geode StringUtils to extend commons StringUtils

[ASF GitHub Bot (JIRA)]

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

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

GitHub user PurelyApplied opened a pull request:

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

GEODE-1994: Overhaul of internal.lang.StringUtils to extend and heavily use 
commons.lang.StringUtils

*   geode.internal.lang.StringUtils has been deprecated.  In the interim, 
it has been heavily refactored and extends commons.lang.StringUtils.
*
*   Renamed:
*   --  EMPTY_STRING -> EMPTY (inherited)
*   --  toUpperCase  -> upperCase (inherited)
*   --  toLowerCase  -> lowerCase (inherited)
*   --  padEnding-> rightPad (inherited)
*
*   Removed:
*   --  EMPTY_STRING_ARRAY; usage replaced with 
commons.lang.ArrayUtils.EMPTY_STRING_ARRAY
*   --  SPACES
*   --  UTF_8; rare usage replaced with raw string
*   --  concat; usage replaced with commons.lang.join, refactoring as 
necessary.
*   --  getLettersOnly
*   --  getSpaces
*   --  truncate
*   --  valueOf; usage refactored to use defaultString
*
*   Refactored
*   --  defaultIfBlank: previously relied on varargs and could return null. 
 Usage refactored to allow inheritance from commons.
*   --  defaultString(s, EMPTY) refactored to use standard signature 
defaultString(s) for consistency throughout codebase.
*   --  isBlank: usage refactored to resolve discrepancies with 
commons.lang.isBlank, which is now inherited.
*   --  isEmpty: usage refactored to resolve discrepancies with 
commons.lang.isEmpty, which is now inherited.
*
*   Code Cleanup:
*   --  Many uses of !isBlank -> isNotBlank
*   --  Changes suggested by Inspections on most touched files.
*   -- Explicit  -> <> when type is inferable
*   -- while loops operating on iterators converted to for each loops
*   -- for loops operating on array indices converted to for each loops
*   --  Various string typos corrected.
*   --  isEmpty(s.trim()) -> isBlank(s)
*   --  s.trim().isEmpty() -> isEmpty(s)
*   --  Removed some instances of 'dead' code
*   --  Optimized imports in every touched file
*
*   Qualitative Changes:
*   --  The following functions now throw an error when called with a null 
string input:
*   --  *  LocatorLauncher.Builder.setMemberName
*   --  *  ServerLauncher.Builder.setMemberName
*   --  *  ServerLauncher.Builder.setHostnameForClients
*   --  (Unit tests added to capture these changes)
*
*   Notes:
*   --  StringUtils.wraps may be inherited from Apache Commons when the 
dependency is updated.
*   --  AbstractLauncher.getMember has the documented behavior of returning 
null when both MemberName and ID are blank.  Is this the best behavior for this 
method?


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

$ git pull https://github.com/PurelyApplied/geode geode-1994

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

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


commit 327e1ae4b7b6e3503b0e295e6c883c387fa03b47
Author: Patrick Rhomberg 
Date:   2017-05-17T23:57:07Z

GEODE-1994: Overhaul of internal.lang.StringUtils to extend and heavily use 
commons.lang.StringUtils

*   geode.internal.lang.StringUtils has been deprecated.  In the interim, 
it has been heavily refactored and extends commons.lang.StringUtils.
*
*   Renamed:
*   --  EMPTY_STRING -> EMPTY (inherited)
*   --  toUpperCase  -> upperCase (inherited)
*   --  toLowerCase  -> lowerCase (inherited)
*   --  padEnding-> rightPad (inherited)
*
*   Removed:
*   --  EMPTY_STRING_ARRAY; usage replaced with 
commons.lang.ArrayUtils.EMPTY_STRING_ARRAY
*   --  SPACES
*   --  UTF_8; rare usage replaced with raw string
*   --  concat; usage replaced with commons.lang.join, refactoring as 
necessary.
*   --  getLettersOnly
*   --  getSpaces
*   --  truncate
*   --  valueOf; usage refactored to use defaultString
*
*   Refactored
*   --  defaultIfBlank: previously relied on varargs and could return null. 
 Usage refactored to allow inheritance from commons.
*   --  defaultString(s, EMPTY) refactored to use standard signature 
defaultString(s) for consistency throughout codebase.
*   --  isBlank: usage refactored to resolve discrepancies with 
commons.lang.isBlank, which is now inherited.
*   --  isEmpty: usage refactored to resolve discrepancies with 
commons.lang.isEmpty, which is now inherited.
*
*   Code Cleanup:
*   --  Many uses of !isBlank -> isNotBlank
*   --  

[GitHub] geode pull request #521: GEODE-1994: Overhaul of internal.lang.StringUtils t...

[PurelyApplied]

GitHub user PurelyApplied opened a pull request:

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

GEODE-1994: Overhaul of internal.lang.StringUtils to extend and heavily use 
commons.lang.StringUtils

*   geode.internal.lang.StringUtils has been deprecated.  In the interim, 
it has been heavily refactored and extends commons.lang.StringUtils.
*
*   Renamed:
*   --  EMPTY_STRING -> EMPTY (inherited)
*   --  toUpperCase  -> upperCase (inherited)
*   --  toLowerCase  -> lowerCase (inherited)
*   --  padEnding-> rightPad (inherited)
*
*   Removed:
*   --  EMPTY_STRING_ARRAY; usage replaced with 
commons.lang.ArrayUtils.EMPTY_STRING_ARRAY
*   --  SPACES
*   --  UTF_8; rare usage replaced with raw string
*   --  concat; usage replaced with commons.lang.join, refactoring as 
necessary.
*   --  getLettersOnly
*   --  getSpaces
*   --  truncate
*   --  valueOf; usage refactored to use defaultString
*
*   Refactored
*   --  defaultIfBlank: previously relied on varargs and could return null. 
 Usage refactored to allow inheritance from commons.
*   --  defaultString(s, EMPTY) refactored to use standard signature 
defaultString(s) for consistency throughout codebase.
*   --  isBlank: usage refactored to resolve discrepancies with 
commons.lang.isBlank, which is now inherited.
*   --  isEmpty: usage refactored to resolve discrepancies with 
commons.lang.isEmpty, which is now inherited.
*
*   Code Cleanup:
*   --  Many uses of !isBlank -> isNotBlank
*   --  Changes suggested by Inspections on most touched files.
*   -- Explicit  -> <> when type is inferable
*   -- while loops operating on iterators converted to for each loops
*   -- for loops operating on array indices converted to for each loops
*   --  Various string typos corrected.
*   --  isEmpty(s.trim()) -> isBlank(s)
*   --  s.trim().isEmpty() -> isEmpty(s)
*   --  Removed some instances of 'dead' code
*   --  Optimized imports in every touched file
*
*   Qualitative Changes:
*   --  The following functions now throw an error when called with a null 
string input:
*   --  *  LocatorLauncher.Builder.setMemberName
*   --  *  ServerLauncher.Builder.setMemberName
*   --  *  ServerLauncher.Builder.setHostnameForClients
*   --  (Unit tests added to capture these changes)
*
*   Notes:
*   --  StringUtils.wraps may be inherited from Apache Commons when the 
dependency is updated.
*   --  AbstractLauncher.getMember has the documented behavior of returning 
null when both MemberName and ID are blank.  Is this the best behavior for this 
method?


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

$ git pull https://github.com/PurelyApplied/geode geode-1994

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

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


commit 327e1ae4b7b6e3503b0e295e6c883c387fa03b47
Author: Patrick Rhomberg 
Date:   2017-05-17T23:57:07Z

GEODE-1994: Overhaul of internal.lang.StringUtils to extend and heavily use 
commons.lang.StringUtils

*   geode.internal.lang.StringUtils has been deprecated.  In the interim, 
it has been heavily refactored and extends commons.lang.StringUtils.
*
*   Renamed:
*   --  EMPTY_STRING -> EMPTY (inherited)
*   --  toUpperCase  -> upperCase (inherited)
*   --  toLowerCase  -> lowerCase (inherited)
*   --  padEnding-> rightPad (inherited)
*
*   Removed:
*   --  EMPTY_STRING_ARRAY; usage replaced with 
commons.lang.ArrayUtils.EMPTY_STRING_ARRAY
*   --  SPACES
*   --  UTF_8; rare usage replaced with raw string
*   --  concat; usage replaced with commons.lang.join, refactoring as 
necessary.
*   --  getLettersOnly
*   --  getSpaces
*   --  truncate
*   --  valueOf; usage refactored to use defaultString
*
*   Refactored
*   --  defaultIfBlank: previously relied on varargs and could return null. 
 Usage refactored to allow inheritance from commons.
*   --  defaultString(s, EMPTY) refactored to use standard signature 
defaultString(s) for consistency throughout codebase.
*   --  isBlank: usage refactored to resolve discrepancies with 
commons.lang.isBlank, which is now inherited.
*   --  isEmpty: usage refactored to resolve discrepancies with 
commons.lang.isEmpty, which is now inherited.
*
*   Code Cleanup:
*   --  Many uses of !isBlank -> isNotBlank
*   --  Changes suggested by Inspections on most touched files.
*   -- Explicit  -> <> when type is inferable
*   -- while loops operating on iterators converted to for each loops
*   -- for loops operating on array indices 

[jira] [Updated] (GEODE-2947) Improve error message (seen in gfsh) when attempting to destroy a region before destroying lucene indexes

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey updated GEODE-2947:
---
Affects Version/s: 1.2.0

> Improve error message (seen in gfsh) when attempting to destroy a region 
> before destroying lucene indexes
> -
>
> Key: GEODE-2947
> URL: https://issues.apache.org/jira/browse/GEODE-2947
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>
> If a user attempta to destroy region before destroying the lucene index (via 
> gfsh), the error message returned is not clear.  It should state that the 
> lucene index should be destroyed prior to destroying the region.  
> Instead it states this:
> {noformat}
> Error occurred while destroying region "testRegion". Reason: The parent 
> region [/testRegion] in colocation chain cannot be destroyed, unless all its 
> children [[/testIndex#_testRegion.files]] are destroyed
> {noformat}



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

[jira] [Created] (GEODE-2947) Improve error message (seen in gfsh) when attempting to destroy a region before destroying lucene indexes

[Shelley Lynn Hughes-Godfrey (JIRA)]

Shelley Lynn Hughes-Godfrey created GEODE-2947:
--

 Summary: Improve error message (seen in gfsh) when attempting to 
destroy a region before destroying lucene indexes
 Key: GEODE-2947
 URL: https://issues.apache.org/jira/browse/GEODE-2947
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Shelley Lynn Hughes-Godfrey


If a user attempta to destroy region before destroying the lucene index (via 
gfsh), the error message returned is not clear.  It should state that the 
lucene index should be destroyed prior to destroying the region.  

Instead it states this:
{noformat}
Error occurred while destroying region "testRegion". Reason: The parent region 
[/testRegion] in colocation chain cannot be destroyed, unless all its children 
[[/testIndex#_testRegion.files]] are destroyed
{noformat}



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

[jira] [Updated] (GEODE-2946) Extend pulse data browser to support lucene queries

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey updated GEODE-2946:
---
Summary: Extend pulse data browser to support lucene queries  (was: The 
pulse data browser allows OQL queries to view region data)

> Extend pulse data browser to support lucene queries
> ---
>
> Key: GEODE-2946
> URL: https://issues.apache.org/jira/browse/GEODE-2946
> Project: Geode
>  Issue Type: New Feature
>  Components: lucene, pulse
>Reporter: Shelley Lynn Hughes-Godfrey
>
> It would be nice to allow lucene queries through the pulse data browser



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

[jira] [Created] (GEODE-2946) The pulse data browser allows OQL queries to view region data

[Shelley Lynn Hughes-Godfrey (JIRA)]

Shelley Lynn Hughes-Godfrey created GEODE-2946:
--

 Summary: The pulse data browser allows OQL queries to view region 
data
 Key: GEODE-2946
 URL: https://issues.apache.org/jira/browse/GEODE-2946
 Project: Geode
  Issue Type: New Feature
  Components: lucene, pulse
Reporter: Shelley Lynn Hughes-Godfrey


It would be nice to allow lucene queries through the pulse data browser



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

[jira] [Created] (GEODE-2945) lucene search prompts in gfsh make it appear that limit, pageSize and keys-only are required fields

[Shelley Lynn Hughes-Godfrey (JIRA)]

Shelley Lynn Hughes-Godfrey created GEODE-2945:
--

 Summary: lucene search prompts in gfsh make it appear that limit, 
pageSize and keys-only are required fields
 Key: GEODE-2945
 URL: https://issues.apache.org/jira/browse/GEODE-2945
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Shelley Lynn Hughes-Godfrey


gfsh command for lucene search prompts make it appear that limit, pageSize and 
keys-only are required parameters.

The lucene search command below is missing the --defaultField specification, 
but the resulting gfsh prompts make it appear that limit, pageSize and 
keys-only are also required ("You should specify option"):

{noformat}
gfsh>search lucene --name=testIndex --region=/testRegion --queryStrings="number"
You should specify option (--defaultField, --limit, --pageSize, --keys-only) 
for this command
{noformat}

help shows this is not the case, but we could make this easier
{noformat}
gfsh>help search lucene
NAME
search lucene
IS AVAILABLE
true
SYNOPSIS
Search lucene index
SYNTAX
search lucene --name=value --region=value --queryStrings=value 
--defaultField=value [--limit=value] [--pageSize=value] [--keys-only=value]
PARAMETERS
name
Name of the lucene index to search.
Required: true
region
Name/Path of the region defining the lucene index to be searched.
Required: true
queryStrings
Query string to search the lucene index
Required: true
defaultField
Default field to search in
Required: true
limit
Number of search results needed
Required: false
Default (if the parameter is not specified): -1
pageSize
Number of results to be returned in a page
Required: false
Default (if the parameter is not specified): -1
keys-only
Return only keys of search results.
Required: false
Default (if the parameter is not specified): false
{noformat}



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

[jira] [Created] (GEODE-2944) lucene queries on String values (vs. objects) requires obscure/undocumented defaultField (__REGION_VALUE_FIELD)

[Shelley Lynn Hughes-Godfrey (JIRA)]

Shelley Lynn Hughes-Godfrey created GEODE-2944:
--

 Summary: lucene queries on String values (vs. objects) requires 
obscure/undocumented defaultField (__REGION_VALUE_FIELD)
 Key: GEODE-2944
 URL: https://issues.apache.org/jira/browse/GEODE-2944
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Shelley Lynn Hughes-Godfrey


When a lucene index is created, one must indicate the field to create the index 
on.  When the object value is a simple String, that must be specified as 
--field=__REGION_VALUE_FIELD.

For example,
create lucene index --name=newIndex --region=testRegion 
--field=__REGION_VALUE_FIELD

However, the lucene help text (for the gfsh command) does not provide this 
detail.  In addition, it seems that when executing a lucene search, this must 
be entered again as --defaultField=__REGION_VALUE_FIELD.

While this is probably not something one would use in production, I imagine it 
will be used by developers experimenting with Lucene, so we should consider 
adding this to the help text.



{noformat}
gfsh>help create lucene index
NAME
create lucene index
IS AVAILABLE
true
SYNOPSIS
Create a lucene index that can be used to execute queries.
SYNTAX
create lucene index --name=value --region=value --field=value(,value)* 
[--analyzer=value(,value)*]
PARAMETERS
name
Name of the lucene index to create.
Required: true
region
Name/Path of the region on which to create the lucene index.
Required: true
field
fields on the region values which are stored in the lucene index.
Required: true
analyzer
Type of the analyzer for each field.
Required: false
{noformat}



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

[jira] [Updated] (GEODE-2944) lucene queries on String values (vs. objects) requires obscure/undocumented defaultField (__REGION_VALUE_FIELD)

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey updated GEODE-2944:
---
Affects Version/s: 1.2.0

> lucene queries on String values (vs. objects) requires obscure/undocumented 
> defaultField (__REGION_VALUE_FIELD)
> ---
>
> Key: GEODE-2944
> URL: https://issues.apache.org/jira/browse/GEODE-2944
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>
> When a lucene index is created, one must indicate the field to create the 
> index on.  When the object value is a simple String, that must be specified 
> as --field=__REGION_VALUE_FIELD.
> For example,
> create lucene index --name=newIndex --region=testRegion 
> --field=__REGION_VALUE_FIELD
> However, the lucene help text (for the gfsh command) does not provide this 
> detail.  In addition, it seems that when executing a lucene search, this must 
> be entered again as --defaultField=__REGION_VALUE_FIELD.
> While this is probably not something one would use in production, I imagine 
> it will be used by developers experimenting with Lucene, so we should 
> consider adding this to the help text.
> {noformat}
> gfsh>help create lucene index
> NAME
> create lucene index
> IS AVAILABLE
> true
> SYNOPSIS
> Create a lucene index that can be used to execute queries.
> SYNTAX
> create lucene index --name=value --region=value --field=value(,value)* 
> [--analyzer=value(,value)*]
> PARAMETERS
> name
> Name of the lucene index to create.
> Required: true
> region
> Name/Path of the region on which to create the lucene index.
> Required: true
> field
> fields on the region values which are stored in the lucene index.
> Required: true
> analyzer
> Type of the analyzer for each field.
> Required: false
> {noformat}



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

[jira] [Updated] (GEODE-2943) Invalid queryStrings cause lucene searches to hang in in PR with multiple nodes

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey updated GEODE-2943:
---
Description: 
Some invalid query strings might be "*" or " ".

When used with a single node dataStore, we see the correct Exception returned:
{noformat}
gfsh>search lucene --name=testIndex --region=/testRegion --queryStrings="*" 
--defaultField=__REGION_VALUE_FIELD
Could not process command due to GemFire error. An error occurred while 
searching lucene index across the Geode cluster: Leading wildcard is not 
allowed: __REGION_VALUE_FIELD:*
{noformat}

However, with multiple nodes, the query hangs. 

Jason debugged this a bit and found:
{noformat}
the remote nodes fail in the function with this stack trace (where we will 
probably need to try/catch any lucene exception)
[warning 2017/05/18 13:50:34.105 PDT server2  
tid=0x3c]
org.apache.geode.cache.lucene.LuceneQueryException: Malformed lucene query: 
*asdf*
at 
org.apache.geode.cache.lucene.internal.StringQueryProvider.getQuery(StringQueryProvider.java:79)
at 
org.apache.geode.cache.lucene.internal.distributed.LuceneQueryFunction.getQuery(LuceneQueryFunction.java:160)
at 
org.apache.geode.cache.lucene.internal.distributed.LuceneQueryFunction.execute(LuceneQueryFunction.java:87)
at 
org.apache.geode.internal.cache.PartitionedRegionDataStore.executeOnDataStore(PartitionedRegionDataStore.java:2956)
at 
org.apache.geode.internal.cache.partitioned.PartitionedRegionFunctionStreamingMessage.operateOnPartitionedRegion(PartitionedRegionFunctionStreamingMessage.java:98)
at 
org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:339)
at 
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
at 
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:625)
at 
org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1071)
at java.lang.Thread.run(Thread.java:745)
Caused by: LEADING_WILDCARD_NOT_ALLOWED: Leading wildcard is not allowed: 
field1:*asdf*
at 
org.apache.lucene.queryparser.flexible.standard.processors.AllowLeadingWildcardProcessor.postProcessNode(AllowLeadingWildcardProcessor.java:79)
at 
org.apache.lucene.queryparser.flexible.core.processors.QueryNodeProcessorImpl.processIteration(QueryNodeProcessorImpl.java:98)
at 
org.apache.lucene.queryparser.flexible.core.processors.QueryNodeProcessorImpl.process(QueryNodeProcessorImpl.java:89)
at 
org.apache.lucene.queryparser.flexible.standard.processors.AllowLeadingWildcardProcessor.process(AllowLeadingWildcardProcessor.java:54)
at 
org.apache.lucene.queryparser.flexible.core.processors.QueryNodeProcessorPipeline.process(QueryNodeProcessorPipeline.java:89)
at 
org.apache.lucene.queryparser.flexible.core.QueryParserHelper.parse(QueryParserHelper.java:250)
at 
org.apache.lucene.queryparser.flexible.standard.StandardQueryParser.parse(StandardQueryParser.java:159)
at 
org.apache.geode.cache.lucene.internal.StringQueryProvider.getQuery(StringQueryProvider.java:73)
... 12 more
{noformat}

  was:
Some invalid query strings might be "`*`" or " ".

When used with a single node dataStore, we see the correct Exception returned:
```
gfsh>search lucene --name=testIndex --region=/testRegion --queryStrings="*" 
--defaultField=__REGION_VALUE_FIELD
Could not process command due to GemFire error. An error occurred while 
searching lucene index across the Geode cluster: Leading wildcard is not 
allowed: __REGION_VALUE_FIELD:*
```
However, with multiple nodes, the query hangs. 

Jason debugged this a bit and found:
```
the remote nodes fail in the function with this stack trace (where we will 
probably need to try/catch any lucene exception)
[warning 2017/05/18 13:50:34.105 PDT server2  
tid=0x3c]
org.apache.geode.cache.lucene.LuceneQueryException: Malformed lucene query: 
*asdf*
at 
org.apache.geode.cache.lucene.internal.StringQueryProvider.getQuery(StringQueryProvider.java:79)
at 
org.apache.geode.cache.lucene.internal.distributed.LuceneQueryFunction.getQuery(LuceneQueryFunction.java:160)
at 
org.apache.geode.cache.lucene.internal.distributed.LuceneQueryFunction.execute(LuceneQueryFunction.java:87)
at 
org.apache.geode.internal.cache.PartitionedRegionDataStore.executeOnDataStore(PartitionedRegionDataStore.java:2956)
at 

[jira] [Updated] (GEODE-2943) Invalid queryStrings cause lucene searches to hang in in PR with multiple nodes

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey updated GEODE-2943:
---
Affects Version/s: 1.2.0

> Invalid queryStrings cause lucene searches to hang in in PR with multiple 
> nodes
> ---
>
> Key: GEODE-2943
> URL: https://issues.apache.org/jira/browse/GEODE-2943
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>
> Some invalid query strings might be "`*`" or " ".
> When used with a single node dataStore, we see the correct Exception returned:
> ```
> gfsh>search lucene --name=testIndex --region=/testRegion --queryStrings="*" 
> --defaultField=__REGION_VALUE_FIELD
> Could not process command due to GemFire error. An error occurred while 
> searching lucene index across the Geode cluster: Leading wildcard is not 
> allowed: __REGION_VALUE_FIELD:*
> ```
> However, with multiple nodes, the query hangs. 
> Jason debugged this a bit and found:
> ```
> the remote nodes fail in the function with this stack trace (where we will 
> probably need to try/catch any lucene exception)
> [warning 2017/05/18 13:50:34.105 PDT server2  
> tid=0x3c]
> org.apache.geode.cache.lucene.LuceneQueryException: Malformed lucene query: 
> *asdf*
> at 
> org.apache.geode.cache.lucene.internal.StringQueryProvider.getQuery(StringQueryProvider.java:79)
> at 
> org.apache.geode.cache.lucene.internal.distributed.LuceneQueryFunction.getQuery(LuceneQueryFunction.java:160)
> at 
> org.apache.geode.cache.lucene.internal.distributed.LuceneQueryFunction.execute(LuceneQueryFunction.java:87)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.executeOnDataStore(PartitionedRegionDataStore.java:2956)
> at 
> org.apache.geode.internal.cache.partitioned.PartitionedRegionFunctionStreamingMessage.operateOnPartitionedRegion(PartitionedRegionFunctionStreamingMessage.java:98)
> at 
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:339)
> at 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:442)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:625)
> at 
> org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1071)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: LEADING_WILDCARD_NOT_ALLOWED: Leading wildcard is not allowed: 
> field1:*asdf*
> at 
> org.apache.lucene.queryparser.flexible.standard.processors.AllowLeadingWildcardProcessor.postProcessNode(AllowLeadingWildcardProcessor.java:79)
> at 
> org.apache.lucene.queryparser.flexible.core.processors.QueryNodeProcessorImpl.processIteration(QueryNodeProcessorImpl.java:98)
> at 
> org.apache.lucene.queryparser.flexible.core.processors.QueryNodeProcessorImpl.process(QueryNodeProcessorImpl.java:89)
> at 
> org.apache.lucene.queryparser.flexible.standard.processors.AllowLeadingWildcardProcessor.process(AllowLeadingWildcardProcessor.java:54)
> at 
> org.apache.lucene.queryparser.flexible.core.processors.QueryNodeProcessorPipeline.process(QueryNodeProcessorPipeline.java:89)
> at 
> org.apache.lucene.queryparser.flexible.core.QueryParserHelper.parse(QueryParserHelper.java:250)
> at 
> org.apache.lucene.queryparser.flexible.standard.StandardQueryParser.parse(StandardQueryParser.java:159)
> at 
> org.apache.geode.cache.lucene.internal.StringQueryProvider.getQuery(StringQueryProvider.java:73)
> ... 12 more
> ```



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

[jira] [Created] (GEODE-2943) Invalid queryStrings cause lucene searches to hang in in PR with multiple nodes

[Shelley Lynn Hughes-Godfrey (JIRA)]

Shelley Lynn Hughes-Godfrey created GEODE-2943:
--

 Summary: Invalid queryStrings cause lucene searches to hang in in 
PR with multiple nodes
 Key: GEODE-2943
 URL: https://issues.apache.org/jira/browse/GEODE-2943
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Shelley Lynn Hughes-Godfrey


Some invalid query strings might be "`*`" or " ".

When used with a single node dataStore, we see the correct Exception returned:
```
gfsh>search lucene --name=testIndex --region=/testRegion --queryStrings="*" 
--defaultField=__REGION_VALUE_FIELD
Could not process command due to GemFire error. An error occurred while 
searching lucene index across the Geode cluster: Leading wildcard is not 
allowed: __REGION_VALUE_FIELD:*
```
However, with multiple nodes, the query hangs. 

Jason debugged this a bit and found:
```
the remote nodes fail in the function with this stack trace (where we will 
probably need to try/catch any lucene exception)
[warning 2017/05/18 13:50:34.105 PDT server2  
tid=0x3c]
org.apache.geode.cache.lucene.LuceneQueryException: Malformed lucene query: 
*asdf*
at 
org.apache.geode.cache.lucene.internal.StringQueryProvider.getQuery(StringQueryProvider.java:79)
at 
org.apache.geode.cache.lucene.internal.distributed.LuceneQueryFunction.getQuery(LuceneQueryFunction.java:160)
at 
org.apache.geode.cache.lucene.internal.distributed.LuceneQueryFunction.execute(LuceneQueryFunction.java:87)
at 
org.apache.geode.internal.cache.PartitionedRegionDataStore.executeOnDataStore(PartitionedRegionDataStore.java:2956)
at 
org.apache.geode.internal.cache.partitioned.PartitionedRegionFunctionStreamingMessage.operateOnPartitionedRegion(PartitionedRegionFunctionStreamingMessage.java:98)
at 
org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:339)
at 
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
at 
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:625)
at 
org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1071)
at java.lang.Thread.run(Thread.java:745)
Caused by: LEADING_WILDCARD_NOT_ALLOWED: Leading wildcard is not allowed: 
field1:*asdf*
at 
org.apache.lucene.queryparser.flexible.standard.processors.AllowLeadingWildcardProcessor.postProcessNode(AllowLeadingWildcardProcessor.java:79)
at 
org.apache.lucene.queryparser.flexible.core.processors.QueryNodeProcessorImpl.processIteration(QueryNodeProcessorImpl.java:98)
at 
org.apache.lucene.queryparser.flexible.core.processors.QueryNodeProcessorImpl.process(QueryNodeProcessorImpl.java:89)
at 
org.apache.lucene.queryparser.flexible.standard.processors.AllowLeadingWildcardProcessor.process(AllowLeadingWildcardProcessor.java:54)
at 
org.apache.lucene.queryparser.flexible.core.processors.QueryNodeProcessorPipeline.process(QueryNodeProcessorPipeline.java:89)
at 
org.apache.lucene.queryparser.flexible.core.QueryParserHelper.parse(QueryParserHelper.java:250)
at 
org.apache.lucene.queryparser.flexible.standard.StandardQueryParser.parse(StandardQueryParser.java:159)
at 
org.apache.geode.cache.lucene.internal.StringQueryProvider.getQuery(StringQueryProvider.java:73)
... 12 more
```



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

[jira] [Created] (GEODE-2942) Add Search to Geode User Guide on Website

[Joey McAllister (JIRA)]

Joey McAllister created GEODE-2942:
--

 Summary: Add Search to Geode User Guide on Website
 Key: GEODE-2942
 URL: https://issues.apache.org/jira/browse/GEODE-2942
 Project: Geode
  Issue Type: New Feature
  Components: docs
Reporter: Joey McAllister


As a User Guide reader, I want to be able to search through the User Guide on 
the Geode website rather than going to Google.com.



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

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #558 was successful.
---
Scheduled
1850 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

[jira] [Commented] (GEODE-2741) Use C++11 shared pointer over custom shared pointer

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2741:


Commit 67c6ee2c20bbaa72ac7846336260575365c8d8be in geode-native's branch 
refs/heads/develop from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=67c6ee2 ]

GEODE-2741: Fixes testEntriesMap.


> Use C++11 shared pointer over custom shared pointer
> ---
>
> Key: GEODE-2741
> URL: https://issues.apache.org/jira/browse/GEODE-2741
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Addison
>Assignee: Jacob S. Barrett
>
> *Context*
> Now that the Native Client is compatible with C++11, we can use its shared 
> pointer over the custom shared pointer we use today.
> *Definition of Done*
> The custom shared pointer is nowhere to be found in the codebase



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

[jira] [Updated] (GEODE-2941) Pulse documentation is outdated

[Jinmei Liao (JIRA)]

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

Jinmei Liao updated GEODE-2941:
---
Component/s: docs

> Pulse documentation is outdated
> ---
>
> Key: GEODE-2941
> URL: https://issues.apache.org/jira/browse/GEODE-2941
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Jinmei Liao
>
> the pulse documentation:
> http://geode.apache.org/docs/guide/11/tools_modules/pulse/quickstart.html#topic_523F6DE33FE54307BBE8F83BB7D9355D
> is no longer accurate anymore.
> 1. jmxUsername and jmxpassword no long applies
> 2. the logging configurations has changed too.



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

[jira] [Created] (GEODE-2941) Pulse documentation is outdated

[Jinmei Liao (JIRA)]

Jinmei Liao created GEODE-2941:
--

 Summary: Pulse documentation is outdated
 Key: GEODE-2941
 URL: https://issues.apache.org/jira/browse/GEODE-2941
 Project: Geode
  Issue Type: Bug
Reporter: Jinmei Liao


the pulse documentation:
http://geode.apache.org/docs/guide/11/tools_modules/pulse/quickstart.html#topic_523F6DE33FE54307BBE8F83BB7D9355D

is no longer accurate anymore.
1. jmxUsername and jmxpassword no long applies
2. the logging configurations has changed too.



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

[jira] [Updated] (GEODE-2940) Remove verification of locator host on start

[Brian Baynes (JIRA)]

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

Brian Baynes updated GEODE-2940:

Issue Type: New Feature  (was: Bug)

> Remove verification of locator host on start
> 
>
> Key: GEODE-2940
> URL: https://issues.apache.org/jira/browse/GEODE-2940
> Project: Geode
>  Issue Type: New Feature
>  Components: membership
>Reporter: Brian Baynes
>




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

[jira] [Created] (GEODE-2940) Remove verification of locator host on start

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2940:
---

 Summary: Remove verification of locator host on start
 Key: GEODE-2940
 URL: https://issues.apache.org/jira/browse/GEODE-2940
 Project: Geode
  Issue Type: Bug
  Components: membership
Reporter: Brian Baynes






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

[jira] [Updated] (GEODE-1274) Pulse logging does not appear in Geode log file.

[Jinmei Liao (JIRA)]

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

Jinmei Liao updated GEODE-1274:
---
Fix Version/s: 1.2.0

> Pulse logging does not appear in Geode log file.
> 
>
> Key: GEODE-1274
> URL: https://issues.apache.org/jira/browse/GEODE-1274
> Project: Geode
>  Issue Type: Bug
>  Components: logging, pulse
>Affects Versions: 1.0.0-incubating, 1.1.0
>Reporter: Jens Deppe
>  Labels: Log4j2
> Fix For: 1.2.0
>
>
> While trying to enable debug logging for Pulse, I found that no Pulse logging 
> appears in the Geode log. The Admin REST logging does appear though.
> I had tried to enable debug logging by starting a locator with the followiing 
> log4j config:
> {noformat}
> 
>  packages="com.gemstone.gemfire.internal.logging.log4j">
>   
> [%level{lowerCase=true} %date{/MM/dd 
> HH:mm:ss.SSS z} %thread tid=%tid] %message%n%throwable%n
>   
>   
> 
>   
> 
>   
>   
> 
> 
>onMismatch="NEUTRAL"/>
> 
> 
> 
> 
>   
> 
>   
> 
> {noformat}
> However, only the Admin REST app produced debug log output. 



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

[jira] [Resolved] (GEODE-2927) Verify pulse connectivity to locator/jmx manager and logging both in the embedded and un-embedded mode.

[Jinmei Liao (JIRA)]

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

Jinmei Liao resolved GEODE-2927.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Verify pulse connectivity to locator/jmx manager and logging both in the 
> embedded and un-embedded mode.
> ---
>
> Key: GEODE-2927
> URL: https://issues.apache.org/jira/browse/GEODE-2927
> Project: Geode
>  Issue Type: Bug
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
> Fix For: 1.2.0
>
>




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

[jira] [Resolved] (GEODE-2775) Pulse is not using certificate to connect to JMX when ssl is turned for jmx connection

[Jinmei Liao (JIRA)]

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

Jinmei Liao resolved GEODE-2775.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Pulse is not using certificate to connect to JMX when ssl is turned for jmx 
> connection
> --
>
> Key: GEODE-2775
> URL: https://issues.apache.org/jira/browse/GEODE-2775
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.1.1
>Reporter: Jinmei Liao
> Fix For: 1.2.0
>
>
> Steps to reproduce:
> 1) start a locator with a SecurityManager and with this property: 
> ssl-enabled-components=jmx
> 2) start a browser and tries to login to pulse.
> Actual result: not able to log in using valid username/password



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

[jira] [Assigned] (GEODE-2939) Initiate bucket event tracker and get GII from different source could lead to bucket copies inconsistence

[Eric Shu (JIRA)]

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

Eric Shu reassigned GEODE-2939:
---

Assignee: Eric Shu

> Initiate bucket event tracker and get GII from different source could lead to 
> bucket copies inconsistence
> -
>
> Key: GEODE-2939
> URL: https://issues.apache.org/jira/browse/GEODE-2939
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Eric Shu
>Assignee: Eric Shu
>
> When a bucket region is created, it send CreateRegionMessage to all nodes 
> hosting the bucket data. It initiates its event tracker from the first one 
> replied. 
> In one case, it copies event tracker states from the node with primary 
> bucket, which is processing putAll operation and already applied a few entry 
> operations (so the newer seqNo is recorded for the thread performing the 
> putAll). 
> However, it gets initial image from another node -- which does not have the 
> entry operations yet (as putAll op is not yet being distributed to secondary 
> yet.)
> The newly created region would receive all the putAll operations from the 
> primary when the primary distributes the putAll operations to secondary 
> copies. In the node with newly created region, some of the events would not 
> be applied due to hasSeenEvent method call (up to initiated last seqNo for 
> the said thread). This leads to bucket inconsistence among the redundant 
> copies.
> Please note this issue would not occur if there is only one redundant copy.



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

[jira] [Created] (GEODE-2939) Initiate bucket event tracker and get GII from different source could lead to bucket copies inconsistence

[Eric Shu (JIRA)]

Eric Shu created GEODE-2939:
---

 Summary: Initiate bucket event tracker and get GII from different 
source could lead to bucket copies inconsistence
 Key: GEODE-2939
 URL: https://issues.apache.org/jira/browse/GEODE-2939
 Project: Geode
  Issue Type: Bug
  Components: regions
Reporter: Eric Shu


When a bucket region is created, it send CreateRegionMessage to all nodes 
hosting the bucket data. It initiates its event tracker from the first one 
replied. 

In one case, it copies event tracker states from the node with primary bucket, 
which is processing putAll operation and already applied a few entry operations 
(so the newer seqNo is recorded for the thread performing the putAll). 

However, it gets initial image from another node -- which does not have the 
entry operations yet (as putAll op is not yet being distributed to secondary 
yet.)

The newly created region would receive all the putAll operations from the 
primary when the primary distributes the putAll operations to secondary copies. 
In the node with newly created region, some of the events would not be applied 
due to hasSeenEvent method call (up to initiated last seqNo for the said 
thread). This leads to bucket inconsistence among the redundant copies.

Please note this issue would not occur if there is only one redundant copy.



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

Review Request 59380: GEODE-2661 do not invoke afterDestroy events for non-existent keys in caching proxy clients and servers

[Lynn Gallinat]

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

Review request for geode, anilkumar gingade, Darrel Schneider, and Eric Shu.


Repository: geode


Description
---

When a non-existing entry is removed using removeAll from PartitionedRegion 
(need to verify this on replicated), the CacheListener's aftrerDestroy callback 
method gets invoked. The afterDestroy should not be invoked for entry which is 
not present.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRemoveAllOperation.java
 42bf10f 
  geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
8e7ec68 
  
geode-core/src/test/java/org/apache/geode/cache/RemoveAllCacheListenerPeerRegressionTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/cache/client/RemoveAllCacheListenerClientServerRegressionTest.java
 PRE-CREATION 


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


Testing
---

New unit tests, precheckin in progress.


Thanks,

Lynn Gallinat

[jira] [Commented] (GEODE-2913) Update Lucene documentation

[ASF GitHub Bot (JIRA)]

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

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

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode/pull/518
  
+1 with Joey's changes.


> Update Lucene documentation
> ---
>
> Key: GEODE-2913
> URL: https://issues.apache.org/jira/browse/GEODE-2913
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Improvements to the code base that need to be reflected in the docs:
> * Change LuceneService.createIndex to use a factory pattern
> {code:java}
> luceneService.createIndex(region, index, ...)
> {code}
> changes to
> {code:java}
> luceneService.createIndexFactory()
> .addField("field1name")
> .addField("field2name")
> .create()
> {code}
> *  Lucene indexes will *NOT* be stored in off-heap memory.
> * Document how to configure an index on accessors - you still need to create 
> the Lucene index before creating the region, even though this member does not 
> hold any region data.
> If the index is not defined on the accessor, an exception like this will be 
> thrown while attempting to create the region:
> {quote}
> [error 2017/05/02 15:19:26.018 PDT  tid=0x1] 
> java.lang.IllegalStateException: Must create Lucene index full_index on 
> region /data because it is defined in another member.
> Exception in thread "main" java.lang.IllegalStateException: Must create 
> Lucene index full_index on region /data because it is defined in another 
> member.
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
> {quote}
> * Do not need to create a Lucene index on a client with a Proxy cache. The 
> Lucene search will always be done on the server.  Besides, _you can't create 
> an index on a client._
> * If you configure Invalidates for region entries (alone or as part of 
> expiration), these will *NOT* invalidate the Lucene indexes.
> The problem with this is the index contains the keys, but the region doesn't, 
> so the query produces results that don't exist.
> In this test, the first time the query is run, it produces N valid results. 
> The second time it is run it produces N empty results:
> ** load entries
> ** run query
> ** invalidate entries
> ** run query again
> *  Destroying a region will *NOT* automatically destroy any Lucene index 
> associated with that region. Instead, attempting to destroy a region with a 
> Lucene index will throw a colocated region exception. 
> An IllegalStateException is thrown:
> {quote}
> java.lang.IllegalStateException: The parent region [/data] in colocation 
> chain cannot be destroyed, unless all its children 
> [[/cusip_index#_data.files]] are destroyed
> at 
> org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
> at 
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
> at 
> DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
> {quote}
> * The process to change a Lucene index using gfsh: 
>   1. export region data
>   2. destroy Lucene index, destroy region 
>   3. create new index, create new region without user-defined business 
> logic callbacks
>   4. import data with option to turn on callbacks (to invoke Lucene Async 
> Event Listener to index the data)
>   5. alter region to add user-defined business logic callbacks
> * Make sure there are no references to replicated regions as they are not 
> supported.
> * Document security implementation and defaults.  If a user has security 
> configured for their cluster, creating a Lucene index requires DATA:MANAGE 
> privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE 
> privilege because a function is called (different from OQL which requires 
> only DATA:READ privilege). Here are all the required privileges for the gfsh 
> commands:
> ** create index requires DATA:MANAGE:region
> ** describe index requires CLUSTER:READ
> ** list indexes requires CLUSTER:READ
> ** search index requires DATA:WRITE
> ** destroy index requires DATA:MANAGE:region
> * A user cannot create a Lucene index on a region that has eviction 
> configured with local destroy. If using Lucene indexing, eviction can only be 
> configured with overflow to disk. In this case, only the region data is 
> overflowed to disk, *NOT* the Lucene index. An UnsupportedOperationException 
> 

[GitHub] geode issue #518: GEODE-2913 Update Lucene index documentation

[davebarnes97]

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode/pull/518
  
+1 with Joey's changes.


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

Re: Review Request 59374: GEODE-1597: fix auto-complete when user input ends with space

[Kirk Lund]

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


Ship it!




Ship It!

- Kirk Lund


On May 18, 2017, 7:42 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59374/
> ---
> 
> (Updated May 18, 2017, 7:42 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1597: fix auto-complete when user input ends with space
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
>  f9adeb3f20f13d575d9ecabfa2a7a5c07c212c67 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserAutoCompletionTest.java
>  31a5cebc6760a3ef7f47e54c7fd396b71f4105cd 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserJUnitTest.java
>  2fd8c2f343c568d94fce3ef1ecc48bac846b1784 
> 
> 
> Diff: https://reviews.apache.org/r/59374/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Review Request 59374: GEODE-1597: fix auto-complete when user input ends with space

[Jinmei Liao]

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

Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
Rhomberg.


Repository: geode


Description
---

GEODE-1597: fix auto-complete when user input ends with space


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
 f9adeb3f20f13d575d9ecabfa2a7a5c07c212c67 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserAutoCompletionTest.java
 31a5cebc6760a3ef7f47e54c7fd396b71f4105cd 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserJUnitTest.java
 2fd8c2f343c568d94fce3ef1ecc48bac846b1784 


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


Testing
---


Thanks,

Jinmei Liao

[jira] [Commented] (GEODE-2929) Remove superfluous uses of final from classes and methods

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2929:


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

GEODE-2929: remove superfluous final from methods


> Remove superfluous uses of final from classes and methods
> -
>
> Key: GEODE-2929
> URL: https://issues.apache.org/jira/browse/GEODE-2929
> Project: Geode
>  Issue Type: Wish
>  Components: core
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Use of final keyword on classes and methods should be reserved for unique 
> situations in the User API where we really need final to prevent a User from 
> overriding something in the API.
> Superfluous usage of final on classes and methods hinders good unit testing 
> by preventing mocking of those classes and methods.
> Any unnecessary usage of final should be removed to facilitate mocking.



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

[jira] [Commented] (GEODE-2804) Allow a locator host to be taken off line and replaced with a different machine having the same host name

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2804:


Commit e216fde1e4b1613bde22112cfb1544be022c3aac in geode's branch 
refs/heads/feature/GEODE-2929-1 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=e216fde ]

GEODE-2804 Update InetSocketAddress, when there is IOException.

Geode keeps InetSocketAddress for locators. So, if locators ip
changes in cloud/VM enviroment then Geode process unable to
connect to locator. Thus we have fixed this problem in two way.

a. If Geode client sees IOException while connecting to locator then
we change cached InetAddress to use locator hostname. In this way,
client does DNS query again for locator host.
b. For other Geode process, now we connect to locator using hostname.

Added couple of junit tests for it.


> Allow a locator host to be taken off line and replaced with a different 
> machine having the same host name
> -
>
> Key: GEODE-2804
> URL: https://issues.apache.org/jira/browse/GEODE-2804
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, membership, native client
>Affects Versions: 1.1.1
>Reporter: Bruce Schuchardt
>Assignee: Hitesh Khamesra
>
> It is not unlikely that in a long-running system a machine hosting a locator 
> will break down and need to be replace, or that a virtual machine hosting a 
> locator will be stopped and restarted.  In either case the machine may have a 
> different IP address.
> Clients and servers currently cache the IP address of a locator and should be 
> changed to re-resolve the host name if the address stops being usable.
> Servers currently cannot be started if they are given a host name that can 
> not be resolved.  They should be changed to allow this and start up if they 
> are able to contact one or more of the other locators in their "locators" 
> setting.



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

[jira] [Commented] (GEODE-2874) StringIndexOutOfBoundsException while initializing logger

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2874:


Commit 90ee3d8a0f071f83e19f7c28f78e2d470282e0de in geode's branch 
refs/heads/feature/GEODE-2929-1 from [~jstewart]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=90ee3d8 ]

GEODE-2874: Fix StringIndexOutOfBoundsException while initializing logger


> StringIndexOutOfBoundsException while initializing logger
> -
>
> Key: GEODE-2874
> URL: https://issues.apache.org/jira/browse/GEODE-2874
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
> index out of range: -1
>   at java.lang.String.substring(String.java:1967)
>   at 
> org.apache.geode.internal.io.MainWithChildrenRollingFileHandler.calcNextChildId(MainWithChildrenRollingFileHandler.java:47)
>   at 
> org.apache.geode.internal.logging.ManagerLogWriter.getLogNameForOldMainLog(ManagerLogWriter.java:330)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.createLogWriterAppender(LogWriterAppenders.java:144)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:72)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:88)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:591)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:304)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:207)
>   at GeodeClient.GeodeClient(GeodeClient.java:22)
>   at GeodeClient.main(GeodeClient.java:10)



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

[jira] [Commented] (GEODE-2938) Remove @Deprecated tag from OrderByComparatorUnmapped

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2938:


Commit da6c28c321f73903dc4849687710c347c16ade95 in geode's branch 
refs/heads/feature/GEODE-2929-1 from [~nnag]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=da6c28c ]

GEODE-2938: Removed the deprecated tag

* Removed the deprecated tag in OrderByComparatorUnmapped.
* This code is still being used.


> Remove @Deprecated tag from OrderByComparatorUnmapped
> -
>
> Key: GEODE-2938
> URL: https://issues.apache.org/jira/browse/GEODE-2938
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: nabarun
>Assignee: nabarun
> Fix For: 1.2.0
>
>
> Issue:
> OrderByComparatorUnmapped is marked @Deprecated but it is currently in heavy 
> use in the geode codebase and we have no alternative code for this.
> Solution:
> Remove the deprecated tag



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

[jira] [Commented] (GEODE-2937) Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system property

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2937:


Commit d9343d4406ac2b0625a9acf40a7ec20d6ac2cf36 in geode's branch 
refs/heads/feature/GEODE-2929-1 from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=d9343d4 ]

GEODE-2937: Restore removeFromQueueOnException


> Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system property
> --
>
> Key: GEODE-2937
> URL: https://issues.apache.org/jira/browse/GEODE-2937
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.2.0
>
>
> In a refactoring effort last year, the system property 
> REMOVE_FROM_QUEUE_ON_EXCEPTION was removed as it was unknown that it was 
> actually being used. 
> There are no tests that actually fail when the code is removed but it is a 
> behavior that is definitely wanted by certain users and may be defaulted to 
> in the future.



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

[jira] [Commented] (GEODE-2587) Refactor OrderByComparator's compare method

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2587:


Commit b3fc0c814948cdfeb3181fcb57d07886aba8691e in geode's branch 
refs/heads/feature/GEODE-2929-1 from nabarunnag
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=b3fc0c8 ]

GEODE-2587: Refactored the OrderByComparator's compare method

* This prevents creation of extra data structures like arrays of arrays
* Hence let number of GC, faster execution of queries with ORDER BY

This closes #517


> Refactor OrderByComparator's compare method
> ---
>
> Key: GEODE-2587
> URL: https://issues.apache.org/jira/browse/GEODE-2587
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: nabarun
> Fix For: 1.2.0
>
>
> OrderByComparator's compare method creates a lot of objects / arrays with the 
> intention of comparing two objects.
> But allocation of memory for these objects results in GC to kick in.
> The additional time consumed in GC results in increased execution time for 
> queries with ORDER BY clause.
> This method must be refactored to require less memory allocations in order to 
> compare and thus speed up ORDER BY clause.



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

[jira] [Commented] (GEODE-2927) Verify pulse connectivity to locator/jmx manager and logging both in the embedded and un-embedded mode.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2927:


Commit 0f978a6df711d04e0c7c1926fb1e297d07c21aa3 in geode's branch 
refs/heads/feature/GEODE-2929-1 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=0f978a6 ]

GEODE-2927: fix pulse logging and useLocator, SSL flags

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


> Verify pulse connectivity to locator/jmx manager and logging both in the 
> embedded and un-embedded mode.
> ---
>
> Key: GEODE-2927
> URL: https://issues.apache.org/jira/browse/GEODE-2927
> Project: Geode
>  Issue Type: Bug
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>




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

[jira] [Commented] (GEODE-2929) Remove superfluous uses of final from classes and methods

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2929:


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

GEODE-2929: remove superfluous final from methods


> Remove superfluous uses of final from classes and methods
> -
>
> Key: GEODE-2929
> URL: https://issues.apache.org/jira/browse/GEODE-2929
> Project: Geode
>  Issue Type: Wish
>  Components: core
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Use of final keyword on classes and methods should be reserved for unique 
> situations in the User API where we really need final to prevent a User from 
> overriding something in the API.
> Superfluous usage of final on classes and methods hinders good unit testing 
> by preventing mocking of those classes and methods.
> Any unnecessary usage of final should be removed to facilitate mocking.



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

[jira] [Commented] (GEODE-2875) shutdown is taking as long as 20 seconds

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2875:


Commit 15245dfd2b78a593697e46c8710d23783fc4 in geode's branch 
refs/heads/feature/GEODE-2929-1 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=15245df ]

GEODE-2875 shutdown is taking as long as 20 seconds

With a 1.2.0 release pending I am backing out the part of the fix for
this issue that routed certain messages over UDP unicast.  This change
needs more testing as Hitesh suspects it is implicated in a number of
hangs he has seen in his tests.

The Shutdown message is still routed over UDP but all others are now
directed to TCP/IP stream sockets, as they were before.


> shutdown is taking as long as 20 seconds
> 
>
> Key: GEODE-2875
> URL: https://issues.apache.org/jira/browse/GEODE-2875
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> Recent changes have introduced a bug where sometimes, particularly during 
> shutdown of a lot of servers, the shutdown process will stall for as long as 
> 20 seconds.  This appears to be due to changes that keep a membership 
> coordinator from sending out a new view during shutdown.



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

[jira] [Resolved] (GEODE-2934) Refactor AnalyzeSerializablesJUnitTest and subclasses

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-2934.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> Refactor AnalyzeSerializablesJUnitTest and subclasses
> -
>
> Key: GEODE-2934
> URL: https://issues.apache.org/jira/browse/GEODE-2934
> Project: Geode
>  Issue Type: Wish
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
> Fix For: 1.2.0
>
>
> There is quite a lot of redundant code in AnalyzeSerializablesJUnitTest, 
> AnalyzeCQSerializablesJUnitTest and AnalyzeWANSerializablesJUnitTest.
> The subclasses should be able to specify a simple geode-module module name 
> and keep all of the other code in AnalyzeSerializablesJUnitTest.
> I'd also like to move most of the setup to the Before method and make the 
> actual tests smaller and easier to debug.



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

hangs in precheckin testing

[Bruce Schuchardt]

A number of developers have experienced hangs in precheckin runs. Thread 
dumps will show a thread waiting for a response to a message of a class 
that implements "sendViaUDP" and returns true.  I am concerned that the 
recent fix for GEODE-2875 may be the cause of this and have backed out 
the portion that directed these messages over the JGroups channel 
instead of sending them over the TCP/IP channel.


If you updated your develop checkout since Friday afternoon and have not 
picked up commit 15245dfd that I checked in this morning you should do so.

Re: org.apache.geode.internal.InternalDataSerializer API Changes...

[John Blum]

Thanks Kirk and team!

+1 for bubbling up some of the internal APIs and having consistency and/or
functional parity.

One suggestion is, perhaps a quick note could be sent out to the Geode devs
with a title/subject of "*NOTICE: Frameworks/Tooling*" with a body
detailing the API (public/internal) changes that would affect 3rd party
projects (e.g. access modifier changes, removing methods, changing
signatures, introducing new types/properties, etc)

Another suggestion... it might be nice to list the more formal/official
projects, like SDG, that the community is working on for the Apache Geode
ecosystem.  I literally have no idea what additional projects exist that
might benefit the community.  *Pivotal GemFire* could be even counted among
these ecosystem projects/products perhaps another section similar to "
*Deployments*" on the Community page 
 [1].

Food for thought.

Thanks,
John

[1] http://geode.apache.org/community/


On Thu, May 18, 2017 at 10:31 AM, Kirk Lund  wrote:

> I think we should definitely try to refactor any Geode internals that SDG
> is using to be public API or SPI. We'll need to take a closer look at how
> SDG is using those classes to plan what to do.
>
> If I change or any classes on your list (or public APIs), I'll give you
> heads up next time.
>
> On Thu, May 18, 2017 at 10:21 AM, John Blum  wrote:
>
> > Hi Kirk (also responding to Bruce as I was writing this before he sent)-
> >
> > Thank you for following up.
> >
> > Regarding the addition of the getOnlineLocators()...
> >
> > SDG does implement
> >  > org/springframework/data/gemfire/client/support/package-summary.html>
> > [1]
> > a few Geode interfaces, such as *org.apache.geode.cache.client.Pool*.
> > This
> > is due in part since not all the state for certain Geode objects (e.g.
> > Pool) is known in advance as the actual object may not have been created
> by
> > the *Spring* container yet.  However, that state is captured in *Spring*
> > FactoryBeans, which will be used to construct the actual object at the
> > appropriate time.
> >
> > Anyway, like the "internal" API, I have tried to keep such
> implementations
> > of Geode interfaces/classes to a minimum.  Still, it is a good indicator
> of
> > when something has changed since I will most certainly get a compilation
> > failure.  This leads me to, I do need to know when APIs change to provide
> > appropriate support in SDG, possibly in configuration, whether XML of via
> > Java/annotations with the FactoryBeans, e.g. PoolFactoryBean
> >  > org/springframework/data/gemfire/client/PoolFactoryBean.html>
> > [2],
> > especially if it is a configuration property/attribute.  Other cases my
> be
> > important from an accessibility or information standpoint (probably more
> so
> > for tooling).
> >
> > As for the InternalDataSerializer...
> >
> > No worries.  I found an acceptable and actually better workaround.
> Again,
> > I am trying to reduce or completely eliminate the use of "internal"
> classes
> > in SDG.  Unfortunately, a quick search (using regex) in SDG for "import
> > org\.apache\.geode.*internal" reveals 35 occurrences, the most pertinent
> > ones being...
> >
> > org.apache.geode.internal.GemFireVersion (used in debugging)
> > org.apache.geode.internal.DistributionLocator
> > org.apache.geode.internal.InternalDataSerializer
> > org.apache.geode.internal.cache.GemFireCacheImpl
> > org.apache.geode.internal.cache.LocalRegion (used to inspect whether a
> > server proxy is present to acquire the appropriate QueryService)
> > org.apache.geode.internal.cache.PartitionedRegion
> > org.apache.geode.internal.cache.UserSpecifiedRegionAttributes
> > org.apache.geode.internal.cache.lru.LRUCapacityController
> > org.apache.geode.internal.cache.lru.MemLRUCapacityController
> > org.apache.geode.internal.cache.query.internal.ResultsBag
> > org.apache.geode.internal.distributed.internal.DistributionConfig
> > org.apache.geode.internal.distributed.internal.InternalDistributedSystem
> > org.apache.geode.internal.distributed.internal.InternalLocator
> > org.apache.geode.internal.datasource.ConfigProperty (JNDI support)
> > org.apache.geode.internal.jndi.JNDIInvoker (JNDI support)
> > org.apache.geode.internal.security.SecurityService (my doing)
> >
> > Most of this was added before my time.  I just need time to review these
> > more carefully, and how each is used.  I know many of these are used for
> > good reason.
> >
> > Thanks,
> > John
> >
> >
> > [1]
> > http://docs.spring.io/spring-data-gemfire/docs/current/api/
> > org/springframework/data/gemfire/client/support/package-summary.html
> > [2]
> > http://docs.spring.io/spring-data-gemfire/docs/current/api/
> > org/springframework/data/gemfire/client/PoolFactoryBean.html
> >
> >
> > On Thu, May 18, 2017 at 10:18 AM, Bruce Schuchardt <

[jira] [Commented] (GEODE-265) Remove deprecated methods on Execution interface

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-265:
--

Github user jhuynh1 commented on the issue:

https://github.com/apache/geode/pull/509
  
@metatype Will do for both this and PR#511


> Remove deprecated methods on Execution interface
> 
>
> Key: GEODE-265
> URL: https://issues.apache.org/jira/browse/GEODE-265
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
>   Original Estimate: 5h
>  Remaining Estimate: 5h
>
> The Execution interface has a number of execute methods that have been 
> deprecated. It looks like these could be easily removed.



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

[GitHub] geode pull request #520: GEODE-2582: New client can send a Put request with ...

[galen-pivotal]

GitHub user galen-pivotal opened a pull request:

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

GEODE-2582: New client can send a Put request with Protobuf IDL.

* Update the proto IDL
* Get a put request working.

Currently this only uses String serialization; serialization protocols
still have to be implemented.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [x] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?
 --> It does, except for `testRedundancySatisfactionPreferRemoteIp`, which 
I have seen fail on my machine before for some reason related to my network 
config.

- [x] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.

@metatype can you verify that this license is compatible?
https://github.com/google/protobuf/blob/master/LICENSE

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

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

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

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


commit e7499a892e05fc6f2151310ea088261ffa4966af
Author: Galen OSullivan 
Date:   2017-03-16T23:26:03Z

GEODE-2582: New client can send a Put request with Protobuf IDL.

* Update the proto IDL
* Get a put request working.

Currently this only uses String serialization; serialization protocols
still have to be implemented.




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

[GitHub] geode issue #509: GEODE-265: Removing deprecated API from Execution interfac...

[jhuynh1]

Github user jhuynh1 commented on the issue:

https://github.com/apache/geode/pull/509
  
@metatype Will do for both this and PR#511


---
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-265) Remove deprecated methods on Execution interface

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-265:
--

Github user metatype commented on the issue:

https://github.com/apache/geode/pull/509
  
@jhuynh1 I just noticed the one recent deprecation.  Given this is a public 
API change you should probably double-check me :-)


> Remove deprecated methods on Execution interface
> 
>
> Key: GEODE-265
> URL: https://issues.apache.org/jira/browse/GEODE-265
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
>   Original Estimate: 5h
>  Remaining Estimate: 5h
>
> The Execution interface has a number of execute methods that have been 
> deprecated. It looks like these could be easily removed.



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

[GitHub] geode issue #509: GEODE-265: Removing deprecated API from Execution interfac...

[metatype]

Github user metatype commented on the issue:

https://github.com/apache/geode/pull/509
  
@jhuynh1 I just noticed the one recent deprecation.  Given this is a public 
API change you should probably double-check me :-)


---
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-2938) Remove @Deprecated tag from OrderByComparatorUnmapped

[nabarun (JIRA)]

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

nabarun resolved GEODE-2938.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Remove @Deprecated tag from OrderByComparatorUnmapped
> -
>
> Key: GEODE-2938
> URL: https://issues.apache.org/jira/browse/GEODE-2938
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: nabarun
>Assignee: nabarun
> Fix For: 1.2.0
>
>
> Issue:
> OrderByComparatorUnmapped is marked @Deprecated but it is currently in heavy 
> use in the geode codebase and we have no alternative code for this.
> Solution:
> Remove the deprecated tag



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

[jira] [Commented] (GEODE-2938) Remove @Deprecated tag from OrderByComparatorUnmapped

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2938:


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

GEODE-2938: Removed the deprecated tag

* Removed the deprecated tag in OrderByComparatorUnmapped.
* This code is still being used.


> Remove @Deprecated tag from OrderByComparatorUnmapped
> -
>
> Key: GEODE-2938
> URL: https://issues.apache.org/jira/browse/GEODE-2938
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: nabarun
>Assignee: nabarun
> Fix For: 1.2.0
>
>
> Issue:
> OrderByComparatorUnmapped is marked @Deprecated but it is currently in heavy 
> use in the geode codebase and we have no alternative code for this.
> Solution:
> Remove the deprecated tag



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

[jira] [Resolved] (GEODE-2937) Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system property

[Jason Huynh (JIRA)]

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

Jason Huynh resolved GEODE-2937.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system property
> --
>
> Key: GEODE-2937
> URL: https://issues.apache.org/jira/browse/GEODE-2937
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.2.0
>
>
> In a refactoring effort last year, the system property 
> REMOVE_FROM_QUEUE_ON_EXCEPTION was removed as it was unknown that it was 
> actually being used. 
> There are no tests that actually fail when the code is removed but it is a 
> behavior that is definitely wanted by certain users and may be defaulted to 
> in the future.



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

[jira] [Assigned] (GEODE-2938) Remove @Deprecated tag from OrderByComparatorUnmapped

[nabarun (JIRA)]

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

nabarun reassigned GEODE-2938:
--

Assignee: nabarun

> Remove @Deprecated tag from OrderByComparatorUnmapped
> -
>
> Key: GEODE-2938
> URL: https://issues.apache.org/jira/browse/GEODE-2938
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: nabarun
>Assignee: nabarun
>
> Issue:
> OrderByComparatorUnmapped is marked @Deprecated but it is currently in heavy 
> use in the geode codebase and we have no alternative code for this.
> Solution:
> Remove the deprecated tag



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

[jira] [Created] (GEODE-2938) Remove @Deprecated tag from OrderByComparatorUnmapped

[nabarun (JIRA)]

nabarun created GEODE-2938:
--

 Summary: Remove @Deprecated tag from OrderByComparatorUnmapped
 Key: GEODE-2938
 URL: https://issues.apache.org/jira/browse/GEODE-2938
 Project: Geode
  Issue Type: Bug
  Components: querying
Reporter: nabarun


Issue:
OrderByComparatorUnmapped is marked @Deprecated but it is currently in heavy 
use in the geode codebase and we have no alternative code for this.

Solution:
Remove the deprecated tag



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

[jira] [Updated] (GEODE-2582) Prototype Protobuf Protocol: Client can send Put Request

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan updated GEODE-2582:

Description: 
Using protobuf as the IDL for the [client-server 
protocol|https://cwiki.apache.org/confluence/display/GEODE/New+Client+Server+Protocol],

GIVEN I'm a community developer writing a new client
AND I was given some protofiles
AND I have established a connection to the Gemfire server
WHEN the client sends over a put message and some data
THEN I should be able to see my data in the cache as *JSON*

 Out of scope:
* Stats
* PDX
* Retry

  was:A client should be able to send a connection request so that it can start 
interacting with server and the developer knows things are working.


> Prototype Protobuf Protocol: Client can send Put Request
> 
>
> Key: GEODE-2582
> URL: https://issues.apache.org/jira/browse/GEODE-2582
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Addison
>
> Using protobuf as the IDL for the [client-server 
> protocol|https://cwiki.apache.org/confluence/display/GEODE/New+Client+Server+Protocol],
> GIVEN I'm a community developer writing a new client
> AND I was given some protofiles
> AND I have established a connection to the Gemfire server
> WHEN the client sends over a put message and some data
> THEN I should be able to see my data in the cache as *JSON*
>  Out of scope:
> * Stats
> * PDX
> * Retry



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

[jira] [Assigned] (GEODE-2582) Prototype Protobuf Protocol: Client can send Put Request

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan reassigned GEODE-2582:
---

Assignee: Galen O'Sullivan

> Prototype Protobuf Protocol: Client can send Put Request
> 
>
> Key: GEODE-2582
> URL: https://issues.apache.org/jira/browse/GEODE-2582
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Addison
>Assignee: Galen O'Sullivan
>
> Using protobuf as the IDL for the [client-server 
> protocol|https://cwiki.apache.org/confluence/display/GEODE/New+Client+Server+Protocol],
> GIVEN I'm a community developer writing a new client
> AND I was given some protofiles
> AND I have established a connection to the Gemfire server
> WHEN the client sends over a put message and some data
> THEN I should be able to see my data in the cache as *JSON*
>  Out of scope:
> * Stats
> * PDX
> * Retry



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

[jira] [Updated] (GEODE-2582) Prototype Protobuf Protocol: Client can send Put Request

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan updated GEODE-2582:

Summary: Prototype Protobuf Protocol: Client can send Put Request  (was: 
Client can connect to a Geode Server)

> Prototype Protobuf Protocol: Client can send Put Request
> 
>
> Key: GEODE-2582
> URL: https://issues.apache.org/jira/browse/GEODE-2582
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Addison
>
> A client should be able to send a connection request so that it can start 
> interacting with server and the developer knows things are working.



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

[jira] [Commented] (GEODE-265) Remove deprecated methods on Execution interface

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-265:
--

Github user jhuynh1 commented on the issue:

https://github.com/apache/geode/pull/509
  
I think these changes are ok (I didn't check when these were deprecated but 
I assume @metatype already did the grunt work on it.  I can merge these changes 
in if no one has any other reviews


> Remove deprecated methods on Execution interface
> 
>
> Key: GEODE-265
> URL: https://issues.apache.org/jira/browse/GEODE-265
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
>   Original Estimate: 5h
>  Remaining Estimate: 5h
>
> The Execution interface has a number of execute methods that have been 
> deprecated. It looks like these could be easily removed.



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

Fixed: apache/geode#2610 (develop - d9343d4)

[Travis CI]

Build Update for apache/geode
-

Build: #2610
Status: Fixed

Duration: 8 minutes and 45 seconds
Commit: d9343d4 (develop)
Author: Jason Huynh
Message: GEODE-2937: Restore removeFromQueueOnException

View the changeset: 
https://github.com/apache/geode/compare/e216fde1e4b1...d9343d4406ac

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/233725842?utm_source=email_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

[GitHub] geode issue #509: GEODE-265: Removing deprecated API from Execution interfac...

[jhuynh1]

Github user jhuynh1 commented on the issue:

https://github.com/apache/geode/pull/509
  
I think these changes are ok (I didn't check when these were deprecated but 
I assume @metatype already did the grunt work on it.  I can merge these changes 
in if no one has any other reviews


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

[GitHub] geode issue #511: Feature/geode 269

[jhuynh1]

Github user jhuynh1 commented on the issue:

https://github.com/apache/geode/pull/511
  
I still get a conflicting file but it was simple enough to change.  It 
looks good to me.  I'll merge this in when I get a chance (tomorrow?)


---
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-2937) Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system property

[ASF GitHub Bot (JIRA)]

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

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

Github user jhuynh1 closed the pull request at:

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


> Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system property
> --
>
> Key: GEODE-2937
> URL: https://issues.apache.org/jira/browse/GEODE-2937
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> In a refactoring effort last year, the system property 
> REMOVE_FROM_QUEUE_ON_EXCEPTION was removed as it was unknown that it was 
> actually being used. 
> There are no tests that actually fail when the code is removed but it is a 
> behavior that is definitely wanted by certain users and may be defaulted to 
> in the future.



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

[GitHub] geode pull request #519: GEODE-2937: Restore removeFromQueueOnException

[jhuynh1]

Github user jhuynh1 closed the pull request at:

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


---
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-2937) Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system property

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2937:


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

GEODE-2937: Restore removeFromQueueOnException


> Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system property
> --
>
> Key: GEODE-2937
> URL: https://issues.apache.org/jira/browse/GEODE-2937
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> In a refactoring effort last year, the system property 
> REMOVE_FROM_QUEUE_ON_EXCEPTION was removed as it was unknown that it was 
> actually being used. 
> There are no tests that actually fail when the code is removed but it is a 
> behavior that is definitely wanted by certain users and may be defaulted to 
> in the future.



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

Broken: apache/geode#2608 (develop - e216fde)

[Travis CI]

Build Update for apache/geode
-

Build: #2608
Status: Broken

Duration: 8 minutes and 8 seconds
Commit: e216fde (develop)
Author: Hitesh Khamesra
Message: GEODE-2804 Update InetSocketAddress, when there is IOException.

Geode keeps InetSocketAddress for locators. So, if locators ip
changes in cloud/VM enviroment then Geode process unable to
connect to locator. Thus we have fixed this problem in two way.

a. If Geode client sees IOException while connecting to locator then
we change cached InetAddress to use locator hostname. In this way,
client does DNS query again for locator host.
b. For other Geode process, now we connect to locator using hostname.

Added couple of junit tests for it.

View the changeset: 
https://github.com/apache/geode/compare/90ee3d8a0f07...e216fde1e4b1

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/233714751?utm_source=email_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

Re: org.apache.geode.internal.InternalDataSerializer API Changes...

[Kirk Lund]

I think we should definitely try to refactor any Geode internals that SDG
is using to be public API or SPI. We'll need to take a closer look at how
SDG is using those classes to plan what to do.

If I change or any classes on your list (or public APIs), I'll give you
heads up next time.

On Thu, May 18, 2017 at 10:21 AM, John Blum  wrote:

> Hi Kirk (also responding to Bruce as I was writing this before he sent)-
>
> Thank you for following up.
>
> Regarding the addition of the getOnlineLocators()...
>
> SDG does implement
>  org/springframework/data/gemfire/client/support/package-summary.html>
> [1]
> a few Geode interfaces, such as *org.apache.geode.cache.client.Pool*.
> This
> is due in part since not all the state for certain Geode objects (e.g.
> Pool) is known in advance as the actual object may not have been created by
> the *Spring* container yet.  However, that state is captured in *Spring*
> FactoryBeans, which will be used to construct the actual object at the
> appropriate time.
>
> Anyway, like the "internal" API, I have tried to keep such implementations
> of Geode interfaces/classes to a minimum.  Still, it is a good indicator of
> when something has changed since I will most certainly get a compilation
> failure.  This leads me to, I do need to know when APIs change to provide
> appropriate support in SDG, possibly in configuration, whether XML of via
> Java/annotations with the FactoryBeans, e.g. PoolFactoryBean
>  org/springframework/data/gemfire/client/PoolFactoryBean.html>
> [2],
> especially if it is a configuration property/attribute.  Other cases my be
> important from an accessibility or information standpoint (probably more so
> for tooling).
>
> As for the InternalDataSerializer...
>
> No worries.  I found an acceptable and actually better workaround.  Again,
> I am trying to reduce or completely eliminate the use of "internal" classes
> in SDG.  Unfortunately, a quick search (using regex) in SDG for "import
> org\.apache\.geode.*internal" reveals 35 occurrences, the most pertinent
> ones being...
>
> org.apache.geode.internal.GemFireVersion (used in debugging)
> org.apache.geode.internal.DistributionLocator
> org.apache.geode.internal.InternalDataSerializer
> org.apache.geode.internal.cache.GemFireCacheImpl
> org.apache.geode.internal.cache.LocalRegion (used to inspect whether a
> server proxy is present to acquire the appropriate QueryService)
> org.apache.geode.internal.cache.PartitionedRegion
> org.apache.geode.internal.cache.UserSpecifiedRegionAttributes
> org.apache.geode.internal.cache.lru.LRUCapacityController
> org.apache.geode.internal.cache.lru.MemLRUCapacityController
> org.apache.geode.internal.cache.query.internal.ResultsBag
> org.apache.geode.internal.distributed.internal.DistributionConfig
> org.apache.geode.internal.distributed.internal.InternalDistributedSystem
> org.apache.geode.internal.distributed.internal.InternalLocator
> org.apache.geode.internal.datasource.ConfigProperty (JNDI support)
> org.apache.geode.internal.jndi.JNDIInvoker (JNDI support)
> org.apache.geode.internal.security.SecurityService (my doing)
>
> Most of this was added before my time.  I just need time to review these
> more carefully, and how each is used.  I know many of these are used for
> good reason.
>
> Thanks,
> John
>
>
> [1]
> http://docs.spring.io/spring-data-gemfire/docs/current/api/
> org/springframework/data/gemfire/client/support/package-summary.html
> [2]
> http://docs.spring.io/spring-data-gemfire/docs/current/api/
> org/springframework/data/gemfire/client/PoolFactoryBean.html
>
>
> On Thu, May 18, 2017 at 10:18 AM, Bruce Schuchardt  >
> wrote:
>
> > John, is it possible to list the internal APIs needed by SDG?  I don't
> > think we can live with a requirement that all internal API changes need
> to
> > be communicated and blessed.  We need to address SDG's needs in the
> public
> > APIs and get rid of this dependency.
> >
> >
> > Le 5/18/2017 à 9:36 AM, Kirk Lund a écrit :
> >
> >> Hi John! How did the addition of getOnlineLocators() cause SDG build to
> >> fail? I checked [9] but I couldn't quite grok what happened. I would've
> >> thought that adding would be ok but removing could potentially break
> SDG.
> >>
> >> The InternalDataSerializer change was probably mine. I reduced scope of
> >> methods and variables where possible. Sorry about that. Do you need me
> to
> >> restore getSerializer to public?
> >>
> >> On Wed, May 17, 2017 at 4:42 PM, John Blum  wrote:
> >>
> >> Geode devs-
> >>>
> >>> I am not sure how decisions are made when changing Geode's API, but I
> >>> would
> >>> caution that more care should be taken when doing so, regardless of
> >>> whether
> >>> the APIs are public or not, but especially when they are public.
> >>>
> >>> Unfortunately, in this particular case, the 

Re: Build failed in Jenkins: Geode-nightly #838

[Bruce Schuchardt]

It looks like a test using multicast is not cleaning up after itself and 
infected the tests that failed in this Jenkins run.  The Rest tests that 
failed do not configure their caches to use multicast.


Le 5/17/2017 à 8:50 PM, Apache Jenkins Server a écrit :

See 


Changes:

[klund] GEODE-2929: remove superfluous uses of final from internal classes

[bschuchardt] GEODE-2915 Messages rejected due to unknown "vmkind"

[upthewaterspout] LuceneClientSecurityDUnitTest was not testing anything

[jstewart] GEODE-2836: CacheCallback now extends Declarable

[jstewart] GEODE-2836: Fix compilation error introduced by rebase

[nnag] GEODE-2914: Fixed few javadoc formatting issues.

--
[...truncated 355.46 KB...]
at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest > 
testSSLWithTLSv12ProtocolLegacy[1] FAILED
 java.lang.AssertionError: Suspicious strings were written to the log 
during this run.
 Fix the strings or use IgnoredException.addIgnoredException to ignore.
 ---
 Found suspect string in log4j at line 379

 [error 2017/05/17 06:43:34.408 UTC  
tid=3528] failed setting interface to /127.0.1.1: java.net.SocketException: bad 
argument for IP_MULTICAST_IF: address not bound to any interface
 java.net.SocketException: bad argument for IP_MULTICAST_IF: address not 
bound to any interface
at java.net.PlainDatagramSocketImpl.socketSetOption0(Native Method)
at 
java.net.PlainDatagramSocketImpl.socketSetOption(PlainDatagramSocketImpl.java:74)
at 
java.net.AbstractPlainDatagramSocketImpl.setOption(AbstractPlainDatagramSocketImpl.java:309)
at java.net.MulticastSocket.setInterface(MulticastSocket.java:471)
at org.jgroups.protocols.UDP.setInterface(UDP.java:443)
at org.jgroups.protocols.UDP.createMulticastSocket(UDP.java:511)
at 
org.jgroups.protocols.UDP.createMulticastSocketWithBindPort(UDP.java:494)
at org.jgroups.protocols.UDP.createSockets(UDP.java:348)
at org.jgroups.protocols.UDP.start(UDP.java:266)
at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
at org.jgroups.JChannel.startStack(JChannel.java:889)
at org.jgroups.JChannel._preConnect(JChannel.java:553)
at org.jgroups.JChannel.connect(JChannel.java:288)
at org.jgroups.JChannel.connect(JChannel.java:279)
at 
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:342)
at 
org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:147)
at 
org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102)
at 
org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89)
at 
org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1116)
at 
org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1164)
at 
org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:535)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:693)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:305)
at 
org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
at 
org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:714)
at 
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:342)
at 
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:302)
at org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
at 
org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:202)
at 
org.apache.geode.cache.client.internal.LocatorTestBase.startLocator(LocatorTestBase.java:111)
at 

Re: org.apache.geode.internal.InternalDataSerializer API Changes...

[John Blum]

Hi Kirk (also responding to Bruce as I was writing this before he sent)-

Thank you for following up.

Regarding the addition of the getOnlineLocators()...

SDG does implement

[1]
a few Geode interfaces, such as *org.apache.geode.cache.client.Pool*.  This
is due in part since not all the state for certain Geode objects (e.g.
Pool) is known in advance as the actual object may not have been created by
the *Spring* container yet.  However, that state is captured in *Spring*
FactoryBeans, which will be used to construct the actual object at the
appropriate time.

Anyway, like the "internal" API, I have tried to keep such implementations
of Geode interfaces/classes to a minimum.  Still, it is a good indicator of
when something has changed since I will most certainly get a compilation
failure.  This leads me to, I do need to know when APIs change to provide
appropriate support in SDG, possibly in configuration, whether XML of via
Java/annotations with the FactoryBeans, e.g. PoolFactoryBean

[2],
especially if it is a configuration property/attribute.  Other cases my be
important from an accessibility or information standpoint (probably more so
for tooling).

As for the InternalDataSerializer...

No worries.  I found an acceptable and actually better workaround.  Again,
I am trying to reduce or completely eliminate the use of "internal" classes
in SDG.  Unfortunately, a quick search (using regex) in SDG for "import
org\.apache\.geode.*internal" reveals 35 occurrences, the most pertinent
ones being...

org.apache.geode.internal.GemFireVersion (used in debugging)
org.apache.geode.internal.DistributionLocator
org.apache.geode.internal.InternalDataSerializer
org.apache.geode.internal.cache.GemFireCacheImpl
org.apache.geode.internal.cache.LocalRegion (used to inspect whether a
server proxy is present to acquire the appropriate QueryService)
org.apache.geode.internal.cache.PartitionedRegion
org.apache.geode.internal.cache.UserSpecifiedRegionAttributes
org.apache.geode.internal.cache.lru.LRUCapacityController
org.apache.geode.internal.cache.lru.MemLRUCapacityController
org.apache.geode.internal.cache.query.internal.ResultsBag
org.apache.geode.internal.distributed.internal.DistributionConfig
org.apache.geode.internal.distributed.internal.InternalDistributedSystem
org.apache.geode.internal.distributed.internal.InternalLocator
org.apache.geode.internal.datasource.ConfigProperty (JNDI support)
org.apache.geode.internal.jndi.JNDIInvoker (JNDI support)
org.apache.geode.internal.security.SecurityService (my doing)

Most of this was added before my time.  I just need time to review these
more carefully, and how each is used.  I know many of these are used for
good reason.

Thanks,
John


[1]
http://docs.spring.io/spring-data-gemfire/docs/current/api/org/springframework/data/gemfire/client/support/package-summary.html
[2]
http://docs.spring.io/spring-data-gemfire/docs/current/api/org/springframework/data/gemfire/client/PoolFactoryBean.html


On Thu, May 18, 2017 at 10:18 AM, Bruce Schuchardt 
wrote:

> John, is it possible to list the internal APIs needed by SDG?  I don't
> think we can live with a requirement that all internal API changes need to
> be communicated and blessed.  We need to address SDG's needs in the public
> APIs and get rid of this dependency.
>
>
> Le 5/18/2017 à 9:36 AM, Kirk Lund a écrit :
>
>> Hi John! How did the addition of getOnlineLocators() cause SDG build to
>> fail? I checked [9] but I couldn't quite grok what happened. I would've
>> thought that adding would be ok but removing could potentially break SDG.
>>
>> The InternalDataSerializer change was probably mine. I reduced scope of
>> methods and variables where possible. Sorry about that. Do you need me to
>> restore getSerializer to public?
>>
>> On Wed, May 17, 2017 at 4:42 PM, John Blum  wrote:
>>
>> Geode devs-
>>>
>>> I am not sure how decisions are made when changing Geode's API, but I
>>> would
>>> caution that more care should be taken when doing so, regardless of
>>> whether
>>> the APIs are public or not, but especially when they are public.
>>>
>>> Unfortunately, in this particular case, the API in question is deemed
>>> "internal", which I know, are subject to change.  However, the problem
>>> with
>>> this is, the public API is insufficient in some cases, particularly for
>>> "frameworks" (e.g. SDG) and "tooling" building on Geode and attempting to
>>> uphold Geode's functional/behavioral contract.
>>>
>>> By way of example, a recent *Spring Data Geode* build broke
>>>  [1] because, the
>>> org.apache.geode.internal.InternalDataSerializer class was recently
>>> changed. The scope of 

Re: org.apache.geode.internal.InternalDataSerializer API Changes...

[Bruce Schuchardt]

John, is it possible to list the internal APIs needed by SDG?  I don't 
think we can live with a requirement that all internal API changes need 
to be communicated and blessed.  We need to address SDG's needs in the 
public APIs and get rid of this dependency.


Le 5/18/2017 à 9:36 AM, Kirk Lund a écrit :

Hi John! How did the addition of getOnlineLocators() cause SDG build to
fail? I checked [9] but I couldn't quite grok what happened. I would've
thought that adding would be ok but removing could potentially break SDG.

The InternalDataSerializer change was probably mine. I reduced scope of
methods and variables where possible. Sorry about that. Do you need me to
restore getSerializer to public?

On Wed, May 17, 2017 at 4:42 PM, John Blum  wrote:


Geode devs-

I am not sure how decisions are made when changing Geode's API, but I would
caution that more care should be taken when doing so, regardless of whether
the APIs are public or not, but especially when they are public.

Unfortunately, in this particular case, the API in question is deemed
"internal", which I know, are subject to change.  However, the problem with
this is, the public API is insufficient in some cases, particularly for
"frameworks" (e.g. SDG) and "tooling" building on Geode and attempting to
uphold Geode's functional/behavioral contract.

By way of example, a recent *Spring Data Geode* build broke
 [1] because, the
org.apache.geode.internal.InternalDataSerializer class was recently
changed. The scope of getSerializer(:Class):DataSerializer was changed
from *public
*
[2]
to *private
*
[3]
in a seemingly unrelated commit.

There is a class

[4]
in SDG that extends DataSerializer

[5]
(in Geode's public API) but must use the InternalDataSerializer (internal
Geode API) when changes (e.g. "supported classes") to the SDG serializer
need to be "distributed" across the cluster.  SDG"s serializer use to call
this getSerializer(:Class):DataSerializer method.  However, in this case,
I
fixed the problem by not calling this "overloaded" method as it was not
strictly necessary.

While I am trying to avoid the use of "internal" Geode classes and APIs in
SDG in general, as I mention above, this is not always possible.  For
instance, there are a few API blunders such as the ability to register

[6]
a DataSerializer class but not "unregister" it; that is in

[7]
InternalDataSerializer.  The other bad API practices on this class (i.e.
(Internal)DataSerializer) alone.

Framework and tool developers must occasionally rely on "internal" APIs
(especially when the public API is insufficient) to order to achieve a
similar experience to Geode alone; something to keep in mind as Geode's
ecosystem grows.

Finally, I'll also add that, I do need to know anytime the public API
changes as well.  Recently the getOnlineLocators() method

[8]
was added to org.apache.geode.cache.client.Pool, which caused another SDG
build  [9] to fail.

Special thank you to *Nabarun* and *Diane* for the recent heads about the
LuceneQueryFactory method name change... from setResultLimit(:int) to
setLimit(:int).

Regards,

--
-John


[1] https://build.spring.io/browse/SGF-NAG-556/log
[2]
https://github.com/apache/geode/blob/rel/v1.1.1/geode-
core/src/main/java/org/apache/geode/internal/InternalDataSerializer.java#
L1113
[3]
https://github.com/apache/geode/blob/a44585316a8d7eed35917c1dfd8293
15b34ce316/geode-core/src/main/java/org/apache/geode/internal/
InternalDataSerializer.java#L1090
[4]
https://github.com/spring-projects/spring-data-geode/
blob/master/src/main/java/org/springframework/data/gemfire/
serialization/EnumSerializer.java#L39
[5]
http://gemfire-90-javadocs.docs.pivotal.io/org/apache/
geode/DataSerializer.html
[6]
http://gemfire-90-javadocs.docs.pivotal.io/org/apache/
geode/DataSerializer.html#register-java.lang.Class-
[7]
https://github.com/apache/geode/blob/rel/v1.1.1/geode-
core/src/main/java/org/apache/geode/internal/InternalDataSerializer.java#
L1077

[GitHub] geode pull request #519: GEODE-2937: Restore removeFromQueueOnException

[jhuynh1]

GitHub user jhuynh1 opened a pull request:

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

GEODE-2937: Restore removeFromQueueOnException

Restoring the system property REMOVE_FROM_QUEUE_ON_EXCEPTION.  This was 
no-op'd in some refactoring code last year and should not have been.

Review request for:
@boglesby 



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

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

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

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






---
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-2937) Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system property

[ASF GitHub Bot (JIRA)]

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

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

GitHub user jhuynh1 opened a pull request:

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

GEODE-2937: Restore removeFromQueueOnException

Restoring the system property REMOVE_FROM_QUEUE_ON_EXCEPTION.  This was 
no-op'd in some refactoring code last year and should not have been.

Review request for:
@boglesby 



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

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

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

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






> Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system property
> --
>
> Key: GEODE-2937
> URL: https://issues.apache.org/jira/browse/GEODE-2937
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> In a refactoring effort last year, the system property 
> REMOVE_FROM_QUEUE_ON_EXCEPTION was removed as it was unknown that it was 
> actually being used. 
> There are no tests that actually fail when the code is removed but it is a 
> behavior that is definitely wanted by certain users and may be defaulted to 
> in the future.



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

[jira] [Commented] (GEODE-2937) Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system property

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2937:


Commit 9d5581b70799c32ccb45596e8734012e11e1e3f9 in geode's branch 
refs/heads/feature/GEODE-2937 from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=9d5581b ]

GEODE-2937: Restore removeFromQueueOnException


> Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system property
> --
>
> Key: GEODE-2937
> URL: https://issues.apache.org/jira/browse/GEODE-2937
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> In a refactoring effort last year, the system property 
> REMOVE_FROM_QUEUE_ON_EXCEPTION was removed as it was unknown that it was 
> actually being used. 
> There are no tests that actually fail when the code is removed but it is a 
> behavior that is definitely wanted by certain users and may be defaulted to 
> in the future.



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

[jira] [Assigned] (GEODE-2804) Allow a locator host to be taken off line and replaced with a different machine having the same host name

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra reassigned GEODE-2804:
--

Assignee: Hitesh Khamesra

> Allow a locator host to be taken off line and replaced with a different 
> machine having the same host name
> -
>
> Key: GEODE-2804
> URL: https://issues.apache.org/jira/browse/GEODE-2804
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, membership, native client
>Affects Versions: 1.1.1
>Reporter: Bruce Schuchardt
>Assignee: Hitesh Khamesra
>
> It is not unlikely that in a long-running system a machine hosting a locator 
> will break down and need to be replace, or that a virtual machine hosting a 
> locator will be stopped and restarted.  In either case the machine may have a 
> different IP address.
> Clients and servers currently cache the IP address of a locator and should be 
> changed to re-resolve the host name if the address stops being usable.
> Servers currently cannot be started if they are given a host name that can 
> not be resolved.  They should be changed to allow this and start up if they 
> are able to contact one or more of the other locators in their "locators" 
> setting.



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

[jira] [Resolved] (GEODE-2804) Allow a locator host to be taken off line and replaced with a different machine having the same host name

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra resolved GEODE-2804.

Resolution: Fixed

> Allow a locator host to be taken off line and replaced with a different 
> machine having the same host name
> -
>
> Key: GEODE-2804
> URL: https://issues.apache.org/jira/browse/GEODE-2804
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, membership, native client
>Affects Versions: 1.1.1
>Reporter: Bruce Schuchardt
>Assignee: Hitesh Khamesra
>
> It is not unlikely that in a long-running system a machine hosting a locator 
> will break down and need to be replace, or that a virtual machine hosting a 
> locator will be stopped and restarted.  In either case the machine may have a 
> different IP address.
> Clients and servers currently cache the IP address of a locator and should be 
> changed to re-resolve the host name if the address stops being usable.
> Servers currently cannot be started if they are given a host name that can 
> not be resolved.  They should be changed to allow this and start up if they 
> are able to contact one or more of the other locators in their "locators" 
> setting.



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

[jira] [Commented] (GEODE-2804) Allow a locator host to be taken off line and replaced with a different machine having the same host name

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2804:


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

GEODE-2804 Update InetSocketAddress, when there is IOException.

Geode keeps InetSocketAddress for locators. So, if locators ip
changes in cloud/VM enviroment then Geode process unable to
connect to locator. Thus we have fixed this problem in two way.

a. If Geode client sees IOException while connecting to locator then
we change cached InetAddress to use locator hostname. In this way,
client does DNS query again for locator host.
b. For other Geode process, now we connect to locator using hostname.

Added couple of junit tests for it.


> Allow a locator host to be taken off line and replaced with a different 
> machine having the same host name
> -
>
> Key: GEODE-2804
> URL: https://issues.apache.org/jira/browse/GEODE-2804
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, membership, native client
>Affects Versions: 1.1.1
>Reporter: Bruce Schuchardt
>
> It is not unlikely that in a long-running system a machine hosting a locator 
> will break down and need to be replace, or that a virtual machine hosting a 
> locator will be stopped and restarted.  In either case the machine may have a 
> different IP address.
> Clients and servers currently cache the IP address of a locator and should be 
> changed to re-resolve the host name if the address stops being usable.
> Servers currently cannot be started if they are given a host name that can 
> not be resolved.  They should be changed to allow this and start up if they 
> are able to contact one or more of the other locators in their "locators" 
> setting.



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

Re: org.apache.geode.internal.InternalDataSerializer API Changes...

[Kirk Lund]

Hi John! How did the addition of getOnlineLocators() cause SDG build to
fail? I checked [9] but I couldn't quite grok what happened. I would've
thought that adding would be ok but removing could potentially break SDG.

The InternalDataSerializer change was probably mine. I reduced scope of
methods and variables where possible. Sorry about that. Do you need me to
restore getSerializer to public?

On Wed, May 17, 2017 at 4:42 PM, John Blum  wrote:

> Geode devs-
>
> I am not sure how decisions are made when changing Geode's API, but I would
> caution that more care should be taken when doing so, regardless of whether
> the APIs are public or not, but especially when they are public.
>
> Unfortunately, in this particular case, the API in question is deemed
> "internal", which I know, are subject to change.  However, the problem with
> this is, the public API is insufficient in some cases, particularly for
> "frameworks" (e.g. SDG) and "tooling" building on Geode and attempting to
> uphold Geode's functional/behavioral contract.
>
> By way of example, a recent *Spring Data Geode* build broke
>  [1] because, the
> org.apache.geode.internal.InternalDataSerializer class was recently
> changed. The scope of getSerializer(:Class):DataSerializer was changed
> from *public
>  core/src/main/java/org/apache/geode/internal/InternalDataSerializer.java#
> L1113>*
> [2]
> to *private
>  15b34ce316/geode-core/src/main/java/org/apache/geode/internal/
> InternalDataSerializer.java#L1090>*
> [3]
> in a seemingly unrelated commit.
>
> There is a class
>  blob/master/src/main/java/org/springframework/data/gemfire/
> serialization/EnumSerializer.java#L39>
> [4]
> in SDG that extends DataSerializer
>  geode/DataSerializer.html>
> [5]
> (in Geode's public API) but must use the InternalDataSerializer (internal
> Geode API) when changes (e.g. "supported classes") to the SDG serializer
> need to be "distributed" across the cluster.  SDG"s serializer use to call
> this getSerializer(:Class):DataSerializer method.  However, in this case,
> I
> fixed the problem by not calling this "overloaded" method as it was not
> strictly necessary.
>
> While I am trying to avoid the use of "internal" Geode classes and APIs in
> SDG in general, as I mention above, this is not always possible.  For
> instance, there are a few API blunders such as the ability to register
>  geode/DataSerializer.html#register-java.lang.Class->
> [6]
> a DataSerializer class but not "unregister" it; that is in
>  core/src/main/java/org/apache/geode/internal/InternalDataSerializer.java#
> L1077>
> [7]
> InternalDataSerializer.  The other bad API practices on this class (i.e.
> (Internal)DataSerializer) alone.
>
> Framework and tool developers must occasionally rely on "internal" APIs
> (especially when the public API is insufficient) to order to achieve a
> similar experience to Geode alone; something to keep in mind as Geode's
> ecosystem grows.
>
> Finally, I'll also add that, I do need to know anytime the public API
> changes as well.  Recently the getOnlineLocators() method
>  d3baa942d3/geode-core/src/main/java/org/apache/geode/
> cache/client/Pool.java#L210>
> [8]
> was added to org.apache.geode.cache.client.Pool, which caused another SDG
> build  [9] to fail.
>
> Special thank you to *Nabarun* and *Diane* for the recent heads about the
> LuceneQueryFactory method name change... from setResultLimit(:int) to
> setLimit(:int).
>
> Regards,
>
> --
> -John
>
>
> [1] https://build.spring.io/browse/SGF-NAG-556/log
> [2]
> https://github.com/apache/geode/blob/rel/v1.1.1/geode-
> core/src/main/java/org/apache/geode/internal/InternalDataSerializer.java#
> L1113
> [3]
> https://github.com/apache/geode/blob/a44585316a8d7eed35917c1dfd8293
> 15b34ce316/geode-core/src/main/java/org/apache/geode/internal/
> InternalDataSerializer.java#L1090
> [4]
> https://github.com/spring-projects/spring-data-geode/
> blob/master/src/main/java/org/springframework/data/gemfire/
> serialization/EnumSerializer.java#L39
> [5]
> http://gemfire-90-javadocs.docs.pivotal.io/org/apache/
> geode/DataSerializer.html
> [6]
> http://gemfire-90-javadocs.docs.pivotal.io/org/apache/
> geode/DataSerializer.html#register-java.lang.Class-
> [7]
> https://github.com/apache/geode/blob/rel/v1.1.1/geode-
> core/src/main/java/org/apache/geode/internal/InternalDataSerializer.java#
> L1077
> [8]
> https://github.com/apache/geode/blob/61f676b0187e8918ca62f4a2ec9b6b
> 

[jira] [Created] (GEODE-2937) Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system property

[Jason Huynh (JIRA)]

Jason Huynh created GEODE-2937:
--

 Summary: Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system 
property
 Key: GEODE-2937
 URL: https://issues.apache.org/jira/browse/GEODE-2937
 Project: Geode
  Issue Type: Bug
  Components: wan
Reporter: Jason Huynh


In a refactoring effort last year, the system property 
REMOVE_FROM_QUEUE_ON_EXCEPTION was removed as it was unknown that it was 
actually being used. 

There are no tests that actually test fail when the code is removed but it is a 
behavior that is definitely wanted by certain users and may be defaulted to in 
the future.



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

[jira] [Updated] (GEODE-2937) Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system property

[Jason Huynh (JIRA)]

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

Jason Huynh updated GEODE-2937:
---
Description: 
In a refactoring effort last year, the system property 
REMOVE_FROM_QUEUE_ON_EXCEPTION was removed as it was unknown that it was 
actually being used. 

There are no tests that actually fail when the code is removed but it is a 
behavior that is definitely wanted by certain users and may be defaulted to in 
the future.

  was:
In a refactoring effort last year, the system property 
REMOVE_FROM_QUEUE_ON_EXCEPTION was removed as it was unknown that it was 
actually being used. 

There are no tests that actually test fail when the code is removed but it is a 
behavior that is definitely wanted by certain users and may be defaulted to in 
the future.


> Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system property
> --
>
> Key: GEODE-2937
> URL: https://issues.apache.org/jira/browse/GEODE-2937
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> In a refactoring effort last year, the system property 
> REMOVE_FROM_QUEUE_ON_EXCEPTION was removed as it was unknown that it was 
> actually being used. 
> There are no tests that actually fail when the code is removed but it is a 
> behavior that is definitely wanted by certain users and may be defaulted to 
> in the future.



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

[jira] [Assigned] (GEODE-2937) Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system property

[Jason Huynh (JIRA)]

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

Jason Huynh reassigned GEODE-2937:
--

Assignee: Jason Huynh

> Restore behavior of REMOVE_FROM_QUEUE_ON_EXCEPTION system property
> --
>
> Key: GEODE-2937
> URL: https://issues.apache.org/jira/browse/GEODE-2937
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> In a refactoring effort last year, the system property 
> REMOVE_FROM_QUEUE_ON_EXCEPTION was removed as it was unknown that it was 
> actually being used. 
> There are no tests that actually test fail when the code is removed but it is 
> a behavior that is definitely wanted by certain users and may be defaulted to 
> in the future.



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

[jira] [Commented] (GEODE-2788) Add official Socket timeout parameter when connecting to servers/locators

[ASF GitHub Bot (JIRA)]

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

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

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/474
  
Masaki, it looks like there are some conflicts that need to be resolved


> Add official Socket timeout parameter when connecting to servers/locators
> -
>
> Key: GEODE-2788
> URL: https://issues.apache.org/jira/browse/GEODE-2788
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, docs
>Reporter: Masaki Yamakawa
>Priority: Minor
>  Labels: patch
>
> When connecting from the client to the servers/locators, if the 
> servers/locators is not started, the connection can not be established and a 
> Socket timeout occurs.
> This timeout value is 59 seconds by default. This timeout value is too long. 
> This timeout value can be changed by specifying the unofficial parameter 
> "gemfire.PoolImpl.HANDSHAKE_TIMEOUT" in java system property, but I 
> corresponded so that it can be specified by official parameters.
> Like the NativeClient, the official parameters should be specified by 
> "connect-timeout" in gemfire.properties.
> Timeout values ​​are determined in the following order of priority.
> 1. java system property:gemfire.PoolImpl.HANDSHAKE_TIMEOUT
> 2. java system property:gemfire.connect-timeout
> 3. gemfire.properties:connect-timeout
> 4. default:59000 milli seconds
> As another idea, there is also an idea to make it possible to specify it as 
> an attribute of Pool. In that case NativeClient needs the same modification.



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

[GitHub] geode issue #474: GEODE-2788: Add official Socket timeout parameter when con...

[bschuchardt]

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/474
  
Masaki, it looks like there are some conflicts that need to be resolved


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

[jira] [Updated] (GEODE-2874) StringIndexOutOfBoundsException while initializing logger

[Jared Stewart (JIRA)]

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

Jared Stewart updated GEODE-2874:
-
Fix Version/s: 1.2.0

> StringIndexOutOfBoundsException while initializing logger
> -
>
> Key: GEODE-2874
> URL: https://issues.apache.org/jira/browse/GEODE-2874
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
> index out of range: -1
>   at java.lang.String.substring(String.java:1967)
>   at 
> org.apache.geode.internal.io.MainWithChildrenRollingFileHandler.calcNextChildId(MainWithChildrenRollingFileHandler.java:47)
>   at 
> org.apache.geode.internal.logging.ManagerLogWriter.getLogNameForOldMainLog(ManagerLogWriter.java:330)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.createLogWriterAppender(LogWriterAppenders.java:144)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:72)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:88)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:591)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:304)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:207)
>   at GeodeClient.GeodeClient(GeodeClient.java:22)
>   at GeodeClient.main(GeodeClient.java:10)



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

[jira] [Resolved] (GEODE-2874) StringIndexOutOfBoundsException while initializing logger

[Jared Stewart (JIRA)]

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

Jared Stewart resolved GEODE-2874.
--
Resolution: Fixed

> StringIndexOutOfBoundsException while initializing logger
> -
>
> Key: GEODE-2874
> URL: https://issues.apache.org/jira/browse/GEODE-2874
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
> index out of range: -1
>   at java.lang.String.substring(String.java:1967)
>   at 
> org.apache.geode.internal.io.MainWithChildrenRollingFileHandler.calcNextChildId(MainWithChildrenRollingFileHandler.java:47)
>   at 
> org.apache.geode.internal.logging.ManagerLogWriter.getLogNameForOldMainLog(ManagerLogWriter.java:330)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.createLogWriterAppender(LogWriterAppenders.java:144)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:72)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:88)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:591)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:304)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:207)
>   at GeodeClient.GeodeClient(GeodeClient.java:22)
>   at GeodeClient.main(GeodeClient.java:10)



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

[jira] [Commented] (GEODE-2874) StringIndexOutOfBoundsException while initializing logger

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2874:


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

GEODE-2874: Fix StringIndexOutOfBoundsException while initializing logger


> StringIndexOutOfBoundsException while initializing logger
> -
>
> Key: GEODE-2874
> URL: https://issues.apache.org/jira/browse/GEODE-2874
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>Assignee: Jared Stewart
>
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
> index out of range: -1
>   at java.lang.String.substring(String.java:1967)
>   at 
> org.apache.geode.internal.io.MainWithChildrenRollingFileHandler.calcNextChildId(MainWithChildrenRollingFileHandler.java:47)
>   at 
> org.apache.geode.internal.logging.ManagerLogWriter.getLogNameForOldMainLog(ManagerLogWriter.java:330)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.createLogWriterAppender(LogWriterAppenders.java:144)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:72)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:88)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:591)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:304)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:207)
>   at GeodeClient.GeodeClient(GeodeClient.java:22)
>   at GeodeClient.main(GeodeClient.java:10)



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

[jira] [Commented] (GEODE-2788) Add official Socket timeout parameter when connecting to servers/locators

[ASF GitHub Bot (JIRA)]

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

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

Github user masaki-yamakawa commented on the issue:

https://github.com/apache/geode/pull/474
  
I fixed the test that was failing with precheckin.
As for the modification of XSD, I think that there is no conclusion yet, 
but at the present time, I am dealing with assumption to change cache-1.0.xsd.


> Add official Socket timeout parameter when connecting to servers/locators
> -
>
> Key: GEODE-2788
> URL: https://issues.apache.org/jira/browse/GEODE-2788
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, docs
>Reporter: Masaki Yamakawa
>Priority: Minor
>  Labels: patch
>
> When connecting from the client to the servers/locators, if the 
> servers/locators is not started, the connection can not be established and a 
> Socket timeout occurs.
> This timeout value is 59 seconds by default. This timeout value is too long. 
> This timeout value can be changed by specifying the unofficial parameter 
> "gemfire.PoolImpl.HANDSHAKE_TIMEOUT" in java system property, but I 
> corresponded so that it can be specified by official parameters.
> Like the NativeClient, the official parameters should be specified by 
> "connect-timeout" in gemfire.properties.
> Timeout values ​​are determined in the following order of priority.
> 1. java system property:gemfire.PoolImpl.HANDSHAKE_TIMEOUT
> 2. java system property:gemfire.connect-timeout
> 3. gemfire.properties:connect-timeout
> 4. default:59000 milli seconds
> As another idea, there is also an idea to make it possible to specify it as 
> an attribute of Pool. In that case NativeClient needs the same modification.



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

[GitHub] geode issue #474: GEODE-2788: Add official Socket timeout parameter when con...

[masaki-yamakawa]

Github user masaki-yamakawa commented on the issue:

https://github.com/apache/geode/pull/474
  
I fixed the test that was failing with precheckin.
As for the modification of XSD, I think that there is no conclusion yet, 
but at the present time, I am dealing with assumption to change cache-1.0.xsd.


---
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-2927) Verify pulse connectivity to locator/jmx manager and logging both in the embedded and un-embedded mode.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2927:


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

GEODE-2927: fix pulse logging and useLocator, SSL flags

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


> Verify pulse connectivity to locator/jmx manager and logging both in the 
> embedded and un-embedded mode.
> ---
>
> Key: GEODE-2927
> URL: https://issues.apache.org/jira/browse/GEODE-2927
> Project: Geode
>  Issue Type: Bug
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>




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