Code Contribution Steps Errors

[Avinash Dongre]

I am following steps from
https://cwiki.apache.org/confluence/display/GEODE/Code+contributions for
merging my PR to origin/develop.  Previously all the steps used to work,
but now I am getting following error
fatal: Couldn't find remote ref pull/471/head

adongre@hp-pun-02 ~/source/open/t $ git clone
https://git-wip-us.apache.org/repos/asf/geode.git
Cloning into 'geode'...
remote: Counting objects: 140560, done.
remote: Compressing objects: 100% (41754/41754), done.
remote: Total 140560 (delta 89401), reused 135891 (delta 85551)
Receiving objects: 100% (140560/140560), 79.25 MiB | 899.00 KiB/s, done.
Resolving deltas: 100% (89401/89401), done.
Checking connectivity... done.

adongre@hp-pun-02 ~/source/open/t $ cd geode/
adongre@hp-pun-02 ~/source/open/t/geode (master) $ git checkout develop

adongre@hp-pun-02 ~/source/open/t/geode (develop) $ git remote add
aviGitHub https://github.com/davinash/geode

adongre@hp-pun-02 ~/source/open/t/geode (develop) $ git fetch
aviGitHub  pull/471/head:feature/GEODE-289
fatal: Couldn't find remote ref pull/471/head

Re: Review Request 58518: GEODE-2795: Clean up DUnit VMs after dynamically changing 'user.dir'

[Jinmei Liao]

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




geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
Line 73 (original), 69 (patched)


Why 8?



geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
Line 81 (original), 77 (patched)


If the stopMemberAndboundVMIfNecessary(maybe just rename is cleanUp?) is in 
MemberVM, then in the after(), we can just do:

Arrays.stream(members).forEach(MemberVM::cleanUp);

and in stopMember(int index), we can just do:
members[index].cleanUp();



geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberVM.java
Lines 73 (patched)


I think I prefer to have this cleanUpVM in this class instead of VM, since 
LocatorServerStartupRule is the one that overwrites this user.dir. Feels kind 
of weired that a method in VM will need to refer to a method in a specifid rule 
(LocatorServerStartupRule)


- Jinmei Liao


On April 21, 2017, 10:34 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58518/
> ---
> 
> (Updated April 21, 2017, 10:34 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Ken Howe, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2795: Clean up DUnit VMs after dynamically changing 'user.dir'
> 
> - LocatorServerStarterRule will now always bounce the DUnit VMs in after() to 
> prevent corrupted cached values of `System.getProperty('user.dir')` that 
> refer to a temporary folder which no longer exists.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/ConnectToLocatorSSLDUnitTest.java
>  1033b6c 
>   geode-core/src/test/java/org/apache/geode/management/JMXMBeanDUnitTest.java 
> ebc3f17 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
>  d47b343 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigTestBase.java
>  c5aaa74 
>   geode-core/src/test/java/org/apache/geode/test/dunit/VM.java 0b188ae 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/CleanupDUnitVMsRule.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
>  34506c4 
> 
> 
> Diff: https://reviews.apache.org/r/58518/diff/3/
> 
> 
> Testing
> ---
> 
> Precheckin started (still running)
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 58638: close OffHeapEvictor when cache is closed

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On April 22, 2017, 12:12 a.m., Darrel Schneider wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58638/
> ---
> 
> (Updated April 22, 2017, 12:12 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Eric Shu, and Lynn Gallinat.
> 
> 
> Bugs: GEODE-2811
> https://issues.apache.org/jira/browse/GEODE-2811
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> OffHeapEvictor was never closed resulting in a thread leak
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  56243e1b544f5958204e64c2ca391003aa1fd098 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/lru/HeapEvictor.java 
> b22bb0ec5fa5938a23bad015cf02b9295631bfed 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/GemFireCacheImplTest.java
>  6838e748f112d05363185b7a7e28dd4ce08f80c9 
> 
> 
> Diff: https://reviews.apache.org/r/58638/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin
> 
> 
> Thanks,
> 
> Darrel Schneider
> 
>

Review Request 58638: close OffHeapEvictor when cache is closed

[Darrel Schneider]

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

Review request for geode, anilkumar gingade, Eric Shu, and Lynn Gallinat.


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


Repository: geode


Description
---

OffHeapEvictor was never closed resulting in a thread leak


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
56243e1b544f5958204e64c2ca391003aa1fd098 
  geode-core/src/main/java/org/apache/geode/internal/cache/lru/HeapEvictor.java 
b22bb0ec5fa5938a23bad015cf02b9295631bfed 
  
geode-core/src/test/java/org/apache/geode/internal/cache/GemFireCacheImplTest.java
 6838e748f112d05363185b7a7e28dd4ce08f80c9 


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


Testing
---

precheckin


Thanks,

Darrel Schneider

[jira] [Assigned] (GEODE-2811) Thread leak when offheap memory is configured

[Darrel Schneider (JIRA)]

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

Darrel Schneider reassigned GEODE-2811:
---

Assignee: Darrel Schneider

> Thread leak when offheap memory is configured
> -
>
> Key: GEODE-2811
> URL: https://issues.apache.org/jira/browse/GEODE-2811
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> If you are using offheap memory and keep creating and close the cache over 
> and over then you may run out of threads.
> Each time the cache is initialized it creates a thread pool to handle offheap 
> LRU eviction. The thread pool should be closed when the cache is closed but 
> is not.
> The can lead to an exception like this:
> {quote}
> java.lang.OutOfMemoryError: unable to create new native thread
> {quote}
> The threads will be cleaned up if the garbage collector has a major enough 
> collection to force java object finalization but that may never happen since 
> offheap is being used.



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

[jira] [Created] (GEODE-2811) Thread leak when offheap memory is configured

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2811:
---

 Summary: Thread leak when offheap memory is configured
 Key: GEODE-2811
 URL: https://issues.apache.org/jira/browse/GEODE-2811
 Project: Geode
  Issue Type: Bug
  Components: offheap
Reporter: Darrel Schneider


If you are using offheap memory and keep creating and close the cache over and 
over then you may run out of threads.
Each time the cache is initialized it creates a thread pool to handle offheap 
LRU eviction. The thread pool should be closed when the cache is closed but is 
not.

The can lead to an exception like this:
{quote}
java.lang.OutOfMemoryError: unable to create new native thread
{quote}
The threads will be cleaned up if the garbage collector has a major enough 
collection to force java object finalization but that may never happen since 
offheap is being used.



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

[jira] [Commented] (GEODE-516) GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction has NullPointerException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-516:
---

Commit 50686b0b44024d2bcbb4bea8a36ce3a40ac158c2 in geode's branch 
refs/heads/feature/GEODE-2097 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=50686b0 ]

GEODE-576 & GEODE-516: GemFireDeadlockDetectorDUnitTest failures

Replaced pauses with Awaitility.  Modified asyncs to use the DUnit
blackboard to synchronize their actions for repeatable behavior.
Cleaned up static locks to allow their reuse in other tests or in
repeating the same test.


> GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction has 
> NullPointerException
> -
>
> Key: GEODE-516
> URL: https://issues.apache.org/jira/browse/GEODE-516
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: xiaojian zhou
>  Labels: Flaky, ShowDeadlockCommand
> Fix For: 1.2.0
>
>
> revision 0cc9d895b9f4465138d0fa223b0a0cadc1107893
> {noformat}
> java.lang.NullPointerException
>   at 
> com.gemstone.gemfire.distributed.internal.deadlock.DeadlockDetector.prettyFormat(DeadlockDetector.java:151)
>   at 
> com.gemstone.gemfire.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction(GemFireDeadlockDetectorDUnitTest.java:118)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor215.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.GeneratedMethodAccessor214.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   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

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2632:


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

GEODE-2632: refactor code to reduce GemFireCacheImpl dependencies

* extract fetching GemFireCacheImpl to Provider interface/class
* use InternalCache instead of casting to Impl
* delete useless javadocs and comments
* reduce scope of constants, vars and methods


> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



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

[jira] [Commented] (GEODE-728) Rename Execution.withArgs to Execution.setArguments

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-728:
---

Commit 5891ed7c4306e761c1f12edf85401ab140429d04 in geode's branch 
refs/heads/feature/GEODE-2097 from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5891ed7 ]

GEODE-728: Using the correct parameter in withArgs

ServerRegionFunctionExecutor.withArgs was not using it's argument, it
was just passing the (null) field named args to setArguments.


> Rename Execution.withArgs to Execution.setArguments
> ---
>
> Key: GEODE-728
> URL: https://issues.apache.org/jira/browse/GEODE-728
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, functions
>Reporter: Dan Smith
>Assignee: Alyssa Kim
> Fix For: 1.2.0
>
>
> FunctionContext has a getArguments method. withArgs should be renamed to 
> match.
> See this discussion on the mailing list.
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201512.mbox/browser



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

[jira] [Commented] (GEODE-576) CI Failure: GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-576:
---

Commit 50686b0b44024d2bcbb4bea8a36ce3a40ac158c2 in geode's branch 
refs/heads/feature/GEODE-2097 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=50686b0 ]

GEODE-576 & GEODE-516: GemFireDeadlockDetectorDUnitTest failures

Replaced pauses with Awaitility.  Modified asyncs to use the DUnit
blackboard to synchronize their actions for repeatable behavior.
Cleaned up static locks to allow their reuse in other tests or in
repeating the same test.


> CI Failure: 
> GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction
> 
>
> Key: GEODE-576
> URL: https://issues.apache.org/jira/browse/GEODE-576
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: Barry Oglesby
>  Labels: CI, Flaky
> Fix For: 1.2.0
>
>
> Geode_develop_DistributedTests
> Private Build #612 (Nov 17, 2015 5:09:11 PM)
> Revision: 90b9a632b9738319fc7a7fddb93b6bef9ff57f7d
> Error Message
> {noformat}
> java.lang.Exception: An exception occured during async invocation
> {noformat}
> Stacktrace
> {noformat}
> java.lang.Exception: An exception occured during async invocation
>   at dunit.AsyncInvocation.getResult(AsyncInvocation.java:195)
>   at 
> com.gemstone.gemfire.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction(GemFireDeadlockDetectorDUnitTest.java:121)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor137.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.GeneratedMethodAccessor136.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> 

[jira] [Commented] (GEODE-2808) Deadlock in tomcat session module during session expiration

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2808:


Commit 45dc6744154a08986e833852ef743af5d8bf19ba in geode's branch 
refs/heads/feature/GEODE-2097 from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=45dc674 ]

GEODE-2808 - Fixing lock ordering issues in DeltaSession

