[jira] [Commented] (GEODE-2398) Sporadic Oplog corruption due to channel.write failure

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2398:


Commit aacfa0685d6e8f1043cb485bbd7182a71e444043 in geode's branch 
refs/heads/feature/GEODE-2398 from [~khowe]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=aacfa06 ]

GEODE-2398: Updates from review

https://reviews.apache.org/r/56506/


> Sporadic Oplog corruption due to channel.write failure
> --
>
> Key: GEODE-2398
> URL: https://issues.apache.org/jira/browse/GEODE-2398
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>
> There have been some occurrences of Oplog corruption during testing that have 
> been traced to failures in writing oplog entries to the .crf file. When it 
> fails, Oplog.flush attempts to write a ByteBuffer to the file channel. The 
> call to channel.write(bb) method returns 0 bytes written, but the source 
> ByteBuffer position is moved to the ByteBuffer limit.



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

Re: Propose a new implementation for collections in Geode transaction (GEODE-2392)

[Anthony Baker]

Questions:

1) Do you know why we don’t set detectReadConflicts [1] true by default?  I 
would guess that most users would not expect dirty reads in the context of a 
repeatable read isolation level.
2) In the case of non-local reads on a Partitioned Region, shouldn’t we throw a 
TransactionDataNotColocatedException?
3) Some cache operations throw an UnsupportedOperationInTransactionException.  
Is there a reason we don’t for containsValue()?


Anthony

[1] 
https://geode.apache.org/docs/guide/developing/transactions/transaction_semantics.html

> On Feb 10, 2017, at 12:23 PM, Anilkumar Gingade  wrote:
> 
> As Eric mentioned, this will address the current inconsistencies in the
> product and will provide consistent behavior with replicated and
> partitioned region.
> 
> Also, if we look into typical database transaction applications, the
> transaction queries doesn't touch/read all the records in the table, mostly
> or always they are targeted queries (with where clause) with small result
> set. In Geode case, without support for any filtering option with
> collection api's, it may have to bring in all the region entries into the
> Tx state, which application may not be looking for...The better solution to
> support this is by making Geode queries transactional; which can provide
> repeatable read semantic on sub-set data.
> 
> I agree, its hard for application to distinguish what apis are part of Tx
> and what is not...Option to address this could be, proper documentation or
> not allowing collection apis inside the Tx. In needed, application has to
> suspend the Tx, to call them.
> 
> -Anil.
> 
> 
> 
> 
> 
> 
> 
> 
> On Fri, Feb 10, 2017 at 10:57 AM, Eric Shu  wrote:
> 
>> Hi Dan,
>> 
>> Currently query results do not reflect transaction state at all. The new
>> proposal won't change that.
>> 
>> On Fri, Feb 10, 2017 at 10:47 AM, Eric Shu  wrote:
>> 
>>> Please note even in our current transaction implementation, repeatable
>>> read is not supported on collection operation in transaction with
>>> Partitioned Region. Currently, only the local entry set (resides in the
>>> local node) of a PR is copied into the txState, while data on the remote
>>> nodes are not. Another call of the collection operation of the same
>>> transaction could have different results for the data on the remote
>> nodes.
>>> 
>>> In addition, containValue() call currently does not support repeatable
>>> read either. It does not copy all data into txState (replicated or
>>> partitioned regions.)
>>> 
>>> Currently we only support limited repeatable read for collection
>>> operations in transaction (at least for PR).
>>> 
>>> On Fri, Feb 10, 2017 at 8:36 AM, Anthony Baker 
>> wrote:
>>> 
 I tend to agree with Mike.  Removing collection reads from the txn state
 changes the programming model and makes it harder to write a Geode
 application.  We’re leaking internal details into the public behavior.
 
 Is there another way to provide this optimization to the user?  Perhaps
 something like:
 
CacheTransactionManager txMgr = cache.getCacheTransactionManager();
txMgr.begin(READ_COMMITTED);  // just thinking out loud here
 
 Or, we could set a hard cap on the size of txState.  Would that satisfy
 the original goal to ensure that users apply Geode txns correctly?
 
 Anthony
 
> On Feb 10, 2017, at 12:15 AM, Michael Stolz 
>> wrote:
> 
> -1
> 
> I would recommend against breaking repeatable read semantics for
 specific
> cases. If we're going to do something about the memory pressure,
>> great,
 but
> not at the cost of functionality guarantees.
> 
> --
> Mike Stolz
> Principal Engineer - Gemfire Product Manager
> Mobile: 631-835-4771
> 
> On Feb 9, 2017 10:29 PM, "Eric Shu"  wrote:
> 
> All,
> 
> In current Geode transaction implementation, there will be memory
 pressure
> if collection is used in a transaction. (GEODE-2392
> https://issues.apache.org/jira/browse/GEODE-2392).
> 
> Geode transactions provide repeatable read semantics. In order to
 support
> this repeatable read isolation, all read operations copy the current
 value
> in txState.
> 
> The proposed new implementation is to have collection operation in a
> transaction not copying all values into its txState. Instead, it will
>> go
> over to region directly but reflecting the new state of the entries
 changed
> by the previous operations of this transaction.
> 
> Please note that the proposed implementation will not support
>> repeatable
> read for collection operations.
> 
> Any thoughts?
> 
> Regards,
> Eric
 
 
>>> 
>> 

Build failed in Jenkins: Geode-nightly #747

[Apache Jenkins Server]

See 

--
[...truncated 1416 lines...]
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources UP-TO-DATE
:geode-json:testClasses UP-TO-DATE
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json:flakyTest UP-TO-DATE
:geode-json:integrationTest UP-TO-DATE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJava
:geode-junit:processTestResources UP-TO-DATE
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:flakyTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJava
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-test-framework/6.0.0/lucene-test-framework-6.0.0.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-codecs/6.0.0/lucene-codecs-6.0.0.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-test-framework/6.0.0/lucene-test-framework-6.0.0.jar
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-codecs/6.0.0/lucene-codecs-6.0.0.jar
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
:geode-old-client-support:processTestResources UP-TO-DATE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:flakyTest
:geode-old-client-support:integrationTest
:geode-old-versions:javadoc UP-TO-DATE
:geode-old-versions:javadocJar
:geode-old-versions:sourcesJar
:geode-old-versions:signArchives SKIPPED
:geode-old-versions:assemble
:geode-old-versions:compileTestJava UP-TO-DATE
:geode-old-versions:processTestResources UP-TO-DATE
:geode-old-versions:testClasses UP-TO-DATE
:geode-old-versions:checkMissedTests UP-TO-DATE
:geode-old-versions:spotlessJavaCheck
:geode-old-versions:spotlessCheck
:geode-old-versions:test UP-TO-DATE
:geode-old-versions:check
:geode-old-versions:build
:geode-old-versions:distributedTest UP-TO-DATE
:geode-old-versions:flakyTest UP-TO-DATE
:geode-old-versions:integrationTest UP-TO-DATE
:geode-pulse:assemble
:geode-pulse:compileTestJava
Download 
https://repo1.maven.org/maven2/org/seleniumhq/selenium/selenium-api/2.53.1/selenium-api-2.53.1.pom
Download 
https://repo1.maven.org/maven2/org/seleniumhq/selenium/selenium-parent/2.53.1/selenium-parent-2.53.1.pom
Download 
https://repo1.maven.org/maven2/org/seleniumhq/selenium/selenium-remote-driver/2.53.1/selenium-remote-driver-2.53.1.pom
Download 
https://repo1.maven.org/maven2/org/seleniumhq/selenium/selenium-support/2.53.1/selenium-support-2.53.1.pom
Download 
https://repo1.maven.org/maven2/org/springframework/spring-test/4.3.2.RELEASE/spring-test-4.3.2.RELEASE.pom
Download https://repo1.maven.org/maven2/com/tdunning/json/1.7/json-1.7.pom
Download 
https://repo1.maven.org/maven2/org/seleniumhq/selenium/selenium-api/2.53.1/selenium-api-2.53.1.jar
Download 
https://repo1.maven.org/maven2/org/seleniumhq/selenium/selenium-remote-driver/2.53.1/selenium-remote-driver-2.53.1.jar
Download 
https://repo1.maven.org/maven2/org/seleniumhq/selenium/selenium-support/2.53.1/selenium-support-2.53.1.jar
Download 
https://repo1.maven.org/maven2/org/springframework/spring-test/4.3.2.RELEASE/spring-test-4.3.2.RELEASE.jar
Download https://repo1.maven.org/maven2/com/tdunning/json/1.7/json-1.7.jar
Note: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:depreca

GEODE-2460: update dependency versions

[Kirk Lund]

I'm going to be pushing this change this morning:
https://reviews.apache.org/r/56520/

After you pull and/or rebase any feature branches on this, you'll need to
do a clean build and IDE refresh.

GEODE-2460: update dependency versions

Update the following dependency versions defined in
gradle/dependency-versions.properties.

Update major versions (compile test only):

* org.apache.bcel:bcel:6.0

Update minor versions (distributed in release):

* commons-beanutils:1.9.3
* commons-fileupload:1.3.2
* commons-io:2.5
* commons-lang:2.6
* commons-logging:1.2
* commons-modeler:2.0.1
* fastutil:7.0.13
* guava:21.0
* jansi:1.14
* javax.mail-api:1.4.7
* jline:2.14.3
* jopt-simple:5.0.3
* log4j-api:2.7
* log4j-core:2.7
* log4j-jcl:2.7
* log4j-jul:2.7
* log4j-slf4j-impl:2.7
* netty-all:4.1.7.Final
* shiro-core:1.3.2
* slf4j-api:1.7.22

Update minor versions (compile test and main):

* assertj-core:3.6.2
* cglib:cglib:3.2.4
* commons-configuration:1.10
* derby:10.13.1.1
* google-gson:2.8.0
* httpclient:4.5.2
* httpcore:4.4.6
* hsqldb:2.3.4
* javassist:3.21.0-GA
* jedis:2.9.0
* JUnitParams:1.0.6
* mockrunner:1.1.2
* mortbay-jetty-servlet-api:2.5.20110712
* phantomjsdriver:1.3.0
* powermock-core:1.6.6
* powermock-module-junit4:1.6.6
* powermock-api-mockito:1.6.6
* selenium-api:3.0.1
* selenium-remote-driver:3.0.1
* selenium-support:3.0.1
* spymemcached:2.12.2
* system-rules:1.16.1
* tomcat-catalina:7.0.73 (tomcat7)
* tomcat-coyote:7.0.73 (tomcat7)
* tomcat-juli:7.0.73 (tomcat7)
* tomcat-catalina:8.5.9 (tomcat8)
* tomcat-coyote:8.5.9 (tomcat8)
* tomcat-juli:8.5.9 (tomcat8)

Re: Review Request 56520: GEODE-2460: update dependency versions

[Udo Kohlmeyer]

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


Ship it!




Ship It!

- Udo Kohlmeyer


On Feb. 10, 2017, 11:39 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56520/
> ---
> 
> (Updated Feb. 10, 2017, 11:39 p.m.)
> 
> 
> Review request for geode, Anthony Baker, anilkumar gingade, Bruce Schuchardt, 
> Dave Barnes, Darrel Schneider, Hitesh Khamesra, Jacob Barrett, Jens Deppe, 
> Jinmei Liao, Joey McAllister, Jared Stewart, Karen Miller, Kevin Duling, Udo 
> Kohlmeyer, and Dan Smith.
> 
> 
> Bugs: GEODE-2460
> https://issues.apache.org/jira/browse/GEODE-2460
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2460: update dependency versions
> 
> Update several dependencies so that geode develop uses the latest version.
> 
> These changes fully pass precheckin. Please let me know which dependencies 
> should NOT be updated for any reason and I'll retest with a list of 
> dependencies that it's ok to update and file appropriate Jira ticket(s).
> 
> If you see any dependencies changed in the diff that require me to run any 
> tests not in precheckin, please let me know either in review or direct 
> message.
> 
> [EDIT: I just added the following list categories by test vs main]
> 
> Update the following dependency versions defined in
> gradle/dependency-versions.properties.
> 
> Update major versions (compile test only):
> 
> * org.apache.bcel:bcel:6.0
> 
> Update minor versions (distributed in release):
> 
> * commons-beanutils:1.9.3 
> * commons-fileupload:1.3.2 
> * commons-io:2.5 
> * commons-lang:2.6
> * commons-logging:1.2
> * commons-modeler:2.0.1
> * fastutil:7.0.13
> * guava:21.0
> * jansi:1.14
> * javax.mail-api:1.4.7
> * jline:2.14.3
> * jopt-simple:5.0.3
> * log4j-api:2.7
> * log4j-core:2.7
> * log4j-jcl:2.7
> * log4j-jul:2.7
> * log4j-slf4j-impl:2.7
> * netty-all:4.1.7.Final
> * shiro-core:1.3.2
> * slf4j-api:1.7.22
> 
> Update minor versions (compile tests and main):
> 
> * assertj-core:3.6.2
> * cglib:cglib:3.2.4
> * commons-configuration:1.10
> * derby:10.13.1.1
> * google-gson:2.8.0
> * httpclient:4.5.2
> * httpcore:4.4.6
> * hsqldb:2.3.4
> * javassist:3.21.0-GA
> * jedis:2.9.0
> * JUnitParams:1.0.6
> * mockrunner:1.1.2
> * mortbay-jetty-servlet-api:2.5.20110712
> * phantomjsdriver:1.3.0
> * powermock-core:1.6.6
> * powermock-module-junit4:1.6.6
> * powermock-api-mockito:1.6.6
> * selenium-api:3.0.1
> * selenium-remote-driver:3.0.1
> * selenium-support:3.0.1
> * spymemcached:2.12.2
> * system-rules:1.16.1
> * tomcat-catalina:7.0.73 (tomcat7)
> * tomcat-coyote:7.0.73 (tomcat7)
> * tomcat-juli:7.0.73 (tomcat7)
> * tomcat-catalina:8.5.9 (tomcat8)
> * tomcat-coyote:8.5.9 (tomcat8)
> * tomcat-juli:8.5.9 (tomcat8)
> 
> 
> Diffs
> -
> 
>   geode-assembly/src/main/dist/LICENSE 
> 601ba81005a11e4038eff5a19b61771b1ca9e121 
>   geode-docs/managing/logging/configuring_log4j2.html.md.erb 
> 06b5c56a79804596977d531312b63743c7ba0d30 
>   
> geode-site/website/content/docs/guide/10/managing/logging/configuring_log4j2.html
>  b02422b104cfcea14a34522d35fcbe0e391d8db7 
>   gradle/dependency-versions.properties 
> a0b291e55220e303b1608dbe5f3eb4cf3e510e4b 
> 
> Diff: https://reviews.apache.org/r/56520/diff/
> 
> 
> Testing
> ---
> 
> precheckin passed
> uiTest passed
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Geode nightly build failures

[Kirk Lund]

Some tests still seem to fail only on specific build machines (including
UniversalMembershipListenerAdapterDUnitTest after my fixes). Mostly
management dunits, but one Locator dunit failed. We may need to mark some
of these as Flaky but I'll try to fix anything obvious before resorting to
that.

I'm looking at the management tests marked with * below.

1) https://builds.apache.org/job/Geode-nightly/747/

