[jira] [Commented] (GEODE-6821) Multiple Serial GatewaySenders that are primary in different members can cause a distributed deadlock
[ https://issues.apache.org/jira/browse/GEODE-6821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852490#comment-16852490 ] ASF subversion and git services commented on GEODE-6821: Commit 3ecdc1f0a10acc7fa45038fb3bcd321b3a712a5b in geode's branch refs/heads/feature/GEODE-6821 from Barry Oglesby [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3ecdc1f ] GEODE-6821: Shared P2P reader no longer processes messages on regions with a serial sender inline > Multiple Serial GatewaySenders that are primary in different members can > cause a distributed deadlock > - > > Key: GEODE-6821 > URL: https://issues.apache.org/jira/browse/GEODE-6821 > Project: Geode > Issue Type: Bug > Components: messaging, wan >Reporter: Barry Oglesby >Assignee: Barry Oglesby >Priority: Major > > A test with this scenario causes a distributed deadlock. > 3 servers each with: > - a function that performs a random region operation on the input region > - a replicated region on which the function is executed > - two regions each with a serial AEQ (the type of region could be either > replicate or partitioned) > 1 multi-threaded client that repeatedly executes the function with random > region names and operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6821) Multiple Serial GatewaySenders that are primary in different members can cause a distributed deadlock
[
https://issues.apache.org/jira/browse/GEODE-6821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852457#comment-16852457
]
Barry Oglesby commented on GEODE-6821:
--
The key to this deadlock is a shared P2P message reader waiting in
SerialGatewaySenderQueue.put for a WriteLock like:
{noformat}
"P2P message reader for 192.168.1.2(server-3:54808):41005 shared ordered
uid=6 port=62566" tid=0x4e owned by "Function Execution Processor7" tid=0x66
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Native Method)
- waiting on
java.util.concurrent.locks.ReentrantReadWriteLock$FairSync@42117a4e
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
at
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueue.put(SerialGatewaySenderQueue.java:220)
at
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.queuePrimaryEvent(SerialGatewaySenderEventProcessor.java:477)
at
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.enqueueEvent(SerialGatewaySenderEventProcessor.java:445)
at
org.apache.geode.internal.cache.wan.AbstractGatewaySender.distribute(AbstractGatewaySender.java:1033)
at
org.apache.geode.internal.cache.LocalRegion.notifyGatewaySender(LocalRegion.java:6138)
at
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5768)
at
org.apache.geode.internal.cache.map.RegionMapPut.doBeforeCompletionActions(RegionMapPut.java:282)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutAndDeliverEvent(AbstractRegionMapPut.java:301)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut$$Lambda$163/1504099933.run(Unknown
Source)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWithIndexUpdatingInProgress(AbstractRegionMapPut.java:308)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutIfPreconditionsSatisified(AbstractRegionMapPut.java:296)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutOnSynchronizedRegionEntry(AbstractRegionMapPut.java:282)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutOnRegionEntryInMap(AbstractRegionMapPut.java:273)
- locked
org.apache.geode.internal.cache.entries.VersionedThinRegionEntryHeapIntKey@7bbbc992
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.addRegionEntryToMapAndDoPut(AbstractRegionMapPut.java:251)
- locked
org.apache.geode.internal.cache.entries.VersionedThinRegionEntryHeapIntKey@7bbbc992
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutRetryingIfNeeded(AbstractRegionMapPut.java:216)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut$$Lambda$162/754294637.run(Unknown
Source)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.doWithIndexInUpdateMode(AbstractRegionMapPut.java:198)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:180)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut$$Lambda$161/453331027.run(Unknown
Source)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
at
org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
at
org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5599)
at
org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:377)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at
org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5579)
at
org.apache.geode.internal.cache.AbstractUpdateOperation.doPutOrCreate(AbstractUpdateOperation.java:150)
at
org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.basicOperateOnRegion(AbstractUpdateOperation.java:285)
at
org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.operateOnRegion(AbstractUpdateOperation.java:256)
at
org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1200)
at
org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.process(DistributedCacheOperation.java:1100)
at
[jira] [Commented] (GEODE-6820) CI Failure: ClearTXLockingDUnitTest > testPutWithClearDifferentVM
[
https://issues.apache.org/jira/browse/GEODE-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852455#comment-16852455
]
ASF subversion and git services commented on GEODE-6820:
Commit 9818cd139d11af1b3e4e228a1ec4e6cb5971021c in geode's branch
refs/heads/feature/GEODE-6820 from eshu
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9818cd1 ]
GEODE-6820: Initialize count down latches in setup method.
> CI Failure: ClearTXLockingDUnitTest > testPutWithClearDifferentVM
> -
>
> Key: GEODE-6820
> URL: https://issues.apache.org/jira/browse/GEODE-6820
> Project: Geode
> Issue Type: Test
> Components: transactions
>Reporter: Jens Deppe
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeCommons
>
> CI failure:
> {noformat}
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest >
> testPutWithClearDifferentVM FAILED
> org.junit.ComparisonFailure: [region contents are not consistent for key
> testRegion1theKey0] expected:<"theValue0"> but was:
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.checkForConsistencyErrors(ClearTXLockingDUnitTest.java:344)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.performTestAndCheckResults(ClearTXLockingDUnitTest.java:177)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.testPutWithClearDifferentVM(ClearTXLockingDUnitTest.java:120)
> {noformat}
> Logs available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0316/test-results/distributedTest/1559243936/
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0316/test-artifacts/1559243936/distributedtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0316.tgz
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6821) Multiple Serial GatewaySenders that are primary in different members can cause a distributed deadlock
[ https://issues.apache.org/jira/browse/GEODE-6821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barry Oglesby reassigned GEODE-6821: Assignee: Barry Oglesby > Multiple Serial GatewaySenders that are primary in different members can > cause a distributed deadlock > - > > Key: GEODE-6821 > URL: https://issues.apache.org/jira/browse/GEODE-6821 > Project: Geode > Issue Type: Bug > Components: messaging, wan >Reporter: Barry Oglesby >Assignee: Barry Oglesby >Priority: Major > > A test with this scenario causes a distributed deadlock. > 3 servers each with: > - a function that performs a random region operation on the input region > - a replicated region on which the function is executed > - two regions each with a serial AEQ (the type of region could be either > replicate or partitioned) > 1 multi-threaded client that repeatedly executes the function with random > region names and operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6821) Multiple Serial GatewaySenders that are primary in different members can cause a distributed deadlock
Barry Oglesby created GEODE-6821: Summary: Multiple Serial GatewaySenders that are primary in different members can cause a distributed deadlock Key: GEODE-6821 URL: https://issues.apache.org/jira/browse/GEODE-6821 Project: Geode Issue Type: Bug Components: messaging, wan Reporter: Barry Oglesby A test with this scenario causes a distributed deadlock. 3 servers each with: - a function that performs a random region operation on the input region - a replicated region on which the function is executed - two regions each with a serial AEQ (the type of region could be either replicate or partitioned) 1 multi-threaded client that repeatedly executes the function with random region names and operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6820) CI Failure: ClearTXLockingDUnitTest > testPutWithClearDifferentVM
[
https://issues.apache.org/jira/browse/GEODE-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu reassigned GEODE-6820:
---
Assignee: Eric Shu
> CI Failure: ClearTXLockingDUnitTest > testPutWithClearDifferentVM
> -
>
> Key: GEODE-6820
> URL: https://issues.apache.org/jira/browse/GEODE-6820
> Project: Geode
> Issue Type: Test
> Components: transactions
>Reporter: Jens Deppe
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeCommons
>
> CI failure:
> {noformat}
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest >
> testPutWithClearDifferentVM FAILED
> org.junit.ComparisonFailure: [region contents are not consistent for key
> testRegion1theKey0] expected:<"theValue0"> but was:
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.checkForConsistencyErrors(ClearTXLockingDUnitTest.java:344)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.performTestAndCheckResults(ClearTXLockingDUnitTest.java:177)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.testPutWithClearDifferentVM(ClearTXLockingDUnitTest.java:120)
> {noformat}
> Logs available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0316/test-results/distributedTest/1559243936/
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0316/test-artifacts/1559243936/distributedtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0316.tgz
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6820) CI Failure: ClearTXLockingDUnitTest > testPutWithClearDifferentVM
[
https://issues.apache.org/jira/browse/GEODE-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852438#comment-16852438
]
Eric Shu commented on GEODE-6820:
-
This is caused by recent changes that all latches are final and all latches are
countDown in tearDown. So the latches have effect only on the first test method
run in the test, as other tests all have latches of count of 0 after test run.
@After
public void tearDown() {
for (VM vm : VM.toArray(vm0, vm1, getController())) {
vm.invoke(() -> {
opsLatch.countDown();
regionLatch.countDown();
verifyLatch.countDown();
});
}
}
> CI Failure: ClearTXLockingDUnitTest > testPutWithClearDifferentVM
> -
>
> Key: GEODE-6820
> URL: https://issues.apache.org/jira/browse/GEODE-6820
> Project: Geode
> Issue Type: Test
> Components: transactions
>Reporter: Jens Deppe
>Priority: Major
> Labels: GeodeCommons
>
> CI failure:
> {noformat}
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest >
> testPutWithClearDifferentVM FAILED
> org.junit.ComparisonFailure: [region contents are not consistent for key
> testRegion1theKey0] expected:<"theValue0"> but was:
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.checkForConsistencyErrors(ClearTXLockingDUnitTest.java:344)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.performTestAndCheckResults(ClearTXLockingDUnitTest.java:177)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.testPutWithClearDifferentVM(ClearTXLockingDUnitTest.java:120)
> {noformat}
> Logs available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0316/test-results/distributedTest/1559243936/
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0316/test-artifacts/1559243936/distributedtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0316.tgz
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6696) Only create EntryEvenImpl.offHeapLock if off heap is in use.
[
https://issues.apache.org/jira/browse/GEODE-6696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852390#comment-16852390
]
ASF subversion and git services commented on GEODE-6696:
Commit 327feec1946a0b6e28dd552d175e7833dc8d8dd2 in geode's branch
refs/heads/develop from mivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=327feec ]
GEODE-6696: EntryEvenImpl.offHeapLock created only if off-heap in use (#3581)
> Only create EntryEvenImpl.offHeapLock if off heap is in use.
>
>
> Key: GEODE-6696
> URL: https://issues.apache.org/jira/browse/GEODE-6696
> Project: Geode
> Issue Type: Improvement
>Reporter: Jacob S. Barrett
>Assignee: Mario Ivanac
>Priority: Minor
> Labels: performance, pull-request-available
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Reduce allocation of unnecessary lock object if not using off heap storage.
> {{ private final Object offHeapLock = new Object();}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5222) JMX metric exposed in an MBean
[ https://issues.apache.org/jira/browse/GEODE-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852358#comment-16852358 ] Aaron Lindsey commented on GEODE-5222: -- In [RegionMXBean|[https://geode.apache.org/releases/latest/javadoc/org/apache/geode/management/RegionMXBean.html]], there are examples of metrics that return -1 (int) or -1.0 (float) under scenarios when the value is not applicable. In one such example, getPutLocalRate() returns ManagementConstants.NOT_AVAILABLE_FLOAT when the region is not a partitioned region . I think we could do the same thing here when the operator does not specify directory sizes. > JMX metric exposed in an MBean > -- > > Key: GEODE-5222 > URL: https://issues.apache.org/jira/browse/GEODE-5222 > Project: Geode > Issue Type: Improvement > Components: docs, persistence >Reporter: Nick Vallely >Assignee: Alberto Bustamante Reyes >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > Given I need to scale down or scale up my servers based on usage > When I setup my monitoring of JMX metrics through an MBean > Then I have the ability to see Disk Free Percentage > AND Disk Free in Bytes > AND Disk Used Percentage > AND Disk Used in Bytes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GEODE-5222) JMX metric exposed in an MBean
[ https://issues.apache.org/jira/browse/GEODE-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852358#comment-16852358 ] Aaron Lindsey edited comment on GEODE-5222 at 5/30/19 8:59 PM: --- In RegionMXBean, there are examples of metrics that return -1 (int) or -1.0 (float) under scenarios when the value is not applicable. In one such example, getPutLocalRate() returns ManagementConstants.NOT_AVAILABLE_FLOAT when the region is not a partitioned region . I think we could do the same thing here when the operator does not specify directory sizes. was (Author: aaronlindsey): In [RegionMXBean|[https://geode.apache.org/releases/latest/javadoc/org/apache/geode/management/RegionMXBean.html]], there are examples of metrics that return -1 (int) or -1.0 (float) under scenarios when the value is not applicable. In one such example, getPutLocalRate() returns ManagementConstants.NOT_AVAILABLE_FLOAT when the region is not a partitioned region . I think we could do the same thing here when the operator does not specify directory sizes. > JMX metric exposed in an MBean > -- > > Key: GEODE-5222 > URL: https://issues.apache.org/jira/browse/GEODE-5222 > Project: Geode > Issue Type: Improvement > Components: docs, persistence >Reporter: Nick Vallely >Assignee: Alberto Bustamante Reyes >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > Given I need to scale down or scale up my servers based on usage > When I setup my monitoring of JMX metrics through an MBean > Then I have the ability to see Disk Free Percentage > AND Disk Free in Bytes > AND Disk Used Percentage > AND Disk Used in Bytes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6820) CI Failure: ClearTXLockingDUnitTest > testPutWithClearDifferentVM
[
https://issues.apache.org/jira/browse/GEODE-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-6820:
--
Labels: GeodeCommons (was: )
> CI Failure: ClearTXLockingDUnitTest > testPutWithClearDifferentVM
> -
>
> Key: GEODE-6820
> URL: https://issues.apache.org/jira/browse/GEODE-6820
> Project: Geode
> Issue Type: Test
> Components: transactions
>Reporter: Jens Deppe
>Priority: Major
> Labels: GeodeCommons
>
> CI failure:
> {noformat}
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest >
> testPutWithClearDifferentVM FAILED
> org.junit.ComparisonFailure: [region contents are not consistent for key
> testRegion1theKey0] expected:<"theValue0"> but was:
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.checkForConsistencyErrors(ClearTXLockingDUnitTest.java:344)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.performTestAndCheckResults(ClearTXLockingDUnitTest.java:177)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.testPutWithClearDifferentVM(ClearTXLockingDUnitTest.java:120)
> {noformat}
> Logs available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0316/test-results/distributedTest/1559243936/
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0316/test-artifacts/1559243936/distributedtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0316.tgz
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6556) Geode User Guide: Correct gfsh create region param explanations
[ https://issues.apache.org/jira/browse/GEODE-6556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-6556: --- Description: On the reference page for the `gfsh create region` command, some region-wide parameters are incorrectly described as applying to the regions themselves, when they actually apply to *all entries within the region*. The params whose descriptions need correcting are: * region-idle-time-expiration and region-idle-time-expiration-action * region-time-to-live-expiration and region-time-to-live-expiration-action was: On the reference page for the `gfsh create region` command, some region-wide parameters are indirectly described as applying to the regions themselves, when they actually apply to *all entries within the region*. The params whose descriptions need correcting are: * region-idle-time-expiration and region-idle-time-expiration-action * region-time-to-live-expiration and region-time-to-live-expiration-action > Geode User Guide: Correct gfsh create region param explanations > --- > > Key: GEODE-6556 > URL: https://issues.apache.org/jira/browse/GEODE-6556 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Priority: Major > Labels: starter > > On the reference page for the `gfsh create region` command, some region-wide > parameters are incorrectly described as applying to the regions themselves, > when they actually apply to *all entries within the region*. The params whose > descriptions need correcting are: > * region-idle-time-expiration and region-idle-time-expiration-action > * region-time-to-live-expiration and region-time-to-live-expiration-action -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6820) CI Failure: ClearTXLockingDUnitTest > testPutWithClearDifferentVM
Jens Deppe created GEODE-6820:
-
Summary: CI Failure: ClearTXLockingDUnitTest >
testPutWithClearDifferentVM
Key: GEODE-6820
URL: https://issues.apache.org/jira/browse/GEODE-6820
Project: Geode
Issue Type: Test
Components: transactions
Reporter: Jens Deppe
CI failure:
{noformat}
org.apache.geode.internal.cache.ClearTXLockingDUnitTest >
testPutWithClearDifferentVM FAILED
org.junit.ComparisonFailure: [region contents are not consistent for key
testRegion1theKey0] expected:<"theValue0"> but was:
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.checkForConsistencyErrors(ClearTXLockingDUnitTest.java:344)
at
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.performTestAndCheckResults(ClearTXLockingDUnitTest.java:177)
at
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.testPutWithClearDifferentVM(ClearTXLockingDUnitTest.java:120)
{noformat}
Logs available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0316/test-results/distributedTest/1559243936/
http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0316/test-artifacts/1559243936/distributedtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0316.tgz
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-2275) CI Failure: ClearTXLockingDUnitTest.testPutWithClearDifferentVM
[
https://issues.apache.org/jira/browse/GEODE-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-2275.
---
Resolution: Fixed
Fix Version/s: 1.9.0
> CI Failure: ClearTXLockingDUnitTest.testPutWithClearDifferentVM
> ---
>
> Key: GEODE-2275
> URL: https://issues.apache.org/jira/browse/GEODE-2275
> Project: Geode
> Issue Type: Bug
> Components: regions, transactions
>Reporter: Eric Shu
>Priority: Minor
> Labels: ci, flaky, pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest >
> testPutWithClearDifferentVM FAILED
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$1.run in VM 0 running
> on Host d7fcb695b430 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.runLockingTest(ClearTXLockingDUnitTest.java:206)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.performTestAndCheckResults(ClearTXLockingDUnitTest.java:170)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.testPutWithClearDifferentVM(ClearTXLockingDUnitTest.java:115)
> Caused by:
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$1$$Lambda$21/402256214.run
> in VM 0 running on Host d7fcb695b430 with 4 VMs
> Caused by:
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$$Lambda$24/1595591059.run
> in VM 1 running on Host d7fcb695b430 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.releaseRegionOperation(ClearTXLockingDUnitTest.java:324)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.access$100(ClearTXLockingDUnitTest.java:67)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$CommitTestCallback.run(ClearTXLockingDUnitTest.java:408)
> at org.apache.geode.internal.cache.TXState.applyChanges(TXState.java:796)
> at org.apache.geode.internal.cache.TXState.commit(TXState.java:468)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:254)
> at
> org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:375)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.doPuts(ClearTXLockingDUnitTest.java:316)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.access$000(ClearTXLockingDUnitTest.java:67)
> Caused by:
> java.lang.NullPointerException
>at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.lambda$releaseRegionOperation$b6506259$1(ClearTXLockingDUnitTest.java:324)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6537) ClearTXLockingDUnitTest.testPutWithClearDifferentVM fails intermittently with NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-6537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852278#comment-16852278
]
Jens Deppe commented on GEODE-6537:
---
Duplicates GEODE-6537
> ClearTXLockingDUnitTest.testPutWithClearDifferentVM fails intermittently with
> NullPointerException
> --
>
> Key: GEODE-6537
> URL: https://issues.apache.org/jira/browse/GEODE-6537
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.9.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest >
> testPutWithClearDifferentVM FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$$Lambda$168/0x000840292440.run
> in VM 0 running on Host 823191dd2336 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.performTestAndCheckResults(ClearTXLockingDUnitTest.java:157)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.testPutWithClearDifferentVM(ClearTXLockingDUnitTest.java:107)
> Caused by:
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$$Lambda$284/0x000840422c40.run
> in VM 0 running on Host 823191dd2336 with 4 VMs
> at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.putOperationsTest(ClearTXLockingDUnitTest.java:179)
> Caused by:
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$$Lambda$289/0x0008404a0040.run
> in VM 1 running on Host 823191dd2336 with 4 VMs
> at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.releaseRegionOperation(ClearTXLockingDUnitTest.java:292)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.access$000(ClearTXLockingDUnitTest.java:60)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$CommitTestCallback.run(ClearTXLockingDUnitTest.java:373)
> at
> org.apache.geode.internal.cache.TXState.applyChanges(TXState.java:822)
> at
> org.apache.geode.internal.cache.TXState.commit(TXState.java:486)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:211)
> at
> org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:426)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.doPuts(ClearTXLockingDUnitTest.java:284)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.lambda$putOperationsTest$bb17a952$1(ClearTXLockingDUnitTest.java:179)
> Caused by:
> java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.lambda$releaseRegionOperation$b6506259$1(ClearTXLockingDUnitTest.java:292)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GEODE-6537) ClearTXLockingDUnitTest.testPutWithClearDifferentVM fails intermittently with NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-6537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852278#comment-16852278
]
Jens Deppe edited comment on GEODE-6537 at 5/30/19 7:44 PM:
Duplicates GEODE-2275
was (Author: jens.deppe):
Duplicates GEODE-6537
> ClearTXLockingDUnitTest.testPutWithClearDifferentVM fails intermittently with
> NullPointerException
> --
>
> Key: GEODE-6537
> URL: https://issues.apache.org/jira/browse/GEODE-6537
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.9.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest >
> testPutWithClearDifferentVM FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$$Lambda$168/0x000840292440.run
> in VM 0 running on Host 823191dd2336 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.performTestAndCheckResults(ClearTXLockingDUnitTest.java:157)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.testPutWithClearDifferentVM(ClearTXLockingDUnitTest.java:107)
> Caused by:
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$$Lambda$284/0x000840422c40.run
> in VM 0 running on Host 823191dd2336 with 4 VMs
> at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.putOperationsTest(ClearTXLockingDUnitTest.java:179)
> Caused by:
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$$Lambda$289/0x0008404a0040.run
> in VM 1 running on Host 823191dd2336 with 4 VMs
> at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.releaseRegionOperation(ClearTXLockingDUnitTest.java:292)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.access$000(ClearTXLockingDUnitTest.java:60)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$CommitTestCallback.run(ClearTXLockingDUnitTest.java:373)
> at
> org.apache.geode.internal.cache.TXState.applyChanges(TXState.java:822)
> at
> org.apache.geode.internal.cache.TXState.commit(TXState.java:486)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:211)
> at
> org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:426)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.doPuts(ClearTXLockingDUnitTest.java:284)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.lambda$putOperationsTest$bb17a952$1(ClearTXLockingDUnitTest.java:179)
> Caused by:
> java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.lambda$releaseRegionOperation$b6506259$1(ClearTXLockingDUnitTest.java:292)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6537) ClearTXLockingDUnitTest.testPutWithClearDifferentVM fails intermittently with NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-6537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-6537:
--
Fix Version/s: 1.9.0
> ClearTXLockingDUnitTest.testPutWithClearDifferentVM fails intermittently with
> NullPointerException
> --
>
> Key: GEODE-6537
> URL: https://issues.apache.org/jira/browse/GEODE-6537
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.9.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest >
> testPutWithClearDifferentVM FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$$Lambda$168/0x000840292440.run
> in VM 0 running on Host 823191dd2336 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.performTestAndCheckResults(ClearTXLockingDUnitTest.java:157)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.testPutWithClearDifferentVM(ClearTXLockingDUnitTest.java:107)
> Caused by:
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$$Lambda$284/0x000840422c40.run
> in VM 0 running on Host 823191dd2336 with 4 VMs
> at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.putOperationsTest(ClearTXLockingDUnitTest.java:179)
> Caused by:
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$$Lambda$289/0x0008404a0040.run
> in VM 1 running on Host 823191dd2336 with 4 VMs
> at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.releaseRegionOperation(ClearTXLockingDUnitTest.java:292)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.access$000(ClearTXLockingDUnitTest.java:60)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$CommitTestCallback.run(ClearTXLockingDUnitTest.java:373)
> at
> org.apache.geode.internal.cache.TXState.applyChanges(TXState.java:822)
> at
> org.apache.geode.internal.cache.TXState.commit(TXState.java:486)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:211)
> at
> org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:426)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.doPuts(ClearTXLockingDUnitTest.java:284)
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.lambda$putOperationsTest$bb17a952$1(ClearTXLockingDUnitTest.java:179)
> Caused by:
> java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.lambda$releaseRegionOperation$b6506259$1(ClearTXLockingDUnitTest.java:292)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6803) Be able to configure pdx using management rest api
[ https://issues.apache.org/jira/browse/GEODE-6803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852170#comment-16852170 ] ASF subversion and git services commented on GEODE-6803: Commit c411f6475ffd2ec6e5814246da019cefc6a58368 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c411f64 ] GEODE-6803: be able to configure pdx using management rest api (#3638) * Add PdxManagementController and PdxManager * add RestEndPoint.getUri for single config object uri for HATOS, make it part of the json response * rename RuntimeCacheElement to MultiGroupCacheElement since the only usage of it is to support multi group. * make MultiGroupCacheElement a suplimental interface and list does not have to return MultiGroupCacheElement * do not require servers to be present in order to create a cache element * when realizer is not present, assuming the servers needs to be bounced in order for the config change to take effect > Be able to configure pdx using management rest api > -- > > Key: GEODE-6803 > URL: https://issues.apache.org/jira/browse/GEODE-6803 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jinmei Liao >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6183) CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException
[
https://issues.apache.org/jira/browse/GEODE-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852139#comment-16852139
]
Kirk Lund commented on GEODE-6183:
--
stderr contains a stack trace:
{noformat}
java.util.ServiceConfigurationError: com.sun.tools.attach.spi.AttachProvider:
Provider sun.tools.attach.WindowsAttachProvider not found
at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:588)
at
java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1211)
at
java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1220)
at
java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1264)
at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1299)
at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1384)
at
jdk.attach/com.sun.tools.attach.spi.AttachProvider.providers(AttachProvider.java:258)
at
jdk.attach/com.sun.tools.attach.VirtualMachine.list(VirtualMachine.java:144)
at
org.apache.geode.internal.process.AttachProcessUtils.isProcessAlive(AttachProcessUtils.java:35)
at
org.apache.geode.internal.process.ProcessUtils.isProcessAlive(ProcessUtils.java:99)
at
org.apache.geode.internal.process.lang.AvailablePid.findAvailablePid(AvailablePid.java:117)
at
org.apache.geode.distributed.LauncherIntegrationTestCase.setUpAbstractLauncherIntegrationTestCase(LauncherIntegrationTestCase.java:88)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.Verifier$1.evaluate(Verifier.java:35)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
[jira] [Commented] (GEODE-2600) Inconsistent spacing of headers in Startup Configuration log
[
https://issues.apache.org/jira/browse/GEODE-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852113#comment-16852113
]
ASF subversion and git services commented on GEODE-2600:
Commit fbe167bf2f75571e0e90fdcec9114a92b1f0b026 in geode's branch
refs/heads/develop from Alberto Bustamante Reyes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=fbe167b ]
GEODE-2600 Inconsistent spacing of headers in Startup Configuration log
> Inconsistent spacing of headers in Startup Configuration log
>
>
> Key: GEODE-2600
> URL: https://issues.apache.org/jira/browse/GEODE-2600
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.2.0
>Reporter: Patrick Rhomberg
>Assignee: Alberto Bustamante Reyes
>Priority: Trivial
> Labels: LogBanner, starter
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Note the extra space before the initial ###.
> {noformat}
> [info 2017/03/06 14:29:30.003 PST loc1 tid=0x1] Startup Configuration:
>### GemFire Properties defined with system property ###
> enable-cluster-configuration=true
> load-cluster-configuration-from-dir=false
> ### GemFire Properties defined with api ###
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6794) Returning a client connection to the pool always calls notifyAll
[
https://issues.apache.org/jira/browse/GEODE-6794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-6794.
-
Resolution: Fixed
Fix Version/s: 1.10.0
> Returning a client connection to the pool always calls notifyAll
>
>
> Key: GEODE-6794
> URL: https://issues.apache.org/jira/browse/GEODE-6794
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Kevo
>Priority: Major
> Labels: performance
> Fix For: 1.10.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The PooledConnection passivate method is called every time a client op
> completes and it is returning its connection to the pool.
> passivate almost always calls notifyAll. But no other thread will be waiting
> for this notify unless the boolean "waitingToSwitch" is true. This notifyAll
> calls shows up as a hotspot in profiling. But when I got rid of it it didn't
> make any difference in client operation throughput.
> Here is the change that can be made to get rid of the notifyAll calls:
> {noformat}
> ---
> a/geode-core/src/main/java/org/apache/geode/cache/client/internal/pooling/PooledConnection.java
> +++
> b/geode-core/src/main/java/org/apache/geode/cache/client/internal/pooling/PooledConnection.java
> @@ -157,7 +157,9 @@ public class PooledConnection implements Connection {
> throw new InternalGemFireException("Connection not active");
>}
>this.active = false;
> - notifyAll();
> + if (this.waitingToSwitch) {
> +notifyAll();
> + }
>if (accessed) {
> this.lastAccessed = now; // do this while synchronized
>}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6765) Gfsh list* commands do not return error when no results found
[
https://issues.apache.org/jira/browse/GEODE-6765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16851911#comment-16851911
]
ASF subversion and git services commented on GEODE-6765:
Commit 47e44ff2a5bfd021c90d25a50595a119dba85db7 in geode's branch
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=47e44ff ]
GEODE-6765: Gfsh list* commands do not return error when no results found
(#3634)
- This also includes not returning an error when no members are found to
execute against.
Authored-by: Jens Deppe
> Gfsh list* commands do not return error when no results found
> -
>
> Key: GEODE-6765
> URL: https://issues.apache.org/jira/browse/GEODE-6765
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Jens Deppe
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This is a change that will break scripts parsing output from gfsh.
> Scenario is running with a SNAPSHOT build on a cluster with > 1 server. There
> is a is a durable-cq on one of the servers, and the gfsh command was
> {noformat}
> list durable-cqs --durable-client-id=pizza-store{noformat}
> The expected output is
> {noformat}
> Member | Status | CQ Name
> | -- |
>
> cacheserver-e133-e20e-4f6e-92c3-daaad6.. | ERROR | No client found with
> client-id : pizza-store
> cacheserver-2a9d1c06-893b-4e0e-bc6c-546972.. | OK | PestoPizzaOrdersQuery
> cacheserver-528ca358-3ed2-47b2-a4b6-aa363d.. | ERROR | No client found with
> client-id : pizza-store
> cacheserver-b3b91b30-fa3c-4add-97cf-79b2e9.. | ERROR | No client found with
> client-id : pizza-store{noformat}
> The script fails because it captures the command output and looks for the
> servers with an {{OK}} status. With this SNAPSHOT, gfsh outputs to stderr
> where earlier versions output to stdout. Note that if this command was run
> with a {{--member}} option with a specific server that has the durable-cq,
> then the output DOES go to stdout.
> Bottom line for scripting with gfsh: It's no longer predictable where to look
> for output, stderr or stdout.
> As a side note: From a user point of view, indicating an {{ERROR}} status for
> members on a command like this is misleading. The non-existence of a
> durable-cq on member 'x' is a statement of fact and not necessarily an
> error. Reprorting {{N/A}} or {{DOES NOT EXIST}} would be more appropriate
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6717) NotAuthorizedException during JMX scraping
[
https://issues.apache.org/jira/browse/GEODE-6717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-6717:
--
Component/s: jmx
> NotAuthorizedException during JMX scraping
> --
>
> Key: GEODE-6717
> URL: https://issues.apache.org/jira/browse/GEODE-6717
> Project: Geode
> Issue Type: Improvement
> Components: jmx, security
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> {color:#33}Geode shows the following log and the JMX statistics gathering
> fails:{color}
> {code:java}
> [info 2019/04/29 15:02:39.609 CEST locator
> tid=0x80] NotAuthorizedException: null not authorized for CLUSTER:READ
> {code}
> {color:#33}To reproduce this start geode with access control enabled and
> start JMX scraping (e.g. with jmx-exporter) from 2 processes using the same
> credentials at the same time. What happens is that the first RMI TCP
> connection is created, the user is authenticated and an Apache Shiro session
> is created. If the second process starts collecting JMX info while the first
> one is still running, his RMI TCP Connection will not create a new session,
> but attach to the existing one. Once the first connection ends, the session
> is stopped, the cache emptied and the second connection is left trying to
> gather info without a valid session and credentials info.{color}
>
> {color:#33}As I saw this is how Apache Shiro works:{color}
> {color:#33}To create a session it use method _getSession(boolean
> create)._ In case there is already an existing session associated with the
> same Subject, it is returned and create argument is ignored. If no session
> exist and create is true, new session will be created, associated with that
> Subject and then returned.
> {color}
>
> {color:#33}Workaround for this is checking how many processes are
> connected to the session, and logout only if this is the latest process
> connected on it.{color}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6717) NotAuthorizedException during JMX scraping
[
https://issues.apache.org/jira/browse/GEODE-6717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-6717:
-
Assignee: Mario Kevo
> NotAuthorizedException during JMX scraping
> --
>
> Key: GEODE-6717
> URL: https://issues.apache.org/jira/browse/GEODE-6717
> Project: Geode
> Issue Type: Improvement
> Components: security
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> {color:#33}Geode shows the following log and the JMX statistics gathering
> fails:{color}
> {code:java}
> [info 2019/04/29 15:02:39.609 CEST locator
> tid=0x80] NotAuthorizedException: null not authorized for CLUSTER:READ
> {code}
> {color:#33}To reproduce this start geode with access control enabled and
> start JMX scraping (e.g. with jmx-exporter) from 2 processes using the same
> credentials at the same time. What happens is that the first RMI TCP
> connection is created, the user is authenticated and an Apache Shiro session
> is created. If the second process starts collecting JMX info while the first
> one is still running, his RMI TCP Connection will not create a new session,
> but attach to the existing one. Once the first connection ends, the session
> is stopped, the cache emptied and the second connection is left trying to
> gather info without a valid session and credentials info.{color}
>
> {color:#33}As I saw this is how Apache Shiro works:{color}
> {color:#33}To create a session it use method _getSession(boolean
> create)._ In case there is already an existing session associated with the
> same Subject, it is returned and create argument is ignored. If no session
> exist and create is true, new session will be created, associated with that
> Subject and then returned.
> {color}
>
> {color:#33}Workaround for this is checking how many processes are
> connected to the session, and logout only if this is the latest process
> connected on it.{color}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6571) Remove unneccessary list of region shortcuts
[ https://issues.apache.org/jira/browse/GEODE-6571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo resolved GEODE-6571. --- Resolution: Fixed > Remove unneccessary list of region shortcuts > > > Key: GEODE-6571 > URL: https://issues.apache.org/jira/browse/GEODE-6571 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Mario Kevo >Priority: Major > Labels: starter > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Docs improvement: In file > reference/topics/chapter_overview_regionshortcuts.html.md.erb, there is a > bulleted list of links to region shortcut descriptions. This duplicates the > list that is already in the subnav. This list can be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6571) Remove unneccessary list of region shortcuts
[ https://issues.apache.org/jira/browse/GEODE-6571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo updated GEODE-6571: -- Fix Version/s: 1.10.0 > Remove unneccessary list of region shortcuts > > > Key: GEODE-6571 > URL: https://issues.apache.org/jira/browse/GEODE-6571 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Mario Kevo >Priority: Major > Labels: starter > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Docs improvement: In file > reference/topics/chapter_overview_regionshortcuts.html.md.erb, there is a > bulleted list of links to region shortcut descriptions. This duplicates the > list that is already in the subnav. This list can be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