Region expiration of sessions and explicit expiration of sessions had
lock ordering issues. Fixing the code so that expiration goes through
the region entry lock first, before getting the lock on StandardSession.

Adding a workaround for the fact that liferay calls removeAttribute
from within session expiration by ignoreing remoteAttribute calls during
expiration.

This closes #472


> Deadlock in tomcat session module during session expiration
> ---
>
> Key: GEODE-2808
> URL: https://issues.apache.org/jira/browse/GEODE-2808
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Dan Smith
>Assignee: Dan Smith
> Fix For: 1.2.0
>
>
> We observed a deadlock in the tomcat session state replication module due to 
> the way we do expiration. Here are the threads that are involved:
> {noformat}
> Found one Java-level deadlock:
> =
> "http-nio-21064-exec-2":
>   waiting to lock monitor 0x7f9a04bde298 (object 0x0007947da1f0, a 
> org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey),
>   which is held by "Timer-1"
> "Timer-1":
>   waiting to lock monitor 0x7f99a4004e38 (object 0x0007947da240, a 
> org.apache.geode.modules.session.catalina.DeltaSession8),
>   which is held by "http-nio-21064-exec-2"
> Java stack information for the threads listed above:
> ===
> "http-nio-21064-exec-2":
>   at 
> org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1228)
>   - waiting to lock <0x0007947da1f0> (a 
> org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey)
>   at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6785)
>   at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6762)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.destroyExistingEntry(LocalRegionDataView.java:55)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicDestroy(LocalRegion.java:6724)
>   at 
> org.apache.geode.internal.cache.LocalRegion.validatedDestroy(LocalRegion.java:1110)
>   at 
> org.apache.geode.internal.cache.LocalRegion.destroy(LocalRegion.java:1095)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.destroy(AbstractRegion.java:271)
>   at 
> org.apache.geode.modules.session.catalina.AbstractSessionCache.destroySession(AbstractSessionCache.java:72)
>   at 
> org.apache.geode.modules.session.catalina.DeltaSessionManager.remove(DeltaSessionManager.java:405)
>   at 
> org.apache.catalina.session.StandardSession.expire(StandardSession.java:850)
>   - locked <0x0007947da240> (a 
> org.apache.geode.modules.session.catalina.DeltaSession8)
>   at 
> org.apache.catalina.session.StandardSession.isValid(StandardSession.java:682)
>   at org.apache.catalina.connector.Request.doGetSession(Request.java:2917)
>   at org.apache.catalina.connector.Request.getSession(Request.java:2367)
>   at 
> org.apache.geode.modules.session.catalina.CommitSessionValve.invoke(CommitSessionValve.java:50)
>   at 
> org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:46)
>   at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:474)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
>   at 
> org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:46)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
>   at 
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)
>   at 
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
>   at 
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:789)
>   at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1437)
>   at 
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
>   - locked 

[jira] [Commented] (GEODE-2799) ClassCastException: java.lang.Long cannot be cast to org.apache.geode.internal.cache.AbstractRegionEntry could occur in race condition

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2799:


Commit 60ec931f53ead9a18950fb4b8e441ff3e9993820 in geode's branch 
refs/heads/feature/GEODE-2097 from [~eshu]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=60ec931 ]

GEODE-2799: Handle different types of KeyInfo set when creating the KeySet 
Iterator.


> ClassCastException: java.lang.Long cannot be cast to 
> org.apache.geode.internal.cache.AbstractRegionEntry could occur in race 
> condition
> --
>
> Key: GEODE-2799
> URL: https://issues.apache.org/jira/browse/GEODE-2799
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Eric Shu
>Assignee: Eric Shu
> Fix For: 1.2.0
>
>
> {noformat}
> java.lang.ClassCastException: java.lang.Long cannot be cast to 
> org.apache.geode.internal.cache.AbstractRegionEntry
> at 
> org.apache.geode.internal.cache.LocalRegionDataView.getKeyForIterator(LocalRegionDataView.java:203)
> at 
> org.apache.geode.internal.cache.TXStateProxyImpl.getKeyForIterator(TXStateProxyImpl.java:766)
> at 
> org.apache.geode.internal.cache.EntriesSet$EntriesIterator.moveNext(EntriesSet.java:159)
> at 
> org.apache.geode.internal.cache.EntriesSet$EntriesIterator.(EntriesSet.java:118)
> at org.apache.geode.internal.cache.EntriesSet.iterator(EntriesSet.java:83)
> at java.util.AbstractCollection.addAll(AbstractCollection.java:343)
> at java.util.TreeSet.addAll(TreeSet.java:312)
> at java.util.TreeSet.(TreeSet.java:160)
> at 
> org.apache.geode.internal.cache.BucketRegionQueue.initializeEventSeqNumQueue(BucketRegionQueue.java:145)
> at 
> org.apache.geode.internal.cache.BucketRegionQueue.cleanUpDestroyedTokensAndMarkGIIComplete(BucketRegionQueue.java:108)
> at 
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1288)
> at 
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1080)
> at 
> org.apache.geode.internal.cache.BucketRegion.initialize(BucketRegion.java:251)
> at 
> org.apache.geode.internal.cache.LocalRegion.createSubregion(LocalRegion.java:960)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.createBucketRegion(PartitionedRegionDataStore.java:736)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucket(PartitionedRegionDataStore.java:424)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucketRecursively(PartitionedRegionDataStore.java:282)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabBucket(PartitionedRegionDataStore.java:2860)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.handleManageBucketRequest(PartitionedRegionDataStore.java:1001)
> at 
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketOnMember(PRHARedundancyProvider.java:1214)
> at 
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketInstance(PRHARedundancyProvider.java:390)
> at 
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketAtomically(PRHARedundancyProvider.java:578)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.createBucket(PartitionedRegion.java:3257)
> at 
> org.apache.geode.internal.cache.partitioned.RegionAdvisor$BucketSet$BucketSetIterator.next(RegionAdvisor.java:1422)
> at 
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet$KeysSetIterator.getNextBucketIter(PartitionedRegion.java:6247)
> at 
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet$KeysSetIterator.hasNext(PartitionedRegion.java:6220)
> at 
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet.toArray(PartitionedRegion.java:6322)
> at 
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet.toArray(PartitionedRegion.java:6316)
> at java.util.Collections$UnmodifiableCollection.toArray(Collections.java:1033)
> at java.util.ArrayList.addAll(ArrayList.java:577)
> {noformat}
> KeySet createIterator in transaction always creates keyset(). When a 
> transaction accesses the items, it suspends the transaction and assumes the 
> items provided by iterator are AbrstractRegionEntry.
> private void createIterator(final LocalRegion rgn) {
>   // TX iterates over KEYS.
>   // NonTX iterates over RegionEntry instances
>   this.currRgn = rgn;
>   this.currItr = view.getRegionKeysForIteration(rgn).iterator();
>   this.additionalKeysFromView = view.getAdditionalKeysForIterator(rgn);
> }



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

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2632:


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

GEODE-2632: refactor code to use InternalCache instead of GemFireCacheImpl

* minor cleanup also


> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



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

[jira] [Commented] (GEODE-2796) NPE in ClassPathLoader

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2796:


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

GEODE-2796: ClassPathLoader does not blow up with null TCCL


> NPE in ClassPathLoader
> --
>
> Key: GEODE-2796
> URL: https://issues.apache.org/jira/browse/GEODE-2796
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> It looks like an NPE was introduced by the fix for GEODE-2290:
> {noformat}
> Caused by: java.lang.NullPointerException
> at 
> org.apache.geode.internal.ClassPathLoader.getResource(ClassPathLoader.java:130)
> at 
> org.apache.geode.internal.ClassPathLoader.getResourceAsStream(ClassPathLoader.java:239)
> at 
> org.apache.geode.internal.ClassPathLoader.getResourceAsStream(ClassPathLoader.java:264)
> at 
> org.apache.geode.internal.GemFireVersion$VersionDescription.(GemFireVersion.java:191)
> at 
> org.apache.geode.internal.GemFireVersion.getDescription(GemFireVersion.java:52)
> at 
> org.apache.geode.internal.GemFireVersion.getGemFireVersion(GemFireVersion.java:66)
> at org.apache.geode.cache.CacheFactory.getVersion(CacheFactory.java:305)
> ...
> {noformat}
> This is caused by the following method: 
> {noformat}
>  private List getClassLoaders() {
> ArrayList classLoaders = new ArrayList<>();
> if (!excludeTCCL) {
>   classLoaders.add(Thread.currentThread().getContextClassLoader());
> }
> classLoaders.add(classLoaderForDeployedJars);
> return classLoaders;
>   }
> {noformat}
> According to the JavaDocs, `getContextClassLoader()` actually returns null to 
> indicate the system class loader (rather than actually returning the system 
> class loader).



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

[jira] [Commented] (GEODE-728) Rename Execution.withArgs to Execution.setArguments

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-728:
---

Commit aaef124e3d4d7b46c82ddb4d2af65ee48b73ba53 in geode's branch 
refs/heads/feature/GEODE-2097 from [~dalyssakim]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=aaef124 ]

GEODE-728: Rename Execution.withArgs to Execution.setArguments

 * created setArguments
 * deprecated withArgs
 * implemented setArguments of all Execution implementations in Geode project
 * replaced all of withArgs with setArguments

This closes #457


> Rename Execution.withArgs to Execution.setArguments
> ---
>
> Key: GEODE-728
> URL: https://issues.apache.org/jira/browse/GEODE-728
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, functions
>Reporter: Dan Smith
>Assignee: Alyssa Kim
> Fix For: 1.2.0
>
>
> FunctionContext has a getArguments method. withArgs should be renamed to 
> match.
> See this discussion on the mailing list.
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201512.mbox/browser



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