org.apache.geode.distributed.LocatorUDPSecurityDUnitTest.testNonSSLLocatorDiesWhenConnectingToSSLLocator
*org.apache.geode.management.ClientHealthStatsDUnitTest.testClientHealthStats_DurableClient
*org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverNonSSL
*org.apache.geode.management.internal.cli.NetstatDUnitTest.testConnectToJmxManagerOne
*org.apache.geode.management.internal.cli.NetstatDUnitTest.testConnectToJmxManagerTwo
*org.apache.geode.management.internal.cli.NetstatDUnitTest.testConnectToLocator
*org.apache.geode.management.internal.cli.NetstatDUnitTest.classMethod

2) https://builds.apache.org/job/Geode-nightly/746/

ALL TESTS PASSED

3) https://builds.apache.org/job/Geode-nightly/745/

*org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverNonSSL
*org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer

[jira] [Commented] (GEODE-2469) Redis adapter Hash key support

[Gregory Green (JIRA)]

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

Gregory Green commented on GEODE-2469:
--

Please see https://redis.io/topics/data-types

Hashes
Redis Hashes are maps between string fields and string values, so they are the 
perfect data type to represent objects (e.g. A User with a number of fields 
like name, surname, age, and so forth):
@cli
HMSET user:1000 username antirez password P1pp0 age 34
HGETALL user:1000
HSET user:1000 password 12345
HGETALL user:1000
A hash with a few fields (where few means up to one hundred or so) is stored in 
a way that takes very little space, so you can store millions of objects in a 
small Redis instance.
While Hashes are used mainly to represent objects, they are capable of storing 
many elements, so you can use Hashes for many other tasks as well.
Every hash can store up to 232 - 1 field-value pairs (more than 4 billion).
Check the full list of Hash commands for more information, or read the 
introduction to Redis data types.

> Redis adapter Hash key support
> --
>
> Key: GEODE-2469
> URL: https://issues.apache.org/jira/browse/GEODE-2469
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Gregory Green
>
> The Redis adapter does not appear to handle hash keys correctly.
> The following Example: Redis CLI works.
> localhost:11211>  HSET companies name "John Smith"
> Using a  HSET :id  .. produces an error
> Example:
> localhost:11211>  HSET companies:1000 name "John Smith"
> [Server error]
> [fine 2017/02/10 16:04:33.289 EST server1  
> tid=0x6a] Region names may only be alphanumeric and may contain hyphens or 
> underscores: companies: 1000
> java.lang.IllegalArgumentException: Region names may only be alphanumeric and 
> may contain hyphens or underscores: companies: 1000
> at 
> org.apache.geode.internal.cache.LocalRegion.validateRegionName(LocalRegion.java:7618)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3201)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3181)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:3169)
> at org.apache.geode.cache.RegionFactory.create(RegionFactory.java:762)
> at 
> org.apache.geode.management.internal.cli.functions.RegionCreateFunction.createRegion(RegionCreateFunction.java:355)
> at 
> org.apache.geode.management.internal.cli.functions.RegionCreateFunction.execute(RegionCreateFunction.java:90)
> at 
> org.apache.geode.internal.cache.execute.AbstractExecution.executeFunctionLocally(AbstractExecution.java:333)
> at 
> org.apache.geode.internal.cache.execute.AbstractExecution$2.run(AbstractExecution.java:303)
> 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:621)
> at 
> org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1067)
> at java.lang.Thread.run(Thread.java:745)
> //Example Spring Data Redis Object sample
> @Data
> @EqualsAndHashCode()
> @RedisHash(value="companies")
> @NoArgsConstructor
> public class Company
> {
>   private @Id String id;
>
> //Repository
> public interface CompanyRepository extends CrudRepository 
> {
>  
> }
> //When saving using a repository
> repository.save(this.myCompany);
> [Same Server error]
> java.lang.IllegalArgumentException: Region names may only be alphanumeric and 
> may contain hyphens or underscores: 
> companies:f05405c2-86f2-4aaf-bd0c-6fecd483bf28
> at 
> org.apache.geode.internal.cache.LocalRegion.validateRegionName(LocalRegion.java:7618)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3201)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3181)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:3169)
> at org.apache.geode.cache.RegionFactory.create(RegionFactory.java:762)
> at 
> org.apache.geode.management.internal.cli.functions.RegionCreateFunction.createRegion(RegionCreateFunction.java:355)
> at 
> org.apache.geode.management.internal.cli.functions.RegionCreateFunction.execute(RegionCreateFunction.java:90)
> at 
> org.apache.geode.internal.cache.execute.AbstractExecution.executeFunctionLocally(AbstractExecution.java:333)
> at 
> org.apache.geode.internal.cache.execute.Abstra

[jira] [Commented] (GEODE-2460) Update dependency versions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2460:


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

GEODE-2460: update dependency versions

Update the following dependency versions defined in
gradle/dependency-versions.properties.

Update major versions (compile test only):

* org.apache.bcel:bcel:6.0

Update minor versions (distributed in release):

* commons-beanutils:1.9.3
* commons-fileupload:1.3.2
* commons-io:2.5
* commons-lang:2.6
* commons-logging:1.2
* commons-modeler:2.0.1
* fastutil:7.0.13
* guava:21.0
* jansi:1.14
* javax.mail-api:1.4.7
* jline:2.14.3
* jopt-simple:5.0.3
* log4j-api:2.7
* log4j-core:2.7
* log4j-jcl:2.7
* log4j-jul:2.7
* log4j-slf4j-impl:2.7
* netty-all:4.1.7.Final
* shiro-core:1.3.2
* slf4j-api:1.7.22

Update minor versions (compile test and main):

* assertj-core:3.6.2
* cglib:cglib:3.2.4
* commons-configuration:1.10
* derby:10.13.1.1
* google-gson:2.8.0
* httpclient:4.5.2
* httpcore:4.4.6
* hsqldb:2.3.4
* javassist:3.21.0-GA
* jedis:2.9.0
* JUnitParams:1.0.6
* mockrunner:1.1.2
* mortbay-jetty-servlet-api:2.5.20110712
* phantomjsdriver:1.3.0
* powermock-core:1.6.6
* powermock-module-junit4:1.6.6
* powermock-api-mockito:1.6.6
* selenium-api:3.0.1
* selenium-remote-driver:3.0.1
* selenium-support:3.0.1
* spymemcached:2.12.2
* system-rules:1.16.1
* tomcat-catalina:7.0.73 (tomcat7)
* tomcat-coyote:7.0.73 (tomcat7)
* tomcat-juli:7.0.73 (tomcat7)
* tomcat-catalina:8.5.9 (tomcat8)
* tomcat-coyote:8.5.9 (tomcat8)
* tomcat-juli:8.5.9 (tomcat8)


> Update dependency versions
> --
>
> Key: GEODE-2460
> URL: https://issues.apache.org/jira/browse/GEODE-2460
> Project: Geode
>  Issue Type: Wish
>  Components: build, docs
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Here's the first bunch of dependency version updates that passes precheckin 
> without modifying source code:
> Update the following dependency versions defined in
> gradle/dependency-versions.properties.
> Update major versions (test-only):
> * org.apache.bcel:bcel:6.0
> Update minor versions (test and main):
> * commons-beanutils:1.9.3 
> * commons-fileupload:1.3.2 
> * commons-io:2.5 
> * commons-lang:2.6
> * commons-logging:1.2
> * commons-modeler:2.0.1
> * fastutil:7.0.13
> * guava:21.0
> * jansi:1.14
> * javax.mail-api:1.4.7
> * jline:2.14.3
> * jopt-simple:5.0.3
> * log4j-api:2.7
> * log4j-core:2.7
> * log4j-jcl:2.7
> * log4j-jul:2.7
> * log4j-slf4j-impl:2.7
> * netty-all:4.1.7.Final
> * shiro-core:1.3.2
> * slf4j-api:1.7.22
> Update minor versions (test-only):
> * assertj-core:3.6.2
> * cglib:cglib:3.2.4
> * commons-configuration:1.10
> * derby:10.13.1.1
> * google-gson:2.8.0
> * httpclient:4.5.2
> * httpcore:4.4.6
> * hsqldb:2.3.4
> * javassist:3.21.0-GA
> * jedis:2.9.0
> * JUnitParams:1.0.6
> * mockrunner:1.1.2
> * mortbay-jetty-servlet-api:2.5.20110712
> * phantomjsdriver:1.3.0
> * powermock-core:1.6.6
> * powermock-module-junit4:1.6.6
> * powermock-api-mockito:1.6.6
> * selenium-api:3.0.1
> * selenium-remote-driver:3.0.1
> * selenium-support:3.0.1
> * spymemcached:2.12.2
> * system-rules:1.16.1
> * tomcat-catalina:7.0.73 (tomcat7)
> * tomcat-coyote:7.0.73 (tomcat7)
> * tomcat-juli:7.0.73 (tomcat7)
> * tomcat-catalina:8.5.9 (tomcat8)
> * tomcat-coyote:8.5.9 (tomcat8)
> * tomcat-juli:8.5.9 (tomcat8)



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

[GitHub] geode-native issue #6: GEODE-2470: Replace sed dependency with standard C++.

[pivotal-jbarrett]

Github user pivotal-jbarrett commented on the issue:

https://github.com/apache/geode-native/pull/6
  
Why not use regex_replace in C++11 
http://en.cppreference.com/w/cpp/regex/regex_replace?


---
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-2470) Remove Dependency on sed tool

[ASF GitHub Bot (JIRA)]

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

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

Github user pivotal-jbarrett commented on the issue:

https://github.com/apache/geode-native/pull/6
  
Why not use regex_replace in C++11 
http://en.cppreference.com/w/cpp/regex/regex_replace?


> Remove Dependency on sed tool
> -
>
> Key: GEODE-2470
> URL: https://issues.apache.org/jira/browse/GEODE-2470
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Michael Martell
>
> The integration tests currently rely on sed to replace strings inside config 
> xml files. This task replaces that dependency with standard C++ code.



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

Re: Automating docker builds for geode-native

[Mark Bretl]

+1

On Fri, Feb 10, 2017 at 1:14 PM, Michael William Dodge 
wrote:

> I think this would be a good idea as configuring a machine for building
> can be a barrier to entry for people wishing to contribute.
>
> Sarge
>
> > On 10 Feb, 2017, at 12:29, Anthony Baker  wrote:
> >
> > The geode-native build, like most c++ projects, requires a fairly
> specific toolchain.  Now that we have a docker build environment [1], I’d
> like to ask INFRA to automate the creation and publishing of docker images
> for geode-native.  This can be done by integrating GitHub / DockerHub [2].
> Note that the docker image would *only* be for build purposes and would not
> contain source or binaries from geode-native.  By publishing our build
> toolchain in a docker image:
> >
> > 1) it makes contributing easier
> > 2) it makes our travis-ci builds faster (currently at ~30min)
> > 3) it paves the way to create a nightly Jenkins job for geode-native
> >
> > I suggest publishing this image under the apache namespace [3] as
> geode-native-build.  Thoughts?
> >
> > Anthony
> >
> > [1] https://github.com/apache/geode-native/blob/develop/
> docker/Dockerfile
> > [2] https://issues.apache.org/jira/browse/INFRA-11584?jql=
> project%20%3D%20INFRA%20AND%20text%20~%20docker
> > [3] https://hub.docker.com/u/apache/
>
>

Re: Geode nightly build failures

[Jinmei Liao]

I have a fix for JMXMBeanDUnitTest, the code review is sent out.

NetstatDUnitTest fails with OutofMemeoryError, probably the machine does
not have enough memory to run this test?

On Mon, Feb 13, 2017 at 8:40 AM, Kirk Lund  wrote:

