[jira] [Created] (GEODE-2454) UniversalMembershipListenerAdapterDUnitTest test fails on jenkins

[Hitesh Khamesra (JIRA)]

Hitesh Khamesra created GEODE-2454:
--

 Summary: UniversalMembershipListenerAdapterDUnitTest test fails on 
jenkins
 Key: GEODE-2454
 URL: https://issues.apache.org/jira/browse/GEODE-2454
 Project: Geode
  Issue Type: Bug
  Components: membership
Reporter: Hitesh Khamesra


org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest > 
testSystemClientEventsInServer FAILED
org.junit.ComparisonFailure: 
expected:<[67.195.81.13]9(6505):327...> but 
was:<[asf91]9(6505):327...>
at org.junit.Assert.assertEquals(Assert.java:115)
at org.junit.Assert.assertEquals(Assert.java:144)
at 
org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.doTestSystemClientEventsInServer(UniversalMembershipListenerAdapterDUnitTest.java:946)
at 
org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer(UniversalMembershipListenerAdapterDUnitTest.java:731)

6818 tests completed, 106 failed, 603 skipped
:geode-core:distributedTest FAILED



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

Jenkins build is back to normal : Geode-release #48

[Apache Jenkins Server]

See 

Re: Review Request 56457: GEODE-2433 Backwards compatibility tests are not actually running

[Bruce Schuchardt]

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

(Updated Feb. 9, 2017, 4:02 p.m.)


Review request for geode and Dan Smith.


Changes
---

VersionManager now throws an exception when a test attempts to find versions if 
loading failed.


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


Repository: geode


Description
---

Modified to look for the file on the class-path instead of poking around in the 
file system


Diffs (updated)
-

  
geode-core/src/test/java/org/apache/geode/test/dunit/standalone/VersionManager.java
 c06d4e8fadf7aaba5432280195ef8524e6aadcb5 
  
geode-core/src/test/java/org/apache/geode/test/dunit/standalone/VersionManagerJUnitTest.java
 PRE-CREATION 

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


Testing
---

Tested under Eclipse, Idea and Gradle


Thanks,

Bruce Schuchardt

[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15859759#comment-15859759
 ] 

Kenneth Howe commented on GEODE-2398:
-

This problem occurred writing to the channel from within the method 
Oplog.flush(OplogFile olf, boolean doSync). There is also a channel write 
executed from within Oplog.flush(OplogFile olf, ByteBuffer b1, ByteBuffer b2). 
The second form of flush calls channel.write(ByteBuffer[] bbArray) instead of 
channel.write(ByteBuffer bb) as in the first form. Since the write has been 
seen to fail in the first form, there's presumably a remote chance of a similar 
failure in the second form.

The fix for this problem is to add a retry loop around the channel.write calls 
conditional on the number of bytes written returned by write() being consistent 
with the change in ByteBuffer positions. The number of retries is limited to a 
small number to prevent a hard failure causing a thread to hang. IOException is 
thrown if the retry limit is exceeded.

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

[GitHub] geode issue #387: GEODE-2411: Remove references to Gemfire from include guar...

[PivotalSarge]

Github user PivotalSarge commented on the issue:

https://github.com/apache/geode/pull/387
  
This closes #387.


---
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 #387: GEODE-2411: Remove references to Gemfire from inclu...

[PivotalSarge]

Github user PivotalSarge closed the pull request at:

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


---
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 56242: GEODE-2206: Add junit-quickcheck to geode-core; add a test that uses it.

[xiaojian zhou]

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


Ship it!




cool stuff!

- xiaojian zhou


On Feb. 2, 2017, 9:35 p.m., Galen O'Sullivan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56242/
> ---
> 
> (Updated Feb. 2, 2017, 9:35 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Hitesh Khamesra, Kirk Lund, and 
> Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This adds a test dependency on `junit-quickcheck` (and 
> `junit-quickcheck-generators` and `junit-quickcheck-guava`) to geode-core. 
> I've included an example test of one of the cases in which property-based 
> testing is particularly nice: when you have two operations that should 
> reverse each other and want to test them with as much garbage as possible.
> 
> Property-based testing means basically that you write a function that tests 
> some code and checks some conditions you expect to hold true for all inputs, 
> and then have a computer program test all sorts of weird inputs to try prove 
> you wrong.
> 
> Because the test data is randomly generated, you get to test against more 
> inputs than you might even think of, and because the seed is saved, the test 
> is reproducible. If `junit-quickcheck` finds one failure, it will even try to 
> narrow down to a smallest example of a test failure.
> 
> I'm about to send an email to the dev list soliciting feedback.
> 
> 
> Diffs
> -
> 
>   geode-core/build.gradle 3c2a2abf5 
>   
> geode-core/src/test/java/org/apache/geode/internal/InternalDataSerializerQuickcheckStringTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/InternalDataSerializerRandomizedJUnitTest.java
>  f361de4a2 
>   gradle/dependency-versions.properties fbc76e012 
> 
> Diff: https://reviews.apache.org/r/56242/diff/
> 
> 
> Testing
> ---
> 
> The test passes on my machine. This is mostly just adding a dependency, so 
> there's not a lot here to test.
> 
> I've read some of the source of junit-quickcheck and looked into the data it 
> generates: integral numbers seem pretty reasonable. Strings tend to be 
> short-ish (length up to hundreds with hundreds of iterations, thousands with 
> thousands), but are made up of random codepoints, which is nice.
> 
> 
> Thanks,
> 
> Galen O'Sullivan
> 
>

[jira] [Commented] (GEODE-2411) Remove references to Gemfire from include guards

[ASF GitHub Bot (JIRA)]

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

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

Github user PivotalSarge closed the pull request at:

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


> Remove references to Gemfire from include guards
> 
>
> Key: GEODE-2411
> URL: https://issues.apache.org/jira/browse/GEODE-2411
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> Many of the macro definitions used as include guards in the C++ header files 
> refer to Gemfire. These references should be replaced at least with 
> references to Geode but preferably using pragmas instead of defines.



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

[jira] [Commented] (GEODE-2411) Remove references to Gemfire from include guards

[ASF GitHub Bot (JIRA)]

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

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

Github user PivotalSarge commented on the issue:

https://github.com/apache/geode/pull/387
  
This closes #387.


> Remove references to Gemfire from include guards
> 
>
> Key: GEODE-2411
> URL: https://issues.apache.org/jira/browse/GEODE-2411
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> Many of the macro definitions used as include guards in the C++ header files 
> refer to Gemfire. These references should be replaced at least with 
> references to Geode but preferably using pragmas instead of defines.



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

[jira] [Commented] (GEODE-2422) Finish converting from GemFire to Geode in cppcache src

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2422:


Commit 04c534798395996183b80cda95c6f4f6af119490 in geode's branch 
refs/heads/next-gen-native-client-software-grant from [~mmartell]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=04c5347 ]

GEODE-2422: Switch remaining GemFire strings to Geode.

  - includes rename GemFireCache.hpp to GeodeCache.hpp
  - GemFire, Gemfire, and gemfire replaced with Geode, Geode, geode
  - includes only source changes: .cs, .cpp, and .hpp
  - doesn't include guard statement changes

This closes #391


> Finish converting from GemFire to Geode in cppcache src
> ---
>
> Key: GEODE-2422
> URL: https://issues.apache.org/jira/browse/GEODE-2422
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Michael Martell
>
> There are still some classes in the cppcache src that were not converted to 
> Geode from GemFire. For example, GemFireException.
> Also, change corresponding clicache source that uses these.



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

[jira] [Resolved] (GEODE-2422) Finish converting from GemFire to Geode in cppcache src

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-2422.
--
Resolution: Fixed

> Finish converting from GemFire to Geode in cppcache src
> ---
>
> Key: GEODE-2422
> URL: https://issues.apache.org/jira/browse/GEODE-2422
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Michael Martell
>
> There are still some classes in the cppcache src that were not converted to 
> Geode from GemFire. For example, GemFireException.
> Also, change corresponding clicache source that uses these.



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

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

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan updated GEODE-2295:

Component/s: locator

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



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

geode-native transition

[Anthony Baker]

We’ve made significant progress on the 'next-gen-native-client-software-grant’ 
branch.  Based on our prior discussions [1] I will push these changes over to 
the geode-native repo.  This means:

- Freezing the next-gen-native-client-software-grant branch in geode
- Pushing the next-gen-native-client-software-grant’ branch to 
geode-native:master
- Creating a geode-native:develop branch and doing future commits on this 
branch following our gitflow process
- PR’s would be created against geode-native instead of geode

I’ll send a heads up when this is complete.

Anthony

[1] 
http://mail-archives.apache.org/mod_mbox/geode-dev/201701.mbox/%3c062c99f5-f32e-4228-9e89-37aa6897f...@pivotal.io%3e

[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=15859927#comment-15859927
 ] 

ASF subversion and git services commented on GEODE-2398:


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

GEODE-2398: Retry oplog channel.write on silent failures

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


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

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

[Ken Howe]

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

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 
0b98364b743c39e69773d586f9c793eb7de71b8d 
  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

Build failed in Jenkins: Geode-nightly #743

[Apache Jenkins Server]

See 

Changes:

[gzhou] GEODE-2400: use a function to implement waitUntilFlushed, then accessor

--
[...truncated 5599 lines...]
:geode-cq:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

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

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

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

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

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:flakyTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources UP-TO-DATE
:geode-rebalancer:testClasses
:geode-rebalancer:checkMissedTests
:geode-rebalancer:spotlessJavaCheck
:geode-rebalancer:spotlessCheck
:geode-rebalancer:test
:geode-rebalancer:check
:geode-rebalancer:build
:geode-rebalancer:distributedTest
:geode-rebalancer:flakyTest
:geode-rebalancer:integrationTest
:geode-wan:assemble
:geode-wan:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-wan:processTestResources
:geode-wan:testClasses
:geode-wan:checkMissedTests
:geode-wan:spotlessJavaCheck
:geode-wan:spotlessCheck
:geode-wan:test
:geode-wan:check
:geode-wan:build
:geode-w

Nightly geode build still failing due to dist tx tests

[Kirk Lund]

The nightly build continues to fail with many dist tx test failures
involving cleanup of diskstores. Should we delete the dist tx tests since
we don't have dist tx in geode yet?

https://builds.apache.org/job/Geode-nightly/743/

[error 2017/02/09 11:20:30.602 UTC 
tid=0x600] Error cleaning disk dirs
java.lang.RuntimeException: Unable to delete BACKUPDiskStore file
at
org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.deleteBACKUPDiskStoreFile(JUnit4CacheTestCase.java:580)
at
org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.lambda$cleanDiskDirs$0(JUnit4CacheTestCase.java:572)
at
java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
at
java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
at
org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.cleanDiskDirs(JUnit4CacheTestCase.java:572)
at
org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.remoteTearDown(JUnit4CacheTestCase.java:422)
at
org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.lambda$tearDownCacheTestCase$bb17a952$1(JUnit4CacheTestCase.java:393)
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 hydra.MethExecutor.executeObject(MethExecutor.java:245)
at
org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:73)
at sun.reflect.GeneratedMethodAccessor361.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.nio.file.NoSuchFileException:
./BACKUPDiskStore-0-0-org.apache.geode.disttx.DistributedTransactionDUnitTest.testPutAllWithTransactions_1.krf
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at
sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
at
sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
at java.nio.file.Files.delete(Files.java:1126)
at org.apache.geode.internal.FileUtil.delete(FileUtil.java:166)
at
org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.deleteBACKUPDiskStoreFile(JUnit4CacheTestCase.java:578)
... 28 more

[GitHub] geode issue #391: GEODE-2422: Switch remaining GemFire strings to Geode.

[mmartell]

Github user mmartell commented on the issue:

https://github.com/apache/geode/pull/391
  
This closes #391.


---
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 #391: GEODE-2422: Switch remaining GemFire strings to Geo...

[mmartell]

Github user mmartell closed the pull request at:

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


---
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-2422) Finish converting from GemFire to Geode in cppcache src

[ASF GitHub Bot (JIRA)]

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

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

Github user mmartell commented on the issue:

https://github.com/apache/geode/pull/391
  
This closes #391.


> Finish converting from GemFire to Geode in cppcache src
> ---
>
> Key: GEODE-2422
> URL: https://issues.apache.org/jira/browse/GEODE-2422
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Michael Martell
>
> There are still some classes in the cppcache src that were not converted to 
> Geode from GemFire. For example, GemFireException.
> Also, change corresponding clicache source that uses these.



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

[jira] [Commented] (GEODE-2422) Finish converting from GemFire to Geode in cppcache src

[ASF GitHub Bot (JIRA)]

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

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

Github user mmartell closed the pull request at:

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


> Finish converting from GemFire to Geode in cppcache src
> ---
>
> Key: GEODE-2422
> URL: https://issues.apache.org/jira/browse/GEODE-2422
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Michael Martell
>
> There are still some classes in the cppcache src that were not converted to 
> Geode from GemFire. For example, GemFireException.
> Also, change corresponding clicache source that uses these.



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

Re: Nightly geode build still failing due to dist tx tests

[Bruce Schuchardt]

What concerns me about these failures is that it's iterating the 
contents of a directory to delete eache file one-by-one and is failing 
to find a file.  It's in JUnit4CacheTestCase tear-down code, not code 
specific to distributed transactions.


Le 2/9/2017 à 10:53 AM, Kirk Lund a écrit :

The nightly build continues to fail with many dist tx test failures
involving cleanup of diskstores. Should we delete the dist tx tests since
we don't have dist tx in geode yet?

https://builds.apache.org/job/Geode-nightly/743/