[jira] [Commented] (GEODE-2808) Deadlock in tomcat session module during session expiration

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Deadlock in tomcat session module during session expiration
> ---
>
> Key: GEODE-2808
> URL: https://issues.apache.org/jira/browse/GEODE-2808
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Dan Smith
>Assignee: Dan Smith
>
> We observed a deadlock in the tomcat session state replication module due to 
> the way we do expiration. Here are the threads that are involved:
> {noformat}
> Found one Java-level deadlock:
> =
> "http-nio-21064-exec-2":
>   waiting to lock monitor 0x7f9a04bde298 (object 0x0007947da1f0, a 
> org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey),
>   which is held by "Timer-1"
> "Timer-1":
>   waiting to lock monitor 0x7f99a4004e38 (object 0x0007947da240, a 
> org.apache.geode.modules.session.catalina.DeltaSession8),
>   which is held by "http-nio-21064-exec-2"
> Java stack information for the threads listed above:
> ===
> "http-nio-21064-exec-2":
>   at 
> org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1228)
>   - waiting to lock <0x0007947da1f0> (a 
> org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey)
>   at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6785)
>   at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6762)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.destroyExistingEntry(LocalRegionDataView.java:55)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicDestroy(LocalRegion.java:6724)
>   at 
> org.apache.geode.internal.cache.LocalRegion.validatedDestroy(LocalRegion.java:1110)
>   at 
> org.apache.geode.internal.cache.LocalRegion.destroy(LocalRegion.java:1095)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.destroy(AbstractRegion.java:271)
>   at 
> org.apache.geode.modules.session.catalina.AbstractSessionCache.destroySession(AbstractSessionCache.java:72)
>   at 
> org.apache.geode.modules.session.catalina.DeltaSessionManager.remove(DeltaSessionManager.java:405)
>   at 
> org.apache.catalina.session.StandardSession.expire(StandardSession.java:850)
>   - locked <0x0007947da240> (a 
> org.apache.geode.modules.session.catalina.DeltaSession8)
>   at 
> org.apache.catalina.session.StandardSession.isValid(StandardSession.java:682)
>   at org.apache.catalina.connector.Request.doGetSession(Request.java:2917)
>   at org.apache.catalina.connector.Request.getSession(Request.java:2367)
>   at 
> org.apache.geode.modules.session.catalina.CommitSessionValve.invoke(CommitSessionValve.java:50)
>   at 
> org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:46)
>   at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:474)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
>   at 
> org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:46)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
>   at 
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)
>   at 
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
>   at 
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:789)
>   at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1437)
>   at 
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
>   - locked <0x0007948d6870> (a 
> org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>   at java.lang.Thread.run(Thread.java:745)
> "Timer-1":
>   at 
> org.apache.catalina.session.StandardSession.expire(StandardSession.java:791)
>   - waiting to lock <0x0007947da240> (a 
> 

[GitHub] geode pull request #472: GEODE-2808 - Fixing lock ordering issues in DeltaSe...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2808) Deadlock in tomcat session module during session expiration

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2808:


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

GEODE-2808 - Fixing lock ordering issues in DeltaSession

Region expiration of sessions and explicit expiration of sessions had
lock ordering issues. Fixing the code so that expiration goes through
the region entry lock first, before getting the lock on StandardSession.

Adding a workaround for the fact that liferay calls removeAttribute
from within session expiration by ignoreing remoteAttribute calls during
expiration.

This closes #472


> Deadlock in tomcat session module during session expiration
> ---
>
> Key: GEODE-2808
> URL: https://issues.apache.org/jira/browse/GEODE-2808
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Dan Smith
>Assignee: Dan Smith
>
> We observed a deadlock in the tomcat session state replication module due to 
> the way we do expiration. Here are the threads that are involved:
> {noformat}
> Found one Java-level deadlock:
> =
> "http-nio-21064-exec-2":
>   waiting to lock monitor 0x7f9a04bde298 (object 0x0007947da1f0, a 
> org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey),
>   which is held by "Timer-1"
> "Timer-1":
>   waiting to lock monitor 0x7f99a4004e38 (object 0x0007947da240, a 
> org.apache.geode.modules.session.catalina.DeltaSession8),
>   which is held by "http-nio-21064-exec-2"
> Java stack information for the threads listed above:
> ===
> "http-nio-21064-exec-2":
>   at 
> org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1228)
>   - waiting to lock <0x0007947da1f0> (a 
> org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey)
>   at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6785)
>   at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6762)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.destroyExistingEntry(LocalRegionDataView.java:55)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicDestroy(LocalRegion.java:6724)
>   at 
> org.apache.geode.internal.cache.LocalRegion.validatedDestroy(LocalRegion.java:1110)
>   at 
> org.apache.geode.internal.cache.LocalRegion.destroy(LocalRegion.java:1095)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.destroy(AbstractRegion.java:271)
>   at 
> org.apache.geode.modules.session.catalina.AbstractSessionCache.destroySession(AbstractSessionCache.java:72)
>   at 
> org.apache.geode.modules.session.catalina.DeltaSessionManager.remove(DeltaSessionManager.java:405)
>   at 
> org.apache.catalina.session.StandardSession.expire(StandardSession.java:850)
>   - locked <0x0007947da240> (a 
> org.apache.geode.modules.session.catalina.DeltaSession8)
>   at 
> org.apache.catalina.session.StandardSession.isValid(StandardSession.java:682)
>   at org.apache.catalina.connector.Request.doGetSession(Request.java:2917)
>   at org.apache.catalina.connector.Request.getSession(Request.java:2367)
>   at 
> org.apache.geode.modules.session.catalina.CommitSessionValve.invoke(CommitSessionValve.java:50)
>   at 
> org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:46)
>   at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:474)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
>   at 
> org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:46)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
>   at 
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)
>   at 
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
>   at 
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:789)
>   at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1437)
>   at 
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
>   - locked <0x0007948d6870> (a 
> 

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #531 was successful.
---
Scheduled
1845 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: Review Request 58537: GEODE-2632: refactor code in geode-web-api to reduce GemFireCacheImpl dependencies

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On April 19, 2017, 11:05 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58537/
> ---
> 
> (Updated April 19, 2017, 11:05 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, and Ken Howe.
> 
> 
> Bugs: GEODE-2632
> https://issues.apache.org/jira/browse/GEODE-2632
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2632: refactor code in geode-web-api to reduce GemFireCacheImpl 
> dependencies
> 
> * extract fetching GemFireCacheImpl to Provider interface/class
> * use InternalCache instead of casting to Impl
> * delete useless javadocs and comments
> * reduce scope of constants, vars and methods
> * reorganize imports
> 
> I know that CacheProviderImpl still uses GemFireCacheImpl.getExisting, but 
> AbstractBaseController is now isolated from that so we can introduce better 
> unit testing by providing a mock of InternalCache at a later date. I decided 
> to package up the diff for geode-web-api as its own review and get it out of 
> the way of the geode-core refactorings.
> 
> 
> Diffs
> -
> 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/controllers/AbstractBaseController.java
>  68080a3f27190eafb1541788b4f6bd6c93bd5346 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/controllers/BaseControllerAdvice.java
>  89395425588abef7ff61a34aa30dfbe387342f89 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/controllers/CommonCrudController.java
>  62ce8609b437d02f43996cbb58d9fbbb33c9344e 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/controllers/FunctionAccessController.java
>  e9b61f405c6c64f78551e137e1b98da02f920c4c 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/controllers/PdxBasedCrudController.java
>  3b08c5fafd85d9513395037e01453a5f1fc94667 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/controllers/QueryAccessController.java
>  b00a7aa2d5d7439ba7c2d25fdd322448522cdf90 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/controllers/support/CacheProvider.java
>  PRE-CREATION 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/controllers/support/CacheProviderImpl.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/58537/diff/3/
> 
> 
> Testing
> ---
> 
> precheckin passed
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 58518: GEODE-2795: Clean up DUnit VMs after dynamically changing 'user.dir'

[Jared Stewart]

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

(Updated April 21, 2017, 10:34 p.m.)


Review request for geode, Jinmei Liao, Ken Howe, and Kirk Lund.


Changes
---

This should be the final revision, precheckin runs green.


Repository: geode


Description
---

GEODE-2795: Clean up DUnit VMs after dynamically changing 'user.dir'

- LocatorServerStarterRule will now always bounce the DUnit VMs in after() to 
prevent corrupted cached values of `System.getProperty('user.dir')` that refer 
to a temporary folder which no longer exists.


Diffs (updated)
-

  
geode-core/src/test/java/org/apache/geode/management/ConnectToLocatorSSLDUnitTest.java
 1033b6c 
  geode-core/src/test/java/org/apache/geode/management/JMXMBeanDUnitTest.java 
ebc3f17 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
 d47b343 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigTestBase.java
 c5aaa74 
  geode-core/src/test/java/org/apache/geode/test/dunit/VM.java 0b188ae 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/CleanupDUnitVMsRule.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
 34506c4 


Diff: https://reviews.apache.org/r/58518/diff/3/

Changes: https://reviews.apache.org/r/58518/diff/2-3/


Testing
---

Precheckin started (still running)


Thanks,

Jared Stewart

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2632:


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

GEODE-2632: refactor code to reduce GemFireCacheImpl dependencies

* extract fetching GemFireCacheImpl to Provider interface/class
* use InternalCache instead of casting to Impl
* delete useless javadocs and comments
* reduce scope of constants, vars and methods


> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



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

Re: Review Request 58628: GEODE-2785: Fix a test issue with additional afterSecondary invocations

[Eric Shu]

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

(Updated April 21, 2017, 9:14 p.m.)


Review request for geode, anilkumar gingade, Darrel Schneider, Jason Huynh, and 
Lynn Gallinat.


Changes
---

Actual changes.


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


Repository: geode


Description
---

Verify that all buckets lost primary get the afterSecondary callbacks.


Diffs (updated)
-

  
geode-core/src/test/java/org/apache/geode/internal/cache/PartitionListenerDUnitTest.java
 7fd470f 


Diff: https://reviews.apache.org/r/58628/diff/3/

Changes: https://reviews.apache.org/r/58628/diff/2-3/


Testing
---

precheckin


Thanks,

Eric Shu

Re: Review Request 58628: GEODE-2785: Fix a test issue with additional afterSecondary invocations

[Eric Shu]

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

(Updated April 21, 2017, 9:12 p.m.)


Review request for geode, anilkumar gingade, Darrel Schneider, Jason Huynh, and 
Lynn Gallinat.


Changes
---

Fix a copy paste error.


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


Repository: geode


Description
---

Verify that all buckets lost primary get the afterSecondary callbacks.


Diffs (updated)
-

  
geode-core/src/test/java/org/apache/geode/internal/cache/PartitionListenerDUnitTest.java
 9c38948 


Diff: https://reviews.apache.org/r/58628/diff/2/

Changes: https://reviews.apache.org/r/58628/diff/1-2/


Testing
---

precheckin


Thanks,

Eric Shu

[jira] [Resolved] (GEODE-2799) ClassCastException: java.lang.Long cannot be cast to org.apache.geode.internal.cache.AbstractRegionEntry could occur in race condition

[Eric Shu (JIRA)]

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

Eric Shu resolved GEODE-2799.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> ClassCastException: java.lang.Long cannot be cast to 
> org.apache.geode.internal.cache.AbstractRegionEntry could occur in race 
> condition
> --
>
> Key: GEODE-2799
> URL: https://issues.apache.org/jira/browse/GEODE-2799
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Eric Shu
>Assignee: Eric Shu
> Fix For: 1.2.0
>
>
> {noformat}
> java.lang.ClassCastException: java.lang.Long cannot be cast to 
> org.apache.geode.internal.cache.AbstractRegionEntry
> at 
> org.apache.geode.internal.cache.LocalRegionDataView.getKeyForIterator(LocalRegionDataView.java:203)
> at 
> org.apache.geode.internal.cache.TXStateProxyImpl.getKeyForIterator(TXStateProxyImpl.java:766)
> at 
> org.apache.geode.internal.cache.EntriesSet$EntriesIterator.moveNext(EntriesSet.java:159)
> at 
> org.apache.geode.internal.cache.EntriesSet$EntriesIterator.(EntriesSet.java:118)
> at org.apache.geode.internal.cache.EntriesSet.iterator(EntriesSet.java:83)
> at java.util.AbstractCollection.addAll(AbstractCollection.java:343)
> at java.util.TreeSet.addAll(TreeSet.java:312)
> at java.util.TreeSet.(TreeSet.java:160)
> at 
> org.apache.geode.internal.cache.BucketRegionQueue.initializeEventSeqNumQueue(BucketRegionQueue.java:145)
> at 
> org.apache.geode.internal.cache.BucketRegionQueue.cleanUpDestroyedTokensAndMarkGIIComplete(BucketRegionQueue.java:108)
> at 
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1288)
> at 
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1080)
> at 
> org.apache.geode.internal.cache.BucketRegion.initialize(BucketRegion.java:251)
> at 
> org.apache.geode.internal.cache.LocalRegion.createSubregion(LocalRegion.java:960)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.createBucketRegion(PartitionedRegionDataStore.java:736)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucket(PartitionedRegionDataStore.java:424)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucketRecursively(PartitionedRegionDataStore.java:282)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabBucket(PartitionedRegionDataStore.java:2860)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.handleManageBucketRequest(PartitionedRegionDataStore.java:1001)
> at 
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketOnMember(PRHARedundancyProvider.java:1214)
> at 
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketInstance(PRHARedundancyProvider.java:390)
> at 
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketAtomically(PRHARedundancyProvider.java:578)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.createBucket(PartitionedRegion.java:3257)
> at 
> org.apache.geode.internal.cache.partitioned.RegionAdvisor$BucketSet$BucketSetIterator.next(RegionAdvisor.java:1422)
> at 
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet$KeysSetIterator.getNextBucketIter(PartitionedRegion.java:6247)
> at 
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet$KeysSetIterator.hasNext(PartitionedRegion.java:6220)
> at 
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet.toArray(PartitionedRegion.java:6322)
> at 
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet.toArray(PartitionedRegion.java:6316)
> at java.util.Collections$UnmodifiableCollection.toArray(Collections.java:1033)
> at java.util.ArrayList.addAll(ArrayList.java:577)
> {noformat}
> KeySet createIterator in transaction always creates keyset(). When a 
> transaction accesses the items, it suspends the transaction and assumes the 
> items provided by iterator are AbrstractRegionEntry.
> private void createIterator(final LocalRegion rgn) {
>   // TX iterates over KEYS.
>   // NonTX iterates over RegionEntry instances
>   this.currRgn = rgn;
>   this.currItr = view.getRegionKeysForIteration(rgn).iterator();
>   this.additionalKeysFromView = view.getAdditionalKeysForIterator(rgn);
> }



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