> Some tests still seem to fail only on specific build machines (including
> UniversalMembershipListenerAdapterDUnitTest after my fixes). Mostly
> management dunits, but one Locator dunit failed. We may need to mark some
> of these as Flaky but I'll try to fix anything obvious before resorting to
> that.
>
> I'm looking at the management tests marked with * below.
>
> 1) https://builds.apache.org/job/Geode-nightly/747/
>
> org.apache.geode.distributed.LocatorUDPSecurityDUnitTest.
> testNonSSLLocatorDiesWhenConnectingToSSLLocator
> *org.apache.geode.management.ClientHealthStatsDUnitTest.
> testClientHealthStats_DurableClient
> *org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverNonSSL
> *org.apache.geode.management.internal.cli.NetstatDUnitTest.
> testConnectToJmxManagerOne
> *org.apache.geode.management.internal.cli.NetstatDUnitTest.
> testConnectToJmxManagerTwo
> *org.apache.geode.management.internal.cli.NetstatDUnitTest.
> testConnectToLocator
> *org.apache.geode.management.internal.cli.NetstatDUnitTest.classMethod
>
> 2) https://builds.apache.org/job/Geode-nightly/746/
>
> ALL TESTS PASSED
>
> 3) https://builds.apache.org/job/Geode-nightly/745/
>
> *org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverNonSSL
> *org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.
> testSystemClientEventsInServer
>



-- 
Cheers

Jinmei

Re: Review Request 56586: GEODE-1716: refactor JMXMBeanDunitTest

[Kirk Lund]

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


Ship it!




Ship It!

- Kirk Lund


On Feb. 13, 2017, 4:07 a.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56586/
> ---
> 
> (Updated Feb. 13, 2017, 4:07 a.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, Kirk Lund, 
> and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * refactor MBeanServerConnectRule for easier usage.
> * refactor LocatorServerStartupRule to be able to start up locator/server in 
> VM out of sequence
> 
> 
> Diffs
> -
> 
>   geode-core/src/test/java/org/apache/geode/management/JMXMBeanDUnitTest.java 
> 0feb4c25a957eeeb29a34a90227b01257a92a600 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
>  6c1b4962f82918118401799aad74f399a7cd3af8 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/MBeanServerConnectionRule.java
>  d85975fe7e5bff93ce3fd58a2c1f4e529eff57e0 
> 
> Diff: https://reviews.apache.org/r/56586/diff/
> 
> 
> Testing
> ---
> 
> precheckin successful. ..
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: [VOTE] RC2: Apache Geode release - v1.1.0

[Xiaojian Zhou]

+1.

Should be more careful on naming next time.

On Sun, Feb 12, 2017 at 10:50 AM, Anthony Baker  wrote:

> +1 (binding)
>
> Verified:
> - LICENSE + NOTICE
> - rat report
> - hashes and signatures
> - builds from src / tag
> - sample applications run correctly
>
> Anthony
>
> > On Feb 9, 2017, at 12:55 PM, Hitesh Khamesra 
> wrote:
> >
> > All,
> >
> > This is the second release candidate of the first release for Apache
> Geode, version 1.1.0.
> > Thanks to all the community members.
> >
> > It fixes the following issues:
> >https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12318420&version=12338352
> >
> >
> > *** Please download, test and vote by Tuesday, February 14, 0800 hrs US
> Pacific.
> >
> > Note that we are voting upon the source (tag):
> >rel/v1.1.0.RC2
> >https://git-wip-us.apache.org/repos/asf?p=geode.git;a=tag;h=
> refs/tags/rel/v1.1.0.RC2
> >
> > Commit ID: 2286fd064a52173eab8fdcfadfb89a01e81ef728
> >
> > Source and binary files:
> >https://dist.apache.org/repos/dist/dev/geode/1.1.0.RC2/
> >
> > Maven staging repo:
> >https://repository.apache.org/content/repositories/
> orgapachegeode-1016/
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> >https://github.com/apache/geode/blob/release/1.1.0/KEYS
> >
> > pub   4096R/AC6AB8ED 2017-01-18
> >   Key fingerprint = 048F B40F AD7D 9C15 54AD  D447 2CA9 90A2 AC6A
> B8ED
> >
> > Thanks,
> > Hitesh
>
>

Re: Geode nightly build failures

[Kirk Lund]

We've seen some netstat command tests fail with OutOfMemoryError else where
as well. I don't know why forking a netstat command and reading the output
back into the JVM would take up that much memory. It makes me wonder if
there's a memory leak bug in MiscellaneousCommands#netstat.

Does anyone have any idea how forking a netstat command would cause
OutOfMemoryError?

NetstatDUnitTest is executing the gfsh command "netstat --with-lsof=true
--member="?


On Mon, Feb 13, 2017 at 9:16 AM, Jinmei Liao  wrote:

> I have a fix for JMXMBeanDUnitTest, the code review is sent out.
>
> NetstatDUnitTest fails with OutofMemeoryError, probably the machine does
> not have enough memory to run this test?
>
> On Mon, Feb 13, 2017 at 8:40 AM, Kirk Lund  wrote:
>
> > Some tests still seem to fail only on specific build machines (including
> > UniversalMembershipListenerAdapterDUnitTest after my fixes). Mostly
> > management dunits, but one Locator dunit failed. We may need to mark some
> > of these as Flaky but I'll try to fix anything obvious before resorting
> to
> > that.
> >
> > I'm looking at the management tests marked with * below.
> >
> > 1) https://builds.apache.org/job/Geode-nightly/747/
> >
> > org.apache.geode.distributed.LocatorUDPSecurityDUnitTest.
> > testNonSSLLocatorDiesWhenConnectingToSSLLocator
> > *org.apache.geode.management.ClientHealthStatsDUnitTest.
> > testClientHealthStats_DurableClient
> > *org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverNonSSL
> > *org.apache.geode.management.internal.cli.NetstatDUnitTest.
> > testConnectToJmxManagerOne
> > *org.apache.geode.management.internal.cli.NetstatDUnitTest.
> > testConnectToJmxManagerTwo
> > *org.apache.geode.management.internal.cli.NetstatDUnitTest.
> > testConnectToLocator
> > *org.apache.geode.management.internal.cli.NetstatDUnitTest.classMethod
> >
> > 2) https://builds.apache.org/job/Geode-nightly/746/
> >
> > ALL TESTS PASSED
> >
> > 3) https://builds.apache.org/job/Geode-nightly/745/
> >
> > *org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverNonSSL
> > *org.apache.geode.management.UniversalMembershipListenerAda
> pterDUnitTest.
> > testSystemClientEventsInServer
> >
>
>
>
> --
> Cheers
>
> Jinmei
>

Re: Review Request 56506: GEODE-2398: Retry oplog channel.write on silent failures

[Darrel Schneider]

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


Ship it!




Ship It!

- Darrel Schneider


On Feb. 10, 2017, 4 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56506/
> ---
> 
> (Updated Feb. 10, 2017, 4 p.m.)
> 
> 
> Review request for geode, anilkumar gingade and Darrel Schneider.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Implemented limited retries in two forms of Oplog.flush() when 
> channel.write() is called.
> If write() returns bytes witten less than the change in the ByteBuffer 
> positions, then reset
> buffer positions and re-try writing for a limited number of times. Throws
> IOException if the write doesn't succeeded after a few retries (max
> number of retries is defined by a static).
> 
> Added new unit tests.
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/cache/Oplog.java 0b98364 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/OplogFlushTest.java 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/56506/diff/
> 
> 
> Testing
> ---
> 
> Started precheckin
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

[jira] [Commented] (GEODE-2436) Geode doesn't handle byte[] as key

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt commented on GEODE-2436:
-

Why not use the existing ByteArrayWrapper class?

> Geode doesn't handle byte[] as key
> --
>
> Key: GEODE-2436
> URL: https://issues.apache.org/jira/browse/GEODE-2436
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Hitesh Khamesra
>
> Geode doesn't handle byte[] as key. "byte[]" doesn't implement 
> hashcode/equals method, it just returns native hashcode. Because of that 
> following code returns  null for key k2;
> {code}
> Cache c = CacheFactory.getAnyInstance();
>
> Region region = c.getRegion("primitiveKVStore");
>byte[] k1 = new byte[] {1,2};
>
> region.put(k1, k1);
> byte[] k2 = new byte[] {1,2};
> System.out.println(">> "  + region.get(k2));
> {code}



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

Re: Review Request 56564: GEODE-2449: Moved Redis out of Geode-core into its own module

[Udo Kohlmeyer]

> On Feb. 11, 2017, 1 a.m., Dan Smith wrote:
> > geode-core/src/main/java/org/apache/geode/internal/hll/Bits.java, line 14
> > 
> >
> > Technically, the hyperloglog stuff wasn't introduced for redis. But 
> > maybe it's the only component using this stuff now?

in that case we will move it back into core


- Udo


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


On Feb. 10, 2017, 11:22 p.m., Udo Kohlmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56564/
> ---
> 
> (Updated Feb. 10, 2017, 11:22 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Galen O'Sullivan, Hitesh 
> Khamesra, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Moved Geode-Redis out of core. No other changes other than code move and some 
> test clean up.
> Added GeodeRedisService Interface to be used for the ServiceLoader code in 
> GemFireCacheImpl
> 
> 
> Diffs
> -
> 
>   geode-core/build.gradle 8eba6d4e8 
>   
> geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java
>  63f650510 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfigImpl.java
>  fa6d13f7c 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  6e374ecb7 
>   geode-core/src/main/java/org/apache/geode/internal/hll/Bits.java 595fb57ac 
>   
> geode-core/src/main/java/org/apache/geode/internal/hll/CardinalityMergeException.java
>  59ab0950e 
>   geode-core/src/main/java/org/apache/geode/internal/hll/HyperLogLog.java 
> 4bdf81c77 
>   geode-core/src/main/java/org/apache/geode/internal/hll/HyperLogLogPlus.java 
> fc4b6e554 
>   geode-core/src/main/java/org/apache/geode/internal/hll/IBuilder.java 
> 10189c8bc 
>   geode-core/src/main/java/org/apache/geode/internal/hll/ICardinality.java 
> 125b62183 
>   geode-core/src/main/java/org/apache/geode/internal/hll/MurmurHash.java 
> be19e29ae 
>   geode-core/src/main/java/org/apache/geode/internal/hll/RegisterSet.java 
> cad691b25 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/domain/FixedPartitionAttributesInfo.java
>  eb0435a37 
>   geode-core/src/main/java/org/apache/geode/redis/GeodeRedisServer.java 
> 4c97c98bf 
>   geode-core/src/main/java/org/apache/geode/redis/GeodeRedisService.java 
> PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/redis/internal/ByteArrayWrapper.java
>  4a0ef5989 
>   
> geode-core/src/main/java/org/apache/geode/redis/internal/ByteToCommandDecoder.java
>  124bf7512 
>   geode-core/src/main/java/org/apache/geode/redis/internal/Coder.java  
>   geode-core/src/main/java/org/apache/geode/redis/internal/Command.java  
>   geode-core/src/main/java/org/apache/geode/redis/internal/DoubleWrapper.java 
> 60cd130da 
>   
> geode-core/src/main/java/org/apache/geode/redis/internal/ExecutionHandlerContext.java
>  e2b49bedc 
>   geode-core/src/main/java/org/apache/geode/redis/internal/Executor.java  
>   geode-core/src/main/java/org/apache/geode/redis/internal/Extendable.java  
>   
> geode-core/src/main/java/org/apache/geode/redis/internal/RedisCommandParserException.java
>   
>   
> geode-core/src/main/java/org/apache/geode/redis/internal/RedisCommandType.java
>   
>   
> geode-core/src/main/java/org/apache/geode/redis/internal/RedisConstants.java 
> 3c39c01c5 
>   geode-core/src/main/java/org/apache/geode/redis/internal/RedisDataType.java 
> 63a15dff9 
>   
> geode-core/src/main/java/org/apache/geode/redis/internal/RedisDataTypeMismatchException.java
>   
>   
> geode-core/src/main/java/org/apache/geode/redis/internal/RegionCreationException.java
>   
>   
> geode-core/src/main/java/org/apache/geode/redis/internal/RegionProvider.java 
> 5994d7d8c 
>   
> geode-core/src/main/java/org/apache/geode/redis/internal/executor/AbstractExecutor.java
>  c9d47ab9b 
>   
> geode-core/src/main/java/org/apache/geode/redis/internal/executor/AbstractScanExecutor.java
>  0eb6dcad3 
>   
> geode-core/src/main/java/org/apache/geode/redis/internal/executor/AuthExecutor.java
>  9d318a450 
>   
> geode-core/src/main/java/org/apache/geode/redis/internal/executor/DBSizeExecutor.java
>   
>   
> geode-core/src/main/java/org/apache/geode/redis/internal/executor/DelExecutor.java
>  e0db6518c 
>   
> geode-core/src/main/java/org/apache/geode/redis/internal/executor/EchoExecutor.java
>  407e65354 
>   
> geode-core/src/main/java/org/apache/geode/redis/internal/executor/ExistsExecutor.java
>  96611dc06 
>   
> geode-core/src/main/java/org/apache/geode/redis/internal/executor/ExpirationExecutor.java
>   
>   
> geode-core/src/main/java/org/a

[jira] [Updated] (GEODE-2471) AsyncEventListenerOffHeapDUnitTest.testParallelAsyncEventQueueMoveBucketAndMoveItBackDuringDispatching

[Dan Smith (JIRA)]

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

Dan Smith updated GEODE-2471:
-
Component/s: (was: core)
 wan

> AsyncEventListenerOffHeapDUnitTest.testParallelAsyncEventQueueMoveBucketAndMoveItBackDuringDispatching
> --
>
> Key: GEODE-2471
> URL: https://issues.apache.org/jira/browse/GEODE-2471
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: xiaojian zhou
>  Labels: CI
>
> {noformat}
> found in concourse distributedTest #383
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertTrue(Assert.java:52)
>   at 
> org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventListenerDUnitTest.testParallelAsyncEventQueueMoveBucketAndMoveItBackDuringDispatching(AsyncEventListenerDUnitTest.java:1675)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.remote.internal.hub.Mes

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

[Kenneth Howe (JIRA)]

Kenneth Howe created GEODE-2472:
---

 Summary: Oplog.flush method doesn't verify that the entry gets 
written
 Key: GEODE-2472
 URL: https://issues.apache.org/jira/browse/GEODE-2472
 Project: Geode
  Issue Type: Improvement
  Components: persistence
Reporter: Kenneth Howe


The Oplog.flush(OplogFile olf, ByteBuffer b1, ByteBuffer b2) method doesn't 
check the results of the channel.write() call. The other Oplog.flush() method 
that performs a channel write wraps the write() call in the loop

{code}
do {
...
} while (hasRemaining);
{code}

to make sure the Oplog entry is wirtten to the OplogFile.

This method is implemented without the check loop, making the assumption that 
the write() completely writes everything from both buffers. Defensive 
programming would suggest that the results of lower level calls are checked.

Failure to recognize a partial write to the OplogFile can result in a corrupt 
oplog that isn't found until the persisten diosk store is recovered.




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

Re: Geode nightly build failures

[Kirk Lund]

Looking at
https://builds.apache.org/job/Geode-nightly/747/testReport/org.apache.geode.management.internal.cli/NetstatDUnitTest/classMethod/

...it looks like NetstatFunction.executeLsof keeps executing infinitely
once it gets triggered.

I tried to run "netstat --with-lsof=true" on my Mac, but apparently
NetstatFunction identifies my Mac as Windows and doesn't attempt to use
lsof. I'll file a bug for this.

I'll try to figure out why NetstatFunction seems to keep executing in a
loop and file a bug for that as well.


On Mon, Feb 13, 2017 at 9:31 AM, Kirk Lund  wrote:

> We've seen some netstat command tests fail with OutOfMemoryError else
> where as well. I don't know why forking a netstat command and reading the
> output back into the JVM would take up that much memory. It makes me wonder
> if there's a memory leak bug in MiscellaneousCommands#netstat.
>
> Does anyone have any idea how forking a netstat command would cause
> OutOfMemoryError?
>
> NetstatDUnitTest is executing the gfsh command "netstat --with-lsof=true
> --member="?
>
>
> On Mon, Feb 13, 2017 at 9:16 AM, Jinmei Liao  wrote:
>
>> I have a fix for JMXMBeanDUnitTest, the code review is sent out.
>>
>> NetstatDUnitTest fails with OutofMemeoryError, probably the machine does
>> not have enough memory to run this test?
>>
>> On Mon, Feb 13, 2017 at 8:40 AM, Kirk Lund  wrote:
>>
>> > Some tests still seem to fail only on specific build machines (including
>> > UniversalMembershipListenerAdapterDUnitTest after my fixes). Mostly
>> > management dunits, but one Locator dunit failed. We may need to mark
>> some
>> > of these as Flaky but I'll try to fix anything obvious before resorting
>> to
>> > that.
>> >
>> > I'm looking at the management tests marked with * below.
>> >
>> > 1) https://builds.apache.org/job/Geode-nightly/747/
>> >
>> > org.apache.geode.distributed.LocatorUDPSecurityDUnitTest.
>> > testNonSSLLocatorDiesWhenConnectingToSSLLocator
>> > *org.apache.geode.management.ClientHealthStatsDUnitTest.
>> > testClientHealthStats_DurableClient
>> > *org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverNonSSL
>> > *org.apache.geode.management.internal.cli.NetstatDUnitTest.
>> > testConnectToJmxManagerOne
>> > *org.apache.geode.management.internal.cli.NetstatDUnitTest.
>> > testConnectToJmxManagerTwo
>> > *org.apache.geode.management.internal.cli.NetstatDUnitTest.
>> > testConnectToLocator
>> > *org.apache.geode.management.internal.cli.NetstatDUnitTest.classMethod
>> >
>> > 2) https://builds.apache.org/job/Geode-nightly/746/
>> >
>> > ALL TESTS PASSED
>> >
>> > 3) https://builds.apache.org/job/Geode-nightly/745/
>> >
>> > *org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverNonSSL
>> > *org.apache.geode.management.UniversalMembershipListenerAdap
>> terDUnitTest.
>> > testSystemClientEventsInServer
>> >
>>
>>
>>
>> --
>> Cheers
>>
>> Jinmei
>>
>
>