[error 2017/02/09 11:20:30.602 UTC 
tid=0x600] Error cleaning disk dirs
java.lang.RuntimeException: Unable to delete BACKUPDiskStore file
at
org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.deleteBACKUPDiskStoreFile(JUnit4CacheTestCase.java:580)
at
org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.lambda$cleanDiskDirs$0(JUnit4CacheTestCase.java:572)
at
java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
at
java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
at
org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.cleanDiskDirs(JUnit4CacheTestCase.java:572)
at
org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.remoteTearDown(JUnit4CacheTestCase.java:422)
at
org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.lambda$tearDownCacheTestCase$bb17a952$1(JUnit4CacheTestCase.java:393)
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 hydra.MethExecutor.executeObject(MethExecutor.java:245)
at
org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:73)
at sun.reflect.GeneratedMethodAccessor361.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.nio.file.NoSuchFileException:
./BACKUPDiskStore-0-0-org.apache.geode.disttx.DistributedTransactionDUnitTest.testPutAllWithTransactions_1.krf
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at
sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
at
sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
at java.nio.file.Files.delete(Files.java:1126)
at org.apache.geode.internal.FileUtil.delete(FileUtil.java:166)
at
org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.deleteBACKUPDiskStoreFile(JUnit4CacheTestCase.java:578)
... 28 more

Re: Review Request 56333: GEODE-2429 Fix a race that causes NPE in JtaAfterCompletionMessage.operateOnTx()

[Darrel Schneider]

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


Ship it!




Ship It!

- Darrel Schneider


On Feb. 8, 2017, 5:22 p.m., Eric Shu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56333/
> ---
> 
> (Updated Feb. 8, 2017, 5:22 p.m.)
> 
> 
> Review request for geode, anilkumar gingade and Darrel Schneider.
> 
> 
> Bugs: GEODE-2429
> https://issues.apache.org/jira/browse/GEODE-2429
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Do not run JTA afterCompletion on server if beforeCompletion is failed.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tx/ClientTXStateStub.java
>  e79324d 
>   geode-core/src/main/java/org/apache/geode/internal/jta/TransactionImpl.java 
> f36079a 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/ClientServerTransactionDUnitTest.java
>  270fbce 
> 
> Diff: https://reviews.apache.org/r/56333/diff/
> 
> 
> Testing
> ---
> 
> precheckin.
> 
> 
> Thanks,
> 
> Eric Shu
> 
>

Re: Nightly geode build still failing due to dist tx tests

[Darrel Schneider]

FileUtil.delete could be changed to handle NoSuchFileException on its last
line:

 public static void delete(File file) throws IOException {
if (!file.exists())
  return;
if (file.isDirectory()) {
  for (File child : listFiles(file)) {
delete(child);
  }
}
Files.delete(file.toPath());
  }


On Thu, Feb 9, 2017 at 1:08 PM, Kirk Lund  wrote:

> Here's the source of the exceptions in JUnit4CacheTestCase:
>
>   public static final void cleanDiskDirs() throws IOException {
> FileUtil.delete(getDiskDir());
> Arrays.stream(new File(".").listFiles()).forEach(file ->
> deleteBACKUPDiskStoreFile(file));
>   }
>
>   private static void deleteBACKUPDiskStoreFile(final File file) {
> if (file.getName().startsWith("BACKUPDiskStore-")) {
>   try {
> FileUtil.delete(file);
>   } catch (IOException e) {
> throw new RuntimeException("Unable to delete BACKUPDiskStore file",
> e);
>   }
> }
>   }
>
> There's probably an async thread either from tearDown or from the tests
> that's also deleting disk stores?
>
> On Thu, Feb 9, 2017 at 10:58 AM, Bruce Schuchardt 
> wrote:
>
> > What concerns me about these failures is that it's iterating the contents
> > of a directory to delete eache file one-by-one and is failing to find a
> > file.  It's in JUnit4CacheTestCase tear-down code, not code specific to
> > distributed transactions.
> >
> >
> > Le 2/9/2017 à 10:53 AM, Kirk Lund a écrit :
> >
> >> The nightly build continues to fail with many dist tx test failures
> >> involving cleanup of diskstores. Should we delete the dist tx tests
> since
> >> we don't have dist tx in geode yet?
> >>
> >> https://builds.apache.org/job/Geode-nightly/743/
> >>
> >> [error 2017/02/09 11:20:30.602 UTC  Connection(28)-67.195.81.139>
> >> tid=0x600] Error cleaning disk dirs
> >> java.lang.RuntimeException: Unable to delete BACKUPDiskStore file
> >> at
> >> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
> >> se.deleteBACKUPDiskStoreFile(JUnit4CacheTestCase.java:580)
> >> at
> >> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
> >> se.lambda$cleanDiskDirs$0(JUnit4CacheTestCase.java:572)
> >> at
> >> java.util.Spliterators$ArraySpliterator.forEachRemaining(
> >> Spliterators.java:948)
> >> at
> >> java.util.stream.ReferencePipeline$Head.forEach(
> >> ReferencePipeline.java:580)
> >> at
> >> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
> >> se.cleanDiskDirs(JUnit4CacheTestCase.java:572)
> >> at
> >> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
> >> se.remoteTearDown(JUnit4CacheTestCase.java:422)
> >> at
> >> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
> >> se.lambda$tearDownCacheTestCase$bb17a952$1(
> JUnit4CacheTestCase.java:393)
> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> at
> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> >> ssorImpl.java:62)
> >> at
> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> >> thodAccessorImpl.java:43)
> >> at java.lang.reflect.Method.invoke(Method.java:498)
> >> at hydra.MethExecutor.executeObject(MethExecutor.java:245)
> >> at
> >> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.execute
> >> MethodOnObject(RemoteDUnitVM.java:73)
> >> at sun.reflect.GeneratedMethodAccessor361.invoke(Unknown Source)
> >> at
> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> >> thodAccessorImpl.java:43)
> >> at java.lang.reflect.Method.invoke(Method.java:498)
> >> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
> >> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> >> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> >> at java.security.AccessController.doPrivileged(Native Method)
> >> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> >> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTranspo
> >> rt.java:568)
> >> at
> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TC
> >> PTransport.java:826)
> >> at
> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$
> >> run$0(TCPTransport.java:683)
> >> at java.security.AccessController.doPrivileged(Native Method)
> >> at
> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCP
> >> Transport.java:682)
> >> at
> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> >> Executor.java:1142)
> >> at
> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> >> lExecutor.java:617)
> >> at java.lang.Thread.run(Thread.java:745)
> >> Caused by: java.nio.file.NoSuchFileException:
> >> ./BACKUPDiskStore-0-0-org.apache.geode.disttx.DistributedTra
> >> nsactionDUnitTest.testPutAllWithTransactions_1.krf
> >> at sun.nio.fs.UnixException.translateToIOException(
> UnixException.java:86)
> >> at sun.nio.fs.UnixException.rethrowAsIOException(
> UnixException.java:102)
> >> at sun.nio.fs.UnixException.rethrowAsIOException(
> UnixException.java:107)
> >> at
> >> sun.

Re: Nightly geode build still failing due to dist tx tests

[Kirk Lund]

FileUtil.delete(File) is a no-op if the file doesn't exist. The IOException
must be thrown due to a race with another thread. Perhaps this utility
method needs to catch the IOException and then confirm that the file
doesn't exist. If the file still exists then go ahead and throw the
IOException.

  public static void delete(File file) throws IOException {
if (!file.exists())
  return;

if (file.isDirectory()) {
  for (File child : listFiles(file)) {
delete(child);
  }
}

Files.delete(file.toPath());
  }


On Thu, Feb 9, 2017 at 11:08 AM, Kirk Lund  wrote:

> Here's the source of the exceptions in JUnit4CacheTestCase:
>
>   public static final void cleanDiskDirs() throws IOException {
> FileUtil.delete(getDiskDir());
> Arrays.stream(new File(".").listFiles()).forEach(file ->
> deleteBACKUPDiskStoreFile(file));
>   }
>
>   private static void deleteBACKUPDiskStoreFile(final File file) {
> if (file.getName().startsWith("BACKUPDiskStore-")) {
>   try {
> FileUtil.delete(file);
>   } catch (IOException e) {
> throw new RuntimeException("Unable to delete BACKUPDiskStore
> file", e);
>   }
> }
>   }
>
> There's probably an async thread either from tearDown or from the tests
> that's also deleting disk stores?
>
> On Thu, Feb 9, 2017 at 10:58 AM, Bruce Schuchardt 
> wrote:
>
>> What concerns me about these failures is that it's iterating the contents
>> of a directory to delete eache file one-by-one and is failing to find a
>> file.  It's in JUnit4CacheTestCase tear-down code, not code specific to
>> distributed transactions.
>>
>>
>> Le 2/9/2017 à 10:53 AM, Kirk Lund a écrit :
>>
>>> The nightly build continues to fail with many dist tx test failures
>>> involving cleanup of diskstores. Should we delete the dist tx tests since
>>> we don't have dist tx in geode yet?
>>>
>>> https://builds.apache.org/job/Geode-nightly/743/
>>>
>>> [error 2017/02/09 11:20:30.602 UTC 
>>> tid=0x600] Error cleaning disk dirs
>>> java.lang.RuntimeException: Unable to delete BACKUPDiskStore file
>>> at
>>> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
>>> se.deleteBACKUPDiskStoreFile(JUnit4CacheTestCase.java:580)
>>> at
>>> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
>>> se.lambda$cleanDiskDirs$0(JUnit4CacheTestCase.java:572)
>>> at
>>> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spl
>>> iterators.java:948)
>>> at
>>> java.util.stream.ReferencePipeline$Head.forEach(ReferencePip
>>> eline.java:580)
>>> at
>>> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
>>> se.cleanDiskDirs(JUnit4CacheTestCase.java:572)
>>> at
>>> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
>>> se.remoteTearDown(JUnit4CacheTestCase.java:422)
>>> at
>>> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
>>> se.lambda$tearDownCacheTestCase$bb17a952$1(JUnit4CacheTestCase.java:393)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>>> ssorImpl.java:62)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>>> thodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>> at hydra.MethExecutor.executeObject(MethExecutor.java:245)
>>> at
>>> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.execute
>>> MethodOnObject(RemoteDUnitVM.java:73)
>>> at sun.reflect.GeneratedMethodAccessor361.invoke(Unknown Source)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>>> thodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
>>> at sun.rmi.transport.Transport$1.run(Transport.java:200)
>>> at sun.rmi.transport.Transport$1.run(Transport.java:197)
>>> at java.security.AccessController.doPrivileged(Native Method)
>>> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>>> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTranspo
>>> rt.java:568)
>>> at
>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TC
>>> PTransport.java:826)
>>> at
>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$
>>> run$0(TCPTransport.java:683)
>>> at java.security.AccessController.doPrivileged(Native Method)
>>> at
>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCP
>>> Transport.java:682)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>> Executor.java:1142)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>> lExecutor.java:617)
>>> at java.lang.Thread.run(Thread.java:745)
>>> Caused by: java.nio.file.NoSuchFileException:
>>> ./BACKUPDiskStore-0-0-org.apache.geode.disttx.DistributedTra
>>> nsactionDUnitTest.testPutAllWithTransactions_1.krf
>>> at sun.nio.fs.UnixException.translateToIOException(UnixExceptio
>>> n.java:86)
>>> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102

Re: Nightly geode build still failing due to dist tx tests

[Kirk Lund]

I'd prefer to delete org.apache.geode.internal.FileUtil and change code
that uses it to instead use org.apache.commons.io.FileUtils.


On Thu, Feb 9, 2017 at 11:10 AM, Darrel Schneider 
wrote:

> FileUtil.delete could be changed to handle NoSuchFileException on its last
> line:
>
>  public static void delete(File file) throws IOException {
> if (!file.exists())
>   return;
> if (file.isDirectory()) {
>   for (File child : listFiles(file)) {
> delete(child);
>   }
> }
> Files.delete(file.toPath());
>   }
>
>
> On Thu, Feb 9, 2017 at 1:08 PM, Kirk Lund  wrote:
>
> > Here's the source of the exceptions in JUnit4CacheTestCase:
> >
> >   public static final void cleanDiskDirs() throws IOException {
> > FileUtil.delete(getDiskDir());
> > Arrays.stream(new File(".").listFiles()).forEach(file ->
> > deleteBACKUPDiskStoreFile(file));
> >   }
> >
> >   private static void deleteBACKUPDiskStoreFile(final File file) {
> > if (file.getName().startsWith("BACKUPDiskStore-")) {
> >   try {
> > FileUtil.delete(file);
> >   } catch (IOException e) {
> > throw new RuntimeException("Unable to delete BACKUPDiskStore
> file",
> > e);
> >   }
> > }
> >   }
> >
> > There's probably an async thread either from tearDown or from the tests
> > that's also deleting disk stores?
> >
> > On Thu, Feb 9, 2017 at 10:58 AM, Bruce Schuchardt <
> bschucha...@pivotal.io>
> > wrote:
> >
> > > What concerns me about these failures is that it's iterating the
> contents
> > > of a directory to delete eache file one-by-one and is failing to find a
> > > file.  It's in JUnit4CacheTestCase tear-down code, not code specific to
> > > distributed transactions.
> > >
> > >
> > > Le 2/9/2017 à 10:53 AM, Kirk Lund a écrit :
> > >
> > >> The nightly build continues to fail with many dist tx test failures
> > >> involving cleanup of diskstores. Should we delete the dist tx tests
> > since
> > >> we don't have dist tx in geode yet?
> > >>
> > >> https://builds.apache.org/job/Geode-nightly/743/
> > >>
> > >> [error 2017/02/09 11:20:30.602 UTC  > Connection(28)-67.195.81.139>
> > >> tid=0x600] Error cleaning disk dirs
> > >> java.lang.RuntimeException: Unable to delete BACKUPDiskStore file
> > >> at
> > >> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
> > >> se.deleteBACKUPDiskStoreFile(JUnit4CacheTestCase.java:580)
> > >> at
> > >> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
> > >> se.lambda$cleanDiskDirs$0(JUnit4CacheTestCase.java:572)
> > >> at
> > >> java.util.Spliterators$ArraySpliterator.forEachRemaining(
> > >> Spliterators.java:948)
> > >> at
> > >> java.util.stream.ReferencePipeline$Head.forEach(
> > >> ReferencePipeline.java:580)
> > >> at
> > >> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
> > >> se.cleanDiskDirs(JUnit4CacheTestCase.java:572)
> > >> at
> > >> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
> > >> se.remoteTearDown(JUnit4CacheTestCase.java:422)
> > >> at
> > >> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
> > >> se.lambda$tearDownCacheTestCase$bb17a952$1(
> > JUnit4CacheTestCase.java:393)
> > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >> at
> > >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> > >> ssorImpl.java:62)
> > >> at
> > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> > >> thodAccessorImpl.java:43)
> > >> at java.lang.reflect.Method.invoke(Method.java:498)
> > >> at hydra.MethExecutor.executeObject(MethExecutor.java:245)
> > >> at
> > >> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.execute
> > >> MethodOnObject(RemoteDUnitVM.java:73)
> > >> at sun.reflect.GeneratedMethodAccessor361.invoke(Unknown Source)
> > >> at
> > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> > >> thodAccessorImpl.java:43)
> > >> at java.lang.reflect.Method.invoke(Method.java:498)
> > >> at sun.rmi.server.UnicastServerRef.dispatch(
> UnicastServerRef.java:324)
> > >> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> > >> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> > >> at java.security.AccessController.doPrivileged(Native Method)
> > >> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> > >> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTranspo
> > >> rt.java:568)
> > >> at
> > >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TC
> > >> PTransport.java:826)
> > >> at
> > >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$
> > >> run$0(TCPTransport.java:683)
> > >> at java.security.AccessController.doPrivileged(Native Method)
> > >> at
> > >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCP
> > >> Transport.java:682)
> > >> at
> > >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> > >> Executor.java:1142)
> > >> at
> > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> > >> lExecutor.java:617)
> > >> at 