[jira] [Commented] (GEODE-2799) ClassCastException: java.lang.Long cannot be cast to org.apache.geode.internal.cache.AbstractRegionEntry could occur in race condition

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2799:


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

GEODE-2799: Handle different types of KeyInfo set when creating the KeySet 
Iterator.


> ClassCastException: java.lang.Long cannot be cast to 
> org.apache.geode.internal.cache.AbstractRegionEntry could occur in race 
> condition
> --
>
> Key: GEODE-2799
> URL: https://issues.apache.org/jira/browse/GEODE-2799
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Eric Shu
>Assignee: Eric Shu
>
> {noformat}
> java.lang.ClassCastException: java.lang.Long cannot be cast to 
> org.apache.geode.internal.cache.AbstractRegionEntry
> at 
> org.apache.geode.internal.cache.LocalRegionDataView.getKeyForIterator(LocalRegionDataView.java:203)
> at 
> org.apache.geode.internal.cache.TXStateProxyImpl.getKeyForIterator(TXStateProxyImpl.java:766)
> at 
> org.apache.geode.internal.cache.EntriesSet$EntriesIterator.moveNext(EntriesSet.java:159)
> at 
> org.apache.geode.internal.cache.EntriesSet$EntriesIterator.(EntriesSet.java:118)
> at org.apache.geode.internal.cache.EntriesSet.iterator(EntriesSet.java:83)
> at java.util.AbstractCollection.addAll(AbstractCollection.java:343)
> at java.util.TreeSet.addAll(TreeSet.java:312)
> at java.util.TreeSet.(TreeSet.java:160)
> at 
> org.apache.geode.internal.cache.BucketRegionQueue.initializeEventSeqNumQueue(BucketRegionQueue.java:145)
> at 
> org.apache.geode.internal.cache.BucketRegionQueue.cleanUpDestroyedTokensAndMarkGIIComplete(BucketRegionQueue.java:108)
> at 
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1288)
> at 
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1080)
> at 
> org.apache.geode.internal.cache.BucketRegion.initialize(BucketRegion.java:251)
> at 
> org.apache.geode.internal.cache.LocalRegion.createSubregion(LocalRegion.java:960)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.createBucketRegion(PartitionedRegionDataStore.java:736)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucket(PartitionedRegionDataStore.java:424)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucketRecursively(PartitionedRegionDataStore.java:282)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabBucket(PartitionedRegionDataStore.java:2860)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.handleManageBucketRequest(PartitionedRegionDataStore.java:1001)
> at 
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketOnMember(PRHARedundancyProvider.java:1214)
> at 
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketInstance(PRHARedundancyProvider.java:390)
> at 
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketAtomically(PRHARedundancyProvider.java:578)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.createBucket(PartitionedRegion.java:3257)
> at 
> org.apache.geode.internal.cache.partitioned.RegionAdvisor$BucketSet$BucketSetIterator.next(RegionAdvisor.java:1422)
> at 
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet$KeysSetIterator.getNextBucketIter(PartitionedRegion.java:6247)
> at 
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet$KeysSetIterator.hasNext(PartitionedRegion.java:6220)
> at 
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet.toArray(PartitionedRegion.java:6322)
> at 
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet.toArray(PartitionedRegion.java:6316)
> at java.util.Collections$UnmodifiableCollection.toArray(Collections.java:1033)
> at java.util.ArrayList.addAll(ArrayList.java:577)
> {noformat}
> KeySet createIterator in transaction always creates keyset(). When a 
> transaction accesses the items, it suspends the transaction and assumes the 
> items provided by iterator are AbrstractRegionEntry.
> private void createIterator(final LocalRegion rgn) {
>   // TX iterates over KEYS.
>   // NonTX iterates over RegionEntry instances
>   this.currRgn = rgn;
>   this.currItr = view.getRegionKeysForIteration(rgn).iterator();
>   this.additionalKeysFromView = view.getAdditionalKeysForIterator(rgn);
> }



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

Review Request 58628: GEODE-2785: Fix a test issue with additional afterSecondary invocations

[Eric Shu]

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

Review request for geode, anilkumar gingade, Darrel Schneider, Jason Huynh, and 
Lynn Gallinat.


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


Repository: geode


Description
---

Verify that all buckets lost primary get the afterSecondary callbacks.


Diffs
-

  
geode-core/src/test/java/org/apache/geode/internal/cache/PartitionListenerDUnitTest.java
 9c38948 


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


Testing
---

precheckin


Thanks,

Eric Shu

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2632:


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

GEODE-2632: refactor code to use InternalCache instead of GemFireCacheImpl

* minor cleanup also


> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



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

[jira] [Commented] (GEODE-576) CI Failure: GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-576:
---

Commit 50686b0b44024d2bcbb4bea8a36ce3a40ac158c2 in geode's branch 
refs/heads/feature/GEODE-2632-5 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=50686b0 ]

GEODE-576 & GEODE-516: GemFireDeadlockDetectorDUnitTest failures

Replaced pauses with Awaitility.  Modified asyncs to use the DUnit
blackboard to synchronize their actions for repeatable behavior.
Cleaned up static locks to allow their reuse in other tests or in
repeating the same test.


> CI Failure: 
> GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction
> 
>
> Key: GEODE-576
> URL: https://issues.apache.org/jira/browse/GEODE-576
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: Barry Oglesby
>  Labels: CI, Flaky
> Fix For: 1.2.0
>
>
> Geode_develop_DistributedTests
> Private Build #612 (Nov 17, 2015 5:09:11 PM)
> Revision: 90b9a632b9738319fc7a7fddb93b6bef9ff57f7d
> Error Message
> {noformat}
> java.lang.Exception: An exception occured during async invocation
> {noformat}
> Stacktrace
> {noformat}
> java.lang.Exception: An exception occured during async invocation
>   at dunit.AsyncInvocation.getResult(AsyncInvocation.java:195)
>   at 
> com.gemstone.gemfire.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction(GemFireDeadlockDetectorDUnitTest.java:121)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor137.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.GeneratedMethodAccessor136.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> 

[jira] [Commented] (GEODE-2806) when batch is dispatched, if the bucket is not primary, we should still destroy the event from queue

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2806:


Commit 0862174c30cad1536f2c105b783653bd0d4344e8 in geode's branch 
refs/heads/feature/GEODE-2632-5 from zhouxh
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=0862174 ]

GEODE-2806: if the batch is dispatched, even the bucket is no longer primary, 
the batch should still be deleted as planned.


> when batch is dispatched, if the bucket is not primary, we should still 
> destroy the event from queue
> 
>
> Key: GEODE-2806
> URL: https://issues.apache.org/jira/browse/GEODE-2806
> Project: Geode
>  Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>  Labels: lucene
>
> This is one of the root causes for data mismatch. 
> When AEQ dispatched a batch, when it tried to destroy the events from queue, 
> the bucket might be no longer primary. There's no need to let the new primary 
> to re-dispatch the batch. 



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

[jira] [Created] (GEODE-2810) Set -Xmx for gfsh

[Swapnil Bawaskar (JIRA)]

Swapnil Bawaskar created GEODE-2810:
---

 Summary: Set -Xmx for gfsh
 Key: GEODE-2810
 URL: https://issues.apache.org/jira/browse/GEODE-2810
 Project: Geode
  Issue Type: Improvement
  Components: gfsh