[jira] [Commented] (GEODE-2471) AsyncEventListenerOffHeapDUnitTest.testParallelAsyncEventQueueMoveBucketAndMoveItBackDuringDispatching

[Darrel Schneider (JIRA)]

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

Darrel Schneider commented on GEODE-2471:
-

It looks like this failure is caused by the AsyncEventListener the test sets up 
not having its processEvent method called (which would have caused it to set 
moved to true).
I see line 1675 as this: assertTrue(getBucketMoved(vm2, "ln"));
and getBucketMoved just tests the moved flag on the test's AsyncEventListener 
impl.

> AsyncEventListenerOffHeapDUnitTest.testParallelAsyncEventQueueMoveBucketAndMoveItBackDuringDispatching
> --
>
> Key: GEODE-2471
> URL: https://issues.apache.org/jira/browse/GEODE-2471
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: xiaojian zhou
>  Labels: CI
>
> {noformat}
> found in concourse distributedTest #383
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertTrue(Assert.java:52)
>   at 
> org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventListenerDUnitTest.testParallelAsyncEventQueueMoveBucketAndMoveItBackDuringDispatching(AsyncEventListenerDUnitTest.java:1675)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingM

Re: C++ client change history

[Michael William Dodge]

I'm not sure exactly what happened as my git fu isn't that great but could it 
be as part of commit 4fa64db926f51d4b12d6e4040c703cc69a9832fe? In that commit I 
see a block under case TcrMessage::PING: being removed so that execution falls 
through to default: but I'm unsure that I've pieced the output from git diff 
together properly so that may not be a change that happened in 
TcrMessage::handleByteArrayResponse.

Sarge

> On 12 Feb, 2017, at 09:25, Avital Amity  wrote:
> 
> Hi,
> 
> I'm trying to track the history of TcrMessage.cpp but I can find it only in 
> the new client release where it moved under cppcache/src
> In particular I'm searching for the change where in function 
> TcrMessage::handleByteArrayResponse
> Where the case of PING message was merged with the case of the default message
> 
> Thanks
> Avital
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
> 
> you may review at http://www.amdocs.com/email_disclaimer.asp

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

[Kenneth Howe (JIRA)]

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

Kenneth Howe updated GEODE-2472:

Description: 
The Oplog.flush(OplogFile olf, ByteBuffer b1, ByteBuffer b2) method doesn't 
check the results of the channel.write() call. The other Oplog.flush() method 
that performs a channel write wraps the write() call in the loop

{code}
do {
...
} while (hasRemaining);
{code}

to make sure the Oplog entry is written to the OplogFile.

This method is implemented without the check loop, making the assumption that 
the write() completely writes everything from both buffers. Defensive 
programming would suggest that the results of lower level calls are checked.

Failure to recognize a partial write to the OplogFile can result in a corrupt 
oplog that isn't found until the persistent disk store is recovered.


  was:
The Oplog.flush(OplogFile olf, ByteBuffer b1, ByteBuffer b2) method doesn't 
check the results of the channel.write() call. The other Oplog.flush() method 
that performs a channel write wraps the write() call in the loop

{code}
do {
...
} while (hasRemaining);
{code}

to make sure the Oplog entry is wirtten to the OplogFile.

This method is implemented without the check loop, making the assumption that 
the write() completely writes everything from both buffers. Defensive 
programming would suggest that the results of lower level calls are checked.

Failure to recognize a partial write to the OplogFile can result in a corrupt 
oplog that isn't found until the persisten diosk store is recovered.



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



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

[jira] [Commented] (GEODE-2375) GemFireException should not inherit from RuntimeException

[Darrel Schneider (JIRA)]

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

Darrel Schneider commented on GEODE-2375:
-

Something that might work, and not break old code, is to introduce a new 
abstract subclass of GemFireException called GeodeRuntimeException. We would 
deprecate GemFireException saying to instead use GeodeRuntimeException. Any of 
our current instances of GemFireException would be changed to instead subclass 
GeodeRuntimeException. Old code that catches GemFireException or does 
instanceof checks would continue to work. We would need to confirm that if we 
java serialize an instance of one of the exception that used to subclass 
GemFireException but now subclass GeodeRuntimeException would still deserialize 
in an old client that does not have GeodeRuntimeException on its classpath.

We would do all of the above with GemFireCheckedException except its new 
abstract subclass would be GeodeException.


> GemFireException should not inherit from RuntimeException
> -
>
> Key: GEODE-2375
> URL: https://issues.apache.org/jira/browse/GEODE-2375
> Project: Geode
>  Issue Type: Bug
>  Components: core, general
>Reporter: Galen O'Sullivan
>
> {{GemFireException}} inherits from {{RuntimeException}}, which means that the 
> majority of exceptions in Geode are unchecked. This means that we don't have 
> the type system helping us to check potential failure conditions of our code, 
> and it's not clear which functions may throw exceptions as a part of their 
> nomal failure modes -- for example, {{ReplyException}} has a 
> {{handleAsUnexpected}} method that seems to indicate that a normal 
> {{ReplyException}} is not unexpected -- but that's not what the type 
> inheritance says. {{GemFireException}} accounts for most of the exceptions in 
> the codebase.
> Even if we were to convert most of the existing instances of 
> {{GemFireException}} to {{GemFireRuntimeException}}, developers (especially 
> new ones) would still be tempted to use {{GemFireException}} for new 
> exceptions.
> Perhaps the best way to solve this (if we want all our exceptions to inherit 
> from a central exception type, which I'm not entirely sold on) would be to 
> create a new {{GeodeUncheckedException}} and {{GeodeCheckedException}}, and 
> deprecate both kinds of {{GemFireException}}? Then we could convert old 
> exceptions as time permits.
> There's a significant amount of work involved here whatever way we decide to 
> change it.



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

Re: [VOTE] RC2: Apache Geode release - v1.1.0

[Dan Smith]

+1 (binding)

IMO I think we don't have to hold up this release for the incubating
references in BUILDING, docker, etc. as long as we can make the docs on the
website correct. Is someone working on cleaning up the incubating
references on develop?

Verified:
 - signatures of artifacts
 - download and basic CRUD test of geode-core from the maven site
 - source build works
 - basic gfsh CRUD test


-Dan

On Sun, Feb 12, 2017 at 10:50 AM, Anthony Baker  wrote:

> +1 (binding)
>
> Verified:
> - LICENSE + NOTICE
> - rat report
> - hashes and signatures
> - builds from src / tag
> - sample applications run correctly
>
> Anthony
>
> > On Feb 9, 2017, at 12:55 PM, Hitesh Khamesra 
> wrote:
> >
> > All,
> >
> > This is the second release candidate of the first release for Apache
> Geode, version 1.1.0.
> > Thanks to all the community members.
> >
> > It fixes the following issues:
> >https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12318420&version=12338352
> >
> >
> > *** Please download, test and vote by Tuesday, February 14, 0800 hrs US
> Pacific.
> >
> > Note that we are voting upon the source (tag):
> >rel/v1.1.0.RC2
> >https://git-wip-us.apache.org/repos/asf?p=geode.git;a=tag;h=
> refs/tags/rel/v1.1.0.RC2
> >
> > Commit ID: 2286fd064a52173eab8fdcfadfb89a01e81ef728
> >
> > Source and binary files:
> >https://dist.apache.org/repos/dist/dev/geode/1.1.0.RC2/
> >
> > Maven staging repo:
> >https://repository.apache.org/content/repositories/
> orgapachegeode-1016/
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> >https://github.com/apache/geode/blob/release/1.1.0/KEYS
> >
> > pub   4096R/AC6AB8ED 2017-01-18
> >   Key fingerprint = 048F B40F AD7D 9C15 54AD  D447 2CA9 90A2 AC6A
> B8ED
> >
> > Thanks,
> > Hitesh
>
>

[jira] [Assigned] (GEODE-2376) Remove stack dump comment from ThinClientPoolDM.cpp

[Michael Dodge (JIRA)]

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

Michael Dodge reassigned GEODE-2376:


Assignee: Michael Dodge

> Remove stack dump comment from ThinClientPoolDM.cpp
> ---
>
> Key: GEODE-2376
> URL: https://issues.apache.org/jira/browse/GEODE-2376
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Michael Dodge
>Priority: Minor
>
> For some strange reason there is a stack dump embedded in the source. There 
> is no comment on the relevance to the section of code.
> See around line 506.



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

Re: C++ client change history

[Jacob Barrett]

The change happened in a commercial release between grants. The ping case
had a deprecated long read that was not compatible with the server Geode
1.0. After removing the read the code path was merged with the default as
there was no diff.

On Mon, Feb 13, 2017 at 10:06 AM Michael William Dodge 
wrote:

> I'm not sure exactly what happened as my git fu isn't that great but could
> it be as part of commit 4fa64db926f51d4b12d6e4040c703cc69a9832fe? In that
> commit I see a block under case TcrMessage::PING: being removed so that
> execution falls through to default: but I'm unsure that I've pieced the
> output from git diff together properly so that may not be a change that
> happened in TcrMessage::handleByteArrayResponse.
>
> Sarge
>
> > On 12 Feb, 2017, at 09:25, Avital Amity  wrote:
> >
> > Hi,
> >
> > I'm trying to track the history of TcrMessage.cpp but I can find it only
> in the new client release where it moved under cppcache/src
> > In particular I'm searching for the change where in function
> TcrMessage::handleByteArrayResponse
> > Where the case of PING message was merged with the case of the default
> message
> >
> > Thanks
> > Avital
> > This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> >
> > you may review at http://www.amdocs.com/email_disclaimer.asp
>
>

Re: Review Request 56586: GEODE-1716: refactor JMXMBeanDunitTest

[Kevin Duling]

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


Ship it!




Ship It!

- Kevin Duling


On Feb. 12, 2017, 8:07 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56586/
> ---
> 
> (Updated Feb. 12, 2017, 8:07 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, Kirk Lund, 
> and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * refactor MBeanServerConnectRule for easier usage.
> * refactor LocatorServerStartupRule to be able to start up locator/server in 
> VM out of sequence
> 
> 
> Diffs
> -
> 
>   geode-core/src/test/java/org/apache/geode/management/JMXMBeanDUnitTest.java 
> 0feb4c25a957eeeb29a34a90227b01257a92a600 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
>  6c1b4962f82918118401799aad74f399a7cd3af8 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/MBeanServerConnectionRule.java
>  d85975fe7e5bff93ce3fd58a2c1f4e529eff57e0 
> 
> Diff: https://reviews.apache.org/r/56586/diff/
> 
> 
> Testing
> ---
> 
> precheckin successful. ..
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

[jira] [Commented] (GEODE-2416) Collect together artifacts from individual servers into a single zip file

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2416:


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

GEODE-2416: Collect together artifacts from individual servers into a single 
zip file

 - GEODE-2414: Determine a mechanism to stream a zip file from server to locator
 - GEODE-2415: Write a function to return a zip file for a single server


> Collect together artifacts from individual servers into a single zip file
> -
>
> Key: GEODE-2416
> URL: https://issues.apache.org/jira/browse/GEODE-2416
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> We need a locator to unzip the individual zip files produced by GEODE-2415 
> and re-zip them together into a single zip file (with a directory for each 
> member, containing the artifacts from that member).



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

[jira] [Commented] (GEODE-2415) Write a function to return a zip file for a single server

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2415:


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

GEODE-2416: Collect together artifacts from individual servers into a single 
zip file

 - GEODE-2414: Determine a mechanism to stream a zip file from server to locator
 - GEODE-2415: Write a function to return a zip file for a single server


> Write a function to return a zip file for a single server
> -
>
> Key: GEODE-2415
> URL: https://issues.apache.org/jira/browse/GEODE-2415
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> We need to write a function to be executed on each server that will find the 
> desired artifacts (logs, stat files, stack traces) on that server given the 
> parameters of the export command (date limiting, --exclude-stats, etc) and 
> return that zip file to the calling locator using the mechanism determined by 
> GEODE-2414.



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

[jira] [Commented] (GEODE-2414) Determine a mechanism to stream a zip file from server to locator

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2414:


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

GEODE-2416: Collect together artifacts from individual servers into a single 
zip file

 - GEODE-2414: Determine a mechanism to stream a zip file from server to locator
 - GEODE-2415: Write a function to return a zip file for a single server


> Determine a mechanism to stream a zip file from server to locator
> -
>
> Key: GEODE-2414
> URL: https://issues.apache.org/jira/browse/GEODE-2414
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> Our export command will execute a function on servers (one at a time) to 
> build up a zip file of the artifacts for that server.  Then, the zip file 
> needs to be sent back to the locator, so that the locator can aggregate 
> together the files from all servers.  However, we need to make sure to 
> chunk/stream the data that we send from server to locator so that neither 
> member will run out of memory if the file is very large.



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

[jira] [Created] (GEODE-2473) redis-cli hangs if Geode unable to process command properly

[Hitesh Khamesra (JIRA)]

Hitesh Khamesra created GEODE-2473:
--

 Summary: redis-cli hangs if Geode unable to process command 
properly
 Key: GEODE-2473
 URL: https://issues.apache.org/jira/browse/GEODE-2473
 Project: Geode
  Issue Type: Bug
  Components: redis
Reporter: Hitesh Khamesra


Here is the command  "HSET companies:1000 name "John Smith""

"GeodeRedisServer-WorkerThread-1" #86 prio=5 os_prio=0 tid=0x7f1a20002800 
nid=0x4750 sleeping[0x7f1bf0dd9000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at 
org.apache.geode.management.internal.cli.commands.CreateAlterDestroyRegionCommands.verifyDistributedRegionMbean(CreateAlterDestroyRegionCommands.java:410)
at 
org.apache.geode.management.internal.cli.commands.CreateAlterDestroyRegionCommands.createRegion(CreateAlterDestroyRegionCommands.java:371)
at 
org.apache.geode.redis.internal.RegionProvider.createRegionGlobally(RegionProvider.java:405)
at 
org.apache.geode.redis.internal.RegionProvider.getOrCreateRegion0(RegionProvider.java:292)
at 
org.apache.geode.redis.internal.RegionProvider.getOrCreateRegion(RegionProvider.java:212)
at 
org.apache.geode.redis.internal.executor.hash.HashExecutor.getOrCreateRegion(HashExecutor.java:31)
at 
org.apache.geode.redis.internal.executor.hash.HSetExecutor.executeCommand(HSetExecutor.java:48)
at 
org.apache.geode.redis.internal.ExecutionHandlerContext.executeWithoutTransaction(ExecutionHandlerContext.java:235)
at 
org.apache.geode.redis.internal.ExecutionHandlerContext.executeCommand(ExecutionHandlerContext.java:199)
at 
org.apache.geode.redis.internal.ExecutionHandlerContext.channelRead(ExecutionHandlerContext.java:139)
at 
io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
at 
io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
at 
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:173)
at 
io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
at 
io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
at 
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:780)
at 
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:100)
at 
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:497)
at 
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:465)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:359)
at 
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101)
at java.lang.Thread.run(Thread.java:745)




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