Re: Nightly geode build still failing due to dist tx tests

[Kirk Lund]

Here's the source of the exceptions in JUnit4CacheTestCase:

  public static final void cleanDiskDirs() throws IOException {
FileUtil.delete(getDiskDir());
Arrays.stream(new File(".").listFiles()).forEach(file ->
deleteBACKUPDiskStoreFile(file));
  }

  private static void deleteBACKUPDiskStoreFile(final File file) {
if (file.getName().startsWith("BACKUPDiskStore-")) {
  try {
FileUtil.delete(file);
  } catch (IOException e) {
throw new RuntimeException("Unable to delete BACKUPDiskStore file",
e);
  }
}
  }

There's probably an async thread either from tearDown or from the tests
that's also deleting disk stores?

On Thu, Feb 9, 2017 at 10:58 AM, Bruce Schuchardt 
wrote:

> What concerns me about these failures is that it's iterating the contents
> of a directory to delete eache file one-by-one and is failing to find a
> file.  It's in JUnit4CacheTestCase tear-down code, not code specific to
> distributed transactions.
>
>
> Le 2/9/2017 à 10:53 AM, Kirk Lund a écrit :
>
>> The nightly build continues to fail with many dist tx test failures
>> involving cleanup of diskstores. Should we delete the dist tx tests since
>> we don't have dist tx in geode yet?
>>
>> https://builds.apache.org/job/Geode-nightly/743/
>>
>> [error 2017/02/09 11:20:30.602 UTC 
>> tid=0x600] Error cleaning disk dirs
>> java.lang.RuntimeException: Unable to delete BACKUPDiskStore file
>> at
>> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
>> se.deleteBACKUPDiskStoreFile(JUnit4CacheTestCase.java:580)
>> at
>> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
>> se.lambda$cleanDiskDirs$0(JUnit4CacheTestCase.java:572)
>> at
>> java.util.Spliterators$ArraySpliterator.forEachRemaining(
>> Spliterators.java:948)
>> at
>> java.util.stream.ReferencePipeline$Head.forEach(
>> ReferencePipeline.java:580)
>> at
>> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
>> se.cleanDiskDirs(JUnit4CacheTestCase.java:572)
>> at
>> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
>> se.remoteTearDown(JUnit4CacheTestCase.java:422)
>> at
>> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
>> se.lambda$tearDownCacheTestCase$bb17a952$1(JUnit4CacheTestCase.java:393)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> ssorImpl.java:62)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at hydra.MethExecutor.executeObject(MethExecutor.java:245)
>> at
>> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.execute
>> MethodOnObject(RemoteDUnitVM.java:73)
>> at sun.reflect.GeneratedMethodAccessor361.invoke(Unknown Source)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
>> at sun.rmi.transport.Transport$1.run(Transport.java:200)
>> at sun.rmi.transport.Transport$1.run(Transport.java:197)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTranspo
>> rt.java:568)
>> at
>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TC
>> PTransport.java:826)
>> at
>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$
>> run$0(TCPTransport.java:683)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at
>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCP
>> Transport.java:682)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1142)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:617)
>> at java.lang.Thread.run(Thread.java:745)
>> Caused by: java.nio.file.NoSuchFileException:
>> ./BACKUPDiskStore-0-0-org.apache.geode.disttx.DistributedTra
>> nsactionDUnitTest.testPutAllWithTransactions_1.krf
>> at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>> at
>> sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemP
>> rovider.java:244)
>> at
>> sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSys
>> temProvider.java:103)
>> at java.nio.file.Files.delete(Files.java:1126)
>> at org.apache.geode.internal.FileUtil.delete(FileUtil.java:166)
>> at
>> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCa
>> se.deleteBACKUPDiskStoreFile(JUnit4CacheTestCase.java:578)
>> ... 28 more
>>
>>
>

[jira] [Assigned] (GEODE-2455) DescribeDiskStoreFunctionJUnitTest will still pass when wrong line throws expected exception

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2455:


Assignee: Kirk Lund

> DescribeDiskStoreFunctionJUnitTest will still pass when wrong line throws 
> expected exception
> 
>
> Key: GEODE-2455
> URL: https://issues.apache.org/jira/browse/GEODE-2455
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The tests in DescribeDiskStoreFunctionJUnitTest are using the JUnit @Test 
> syntax expected exceptions. Unfortunately there are multiple lines within its 
> tests that can throw the expected exceptions. After seeing this occur and the 
> test passed, I decided to file this ticket to change the test to use 
> assertThatThrownBy from AssertJ.



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

[jira] [Created] (GEODE-2455) DescribeDiskStoreFunctionJUnitTest will still pass when wrong line throws expected exception

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2455:


 Summary: DescribeDiskStoreFunctionJUnitTest will still pass when 
wrong line throws expected exception
 Key: GEODE-2455
 URL: https://issues.apache.org/jira/browse/GEODE-2455
 Project: Geode
  Issue Type: Bug
  Components: tests
Reporter: Kirk Lund


The tests in DescribeDiskStoreFunctionJUnitTest are using the JUnit @Test 
syntax expected exceptions. Unfortunately there are multiple lines within its 
tests that can throw the expected exceptions. After seeing this occur and the 
test passed, I decided to file this ticket to change the test to use 
assertThatThrownBy from AssertJ.



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

[jira] [Assigned] (GEODE-2456) Distributed Transaction dunit tests are failing during tearDown

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2456:


Assignee: Kirk Lund

> Distributed Transaction dunit tests are failing during tearDown
> ---
>
> Key: GEODE-2456
> URL: https://issues.apache.org/jira/browse/GEODE-2456
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The Distributed Transaction dunit tests are failing during tearDown. It looks 
> like the JUnit tearDown thread and some other async thread are racing to 
> delete diskstore files.
> {noformat}
> Caused by: java.nio.file.NoSuchFileException: 
> ./BACKUPDiskStore-0-0-org.apache.geode.disttx.DistributedTransactionDUnitTest.testPutAllWithTransactions_1.krf
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
>   at 
> sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
>   at java.nio.file.Files.delete(Files.java:1126)
>   at org.apache.geode.internal.FileUtil.delete(FileUtil.java:166)
>   at 
> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.deleteBACKUPDiskStoreFile(JUnit4CacheTestCase.java:578)
>   ... 28 more
> {noformat}
> Recommended changes:
> * change from using org.apache.geode.internal.FileUtil to 
> org.apache.commons.io.FileUtils
> * make sure distributed transaction dunit tests aren't leaving orphaned 
> threads running after test completes



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

[jira] [Created] (GEODE-2456) Distributed Transaction dunit tests are failing during tearDown

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2456:


 Summary: Distributed Transaction dunit tests are failing during 
tearDown
 Key: GEODE-2456
 URL: https://issues.apache.org/jira/browse/GEODE-2456
 Project: Geode
  Issue Type: Bug
  Components: tests
Reporter: Kirk Lund


The Distributed Transaction dunit tests are failing during tearDown. It looks 
like the JUnit tearDown thread and some other async thread are racing to delete 
diskstore files.
{noformat}
Caused by: java.nio.file.NoSuchFileException: 
./BACKUPDiskStore-0-0-org.apache.geode.disttx.DistributedTransactionDUnitTest.testPutAllWithTransactions_1.krf
at 
sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at 
sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
at 
sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
at java.nio.file.Files.delete(Files.java:1126)
at org.apache.geode.internal.FileUtil.delete(FileUtil.java:166)
at 
org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.deleteBACKUPDiskStoreFile(JUnit4CacheTestCase.java:578)
... 28 more
{noformat}
Recommended changes:
* change from using org.apache.geode.internal.FileUtil to 
org.apache.commons.io.FileUtils
* make sure distributed transaction dunit tests aren't leaving orphaned threads 
running after test completes




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

Review Request 56514: GEODE-2455: change test to use AssertJ assertThatThrownBy

[Kirk Lund]

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

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


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


Repository: geode


Description
---

GEODE-2455: change test to use AssertJ assertThatThrownBy


Diffs
-

  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/DescribeDiskStoreFunctionJUnitTest.java
 469fab8 

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


Testing
---

DescribeDiskStoreFunctionJUnitTest


Thanks,

Kirk Lund

Re: Review Request 56514: GEODE-2455: change test to use AssertJ assertThatThrownBy

[Kirk Lund]

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

(Updated Feb. 9, 2017, 7:46 p.m.)


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


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


Repository: geode


Description (updated)
---

GEODE-2455: change test to use AssertJ assertThatThrownBy

enter random text to allow review board publish to work


Diffs
-

  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/DescribeDiskStoreFunctionJUnitTest.java
 469fab8 

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


Testing
---

DescribeDiskStoreFunctionJUnitTest


Thanks,

Kirk Lund

Re: Review Request 56514: GEODE-2455: change test to use AssertJ assertThatThrownBy

[Kevin Duling]

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


Ship it!




Ship It!

- Kevin Duling