Reporter: Swapnil Bawaskar


The gfsh JVM does not need to be huge. So, rather than letting the size of the 
JVM be determined at runtime based on which system it is being run, we should 
limit it to something reasonable. Say, -Xmx 128m.



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

[jira] [Commented] (GEODE-2808) Deadlock in tomcat session module during session expiration

[ASF GitHub Bot (JIRA)]

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

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

GitHub user upthewaterspout opened a pull request:

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

GEODE-2808 - Fixing lock ordering issues in DeltaSession

Region expiration of sessions and explicit expiration of sessions had
lock ordering issues. Fixing the code so that expiration goes through
the region entry lock first, before getting the lock on StandardSession.

Adding a workaround for the fact that liferay calls removeAttribute
from within session expiration by ignoreing remoteAttribute calls during
expiration.

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

$ git pull https://github.com/upthewaterspout/incubator-geode 
feature/GEODE-2808

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

https://github.com/apache/geode/pull/472.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #472


commit 8667c805d4a7b77cca2c883e34200169beab585a
Author: Dan Smith 
Date:   2017-04-21T18:36:24Z

GEODE-2808 - Fixing lock ordering issues in DeltaSession

Region expiration of sessions and explicit expiration of sessions had
lock ordering issues. Fixing the code so that expiration goes through
the region entry lock first, before getting the lock on StandardSession.

Adding a workaround for the fact that liferay calls removeAttribute
from within session expiration by ignoreing remoteAttribute calls during
expiration.




> Deadlock in tomcat session module during session expiration
> ---
>
> Key: GEODE-2808
> URL: https://issues.apache.org/jira/browse/GEODE-2808
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Dan Smith
>Assignee: Dan Smith
>
> We observed a deadlock in the tomcat session state replication module due to 
> the way we do expiration. Here are the threads that are involved:
> {noformat}
> Found one Java-level deadlock:
> =
> "http-nio-21064-exec-2":
>   waiting to lock monitor 0x7f9a04bde298 (object 0x0007947da1f0, a 
> org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey),
>   which is held by "Timer-1"
> "Timer-1":
>   waiting to lock monitor 0x7f99a4004e38 (object 0x0007947da240, a 
> org.apache.geode.modules.session.catalina.DeltaSession8),
>   which is held by "http-nio-21064-exec-2"
> Java stack information for the threads listed above:
> ===
> "http-nio-21064-exec-2":
>   at 
> org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1228)
>   - waiting to lock <0x0007947da1f0> (a 
> org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey)
>   at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6785)
>   at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6762)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.destroyExistingEntry(LocalRegionDataView.java:55)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicDestroy(LocalRegion.java:6724)
>   at 
> org.apache.geode.internal.cache.LocalRegion.validatedDestroy(LocalRegion.java:1110)
>   at 
> org.apache.geode.internal.cache.LocalRegion.destroy(LocalRegion.java:1095)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.destroy(AbstractRegion.java:271)
>   at 
> org.apache.geode.modules.session.catalina.AbstractSessionCache.destroySession(AbstractSessionCache.java:72)
>   at 
> org.apache.geode.modules.session.catalina.DeltaSessionManager.remove(DeltaSessionManager.java:405)
>   at 
> org.apache.catalina.session.StandardSession.expire(StandardSession.java:850)
>   - locked <0x0007947da240> (a 
> org.apache.geode.modules.session.catalina.DeltaSession8)
>   at 
> org.apache.catalina.session.StandardSession.isValid(StandardSession.java:682)
>   at org.apache.catalina.connector.Request.doGetSession(Request.java:2917)
>   at org.apache.catalina.connector.Request.getSession(Request.java:2367)
>   at 
> org.apache.geode.modules.session.catalina.CommitSessionValve.invoke(CommitSessionValve.java:50)
>   at 
> org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:46)
>   at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:474)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
>   at 
> 

[jira] [Commented] (GEODE-2808) Deadlock in tomcat session module during session expiration

[ASF GitHub Bot (JIRA)]

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

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

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/472
  
@jhuynh1 @boglesby 


> Deadlock in tomcat session module during session expiration
> ---
>
> Key: GEODE-2808
> URL: https://issues.apache.org/jira/browse/GEODE-2808
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Dan Smith
>Assignee: Dan Smith
>
> We observed a deadlock in the tomcat session state replication module due to 
> the way we do expiration. Here are the threads that are involved:
> {noformat}
> Found one Java-level deadlock:
> =
> "http-nio-21064-exec-2":
>   waiting to lock monitor 0x7f9a04bde298 (object 0x0007947da1f0, a 
> org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey),
>   which is held by "Timer-1"
> "Timer-1":
>   waiting to lock monitor 0x7f99a4004e38 (object 0x0007947da240, a 
> org.apache.geode.modules.session.catalina.DeltaSession8),
>   which is held by "http-nio-21064-exec-2"
> Java stack information for the threads listed above:
> ===
> "http-nio-21064-exec-2":
>   at 
> org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1228)
>   - waiting to lock <0x0007947da1f0> (a 
> org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey)
>   at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6785)
>   at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6762)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.destroyExistingEntry(LocalRegionDataView.java:55)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicDestroy(LocalRegion.java:6724)
>   at 
> org.apache.geode.internal.cache.LocalRegion.validatedDestroy(LocalRegion.java:1110)
>   at 
> org.apache.geode.internal.cache.LocalRegion.destroy(LocalRegion.java:1095)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.destroy(AbstractRegion.java:271)
>   at 
> org.apache.geode.modules.session.catalina.AbstractSessionCache.destroySession(AbstractSessionCache.java:72)
>   at 
> org.apache.geode.modules.session.catalina.DeltaSessionManager.remove(DeltaSessionManager.java:405)
>   at 
> org.apache.catalina.session.StandardSession.expire(StandardSession.java:850)
>   - locked <0x0007947da240> (a 
> org.apache.geode.modules.session.catalina.DeltaSession8)
>   at 
> org.apache.catalina.session.StandardSession.isValid(StandardSession.java:682)
>   at org.apache.catalina.connector.Request.doGetSession(Request.java:2917)
>   at org.apache.catalina.connector.Request.getSession(Request.java:2367)
>   at 
> org.apache.geode.modules.session.catalina.CommitSessionValve.invoke(CommitSessionValve.java:50)
>   at 
> org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:46)
>   at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:474)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
>   at 
> org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:46)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
>   at 
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)
>   at 
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
>   at 
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:789)
>   at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1437)
>   at 
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
>   - locked <0x0007948d6870> (a 
> org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>   at java.lang.Thread.run(Thread.java:745)
> "Timer-1":
>   at 
> org.apache.catalina.session.StandardSession.expire(StandardSession.java:791)
>   - waiting to lock <0x0007947da240> (a 
> 

[GitHub] geode issue #472: GEODE-2808 - Fixing lock ordering issues in DeltaSession

[upthewaterspout]

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/472
  
@jhuynh1 @boglesby 


---
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 #472: GEODE-2808 - Fixing lock ordering issues in DeltaSe...

[upthewaterspout]

GitHub user upthewaterspout opened a pull request:

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

GEODE-2808 - Fixing lock ordering issues in DeltaSession

Region expiration of sessions and explicit expiration of sessions had
lock ordering issues. Fixing the code so that expiration goes through
the region entry lock first, before getting the lock on StandardSession.

Adding a workaround for the fact that liferay calls removeAttribute
from within session expiration by ignoreing remoteAttribute calls during
expiration.

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

$ git pull https://github.com/upthewaterspout/incubator-geode 
feature/GEODE-2808

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

https://github.com/apache/geode/pull/472.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #472


commit 8667c805d4a7b77cca2c883e34200169beab585a
Author: Dan Smith 
Date:   2017-04-21T18:36:24Z

GEODE-2808 - Fixing lock ordering issues in DeltaSession

Region expiration of sessions and explicit expiration of sessions had
lock ordering issues. Fixing the code so that expiration goes through
the region entry lock first, before getting the lock on StandardSession.

Adding a workaround for the fact that liferay calls removeAttribute
from within session expiration by ignoreing remoteAttribute calls during
expiration.




---
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] [Reopened] (GEODE-2097) Offheap persistent heapLRU regions can run out of offheap memory during recovery

[Darrel Schneider (JIRA)]

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

Darrel Schneider reopened GEODE-2097:
-

the unit test introduced in this fix if failing intermittently.

> Offheap persistent heapLRU regions can run out of offheap memory during 
> recovery
> 
>
> Key: GEODE-2097
> URL: https://issues.apache.org/jira/browse/GEODE-2097
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> When the data for a persistent region is being recovered from the disk store 
> the lru limit is constantly checked. If the lru limit is exceeded then value 
> recovery will cease. But for off-heap regions this lru limit should be 
> checking how much off-heap memory has been allocated.
> During recovery the amount of heap memory is being checked for an offheap 
> regions. So we can end up recovering too many values to off-heap and running 
> out of off-heap memory during recovery.
> The code that causes this problem is: 
> org.apache.geode.internal.cache.lru.HeapLRUCapacityController.createLRUHelper().new
>  AbstractEnableLRU() {...}.mustEvict(LRUStatistics, Region, int)
> During off-heap disk store recovery the Region parameter passed to this 
> method is "null". This causes the following heap check to be done:
>if (region == null) {
>   return resourceManager.getHeapMonitor().getState().isEviction();
> }



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

[jira] [Resolved] (GEODE-2806) when batch is dispatched, if the bucket is not primary, we should still destroy the event from queue

[xiaojian zhou (JIRA)]

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

xiaojian zhou resolved GEODE-2806.
--
Resolution: Fixed

> when batch is dispatched, if the bucket is not primary, we should still 
> destroy the event from queue
> 
>
> Key: GEODE-2806
> URL: https://issues.apache.org/jira/browse/GEODE-2806
> Project: Geode
>  Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>  Labels: lucene
>
> This is one of the root causes for data mismatch. 
> When AEQ dispatched a batch, when it tried to destroy the events from queue, 
> the bucket might be no longer primary. There's no need to let the new primary 
> to re-dispatch the batch. 



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

[jira] [Commented] (GEODE-2808) Deadlock in tomcat session module during session expiration

[Dan Smith (JIRA)]

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

Dan Smith commented on GEODE-2808:
--

We hit a related deadlock with liferay portal during session expiration. 
Liferay adds a SessionListener that ends up removing an attribute from the 
session (see the below stack trace).

Unfortunately, this also has a lock ordering issue. The thread doing expiration 
does this:
  # Locks the entry in AbstractRegionMap.destroy
  # Calls StandardSession.expire, which notifies the liferay listener
  # The liferay listener calls removeAttribute, which gets 
DeltaSession8.changeLock.

However, an normal call to set attribute does this
  # Locks DeltaSession8.changeLock
  # Down inside region.put, locks the region entry.

So the liferay listener caused a deadlock because it locks the change lock 
*after* locking the region entry.

{noformat}
- waiting to lock <0x0006e4b1ca48> (a java.lang.Object)
at 
org.apache.catalina.session.StandardSession.removeAttribute(StandardSession.java:1324)
at 
org.apache.catalina.session.StandardSessionFacade.removeAttribute(StandardSessionFacade.java:173)
at 
com.liferay.portal.servlet.PortalSessionDestroyer.doPortalInit(PortalSessionDestroyer.java:81)
at 
com.liferay.portal.kernel.util.BasePortalLifecycle.portalInit(BasePortalLifecycle.java:44)
at 
com.liferay.portal.kernel.util.PortalLifecycleUtil.register(PortalLifecycleUtil.java:74)
at 
com.liferay.portal.kernel.util.BasePortalLifecycle.registerPortalLifecycle(BasePortalLifecycle.java:58)
at 
com.liferay.portal.servlet.PortalSessionDestroyer.(PortalSessionDestroyer.java:49)
at 
com.liferay.portal.servlet.PortalSessionListener.sessionDestroyed(PortalSessionListener.java:75)
{noformat}

> Deadlock in tomcat session module during session expiration
> ---
>
> Key: GEODE-2808
> URL: https://issues.apache.org/jira/browse/GEODE-2808
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Dan Smith
>Assignee: Dan Smith
>
> We observed a deadlock in the tomcat session state replication module due to 
> the way we do expiration. Here are the threads that are involved:
> {noformat}
> Found one Java-level deadlock:
> =
> "http-nio-21064-exec-2":
>   waiting to lock monitor 0x7f9a04bde298 (object 0x0007947da1f0, a 
> org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey),
>   which is held by "Timer-1"
> "Timer-1":
>   waiting to lock monitor 0x7f99a4004e38 (object 0x0007947da240, a 
> org.apache.geode.modules.session.catalina.DeltaSession8),
>   which is held by "http-nio-21064-exec-2"
> Java stack information for the threads listed above:
> ===
> "http-nio-21064-exec-2":
>   at 
> org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1228)
>   - waiting to lock <0x0007947da1f0> (a 
> org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey)
>   at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6785)
>   at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6762)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.destroyExistingEntry(LocalRegionDataView.java:55)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicDestroy(LocalRegion.java:6724)
>   at 
> org.apache.geode.internal.cache.LocalRegion.validatedDestroy(LocalRegion.java:1110)
>   at 
> org.apache.geode.internal.cache.LocalRegion.destroy(LocalRegion.java:1095)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.destroy(AbstractRegion.java:271)
>   at 
> org.apache.geode.modules.session.catalina.AbstractSessionCache.destroySession(AbstractSessionCache.java:72)
>   at 
> org.apache.geode.modules.session.catalina.DeltaSessionManager.remove(DeltaSessionManager.java:405)
>   at 
> org.apache.catalina.session.StandardSession.expire(StandardSession.java:850)
>   - locked <0x0007947da240> (a 
> org.apache.geode.modules.session.catalina.DeltaSession8)
>   at 
> org.apache.catalina.session.StandardSession.isValid(StandardSession.java:682)
>   at org.apache.catalina.connector.Request.doGetSession(Request.java:2917)
>   at org.apache.catalina.connector.Request.getSession(Request.java:2367)
>   at 
> org.apache.geode.modules.session.catalina.CommitSessionValve.invoke(CommitSessionValve.java:50)
>   at 
> org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:46)
>   at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:474)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
>   at 