[jira] [Commented] (GEODE-1716) Non-ssl RMI server seems not to be cleaning up after itself. Causing the rest of the tests to fail.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1716:


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

GEODE-1716: refactor JMXMBeanDunitTest

* refactor MBeanServerConnectRule for easier usage.
* refactor LocatorServerStartupRule to be able to start up locator/server in VM 
out of sequence


> Non-ssl RMI server seems not to be cleaning up after itself. Causing the rest 
> of the tests to fail.
> ---
>
> Key: GEODE-1716
> URL: https://issues.apache.org/jira/browse/GEODE-1716
> Project: Geode
>  Issue Type: Bug
>  Components: jmx
>Reporter: Udo Kohlmeyer
>Priority: Minor
>
> In JMXMBeanDUnitTest the testJMXOverNonSSL test is causing the whole test 
> class to fail. It seems the RMI stuff does not clean up nicely after itself.



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

[jira] [Commented] (GEODE-2439) Replace all non-standard types in all public includes / API

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett commented on GEODE-2439:
-

GEODE-2408 resolves the WinSock2.h and timeval issues.

> Replace all non-standard types in all public includes / API
> ---
>
> Key: GEODE-2439
> URL: https://issues.apache.org/jira/browse/GEODE-2439
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ernest Burghardt
>
> research other non-standard types in API, ACE_Time



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

[GitHub] geode-native pull request #3: Replace ace calls to standard functions

[pivotal-jbarrett]

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

https://github.com/apache/geode-native/pull/3#discussion_r100877742
  
--- Diff: src/cppcache/src/CacheXmlParser.cpp ---
@@ -1165,7 +1166,7 @@ void CacheXmlParser::startPersistenceManager(const 
xmlChar** atts) {
 throw CacheXmlException(s.c_str());
   }
 
-  ACE_OS::strncpy(libraryFunctionName, (char*)atts[i], len);
+  std::strncpy(libraryFunctionName, (char*)atts[i], len);
--- End diff --

Maybe not is a great opportunity to fix these c-style casts that are 
warnings in C++11 now when you are fixing other things in the file.


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

[GitHub] geode-native pull request #3: Replace ace calls to standard functions

[pivotal-jbarrett]

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

https://github.com/apache/geode-native/pull/3#discussion_r100878314
  