On Feb. 9, 2017, 11:44 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56514/
> ---
> 
> (Updated Feb. 9, 2017, 11:44 a.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, and Kevin Duling.
> 
> 
> Bugs: GEODE-2455
> https://issues.apache.org/jira/browse/GEODE-2455
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2455: change test to use AssertJ assertThatThrownBy
> 
> enter random text to allow review board publish to work
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/DescribeDiskStoreFunctionJUnitTest.java
>  469fab8 
> 
> Diff: https://reviews.apache.org/r/56514/diff/
> 
> 
> Testing
> ---
> 
> DescribeDiskStoreFunctionJUnitTest
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

[jira] [Commented] (GEODE-2455) DescribeDiskStoreFunctionJUnitTest will still pass when wrong line throws expected exception

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2455:


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

GEODE-2455: change test to use AssertJ assertThatThrownBy


> DescribeDiskStoreFunctionJUnitTest will still pass when wrong line throws 
> expected exception
> 
>
> Key: GEODE-2455
> URL: https://issues.apache.org/jira/browse/GEODE-2455
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The tests in DescribeDiskStoreFunctionJUnitTest are using the JUnit @Test 
> syntax expected exceptions. Unfortunately there are multiple lines within its 
> tests that can throw the expected exceptions. After seeing this occur and the 
> test passed, I decided to file this ticket to change the test to use 
> assertThatThrownBy from AssertJ.



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

[jira] [Resolved] (GEODE-2455) DescribeDiskStoreFunctionJUnitTest will still pass when wrong line throws expected exception

[Kirk Lund (JIRA)]

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

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

> DescribeDiskStoreFunctionJUnitTest will still pass when wrong line throws 
> expected exception
> 
>
> Key: GEODE-2455
> URL: https://issues.apache.org/jira/browse/GEODE-2455
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
> Fix For: 1.2.0
>
>
> The tests in DescribeDiskStoreFunctionJUnitTest are using the JUnit @Test 
> syntax expected exceptions. Unfortunately there are multiple lines within its 
> tests that can throw the expected exceptions. After seeing this occur and the 
> test passed, I decided to file this ticket to change the test to use 
> assertThatThrownBy from AssertJ.



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

Removal of distributed transaction tests

[Kirk Lund]

Do we really want our nightly build and precheckin runs to waste time
running these tests?

DistributedTransactionDUnitTest
DistTXDebugDUnitTest
DistTXOrderDUnitTest
DistTXPersistentDebugDUnitTest
DistTXRestrictionsDUnitTest
DistTXWithDeltaDUnitTest
DistributedTransactionDUnitTest
PRDistTXDUnitTest
PRDistTXWithVersionsDUnitTest

There are also quite a few non-dunit tests for distributed transactions.

-Kirk

[jira] [Commented] (GEODE-2456) Distributed Transaction dunit tests are failing during tearDown

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2456:


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

GEODE-2456: change JUnit4CacheTestCase tearDown to use deleteQuietly


> Distributed Transaction dunit tests are failing during tearDown
> ---
>
> Key: GEODE-2456
> URL: https://issues.apache.org/jira/browse/GEODE-2456
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The Distributed Transaction dunit tests are failing during tearDown. It looks 
> like the JUnit tearDown thread and some other async thread are racing to 
> delete diskstore files.
> {noformat}
> Caused by: java.nio.file.NoSuchFileException: 
> ./BACKUPDiskStore-0-0-org.apache.geode.disttx.DistributedTransactionDUnitTest.testPutAllWithTransactions_1.krf
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
>   at 
> sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
>   at java.nio.file.Files.delete(Files.java:1126)
>   at org.apache.geode.internal.FileUtil.delete(FileUtil.java:166)
>   at 
> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.deleteBACKUPDiskStoreFile(JUnit4CacheTestCase.java:578)
>   ... 28 more
> {noformat}
> Recommended changes:
> * change from using org.apache.geode.internal.FileUtil to 
> org.apache.commons.io.FileUtils
> * make sure distributed transaction dunit tests aren't leaving orphaned 
> threads running after test completes



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

Re: Removal of distributed transaction tests

[Dan Smith]

What's wrong with these tests? Are you saying there is coverage elsewhere?

-Dan

On Thu, Feb 9, 2017 at 12:02 PM, Kirk Lund  wrote:

> Do we really want our nightly build and precheckin runs to waste time
> running these tests?
>
> DistributedTransactionDUnitTest
> DistTXDebugDUnitTest
> DistTXOrderDUnitTest
> DistTXPersistentDebugDUnitTest
> DistTXRestrictionsDUnitTest
> DistTXWithDeltaDUnitTest
> DistributedTransactionDUnitTest
> PRDistTXDUnitTest
> PRDistTXWithVersionsDUnitTest
>
> There are also quite a few non-dunit tests for distributed transactions.
>
> -Kirk
>

Review Request 56516: GEODE-2456: change JUnit4CacheTestCase tearDown to use deleteQuietly

[Kirk Lund]

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

Review request for geode, Darrel Schneider, Eric Shu, Jinmei Liao, Jared 
Stewart, Kevin Duling, and Ken Howe.


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


Repository: geode


Description
---

GEODE-2456: change JUnit4CacheTestCase tearDown to use deleteQuietly

Change from use of org.apache.geode.internal.FileUtil.delete(File) to 
org.apache.commons.io.FileUtils.deleteQuietly(File)


Diffs
-

  
geode-core/src/test/java/org/apache/geode/test/dunit/cache/internal/JUnit4CacheTestCase.java
 a511995 

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


Testing
---

DistributedTransactionDUnitTest
DistTXDebugDUnitTest
DistTXOrderDUnitTest
DistTXPersistentDebugDUnitTest
DistTXRestrictionsDUnitTest
DistTXWithDeltaDUnitTest
DistributedTransactionDUnitTest
PRDistTXDUnitTest
PRDistTXWithVersionsDUnitTest

full precheckin in progress


Thanks,

Kirk Lund

Re: Review Request 56516: GEODE-2456: change JUnit4CacheTestCase tearDown to use deleteQuietly

[Kevin Duling]

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


Ship it!




Ship It!

- Kevin Duling


On Feb. 9, 2017, 12:06 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56516/
> ---
> 
> (Updated Feb. 9, 2017, 12:06 p.m.)
> 
> 
> Review request for geode, Darrel Schneider, Eric Shu, Jinmei Liao, Jared 
> Stewart, Kevin Duling, and Ken Howe.
> 
> 
> Bugs: GEODE-2456
> https://issues.apache.org/jira/browse/GEODE-2456
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2456: change JUnit4CacheTestCase tearDown to use deleteQuietly
> 
> Change from use of org.apache.geode.internal.FileUtil.delete(File) to 
> org.apache.commons.io.FileUtils.deleteQuietly(File)
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/cache/internal/JUnit4CacheTestCase.java
>  a511995 
> 
> Diff: https://reviews.apache.org/r/56516/diff/
> 
> 
> Testing
> ---
> 
> DistributedTransactionDUnitTest
> DistTXDebugDUnitTest
> DistTXOrderDUnitTest
> DistTXPersistentDebugDUnitTest
> DistTXRestrictionsDUnitTest
> DistTXWithDeltaDUnitTest
> DistributedTransactionDUnitTest
> PRDistTXDUnitTest
> PRDistTXWithVersionsDUnitTest
> 
> full precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

[jira] [Assigned] (GEODE-2457) Replace org.apache.geode.internal.FileUtil with org.apache.commons.io.FileUtils

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2457:


Assignee: Kirk Lund

> Replace org.apache.geode.internal.FileUtil with 
> org.apache.commons.io.FileUtils
> ---
>
> Key: GEODE-2457
> URL: https://issues.apache.org/jira/browse/GEODE-2457
> Project: Geode
>  Issue Type: Wish
>  Components: general
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Replace use of org.apache.geode.internal.FileUtil with 
> org.apache.commons.io.FileUtils.
> Delete org.apache.geode.internal.FileUtil.



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

[jira] [Created] (GEODE-2457) Replace org.apache.geode.internal.FileUtil with org.apache.commons.io.FileUtils

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2457:


 Summary: Replace org.apache.geode.internal.FileUtil with 
org.apache.commons.io.FileUtils
 Key: GEODE-2457
 URL: https://issues.apache.org/jira/browse/GEODE-2457
 Project: Geode
  Issue Type: Wish
  Components: general
Reporter: Kirk Lund


Replace use of org.apache.geode.internal.FileUtil with 
org.apache.commons.io.FileUtils.

Delete org.apache.geode.internal.FileUtil.




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

[jira] [Updated] (GEODE-1964) Add docs for native client to native client repo

[Dave Barnes (JIRA)]

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

Dave Barnes updated GEODE-1964:
---
Summary: Add docs for native client to native client repo  (was: Add docs 
for native client to develop branch)

> Add docs for native client to native client repo
> 
>
> Key: GEODE-1964
> URL: https://issues.apache.org/jira/browse/GEODE-1964
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> After the native client code has been merged to develop, the documentation 
> should follow. This subtask allows us to 'park' the existing docs on a 
> feature branch until they're needed.



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

[jira] [Commented] (GEODE-1964) Add docs for native client to native client repo

[Dave Barnes (JIRA)]

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

Dave Barnes commented on GEODE-1964:


Changed title: "add to develop branch" => "add to native client repo".


> Add docs for native client to native client repo
> 
>
> Key: GEODE-1964
> URL: https://issues.apache.org/jira/browse/GEODE-1964
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> After the native client code has been merged to develop, the documentation 
> should follow. This subtask allows us to 'park' the existing docs on a 
> feature branch until they're needed.



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

Re: Review Request 56514: GEODE-2455: change test to use AssertJ assertThatThrownBy

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On Feb. 9, 2017, 7:46 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56514/
> ---
> 
> (Updated Feb. 9, 2017, 7:46 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, and Kevin Duling.
> 
> 
> Bugs: GEODE-2455
> https://issues.apache.org/jira/browse/GEODE-2455
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2455: change test to use AssertJ assertThatThrownBy
> 
> enter random text to allow review board publish to work
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/DescribeDiskStoreFunctionJUnitTest.java
>  469fab8 
> 
> Diff: https://reviews.apache.org/r/56514/diff/
> 
> 
> Testing
> ---
> 
> DescribeDiskStoreFunctionJUnitTest
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 56516: GEODE-2456: change JUnit4CacheTestCase tearDown to use deleteQuietly

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On Feb. 9, 2017, 8:06 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56516/
> ---
> 
> (Updated Feb. 9, 2017, 8:06 p.m.)
> 
> 
> Review request for geode, Darrel Schneider, Eric Shu, Jinmei Liao, Jared 
> Stewart, Kevin Duling, and Ken Howe.
> 
> 
> Bugs: GEODE-2456
> https://issues.apache.org/jira/browse/GEODE-2456
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2456: change JUnit4CacheTestCase tearDown to use deleteQuietly
> 
> Change from use of org.apache.geode.internal.FileUtil.delete(File) to 
> org.apache.commons.io.FileUtils.deleteQuietly(File)
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/cache/internal/JUnit4CacheTestCase.java
>  a511995 
> 
> Diff: https://reviews.apache.org/r/56516/diff/
> 
> 
> Testing
> ---
> 
> DistributedTransactionDUnitTest
> DistTXDebugDUnitTest
> DistTXOrderDUnitTest
> DistTXPersistentDebugDUnitTest
> DistTXRestrictionsDUnitTest
> DistTXWithDeltaDUnitTest
> DistributedTransactionDUnitTest
> PRDistTXDUnitTest
> PRDistTXWithVersionsDUnitTest
> 
> full precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 56459: GEODE-2247: GFSH connect over HTTP without credentials should fail earlier

[Kevin Duling]

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

(Updated Feb. 9, 2017, 12:50 p.m.)


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


Changes
---

Removed change to ping time.


Repository: geode


Description
---

GEODE-2247: GFSH connect over HTTP without credentials should fail earlier


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
 6507295cd28b5f45f4de164c86c176f467a20f6e 
  
geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
 727a1ce0c1c99edd5cd7299ddfbbcda4ca9a664f 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/support/LoginHandlerInterceptor.java
 79c8c2717b3523837f01939cf67b3b38169c856b 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/auth/AbstractGMSAuthenticatorTestCase.java
 65c38ad261ba759d5022fad4c1eb20249e71d69d 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/IntegratedSecurityServiceWithIniFileJUnitTest.java
 a300880d1d4a221d03c480df94b5b652175814f7 
  
geode-web-api/src/main/java/org/apache/geode/rest/internal/web/security/GeodeAuthenticationProvider.java
 c8b5cf0827032ae3148bfdeb1777fb8fc3b2d85e 

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


Testing (updated)
---

Log of UX on https://issues.apache.org/jira/browse/GEODE-2247
precheckin successful


Thanks,

Kevin Duling

Re: geode-native transition

[Anthony Baker]

This is complete.  Thanks to the INFRA team, both geode-examples and 
geode-native are setup to integrate with GitHub, Travis CI, and JIRA (this is 
in progress).  If you see anything missing, please let the community know.

Anthony


> On Feb 9, 2017, at 10:05 AM, Anthony Baker  wrote:
> 
> We’ve made significant progress on the 
> 'next-gen-native-client-software-grant’ branch.  Based on our prior 
> discussions [1] I will push these changes over to the geode-native repo.  
> This means:
> 
> - Freezing the next-gen-native-client-software-grant branch in geode
> - Pushing the next-gen-native-client-software-grant’ branch to 
> geode-native:master
> - Creating a geode-native:develop branch and doing future commits on this 
> branch following our gitflow process
> - PR’s would be created against geode-native instead of geode
> 
> I’ll send a heads up when this is complete.
> 
> Anthony
> 
> [1] 
> http://mail-archives.apache.org/mod_mbox/geode-dev/201701.mbox/%3c062c99f5-f32e-4228-9e89-37aa6897f...@pivotal.io%3e
> 

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

[Hitesh Khamesra]

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] [Commented] (GEODE-2247) GFSH connect over HTTP without credentials should fail earlier

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2247:


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

GEODE-2247: GFSH connect over HTTP without credentials should fail earlier


> GFSH connect over HTTP without credentials should fail earlier
> --
>
> Key: GEODE-2247
> URL: https://issues.apache.org/jira/browse/GEODE-2247
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, rest (admin), security
>Affects Versions: 1.0.0-incubating
>Reporter: Ben Moss
>Assignee: Kevin Duling
>Priority: Minor
>  Labels: HttpService, gfsh, security
> Fix For: 1.2.0
>
>
> With a SecurityManager configured and using GFSH over http, issuing a 
> {{connect}} command without {{--user}} or {{--password}} will appear to 
> succeed, responding with {{Successfully connected to: GemFire Manager HTTP 
> service}}. However if you then try to do anything in this session you will 
> get an error {{Could not process command due to GemFire error. Error while 
> processing command  Reason : Error: Anonymous User}}.
> It seems like it should fail on the {{connect}}.



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

Re: Removal of distributed transaction tests

[Kirk Lund]

My reasoning is simple: Apache Geode does not currently have a distributed
transactions feature.


On Thu, Feb 9, 2017 at 12:03 PM, Dan Smith  wrote:

> What's wrong with these tests? Are you saying there is coverage elsewhere?
>
> -Dan
>
> On Thu, Feb 9, 2017 at 12:02 PM, Kirk Lund  wrote:
>
> > Do we really want our nightly build and precheckin runs to waste time
> > running these tests?
> >
> > DistributedTransactionDUnitTest
> > DistTXDebugDUnitTest
> > DistTXOrderDUnitTest
> > DistTXPersistentDebugDUnitTest
> > DistTXRestrictionsDUnitTest
> > DistTXWithDeltaDUnitTest
> > DistributedTransactionDUnitTest
> > PRDistTXDUnitTest
> > PRDistTXWithVersionsDUnitTest
> >
> > There are also quite a few non-dunit tests for distributed transactions.
> >
> > -Kirk
> >
>

Re: Removal of distributed transaction tests

[Swapnil Bawaskar]

Implementation for distributed transactions was started but has not been
completed yet. The tests may only be testing what has been implemented so
far, so I would vote not to remove these tests.
On Thu, Feb 9, 2017 at 1:57 PM Kirk Lund  wrote:

> My reasoning is simple: Apache Geode does not currently have a distributed
> transactions feature.
>
>
> On Thu, Feb 9, 2017 at 12:03 PM, Dan Smith  wrote:
>
> > What's wrong with these tests? Are you saying there is coverage
> elsewhere?
> >
> > -Dan
> >
> > On Thu, Feb 9, 2017 at 12:02 PM, Kirk Lund  wrote:
> >
> > > Do we really want our nightly build and precheckin runs to waste time
> > > running these tests?
> > >
> > > DistributedTransactionDUnitTest
> > > DistTXDebugDUnitTest
> > > DistTXOrderDUnitTest
> > > DistTXPersistentDebugDUnitTest
> > > DistTXRestrictionsDUnitTest
> > > DistTXWithDeltaDUnitTest
> > > DistributedTransactionDUnitTest
> > > PRDistTXDUnitTest
> > > PRDistTXWithVersionsDUnitTest
> > >
> > > There are also quite a few non-dunit tests for distributed
> transactions.
> > >
> > > -Kirk
> > >
> >
>

Re: Removal of distributed transaction tests

[Kirk Lund]

If we think we'll eventually finish the feature then that sounds good.


On Thu, Feb 9, 2017 at 2:01 PM, Swapnil Bawaskar 
wrote:

> Implementation for distributed transactions was started but has not been
> completed yet. The tests may only be testing what has been implemented so
> far, so I would vote not to remove these tests.
> On Thu, Feb 9, 2017 at 1:57 PM Kirk Lund  wrote:
>
> > My reasoning is simple: Apache Geode does not currently have a
> distributed
> > transactions feature.
> >
> >
> > On Thu, Feb 9, 2017 at 12:03 PM, Dan Smith  wrote:
> >
> > > What's wrong with these tests? Are you saying there is coverage
> > elsewhere?
> > >
> > > -Dan
> > >
> > > On Thu, Feb 9, 2017 at 12:02 PM, Kirk Lund  wrote:
> > >
> > > > Do we really want our nightly build and precheckin runs to waste time
> > > > running these tests?
> > > >
> > > > DistributedTransactionDUnitTest
> > > > DistTXDebugDUnitTest
> > > > DistTXOrderDUnitTest
> > > > DistTXPersistentDebugDUnitTest
> > > > DistTXRestrictionsDUnitTest
> > > > DistTXWithDeltaDUnitTest
> > > > DistributedTransactionDUnitTest
> > > > PRDistTXDUnitTest
> > > > PRDistTXWithVersionsDUnitTest
> > > >
> > > > There are also quite a few non-dunit tests for distributed
> > transactions.
> > > >
> > > > -Kirk
> > > >
> > >
> >
>

[jira] [Commented] (GEODE-2456) Distributed Transaction dunit tests are failing during tearDown

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2456:


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

GEODE-2456: change JUnit4CacheTestCase tearDown to use deleteQuietly


> Distributed Transaction dunit tests are failing during tearDown
> ---
>
> Key: GEODE-2456
> URL: https://issues.apache.org/jira/browse/GEODE-2456
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The Distributed Transaction dunit tests are failing during tearDown. It looks 
> like the JUnit tearDown thread and some other async thread are racing to 
> delete diskstore files.
> {noformat}
> Caused by: java.nio.file.NoSuchFileException: 
> ./BACKUPDiskStore-0-0-org.apache.geode.disttx.DistributedTransactionDUnitTest.testPutAllWithTransactions_1.krf
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
>   at 
> sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
>   at java.nio.file.Files.delete(Files.java:1126)
>   at org.apache.geode.internal.FileUtil.delete(FileUtil.java:166)
>   at 
> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.deleteBACKUPDiskStoreFile(JUnit4CacheTestCase.java:578)
>   ... 28 more
> {noformat}
> Recommended changes:
> * change from using org.apache.geode.internal.FileUtil to 
> org.apache.commons.io.FileUtils
> * make sure distributed transaction dunit tests aren't leaving orphaned 
> threads running after test completes



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

[jira] [Commented] (GEODE-2247) GFSH connect over HTTP without credentials should fail earlier

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2247:


Commit 30341ec154b0d073dbca497cae110508f9480be1 in geode's branch 
refs/heads/feature/GEODE-2456 from [~kduling]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=30341ec ]