Re: Review Request 58595: GEODE-2681: refactoring to prevent synchronization hang on getAnyInstance

[Jared Stewart]

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




geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunction.java
Line 63 (original), 60 (patched)


Since `entry.getKey()` is not used, I think this can be simplified to: 

```
for (Set entry : waitingRegions.values()) {
for (PersistentMemberID id : entry) {
memberMissingIDs.add(new PersistentMemberPattern(id));
}
}
```


- Jared Stewart


On April 20, 2017, 10:41 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58595/
> ---
> 
> (Updated April 20, 2017, 10:41 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This is a first pass review of the fix of gfsh hang on "show  
> missing-disk-stores" command when cache is initializing (i.e. waiting for a 
> missing disk-store). I'm working on a new DUnit test validate this change, 
> and will update the review when it's ready.
> 
> GEODE-2681: refactoring to prevent synchronization hang on getAnyInstance
> 
> In the JUnit test, renamed some variables to make things a more readable. 
> Also removed try/catches around unexpected Exceptions to let the testing 
> framework handle them.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunction.java
>  a2812faa1f0310fd7e1861fe5c3623cb9ba79f97 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java
>  1cfa24270c3e4b6a59156c70d3ba478307af234a 
> 
> 
> Diff: https://reviews.apache.org/r/58595/diff/2/
> 
> 
> Testing
> ---
> 
> Verified manually using the steps noted in GEODE-2798 (which is a dupilcate 
> of GEODE-2681.)
> 
> Precheckin has been started.
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

[jira] [Assigned] (GEODE-2809) Geode docs: Clarify SSL setup for client

[Dave Barnes (JIRA)]

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

Dave Barnes reassigned GEODE-2809:
--

Assignee: Dave Barnes

> Geode docs: Clarify SSL setup for client
> 
>
> Key: GEODE-2809
> URL: https://issues.apache.org/jira/browse/GEODE-2809
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> The page managing/security/implementing_ssl.html contains an example of 
> setting ssl properties for a client. It would be helpful to clarify which  
> properties refer to client-local entities (e.g. path to keystore) and which 
> are local reflections of server settings (e.g. whether locators and servers 
> are ssl-enabled).



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

[jira] [Created] (GEODE-2809) Geode docs: Clarify SSL setup for client

[Dave Barnes (JIRA)]

Dave Barnes created GEODE-2809:
--

 Summary: Geode docs: Clarify SSL setup for client
 Key: GEODE-2809
 URL: https://issues.apache.org/jira/browse/GEODE-2809
 Project: Geode
  Issue Type: Improvement
  Components: docs
Reporter: Dave Barnes


The page managing/security/implementing_ssl.html contains an example of setting 
ssl properties for a client. It would be helpful to clarify which  properties 
refer to client-local entities (e.g. path to keystore) and which are local 
reflections of server settings (e.g. whether locators and servers are 
ssl-enabled).



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

[jira] [Created] (GEODE-2808) Deadlock in tomcat session module during session expiration

[Dan Smith (JIRA)]

Dan Smith created GEODE-2808:


 Summary: Deadlock in tomcat session module during session 
expiration
 Key: GEODE-2808
 URL: https://issues.apache.org/jira/browse/GEODE-2808
 Project: Geode
  Issue Type: Bug
  Components: http session
Reporter: Dan Smith


We observed a deadlock in the tomcat session state replication module due to 
the way we do expiration. Here are the threads that are involved:

{noformat}
Found one Java-level deadlock:
=
"http-nio-21064-exec-2":
  waiting to lock monitor 0x7f9a04bde298 (object 0x0007947da1f0, a 
org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey),
  which is held by "Timer-1"
"Timer-1":
  waiting to lock monitor 0x7f99a4004e38 (object 0x0007947da240, a 
org.apache.geode.modules.session.catalina.DeltaSession8),
  which is held by "http-nio-21064-exec-2"