--- Diff: src/cppcache/src/TcrMessage.hpp ---
@@ -1170,7 +1170,7 @@ class TcrMessageHelper {
 }
 if (compId != expectedPartType) {
   char exMsg[256];
-  ACE_OS::snprintf(exMsg, 255,
+  std::snprintf(exMsg, 255,
--- End diff --

This change violates the C++ formatting we adhere to. Please reformat each 
changed line or file after global search and replace.


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

[GitHub] geode-native pull request #3: Replace ace calls to standard functions

[pivotal-jbarrett]

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

https://github.com/apache/geode-native/pull/3#discussion_r100878727
  
--- Diff: src/cppcache/src/TcrMessage.hpp ---
@@ -1170,7 +1170,7 @@ class TcrMessageHelper {
 }
 if (compId != expectedPartType) {
   char exMsg[256];
-  ACE_OS::snprintf(exMsg, 255,
+  std::snprintf(exMsg, 255,
--- End diff --

Technically its the lines following this change that violate the formatting.


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

New Committer And PMC Member: Jared Stewart

[Mark Bretl]

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

Please join me in welcoming Jared!

Best Regards,

Mark Bretl
On behalf of the Apache Geode PMC

Re: Regarding region.putAll()

[Goutam Tadi]

+Jacob Barrett 

We are planning to replace the region.put() to one of the putAll()
implementations provided by GemFire.
We have found two ways of doing it.

((LocalRegion) region).basicImportPutAll(map)

and

region.putAll(map)

where regionis a PartitionedRegion ?

Anthony gave us some info and also suggested to discuss with you as well.

1) What would be the potential issues we might face using one of them over
the other ?
2) Which of them works like region.put() ?

Thanks,
Goutam Tadi

On Tue, Feb 7, 2017 at 8:54 PM Anthony Baker  wrote:

> LocalRegion.basicImportPutAll() is an internal method used by `gfsh import
> data`.  One important difference is that it will skip firing callbacks and
> distributing updates over WAN connections.
>
> Anthony
>
>
> > On Feb 7, 2017, at 5:43 PM, Goutam Tadi  wrote:
> >
> > Hi Team,
> >
> > What is the difference between
> >
> > ((LocalRegion) region).basicImportPutAll(map)
> >
> > ​
> > and
> >
> > region.putAll(map)
> >
> > ​
> > where regionis a PartitionedRegion ?
> >
> >
> > Thanks,
> > Goutam and Bradford.
> > --
> > Regards,
> > *Goutam Tadi.*
>
> --
Regards,
*Goutam Tadi.*

Re: New Committer And PMC Member: Jared Stewart

[Joey McAllister]

Nice! Congratulations, Jared!

On Mon, Feb 13, 2017 at 11:59 AM Mark Bretl  wrote:

> The Apache Geode Project Management Committee has invited Jared Stewart to
> be a committer on the project and join the Geode PMC. We are pleased to
> announce he has accepted the invitation.
>
> Please join me in welcoming Jared!
>
> Best Regards,
>
> Mark Bretl
> On behalf of the Apache Geode PMC
>

[jira] [Created] (GEODE-2474) netstat command fails to correctly identify OS and --with-lsof fails on Mac

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2474:


 Summary: netstat command fails to correctly identify OS and 
--with-lsof fails on Mac
 Key: GEODE-2474
 URL: https://issues.apache.org/jira/browse/GEODE-2474
 Project: Geode
  Issue Type: Bug
  Components: gfsh, management
Reporter: Kirk Lund


The netstat gfsh command uses NetstatFunction which has its own faulty logic 
for identifying the operating system. This logic identifies Mac as Windows and 
fails to process --with-lsof.

NetstatFunction should instead use org.apache.geode.internal.lang.SystemUtils 
which correctly identifies the operating system.




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

[jira] [Updated] (GEODE-2474) netstat command fails to correctly identify OS and --with-lsof fails on Mac

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2474:
-
Labels: MiscellaneousCommands NetstatCommand gfsh netstat  (was: )

> netstat command fails to correctly identify OS and --with-lsof fails on Mac
> ---
>
> Key: GEODE-2474
> URL: https://issues.apache.org/jira/browse/GEODE-2474
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Affects Versions: 1.0.0-incubating, 1.1.0
>Reporter: Kirk Lund
>  Labels: MiscellaneousCommands, NetstatCommand, gfsh, netstat
>
> The netstat gfsh command uses NetstatFunction which has its own faulty logic 
> for identifying the operating system. This logic identifies Mac as Windows 
> and fails to process --with-lsof.
> NetstatFunction should instead use org.apache.geode.internal.lang.SystemUtils 
> which correctly identifies the operating system.



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

[jira] [Updated] (GEODE-2474) netstat command fails to correctly identify OS and --with-lsof fails on Mac

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2474:
-
Affects Version/s: 1.1.0
   1.0.0-incubating

> netstat command fails to correctly identify OS and --with-lsof fails on Mac
> ---
>
> Key: GEODE-2474
> URL: https://issues.apache.org/jira/browse/GEODE-2474
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Affects Versions: 1.0.0-incubating, 1.1.0
>Reporter: Kirk Lund
>  Labels: MiscellaneousCommands, NetstatCommand, gfsh, netstat
>
> The netstat gfsh command uses NetstatFunction which has its own faulty logic 
> for identifying the operating system. This logic identifies Mac as Windows 
> and fails to process --with-lsof.
> NetstatFunction should instead use org.apache.geode.internal.lang.SystemUtils 
> which correctly identifies the operating system.



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

Re: New Committer And PMC Member: Jared Stewart

[Kenneth Howe]

Congratulations Jared

> On Feb 13, 2017, at 12:07 PM, Joey McAllister  wrote:
> 
> Nice! Congratulations, Jared!
> 
> On Mon, Feb 13, 2017 at 11:59 AM Mark Bretl  wrote:
> 
>> The Apache Geode Project Management Committee has invited Jared Stewart to
>> be a committer on the project and join the Geode PMC. We are pleased to
>> announce he has accepted the invitation.
>> 
>> Please join me in welcoming Jared!
>> 
>> Best Regards,
>> 
>> Mark Bretl
>> On behalf of the Apache Geode PMC
>> 

[GitHub] geode-native pull request #8: GEODE-2376: Remove low-value comments from Thi...

[PivotalSarge]

GitHub user PivotalSarge opened a pull request:

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

GEODE-2376: Remove low-value comments from ThinClientPoolDM.cpp.

- Remove the stack trace comment.
- Remove commented-out code that already exists in the history
  of the file in version control.

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

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

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

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


commit 5aaec654a5503f89728373039c62c1c23c7d4259
Author: Sarge 
Date:   2017-02-13T18:54:51Z

GEODE-2376: Remove low-value comments from ThinClientPoolDM.cpp.

- Remove the stack trace comment.
- Remove commented-out code that already exists in the history
  of the file in version control.




---
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-2376) Remove stack dump comment from ThinClientPoolDM.cpp

[ASF GitHub Bot (JIRA)]

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

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

GitHub user PivotalSarge opened a pull request:

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

GEODE-2376: Remove low-value comments from ThinClientPoolDM.cpp.

- Remove the stack trace comment.
- Remove commented-out code that already exists in the history
  of the file in version control.

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

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

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

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


commit 5aaec654a5503f89728373039c62c1c23c7d4259
Author: Sarge 
Date:   2017-02-13T18:54:51Z

GEODE-2376: Remove low-value comments from ThinClientPoolDM.cpp.

- Remove the stack trace comment.
- Remove commented-out code that already exists in the history
  of the file in version control.




> Remove stack dump comment from ThinClientPoolDM.cpp
> ---
>
> Key: GEODE-2376
> URL: https://issues.apache.org/jira/browse/GEODE-2376
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Michael Dodge
>Priority: Minor
>
> For some strange reason there is a stack dump embedded in the source. There 
> is no comment on the relevance to the section of code.
> See around line 506.



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

[jira] [Created] (GEODE-2475) Upgrade lucene version to 6.4.1

[Jason Huynh (JIRA)]

Jason Huynh created GEODE-2475:
--

 Summary: Upgrade lucene version to 6.4.1 
 Key: GEODE-2475
 URL: https://issues.apache.org/jira/browse/GEODE-2475
 Project: Geode
  Issue Type: Task
  Components: lucene
Reporter: Jason Huynh


We should probably keep geode up to date with the latest Lucene jars



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

[jira] [Assigned] (GEODE-2475) Upgrade lucene version to 6.4.1

[Jason Huynh (JIRA)]

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

Jason Huynh reassigned GEODE-2475:
--

Assignee: Jason Huynh

> Upgrade lucene version to 6.4.1 
> 
>
> Key: GEODE-2475
> URL: https://issues.apache.org/jira/browse/GEODE-2475
> Project: Geode
>  Issue Type: Task
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> We should probably keep geode up to date with the latest Lucene jars



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

[jira] [Assigned] (GEODE-2476) Replace gfcpp with geode

[Michael Dodge (JIRA)]

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

Michael Dodge reassigned GEODE-2476:


Assignee: Michael Dodge

> Replace gfcpp with geode
> 
>
> Key: GEODE-2476
> URL: https://issues.apache.org/jira/browse/GEODE-2476
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> The substring "gfcpp" still occurs in some places in the native client 
> codebase. It ought to be replaced with "geode" or "geode-native", whichever 
> makes more sense on a case-by-case basis.



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

[jira] [Created] (GEODE-2476) Replace gfcpp with geode

[Michael Dodge (JIRA)]

Michael Dodge created GEODE-2476:


 Summary: Replace gfcpp with geode
 Key: GEODE-2476
 URL: https://issues.apache.org/jira/browse/GEODE-2476
 Project: Geode
  Issue Type: Improvement
  Components: native client
Reporter: Michael Dodge


The substring "gfcpp" still occurs in some places in the native client 
codebase. It ought to be replaced with "geode" or "geode-native", whichever 
makes more sense on a case-by-case basis.



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

Review Request 56613: GEODE-2475: Upgrade Lucene version to 6.4.1

[Jason Huynh]

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

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


Repository: geode


Description
---

Upgrading lucene version to 6.4.1


Diffs
-

  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/directory/RegionDirectory.java
 2623e16 
  gradle/dependency-versions.properties 75b1243 

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


Testing
---

geode-lucene:precheckin


Thanks,

Jason Huynh

[GitHub] geode pull request #396: Add junit to try parsing of simple XML file with po...

[oshvarts]

Github user oshvarts closed the pull request at:

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


---
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 #396: Add junit to try parsing of simple XML file with pool...

[oshvarts]

Github user oshvarts commented on the issue:

https://github.com/apache/geode/pull/396
  
will create another pull request, canceling this one.


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

[GitHub] geode pull request #397: Add junit to try parsing of simple XML file w pool ...

[oshvarts]

GitHub user oshvarts opened a pull request:

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

Add junit to try parsing of simple XML file w pool ...

...to detect/prevent regression to parsing exceptions that happened
in gemfire 9.0 - 9.0.1.

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

$ git pull https://github.com/oshvarts/geode config-xml-parser2

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

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






---
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 56613: GEODE-2475: Upgrade Lucene version to 6.4.1

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Feb. 13, 2017, 9:02 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56613/
> ---
> 
> (Updated Feb. 13, 2017, 9:02 p.m.)
> 
> 
> Review request for geode, nabarun nag, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Upgrading lucene version to 6.4.1
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/directory/RegionDirectory.java
>  2623e16 
>   gradle/dependency-versions.properties 75b1243 
> 
> Diff: https://reviews.apache.org/r/56613/diff/
> 
> 
> Testing
> ---
> 
> geode-lucene:precheckin
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: New Committer And PMC Member: Jared Stewart

[Dan Smith]

Sweet! Welcome!

-Dan

On Mon, Feb 13, 2017 at 12:23 PM, Kenneth Howe  wrote:

> Congratulations Jared
>
> > On Feb 13, 2017, at 12:07 PM, Joey McAllister 
> wrote:
> >
> > Nice! Congratulations, Jared!
> >
> > On Mon, Feb 13, 2017 at 11:59 AM Mark Bretl  wrote:
> >
> >> The Apache Geode Project Management Committee has invited Jared Stewart
> to
> >> be a committer on the project and join the Geode PMC. We are pleased to
> >> announce he has accepted the invitation.
> >>
> >> Please join me in welcoming Jared!
> >>
> >> Best Regards,
> >>
> >> Mark Bretl
> >> On behalf of the Apache Geode PMC
> >>
>
>

[GitHub] geode-native pull request #3: Replace ace calls to standard functions

[dgkimura]

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

https://github.com/apache/geode-native/pull/3#discussion_r100903407
  
--- Diff: src/cppcache/src/TcrMessage.hpp ---
@@ -1170,7 +1170,7 @@ class TcrMessageHelper {
 }
 if (compId != expectedPartType) {
   char exMsg[256];
-  ACE_OS::snprintf(exMsg, 255,
+  std::snprintf(exMsg, 255,
--- End diff --

Is there a command line tool (e.g. lint) that I can run to ensure changes 
adhere to the style guide?  Also to be clear, it's the fact that the following 
lines are indented more than 2 spaces (than the line above) that is in 
violation?


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

[GitHub] geode pull request #377: GEODE-1435: Adds binary distribution licensing.

[pivotal-jbarrett]

Github user pivotal-jbarrett closed the pull request at:

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


---
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-1435) Update LICENSE for native client bundled dependencies

[ASF GitHub Bot (JIRA)]

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

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

Github user pivotal-jbarrett closed the pull request at:

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


> Update LICENSE for native client bundled dependencies
> -
>
> Key: GEODE-1435
> URL: https://issues.apache.org/jira/browse/GEODE-1435
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>Assignee: Jacob S. Barrett
>
> We need to declare attribution for any bundled dependencies in the native 
> client source code.  If we choose to include the native client in the binary 
> distribution, we will need to declare those bundled libraries as well.
> See 
> https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors.
> Affected files:
> - LICENSE, NOTICE (source distribution)
> - geode-assembly/src/main/dist/LICENSE, NOTICE (binary distribution)
> Initial list of bundled source dependencies:
> - MersenneTwister (src/tests/cpp/fwklib/MersenneTwister.*pp)
> The binary dependencies can be reviewed in 
> geode-client-native/src/dependencies (some of these are not shipped though):
> - libxml2
> - xerces-c
> - openssl
> - ACE
> - antlr
> - sqlite
> - doxygen
> - gtest



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

[GitHub] geode-native pull request #3: Replace ace calls to standard functions

[dgkimura]

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

https://github.com/apache/geode-native/pull/3#discussion_r100904404
  
--- Diff: src/cppcache/src/CacheXmlParser.cpp ---
@@ -1165,7 +1166,7 @@ void CacheXmlParser::startPersistenceManager(const 
xmlChar** atts) {
 throw CacheXmlException(s.c_str());
   }
 
-  ACE_OS::strncpy(libraryFunctionName, (char*)atts[i], len);
+  std::strncpy(libraryFunctionName, (char*)atts[i], len);
--- End diff --

Maybe this would be better as a separate pull request for fixing all 
c-style casts?  However, if you feel it's more effective to update them 
incrementally as we make changes then I will add them to this pull request.


---
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-2475) Upgrade lucene version to 6.4.1

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2475:


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

GEODE-2475: Upgrade Lucene version to 6.4.1


> Upgrade lucene version to 6.4.1 
> 
>
> Key: GEODE-2475
> URL: https://issues.apache.org/jira/browse/GEODE-2475
> Project: Geode
>  Issue Type: Task
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> We should probably keep geode up to date with the latest Lucene jars



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

[GitHub] geode-native pull request #9: [GEODE-2408] Refactor CacheableDate with C++11...

[pivotal-jbarrett]

GitHub user pivotal-jbarrett opened a pull request:

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

[GEODE-2408] Refactor CacheableDate with C++11 standards.

Moved from old repo to new repo. Can I get a thumbs up please?

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

$ git pull https://github.com/pivotal-jbarrett/geode-native 
feature/GEODE-2408

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

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


commit 1d16b3be249693b7bd5bf4422445a0635c9d1379
Author: Jacob Barrett 
Date:   2016-12-06T01:52:31Z

GEODE-2408: Refactor CacheableDate with C++11 standards.

commit bc1a8faccd7dceb2e37abe632ab809adc23e790a
Author: Jacob Barrett 
Date:   2017-02-01T06:15:07Z

GEODE-2408: Updated usage of deprecated CacheableDate.

commit e1f99a67b77658178f2d5e3b025ed5f1369060ca
Author: Jacob Barrett 
Date:   2017-02-01T06:34:44Z

GEODE-2408: Removed non-standard timeval type methods.




---
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-2408) Refactor CacheableDate to use C++ std::chrono

[ASF GitHub Bot (JIRA)]

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

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

GitHub user pivotal-jbarrett opened a pull request:

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

[GEODE-2408] Refactor CacheableDate with C++11 standards.

Moved from old repo to new repo. Can I get a thumbs up please?

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

$ git pull https://github.com/pivotal-jbarrett/geode-native 
feature/GEODE-2408

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

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


commit 1d16b3be249693b7bd5bf4422445a0635c9d1379
Author: Jacob Barrett 
Date:   2016-12-06T01:52:31Z

GEODE-2408: Refactor CacheableDate with C++11 standards.

commit bc1a8faccd7dceb2e37abe632ab809adc23e790a
Author: Jacob Barrett 
Date:   2017-02-01T06:15:07Z

GEODE-2408: Updated usage of deprecated CacheableDate.

commit e1f99a67b77658178f2d5e3b025ed5f1369060ca
Author: Jacob Barrett 
Date:   2017-02-01T06:34:44Z

GEODE-2408: Removed non-standard timeval type methods.




> Refactor CacheableDate to use C++ std::chrono
> -
>
> Key: GEODE-2408
> URL: https://issues.apache.org/jira/browse/GEODE-2408
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>




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

[GitHub] geode pull request #385: [GEODE-2408] Refactor CacheableDate to use C++ std:...

[pivotal-jbarrett]

Github user pivotal-jbarrett closed the pull request at:

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


---
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 #385: [GEODE-2408] Refactor CacheableDate to use C++ std::chrono

[pivotal-jbarrett]

Github user pivotal-jbarrett commented on the issue:

https://github.com/apache/geode/pull/385
  
Moved to https://github.com/apache/geode-native/pull/9


---
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-2408) Refactor CacheableDate to use C++ std::chrono

[ASF GitHub Bot (JIRA)]

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

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

Github user pivotal-jbarrett commented on the issue:

https://github.com/apache/geode/pull/385
  
Moved to https://github.com/apache/geode-native/pull/9


> Refactor CacheableDate to use C++ std::chrono
> -
>
> Key: GEODE-2408
> URL: https://issues.apache.org/jira/browse/GEODE-2408
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>




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

[jira] [Commented] (GEODE-2408) Refactor CacheableDate to use C++ std::chrono

[ASF GitHub Bot (JIRA)]

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

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

Github user pivotal-jbarrett closed the pull request at:

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


> Refactor CacheableDate to use C++ std::chrono
> -
>
> Key: GEODE-2408
> URL: https://issues.apache.org/jira/browse/GEODE-2408
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>




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

[jira] [Commented] (GEODE-2408) Refactor CacheableDate to use C++ std::chrono

[ASF GitHub Bot (JIRA)]

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

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

Github user PivotalSarge commented on the issue:

https://github.com/apache/geode-native/pull/9
  
LGTM


> Refactor CacheableDate to use C++ std::chrono
> -
>
> Key: GEODE-2408
> URL: https://issues.apache.org/jira/browse/GEODE-2408
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>




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

[jira] [Resolved] (GEODE-2475) Upgrade lucene version to 6.4.1

[Jason Huynh (JIRA)]

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

Jason Huynh resolved GEODE-2475.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Upgrade lucene version to 6.4.1 
> 
>
> Key: GEODE-2475
> URL: https://issues.apache.org/jira/browse/GEODE-2475
> Project: Geode
>  Issue Type: Task
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.2.0
>
>
> We should probably keep geode up to date with the latest Lucene jars



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

[GitHub] geode-native issue #9: [GEODE-2408] Refactor CacheableDate with C++11 standa...

[PivotalSarge]

Github user PivotalSarge commented on the issue:

https://github.com/apache/geode-native/pull/9
  
LGTM


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

[jira] [Created] (GEODE-2477) CI Failure suspect string from returnCorrectResultsWhenCloseCacheHappensOnPartialIndexWrite

[Dan Smith (JIRA)]

Dan Smith created GEODE-2477:


 Summary: CI Failure  suspect string from 
returnCorrectResultsWhenCloseCacheHappensOnPartialIndexWrite
 Key: GEODE-2477
 URL: https://issues.apache.org/jira/browse/GEODE-2477
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Dan Smith


Revision dbea592cc96f64c9fbc7abf8bbf597a69c5881cd

{noformat}
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 1450

[error 2017/02/12 06:02:16.915 PST  tid=0x7a8] Unable to save to 
lucene index
org.apache.geode.cache.CacheClosedException: The cache has been closed
at 
org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1621)
at 
org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:498)
at 
org.apache.geode.internal.cache.AbstractUpdateOperation.distribute(AbstractUpdateOperation.java:70)
at 
org.apache.geode.internal.cache.BucketRegion.basicPutPart2(BucketRegion.java:633)
at 
org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2800)
at 
org.apache.geode.internal.cache.BucketRegion.virtualPut(BucketRegion.java:485)
at 
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:151)
at 
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5194)
at 
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1605)
at 
org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1592)
at 
org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:277)
at 
org.apache.geode.cache.lucene.internal.filesystem.FileSystem.putChunk(FileSystem.java:183)
at 
org.apache.geode.cache.lucene.internal.filesystem.FileOutputStream.flushBuffer(FileOutputStream.java:90)
at 
org.apache.geode.cache.lucene.internal.filesystem.FileOutputStream.close(FileOutputStream.java:78)
at java.io.FilterOutputStream.close(FilterOutputStream.java:159)
at java.io.FilterOutputStream.close(FilterOutputStream.java:159)
at 
org.apache.lucene.store.OutputStreamIndexOutput.close(OutputStreamIndexOutput.java:70)
at 
org.apache.lucene.codecs.compressing.CompressingStoredFieldsIndexWriter.close(CompressingStoredFieldsIndexWriter.java:210)
at org.apache.lucene.util.IOUtils.close(IOUtils.java:89)
at org.apache.lucene.util.IOUtils.close(IOUtils.java:76)
at 
org.apache.lucene.codecs.compressing.CompressingStoredFieldsWriter.close(CompressingStoredFieldsWriter.java:138)
at 
org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:117)
at 
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:423)
at 
org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:502)
at 
org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:614)
at 
org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2815)
at 
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2989)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2956)
at 
org.apache.geode.cache.lucene.internal.repository.IndexRepositoryImpl.commit(IndexRepositoryImpl.java:144)
at 
org.apache.geode.cache.lucene.internal.LuceneEventListener.processEvents(LuceneEventListener.java:88)
at 
org.apache.geode.internal.cache.wan.GatewaySenderEventCallbackDispatcher.dispatchBatch(GatewaySenderEventCallbackDispatcher.java:154)
at 
org.apache.geode.internal.cache.wan.GatewaySenderEventCallbackDispatcher.dispatchBatch(GatewaySenderEventCallbackDispatcher.java:80)
at 
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.processQueue(AbstractGatewaySenderEventProcessor.java:593)
at 
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.run(AbstractGatewaySenderEventProcessor.java:1036)
{noformat}



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