GEODE-2247: GFSH connect over HTTP without credentials should fail earlier


> GFSH connect over HTTP without credentials should fail earlier
> --
>
> Key: GEODE-2247
> URL: https://issues.apache.org/jira/browse/GEODE-2247
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, rest (admin), security
>Affects Versions: 1.0.0-incubating
>Reporter: Ben Moss
>Assignee: Kevin Duling
>Priority: Minor
>  Labels: HttpService, gfsh, security
> Fix For: 1.2.0
>
>
> With a SecurityManager configured and using GFSH over http, issuing a 
> {{connect}} command without {{--user}} or {{--password}} will appear to 
> succeed, responding with {{Successfully connected to: GemFire Manager HTTP 
> service}}. However if you then try to do anything in this session you will 
> get an error {{Could not process command due to GemFire error. Error while 
> processing command  Reason : Error: Anonymous User}}.
> It seems like it should fail on the {{connect}}.



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

[jira] [Commented] (GEODE-2324) If AcceptorImpl is interrupted during shutdown, it does not clean up properly.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2324:


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

[GEODE-2324] Make AcceptorImplObserver an interface

and fix threading issues.


> If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
> --
>
> Key: GEODE-2324
> URL: https://issues.apache.org/jira/browse/GEODE-2324
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.0.0-incubating
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> In {{AcceptorImpl.close()}}, the call to 
> {{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT, 
> TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which 
> case neither {pool} nor {{hsPool}} or anything else that comes after is 
> properly closed and an error message is logged.
> I believe that the thread will be interrupted if a shutdown command is issued 
> (for example, through gfsh), though I haven't created a reproduction yet.



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

[jira] [Commented] (GEODE-2324) If AcceptorImpl is interrupted during shutdown, it does not clean up properly.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2324:


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

[GEODE-2324] keep private variables private.

* Update AcceptorImplDUnit test,
* Refactor AcceptorImpl.close into multiple methods.
* Remove a commented-out method.


> If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
> --
>
> Key: GEODE-2324
> URL: https://issues.apache.org/jira/browse/GEODE-2324
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.0.0-incubating
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> In {{AcceptorImpl.close()}}, the call to 
> {{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT, 
> TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which 
> case neither {pool} nor {{hsPool}} or anything else that comes after is 
> properly closed and an error message is logged.
> I believe that the thread will be interrupted if a shutdown command is issued 
> (for example, through gfsh), though I haven't created a reproduction yet.



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

[jira] [Commented] (GEODE-2324) If AcceptorImpl is interrupted during shutdown, it does not clean up properly.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2324:


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

[GEODE-2324] Update isShutdownProperly method.


> If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
> --
>
> Key: GEODE-2324
> URL: https://issues.apache.org/jira/browse/GEODE-2324
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.0.0-incubating
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> In {{AcceptorImpl.close()}}, the call to 
> {{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT, 
> TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which 
> case neither {pool} nor {{hsPool}} or anything else that comes after is 
> properly closed and an error message is logged.
> I believe that the thread will be interrupted if a shutdown command is issued 
> (for example, through gfsh), though I haven't created a reproduction yet.



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

[jira] [Commented] (GEODE-2324) If AcceptorImpl is interrupted during shutdown, it does not clean up properly.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2324:


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

[GEODE-2324] fixes to AcceptorImpl.close()

If the thread is interrupted during closing, just continue to shut down
what we can.

* Catch InterruptedException so cleanup continues.
* Remove top-level exception handler to avoid masking exceptions that
* could short-circuit shutdown.
* Fix a synchronization bug that could cause AcceptorImpl to try to shut
  down twice.
* Fix what looks like a bug where if closing the socket throws an
  IOException, we fail to shut anything else down, though we still have
  ourselves marked as shut down.


> If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
> --
>
> Key: GEODE-2324
> URL: https://issues.apache.org/jira/browse/GEODE-2324
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.0.0-incubating
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> In {{AcceptorImpl.close()}}, the call to 
> {{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT, 
> TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which 
> case neither {pool} nor {{hsPool}} or anything else that comes after is 
> properly closed and an error message is logged.
> I believe that the thread will be interrupted if a shutdown command is issued 
> (for example, through gfsh), though I haven't created a reproduction yet.



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

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

[Eric Shu]

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

[jira] [Commented] (GEODE-2324) If AcceptorImpl is interrupted during shutdown, it does not clean up properly.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2324:


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

[GEODE-2324] Dunit test for AcceptorImpl.close()

* Add AcceptorImplObserver
* Add AccceptorImplDunitTest


> If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
> --
>
> Key: GEODE-2324
> URL: https://issues.apache.org/jira/browse/GEODE-2324
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.0.0-incubating
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> In {{AcceptorImpl.close()}}, the call to 
> {{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT, 
> TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which 
> case neither {pool} nor {{hsPool}} or anything else that comes after is 
> properly closed and an error message is logged.
> I believe that the thread will be interrupted if a shutdown command is issued 
> (for example, through gfsh), though I haven't created a reproduction yet.



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

[jira] [Commented] (GEODE-2324) If AcceptorImpl is interrupted during shutdown, it does not clean up properly.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2324:


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

[GEODE-2324] Re-interrupt after catching InterruptedException.


> If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
> --
>
> Key: GEODE-2324
> URL: https://issues.apache.org/jira/browse/GEODE-2324
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.0.0-incubating
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> In {{AcceptorImpl.close()}}, the call to 
> {{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT, 
> TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which 
> case neither {pool} nor {{hsPool}} or anything else that comes after is 
> properly closed and an error message is logged.
> I believe that the thread will be interrupted if a shutdown command is issued 
> (for example, through gfsh), though I haven't created a reproduction yet.



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

Re: Review Request 56459: GEODE-2247: GFSH connect over HTTP without credentials should fail earlier

[Kirk Lund]

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


Ship it!




Ship It!

- Kirk Lund


On Feb. 9, 2017, 8:50 p.m., Kevin Duling wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56459/
> ---
> 
> (Updated Feb. 9, 2017, 8:50 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2247: GFSH connect over HTTP without credentials should fail earlier
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  6507295cd28b5f45f4de164c86c176f467a20f6e 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
>  727a1ce0c1c99edd5cd7299ddfbbcda4ca9a664f 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/support/LoginHandlerInterceptor.java
>  79c8c2717b3523837f01939cf67b3b38169c856b 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/auth/AbstractGMSAuthenticatorTestCase.java
>  65c38ad261ba759d5022fad4c1eb20249e71d69d 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/IntegratedSecurityServiceWithIniFileJUnitTest.java
>  a300880d1d4a221d03c480df94b5b652175814f7 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/security/GeodeAuthenticationProvider.java
>  c8b5cf0827032ae3148bfdeb1777fb8fc3b2d85e 
> 
> Diff: https://reviews.apache.org/r/56459/diff/
> 
> 
> Testing
> ---
> 
> Log of UX on https://issues.apache.org/jira/browse/GEODE-2247
> precheckin successful
> 
> 
> Thanks,
> 
> Kevin Duling
> 
>

[jira] [Commented] (GEODE-2324) If AcceptorImpl is interrupted during shutdown, it does not clean up properly.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2324:


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

[GEODE-2324] Reinstate Exception catching for RuntimeException

so we gain the benefits of logging unchecked exceptions without losing
the type system benefits of having to catch exceptions.


> If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
> --
>
> Key: GEODE-2324
> URL: https://issues.apache.org/jira/browse/GEODE-2324
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.0.0-incubating
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> In {{AcceptorImpl.close()}}, the call to 
> {{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT, 
> TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which 
> case neither {pool} nor {{hsPool}} or anything else that comes after is 
> properly closed and an error message is logged.
> I believe that the thread will be interrupted if a shutdown command is issued 
> (for example, through gfsh), though I haven't created a reproduction yet.



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

Nightly geode failure due to DNS

[Kirk Lund]

Any opinions on this failure? I'm not sure if we should change the test,
change our use of host name lookup or blacklist asf91 from our nightly
build.

org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer

org.junit.ComparisonFailure:
expected:<[67.195.81.13]9(2651):327...> but
was:<[asf91]9(2651):327...>
at org.junit.Assert.assertEquals(Assert.java:115)
at org.junit.Assert.assertEquals(Assert.java:144)
at
org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.doTestSystemClientEventsInServer(UniversalMembershipListenerAdapterDUnitTest.java:946)
at
org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer(UniversalMembershipListenerAdapterDUnitTest.java:731)

WaitUntilParallelGatewaySenderFlushedCoordinatorJUnitTest

[Kirk Lund]

Does anyone want to look into this geode nightly build failure involving
WaitUntilParallelGatewaySenderFlushedCoordinatorJUnitTest?

java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertFalse(Assert.java:64)
at org.junit.Assert.assertFalse(Assert.java:74)
at
org.apache.geode.internal.cache.wan.parallel.WaitUntilParallelGatewaySenderFlushedCoordinatorJUnitTest.testWaitUntilParallelGatewaySenderFlushedUnsuccessfulInitiator(WaitUntilParallelGatewaySenderFlushedCoordinatorJUnitTest.java:102)

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2295:


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

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

remove final to be consistent.


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



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

[jira] [Closed] (GEODE-2135) Doc update of schema location

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2135.
--

> Doc update of schema location 
> --
>
> Key: GEODE-2135
> URL: https://issues.apache.org/jira/browse/GEODE-2135
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.1.0
>
>
> Throughout the documentation, update the schema location to be
> {{http://geode.apache.org/schema/cache/cache-1.0.xsd}}
> Incorrect location uses {{geode.incubator.apache.org}}



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

[jira] [Closed] (GEODE-2134) Doc update of schema location

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2134.
--

> Doc update of schema location 
> --
>
> Key: GEODE-2134
> URL: https://issues.apache.org/jira/browse/GEODE-2134
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
> Fix For: 1.1.0
>
>
> Throughout the documentation, update the schema location to be
> {{http://geode.apache.org/schema/cache/cache-1.0.xsd}}
> Incorrect location uses {{geode.incubator.apache.org}}



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2295:


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

[GEODE-2295] Add constructors for LocatorCancelException

and update one place where it's used.


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



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

[jira] [Closed] (GEODE-2133) An exception in a receiving site can cause the sender site's AckReaderThread to stop

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2133.
--

> An exception in a receiving site can cause the sender site's AckReaderThread 
> to stop
> 
>
> Key: GEODE-2133
> URL: https://issues.apache.org/jira/browse/GEODE-2133
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
> Fix For: 1.1.0
>
>
> This is the same bug as GEM-1100.
> If the receiving site throws an exception, the sendeing site's 
> AckReaderThread BatchException logging can fail and cause the thread to stop. 
> The BatchException logging handles exceptions that occur while processing 
> GatewaySenderEvents, but it doesn't handle other kinds of exceptions (like 
> NPEs processing PdxType updates).
> Here are the relevant sending site log messages:
> {noformat}
> [warning 2016/11/18 12:00:18.856 PST ln-1  Processor for GatewaySender_ny_2> tid=0x71] A BatchException occurred 
> processing events. Index of Array of Exception : -1
> org.apache.geode.internal.cache.wan.BatchException70: Exception occurred 
> while processing a batch on the receiver running on DistributedSystem with 
> Id: 1, DistributedMember on which the receiver is running: 
> 192.168.2.10(ny-1:18934):1027
>   at 
> org.apache.geode.internal.cache.tier.sockets.command.GatewayReceiverCommand.cmdExecute(GatewayReceiverCommand.java:714)
>   at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:141)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:776)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:904)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1160)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:519)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.geode.pdx.internal.PeerTypeRegistration$2.beforeUpdate(PeerTypeRegistration.java:173)
>   at 
> org.apache.geode.internal.cache.SearchLoadAndWriteProcessor.doLocalWrite(SearchLoadAndWriteProcessor.java:845)
>   at 
> org.apache.geode.internal.cache.SearchLoadAndWriteProcessor.doNetWrite(SearchLoadAndWriteProcessor.java:182)
>   at 
> org.apache.geode.internal.cache.DistributedRegion.cacheWriteBeforePut(DistributedRegion.java:2687)
>   at 
> org.apache.geode.internal.cache.AbstractRegionMap.invokeCacheWriter(AbstractRegionMap.java:3008)
>   at 
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2769)
>   at 
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5750)
>   at 
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:337)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:151)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5730)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicBridgePut(LocalRegion.java:5374)
>   at 
> org.apache.geode.internal.cache.tier.sockets.command.GatewayReceiverCommand.cmdExecute(GatewayReceiverCommand.java:468)
>   ... 8 more
> [severe 2016/11/18 12:00:18.856 PST ln-1  Processor for GatewaySender_ny_2> tid=0x71] Stopping the processor because 
> the following exception occurred while processing a batch:
> java.lang.ArrayIndexOutOfBoundsException: -1
>   at java.util.ArrayList.elementData(ArrayList.java:418)
>   at java.util.ArrayList.get(ArrayList.java:431)
>   at 
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.logBatchExceptions(GatewaySenderEventRemoteDispatcher.java:721)
>   at 
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:623)
> {noformat}



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

[jira] [Closed] (GEODE-2129) Need to generate pdx type id random(or avoid sequential)

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2129.
--

> Need to generate pdx type id random(or avoid sequential)
> 
>
> Key: GEODE-2129
> URL: https://issues.apache.org/jira/browse/GEODE-2129
> Project: Geode
>  Issue Type: Bug
>  Components: serialization
>Reporter: Hitesh Khamesra
>Assignee: Hitesh Khamesra
> Fix For: 1.1.0
>
>
> Right now pdxtype id has 4 bytes.  Out of those 4 bytes, one byte reserved 
> for distributed-system-id, this make sure type id generated from different 
> cluster has different id. For rest of the three bytes we just increment 
> counter to create new pdxtype id.  In the field, we have observed that 
> sometimes this pdxType Id collides.  One reason could be they end up having 
> same distributed-system-id for the different cluster.  
> Thus to avoid a collision, we will be using hashcode of pdxType for three 
> bytes of pdxType id. That will reduce the possibility of collision.



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

[jira] [Closed] (GEODE-2127) old client support service is not set up to handle arrays

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2127.
--

> old client support service is not set up to handle arrays
> -
>
> Key: GEODE-2127
> URL: https://issues.apache.org/jira/browse/GEODE-2127
> Project: Geode
>  Issue Type: Test
>  Components: client/server
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> I noticed that the OldClientSupportProvider is not checking for classes whose 
> names start with "[L".  It should be looking for names that start with some 
> number of left-brackets followed by L and the old package name.



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

[jira] [Closed] (GEODE-2123) Replace static members in ParallelgatewaySenderQueues with instance variables

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2123.
--

> Replace static members in ParallelgatewaySenderQueues with instance variables
> -
>
> Key: GEODE-2123
> URL: https://issues.apache.org/jira/browse/GEODE-2123
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: nabarun
>Assignee: Jason Huynh
> Fix For: 1.1.0
>
>
> All parallel sender queues shared one BatchRemovalThread, which led to the 
> case that if BatchRemovalThread thread was killed by one sender, all 
> secondary sender queues will keep growing as no prq remove messages will be 
> sent to them.
> Also, the static variables in ParallelGatewaySenderQueue needs to be 
> converted in to instance variables, so that the senders don't share these 
> variables and work independent of each other.



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

[jira] [Closed] (GEODE-2124) Queries that invoke StructSet addAll fail with ClassCastException

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2124.
--

> Queries that invoke StructSet addAll fail with ClassCastException
> -
>
> Key: GEODE-2124
> URL: https://issues.apache.org/jira/browse/GEODE-2124
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Barry Oglesby
>Assignee: Jason Huynh
> Fix For: 1.1.0
>
> Attachments: Portfolio.java, Position.java
>
>
> A query like this fails with the exception below:
> {noformat}
> select distinct oP.ID, oP.status, oP.getType from /data oP where 
> element(select distinct p.ID, p.status, p.getType from /data p where p.ID = 
> oP.ID).status = 'inactive'
> {noformat}
> {noformat}
> Caused by: java.lang.ClassCastException: 
> org.apache.geode.cache.query.internal.StructImpl cannot be cast to 
> [Ljava.lang.Object;
>   at 
> org.apache.geode.cache.query.internal.StructSet$ObjectArrayHashingStrategy.hashCode(StructSet.java:70)
>   at 
> it.unimi.dsi.fastutil.objects.ObjectOpenCustomHashSet.add(ObjectOpenCustomHashSet.java:248)
>   at 
> it.unimi.dsi.fastutil.objects.AbstractObjectCollection.addAll(AbstractObjectCollection.java:71)
>   at 
> it.unimi.dsi.fastutil.objects.ObjectOpenCustomHashSet.addAll(ObjectOpenCustomHashSet.java:235)
>   at 
> org.apache.geode.cache.query.internal.StructSet.addAll(StructSet.java:248)
>   at 
> org.apache.geode.cache.query.internal.ResultsCollectionWrapper.addAll(ResultsCollectionWrapper.java:157)
>   at 
> org.apache.geode.cache.query.internal.Functions.element(Functions.java:103)
>   at 
> org.apache.geode.cache.query.internal.CompiledFunction.call(CompiledFunction.java:84)
>   at 
> org.apache.geode.cache.query.internal.CompiledFunction.evaluate(CompiledFunction.java:59)
>   at 
> org.apache.geode.cache.query.internal.CompiledPath.evaluate(CompiledPath.java:92)
>   at 
> org.apache.geode.cache.query.internal.CompiledComparison.evaluate(CompiledComparison.java:82)
>   at 
> org.apache.geode.cache.query.internal.CompiledSelect.doNestedIterations(CompiledSelect.java:787)
>   at 
> org.apache.geode.cache.query.internal.CompiledSelect.doNestedIterations(CompiledSelect.java:857)
>   at 
> org.apache.geode.cache.query.internal.CompiledSelect.doIterationEvaluate(CompiledSelect.java:715)
>   at 
> org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:553)
>   at 
> org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:57)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.executeUsingContext(DefaultQuery.java:559)
>   at 
> org.apache.geode.internal.cache.PRQueryProcessor.executeQueryOnBuckets(PRQueryProcessor.java:367)
>   at 
> org.apache.geode.internal.cache.PRQueryProcessor.executeSequentially(PRQueryProcessor.java:331)
>   at 
> org.apache.geode.internal.cache.PRQueryProcessor.executeQuery(PRQueryProcessor.java:121)
>   at 
> org.apache.geode.internal.cache.PartitionedRegionQueryEvaluator.executeQueryOnLocalNode(PartitionedRegionQueryEvaluator.java:909)
>   at 
> org.apache.geode.internal.cache.PartitionedRegionQueryEvaluator.executeQueryOnRemoteAndLocalNodes(PartitionedRegionQueryEvaluator.java:327)
>   at 
> org.apache.geode.internal.cache.PartitionedRegionQueryEvaluator.queryBuckets(PartitionedRegionQueryEvaluator.java:445)
>   at 
> org.apache.geode.internal.cache.PartitionedRegion.doExecuteQuery(PartitionedRegion.java:1792)
>   at 
> org.apache.geode.internal.cache.PartitionedRegion.executeQuery(PartitionedRegion.java:1721)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:342)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:300)
>   at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommandQuery.processQueryUsingParams(BaseCommandQuery.java:121)
>   at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommandQuery.processQuery(BaseCommandQuery.java:65)
>   at 
> org.apache.geode.internal.cache.tier.sockets.command.Query.cmdExecute(Query.java:92)
>   at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:141)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:777)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:905)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1161)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolEx

[jira] [Closed] (GEODE-2121) add DLockTest, MembershipTest, ClientServerTest, ClientSubscriptionTest and RestAPITest categories

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2121.
--

> add DLockTest, MembershipTest, ClientServerTest, ClientSubscriptionTest and 
> RestAPITest categories
> --
>
> Key: GEODE-2121
> URL: https://issues.apache.org/jira/browse/GEODE-2121
> Project: Geode
>  Issue Type: Test
>  Components: client queues, client/server, distributed lock service, 
> membership, rest (dev), serialization
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> I need these test categories in order to run code-coverage analysis for the 
> components I usually work with.  The categories should be added to the 
> appropriate unit tests.



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

[jira] [Closed] (GEODE-2120) MultipleOplogsRollingFeatureJUnitTest sometimes failed in CI

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2120.
--

> MultipleOplogsRollingFeatureJUnitTest sometimes failed in CI
> 
>
> Key: GEODE-2120
> URL: https://issues.apache.org/jira/browse/GEODE-2120
> Project: Geode
>  Issue Type: Bug
>  Components: core
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>  Labels: CI
> Fix For: 1.1.0
>
>
> In Integration Tests Build #276: 
>classname="org.apache.geode.internal.cache.MultipleOplogsRollingFeatureJUnitTest"
>  time="7.264">
> 

[jira] [Closed] (GEODE-2117) Pulse fails to handle float type mbean attributes

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2117.
--