Java stack information for the threads listed above:
===
"http-nio-21064-exec-2":
at 
org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1228)
- waiting to lock <0x0007947da1f0> (a 
org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey)
at 
org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6785)
at 
org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6762)
at 
org.apache.geode.internal.cache.LocalRegionDataView.destroyExistingEntry(LocalRegionDataView.java:55)
at 
org.apache.geode.internal.cache.LocalRegion.basicDestroy(LocalRegion.java:6724)
at 
org.apache.geode.internal.cache.LocalRegion.validatedDestroy(LocalRegion.java:1110)
at 
org.apache.geode.internal.cache.LocalRegion.destroy(LocalRegion.java:1095)
at 
org.apache.geode.internal.cache.AbstractRegion.destroy(AbstractRegion.java:271)
at 
org.apache.geode.modules.session.catalina.AbstractSessionCache.destroySession(AbstractSessionCache.java:72)
at 
org.apache.geode.modules.session.catalina.DeltaSessionManager.remove(DeltaSessionManager.java:405)
at 
org.apache.catalina.session.StandardSession.expire(StandardSession.java:850)
- locked <0x0007947da240> (a 
org.apache.geode.modules.session.catalina.DeltaSession8)
at 
org.apache.catalina.session.StandardSession.isValid(StandardSession.java:682)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2917)
at org.apache.catalina.connector.Request.getSession(Request.java:2367)
at 
org.apache.geode.modules.session.catalina.CommitSessionValve.invoke(CommitSessionValve.java:50)
at 
org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:46)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:474)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at 
org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:46)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:789)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1437)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
- locked <0x0007948d6870> (a 
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
"Timer-1":
at 
org.apache.catalina.session.StandardSession.expire(StandardSession.java:791)
- waiting to lock <0x0007947da240> (a 
org.apache.geode.modules.session.catalina.DeltaSession8)
at 
org.apache.catalina.session.StandardSession.expire(StandardSession.java:766)
at 
org.apache.geode.modules.session.catalina.DeltaSession8.processExpired(DeltaSession8.java:320)
at 
org.apache.geode.modules.session.catalina.callback.SessionExpirationCacheListener.afterDestroy(SessionExpirationCacheListener.java:56)
at 

[jira] [Assigned] (GEODE-2808) Deadlock in tomcat session module during session expiration

[Dan Smith (JIRA)]

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

Dan Smith reassigned GEODE-2808:


Assignee: Dan Smith

> Deadlock in tomcat session module during session expiration
> ---
>
> Key: GEODE-2808
> URL: https://issues.apache.org/jira/browse/GEODE-2808
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Dan Smith
>Assignee: Dan Smith
>
> We observed a deadlock in the tomcat session state replication module due to 
> the way we do expiration. Here are the threads that are involved:
> {noformat}
> Found one Java-level deadlock:
> =
> "http-nio-21064-exec-2":
>   waiting to lock monitor 0x7f9a04bde298 (object 0x0007947da1f0, a 
> org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey),
>   which is held by "Timer-1"
> "Timer-1":
>   waiting to lock monitor 0x7f99a4004e38 (object 0x0007947da240, a 
> org.apache.geode.modules.session.catalina.DeltaSession8),
>   which is held by "http-nio-21064-exec-2"
> Java stack information for the threads listed above:
> ===
> "http-nio-21064-exec-2":
>   at 
> org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1228)
>   - waiting to lock <0x0007947da1f0> (a 
> org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey)
>   at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6785)
>   at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6762)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.destroyExistingEntry(LocalRegionDataView.java:55)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicDestroy(LocalRegion.java:6724)
>   at 
> org.apache.geode.internal.cache.LocalRegion.validatedDestroy(LocalRegion.java:1110)
>   at 
> org.apache.geode.internal.cache.LocalRegion.destroy(LocalRegion.java:1095)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.destroy(AbstractRegion.java:271)
>   at 
> org.apache.geode.modules.session.catalina.AbstractSessionCache.destroySession(AbstractSessionCache.java:72)
>   at 
> org.apache.geode.modules.session.catalina.DeltaSessionManager.remove(DeltaSessionManager.java:405)
>   at 
> org.apache.catalina.session.StandardSession.expire(StandardSession.java:850)
>   - locked <0x0007947da240> (a 
> org.apache.geode.modules.session.catalina.DeltaSession8)
>   at 
> org.apache.catalina.session.StandardSession.isValid(StandardSession.java:682)
>   at org.apache.catalina.connector.Request.doGetSession(Request.java:2917)
>   at org.apache.catalina.connector.Request.getSession(Request.java:2367)
>   at 
> org.apache.geode.modules.session.catalina.CommitSessionValve.invoke(CommitSessionValve.java:50)
>   at 
> org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:46)
>   at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:474)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
>   at 
> org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:46)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
>   at 
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)
>   at 
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
>   at 
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:789)
>   at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1437)
>   at 
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
>   - locked <0x0007948d6870> (a 
> org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>   at java.lang.Thread.run(Thread.java:745)
> "Timer-1":
>   at 
> org.apache.catalina.session.StandardSession.expire(StandardSession.java:791)
>   - waiting to lock <0x0007947da240> (a 
> org.apache.geode.modules.session.catalina.DeltaSession8)
>   at 
> org.apache.catalina.session.StandardSession.expire(StandardSession.java:766)
>   at 

Re: Review Request 58520: GEODE-2799: suspend the transaction when creating iterator if necessary

[Darrel Schneider]

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


Ship it!




Ship It!

- Darrel Schneider


On April 20, 2017, 11:33 a.m., Eric Shu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58520/
> ---
> 
> (Updated April 20, 2017, 11:33 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, and Lynn 
> Gallinat.
> 
> 
> Bugs: GEODE-2799
> https://issues.apache.org/jira/browse/GEODE-2799
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Return correct region keys in a transaction when creating iterator which will 
> be consumed later.
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
> 5d5044b 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegionDataView.java
>  b4aa20b 
>   geode-core/src/main/java/org/apache/geode/internal/cache/TXState.java 
> 234baee 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/TXStateProxyImplJUnitTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/58520/diff/3/
> 
> 
> Testing
> ---
> 
> precheckin.
> 
> 
> Thanks,
> 
> Eric Shu
> 
>

Re: Review Request 58599: GEODE:2802 Tombstone version vector to contain only the members that generate the tombstone.

[Darrel Schneider]

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



This fix does address one particular failure.
Should you also make some other changes to prevent and/or detect when it 
happens in other contexts?
One issue is the serialization of the TombstoneMessage. I think the toData code 
should be changed to detect that it was given a RegionVersionVector that has a 
mix of element types and fail with an exception thrown from toData. This is 
better than what currently happens which is we report corruption during 
fromData deserialization.

The other thing not to lose track of, but that probably should be a seperate 
ticket is that VMRegionVersionVector which is strongly typed to only have 
InternalDistributedMember elements can instead have DiskStoreID elements. We 
should change the implementation to never allow a mix but to also not say it is 
always InternalDistributedMember unless we enforce that (like we did for 
DiskStoreID on the DiskRegionVersionVector class). It was also reported that 
VersionedObjectList had a similar issue as TombstoneMessage and that should be 
looked into.

- Darrel Schneider


On April 20, 2017, 6:03 p.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58599/
> ---
> 
> (Updated April 20, 2017, 6:03 p.m.)
> 
> 
> Review request for geode, Darrel Schneider, Eric Shu, and Lynn Gallinat.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> TombstoneMessage serialization code assumes the member info in RVV to be 
> either membership-id or disk-id and uses this info while de-serializing.
> When there is a mix of persistent and non-persistent region in the cluster 
> (between nodes), the above assumption will not hold good; resulting in data 
> serialization exception.
> 
> When there is a mix of persistent and non-persistent region, the version info 
> is always generated from the persistent member. While constructing the 
> tombstone message, even though there is no tombstone version generated on 
> non-persistent member, it was added into the tombstone message, resulting in 
> mixed version source, causing deserialization failure.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/versions/RegionVersionVector.java
>  2e01c00 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/versions/TombstoneDUnitTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/58599/diff/1/
> 
> 
> Testing
> ---
> 
> Manual testing.
> Added new dunit test. Verified the failure without change.
> precheckin in progress.
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

Build failed in Jenkins: Geode-nightly #814

[Apache Jenkins Server]

See 


Changes:

[upthewaterspout] GEODE-728: Using the correct parameter in withArgs

--
[...truncated 117.13 KB...]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at sun.nio.fs.UnixPath.toRealPath(UnixPath.java:876)
at 
io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:215)
... 5 more

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

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

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

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

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

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:flakyTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources UP-TO-DATE
:geode-rebalancer:testClasses
:geode-rebalancer:checkMissedTests
:geode-rebalancer:spotlessJavaCheck
: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 

Re: Review Request 58595: GEODE-2681: refactoring to prevent synchronization hang on getAnyInstance

[Jinmei Liao]

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




geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunction.java
Line 53 (original), 53 (patched)


if (cache != null) {
if (cache != null && !cache.isClosed()) {
}
}

looks like we can get rid of the outer if?


- Jinmei Liao


On April 20, 2017, 10:41 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58595/
> ---
> 
> (Updated April 20, 2017, 10:41 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This is a first pass review of the fix of gfsh hang on "show  
> missing-disk-stores" command when cache is initializing (i.e. waiting for a 
> missing disk-store). I'm working on a new DUnit test validate this change, 
> and will update the review when it's ready.
> 
> GEODE-2681: refactoring to prevent synchronization hang on getAnyInstance
> 
> In the JUnit test, renamed some variables to make things a more readable. 
> Also removed try/catches around unexpected Exceptions to let the testing 
> framework handle them.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunction.java
>  a2812faa1f0310fd7e1861fe5c3623cb9ba79f97 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java
>  1cfa24270c3e4b6a59156c70d3ba478307af234a 
> 
> 
> Diff: https://reviews.apache.org/r/58595/diff/2/
> 
> 
> Testing
> ---
> 
> Verified manually using the steps noted in GEODE-2798 (which is a dupilcate 
> of GEODE-2681.)
> 
> Precheckin has been started.
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

[jira] [Commented] (GEODE-2806) when batch is dispatched, if the bucket is not primary, we should still destroy the event from queue

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2806:


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

GEODE-2806: if the batch is dispatched, even the bucket is no longer primary, 
the batch should still be deleted as planned.


> when batch is dispatched, if the bucket is not primary, we should still 
> destroy the event from queue
> 
>
> Key: GEODE-2806
> URL: https://issues.apache.org/jira/browse/GEODE-2806
> Project: Geode
>  Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>  Labels: lucene
>
> This is one of the root causes for data mismatch. 
> When AEQ dispatched a batch, when it tried to destroy the events from queue, 
> the bucket might be no longer primary. There's no need to let the new primary 
> to re-dispatch the batch. 



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

[jira] [Commented] (GEODE-2746) Investigate and Evaluate Existing RPC frameworks.

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan commented on GEODE-2746:
-

https://cwiki.apache.org/confluence/display/GEODE/RPC+framework+evaluation

> Investigate and Evaluate Existing RPC frameworks.
> -
>
> Key: GEODE-2746
> URL: https://issues.apache.org/jira/browse/GEODE-2746
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> There are several existing RPC frameworks for which you can define the 
> structure of your protocol and the tool will generate code for talking over 
> the wire, generally down to serialization of objects.
> If one of those RPC frameworks does not fit all our requirements, we'll 
> design our own binary protocol. This protocol would define both what kind of 
> messages can be sent and how they are encoded on the wire. How we encode the 
> objects that we are sending in requests, however, could still be pluggable.
> A few contenders:
> * [BERT|http://bert-rpc.org]
> * [thrift|https://thrift.apache.org/]
> * [gRPC|http://www.grpc.io/]
> * [Avro|https://avro.apache.org/]
> These are two not-entirely-common features we will need to have:
> * support for SSL/TLS, ability to connect to a server with IP & port.
> * support for push messages from the server without polling (this is needed 
> for CQs).
> This is one half of GEODE-2734.



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

[jira] [Resolved] (GEODE-576) CI Failure: GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt resolved GEODE-576.

   Resolution: Fixed
 Assignee: (was: Bruce Schuchardt)
Fix Version/s: 1.2.0

> CI Failure: 
> GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction
> 
>
> Key: GEODE-576
> URL: https://issues.apache.org/jira/browse/GEODE-576
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: Barry Oglesby
>  Labels: CI, Flaky
> Fix For: 1.2.0
>
>
> Geode_develop_DistributedTests
> Private Build #612 (Nov 17, 2015 5:09:11 PM)
> Revision: 90b9a632b9738319fc7a7fddb93b6bef9ff57f7d
> Error Message
> {noformat}
> java.lang.Exception: An exception occured during async invocation
> {noformat}
> Stacktrace
> {noformat}
> java.lang.Exception: An exception occured during async invocation
>   at dunit.AsyncInvocation.getResult(AsyncInvocation.java:195)
>   at 
> com.gemstone.gemfire.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction(GemFireDeadlockDetectorDUnitTest.java:121)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor137.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.GeneratedMethodAccessor136.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   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: dunit.RMIException: While invoking 
> com.gemstone.gemfire.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest$2.run
>  in VM 0 running on Host rooktwo.gemstone.com with 4 VMs
>   at dunit.VM.invoke(VM.java:369)
>   at dunit.VM$2.run(VM.java:220)
>   at java.lang.Thread.run(Thread.java:745)
>   at 

[jira] [Resolved] (GEODE-516) GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction has NullPointerException

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt resolved GEODE-516.

Resolution: Fixed
  Assignee: (was: Bruce Schuchardt)

> GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction has 
> NullPointerException
> -
>
> Key: GEODE-516
> URL: https://issues.apache.org/jira/browse/GEODE-516
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: xiaojian zhou
>  Labels: Flaky, ShowDeadlockCommand
>
> revision 0cc9d895b9f4465138d0fa223b0a0cadc1107893
> {noformat}
> java.lang.NullPointerException
>   at 
> com.gemstone.gemfire.distributed.internal.deadlock.DeadlockDetector.prettyFormat(DeadlockDetector.java:151)
>   at 
> com.gemstone.gemfire.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction(GemFireDeadlockDetectorDUnitTest.java:118)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor215.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.GeneratedMethodAccessor214.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   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] [Updated] (GEODE-516) GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction has NullPointerException

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt updated GEODE-516:
---
Fix Version/s: 1.2.0

> GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction has 
> NullPointerException
> -
>
> Key: GEODE-516
> URL: https://issues.apache.org/jira/browse/GEODE-516
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: xiaojian zhou
>  Labels: Flaky, ShowDeadlockCommand
> Fix For: 1.2.0
>
>
> revision 0cc9d895b9f4465138d0fa223b0a0cadc1107893
> {noformat}
> java.lang.NullPointerException
>   at 
> com.gemstone.gemfire.distributed.internal.deadlock.DeadlockDetector.prettyFormat(DeadlockDetector.java:151)
>   at 
> com.gemstone.gemfire.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction(GemFireDeadlockDetectorDUnitTest.java:118)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor215.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.GeneratedMethodAccessor214.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   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] [Commented] (GEODE-516) GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction has NullPointerException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-516:
---

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

GEODE-576 & GEODE-516: GemFireDeadlockDetectorDUnitTest failures

Replaced pauses with Awaitility.  Modified asyncs to use the DUnit
blackboard to synchronize their actions for repeatable behavior.
Cleaned up static locks to allow their reuse in other tests or in
repeating the same test.


> GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction has 
> NullPointerException
> -
>
> Key: GEODE-516
> URL: https://issues.apache.org/jira/browse/GEODE-516
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: xiaojian zhou
>Assignee: Bruce Schuchardt
>  Labels: Flaky, ShowDeadlockCommand
>
> revision 0cc9d895b9f4465138d0fa223b0a0cadc1107893
> {noformat}
> java.lang.NullPointerException
>   at 
> com.gemstone.gemfire.distributed.internal.deadlock.DeadlockDetector.prettyFormat(DeadlockDetector.java:151)
>   at 
> com.gemstone.gemfire.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction(GemFireDeadlockDetectorDUnitTest.java:118)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor215.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.GeneratedMethodAccessor214.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   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

[jira] [Commented] (GEODE-2763) Remove of nonSingleHopsCount stat in client

[ASF GitHub Bot (JIRA)]

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

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

Github user ameybarve15 commented on the issue:

https://github.com/apache/geode-native/pull/90
  
Ok, but for this branch I have already merged develop, Let me know If you 
can merge this request in this state or else I will create a new branch again 
and follow the entire procedure again


> Remove of nonSingleHopsCount stat in client
> ---
>
> Key: GEODE-2763
> URL: https://issues.apache.org/jira/browse/GEODE-2763
> Project: Geode
>  Issue Type: Bug
>  Components: docs, native client
>Reporter: Michael Dodge
>Assignee: Amey Barve
>
> A pre-existing issue (GEODE-2017) required the removal of the 
> nonSingleHopsCount statistic in the clients. Whilst marked for the native 
> client as well, it was not addressed in the native client. It should be.



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

[GitHub] geode-native issue #90: GEODE-2763: Remove of nonSingleHopsCount stat in cli...

[ameybarve15]

Github user ameybarve15 commented on the issue:

https://github.com/apache/geode-native/pull/90
  
Ok, but for this branch I have already merged develop, Let me know If you 
can merge this request in this state or else I will create a new branch again 
and follow the entire procedure again


---
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 58550: AEQ regions being created before the user regions

[nabarun nag]

> On April 21, 2017, 6:21 a.m., xiaojian zhou wrote:
> > geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/AbstractPartitionedRepositoryManager.java
> > Line 57 (original), 58 (patched)
> > 
> >
> > According to your code, the getRegionPath() will return null here. Is 
> > that by design? It looks like you purpursely hack the code to leave 
> > userRegion as null for a while. But actually it's not necessary. A simpler 
> > way is: you just specify the data region path in index, since data region 
> > not created yet, it will be null here.

yes gester, you are right. the region name will be null here. This was just to 
satisfy a JUnit test. The three lines [57,58,59] will be removed eventually.


> On April 21, 2017, 6:21 a.m., xiaojian zhou wrote:
> > geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneRawIndex.java
> > Lines 28 (patched)
> > 
> >
> > This is wrong. You have to move the createRepositoryManager() into this 
> > method. 
> > 
> > You need to test the RawIndex to make sure it did work after your code 
> > changes.

I agree. this solution of creating AEQ before region was a kind of prototype 
solution. We wanted to make sure if we are in the right path before changing 
the RAW index module


- nabarun


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


On April 20, 2017, 2:03 a.m., nabarun nag wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58550/
> ---
> 
> (Updated April 20, 2017, 2:03 a.m.)
> 
> 
> Review request for geode, Jason Huynh and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Testing a new start up mechanism where the AEQ is created before the user 
> region. Please review and let us know if any modifications are needed, or if 
> this is a viable solution
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/AbstractPartitionedRepositoryManager.java
>  26bb488ed 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneEventListener.java
>  0f5553343 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
>  fea484547 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexImpl.java
>  36f6720c3 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexImplFactory.java
>  e99f3d9db 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneRawIndex.java
>  75ab5cab3 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneRegionListener.java
>  f4e2a79ef 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneServiceImpl.java
>  30952bfe2 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/LuceneEventListenerJUnitTest.java
>  79de29a09 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/LuceneIndexForPartitionedRegionTest.java
>  8e4c179a5 
> 
> 
> Diff: https://reviews.apache.org/r/58550/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> nabarun nag
> 
>

[jira] [Commented] (GEODE-2807) Replace SharedPtr with std::shared_ptr

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett commented on GEODE-2807:
-

Docs Changes
* All references to {{SharedPtr}} need to be replaced with 
[{{std::shared_ptr}}|http://en.cppreference.com/w/cpp/memory/shared_ptr] 
(suggest using this link too)
* All {{*Ptr}} typedefs replaced with explicit {{std::shared_ptr<*>}}. For 
example, {{CacheableStringPtr}} is now {{std::shared_ptr}}. 
(not complete)


> Replace SharedPtr with std::shared_ptr
> --
>
> Key: GEODE-2807
> URL: https://issues.apache.org/jira/browse/GEODE-2807
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Jacob S. Barrett
>
> Replace proprietary SharePtr with C++11 std::shared_ptr.



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

[jira] [Created] (GEODE-2807) Replace SharedPtr with std::shared_ptr

[Jacob S. Barrett (JIRA)]

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

 Summary: Replace SharedPtr with std::shared_ptr
 Key: GEODE-2807
 URL: https://issues.apache.org/jira/browse/GEODE-2807
 Project: Geode
  Issue Type: Improvement
  Components: native client
Reporter: Jacob S. Barrett


Replace proprietary SharePtr with C++11 std::shared_ptr.



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

Re: Review Request 58550: AEQ regions being created before the user regions

[xiaojian zhou]

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




geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/AbstractPartitionedRepositoryManager.java
Line 57 (original), 58 (patched)


According to your code, the getRegionPath() will return null here. Is that 
by design? It looks like you purpursely hack the code to leave userRegion as 
null for a while. But actually it's not necessary. A simpler way is: you just 
specify the data region path in index, since data region not created yet, it 
will be null here.



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneRawIndex.java
Lines 28 (patched)


This is wrong. You have to move the createRepositoryManager() into this 
method. 

You need to test the RawIndex to make sure it did work after your code 
changes.



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneRegionListener.java
Lines 103 (patched)


This is the main entrance, you should add some comments here to describe 
the background.



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneRegionListener.java
Lines 104 (patched)


Why you did not specify "this.regionPath" in parameter? If so, your code 
will be much simpler. Many code could be omitted. I will point them later.



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneServiceImpl.java
Lines 199 (patched)


you can use existing createIndexRegions(indexNames, regionPath).



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneServiceImpl.java
Lines 220 (patched)


This can be omitted.


- xiaojian zhou


On April 20, 2017, 2:03 a.m., nabarun nag wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58550/
> ---
> 
> (Updated April 20, 2017, 2:03 a.m.)
> 
> 
> Review request for geode, Jason Huynh and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Testing a new start up mechanism where the AEQ is created before the user 
> region. Please review and let us know if any modifications are needed, or if 
> this is a viable solution
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/AbstractPartitionedRepositoryManager.java
>  26bb488ed 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneEventListener.java
>  0f5553343 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
>  fea484547 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexImpl.java
>  36f6720c3 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexImplFactory.java
>  e99f3d9db 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneRawIndex.java
>  75ab5cab3 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneRegionListener.java
>  f4e2a79ef 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneServiceImpl.java
>  30952bfe2 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/LuceneEventListenerJUnitTest.java
>  79de29a09 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/LuceneIndexForPartitionedRegionTest.java
>  8e4c179a5 
> 
> 
> Diff: https://reviews.apache.org/r/58550/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> nabarun nag
> 
>

[jira] [Commented] (GEODE-2763) Remove of nonSingleHopsCount stat in client

[ASF GitHub Bot (JIRA)]

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

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

Github user pivotal-jbarrett commented on the issue:

https://github.com/apache/geode-native/pull/90
  
You shouldn't merge develop into your feature branch. You should rebase 
your feature branch on develop. This creates a much cleaner merge of the 
feature back into develop when approved.


> Remove of nonSingleHopsCount stat in client
> ---
>
> Key: GEODE-2763
> URL: https://issues.apache.org/jira/browse/GEODE-2763
> Project: Geode
>  Issue Type: Bug
>  Components: docs, native client
>Reporter: Michael Dodge
>Assignee: Amey Barve
>
> A pre-existing issue (GEODE-2017) required the removal of the 
> nonSingleHopsCount statistic in the clients. Whilst marked for the native 
> client as well, it was not addressed in the native client. It should be.



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

[GitHub] geode-native issue #90: GEODE-2763: Remove of nonSingleHopsCount stat in cli...

[pivotal-jbarrett]

Github user pivotal-jbarrett commented on the issue:

https://github.com/apache/geode-native/pull/90
  
You shouldn't merge develop into your feature branch. You should rebase 
your feature branch on develop. This creates a much cleaner merge of the 
feature back into develop when approved.


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