[GitHub] geode-native issue #7: Feature/geode 2467

[PivotalSarge]

Github user PivotalSarge commented on the issue:

https://github.com/apache/geode-native/pull/7
  
LGTM



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

[GitHub] geode-native issue #2: GEODE-2423: Remove unused keystore files and rename t...

[PivotalSarge]

Github user PivotalSarge commented on the issue:

https://github.com/apache/geode-native/pull/2
  
LGTM


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

[GitHub] geode-native pull request #9: [GEODE-2408] Refactor CacheableDate with C++11...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1824) CI Failure: LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnPartialIndexWrite

[Dan Smith (JIRA)]

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

Dan Smith resolved GEODE-1824.
--
   Resolution: Cannot Reproduce
 Assignee: Dan Smith
Fix Version/s: 1.2.0

I haven't seen this happen after running a few hundred times with 
dbea592cc96f64c9fbc7abf8bbf597a69c5881cd. I am seeing GEODE-2477. The code has 
changed quite a bit since this was filed. Closing this issue in favor that one.

> CI Failure: 
> LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnPartialIndexWrite
> ---
>
> Key: GEODE-1824
> URL: https://issues.apache.org/jira/browse/GEODE-1824
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Anilkumar Gingade
>Assignee: Dan Smith
>  Labels: CI
> Fix For: 1.2.0
>
>
> Build #3764 (Aug 24, 2016 11:09:14 PM) 
> Revision: 98531a16f8844a1028e2e6de293eb080d8ea7a1d
> refs/remotes/origin/develop
> Error Message
> java.lang.AssertionError
> Stacktrace
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertTrue(Assert.java:52)
>   at 
> com.gemstone.gemfire.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest.putEntriesAndValidateResultsWithRedundancy(LuceneQueriesPeerPRRedundancyDUnitTest.java:114)
>   at 
> com.gemstone.gemfire.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnPartialIndexWrite(LuceneQueriesPeerPRRedundancyDUnitTest.java:90)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor166.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>

[jira] [Commented] (GEODE-2408) Refactor CacheableDate to use C++ std::chrono

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Refactor CacheableDate to use C++ std::chrono
> -
>
> Key: GEODE-2408
> URL: https://issues.apache.org/jira/browse/GEODE-2408
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>




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

[jira] [Commented] (GEODE-2408) Refactor CacheableDate to use C++ std::chrono

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2408:


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

GEODE-2408: Updated usage of deprecated CacheableDate.


> Refactor CacheableDate to use C++ std::chrono
> -
>
> Key: GEODE-2408
> URL: https://issues.apache.org/jira/browse/GEODE-2408
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>




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

[jira] [Commented] (GEODE-2408) Refactor CacheableDate to use C++ std::chrono

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2408:


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

GEODE-2408: Removed non-standard timeval type methods.


> Refactor CacheableDate to use C++ std::chrono
> -
>
> Key: GEODE-2408
> URL: https://issues.apache.org/jira/browse/GEODE-2408
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>




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

[jira] [Commented] (GEODE-2423) Remove unused keystore files

[ASF GitHub Bot (JIRA)]

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

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

Github user PivotalSarge commented on the issue:

https://github.com/apache/geode-native/pull/2
  
LGTM


> Remove unused keystore files
> 
>
> Key: GEODE-2423
> URL: https://issues.apache.org/jira/browse/GEODE-2423
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Michael Martell
>
> This task is to remove unreferenced files in 
> cppcache/integration-test/keystore folder.



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

[jira] [Commented] (GEODE-2408) Refactor CacheableDate to use C++ std::chrono

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2408:


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

GEODE-2408: Refactor CacheableDate with C++11 standards.


> Refactor CacheableDate to use C++ std::chrono
> -
>
> Key: GEODE-2408
> URL: https://issues.apache.org/jira/browse/GEODE-2408
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>




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

Re: Review Request 56613: GEODE-2475: Upgrade Lucene version to 6.4.1

[xiaojian zhou]

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


Ship it!




Ship It!

- xiaojian zhou


On Feb. 13, 2017, 9:02 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56613/
> ---
> 
> (Updated Feb. 13, 2017, 9:02 p.m.)
> 
> 
> Review request for geode, nabarun nag, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Upgrading lucene version to 6.4.1
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/directory/RegionDirectory.java
>  2623e16 
>   gradle/dependency-versions.properties 75b1243 
> 
> Diff: https://reviews.apache.org/r/56613/diff/
> 
> 
> Testing
> ---
> 
> geode-lucene:precheckin
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

[jira] [Commented] (GEODE-2231) Create new partitioning example

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2231:


Commit c22885346b8af173bc4765cf179b0a96d70959bc in geode-examples's branch 
refs/heads/feature/GEODE-2231 from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode-examples.git;h=c228853 ]

GEODE-2231 Revise Producer tests and the README.md

- Re-run spotlessApply.
- Clean up unused code and update comments.


> Create new partitioning example
> ---
>
> Key: GEODE-2231
> URL: https://issues.apache.org/jira/browse/GEODE-2231
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>Priority: Minor
>
> Add a new example to the geode-examples that demonstrates partitioning.
> The example will use the same structure as the replicated example, starting 2 
> servers that host a partitioned region (with no redundant copies).  Run the 
> producer to populate the region.  Run the consumer to see the contents of the 
> region. Then, stop one of the servers and run the consumer again to notice 
> that only roughly half (with 2 servers and hopefully a reasonable hash) of 
> the entries are present.



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2357:


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

GEODE-2357: Replace gemfire with geode (all case variants) in C#
quickstarts

This closes #1


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



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

[GitHub] geode-native pull request #1: GEODE-2357: Replace gemfire with geode (all ca...

[asfgit]

Github user asfgit closed the pull request at:

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


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

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

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


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



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

[GitHub] geode-native pull request #2: GEODE-2423: Remove unused keystore files and r...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2423) Remove unused keystore files

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Remove unused keystore files
> 
>
> Key: GEODE-2423
> URL: https://issues.apache.org/jira/browse/GEODE-2423
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Michael Martell
>
> This task is to remove unreferenced files in 
> cppcache/integration-test/keystore folder.



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

[jira] [Commented] (GEODE-2423) Remove unused keystore files

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2423:


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

GEODE-2423: Remove unused keystore files and rename to geode.keystore

This closes #2.


> Remove unused keystore files
> 
>
> Key: GEODE-2423
> URL: https://issues.apache.org/jira/browse/GEODE-2423
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Michael Martell
>
> This task is to remove unreferenced files in 
> cppcache/integration-test/keystore folder.



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

[GitHub] geode-native pull request #3: Replace ace calls to standard functions

[pivotal-jbarrett]

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

https://github.com/apache/geode-native/pull/3#discussion_r100912867
  