> Pulse fails to handle float type mbean attributes
> -
>
> Key: GEODE-2117
> URL: https://issues.apache.org/jira/browse/GEODE-2117
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.0.0-incubating.M2, 1.0.0-incubating.M3, 
> 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Kirk Lund
> Fix For: 1.1.0
>
>
> The following log messages are logged to Pulse log. These attributes 
> correspond to fields on MemberMXBean.
> Pulse reacts to this by using zero as the value for all of these MBeans 
> attributes.
> This seems to have been introduced by these commits in Feb:
> {noformat}
> commit 022733e8837b15b415c466a2e59874e09165e1c1
> Author: Jens Deppe 
> Date:   Sat Feb 20 12:15:24 2016 -0800
> GEODE-907: Switch all fields from floats to doubles
> 
> - This is because when Jackson serializes a float (to JSON) it does so
>   through an implicit cast to a double which alters the precision.
>   Practically, a number like 23.99F ends up being 23.9899234D which
>   messes with unit tests and displaying in the UI.
> commit 6d3f55605bd97a3e1172bf05906a9f612c18f1e2
> Author: Jens Deppe 
> Date:   Thu Feb 18 16:31:15 2016 -0800
> GEODE-907: Converted core functionality to use jackson
> {noformat}
> Errors in log file (note they're logged at INFO level as well):
> {noformat}
> [INFO 2016/11/10 21:20:40.594 IST PULSE-dharam-ThinkPad-Edge-E431:1099:null 
> tid=0x6d] (msgTID=109 msgSN=18882) [PULSE]
> [org.apache.geode.tools.pulse.internal.log.PulseLogWriter]
> Unexpected type for attribute: AverageWrites Expected 
> type: java.lang.Double Received type: java.lang.Float
> [INFO 2016/11/10 21:20:45.594 IST PULSE-dharam-ThinkPad-Edge-E431:1099:null 
> tid=0x6d] (msgTID=109 msgSN=18883) [PULSE]
> [org.apache.geode.tools.pulse.internal.log.PulseLogWriter]
> Unexpected type for attribute: DiskWritesRate 
> Expected type: java.lang.Double Received type: 
> java.lang.Float
> [INFO 2016/11/10 21:20:45.595 IST PULSE-dharam-ThinkPad-Edge-E431:1099:null 
> tid=0x6d] (msgTID=109 msgSN=18884) [PULSE]
> [org.apache.geode.tools.pulse.internal.log.PulseLogWriter]
> Unexpected type for attribute: AverageWrites Expected 
> type: java.lang.Double Received type: java.lang.Float
> [INFO 2016/11/10 21:20:45.595 IST PULSE-dharam-ThinkPad-Edge-E431:1099:null 
> tid=0x6d] (msgTID=109 msgSN=18885) [PULSE]
> [org.apache.geode.tools.pulse.internal.log.PulseLogWriter]
> Unexpected type for attribute: AverageReads Expected 
> type: java.lang.Double Received type: java.lang.Float
> [INFO 2016/11/10 21:20:45.595 IST PULSE-dharam-ThinkPad-Edge-E431:1099:null 
> tid=0x6d] (msgTID=109 msgSN=18886) [PULSE]
> [org.apache.geode.tools.pulse.internal.log.PulseLogWriter]
> Unexpected type for attribute: QueryRequestRate 
> Expected type: java.lang.Double Received type: 
> java.lang.Float
> [INFO 2016/11/10 21:20:45.595 IST PULSE-dharam-ThinkPad-Edge-E431:1099:null 
> tid=0x6d] (msgTID=109 msgSN=18887) [PULSE]
> [org.apache.geode.tools.pulse.internal.log.PulseLogWriter]
> Unexpected type for attribute: DiskReadsRate Expected 
> type: java.lang.Double Received type: java.lang.Float
> [INFO 2016/11/10 21:20:45.596 IST PULSE-dharam-ThinkPad-Edge-E431:1099:null 
> tid=0x6d] (msgTID=109 msgSN=1) [PULSE]
> [org.apache.geode.tools.pulse.internal.log.PulseLogWriter]
> Unexpected type for attribute: DiskWritesRate 
> Expected type: java.lang.Double Received type: 
> java.lang.Float
> [INFO 2016/11/10 21:20:45.596 IST PULSE-dharam-ThinkPad-Edge-E431:1099:null 
> tid=0x6d] (msgTID=109 msgSN=18889) [PULSE]
> [org.apache.geode.tools.pulse.internal.log.PulseLogWriter]
> Unexpected type for attribute: DiskReadsRate Expected 
> type: java.lang.Double Received type: java.lang.Float
> [INFO 2016/11/10 21:20:45.596 IST PULSE-dharam-ThinkPad-Edge-E431:1099:null 
> tid=0x6d] (msgTID=109 msgSN=18890) [PULSE]
> [org.apache.geode.tools.pulse.internal.log.PulseLogWriter]
> Unexpected type for attribute: CpuUsage Expected 
> type: java.lang.Double Received type: java.lang.Float
> [INFO 2016/11/10 21:20:45.596 IST PULSE-dharam-ThinkPad-Edge-E431:1099:null 
> tid=0x6d] (msgTID=109 msgSN=18891) [PULSE]
> [org.apache.geode.tools.pulse.internal.log.PulseLogWriter]
> *

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

[Spring CI]

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

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





--
This message is automatically generated by Atlassian Bamboo

[jira] [Closed] (GEODE-2119) gfsh user and password visible in clear text

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2119.
--

> gfsh user and password visible in clear text
> 
>
> Key: GEODE-2119
> URL: https://issues.apache.org/jira/browse/GEODE-2119
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.0.0-incubating
>Reporter: Karen Smoler Miller
>Assignee: Kevin Duling
> Fix For: 1.1.0
>
>
> Both gfsh connect and gfsh start server allow the specification on the 
> command line of a user name and a password for use as credentials in 
> authentication.  Clear text versions of the user name and password are then 
> visible
> 1. if the user runs gfsh history
> 2. in historyfile, if the user runs gfsh history --file=historyfile
> 3. in the output of ps
> It would be worth a check to see if clear text versions of the user or 
> password end up in any locator or server logs.  I don't believe it does for 
> gfsh connect, but it might for the start server case.



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

[jira] [Closed] (GEODE-2114) Add user and password to gfsh connect docs

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2114.
--

> Add user and password to gfsh connect docs
> --
>
> Key: GEODE-2114
> URL: https://issues.apache.org/jira/browse/GEODE-2114
> Project: Geode
>  Issue Type: Task
>  Components: docs
>Reporter: Karen Smoler Miller
> Fix For: 1.1.0
>
>
> The gfsh connect command has --user and --password options that are not 
> completely documented.  The task here is to complete that documentation. 



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

[jira] [Closed] (GEODE-2112) UITests are failing due to insufficient tearDown

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2112.
--

> UITests are failing due to insufficient tearDown
> 
>
> Key: GEODE-2112
> URL: https://issues.apache.org/jira/browse/GEODE-2112
> Project: Geode
>  Issue Type: Bug
>  Components: pulse, tests
>Reporter: Kirk Lund
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> UITests are failing due to insufficient tearDown
> {noformat}
> INFO: Connecting to jmxURL : 
> service:jmx:rmi://localhost/jndi/rmi://localhost:/jmxrmi
> [info 2016/11/14 15:51:15.940 PST  
> tid=0x14] Logging in admin
> [warn 2016/11/14 15:51:15.940 PST  
> tid=0x14] Authentication failed for token submission 
> [org.apache.geode.internal.security.shiro.GeodeAuthenticationToken - admin, 
> rememberMe=false].  Possible unexpected error? (Typical or expected login 
> exceptions should extend from AuthenticationException).
> org.apache.geode.security.AuthenticationFailedException: 
> SampleSecurityManager: wrong username/password
> at 
> org.apache.geode.security.templates.SampleSecurityManager.authenticate(SampleSecurityManager.java:146)
> at 
> org.apache.geode.internal.security.shiro.CustomAuthRealm.doGetAuthenticationInfo(CustomAuthRealm.java:66)
> at 
> org.apache.shiro.realm.AuthenticatingRealm.getAuthenticationInfo(AuthenticatingRealm.java:568)
> at 
> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doSingleRealmAuthentication(ModularRealmAuthenticator.java:180)
> at 
> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doAuthenticate(ModularRealmAuthenticator.java:267)
> at 
> org.apache.shiro.authc.AbstractAuthenticator.authenticate(AbstractAuthenticator.java:198)
> at 
> org.apache.shiro.mgt.AuthenticatingSecurityManager.authenticate(AuthenticatingSecurityManager.java:106)
> at 
> org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:270)
> at 
> org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:256)
> at 
> org.apache.geode.internal.security.IntegratedSecurityService.login(IntegratedSecurityService.java:151)
> at 
> org.apache.geode.internal.security.shiro.JMXShiroAuthenticator.authenticate(JMXShiroAuthenticator.java:58)
> at 
> javax.management.remote.rmi.RMIServerImpl.doNewClient(RMIServerImpl.java:232)
> at 
> javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Closed] (GEODE-2111) Add gfsh recommendation to put all --J options at end of command line

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2111.
--

> Add gfsh recommendation to put all --J options at end of command line
> -
>
> Key: GEODE-2111
> URL: https://issues.apache.org/jira/browse/GEODE-2111
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Diane Hardman
> Fix For: 1.1.0
>
>
> This is a follow-on bug to GEODE-2104. Due to command line parsing 
> irregularities (which are being worked on), we should recommend in the docs 
> that any --J options should be placed at the end of the command line.



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

[jira] [Closed] (GEODE-2110) Add user and password to gfsh start server docs

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2110.
--

> Add user and password to gfsh start server docs
> ---
>
> Key: GEODE-2110
> URL: https://issues.apache.org/jira/browse/GEODE-2110
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.1.0
>
>
> Options to the gfsh start server command specify the user and password to use 
> as credentials in authentication.  These options are nicely printed in the 
> gfsh help option, but they did not  make it into the command reference page 
> for the gfsh start server command.  Thus, they need to be added.
> From the help output:
> user
> User name to securely connect to the cluster. If the --password 
> parameter is not specified then it will be prompted for.
> Required: false
> password
> Password to securely connect to the cluster.
> Required: false



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

[jira] [Closed] (GEODE-2109) calling submit on ExecutionService can cause exceptions to be lost

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2109.
--

> calling submit on ExecutionService can cause exceptions to be lost
> --
>
> Key: GEODE-2109
> URL: https://issues.apache.org/jira/browse/GEODE-2109
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
> Fix For: 1.1.0
>
>
> Geode has a number of places that call submit on ExecutionService. The submit 
> method returns a Future object. If the caller makes sure it calls "get" on 
> the Future then all is well. But in many places geode is not calling get. In 
> that case if the Runnable that was submitted throws an exception it gets 
> stored in the get and never logged. This can make it very hard to diagnose 
> problems.
> If the caller does not want to call get on the returned Future then it should 
> instead call the "execute" method. In that case the exception will be 
> unhandled and the unhandled exception handler code we have on the 
> LoggingThreadGroup class will cause the exception to be logged.
> Here are the places that should be changed to use execute instead of submit:
> org.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap.clear()
> org.apache.geode.internal.cache.DiskStoreImpl.executeDiskStoreTask(Runnable)
> org.apache.geode.internal.cache.lru.HeapEvictor.onEvent(MemoryEvent)
> org.apache.geode.distributed.internal.InternalLocator.restartWithDS(InternalDistributedSystem,
>  GemFireCacheImpl)
> org.apache.geode.distributed.internal.FunctionExecutionPooledExecutor.FunctionExecutionPooledExecutor(BlockingQueue,
>  int, PoolStatHelper, ThreadFactory, int, boolean)
> org.apache.geode.internal.cache.PRHARedundancyProvider.scheduleCreateMissingBuckets()
> org.apache.geode.distributed.internal.InternalLocator.startSharedConfigurationService(GemFireCacheImpl)
> org.apache.geode.cache.client.internal.SingleHopClientExecutor.submitTask(Runnable)
> org.apache.geode.management.internal.FederatingManager.submitTask(Callable)



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

[jira] [Closed] (GEODE-2101) Improve WAN topology terminology in docs

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2101.
--

> Improve WAN topology terminology in docs
> 
>
> Key: GEODE-2101
> URL: https://issues.apache.org/jira/browse/GEODE-2101
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>Priority: Minor
> Fix For: 1.1.0
>
>
> In our documentation description of WAN topologies, the term "parallel 
> multi-site topology" is a fully connected mesh. The "serial multi-site 
> topology" is a ring.  It will improve the docs to change our descriptions to 
> use the common and accepted terms.



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

[jira] [Closed] (GEODE-2104) GFSH parsing of options following --J options are interpreted as part of the --J value

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2104.
--