--- Diff: src/cppcache/src/TcrMessage.hpp ---
@@ -1170,7 +1170,7 @@ class TcrMessageHelper {
 }
 if (compId != expectedPartType) {
   char exMsg[256];
-  ACE_OS::snprintf(exMsg, 255,
+  std::snprintf(exMsg, 255,
--- End diff --

We don't have a good command to execute. I suggest looking for integration 
into what ever editor you have with clang-format. There appears to be some 
differences between clang-format on mac and windows so limit the formatting to 
files you are editing. 

For example, in Eclipse, I have reformat on save configured. 

The following lines used to be aligned with the changed line's open paren. 
The guide defines specific rules for when to align to the paren or indent.



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

[GitHub] geode-native pull request #3: Replace ace calls to standard functions

[pivotal-jbarrett]

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

https://github.com/apache/geode-native/pull/3#discussion_r100913452
  
--- Diff: src/cppcache/src/CacheXmlParser.cpp ---
@@ -1165,7 +1166,7 @@ void CacheXmlParser::startPersistenceManager(const 
xmlChar** atts) {
 throw CacheXmlException(s.c_str());
   }
 
-  ACE_OS::strncpy(libraryFunctionName, (char*)atts[i], len);
+  std::strncpy(libraryFunctionName, (char*)atts[i], len);
--- End diff --

I am of the camp that believes that large efforts like that are rarely 
undertaken unless there is an easy tool to do the work for you. The clang-tidy 
rule fixed some when we did the initial reformat and cleanup to Google C++ 
Style Guide. There were some it was unable to do automagically, my guess 
because they were ambiguous. I would make an effort that any file you edit 
should compile clean, no warnings and no static analyzer warnings/errors. You 
can enable clang-tidy by passing CLANG_TIDY_ENABLED=ON to CMake.




---
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-2398) Sporadic Oplog corruption due to channel.write failure

[Kenneth Howe (JIRA)]

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

Kenneth Howe resolved GEODE-2398.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

Commits:
fb14e9aab263654ed0176dcc3c9738be1b208a82
9b0f16570aad4abc82b71d0d16167a9774449d41

> Sporadic Oplog corruption due to channel.write failure
> --
>
> Key: GEODE-2398
> URL: https://issues.apache.org/jira/browse/GEODE-2398
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
> Fix For: 1.2.0
>
>
> There have been some occurrences of Oplog corruption during testing that have 
> been traced to failures in writing oplog entries to the .crf file. When it 
> fails, Oplog.flush attempts to write a ByteBuffer to the file channel. The 
> call to channel.write(bb) method returns 0 bytes written, but the source 
> ByteBuffer position is moved to the ByteBuffer limit.



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

[GitHub] geode-native pull request #3: Replace ace calls to standard functions

[dgkimura]

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

https://github.com/apache/geode-native/pull/3#discussion_r10091
  
--- Diff: src/cppcache/src/CacheXmlParser.cpp ---
@@ -1165,7 +1166,7 @@ void CacheXmlParser::startPersistenceManager(const 
xmlChar** atts) {
 throw CacheXmlException(s.c_str());
   }
 
-  ACE_OS::strncpy(libraryFunctionName, (char*)atts[i], len);
+  std::strncpy(libraryFunctionName, (char*)atts[i], len);
--- End diff --

Alright.  Thanks for the clang-tidy tip.  I'll add these changes and update 
the pull request.


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

[GitHub] geode-native pull request #3: Replace ace calls to standard functions

[dgkimura]

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

https://github.com/apache/geode-native/pull/3#discussion_r100917160
  
--- Diff: src/cppcache/src/TcrMessage.hpp ---
@@ -1170,7 +1170,7 @@ class TcrMessageHelper {
 }
 if (compId != expectedPartType) {
   char exMsg[256];
-  ACE_OS::snprintf(exMsg, 255,
+  std::snprintf(exMsg, 255,
--- End diff --

Ah, thanks.  I didn't see that.  I'll update the PR.


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

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #471 was successful.
---
Scheduled
1681 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

[jira] [Updated] (GEODE-2052) Docs to segregate types of properties

[Dave Barnes (JIRA)]

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

Dave Barnes updated GEODE-2052:
---
Description: 
Geode has a lot of properties. But they are not mentioned in context but rather 
listed as geode properties which can go in geode.properties and 
gfsecurity.properties.

It would nice to have a segregation by Locator and Server under 
geode.properties. The reason for this ask is that some properties do not apply 
to both locator and server. Currently the only way to know this is by 
experience or trial and error.

We also found out that some of the gemfire.properties do not get applied when 
supplied in geode.properties but rather have to be passed as command line 
properties. e.g. enabling rest api.
It would be nice to call that out clearly in docs.

There are example of properties which have to be applied together in order to 
enable a functionality e.g. rest api needs bind address property and 
http-service-port. Its not called out clearly in the docs that they are 
*mandatory*. 
[link to docs 
section](http://geode.incubator.apache.org/docs/guide/rest_apps/setup_config.html)

~~quote ~~

~~To enable the developer REST API service in Apache Geode, set the 
start-dev-rest-api Geode property to true when starting a data node using 
either gfsh or the ServerLauncher API. Setting this property to true on a data 
node will start up an embedded Jetty server and deploy the REST developer API 
WAR file.~~

~~It should highlight that its necessary to have 2 more properties bind-address 
and http-service-port defined to make it work.~~

We would be happy to provide further details on this matter if needed.

  was:
Geode has a lot of properties. But they are not mentioned in context but rather 
listed as geode properties which can go in geode.properties and 
gfsecurity.properties.

It would nice to have a segregation by Locator and Server under 
geode.properties. The reason for this ask is that some properties do not apply 
to both locator and server. Currently the only way to know this is by 
experience or trial and error.

We also found out that some of the gemfire.properties do not get applied when 
supplied in geode.properties but rather have to be passed as command line 
properties. e.g. enabling rest api.
It would be nice to call that out clearly in docs.

There are example of properties which have to be applied together in order to 
enable a functionality e.g. rest api needs bind address property and 
http-service-port. Its not called out clearly in the docs that they are 
*mandatory*. 
[link to docs 
section](http://geode.incubator.apache.org/docs/guide/rest_apps/setup_config.html)

quote 

```
To enable the developer REST API service in Apache Geode, set the 
start-dev-rest-api Geode property to true when starting a data node using 
either gfsh or the ServerLauncher API. Setting this property to true on a data 
node will start up an embedded Jetty server and deploy the REST developer API 
WAR file.

```
It should highlight that its necessary to have 2 more properties bind-address 
and http-service-port defined to make it work.

We would be happy to provide further details on this matter if needed.


> Docs to segregate types of properties
> -
>
> Key: GEODE-2052
> URL: https://issues.apache.org/jira/browse/GEODE-2052
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Pulkit Chandra
>Assignee: Dave Barnes
>
> Geode has a lot of properties. But they are not mentioned in context but 
> rather listed as geode properties which can go in geode.properties and 
> gfsecurity.properties.
> It would nice to have a segregation by Locator and Server under 
> geode.properties. The reason for this ask is that some properties do not 
> apply to both locator and server. Currently the only way to know this is by 
> experience or trial and error.
> We also found out that some of the gemfire.properties do not get applied when 
> supplied in geode.properties but rather have to be passed as command line 
> properties. e.g. enabling rest api.
> It would be nice to call that out clearly in docs.
> There are example of properties which have to be applied together in order to 
> enable a functionality e.g. rest api needs bind address property and 
> http-service-port. Its not called out clearly in the docs that they are 
> *mandatory*. 
> [link to docs 
> section](http://geode.incubator.apache.org/docs/guide/rest_apps/setup_config.html)
> ~~quote ~~
> ~~To enable the developer REST API service in Apache Geode, set the 
> start-dev-rest-api Geode property to true when starting a data node using 
> either gfsh or the ServerLauncher API. Setting this property to true on a 
> data node will start up an embedded Jetty server and deploy the REST 
> developer API WAR file.~~
> ~~It should h

[jira] [Updated] (GEODE-2052) Docs to segregate types of properties

[Dave Barnes (JIRA)]

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

Dave Barnes updated GEODE-2052:
---
Description: 
Geode has a lot of properties. But they are not mentioned in context but rather 
listed as geode properties which can go in geode.properties and 
gfsecurity.properties.

It would nice to have a segregation by Locator and Server under 
geode.properties. The reason for this ask is that some properties do not apply 
to both locator and server. Currently the only way to know this is by 
experience or trial and error.

~~We also found out that some of the gemfire.properties do not get applied when 
supplied in geode.properties but rather have to be passed as command line 
properties. e.g. enabling rest api.
It would be nice to call that out clearly in docs.~~

~~There are example of properties which have to be applied together in order to 
enable a functionality e.g. rest api needs bind address property and 
http-service-port. Its not called out clearly in the docs that they are 
*mandatory*. ~~
[link to docs 
section](http://geode.incubator.apache.org/docs/guide/rest_apps/setup_config.html)

~~quote ~~

~~To enable the developer REST API service in Apache Geode, set the 
start-dev-rest-api Geode property to true when starting a data node using 
either gfsh or the ServerLauncher API. Setting this property to true on a data 
node will start up an embedded Jetty server and deploy the REST developer API 
WAR file.~~

~~It should highlight that its necessary to have 2 more properties bind-address 
and http-service-port defined to make it work.~~

We would be happy to provide further details on this matter if needed.

  was:
Geode has a lot of properties. But they are not mentioned in context but rather 
listed as geode properties which can go in geode.properties and 
gfsecurity.properties.

It would nice to have a segregation by Locator and Server under 
geode.properties. The reason for this ask is that some properties do not apply 
to both locator and server. Currently the only way to know this is by 
experience or trial and error.

We also found out that some of the gemfire.properties do not get applied when 
supplied in geode.properties but rather have to be passed as command line 
properties. e.g. enabling rest api.
It would be nice to call that out clearly in docs.

There are example of properties which have to be applied together in order to 
enable a functionality e.g. rest api needs bind address property and 
http-service-port. Its not called out clearly in the docs that they are 
*mandatory*. 
[link to docs 
section](http://geode.incubator.apache.org/docs/guide/rest_apps/setup_config.html)

~~quote ~~

~~To enable the developer REST API service in Apache Geode, set the 
start-dev-rest-api Geode property to true when starting a data node using 
either gfsh or the ServerLauncher API. Setting this property to true on a data 
node will start up an embedded Jetty server and deploy the REST developer API 
WAR file.~~

~~It should highlight that its necessary to have 2 more properties bind-address 
and http-service-port defined to make it work.~~

We would be happy to provide further details on this matter if needed.


> Docs to segregate types of properties
> -
>
> Key: GEODE-2052
> URL: https://issues.apache.org/jira/browse/GEODE-2052
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Pulkit Chandra
>Assignee: Dave Barnes
>
> Geode has a lot of properties. But they are not mentioned in context but 
> rather listed as geode properties which can go in geode.properties and 
> gfsecurity.properties.
> It would nice to have a segregation by Locator and Server under 
> geode.properties. The reason for this ask is that some properties do not 
> apply to both locator and server. Currently the only way to know this is by 
> experience or trial and error.
> ~~We also found out that some of the gemfire.properties do not get applied 
> when supplied in geode.properties but rather have to be passed as command 
> line properties. e.g. enabling rest api.
> It would be nice to call that out clearly in docs.~~
> ~~There are example of properties which have to be applied together in order 
> to enable a functionality e.g. rest api needs bind address property and 
> http-service-port. Its not called out clearly in the docs that they are 
> *mandatory*. ~~
> [link to docs 
> section](http://geode.incubator.apache.org/docs/guide/rest_apps/setup_config.html)
> ~~quote ~~
> ~~To enable the developer REST API service in Apache Geode, set the 
> start-dev-rest-api Geode property to true when starting a data node using 
> either gfsh or the ServerLauncher API. Setting this property to true on a 
> data node will start up an embedded Jetty server and deploy the REST 
> developer API WAR fil

[jira] [Commented] (GEODE-2453) region.create does not honor contract on PROXY region

[Darrel Schneider (JIRA)]

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

Darrel Schneider commented on GEODE-2453:
-

This is actually the expected behavior with how PROXY regions are currently 
specified to behave.
Create is checking if the local PROXY region has an existing entry. Since the 
PROXY is always empty it does not and the create operation is allowed and 
distributed to others.
In the new specification of PROXY regions in which they will always forward the 
operation to be done on the server (see GEODE-1887) create should be changed to 
check the server for an existing key instead of checking the state on the local 
PROXY.

> region.create does not honor contract on PROXY region
> -
>
> Key: GEODE-2453
> URL: https://issues.apache.org/jira/browse/GEODE-2453
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Swapnil Bawaskar
>
> A create(K,V) on a client PROXY region does not throw an 
> {{EntryExistsException}} when the entry already exists on the server.



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

[jira] [Updated] (GEODE-2352) Document that REST API requires two properties

[Dave Barnes (JIRA)]

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

Dave Barnes updated GEODE-2352:
---
Description: 
Pulkit Chandra wrote in GEODE-2052:

The REST api needs bind address property and http-service-port. Its not called 
out clearly in the docs that they are *mandatory*. 
[link to docs 
section](http://geode.incubator.apache.org/docs/guide/rest_apps/setup_config.html)

quote 

```
To enable the developer REST API service in Apache Geode, set the 
start-dev-rest-api Geode property to true when starting a data node using 
either gfsh or the ServerLauncher API. Setting this property to true on a data 
node will start up an embedded Jetty server and deploy the REST developer API 
WAR file.

```
We also found out that some of the gemfire.properties do not get applied when 
supplied in geode.properties but rather have to be passed as command line 
properties. e.g. enabling rest api.
It would be nice to call that out clearly in docs.
It should highlight that its necessary to have 2 more properties bind-address 
and http-service-port defined to make it work.

We would be happy to provide further details on this matter if needed.

  was:
Pulkit Chandra wrote in GEODE-2052:

The REST api needs bind address property and http-service-port. Its not called 
out clearly in the docs that they are *mandatory*. 
[link to docs 
section](http://geode.incubator.apache.org/docs/guide/rest_apps/setup_config.html)

quote 

```
To enable the developer REST API service in Apache Geode, set the 
start-dev-rest-api Geode property to true when starting a data node using 
either gfsh or the ServerLauncher API. Setting this property to true on a data 
node will start up an embedded Jetty server and deploy the REST developer API 
WAR file.

```
It should highlight that its necessary to have 2 more properties bind-address 
and http-service-port defined to make it work.

We would be happy to provide further details on this matter if needed.


> Document that REST API requires two properties
> --
>
> Key: GEODE-2352
> URL: https://issues.apache.org/jira/browse/GEODE-2352
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Pulkit Chandra wrote in GEODE-2052:
> The REST api needs bind address property and http-service-port. Its not 
> called out clearly in the docs that they are *mandatory*. 
> [link to docs 
> section](http://geode.incubator.apache.org/docs/guide/rest_apps/setup_config.html)
> quote 
> ```
> To enable the developer REST API service in Apache Geode, set the 
> start-dev-rest-api Geode property to true when starting a data node using 
> either gfsh or the ServerLauncher API. Setting this property to true on a 
> data node will start up an embedded Jetty server and deploy the REST 
> developer API WAR file.
> ```
> We also found out that some of the gemfire.properties do not get applied when 
> supplied in geode.properties but rather have to be passed as command line 
> properties. e.g. enabling rest api.
> It would be nice to call that out clearly in docs.
> It should highlight that its necessary to have 2 more properties bind-address 
> and http-service-port defined to make it work.
> We would be happy to provide further details on this matter if needed.



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

[jira] [Commented] (GEODE-2052) Docs to segregate types of properties

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2052:


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

GEODE-2052 Docs to segregate types of properties


> Docs to segregate types of properties
> -
>
> Key: GEODE-2052
> URL: https://issues.apache.org/jira/browse/GEODE-2052
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Pulkit Chandra
>Assignee: Dave Barnes
>
> Geode has a lot of properties. But they are not mentioned in context but 
> rather listed as geode properties which can go in geode.properties and 
> gfsecurity.properties.
> It would nice to have a segregation by Locator and Server under 
> geode.properties. The reason for this ask is that some properties do not 
> apply to both locator and server. Currently the only way to know this is by 
> experience or trial and error.
> ~~We also found out that some of the gemfire.properties do not get applied 
> when supplied in geode.properties but rather have to be passed as command 
> line properties. e.g. enabling rest api.
> It would be nice to call that out clearly in docs.~~
> ~~There are example of properties which have to be applied together in order 
> to enable a functionality e.g. rest api needs bind address property and 
> http-service-port. Its not called out clearly in the docs that they are 
> *mandatory*. ~~
> [link to docs 
> section](http://geode.incubator.apache.org/docs/guide/rest_apps/setup_config.html)
> ~~quote ~~
> ~~To enable the developer REST API service in Apache Geode, set the 
> start-dev-rest-api Geode property to true when starting a data node using 
> either gfsh or the ServerLauncher API. Setting this property to true on a 
> data node will start up an embedded Jetty server and deploy the REST 
> developer API WAR file.~~
> ~~It should highlight that its necessary to have 2 more properties 
> bind-address and http-service-port defined to make it work.~~
> We would be happy to provide further details on this matter if needed.



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