> GFSH parsing of options following --J options are interpreted as part of the 
> --J value
> --
>
> Key: GEODE-2104
> URL: https://issues.apache.org/jira/browse/GEODE-2104
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> GFSH parsing of options following --J options are interpreted as part of the 
> --J value.
> $ start server --name=me3 --J=-Dgemfire.jmx-manager=true 
> --J=-Dgemfire.jmx-manager-start=true --http-service-port=8080` 
> In the above GFSH does not interpret the `http-service-port` option 
> correctly.  If you look in the log, the value for `gemfire.jmx-manager-start` 
> is `true --http-service-port=8080`



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

[jira] [Closed] (GEODE-2098) gfsh history should be stored in ~/.geode

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2098.
--

> gfsh history should be stored in ~/.geode
> -
>
> Key: GEODE-2098
> URL: https://issues.apache.org/jira/browse/GEODE-2098
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh
>Reporter: Anthony Baker
>Assignee: Karen Smoler Miller
> Fix For: 1.1.0
>
>
> Currently gfsh stores history in the ~/.gemfire directory.  We should change 
> that to be ~/.geode.
> {code}
> private static String getHomeGemFireDirectory() {
> String userHome = System.getProperty("user.home");
> String homeDirPath = userHome + "/.gemfire";
> File alternateDir = new File(homeDirPath);
> if (!alternateDir.exists()) {
>   if (!alternateDir.mkdirs()) {
> homeDirPath = ".";
>   }
> }
> return homeDirPath;
>   }
> {code}



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

[jira] [Closed] (GEODE-2099) Race condition in ConnectToLocatorSSLDUnitTest

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2099.
--

> Race condition in ConnectToLocatorSSLDUnitTest
> --
>
> Key: GEODE-2099
> URL: https://issues.apache.org/jira/browse/GEODE-2099
> Project: Geode
>  Issue Type: Bug
>  Components: management, tests
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>  Labels: Flaky
> Fix For: 1.1.0
>
>
> This test contains 3 tests, if put a long enough wait or a break point in 
> between the tests, the tests would pass, otherwise the last two tests would 
> fail. Need to get to the bottom of this. For the last tests are ignored. This 
> is happening after we have to put "disconnect" after each connect to properly 
> close the jmx thread so that it wouldn't pollute other tests.



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

[jira] [Closed] (GEODE-2100) Add new version of query client server messages

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2100.
--

> Add new version of query client server messages
> ---
>
> Key: GEODE-2100
> URL: https://issues.apache.org/jira/browse/GEODE-2100
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.1.0
>
>
> Create new message types that properly handle legacy clients compared to 
> newer clients



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

[jira] [Closed] (GEODE-2094) Update admin/dev REST API documentation

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2094.
--

> Update admin/dev REST API documentation
> ---
>
> Key: GEODE-2094
> URL: https://issues.apache.org/jira/browse/GEODE-2094
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.1.0
>
>
> These 3 options for the gfsh start server command are not documented, so also 
> add them to the command reference page:
> --http-service-port
> --http-service-bind-address
> --start-rest-api
> The commands to start a server can be simplified in the prose on using gfsh 
> with REST commands.
> 1. In the docs file 
> geode-docs/configuring/cluster_config/gfsh_remote.html.md.erb, about using 
> the admin REST interface, the sample gfsh start server command can be 
> simplified.
> --J=-Dgemfire.http-service-port=8080
> becomes
> --http-service-port=8080
> --J=-Dgemfire.http-service-bind-address=myremotecluster.example.com
> becomes
> --http-service-bind-address=myremotecluster.example.com
> 2. In the docs file geode-docs/rest_apps/setup_config.html.md.erb, about 
> using the dev REST API, the gfsh start server commands given in steps 2 and 3 
> can be simplified (corrected).
> --J=-Dgemfire.start-dev-rest-api=true
> becomes
> --start-rest-api=true
> --J=-Dgemfire.http-service-port=8080
> becomes
> --http-service-port=8080
> --J=-Dgemfire.http-service-bind-address=localhost
> becomes 
> --http-service-bind-address=localhost



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

[jira] [Closed] (GEODE-2095) CI Failure: PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2095.
--

> CI Failure: 
> PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild
> ---
>
> Key: GEODE-2095
> URL: https://issues.apache.org/jira/browse/GEODE-2095
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Eric Shu
>Assignee: Kenneth Howe
>  Labels: ci, flaky
> Fix For: 1.1.0
>
>
> Failed in a precheckin run.
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
>  > testHierarchyOfColocatedChildPRsMissingGrandchild FAILED
> java.util.concurrent.TimeoutException: Timed out waiting 6 
> milliseconds for AsyncInvocation to complete.
> at 
> org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:423)
> at 
> org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:373)
> at 
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild(PersistentColocatedPartitionedRegionDUnitTest.java:1143)



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

[jira] [Closed] (GEODE-2092) Security examples should not be in product package

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2092.
--

> Security examples should not be in product package
> --
>
> Key: GEODE-2092
> URL: https://issues.apache.org/jira/browse/GEODE-2092
> Project: Geode
>  Issue Type: Bug
>  Components: docs, security
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Kevin Duling
> Fix For: 1.1.0
>
>
> These three classes are currently in geode-core product package which implies 
> they are fully supported user API. They cannot be released in a user API 
> package. 
> 1) Move the security examples to examples package within geode-core
> * 
> geode-core/src/main/java/org/apache/geode/security/templates/SampleSecurityManager.java
> * 
> geode-core/src/main/java/org/apache/geode/security/templates/SamplePostProcessor.java
> To:
> * 
> geode-core/src/main/java/org/apache/geode/security/examples/ExampleSecurityManager.java
> * 
> geode-core/src/main/java/org/apache/geode/security/examples/ExamplePostProcessor.java
> Delete this one (it should only exist in some GitHub application for demoing):
> * 
> geode-core/src/main/java/org/apache/geode/security/templates/SimpleSecurityManager.java
> 2) We have geode-core tests that use the security examples. These tests must 
> be altered to use new classes that implement SecurityManager and 
> PostProcessor. These new classes need to live under 
> geode-core/src/tests/java/org/apache/geode/security.
> I also see 
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/controllers/RedactingPostProcessor.java
>  with javadocs indicating that it is an example. Either a) remove the 
> javadocs saying it's an example or b) move it to 
> geode-core/src/main/java/org/apache/geode/security/examples and then create a 
> new implementation of PostProcessor which the rest tests will use.
> End results should be:
> a) all examples live in either geode-examples or 
> geode-core/src/main/java/org/apache/geode/security/examples
> b) no tests should be using the examples, they should be using test specific 
> implementations under geode-core/src/tests/java
> c) no demoing code should be GEODE -- such code belongs in GitHub or other 
> project repos -- for a really good example, please see:
> * https://github.com/spring-projects/spring-gemfire-examples
> * 
> https://github.com/spring-projects/spring-gemfire-examples/tree/master/quickstart/repository
> If anyone needs help creating an example repo outside of GEODE, then please 
> discuss this on geode dev mailing list.



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

[jira] [Closed] (GEODE-2091) PartitionedRegion containsValueForKey() in transaction may return false if there is a rebalance

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2091.
--

> PartitionedRegion containsValueForKey() in transaction may return false if 
> there is a rebalance
> ---
>
> Key: GEODE-2091
> URL: https://issues.apache.org/jira/browse/GEODE-2091
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Eric Shu
>Assignee: Eric Shu
> Fix For: 1.1.0
>
>
> PartitionedRegion containsValueForKey() in transaction may return false if 
> the bucket contains the entry is moved to other node due to rebalance.



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

[jira] [Closed] (GEODE-2090) Update off-heap statistics documentation

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2090.
--

> Update off-heap statistics documentation
> 
>
> Key: GEODE-2090
> URL: https://issues.apache.org/jira/browse/GEODE-2090
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.1.0
>
>
> The {{gfsh show metrics}} command reference page is missing the optional 
> {{--category=offheap}} option.
> Also, verify if the statistic {{compactions}} ought to be called 
> {{defragmentations}}. If so, fix the error.



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

[jira] [Updated] (GEODE-2458) RegionManagementDUnitTest.testFixedPRRegionMBean fails with AssertionError in verifyMemberNotifications

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2458:
-
Labels: Flaky  (was: )

> RegionManagementDUnitTest.testFixedPRRegionMBean fails with AssertionError in 
> verifyMemberNotifications
> ---
>
> Key: GEODE-2458
> URL: https://issues.apache.org/jira/browse/GEODE-2458
> Project: Geode
>  Issue Type: Bug
>  Components: management, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>  Labels: Flaky
>
> This appears to be a race condition. The assertion finds 5 members when 6 is 
> expected and then lists the members as part of the assertion message which 
> then shows 6 members.
> {noformat}
> org.apache.geode.management.RegionManagementDUnitTest > 
> testFixedPRRegionMBean FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host 
> 242824700ff7 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
> at 
> org.apache.geode.management.RegionManagementDUnitTest.verifyMemberNotifications(RegionManagementDUnitTest.java:580)
> at 
> org.apache.geode.management.RegionManagementDUnitTest.testFixedPRRegionMBean(RegionManagementDUnitTest.java:227)
> Caused by:
> java.lang.AssertionError: 
> Expected size:<6> but was:<5> in:
> 
> <[javax.management.Notification[source=172.17.0.4(161)-32770][type=gemfire.distributedsystem.cache.region.created][message=Region
>  Created With Name /MANAGEMENT_FIXED_PR],
> 
> javax.management.Notification[source=172.17.0.4(166)-32771][type=gemfire.distributedsystem.cache.region.created][message=Region
>  Created With Name /MANAGEMENT_FIXED_PR],
> 
> javax.management.Notification[source=172.17.0.4(171)-32772][type=gemfire.distributedsystem.cache.region.created][message=Region
>  Created With Name /MANAGEMENT_FIXED_PR],
> 
> javax.management.Notification[source=172.17.0.4(161)-32770][type=gemfire.distributedsystem.cache.region.closed][message=Region
>  Destroyed/Closed With Name /MANAGEMENT_FIXED_PR],
> 
> javax.management.Notification[source=172.17.0.4(166)-32771][type=gemfire.distributedsystem.cache.region.closed][message=Region
>  Destroyed/Closed With Name /MANAGEMENT_FIXED_PR],
> 
> javax.management.Notification[source=172.17.0.4(171)-32772][type=gemfire.distributedsystem.cache.region.closed][message=Region
>  Destroyed/Closed With Name /MANAGEMENT_FIXED_PR]]>
> at 
> org.apache.geode.management.RegionManagementDUnitTest.lambda$verifyMemberNotifications$3d0515b3$1(RegionManagementDUnitTest.java:582)
> {noformat}



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

[jira] [Assigned] (GEODE-2458) RegionManagementDUnitTest.testFixedPRRegionMBean fails with AssertionError in verifyMemberNotifications

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2458:


Assignee: Kirk Lund

> RegionManagementDUnitTest.testFixedPRRegionMBean fails with AssertionError in 
> verifyMemberNotifications
> ---
>
> Key: GEODE-2458
> URL: https://issues.apache.org/jira/browse/GEODE-2458
> Project: Geode
>  Issue Type: Bug
>  Components: management, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>  Labels: Flaky
>
> This appears to be a race condition. The assertion finds 5 members when 6 is 
> expected and then lists the members as part of the assertion message which 
> then shows 6 members.
> {noformat}
> org.apache.geode.management.RegionManagementDUnitTest > 
> testFixedPRRegionMBean FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host 
> 242824700ff7 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
> at 
> org.apache.geode.management.RegionManagementDUnitTest.verifyMemberNotifications(RegionManagementDUnitTest.java:580)
> at 
> org.apache.geode.management.RegionManagementDUnitTest.testFixedPRRegionMBean(RegionManagementDUnitTest.java:227)
> Caused by:
> java.lang.AssertionError: 
> Expected size:<6> but was:<5> in:
> 
> <[javax.management.Notification[source=172.17.0.4(161)-32770][type=gemfire.distributedsystem.cache.region.created][message=Region
>  Created With Name /MANAGEMENT_FIXED_PR],
> 
> javax.management.Notification[source=172.17.0.4(166)-32771][type=gemfire.distributedsystem.cache.region.created][message=Region
>  Created With Name /MANAGEMENT_FIXED_PR],
> 
> javax.management.Notification[source=172.17.0.4(171)-32772][type=gemfire.distributedsystem.cache.region.created][message=Region
>  Created With Name /MANAGEMENT_FIXED_PR],
> 
> javax.management.Notification[source=172.17.0.4(161)-32770][type=gemfire.distributedsystem.cache.region.closed][message=Region
>  Destroyed/Closed With Name /MANAGEMENT_FIXED_PR],
> 
> javax.management.Notification[source=172.17.0.4(166)-32771][type=gemfire.distributedsystem.cache.region.closed][message=Region
>  Destroyed/Closed With Name /MANAGEMENT_FIXED_PR],
> 
> javax.management.Notification[source=172.17.0.4(171)-32772][type=gemfire.distributedsystem.cache.region.closed][message=Region
>  Destroyed/Closed With Name /MANAGEMENT_FIXED_PR]]>
> at 
> org.apache.geode.management.RegionManagementDUnitTest.lambda$verifyMemberNotifications$3d0515b3$1(RegionManagementDUnitTest.java:582)
> {noformat}



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

[jira] [Created] (GEODE-2458) RegionManagementDUnitTest.testFixedPRRegionMBean fails with AssertionError in verifyMemberNotifications

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2458:


 Summary: RegionManagementDUnitTest.testFixedPRRegionMBean fails 
with AssertionError in verifyMemberNotifications
 Key: GEODE-2458
 URL: https://issues.apache.org/jira/browse/GEODE-2458
 Project: Geode
  Issue Type: Bug
  Components: management, tests
Reporter: Kirk Lund


This appears to be a race condition. The assertion finds 5 members when 6 is 
expected and then lists the members as part of the assertion message which then 
shows 6 members.
{noformat}
org.apache.geode.management.RegionManagementDUnitTest > testFixedPRRegionMBean 
FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host 
242824700ff7 with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
at 
org.apache.geode.management.RegionManagementDUnitTest.verifyMemberNotifications(RegionManagementDUnitTest.java:580)
at 
org.apache.geode.management.RegionManagementDUnitTest.testFixedPRRegionMBean(RegionManagementDUnitTest.java:227)

Caused by:
java.lang.AssertionError: 
Expected size:<6> but was:<5> in:

<[javax.management.Notification[source=172.17.0.4(161)-32770][type=gemfire.distributedsystem.cache.region.created][message=Region
 Created With Name /MANAGEMENT_FIXED_PR],

javax.management.Notification[source=172.17.0.4(166)-32771][type=gemfire.distributedsystem.cache.region.created][message=Region
 Created With Name /MANAGEMENT_FIXED_PR],

javax.management.Notification[source=172.17.0.4(171)-32772][type=gemfire.distributedsystem.cache.region.created][message=Region
 Created With Name /MANAGEMENT_FIXED_PR],

javax.management.Notification[source=172.17.0.4(161)-32770][type=gemfire.distributedsystem.cache.region.closed][message=Region
 Destroyed/Closed With Name /MANAGEMENT_FIXED_PR],

javax.management.Notification[source=172.17.0.4(166)-32771][type=gemfire.distributedsystem.cache.region.closed][message=Region
 Destroyed/Closed With Name /MANAGEMENT_FIXED_PR],

javax.management.Notification[source=172.17.0.4(171)-32772][type=gemfire.distributedsystem.cache.region.closed][message=Region
 Destroyed/Closed With Name /MANAGEMENT_FIXED_PR]]>
at 
org.apache.geode.management.RegionManagementDUnitTest.lambda$verifyMemberNotifications$3d0515b3$1(RegionManagementDUnitTest.java:582)
{noformat}



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

[jira] [Closed] (GEODE-2088) A get in transaction may get incorrect TransactionDataNotColocatedException when bucket is not hosted locally

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra closed GEODE-2088.
--

> A get in transaction may get incorrect TransactionDataNotColocatedException 
> when bucket is not hosted locally
> -
>
> Key: GEODE-2088
> URL: https://issues.apache.org/jira/browse/GEODE-2088
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Eric Shu
>Assignee: Eric Shu
> Fix For: 1.1.0
>
>
> Currently a get of a PR in transaction on a data node with TXState will first 
> check if the bucket is hosted locally by following code. 
> {noformat}
>   public Object getLocally(int bucketId, final Object key, final Object 
> aCallbackArgument,
>   boolean disableCopyOnRead, boolean preferCD, ClientProxyMembershipID 
> requestingClient,
>   EntryEventImpl clientEvent, boolean returnTombstones, boolean 
> opScopeIsLocal)
>   throws PrimaryBucketException, ForceReattemptException, 
> PRLocallyDestroyedException {
> final BucketRegion bucketRegion = getInitializedBucketForId(key, 
> Integer.valueOf(bucketId));
> {noformat}
> The BucketNotFoundException is thrown if the node does not host the bucket:
> {noformat}
>   public BucketRegion getInitializedBucketForId(Object key, Integer bucketId)
>   throws ForceReattemptException {
> final BucketRegion bucketRegion = 
> this.localBucket2RegionMap.get(bucketId);
> if (null == bucketRegion) {
>   this.partitionedRegion.checkReadiness();
>   if (logger.isDebugEnabled()) {
> logger.debug("Got null bucket region for bucketId={}{}{} for 
> PartitionedRegion = {}",
> this.partitionedRegion.getPRId(), 
> PartitionedRegion.BUCKET_ID_SEPARATOR, bucketId,
> this.partitionedRegion);
>   }
>   ForceReattemptException fre = new BucketNotFoundException(
>   
> LocalizedStrings.PartitionedRegionDataStore_BUCKET_ID_0_NOT_FOUND_ON_VM_1
>   .toLocalizedString(
>   new Object[] 
> {this.partitionedRegion.bucketStringForLogs(bucketId.intValue()),
>   this.partitionedRegion.getMyId()}));
>   if (key != null) {
> fre.setHash(key.hashCode());
>   }
>   throw fre;
> }
> {noformat}
> Currently, transaction would fail with the 
> TransactionDataNotColocatedException if bucket is not on local data store 
> {noformat}
>   if (prce instanceof BucketNotFoundException) {
> TransactionException ex = new 
> TransactionDataNotColocatedException(
> 
> LocalizedStrings.PartitionedRegion_KEY_0_NOT_COLOCATED_WITH_TRANSACTION
> .toLocalizedString(key));
> ex.initCause(prce);
> throw ex;
>   }
> {noformat}
> This TransactionDataNotColocatedException is fine if the node never hosts 
> bucket, or only previous operations within the transaction touches replicate 
> regions earlier. However, if a bucket is moved to another node due to 
> rebalance, and previous entry operations within the transaction only touches 
> colocated regions, the transaction should fail with 
> TransactionDataRebalancedException.
> We do not have a good way currently to throw the correct exception. One idea 
> is to iterate through the existing TXRegions in the TXState to see whether we 
> should throw TransactionDataRebalancedException. 



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