[jira] [Commented] (GEODE-6898) CI: Benchmark job should be called with --ci option
[ https://issues.apache.org/jira/browse/GEODE-6898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870010#comment-16870010 ] ASF subversion and git services commented on GEODE-6898: Commit 50db9a9e393418afc4e1a82f43a0be81eae14a70 in geode's branch refs/heads/develop from Kamilla Aslami [ https://gitbox.apache.org/repos/asf?p=geode.git;h=50db9a9 ] GEODE-6898: Call benchmark script with --ci option Call the benchmark script with the --ci option to indicate to the benchmark that it is being called from CI, so that it will check if the commit should be the new high watermark. > CI: Benchmark job should be called with --ci option > --- > > Key: GEODE-6898 > URL: https://issues.apache.org/jira/browse/GEODE-6898 > Project: Geode > Issue Type: New Feature > Components: benchmarks >Reporter: Kamilla Aslami >Assignee: Helena Bales >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > The benchmark CI job should be called with the --ci option to indicate to the > benchmark that the caller is a CI pipeline. This work is related to a PR on > the geode-benchmark repo: [https://github.com/apache/geode-benchmarks/pull/86] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6798) Refactoring client function execution logic
[ https://issues.apache.org/jira/browse/GEODE-6798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870009#comment-16870009 ] ASF subversion and git services commented on GEODE-6798: Commit 18530da5ae33fc2c922bb4a2aeb5e00a57eaa31e in geode's branch refs/heads/develop from albertogpz [ https://gitbox.apache.org/repos/asf?p=geode.git;h=18530da ] GEODE-6798: Refactoring of client function execution logic (#3710) * Some unit tests for the ExecuteRegionFunctionOpImplTest constructors * Do not allocate failedNodes Collection unless necessary > Refactoring client function execution logic > --- > > Key: GEODE-6798 > URL: https://issues.apache.org/jira/browse/GEODE-6798 > Project: Geode > Issue Type: Bug > Components: client/server, functions >Reporter: Anilkumar Gingade >Assignee: Alberto Gomez >Priority: Major > Labels: GeodeCommons > Time Spent: 6.5h > Remaining Estimate: 0h > > While working on GEODE-6677; issue with client function retry semantic, we > came across duplicating the fix on many places; as the function execution is > supported in many ways: > onServer(pool) > onServers(pool) > onRegion() > onRegions() > onServer(regionService) > onServers(regionService) > Additional methods when data affinity is provided. > In all of these cases, the execution is done by having execute() and > reExecute(); and copies of it to support, execution using function object and > function id, repeating the same logic. > The code can be refactored to remove the duplicating logic and make it easier > to add any changes/fixes. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6901) If a region is replicate and replicate persistent in different members and a replicate persistent member crashes, the replicate members throw a ToDataException attempting
Barry Oglesby created GEODE-6901:
Summary: If a region is replicate and replicate persistent in
different members and a replicate persistent member crashes, the replicate
members throw a ToDataException attempting to synchronize the region
Key: GEODE-6901
URL: https://issues.apache.org/jira/browse/GEODE-6901
Project: Geode
Issue Type: Bug
Components: persistence, regions
Reporter: Barry Oglesby
If a region is replicate and replicate persistent in different members and a
replicate persistent member crashes, the replicate members throw a
ToDataException attempting to synchronize the region
In this case, an exception like this is thrown in the replicate member:
{noformat}
[warn 2019/06/21 17:06:33.516 PDT tid=0x2b] Timer task
encountered
exception
org.apache.geode.ToDataException: class
org.apache.geode.internal.cache.versions.VMRegionVersionVector
at
org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2331)
at
org.apache.geode.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1492)
at
org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2067)
at org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2943)
at
org.apache.geode.internal.cache.InitialImageOperation$RequestImageMessage.toData(InitialImageOperation.java:2135)
at
org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2300)
at
org.apache.geode.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1492)
at org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:242)
at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:385)
at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:241)
at
org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:596)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1711)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.send(GMSMembershipManager.java:1892)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2852)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:2779)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2816)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1526)
at
org.apache.geode.internal.cache.InitialImageOperation.synchronizeWith(InitialImageOperation.java:649)
at
org.apache.geode.internal.cache.DistributedRegion.synchronizeWith(DistributedRegion.java:1321)
at
org.apache.geode.internal.cache.DistributedRegion.synchronizeForLostMember(DistributedRegion.java:1310)
at
org.apache.geode.internal.cache.DistributedRegion.performSynchronizeForLostMemberTask(DistributedRegion.java:1295)
at
org.apache.geode.internal.cache.DistributedRegion$1.run2(DistributedRegion.java:1285)
at
org.apache.geode.internal.SystemTimer$SystemTimerTask.run(SystemTimer.java:445)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Caused by: java.lang.ClassCastException:
org.apache.geode.internal.cache.persistence.DiskStoreID cannot be cast to
org.apache.geode.distributed.internal.membership.InternalDistributedMember
at
org.apache.geode.internal.cache.versions.VMRegionVersionVector.writeMember(VMRegionVersionVector.java:31)
at
org.apache.geode.internal.cache.versions.RegionVersionVector.toData(RegionVersionVector.java:1204)
at
org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2300)
... 24 more
{noformat}
RegionVersionVector.java:1204 is here:
{noformat}
for (Map.Entry> entry :
this.memberToVersion.entrySet()) {
-> writeMember(entry.getKey(), out);
InternalDataSerializer.invokeToData(entry.getValue(), out);
}
{noformat}
VMRegionVersionVector expects the entries of the memberToVersion to be keyed by
InternalDistributedMembers:
{noformat}
protected void writeMember(InternalDistributedMember member, DataOutput out)
throws IOException {
{noformat}
Logging in RegionVersionVector.toData shows the RegionVersionVector in this
member is a VMRegionVersionVector and its memberToVersion map contains
DiskStoreIDs. This causes the ClassCastException.
{noformat}
This RegionVersionVector's (class=VMRegionVersionVector) memberToVersion map
contains the following 1 entries:
member=402d383b29fa4c31-8597a3b72674bf5d; class=DiskStoreID
{noformat}
The documentation
[jira] [Commented] (GEODE-6900) Add a unit test that transaction1 commit failed if it writes on a key was read in transaction2 and transaction2 has hold the lock when read conflict detection is on
[ https://issues.apache.org/jira/browse/GEODE-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869977#comment-16869977 ] ASF subversion and git services commented on GEODE-6900: Commit 21078b4d184c892a5d3ff70f5b13ba355ee4aa67 in geode's branch refs/heads/feature/GEODE-6900 from eshu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=21078b4 ] GEODE-6900: Add a unit test with detect read conflicts > Add a unit test that transaction1 commit failed if it writes on a key was > read in transaction2 and transaction2 has hold the lock when read conflict > detection is on > - > > Key: GEODE-6900 > URL: https://issues.apache.org/jira/browse/GEODE-6900 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > > Need to add a unit test with read conflict detection is on. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6899) retried client should set last try's version tag if found
[ https://issues.apache.org/jira/browse/GEODE-6899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869970#comment-16869970 ] ASF subversion and git services commented on GEODE-6899: Commit 0011e1405caa93c0fafc1a87b15c5fd58679f56d in geode's branch refs/heads/feature/GEODE-6899 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0011e14 ] GEODE-6899: retried client should set last try's version tag if found Co-authored-by: Xiaojian Zhou Co-authored-by: Eric Shu > retried client should set last try's version tag if found > - > > Key: GEODE-6899 > URL: https://issues.apache.org/jira/browse/GEODE-6899 > Project: Geode > Issue Type: Bug >Reporter: xiaojian zhou >Priority: Major > > client does a put to serverA with replicated region, serverA distributed to B > and C, before the distribution arrived at C, A is killed. Then client could > retry to C. C noticed this is a retry operation, it will search for previous > try's version tag. > The found tag should be set into the current event. Interesting thing is: > I found other operations, such as PutIfAbsent and create, they both did that. > But replace (i.e. put) did not. > Another issue is: GEODE-6802 introduce a synchronizeIfNotScheduled(). But > there could be a race that membershipListener is also scheduling. The fix is > to pause 1 second before calling the newly introduced > synchronizeIfNotScheduled(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6900) Add a unit test that transaction1 commit failed if it writes on a key was read in transaction2 and transaction2 has hold the lock when read conflict detection is on
[ https://issues.apache.org/jira/browse/GEODE-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-6900: --- Assignee: Eric Shu > Add a unit test that transaction1 commit failed if it writes on a key was > read in transaction2 and transaction2 has hold the lock when read conflict > detection is on > - > > Key: GEODE-6900 > URL: https://issues.apache.org/jira/browse/GEODE-6900 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > > Need to add a unit test with read conflict detection is on. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6899) retried client should set last try's version tag if found
xiaojian zhou created GEODE-6899: Summary: retried client should set last try's version tag if found Key: GEODE-6899 URL: https://issues.apache.org/jira/browse/GEODE-6899 Project: Geode Issue Type: Bug Reporter: xiaojian zhou client does a put to serverA with replicated region, serverA distributed to B and C, before the distribution arrived at C, A is killed. Then client could retry to C. C noticed this is a retry operation, it will search for previous try's version tag. The found tag should be set into the current event. Interesting thing is: I found other operations, such as PutIfAbsent and create, they both did that. But replace (i.e. put) did not. Another issue is: GEODE-6802 introduce a synchronizeIfNotScheduled(). But there could be a race that membershipListener is also scheduling. The fix is to pause 1 second before calling the newly introduced synchronizeIfNotScheduled(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6900) Add a unit test that transaction1 commit failed if it writes on a key was read in transaction2 and transaction2 has hold the lock when read conflict detection is on
Eric Shu created GEODE-6900: --- Summary: Add a unit test that transaction1 commit failed if it writes on a key was read in transaction2 and transaction2 has hold the lock when read conflict detection is on Key: GEODE-6900 URL: https://issues.apache.org/jira/browse/GEODE-6900 Project: Geode Issue Type: Bug Components: transactions Reporter: Eric Shu Need to add a unit test with read conflict detection is on. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6636) Buffers.acquireBuffer is not optimal
[
https://issues.apache.org/jira/browse/GEODE-6636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869956#comment-16869956
]
Darrel Schneider commented on GEODE-6636:
-
I found the following changes cause the size of the buffers in this pool to be
consistent. So consider using it as part of this fix or another ticket:
{noformat}
diff --git
a/geode-core/src/main/java/org/apache/geode/internal/net/NioPlainEngine.java
b/geode-core/src/main/java/org/apache/geode/internal/net/NioPlainEngine.java
index 2c901e6836..a10515a0b8 100644
--- a/geode-core/src/main/java/org/apache/geode/internal/net/NioPlainEngine.java
+++ b/geode-core/src/main/java/org/apache/geode/internal/net/NioPlainEngine.java
@@ -35,9 +35,16 @@ public class NioPlainEngine implements NioFilter {
int lastReadPosition;
int lastProcessedPosition;
+ final int minimumBufferSize;
- public NioPlainEngine() {}
+ public NioPlainEngine() {
+this(0);
+ }
+
+ public NioPlainEngine(int minimumBufferSize) {
+this.minimumBufferSize = minimumBufferSize;
+ }
@Override
public ByteBuffer wrap(ByteBuffer buffer) {
@@ -56,7 +63,11 @@ public class NioPlainEngine implements NioFilter {
ByteBuffer buffer = wrappedBuffer;
if (buffer == null) {
- buffer = Buffers.acquireBuffer(bufferType, amount, stats);
+ int bufferSize = amount;
+ if (bufferSize < minimumBufferSize) {
+bufferSize = minimumBufferSize;
+ }
+ buffer = Buffers.acquireBuffer(bufferType, bufferSize, stats);
buffer.clear();
lastProcessedPosition = 0;
lastReadPosition = 0;
diff --git
a/geode-core/src/main/java/org/apache/geode/internal/tcp/Connection.java
b/geode-core/src/main/java/org/apache/geode/internal/tcp/Connection.java
index 2ba313ed89..f6533ccf36 100644
--- a/geode-core/src/main/java/org/apache/geode/internal/tcp/Connection.java
+++ b/geode-core/src/main/java/org/apache/geode/internal/tcp/Connection.java
@@ -1132,7 +1132,9 @@ public class Connection implements Runnable {
if (!sharedResource) {
setReceiveBufferSize(channel.socket(),
this.owner.getConduit().tcpBufferSize);
} else {
-setReceiveBufferSize(channel.socket(), SMALL_BUFFER_SIZE); // make
small since only
+// prefer standard size buffer
+setReceiveBufferSize(channel.socket(),
this.owner.getConduit().tcpBufferSize);
+// setReceiveBufferSize(channel.socket(), SMALL_BUFFER_SIZE); // make
small since only
// receive ack messages
}
setSendBufferSize(channel.socket());
@@ -1853,7 +1855,7 @@ public class Connection implements Runnable {
ioFilter =
getConduit().getSocketCreator().handshakeSSLSocketChannel(channel, engine,
getConduit().idleConnectionTimeout, clientSocket, inputBuffer,
getConduit().getStats());
} else {
- ioFilter = new NioPlainEngine();
+ ioFilter = new NioPlainEngine(getConduit().tcpBufferSize);
}
}
{noformat}
> Buffers.acquireBuffer is not optimal
>
>
> Key: GEODE-6636
> URL: https://issues.apache.org/jira/browse/GEODE-6636
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Darrel Schneider
>Assignee: Helena Bales
>Priority: Major
> Labels: performance
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> org.apache.geode.internal.net.Buffers.acquireBuffer takes buffers out of a
> ConcurrentLinkedQueue. If the buffer is too small then it adds it back to the
> queue and adds it to an IdentityHashMap. The map is just to detect if we have
> looped around and found one we added to the map in a previous iteration.
> A more efficient way to do this, which will only remove things from the queue
> that we will either throw away or use and return later, and which gets rid of
> the map, is to use ConcurrentLinkedQueue.remove(Object). You can see an
> example of this by looking at:
> AvailableConnectionManager.EqualsWithPredicate. The predicate to use with
> acquireBuffer is that the soft reference is null or that the capacity of the
> referenced buffer is large enough. If you remove one because the reference is
> null then you need to call remove(Object) again (after decrementing the
> correct stat) since all you did was find one that had been garbage collected.
> You want to keep the predicate as cheap as possible since it is called in the
> "compare-and-set" spin loop. The more you do in the predicate, the more
> likely a concurrent thread will take that buffer and you will need to spin
> around and try again.
> I was surprised when running a benchmark under the profiler to see operations
> on this IdentityHashMap show up. The benchmark was doing pr puts of all the
> same size so I would have thought all these direct buffers would be the same.
> I
[jira] [Resolved] (GEODE-6888) CI failure: HAGIIDUnitTest.testGIIRegionQueue Suspect string in the log
[ https://issues.apache.org/jira/browse/GEODE-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun resolved GEODE-6888. Resolution: Fixed Fix Version/s: 1.10.0 > CI failure: HAGIIDUnitTest.testGIIRegionQueue Suspect string in the log > --- > > Key: GEODE-6888 > URL: https://issues.apache.org/jira/browse/GEODE-6888 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Anilkumar Gingade >Assignee: nabarun >Priority: Major > Fix For: 1.10.0 > > Time Spent: 50m > Remaining Estimate: 0h > > java.lang.AssertionError: Suspicious strings were written to the log during > this run. Fix the strings or use IgnoredException.addIgnoredException to > ignore. > --- > Found suspect string in log4j at line 2826 java.net.ConnectException: > Connection refused (Connection refused) > Vm2 log with Exception: > [vm2] Library Path: [vm2] /usr/java/packages/lib [vm2] > /usr/lib/x86_64-linux-gnu/jni [vm2] /lib/x86_64-linux-gnu [vm2] > /usr/lib/x86_64-linux-gnu [vm2] /usr/lib/jni [vm2] /lib [vm2] /usr/lib [vm2] > System Properties: [vm2] Locator.inhibitDMBanner = true [vm2] WORKSPACE_DIR = > /home/geode/geode/geode-core/build/distributedTest933/. [vm2] awt.toolkit = > sun.awt.X11.XToolkit [vm2] dummyArg = true [vm2] file.encoding = UTF-8 [vm2] > file.separator = / [vm2] gemfire.DEFAULT_MAX_OPLOG_SIZE = 10 [vm2] > gemfire.DUnitLauncher.LAUNCHED = true [vm2] gemfire.DUnitLauncher.RMI_PORT = > 24145 [vm2] gemfire.DUnitLauncher.VM_NUM = 2 [vm2] > gemfire.DUnitLauncher.VM_VERSION = 000 [vm2] gemfire.disallowMcastDefaults = > true [vm2] gemfire.free-off-heap-memory = true [vm2] > gemfire.use-ephemeral-ports = true [vm2] > gemfire.validate-serializable-objects = true [vm2] java.awt.graphicsenv = > sun.awt.X11GraphicsEnvironment [vm2] java.awt.printerjob = > sun.print.PSPrinterJob [vm2] java.class.version = 55.0 [vm2] java.home = > /usr/lib/jvm/java-11-openjdk-amd64 [vm2] java.io.tmpdir = /tmp [vm2] > java.runtime.name = OpenJDK Runtime Environment [vm2] java.runtime.version = > 11.0.3+7-Ubuntu-1ubuntu218.04.1 [vm2] java.specification.name = Java Platform > API Specification [vm2] java.specification.vendor = Oracle Corporation [vm2] > java.specification.version = 11 [vm2] java.vendor = Oracle Corporation [vm2] > java.vendor.url = [http://java.oracle.com/] [vm2] java.vendor.url.bug = > [http://bugreport.java.com/bugreport/] [vm2] java.version = 11.0.3 [vm2] > java.version.date = 2019-04-16 [vm2] java.vm.compressedOopsMode = 32-bit > [vm2] java.vm.info = mixed mode, sharing [vm2] java.vm.name = OpenJDK 64-Bit > Server VM [vm2] java.vm.specification.name = Java Virtual Machine > Specification [vm2] java.vm.specification.vendor = Oracle Corporation [vm2] > java.vm.specification.version = 11 [vm2] java.vm.vendor = Oracle Corporation > [vm2] java.vm.version = 11.0.3+7-Ubuntu-1ubuntu218.04.1 [vm2] jdk.debug = > release [vm2] line.separator = [vm2] log-level = info [vm2] os.version = > 4.15.0-1033-gcp [vm2] path.separator = : [vm2] sun.arch.data.model = 64 [vm2] > sun.boot.library.path = /usr/lib/jvm/java-11-openjdk-amd64/lib [vm2] > sun.cpu.endian = little [vm2] sun.cpu.isalist = [vm2] sun.io.unicode.encoding > = UnicodeLittle [vm2] sun.java.command = > org.apache.geode.test.dunit.internal.ChildVM [vm2] sun.java.launcher = > SUN_STANDARD [vm2] sun.jnu.encoding = UTF-8 [vm2] sun.management.compiler = > HotSpot 64-Bit Tiered Compilers [vm2] sun.nio.ch.bugLevel = [vm2] > sun.os.patch.level = unknown [vm2] user.language = en [vm2] user.timezone = > GMT [vm2] Log4J 2 Configuration: [vm2] > /home/geode/geode/geode-core/build/resources/main/log4j2.xml [vm2] > --- > [vm2] [info 2019/06/18 16:53:44.443 GMT > tid=0x22] Startup Configuration: [vm2] ### GemFire Properties defined with > system property ### [vm2] validate-serializable-objects=true [vm2] ### > GemFire Properties defined with api ### [vm2] disable-auto-reconnect=true > [vm2] enable-cluster-configuration=false [vm2] locators= [vm2] log-level=info > [vm2] mcast-port=0 [vm2] use-cluster-configuration=false [vm2] ### GemFire > Properties using default values ### [vm2] ack-severe-alert-threshold=0 [vm2] > ack-wait-threshold=15 [vm2] archive-disk-space-limit=0 [vm2] > archive-file-size-limit=0 [vm2] async-distribution-timeout=0 [vm2] > async-max-queue-size=8 [vm2] async-queue-timeout=6 [vm2] bind-address= > [vm2] cache-xml-file=cache.xml [vm2] cluster-configuration-dir= [vm2] > cluster-ssl-ciphers=any [vm2] cluster-ssl-enabled=false [vm2] > cluster-ssl-keystore= [vm2] cluster-ssl-keystore-password= [vm2] >
[jira] [Commented] (GEODE-6051) CI Failure: ClientServerMiscBCDUnitTest.giiEventQueueFromCurrentToOldMemberShouldSucceed FAILED
[ https://issues.apache.org/jira/browse/GEODE-6051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869914#comment-16869914 ] ASF subversion and git services commented on GEODE-6051: Commit 4a3ae76720515c340d991eb1da239b4df60fde98 in geode's branch refs/heads/develop from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4a3ae76 ] GEODE-6888: Adding ignored exception for ConnectException (#3740) * Immitating the fix for GEODE-6051 * Compared successfull runs of the test on IntelliJ and comapared the logs to the failed tests and all the stacktraces match. > CI Failure: > ClientServerMiscBCDUnitTest.giiEventQueueFromCurrentToOldMemberShouldSucceed > FAILED > --- > > Key: GEODE-6051 > URL: https://issues.apache.org/jira/browse/GEODE-6051 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > See this failure in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/110 > org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest > > giiEventQueueFromCurrentToOldMemberShouldSucceed[1] FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 3048 > java.net.ConnectException: Connection refused (Connection refused) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6888) CI failure: HAGIIDUnitTest.testGIIRegionQueue Suspect string in the log
[ https://issues.apache.org/jira/browse/GEODE-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869913#comment-16869913 ] ASF subversion and git services commented on GEODE-6888: Commit 4a3ae76720515c340d991eb1da239b4df60fde98 in geode's branch refs/heads/develop from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4a3ae76 ] GEODE-6888: Adding ignored exception for ConnectException (#3740) * Immitating the fix for GEODE-6051 * Compared successfull runs of the test on IntelliJ and comapared the logs to the failed tests and all the stacktraces match. > CI failure: HAGIIDUnitTest.testGIIRegionQueue Suspect string in the log > --- > > Key: GEODE-6888 > URL: https://issues.apache.org/jira/browse/GEODE-6888 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Anilkumar Gingade >Assignee: nabarun >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > java.lang.AssertionError: Suspicious strings were written to the log during > this run. Fix the strings or use IgnoredException.addIgnoredException to > ignore. > --- > Found suspect string in log4j at line 2826 java.net.ConnectException: > Connection refused (Connection refused) > Vm2 log with Exception: > [vm2] Library Path: [vm2] /usr/java/packages/lib [vm2] > /usr/lib/x86_64-linux-gnu/jni [vm2] /lib/x86_64-linux-gnu [vm2] > /usr/lib/x86_64-linux-gnu [vm2] /usr/lib/jni [vm2] /lib [vm2] /usr/lib [vm2] > System Properties: [vm2] Locator.inhibitDMBanner = true [vm2] WORKSPACE_DIR = > /home/geode/geode/geode-core/build/distributedTest933/. [vm2] awt.toolkit = > sun.awt.X11.XToolkit [vm2] dummyArg = true [vm2] file.encoding = UTF-8 [vm2] > file.separator = / [vm2] gemfire.DEFAULT_MAX_OPLOG_SIZE = 10 [vm2] > gemfire.DUnitLauncher.LAUNCHED = true [vm2] gemfire.DUnitLauncher.RMI_PORT = > 24145 [vm2] gemfire.DUnitLauncher.VM_NUM = 2 [vm2] > gemfire.DUnitLauncher.VM_VERSION = 000 [vm2] gemfire.disallowMcastDefaults = > true [vm2] gemfire.free-off-heap-memory = true [vm2] > gemfire.use-ephemeral-ports = true [vm2] > gemfire.validate-serializable-objects = true [vm2] java.awt.graphicsenv = > sun.awt.X11GraphicsEnvironment [vm2] java.awt.printerjob = > sun.print.PSPrinterJob [vm2] java.class.version = 55.0 [vm2] java.home = > /usr/lib/jvm/java-11-openjdk-amd64 [vm2] java.io.tmpdir = /tmp [vm2] > java.runtime.name = OpenJDK Runtime Environment [vm2] java.runtime.version = > 11.0.3+7-Ubuntu-1ubuntu218.04.1 [vm2] java.specification.name = Java Platform > API Specification [vm2] java.specification.vendor = Oracle Corporation [vm2] > java.specification.version = 11 [vm2] java.vendor = Oracle Corporation [vm2] > java.vendor.url = [http://java.oracle.com/] [vm2] java.vendor.url.bug = > [http://bugreport.java.com/bugreport/] [vm2] java.version = 11.0.3 [vm2] > java.version.date = 2019-04-16 [vm2] java.vm.compressedOopsMode = 32-bit > [vm2] java.vm.info = mixed mode, sharing [vm2] java.vm.name = OpenJDK 64-Bit > Server VM [vm2] java.vm.specification.name = Java Virtual Machine > Specification [vm2] java.vm.specification.vendor = Oracle Corporation [vm2] > java.vm.specification.version = 11 [vm2] java.vm.vendor = Oracle Corporation > [vm2] java.vm.version = 11.0.3+7-Ubuntu-1ubuntu218.04.1 [vm2] jdk.debug = > release [vm2] line.separator = [vm2] log-level = info [vm2] os.version = > 4.15.0-1033-gcp [vm2] path.separator = : [vm2] sun.arch.data.model = 64 [vm2] > sun.boot.library.path = /usr/lib/jvm/java-11-openjdk-amd64/lib [vm2] > sun.cpu.endian = little [vm2] sun.cpu.isalist = [vm2] sun.io.unicode.encoding > = UnicodeLittle [vm2] sun.java.command = > org.apache.geode.test.dunit.internal.ChildVM [vm2] sun.java.launcher = > SUN_STANDARD [vm2] sun.jnu.encoding = UTF-8 [vm2] sun.management.compiler = > HotSpot 64-Bit Tiered Compilers [vm2] sun.nio.ch.bugLevel = [vm2] > sun.os.patch.level = unknown [vm2] user.language = en [vm2] user.timezone = > GMT [vm2] Log4J 2 Configuration: [vm2] > /home/geode/geode/geode-core/build/resources/main/log4j2.xml [vm2] > --- > [vm2] [info 2019/06/18 16:53:44.443 GMT > tid=0x22] Startup Configuration: [vm2] ### GemFire Properties defined with > system property ### [vm2] validate-serializable-objects=true [vm2] ### > GemFire Properties defined with api ### [vm2] disable-auto-reconnect=true > [vm2] enable-cluster-configuration=false [vm2] locators= [vm2] log-level=info > [vm2] mcast-port=0 [vm2] use-cluster-configuration=false [vm2] ### GemFire > Properties using default values ### [vm2] ack-severe-alert-threshold=0 [vm2] > ack-wait-threshold=15
[jira] [Comment Edited] (GEODE-6885) desribe config should redact some property values
[ https://issues.apache.org/jira/browse/GEODE-6885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869819#comment-16869819 ] Ashish Choudhary edited comment on GEODE-6885 at 6/21/19 7:29 PM: -- We can close this as we were testing on versions older then 1.9.0 and could see that it's being fixed in 1.9.0. Thanks Ashish was (Author: achoudhary): We can close this as we were testing on version older that 1.9.0 and could see that it's being fixed in 1.9.0. Thanks Ashish > desribe config should redact some property values > - > > Key: GEODE-6885 > URL: https://issues.apache.org/jira/browse/GEODE-6885 > Project: Geode > Issue Type: Bug > Components: security >Reporter: Ashish Choudhary >Priority: Major > > when you run describe config --member=memberName with ssl enabled on cluster > then it shows > ssl keystore and truststore password in plaintext. Is it acceptable or it's > being fixed in newer versions as with geode 1.2 version we see similar > behaviour that shows secrets in plain text?. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6885) desribe config should redact some property values
[ https://issues.apache.org/jira/browse/GEODE-6885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869819#comment-16869819 ] Ashish Choudhary commented on GEODE-6885: - We can close this as we were testing on version older that 1.9.0 and could see that it's being fixed in 1.9.0. Thanks Ashish > desribe config should redact some property values > - > > Key: GEODE-6885 > URL: https://issues.apache.org/jira/browse/GEODE-6885 > Project: Geode > Issue Type: Bug > Components: security >Reporter: Ashish Choudhary >Priority: Major > > when you run describe config --member=memberName with ssl enabled on cluster > then it shows > ssl keystore and truststore password in plaintext. Is it acceptable or it's > being fixed in newer versions as with geode 1.2 version we see similar > behaviour that shows secrets in plain text?. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6885) desribe config should redact some property values
[
https://issues.apache.org/jira/browse/GEODE-6885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869775#comment-16869775
]
Anthony Baker commented on GEODE-6885:
--
[~achoudhary] Can you provide more details on your test case? I believe we
addressed this issue with GEODE-6064.
When I invoke {{describe config}} on v1.9.0 I get this response which seems to
be the behaviory you're asking for:
{noformat}
GemFire properties defined with the property file
ssl-keystore-password :
{noformat}
> desribe config should redact some property values
> -
>
> Key: GEODE-6885
> URL: https://issues.apache.org/jira/browse/GEODE-6885
> Project: Geode
> Issue Type: Bug
> Components: security
>Reporter: Ashish Choudhary
>Priority: Major
>
> when you run describe config --member=memberName with ssl enabled on cluster
> then it shows
> ssl keystore and truststore password in plaintext. Is it acceptable or it's
> being fixed in newer versions as with geode 1.2 version we see similar
> behaviour that shows secrets in plain text?.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6636) Buffers.acquireBuffer is not optimal
[ https://issues.apache.org/jira/browse/GEODE-6636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helena Bales reassigned GEODE-6636: --- Assignee: Helena Bales > Buffers.acquireBuffer is not optimal > > > Key: GEODE-6636 > URL: https://issues.apache.org/jira/browse/GEODE-6636 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Helena Bales >Priority: Major > Labels: performance > > org.apache.geode.internal.net.Buffers.acquireBuffer takes buffers out of a > ConcurrentLinkedQueue. If the buffer is too small then it adds it back to the > queue and adds it to an IdentityHashMap. The map is just to detect if we have > looped around and found one we added to the map in a previous iteration. > A more efficient way to do this, which will only remove things from the queue > that we will either throw away or use and return later, and which gets rid of > the map, is to use ConcurrentLinkedQueue.remove(Object). You can see an > example of this by looking at: > AvailableConnectionManager.EqualsWithPredicate. The predicate to use with > acquireBuffer is that the soft reference is null or that the capacity of the > referenced buffer is large enough. If you remove one because the reference is > null then you need to call remove(Object) again (after decrementing the > correct stat) since all you did was find one that had been garbage collected. > You want to keep the predicate as cheap as possible since it is called in the > "compare-and-set" spin loop. The more you do in the predicate, the more > likely a concurrent thread will take that buffer and you will need to spin > around and try again. > I was surprised when running a benchmark under the profiler to see operations > on this IdentityHashMap show up. The benchmark was doing pr puts of all the > same size so I would have thought all these direct buffers would be the same. > I think it would be worth understanding what sizes of buffers will be > requested by acquireBuffer and how often they will be acquired and returned. > If different sizes is a normal use case then it probably would make sense to > have more than one queue. If we could go to a queue knowing that if it has a > buffer in it that it meets are desired size. The geode off-heap free list > implementation does this and only the largest allocations need to search > through a free list that has items in it that exceed a max size. Every other > free list is found quickly be using the requested size to index an array of > free lists, which only contain items of that size. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6387) MemberLevelStatsJUnitTest fails in StressTest
[
https://issues.apache.org/jira/browse/GEODE-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869733#comment-16869733
]
ASF subversion and git services commented on GEODE-6387:
Commit 304db494cc3ddf71a1bde9f2b694e8df65758037 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=304db49 ]
GEODE-6387: Fix compile error in DistributionStats
Compile error was caused by bungled conflict resolution while merging
in a PR.
> MemberLevelStatsJUnitTest fails in StressTest
> -
>
> Key: GEODE-6387
> URL: https://issues.apache.org/jira/browse/GEODE-6387
> Project: Geode
> Issue Type: Bug
> Components: statistics, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: StressTest, swat
> Fix For: 1.10.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> MemberLevelStatsJUnitTest appears to fail consistently in StressTest. This
> test relies on IntegrationTest forking a new JVM for each test. Any PR that
> touches MemberLevelStatsJUnitTest will reproduce this ticket.
> Test failure example call stack:
> {noformat}
> java.lang.IllegalStateException: A connection to a distributed system already
> exists in this VM. It has the following configuration:
> ack-severe-alert-threshold="0"
> ack-wait-threshold="15"
> archive-disk-space-limit="0"
> archive-file-size-limit="0"
> async-distribution-timeout="0"
> async-max-queue-size="8"
> async-queue-timeout="6"
> bind-address=""
> cache-xml-file="cache.xml"
> cluster-configuration-dir=""
> cluster-ssl-ciphers="any"
> cluster-ssl-enabled="false"
> cluster-ssl-keystore=""
> cluster-ssl-keystore-password=""
> cluster-ssl-keystore-type=""
> cluster-ssl-protocols="any"
> cluster-ssl-require-authentication="true"
> cluster-ssl-truststore=""
> cluster-ssl-truststore-password=""
> conflate-events="server"
> conserve-sockets="true"
> delta-propagation="true"
>
> deploy-working-dir="/home/geode/geode/geode-core/build/repeatIntegrationTest31"
> disable-auto-reconnect="false"
> disable-jmx="false"
> disable-tcp="false"
> distributed-system-id="-1"
> distributed-transactions="false"
> durable-client-id=""
> durable-client-timeout="300"
> enable-cluster-configuration="true"
> enable-network-partition-detection="true"
> enable-time-statistics="false" ***(wanted "true")***
> enforce-unique-host="false"
> gateway-ssl-ciphers="any"
> gateway-ssl-enabled="false"
> gateway-ssl-keystore=""
> gateway-ssl-keystore-password=""
> gateway-ssl-keystore-type=""
> gateway-ssl-protocols="any"
> gateway-ssl-require-authentication="true"
> gateway-ssl-truststore=""
> gateway-ssl-truststore-password=""
> groups=""
> http-service-bind-address=""
> http-service-port="7070"
> http-service-ssl-ciphers="any"
> http-service-ssl-enabled="false"
> http-service-ssl-keystore=""
> http-service-ssl-keystore-password=""
> http-service-ssl-keystore-type=""
> http-service-ssl-protocols="any"
> http-service-ssl-require-authentication="false"
> http-service-ssl-truststore=""
> http-service-ssl-truststore-password=""
> jmx-manager="false"
> jmx-manager-access-file=""
> jmx-manager-bind-address=""
> jmx-manager-hostname-for-clients=""
> jmx-manager-http-port="7070"
> jmx-manager-password-file=""
> jmx-manager-port="1099"
> jmx-manager-ssl-ciphers="any"
> jmx-manager-ssl-enabled="false"
> jmx-manager-ssl-keystore=""
> jmx-manager-ssl-keystore-password=""
> jmx-manager-ssl-keystore-type=""
> jmx-manager-ssl-protocols="any"
> jmx-manager-ssl-require-authentication="true"
> jmx-manager-ssl-truststore=""
> jmx-manager-ssl-truststore-password=""
> jmx-manager-start="false"
> jmx-manager-update-rate="2000"
> load-cluster-configuration-from-dir="false"
> locator-wait-time="0"
> locators=""
> lock-memory="false"
> log-disk-space-limit="0"
> log-file=""
> log-file-size-limit="0"
> log-level="config"
> max-num-reconnect-tries="3"
> max-wait-time-reconnect="6"
> mcast-address="/239.192.81.1"
> mcast-flow-control="1048576, 0.25, 5000"
> mcast-port="0"
> mcast-recv-buffer-size="1048576"
> mcast-send-buffer-size="65535"
> mcast-ttl="32"
> member-timeout="5000"
> membership-port-range="[41000,61000]"
> memcached-bind-address=""
> memcached-port="0"
> memcached-protocol="ASCII"
> name=""
> off-heap-memory-size=""
> redis-bind-address=""
> redis-password=""
> redis-port="0"
> redundancy-zone=""
> remote-locators=""
> remove-unresponsive-client="false"
> roles=""
> security-client-accessor=""
> security-client-accessor-pp=""
> security-client-auth-init=""
> security-client-authenticator=""
[jira] [Resolved] (GEODE-6834) PartitionedRegionStats counters should be 64 bit to prevent wrap around
[ https://issues.apache.org/jira/browse/GEODE-6834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-6834. - Resolution: Fixed Fix Version/s: 1.10.0 > PartitionedRegionStats counters should be 64 bit to prevent wrap around > --- > > Key: GEODE-6834 > URL: https://issues.apache.org/jira/browse/GEODE-6834 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.10.0 > > Time Spent: 50m > Remaining Estimate: 0h > > I was looking at getsCompleted on PartitionedRegionStats when the gets are > done in a function and they happen so fast that the 32-bit counter wraps > around. > Other stats on PartitionedRegionStats could have the same issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6885) desribe config should redact some property values
[ https://issues.apache.org/jira/browse/GEODE-6885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-6885: - Summary: desribe config should redact some property values (was: desribe config shows ssl keystore and truststore password in plaintext) > desribe config should redact some property values > - > > Key: GEODE-6885 > URL: https://issues.apache.org/jira/browse/GEODE-6885 > Project: Geode > Issue Type: Bug > Components: security >Reporter: Ashish Choudhary >Priority: Major > > when you run describe config --member=memberName with ssl enabled on cluster > then it shows > ssl keystore and truststore password in plaintext. Is it acceptable or it's > being fixed in newer versions as with geode 1.2 version we see similar > behaviour that shows secrets in plain text?. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6834) PartitionedRegionStats counters should be 64 bit to prevent wrap around
[ https://issues.apache.org/jira/browse/GEODE-6834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869708#comment-16869708 ] ASF subversion and git services commented on GEODE-6834: Commit 7a94527ac804279bfd233e9a74ec02d53dcde0b2 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7a94527 ] GEODE-6834: change PartitionedRegionStats to not use deprecated "Int" methods (#3689) > PartitionedRegionStats counters should be 64 bit to prevent wrap around > --- > > Key: GEODE-6834 > URL: https://issues.apache.org/jira/browse/GEODE-6834 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > I was looking at getsCompleted on PartitionedRegionStats when the gets are > done in a function and they happen so fast that the 32-bit counter wraps > around. > Other stats on PartitionedRegionStats could have the same issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6834) PartitionedRegionStats counters should be 64 bit to prevent wrap around
[ https://issues.apache.org/jira/browse/GEODE-6834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869703#comment-16869703 ] Darrel Schneider commented on GEODE-6834: - This was fixed by GEODE-6850. The only remaining work related to this ticket is to change PartitionedRegionStats to not call the deprecated "Int" methods. > PartitionedRegionStats counters should be 64 bit to prevent wrap around > --- > > Key: GEODE-6834 > URL: https://issues.apache.org/jira/browse/GEODE-6834 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > I was looking at getsCompleted on PartitionedRegionStats when the gets are > done in a function and they happen so fast that the 32-bit counter wraps > around. > Other stats on PartitionedRegionStats could have the same issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6895) Change v2 REST API context to 'management/v2'
[
https://issues.apache.org/jira/browse/GEODE-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869691#comment-16869691
]
ASF subversion and git services commented on GEODE-6895:
Commit 964736ce15ec1e5f0cc2af8f726223e173228c52 in geode's branch
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=964736c ]
GEODE-6895: Change v2 REST API endpoint to '/management/v2' (#3739)
> Change v2 REST API context to 'management/v2'
> -
>
> Key: GEODE-6895
> URL: https://issues.apache.org/jira/browse/GEODE-6895
> Project: Geode
> Issue Type: Task
> Components: management
>Reporter: Jens Deppe
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Change our endpoint from {{geode-management/v2}} to {{management/v2}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6897) Create REST v2 endpoint to launch an asynchronous operation
[ https://issues.apache.org/jira/browse/GEODE-6897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-6897: -- Summary: Create REST v2 endpoint to launch an asynchronous operation (was: Create REST v2 endpoint to launch asynchronous operation) > Create REST v2 endpoint to launch an asynchronous operation > --- > > Key: GEODE-6897 > URL: https://issues.apache.org/jira/browse/GEODE-6897 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jinmei Liao >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6897) Create a REST v2 endpoint to launch an asynchronous operation
[ https://issues.apache.org/jira/browse/GEODE-6897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-6897: -- Summary: Create a REST v2 endpoint to launch an asynchronous operation (was: Create REST v2 endpoint to launch an asynchronous operation) > Create a REST v2 endpoint to launch an asynchronous operation > - > > Key: GEODE-6897 > URL: https://issues.apache.org/jira/browse/GEODE-6897 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jinmei Liao >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6897) Create REST v2 endpoint to launch asynchronous operation
[ https://issues.apache.org/jira/browse/GEODE-6897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-6897: -- Summary: Create REST v2 endpoint to launch asynchronous operation (was: user should be able to do a rebalance when using management rest api) > Create REST v2 endpoint to launch asynchronous operation > > > Key: GEODE-6897 > URL: https://issues.apache.org/jira/browse/GEODE-6897 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jinmei Liao >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6387) MemberLevelStatsJUnitTest fails in StressTest
[
https://issues.apache.org/jira/browse/GEODE-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-6387.
--
Resolution: Fixed
Fix Version/s: 1.10.0
> MemberLevelStatsJUnitTest fails in StressTest
> -
>
> Key: GEODE-6387
> URL: https://issues.apache.org/jira/browse/GEODE-6387
> Project: Geode
> Issue Type: Bug
> Components: statistics, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: StressTest, swat
> Fix For: 1.10.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> MemberLevelStatsJUnitTest appears to fail consistently in StressTest. This
> test relies on IntegrationTest forking a new JVM for each test. Any PR that
> touches MemberLevelStatsJUnitTest will reproduce this ticket.
> Test failure example call stack:
> {noformat}
> java.lang.IllegalStateException: A connection to a distributed system already
> exists in this VM. It has the following configuration:
> ack-severe-alert-threshold="0"
> ack-wait-threshold="15"
> archive-disk-space-limit="0"
> archive-file-size-limit="0"
> async-distribution-timeout="0"
> async-max-queue-size="8"
> async-queue-timeout="6"
> bind-address=""
> cache-xml-file="cache.xml"
> cluster-configuration-dir=""
> cluster-ssl-ciphers="any"
> cluster-ssl-enabled="false"
> cluster-ssl-keystore=""
> cluster-ssl-keystore-password=""
> cluster-ssl-keystore-type=""
> cluster-ssl-protocols="any"
> cluster-ssl-require-authentication="true"
> cluster-ssl-truststore=""
> cluster-ssl-truststore-password=""
> conflate-events="server"
> conserve-sockets="true"
> delta-propagation="true"
>
> deploy-working-dir="/home/geode/geode/geode-core/build/repeatIntegrationTest31"
> disable-auto-reconnect="false"
> disable-jmx="false"
> disable-tcp="false"
> distributed-system-id="-1"
> distributed-transactions="false"
> durable-client-id=""
> durable-client-timeout="300"
> enable-cluster-configuration="true"
> enable-network-partition-detection="true"
> enable-time-statistics="false" ***(wanted "true")***
> enforce-unique-host="false"
> gateway-ssl-ciphers="any"
> gateway-ssl-enabled="false"
> gateway-ssl-keystore=""
> gateway-ssl-keystore-password=""
> gateway-ssl-keystore-type=""
> gateway-ssl-protocols="any"
> gateway-ssl-require-authentication="true"
> gateway-ssl-truststore=""
> gateway-ssl-truststore-password=""
> groups=""
> http-service-bind-address=""
> http-service-port="7070"
> http-service-ssl-ciphers="any"
> http-service-ssl-enabled="false"
> http-service-ssl-keystore=""
> http-service-ssl-keystore-password=""
> http-service-ssl-keystore-type=""
> http-service-ssl-protocols="any"
> http-service-ssl-require-authentication="false"
> http-service-ssl-truststore=""
> http-service-ssl-truststore-password=""
> jmx-manager="false"
> jmx-manager-access-file=""
> jmx-manager-bind-address=""
> jmx-manager-hostname-for-clients=""
> jmx-manager-http-port="7070"
> jmx-manager-password-file=""
> jmx-manager-port="1099"
> jmx-manager-ssl-ciphers="any"
> jmx-manager-ssl-enabled="false"
> jmx-manager-ssl-keystore=""
> jmx-manager-ssl-keystore-password=""
> jmx-manager-ssl-keystore-type=""
> jmx-manager-ssl-protocols="any"
> jmx-manager-ssl-require-authentication="true"
> jmx-manager-ssl-truststore=""
> jmx-manager-ssl-truststore-password=""
> jmx-manager-start="false"
> jmx-manager-update-rate="2000"
> load-cluster-configuration-from-dir="false"
> locator-wait-time="0"
> locators=""
> lock-memory="false"
> log-disk-space-limit="0"
> log-file=""
> log-file-size-limit="0"
> log-level="config"
> max-num-reconnect-tries="3"
> max-wait-time-reconnect="6"
> mcast-address="/239.192.81.1"
> mcast-flow-control="1048576, 0.25, 5000"
> mcast-port="0"
> mcast-recv-buffer-size="1048576"
> mcast-send-buffer-size="65535"
> mcast-ttl="32"
> member-timeout="5000"
> membership-port-range="[41000,61000]"
> memcached-bind-address=""
> memcached-port="0"
> memcached-protocol="ASCII"
> name=""
> off-heap-memory-size=""
> redis-bind-address=""
> redis-password=""
> redis-port="0"
> redundancy-zone=""
> remote-locators=""
> remove-unresponsive-client="false"
> roles=""
> security-client-accessor=""
> security-client-accessor-pp=""
> security-client-auth-init=""
> security-client-authenticator=""
> security-client-dhalgo=""
> security-log-file=""
> security-log-level="config"
> security-manager=""
> security-peer-auth-init=""
> security-peer-authenticator=""
> security-peer-verifymember-timeout="1000"
> security-post-processor=""
> security-shiro-init=""
> security-udp-dhalgo=""
>
[jira] [Commented] (GEODE-6387) MemberLevelStatsJUnitTest fails in StressTest
[
https://issues.apache.org/jira/browse/GEODE-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869672#comment-16869672
]
ASF subversion and git services commented on GEODE-6387:
Commit f3547132d0fe0f68fdb65bfc498dad70460785e9 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f354713 ]
GEODE-6387: Rename MemberLevelStatsIntegrationTest
Rename MemberLevelStatsJUnitTest to MemberLevelStatsIntegrationTest.
> MemberLevelStatsJUnitTest fails in StressTest
> -
>
> Key: GEODE-6387
> URL: https://issues.apache.org/jira/browse/GEODE-6387
> Project: Geode
> Issue Type: Bug
> Components: statistics, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: StressTest, swat
> Time Spent: 1h
> Remaining Estimate: 0h
>
> MemberLevelStatsJUnitTest appears to fail consistently in StressTest. This
> test relies on IntegrationTest forking a new JVM for each test. Any PR that
> touches MemberLevelStatsJUnitTest will reproduce this ticket.
> Test failure example call stack:
> {noformat}
> java.lang.IllegalStateException: A connection to a distributed system already
> exists in this VM. It has the following configuration:
> ack-severe-alert-threshold="0"
> ack-wait-threshold="15"
> archive-disk-space-limit="0"
> archive-file-size-limit="0"
> async-distribution-timeout="0"
> async-max-queue-size="8"
> async-queue-timeout="6"
> bind-address=""
> cache-xml-file="cache.xml"
> cluster-configuration-dir=""
> cluster-ssl-ciphers="any"
> cluster-ssl-enabled="false"
> cluster-ssl-keystore=""
> cluster-ssl-keystore-password=""
> cluster-ssl-keystore-type=""
> cluster-ssl-protocols="any"
> cluster-ssl-require-authentication="true"
> cluster-ssl-truststore=""
> cluster-ssl-truststore-password=""
> conflate-events="server"
> conserve-sockets="true"
> delta-propagation="true"
>
> deploy-working-dir="/home/geode/geode/geode-core/build/repeatIntegrationTest31"
> disable-auto-reconnect="false"
> disable-jmx="false"
> disable-tcp="false"
> distributed-system-id="-1"
> distributed-transactions="false"
> durable-client-id=""
> durable-client-timeout="300"
> enable-cluster-configuration="true"
> enable-network-partition-detection="true"
> enable-time-statistics="false" ***(wanted "true")***
> enforce-unique-host="false"
> gateway-ssl-ciphers="any"
> gateway-ssl-enabled="false"
> gateway-ssl-keystore=""
> gateway-ssl-keystore-password=""
> gateway-ssl-keystore-type=""
> gateway-ssl-protocols="any"
> gateway-ssl-require-authentication="true"
> gateway-ssl-truststore=""
> gateway-ssl-truststore-password=""
> groups=""
> http-service-bind-address=""
> http-service-port="7070"
> http-service-ssl-ciphers="any"
> http-service-ssl-enabled="false"
> http-service-ssl-keystore=""
> http-service-ssl-keystore-password=""
> http-service-ssl-keystore-type=""
> http-service-ssl-protocols="any"
> http-service-ssl-require-authentication="false"
> http-service-ssl-truststore=""
> http-service-ssl-truststore-password=""
> jmx-manager="false"
> jmx-manager-access-file=""
> jmx-manager-bind-address=""
> jmx-manager-hostname-for-clients=""
> jmx-manager-http-port="7070"
> jmx-manager-password-file=""
> jmx-manager-port="1099"
> jmx-manager-ssl-ciphers="any"
> jmx-manager-ssl-enabled="false"
> jmx-manager-ssl-keystore=""
> jmx-manager-ssl-keystore-password=""
> jmx-manager-ssl-keystore-type=""
> jmx-manager-ssl-protocols="any"
> jmx-manager-ssl-require-authentication="true"
> jmx-manager-ssl-truststore=""
> jmx-manager-ssl-truststore-password=""
> jmx-manager-start="false"
> jmx-manager-update-rate="2000"
> load-cluster-configuration-from-dir="false"
> locator-wait-time="0"
> locators=""
> lock-memory="false"
> log-disk-space-limit="0"
> log-file=""
> log-file-size-limit="0"
> log-level="config"
> max-num-reconnect-tries="3"
> max-wait-time-reconnect="6"
> mcast-address="/239.192.81.1"
> mcast-flow-control="1048576, 0.25, 5000"
> mcast-port="0"
> mcast-recv-buffer-size="1048576"
> mcast-send-buffer-size="65535"
> mcast-ttl="32"
> member-timeout="5000"
> membership-port-range="[41000,61000]"
> memcached-bind-address=""
> memcached-port="0"
> memcached-protocol="ASCII"
> name=""
> off-heap-memory-size=""
> redis-bind-address=""
> redis-password=""
> redis-port="0"
> redundancy-zone=""
> remote-locators=""
> remove-unresponsive-client="false"
> roles=""
> security-client-accessor=""
> security-client-accessor-pp=""
> security-client-auth-init=""
> security-client-authenticator=""
> security-client-dhalgo=""
>
[jira] [Commented] (GEODE-6387) MemberLevelStatsJUnitTest fails in StressTest
[
https://issues.apache.org/jira/browse/GEODE-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869676#comment-16869676
]
ASF subversion and git services commented on GEODE-6387:
Commit 2df3bddac46c27954e7806048f4c8b8797b661d3 in geode's branch
refs/heads/develop from Michael Oleske
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2df3bdd ]
GEODE-6387: Clean up MemberMBeanBridge
* General cleanup of IDE warnings in MemberMBeanBridge
* Make some fields final
* Remove unused code
* Move constants to top of class
* Inline some very short methods
* Remove unnecessary uses of this
* Fix typos and improve variable names
* Apply @VisibleForTesting annotation to many methods that are not
private only because they are invoked from tests
* Declare variables when they are used
* Weaken declared types where possible
* Weaken access scopes where possible
* Remove useless javadocs
Authored-by: Michael Oleske
> MemberLevelStatsJUnitTest fails in StressTest
> -
>
> Key: GEODE-6387
> URL: https://issues.apache.org/jira/browse/GEODE-6387
> Project: Geode
> Issue Type: Bug
> Components: statistics, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: StressTest, swat
> Time Spent: 1h
> Remaining Estimate: 0h
>
> MemberLevelStatsJUnitTest appears to fail consistently in StressTest. This
> test relies on IntegrationTest forking a new JVM for each test. Any PR that
> touches MemberLevelStatsJUnitTest will reproduce this ticket.
> Test failure example call stack:
> {noformat}
> java.lang.IllegalStateException: A connection to a distributed system already
> exists in this VM. It has the following configuration:
> ack-severe-alert-threshold="0"
> ack-wait-threshold="15"
> archive-disk-space-limit="0"
> archive-file-size-limit="0"
> async-distribution-timeout="0"
> async-max-queue-size="8"
> async-queue-timeout="6"
> bind-address=""
> cache-xml-file="cache.xml"
> cluster-configuration-dir=""
> cluster-ssl-ciphers="any"
> cluster-ssl-enabled="false"
> cluster-ssl-keystore=""
> cluster-ssl-keystore-password=""
> cluster-ssl-keystore-type=""
> cluster-ssl-protocols="any"
> cluster-ssl-require-authentication="true"
> cluster-ssl-truststore=""
> cluster-ssl-truststore-password=""
> conflate-events="server"
> conserve-sockets="true"
> delta-propagation="true"
>
> deploy-working-dir="/home/geode/geode/geode-core/build/repeatIntegrationTest31"
> disable-auto-reconnect="false"
> disable-jmx="false"
> disable-tcp="false"
> distributed-system-id="-1"
> distributed-transactions="false"
> durable-client-id=""
> durable-client-timeout="300"
> enable-cluster-configuration="true"
> enable-network-partition-detection="true"
> enable-time-statistics="false" ***(wanted "true")***
> enforce-unique-host="false"
> gateway-ssl-ciphers="any"
> gateway-ssl-enabled="false"
> gateway-ssl-keystore=""
> gateway-ssl-keystore-password=""
> gateway-ssl-keystore-type=""
> gateway-ssl-protocols="any"
> gateway-ssl-require-authentication="true"
> gateway-ssl-truststore=""
> gateway-ssl-truststore-password=""
> groups=""
> http-service-bind-address=""
> http-service-port="7070"
> http-service-ssl-ciphers="any"
> http-service-ssl-enabled="false"
> http-service-ssl-keystore=""
> http-service-ssl-keystore-password=""
> http-service-ssl-keystore-type=""
> http-service-ssl-protocols="any"
> http-service-ssl-require-authentication="false"
> http-service-ssl-truststore=""
> http-service-ssl-truststore-password=""
> jmx-manager="false"
> jmx-manager-access-file=""
> jmx-manager-bind-address=""
> jmx-manager-hostname-for-clients=""
> jmx-manager-http-port="7070"
> jmx-manager-password-file=""
> jmx-manager-port="1099"
> jmx-manager-ssl-ciphers="any"
> jmx-manager-ssl-enabled="false"
> jmx-manager-ssl-keystore=""
> jmx-manager-ssl-keystore-password=""
> jmx-manager-ssl-keystore-type=""
> jmx-manager-ssl-protocols="any"
> jmx-manager-ssl-require-authentication="true"
> jmx-manager-ssl-truststore=""
> jmx-manager-ssl-truststore-password=""
> jmx-manager-start="false"
> jmx-manager-update-rate="2000"
> load-cluster-configuration-from-dir="false"
> locator-wait-time="0"
> locators=""
> lock-memory="false"
> log-disk-space-limit="0"
> log-file=""
> log-file-size-limit="0"
> log-level="config"
> max-num-reconnect-tries="3"
> max-wait-time-reconnect="6"
> mcast-address="/239.192.81.1"
> mcast-flow-control="1048576, 0.25, 5000"
> mcast-port="0"
> mcast-recv-buffer-size="1048576"
> mcast-send-buffer-size="65535"
> mcast-ttl="32"
> member-timeout="5000"
> membership-port-range="[41000,61000]"
>
[jira] [Commented] (GEODE-6387) MemberLevelStatsJUnitTest fails in StressTest
[
https://issues.apache.org/jira/browse/GEODE-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869675#comment-16869675
]
ASF subversion and git services commented on GEODE-6387:
Commit b21b7ef89e3f447c3ff842f62fe42c4b47022894 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b21b7ef ]
GEODE-6387: Extract MemberLevelStatsTest
MemberLevelStatsIntegrationTest setUp creates a cache, but the majority
of the tests do not even use or require that cache. So, it's a good
idea to extract those to the new unit test MemberLevelStatsTest.
These changes further isolate the testing in MemberLevelStatsTest to
avoid any potential flakiness.
We also clean up MemberLevelStatsIntegrationTest to prevent potential
causes of flakiness, but ultimately GEODE-6387 is now fixed because
only one test remains so it should be impossible for another test to
leave around an incompatible distributed system.
> MemberLevelStatsJUnitTest fails in StressTest
> -
>
> Key: GEODE-6387
> URL: https://issues.apache.org/jira/browse/GEODE-6387
> Project: Geode
> Issue Type: Bug
> Components: statistics, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: StressTest, swat
> Time Spent: 1h
> Remaining Estimate: 0h
>
> MemberLevelStatsJUnitTest appears to fail consistently in StressTest. This
> test relies on IntegrationTest forking a new JVM for each test. Any PR that
> touches MemberLevelStatsJUnitTest will reproduce this ticket.
> Test failure example call stack:
> {noformat}
> java.lang.IllegalStateException: A connection to a distributed system already
> exists in this VM. It has the following configuration:
> ack-severe-alert-threshold="0"
> ack-wait-threshold="15"
> archive-disk-space-limit="0"
> archive-file-size-limit="0"
> async-distribution-timeout="0"
> async-max-queue-size="8"
> async-queue-timeout="6"
> bind-address=""
> cache-xml-file="cache.xml"
> cluster-configuration-dir=""
> cluster-ssl-ciphers="any"
> cluster-ssl-enabled="false"
> cluster-ssl-keystore=""
> cluster-ssl-keystore-password=""
> cluster-ssl-keystore-type=""
> cluster-ssl-protocols="any"
> cluster-ssl-require-authentication="true"
> cluster-ssl-truststore=""
> cluster-ssl-truststore-password=""
> conflate-events="server"
> conserve-sockets="true"
> delta-propagation="true"
>
> deploy-working-dir="/home/geode/geode/geode-core/build/repeatIntegrationTest31"
> disable-auto-reconnect="false"
> disable-jmx="false"
> disable-tcp="false"
> distributed-system-id="-1"
> distributed-transactions="false"
> durable-client-id=""
> durable-client-timeout="300"
> enable-cluster-configuration="true"
> enable-network-partition-detection="true"
> enable-time-statistics="false" ***(wanted "true")***
> enforce-unique-host="false"
> gateway-ssl-ciphers="any"
> gateway-ssl-enabled="false"
> gateway-ssl-keystore=""
> gateway-ssl-keystore-password=""
> gateway-ssl-keystore-type=""
> gateway-ssl-protocols="any"
> gateway-ssl-require-authentication="true"
> gateway-ssl-truststore=""
> gateway-ssl-truststore-password=""
> groups=""
> http-service-bind-address=""
> http-service-port="7070"
> http-service-ssl-ciphers="any"
> http-service-ssl-enabled="false"
> http-service-ssl-keystore=""
> http-service-ssl-keystore-password=""
> http-service-ssl-keystore-type=""
> http-service-ssl-protocols="any"
> http-service-ssl-require-authentication="false"
> http-service-ssl-truststore=""
> http-service-ssl-truststore-password=""
> jmx-manager="false"
> jmx-manager-access-file=""
> jmx-manager-bind-address=""
> jmx-manager-hostname-for-clients=""
> jmx-manager-http-port="7070"
> jmx-manager-password-file=""
> jmx-manager-port="1099"
> jmx-manager-ssl-ciphers="any"
> jmx-manager-ssl-enabled="false"
> jmx-manager-ssl-keystore=""
> jmx-manager-ssl-keystore-password=""
> jmx-manager-ssl-keystore-type=""
> jmx-manager-ssl-protocols="any"
> jmx-manager-ssl-require-authentication="true"
> jmx-manager-ssl-truststore=""
> jmx-manager-ssl-truststore-password=""
> jmx-manager-start="false"
> jmx-manager-update-rate="2000"
> load-cluster-configuration-from-dir="false"
> locator-wait-time="0"
> locators=""
> lock-memory="false"
> log-disk-space-limit="0"
> log-file=""
> log-file-size-limit="0"
> log-level="config"
> max-num-reconnect-tries="3"
> max-wait-time-reconnect="6"
> mcast-address="/239.192.81.1"
> mcast-flow-control="1048576, 0.25, 5000"
> mcast-port="0"
> mcast-recv-buffer-size="1048576"
> mcast-send-buffer-size="65535"
> mcast-ttl="32"
> member-timeout="5000"
>
[jira] [Commented] (GEODE-6387) MemberLevelStatsJUnitTest fails in StressTest
[
https://issues.apache.org/jira/browse/GEODE-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869673#comment-16869673
]
ASF subversion and git services commented on GEODE-6387:
Commit 92e868670f664ffe5d7d7f03933aea7f1f10186a in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=92e8686 ]
GEODE-6387: Replace CachePerfStats.Clock with LongSupplier
Use LongSupplier to wrap NanoTimer.getTime and/or
DistributionStats.getStatsTime for constructor injection to improve
testability.
We have been using LongSupplier in the other stats classes, but I had
previously introduced a custom inner-class interface to CachePerfStats
that I decided to replace with LongSupplier and delete the inner-class.
> MemberLevelStatsJUnitTest fails in StressTest
> -
>
> Key: GEODE-6387
> URL: https://issues.apache.org/jira/browse/GEODE-6387
> Project: Geode
> Issue Type: Bug
> Components: statistics, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: StressTest, swat
> Time Spent: 1h
> Remaining Estimate: 0h
>
> MemberLevelStatsJUnitTest appears to fail consistently in StressTest. This
> test relies on IntegrationTest forking a new JVM for each test. Any PR that
> touches MemberLevelStatsJUnitTest will reproduce this ticket.
> Test failure example call stack:
> {noformat}
> java.lang.IllegalStateException: A connection to a distributed system already
> exists in this VM. It has the following configuration:
> ack-severe-alert-threshold="0"
> ack-wait-threshold="15"
> archive-disk-space-limit="0"
> archive-file-size-limit="0"
> async-distribution-timeout="0"
> async-max-queue-size="8"
> async-queue-timeout="6"
> bind-address=""
> cache-xml-file="cache.xml"
> cluster-configuration-dir=""
> cluster-ssl-ciphers="any"
> cluster-ssl-enabled="false"
> cluster-ssl-keystore=""
> cluster-ssl-keystore-password=""
> cluster-ssl-keystore-type=""
> cluster-ssl-protocols="any"
> cluster-ssl-require-authentication="true"
> cluster-ssl-truststore=""
> cluster-ssl-truststore-password=""
> conflate-events="server"
> conserve-sockets="true"
> delta-propagation="true"
>
> deploy-working-dir="/home/geode/geode/geode-core/build/repeatIntegrationTest31"
> disable-auto-reconnect="false"
> disable-jmx="false"
> disable-tcp="false"
> distributed-system-id="-1"
> distributed-transactions="false"
> durable-client-id=""
> durable-client-timeout="300"
> enable-cluster-configuration="true"
> enable-network-partition-detection="true"
> enable-time-statistics="false" ***(wanted "true")***
> enforce-unique-host="false"
> gateway-ssl-ciphers="any"
> gateway-ssl-enabled="false"
> gateway-ssl-keystore=""
> gateway-ssl-keystore-password=""
> gateway-ssl-keystore-type=""
> gateway-ssl-protocols="any"
> gateway-ssl-require-authentication="true"
> gateway-ssl-truststore=""
> gateway-ssl-truststore-password=""
> groups=""
> http-service-bind-address=""
> http-service-port="7070"
> http-service-ssl-ciphers="any"
> http-service-ssl-enabled="false"
> http-service-ssl-keystore=""
> http-service-ssl-keystore-password=""
> http-service-ssl-keystore-type=""
> http-service-ssl-protocols="any"
> http-service-ssl-require-authentication="false"
> http-service-ssl-truststore=""
> http-service-ssl-truststore-password=""
> jmx-manager="false"
> jmx-manager-access-file=""
> jmx-manager-bind-address=""
> jmx-manager-hostname-for-clients=""
> jmx-manager-http-port="7070"
> jmx-manager-password-file=""
> jmx-manager-port="1099"
> jmx-manager-ssl-ciphers="any"
> jmx-manager-ssl-enabled="false"
> jmx-manager-ssl-keystore=""
> jmx-manager-ssl-keystore-password=""
> jmx-manager-ssl-keystore-type=""
> jmx-manager-ssl-protocols="any"
> jmx-manager-ssl-require-authentication="true"
> jmx-manager-ssl-truststore=""
> jmx-manager-ssl-truststore-password=""
> jmx-manager-start="false"
> jmx-manager-update-rate="2000"
> load-cluster-configuration-from-dir="false"
> locator-wait-time="0"
> locators=""
> lock-memory="false"
> log-disk-space-limit="0"
> log-file=""
> log-file-size-limit="0"
> log-level="config"
> max-num-reconnect-tries="3"
> max-wait-time-reconnect="6"
> mcast-address="/239.192.81.1"
> mcast-flow-control="1048576, 0.25, 5000"
> mcast-port="0"
> mcast-recv-buffer-size="1048576"
> mcast-send-buffer-size="65535"
> mcast-ttl="32"
> member-timeout="5000"
> membership-port-range="[41000,61000]"
> memcached-bind-address=""
> memcached-port="0"
> memcached-protocol="ASCII"
> name=""
> off-heap-memory-size=""
> redis-bind-address=""
> redis-password=""
>
[jira] [Commented] (GEODE-6387) MemberLevelStatsJUnitTest fails in StressTest
[
https://issues.apache.org/jira/browse/GEODE-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869674#comment-16869674
]
ASF subversion and git services commented on GEODE-6387:
Commit b21b7ef89e3f447c3ff842f62fe42c4b47022894 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b21b7ef ]
GEODE-6387: Extract MemberLevelStatsTest
MemberLevelStatsIntegrationTest setUp creates a cache, but the majority
of the tests do not even use or require that cache. So, it's a good
idea to extract those to the new unit test MemberLevelStatsTest.
These changes further isolate the testing in MemberLevelStatsTest to
avoid any potential flakiness.
We also clean up MemberLevelStatsIntegrationTest to prevent potential
causes of flakiness, but ultimately GEODE-6387 is now fixed because
only one test remains so it should be impossible for another test to
leave around an incompatible distributed system.
> MemberLevelStatsJUnitTest fails in StressTest
> -
>
> Key: GEODE-6387
> URL: https://issues.apache.org/jira/browse/GEODE-6387
> Project: Geode
> Issue Type: Bug
> Components: statistics, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: StressTest, swat
> Time Spent: 1h
> Remaining Estimate: 0h
>
> MemberLevelStatsJUnitTest appears to fail consistently in StressTest. This
> test relies on IntegrationTest forking a new JVM for each test. Any PR that
> touches MemberLevelStatsJUnitTest will reproduce this ticket.
> Test failure example call stack:
> {noformat}
> java.lang.IllegalStateException: A connection to a distributed system already
> exists in this VM. It has the following configuration:
> ack-severe-alert-threshold="0"
> ack-wait-threshold="15"
> archive-disk-space-limit="0"
> archive-file-size-limit="0"
> async-distribution-timeout="0"
> async-max-queue-size="8"
> async-queue-timeout="6"
> bind-address=""
> cache-xml-file="cache.xml"
> cluster-configuration-dir=""
> cluster-ssl-ciphers="any"
> cluster-ssl-enabled="false"
> cluster-ssl-keystore=""
> cluster-ssl-keystore-password=""
> cluster-ssl-keystore-type=""
> cluster-ssl-protocols="any"
> cluster-ssl-require-authentication="true"
> cluster-ssl-truststore=""
> cluster-ssl-truststore-password=""
> conflate-events="server"
> conserve-sockets="true"
> delta-propagation="true"
>
> deploy-working-dir="/home/geode/geode/geode-core/build/repeatIntegrationTest31"
> disable-auto-reconnect="false"
> disable-jmx="false"
> disable-tcp="false"
> distributed-system-id="-1"
> distributed-transactions="false"
> durable-client-id=""
> durable-client-timeout="300"
> enable-cluster-configuration="true"
> enable-network-partition-detection="true"
> enable-time-statistics="false" ***(wanted "true")***
> enforce-unique-host="false"
> gateway-ssl-ciphers="any"
> gateway-ssl-enabled="false"
> gateway-ssl-keystore=""
> gateway-ssl-keystore-password=""
> gateway-ssl-keystore-type=""
> gateway-ssl-protocols="any"
> gateway-ssl-require-authentication="true"
> gateway-ssl-truststore=""
> gateway-ssl-truststore-password=""
> groups=""
> http-service-bind-address=""
> http-service-port="7070"
> http-service-ssl-ciphers="any"
> http-service-ssl-enabled="false"
> http-service-ssl-keystore=""
> http-service-ssl-keystore-password=""
> http-service-ssl-keystore-type=""
> http-service-ssl-protocols="any"
> http-service-ssl-require-authentication="false"
> http-service-ssl-truststore=""
> http-service-ssl-truststore-password=""
> jmx-manager="false"
> jmx-manager-access-file=""
> jmx-manager-bind-address=""
> jmx-manager-hostname-for-clients=""
> jmx-manager-http-port="7070"
> jmx-manager-password-file=""
> jmx-manager-port="1099"
> jmx-manager-ssl-ciphers="any"
> jmx-manager-ssl-enabled="false"
> jmx-manager-ssl-keystore=""
> jmx-manager-ssl-keystore-password=""
> jmx-manager-ssl-keystore-type=""
> jmx-manager-ssl-protocols="any"
> jmx-manager-ssl-require-authentication="true"
> jmx-manager-ssl-truststore=""
> jmx-manager-ssl-truststore-password=""
> jmx-manager-start="false"
> jmx-manager-update-rate="2000"
> load-cluster-configuration-from-dir="false"
> locator-wait-time="0"
> locators=""
> lock-memory="false"
> log-disk-space-limit="0"
> log-file=""
> log-file-size-limit="0"
> log-level="config"
> max-num-reconnect-tries="3"
> max-wait-time-reconnect="6"
> mcast-address="/239.192.81.1"
> mcast-flow-control="1048576, 0.25, 5000"
> mcast-port="0"
> mcast-recv-buffer-size="1048576"
> mcast-send-buffer-size="65535"
> mcast-ttl="32"
> member-timeout="5000"
>
[jira] [Commented] (GEODE-6772) create index sometimes will create the index but failed to update the cluster configuration.
[ https://issues.apache.org/jira/browse/GEODE-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869670#comment-16869670 ] Jinmei Liao commented on GEODE-6772: [~mivanac] when a region is created via cache.xml, you have to use --member option to specify which member has this region. With no --member option, gfsh assumes the region/index are managed by cluster configuration. > create index sometimes will create the index but failed to update the cluster > configuration. > > > Key: GEODE-6772 > URL: https://issues.apache.org/jira/browse/GEODE-6772 > Project: Geode > Issue Type: Bug > Components: gfsh, management >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Scenario: > 1. start a server (server-1) in group1: start server --name=server-1 > --group=group1 > 2. start another server-2 with no group: start server --name=server-2 > 3. create a regionA in group1: create region --name=regionA --group=group1 > --type=REPLICATE > 4. create an index on regionA: create index --region=regionA --name=index1 > > observe that command will try to create index on both servers, but failed on > server-2, since server-2 has no regionA, but the failure caused the cluster > configuration not being updated. > Proposal: > when create index, the region already should determine what members this > index needs to be created on, there should be no need for user to specify a > group. We should ignore "group" when cluster configuration is enabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6894) reconnect depends on the value of the reliableRegionsMissing CachePerfStat
[
https://issues.apache.org/jira/browse/GEODE-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869667#comment-16869667
]
Darrel Schneider commented on GEODE-6894:
-
Since RequiredRoles has been deprecated, it probably does not make sense to
spend time fixing this dependency on stats.
> reconnect depends on the value of the reliableRegionsMissing CachePerfStat
> --
>
> Key: GEODE-6894
> URL: https://issues.apache.org/jira/browse/GEODE-6894
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Darrel Schneider
>Priority: Major
>
> InternalDistributedSystem.reconnect(boolean, String) has the following code
> that reads a statistics:
> {code:java}
> if (cache.getCachePerfStats().getReliableRegionsMissing()
> == 0) {
> reconnectAttemptCounter.set(0);
> {code}
> This should be changed to read an internal value that is updated whenever the
> reliableRegionsMissing stat is updated. Otherwise reconnect will not behave
> as expected when stats are disabled.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6889) replyWaitMaxTime stat calculation code needs improvement
[
https://issues.apache.org/jira/browse/GEODE-6889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-6889.
-
Resolution: Fixed
Fix Version/s: 1.10.0
> replyWaitMaxTime stat calculation code needs improvement
>
>
> Key: GEODE-6889
> URL: https://issues.apache.org/jira/browse/GEODE-6889
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Darrel Schneider
>Assignee: Murtuza Boxwala
>Priority: Major
> Labels: performance
> Fix For: 1.10.0
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> The way the replyWaitMaxTime is calculated has some problems:
> 1. the elapsed time is calculated using System.currentTimeMillis but should
> instead use getStatTime (it actually uses getStatTime for the begin timestamp
> but not for the end timestamp).
> 2. a local atomic should be used to calculate it instead of reading the value
> from the Statistics instance. Reading is expensive since it uses
> synchronization.
> The following is a prototype fix for #2 I used when performance testing:
> {noformat}
> diff --git
> a/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
>
> b/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> index 91c47e2495..d591e35570 100644
> ---
> a/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> +++
> b/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> @@ -14,6 +14,8 @@
> */
> package org.apache.geode.distributed.internal;
>
> +import java.util.concurrent.atomic.AtomicLong;
> +
> import org.apache.logging.log4j.Logger;
>
> import org.apache.geode.StatisticDescriptor;
> @@ -1602,6 +1604,8 @@ public class DistributionStats implements DMStats {
> return getStatTime();
>}
>
> + private final AtomicLong replyWaitMaxTime = new AtomicLong();
> +
>@Override
>public void endReplyWait(long startNanos, long initTime) {
> if (enableClockStats) {
> @@ -1610,8 +1614,17 @@ public class DistributionStats implements DMStats {
> }
> if (initTime != 0) {
>long mswait = System.currentTimeMillis() - initTime;
> - if (mswait > getReplyWaitMaxTime()) {
> -stats.setLong(replyWaitMaxTimeId, mswait);
> + boolean done = false;
> + while (!done) {
> +long currentReplyWaitMaxTime = replyWaitMaxTime.get();
> +if (mswait > currentReplyWaitMaxTime) {
> + done = replyWaitMaxTime.compareAndSet(currentReplyWaitMaxTime,
> mswait);
> + if (done) {
> +stats.setLong(replyWaitMaxTimeId, mswait);
> + }
> +} else {
> + done = true;
> +}
>}
> }
> stats.incInt(replyWaitsInProgressId, -1);{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6890) sentMessagesMaxTime stat calculation needs improvement
[
https://issues.apache.org/jira/browse/GEODE-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-6890.
-
Resolution: Fixed
Fix Version/s: 1.10.0
> sentMessagesMaxTime stat calculation needs improvement
> --
>
> Key: GEODE-6890
> URL: https://issues.apache.org/jira/browse/GEODE-6890
> Project: Geode
> Issue Type: Improvement
> Components: statistics
>Reporter: Darrel Schneider
>Assignee: Murtuza Boxwala
>Priority: Major
> Fix For: 1.10.0
>
>
> The sentMessagesMaxTime stat is calculated by reading the old value. This
> read is an expensive synchronized operation.
> The following is a prototype fix that uses a local atomic:
> {noformat}
> diff --git
> a/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
>
> b/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> index d591e35570..0b5017b857 100644
> ---
> a/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> +++
> b/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> @@ -1035,6 +1035,8 @@ public class DistributionStats implements DMStats {
> return this.stats.getLong(sentMessagesTimeId);
>}
>
> + private final AtomicLong sentMessagesMaxTime = new AtomicLong();
> +
>/**
> * Increments the total number of nanoseconds spend sending messages.
> *
> @@ -1045,8 +1047,17 @@ public class DistributionStats implements DMStats {
> if (enableClockStats) {
>this.stats.incLong(sentMessagesTimeId, nanos);
>long millis = nanos / 100;
> - if (getSentMessagesMaxTime() < millis) {
> -this.stats.setLong(sentMessagesMaxTimeId, millis);
> + boolean done = false;
> + while (!done) {
> +long currentSentMessagesMaxTime = sentMessagesMaxTime.get();
> +if (millis > currentSentMessagesMaxTime) {
> + done =
> sentMessagesMaxTime.compareAndSet(currentSentMessagesMaxTime, millis);
> + if (done) {
> +stats.setLong(sentMessagesMaxTimeId, millis);
> + }
> +} else {
> + done = true;
> +}
>}
> }
>}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6890) sentMessagesMaxTime stat calculation needs improvement
[
https://issues.apache.org/jira/browse/GEODE-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869660#comment-16869660
]
ASF subversion and git services commented on GEODE-6890:
Commit 0b15a8119b7b42df3b69825f42b9e096556c91a0 in geode's branch
refs/heads/develop from Murtuza Boxwala
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0b15a81 ]
GEODE-6889, GEODE-6890: remove sync when updating max stats (#3728)
* GEODE-6889: Ensure the highest value is recorded to replyWaitMaxTime
* GEODE-6890: Ensure the highest value is recorded to maxSentMessagesTime
Co-authored-by: Murtuza Boxwala
> sentMessagesMaxTime stat calculation needs improvement
> --
>
> Key: GEODE-6890
> URL: https://issues.apache.org/jira/browse/GEODE-6890
> Project: Geode
> Issue Type: Improvement
> Components: statistics
>Reporter: Darrel Schneider
>Assignee: Murtuza Boxwala
>Priority: Major
>
> The sentMessagesMaxTime stat is calculated by reading the old value. This
> read is an expensive synchronized operation.
> The following is a prototype fix that uses a local atomic:
> {noformat}
> diff --git
> a/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
>
> b/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> index d591e35570..0b5017b857 100644
> ---
> a/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> +++
> b/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> @@ -1035,6 +1035,8 @@ public class DistributionStats implements DMStats {
> return this.stats.getLong(sentMessagesTimeId);
>}
>
> + private final AtomicLong sentMessagesMaxTime = new AtomicLong();
> +
>/**
> * Increments the total number of nanoseconds spend sending messages.
> *
> @@ -1045,8 +1047,17 @@ public class DistributionStats implements DMStats {
> if (enableClockStats) {
>this.stats.incLong(sentMessagesTimeId, nanos);
>long millis = nanos / 100;
> - if (getSentMessagesMaxTime() < millis) {
> -this.stats.setLong(sentMessagesMaxTimeId, millis);
> + boolean done = false;
> + while (!done) {
> +long currentSentMessagesMaxTime = sentMessagesMaxTime.get();
> +if (millis > currentSentMessagesMaxTime) {
> + done =
> sentMessagesMaxTime.compareAndSet(currentSentMessagesMaxTime, millis);
> + if (done) {
> +stats.setLong(sentMessagesMaxTimeId, millis);
> + }
> +} else {
> + done = true;
> +}
>}
> }
>}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6889) replyWaitMaxTime stat calculation code needs improvement
[
https://issues.apache.org/jira/browse/GEODE-6889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869659#comment-16869659
]
ASF subversion and git services commented on GEODE-6889:
Commit 0b15a8119b7b42df3b69825f42b9e096556c91a0 in geode's branch
refs/heads/develop from Murtuza Boxwala
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0b15a81 ]
GEODE-6889, GEODE-6890: remove sync when updating max stats (#3728)
* GEODE-6889: Ensure the highest value is recorded to replyWaitMaxTime
* GEODE-6890: Ensure the highest value is recorded to maxSentMessagesTime
Co-authored-by: Murtuza Boxwala
> replyWaitMaxTime stat calculation code needs improvement
>
>
> Key: GEODE-6889
> URL: https://issues.apache.org/jira/browse/GEODE-6889
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Darrel Schneider
>Assignee: Murtuza Boxwala
>Priority: Major
> Labels: performance
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> The way the replyWaitMaxTime is calculated has some problems:
> 1. the elapsed time is calculated using System.currentTimeMillis but should
> instead use getStatTime (it actually uses getStatTime for the begin timestamp
> but not for the end timestamp).
> 2. a local atomic should be used to calculate it instead of reading the value
> from the Statistics instance. Reading is expensive since it uses
> synchronization.
> The following is a prototype fix for #2 I used when performance testing:
> {noformat}
> diff --git
> a/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
>
> b/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> index 91c47e2495..d591e35570 100644
> ---
> a/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> +++
> b/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> @@ -14,6 +14,8 @@
> */
> package org.apache.geode.distributed.internal;
>
> +import java.util.concurrent.atomic.AtomicLong;
> +
> import org.apache.logging.log4j.Logger;
>
> import org.apache.geode.StatisticDescriptor;
> @@ -1602,6 +1604,8 @@ public class DistributionStats implements DMStats {
> return getStatTime();
>}
>
> + private final AtomicLong replyWaitMaxTime = new AtomicLong();
> +
>@Override
>public void endReplyWait(long startNanos, long initTime) {
> if (enableClockStats) {
> @@ -1610,8 +1614,17 @@ public class DistributionStats implements DMStats {
> }
> if (initTime != 0) {
>long mswait = System.currentTimeMillis() - initTime;
> - if (mswait > getReplyWaitMaxTime()) {
> -stats.setLong(replyWaitMaxTimeId, mswait);
> + boolean done = false;
> + while (!done) {
> +long currentReplyWaitMaxTime = replyWaitMaxTime.get();
> +if (mswait > currentReplyWaitMaxTime) {
> + done = replyWaitMaxTime.compareAndSet(currentReplyWaitMaxTime,
> mswait);
> + if (done) {
> +stats.setLong(replyWaitMaxTimeId, mswait);
> + }
> +} else {
> + done = true;
> +}
>}
> }
> stats.incInt(replyWaitsInProgressId, -1);{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6889) replyWaitMaxTime stat calculation code needs improvement
[
https://issues.apache.org/jira/browse/GEODE-6889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869661#comment-16869661
]
ASF subversion and git services commented on GEODE-6889:
Commit 0b15a8119b7b42df3b69825f42b9e096556c91a0 in geode's branch
refs/heads/develop from Murtuza Boxwala
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0b15a81 ]
GEODE-6889, GEODE-6890: remove sync when updating max stats (#3728)
* GEODE-6889: Ensure the highest value is recorded to replyWaitMaxTime
* GEODE-6890: Ensure the highest value is recorded to maxSentMessagesTime
Co-authored-by: Murtuza Boxwala
> replyWaitMaxTime stat calculation code needs improvement
>
>
> Key: GEODE-6889
> URL: https://issues.apache.org/jira/browse/GEODE-6889
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Darrel Schneider
>Assignee: Murtuza Boxwala
>Priority: Major
> Labels: performance
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> The way the replyWaitMaxTime is calculated has some problems:
> 1. the elapsed time is calculated using System.currentTimeMillis but should
> instead use getStatTime (it actually uses getStatTime for the begin timestamp
> but not for the end timestamp).
> 2. a local atomic should be used to calculate it instead of reading the value
> from the Statistics instance. Reading is expensive since it uses
> synchronization.
> The following is a prototype fix for #2 I used when performance testing:
> {noformat}
> diff --git
> a/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
>
> b/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> index 91c47e2495..d591e35570 100644
> ---
> a/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> +++
> b/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> @@ -14,6 +14,8 @@
> */
> package org.apache.geode.distributed.internal;
>
> +import java.util.concurrent.atomic.AtomicLong;
> +
> import org.apache.logging.log4j.Logger;
>
> import org.apache.geode.StatisticDescriptor;
> @@ -1602,6 +1604,8 @@ public class DistributionStats implements DMStats {
> return getStatTime();
>}
>
> + private final AtomicLong replyWaitMaxTime = new AtomicLong();
> +
>@Override
>public void endReplyWait(long startNanos, long initTime) {
> if (enableClockStats) {
> @@ -1610,8 +1614,17 @@ public class DistributionStats implements DMStats {
> }
> if (initTime != 0) {
>long mswait = System.currentTimeMillis() - initTime;
> - if (mswait > getReplyWaitMaxTime()) {
> -stats.setLong(replyWaitMaxTimeId, mswait);
> + boolean done = false;
> + while (!done) {
> +long currentReplyWaitMaxTime = replyWaitMaxTime.get();
> +if (mswait > currentReplyWaitMaxTime) {
> + done = replyWaitMaxTime.compareAndSet(currentReplyWaitMaxTime,
> mswait);
> + if (done) {
> +stats.setLong(replyWaitMaxTimeId, mswait);
> + }
> +} else {
> + done = true;
> +}
>}
> }
> stats.incInt(replyWaitsInProgressId, -1);{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6890) sentMessagesMaxTime stat calculation needs improvement
[
https://issues.apache.org/jira/browse/GEODE-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869662#comment-16869662
]
ASF subversion and git services commented on GEODE-6890:
Commit 0b15a8119b7b42df3b69825f42b9e096556c91a0 in geode's branch
refs/heads/develop from Murtuza Boxwala
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0b15a81 ]
GEODE-6889, GEODE-6890: remove sync when updating max stats (#3728)
* GEODE-6889: Ensure the highest value is recorded to replyWaitMaxTime
* GEODE-6890: Ensure the highest value is recorded to maxSentMessagesTime
Co-authored-by: Murtuza Boxwala
> sentMessagesMaxTime stat calculation needs improvement
> --
>
> Key: GEODE-6890
> URL: https://issues.apache.org/jira/browse/GEODE-6890
> Project: Geode
> Issue Type: Improvement
> Components: statistics
>Reporter: Darrel Schneider
>Assignee: Murtuza Boxwala
>Priority: Major
>
> The sentMessagesMaxTime stat is calculated by reading the old value. This
> read is an expensive synchronized operation.
> The following is a prototype fix that uses a local atomic:
> {noformat}
> diff --git
> a/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
>
> b/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> index d591e35570..0b5017b857 100644
> ---
> a/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> +++
> b/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionStats.java
> @@ -1035,6 +1035,8 @@ public class DistributionStats implements DMStats {
> return this.stats.getLong(sentMessagesTimeId);
>}
>
> + private final AtomicLong sentMessagesMaxTime = new AtomicLong();
> +
>/**
> * Increments the total number of nanoseconds spend sending messages.
> *
> @@ -1045,8 +1047,17 @@ public class DistributionStats implements DMStats {
> if (enableClockStats) {
>this.stats.incLong(sentMessagesTimeId, nanos);
>long millis = nanos / 100;
> - if (getSentMessagesMaxTime() < millis) {
> -this.stats.setLong(sentMessagesMaxTimeId, millis);
> + boolean done = false;
> + while (!done) {
> +long currentSentMessagesMaxTime = sentMessagesMaxTime.get();
> +if (millis > currentSentMessagesMaxTime) {
> + done =
> sentMessagesMaxTime.compareAndSet(currentSentMessagesMaxTime, millis);
> + if (done) {
> +stats.setLong(sentMessagesMaxTimeId, millis);
> + }
> +} else {
> + done = true;
> +}
>}
> }
>}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6762) BucketRegion ops do not always need to call createEventForPR
[ https://issues.apache.org/jira/browse/GEODE-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac reassigned GEODE-6762: --- Assignee: Mario Ivanac > BucketRegion ops do not always need to call createEventForPR > > > Key: GEODE-6762 > URL: https://issues.apache.org/jira/browse/GEODE-6762 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > > The BucketRegion class has multiple places in the after op event delivery > code that call createEventForPR and then ask that callbacks be invoked for > that event on the partitioned region. > But we will only have callbacks to invoke if we are a cache server that has > clients registered for events or the partitioned region has a cache listener, > We could prevent this optimization by doing some cheap checks to see if any > callbacks are possible before calling createEventForPR. > Some code that does this for BucketRegion put can be found here: > f7a824c62a57a5039b816a4a8b8b4d8c1c1fcb86 and here: > f568960235bda994bd7c6d0c575567ed2ccb10a5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GEODE-6869) decouple ClusterManagementService query and response types
[ https://issues.apache.org/jira/browse/GEODE-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols reopened GEODE-6869: - was not actually fixed > decouple ClusterManagementService query and response types > -- > > Key: GEODE-6869 > URL: https://issues.apache.org/jira/browse/GEODE-6869 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.10.0 > > Time Spent: 2h > Remaining Estimate: 0h > > currently CMS calls like `list(CacheElement)` return CacheElement (or > sometimes RuntimeCacheElement which uses inheritance+copy constructor rather > than composition to add additional stats alongside the static config info) > this has been "ok" so far, since most CMS calls focus on CRUD operations on > things in cache.xml which already extend CacheElement. However, it would be > cleaner to decouple the return type from the filter class, and not require > either one to extend CacheElement, to give us more flexibility to expose > things via CMS that aren't strictly elements of cache.xml > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6869) decouple ClusterManagementService query and response types
[ https://issues.apache.org/jira/browse/GEODE-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-6869. - Resolution: Won't Fix > decouple ClusterManagementService query and response types > -- > > Key: GEODE-6869 > URL: https://issues.apache.org/jira/browse/GEODE-6869 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.10.0 > > Time Spent: 2h > Remaining Estimate: 0h > > currently CMS calls like `list(CacheElement)` return CacheElement (or > sometimes RuntimeCacheElement which uses inheritance+copy constructor rather > than composition to add additional stats alongside the static config info) > this has been "ok" so far, since most CMS calls focus on CRUD operations on > things in cache.xml which already extend CacheElement. However, it would be > cleaner to decouple the return type from the filter class, and not require > either one to extend CacheElement, to give us more flexibility to expose > things via CMS that aren't strictly elements of cache.xml > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6887) Implement wrapper-style meters to route measurements to both meters and stats
[
https://issues.apache.org/jira/browse/GEODE-6887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869644#comment-16869644
]
ASF subversion and git services commented on GEODE-6887:
Commit cb8b36c03e80efbe81bc207770d0a21b4b57ca9d in geode's branch
refs/heads/develop from M. Oleske
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=cb8b36c ]
GEODE-6887: Stop routing wrapper meters to int stats (#3733)
Given that the int stat inc and get methods have been deprecated, remove
the ability to route legacy stat meters to int stats.
Co-authored-by: Michael Oleske
Co-authored-by: Dale Emery
> Implement wrapper-style meters to route measurements to both meters and stats
> -
>
> Key: GEODE-6887
> URL: https://issues.apache.org/jira/browse/GEODE-6887
> Project: Geode
> Issue Type: New Feature
>Reporter: Dale Emery
>Priority: Major
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Implement wrapper-style {{Counter}} and {{Timer}} meters that route
> measurements to both a registered meter and an associated stat (for counters)
> or stats (for timers, which track both the number of events and the total
> duration of the events). Use these wrapper-style meters whenever we want to
> route a given measurement to both meters and stats.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6772) create index sometimes will create the index but failed to update the cluster configuration.
[ https://issues.apache.org/jira/browse/GEODE-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-6772: -- Component/s: management > create index sometimes will create the index but failed to update the cluster > configuration. > > > Key: GEODE-6772 > URL: https://issues.apache.org/jira/browse/GEODE-6772 > Project: Geode > Issue Type: Bug > Components: gfsh, management >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Scenario: > 1. start a server (server-1) in group1: start server --name=server-1 > --group=group1 > 2. start another server-2 with no group: start server --name=server-2 > 3. create a regionA in group1: create region --name=regionA --group=group1 > --type=REPLICATE > 4. create an index on regionA: create index --region=regionA --name=index1 > > observe that command will try to create index on both servers, but failed on > server-2, since server-2 has no regionA, but the failure caused the cluster > configuration not being updated. > Proposal: > when create index, the region already should determine what members this > index needs to be created on, there should be no need for user to specify a > group. We should ignore "group" when cluster configuration is enabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6174) Create Region REST API
[ https://issues.apache.org/jira/browse/GEODE-6174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6174. --- Resolution: Fixed Fix Version/s: 1.10.0 > Create Region REST API > -- > > Key: GEODE-6174 > URL: https://issues.apache.org/jira/browse/GEODE-6174 > Project: Geode > Issue Type: New Feature > Components: docs, management >Reporter: Peter Tran >Priority: Major > Labels: pull-request-available > Fix For: 1.10.0 > > Time Spent: 8.5h > Remaining Estimate: 0h > > I want to be able to interact with the cluster without having to be on the > cluster in order to effect the configuration. Either as a developer, I want > to develop code in my IDE and as part of developing that code, I need to > create regions. Or as a data operator, I need to perform configurations on > the cluster and I want to interact with the cluster. > > As a Developer > I want to create a region in the cluster using the JAVA API on the cluster > when I am not located on the cluster (I do not need to be be on a node on the > cluster) > when I am authenticated and authorized for create region > So that a region is created on the cluster > So that I can put and get data in that region -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6182) auto completion on --member throws exception
[ https://issues.apache.org/jira/browse/GEODE-6182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6182. --- Fix Version/s: 1.10.0 > auto completion on --member throws exception > > > Key: GEODE-6182 > URL: https://issues.apache.org/jira/browse/GEODE-6182 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.7.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > gfsh>export data --parallel=true --region=/test > --dir=/var/vcap/store/gemfire-server --member > The HTTP request failed with: 500 - javax.management.RuntimeMBeanException: > java.lang.IllegalArgumentException: argument type mismatch > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:839) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrowMaybeMBeanException(DefaultMBeanServerInterceptor.java:852) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:821) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) > at > org.apache.geode.management.internal.security.MBeanServerWrapper.invoke(MBeanServerWrapper.java:221) > at > org.apache.geode.management.internal.web.controllers.ShellCommandsController.invoke(ShellCommandsController.java:151) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:205) > at > org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:133) > at > org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:97) > at > org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:827) > at > org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:738) > at > org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85) > at > org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:967) > at > org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:901) > at > org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970) > at > org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:872) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) > at > org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:860) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1650) > at > org.springframework.web.filter.HttpPutFormContentFilter.doFilterInternal(HttpPutFormContentFilter.java:109) > at > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:190) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564) > at >
[jira] [Resolved] (GEODE-6336) gfsh create region does not support multiple configurations for the same region name
[ https://issues.apache.org/jira/browse/GEODE-6336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6336. --- Resolution: Not A Problem > gfsh create region does not support multiple configurations for the same > region name > > > Key: GEODE-6336 > URL: https://issues.apache.org/jira/browse/GEODE-6336 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Darrel Schneider >Priority: Major > > gfsh create region has group support but it does not allow the same region > name to be created with different configurations in different groups. > Geode has support for different configurations for the same region name in > the same cluster. > For example you can have some members define a PartitionedRegion as an > accessor (it stores no data) and others that define it as a store (it > actually stores data for the region). > For replicas you can have some members be persistent, others non-persistent, > and others be empty proxies. > Cluster config does have group support so the way this was supposed to work > was that each group could define the region in its own way and would not fail > saying it was already created in another group. If a member decides to join > multiple groups then it is an error if the same name is defined in more than > one group. > As it is, you currently can not use gfsh to create regions in supported > configurations. You would need to disable cluster config and instead define > you regions with your own xml files or using apis each time. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6384) Create consistent API to retrieve CMS instance (Java API)
[ https://issues.apache.org/jira/browse/GEODE-6384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6384. --- Resolution: Fixed Fix Version/s: 1.10.0 > Create consistent API to retrieve CMS instance (Java API) > - > > Key: GEODE-6384 > URL: https://issues.apache.org/jira/browse/GEODE-6384 > Project: Geode > Issue Type: New Feature > Components: configuration >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.10.0 > > Time Spent: 4h > Remaining Estimate: 0h > > We want a developer to acquire a ClusterManagementService instance in their > Java application. We also know that we will need to enable Servers to also > obtain a ClusterManagementService instance. We should ensure that both these > mechanisms are the same so we don't have duplicate code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6429) Destroy Region only updates default Cluster Configuration
[ https://issues.apache.org/jira/browse/GEODE-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6429. --- Resolution: Cannot Reproduce > Destroy Region only updates default Cluster Configuration > - > > Key: GEODE-6429 > URL: https://issues.apache.org/jira/browse/GEODE-6429 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Benjamin P Ross >Priority: Major > > Destroy region doesn't appear to remove the region from group configs, just > from the default 'cluster' group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6523) Disable new REST and Java API behind feature flag
[ https://issues.apache.org/jira/browse/GEODE-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6523. --- Resolution: Fixed Fix Version/s: 1.10.0 > Disable new REST and Java API behind feature flag > - > > Key: GEODE-6523 > URL: https://issues.apache.org/jira/browse/GEODE-6523 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Peter Tran >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Discuss: Do we want our new functionality to be disabled by default until > such time as we are happy to make it publicly available? Other features - > e.g. protobuf currently do this. > If we do this, please use a feature-flag system property of the form: > `geode.feature-cluster-management-service` for consistency with other feature > flags. > * consider tests > * GFSH start option to switch it on > * Augment Experimental (don't turn off experimental with addition) > * What happens with Experimental later, leave it on until we are solid on the > External/public API. > * Feature flag = MVP adding value, Experimental = public API is solid > there is one flag to control this feature as Java Runtime properties "--J-D": > - enable-experimental-cluster-management-service: for features, which is > just an experimental, just want to get some feedback from early birds. > ### Why > We want users to not have access to Experimental API by default because it > could be in a state that is insecure/incomplete/could cause corruption of a > system. We need to turn this off by default so that users can opt into this > functionality. > ### Acceptance Criteria > ```gherkin > Scenario: System doesn't see this flag > Given geode is unpacked in a directory > When the system cannot find a flag of > 'enable-experimental-cluster-management-service' in Java Runtime properties. > Then the REST API v2 will not be available to the user on any port of the > locator > AND a info level log would be added to locator log: "CMS is turned off , > because value the experimental flag: > enable-experimental-cluster-management-service is false." > ``` > ```gherkin > Scenario: User default false for opt-in on experimental > Given the user does not change this flag > 'enable-experimental-cluster-management-service' and its default value. > When the user starts a locator > Then the REST API v2 will not be available to the user on any port of the > locator > AND a info level log would be added to locator log: "CMS is turned off , > because value the experimental flag: > enable-experimental-cluster-management-service is false." > ``` > ```gherkin > Scenario: User default incorrectly specified flag value > Given geode is unpacked in a directory > When the user specifies an incorrect value for this flag: > 'enable-experimental-cluster-management-service' by Java Runtime properties > "--J-D" > Then the REST API v2 will not be available to the user on any port of the > locator > AND a info level log would be added to locator log: "CMS is turned off , > because value the experimental flag: > enable-experimental-cluster-management-service is false." > ``` > ```gherkin > Scenario: User opts into the experimental flag > Given geode is unpacked in a directory > When the user enables this flag: > 'enable-experimental-cluster-management-service' by Java Runtime properties > "--J-D" > Then the REST API v2 will be available to the user at the standard port of > 7070 or whatever port the user has specified. > AND a info level log would be added to locator log: "CMS is turned on , > because value the experimental flag: > enable-experimental-cluster-management-service is true." > ``` > **Notes:** -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6629) Allow disk stores to be specified for region creation in V2 Management API
[ https://issues.apache.org/jira/browse/GEODE-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6629. --- Resolution: Fixed Fix Version/s: 1.10.0 > Allow disk stores to be specified for region creation in V2 Management API > -- > > Key: GEODE-6629 > URL: https://issues.apache.org/jira/browse/GEODE-6629 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6602) gfsh commands do not log successful/ unsuccessful messages in the log file
[ https://issues.apache.org/jira/browse/GEODE-6602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6602. --- Resolution: Fixed Fix Version/s: 1.10.0 > gfsh commands do not log successful/ unsuccessful messages in the log file > -- > > Key: GEODE-6602 > URL: https://issues.apache.org/jira/browse/GEODE-6602 > Project: Geode > Issue Type: Test > Components: gfsh >Reporter: Jens Deppe >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > In the past, Geode would log commands, being executed via gfsh, in the log > file. This was removed and should now be restored. > Any logging should also redact passwords and security info. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6608) Add Swagger UI to Management REST API
[ https://issues.apache.org/jira/browse/GEODE-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6608. --- Resolution: Fixed Fix Version/s: 1.10.0 > Add Swagger UI to Management REST API > - > > Key: GEODE-6608 > URL: https://issues.apache.org/jira/browse/GEODE-6608 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6574) Cluster Management Service should be able to query and list member details
[ https://issues.apache.org/jira/browse/GEODE-6574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6574. --- Resolution: Fixed Fix Version/s: 1.10.0 > Cluster Management Service should be able to query and list member details > -- > > Key: GEODE-6574 > URL: https://issues.apache.org/jira/browse/GEODE-6574 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jens Deppe >Assignee: Jinmei Liao >Priority: Major > Fix For: 1.10.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6634) Fix parallel option for repeatTest
[
https://issues.apache.org/jira/browse/GEODE-6634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-6634.
---
Resolution: Fixed
Fix Version/s: 1.10.0
> Fix parallel option for repeatTest
> --
>
> Key: GEODE-6634
> URL: https://issues.apache.org/jira/browse/GEODE-6634
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Currently both {{--parallel}} and {{--no-parallel}} options are being used
> for stress tests.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6779) Create disk-store command should only return when DistributedSystemMXBean reflects creation status
[
https://issues.apache.org/jira/browse/GEODE-6779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-6779.
---
Resolution: Fixed
Fix Version/s: 1.10.0
> Create disk-store command should only return when DistributedSystemMXBean
> reflects creation status
> --
>
> Key: GEODE-6779
> URL: https://issues.apache.org/jira/browse/GEODE-6779
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Once fixed, we can remove
> {{MemberVM.waitUntilDiskStoreIsReadyOnExactlyThisManyServers}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (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:all-tabpanel
]
Jens Deppe resolved GEODE-6765.
---
Resolution: Fixed
Fix Version/s: 1.10.0
> 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
> Fix For: 1.10.0
>
> 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] [Resolved] (GEODE-6679) Use ephemeral port locator in StandaloneClientManagementAPIAcceptanceTest
[ https://issues.apache.org/jira/browse/GEODE-6679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6679. --- Resolution: Fixed Fix Version/s: 1.10.0 > Use ephemeral port locator in StandaloneClientManagementAPIAcceptanceTest > - > > Key: GEODE-6679 > URL: https://issues.apache.org/jira/browse/GEODE-6679 > Project: Geode > Issue Type: Task > Components: management >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6643) Fix intermittent failure of GfshCommandIntegrationTest on Windows
[ https://issues.apache.org/jira/browse/GEODE-6643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6643. --- Resolution: Fixed Fix Version/s: 1.10.0 > Fix intermittent failure of GfshCommandIntegrationTest on Windows > - > > Key: GEODE-6643 > URL: https://issues.apache.org/jira/browse/GEODE-6643 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6678) Remove singleton cache reference from ClusterManagementServiceProvider
[
https://issues.apache.org/jira/browse/GEODE-6678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-6678.
---
Resolution: Fixed
Fix Version/s: 1.10.0
> Remove singleton cache reference from ClusterManagementServiceProvider
> --
>
> Key: GEODE-6678
> URL: https://issues.apache.org/jira/browse/GEODE-6678
> Project: Geode
> Issue Type: Task
> Components: management
>Reporter: Jens Deppe
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> This will probably mean adding a {{ClusterManagementServiceConfig}} interface
> which can be instantiated with locator, port, user, password and SSLContext.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6709) Locators should not start when ClusterConfigurationService is on but JMX Manager is off
[ https://issues.apache.org/jira/browse/GEODE-6709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6709. --- Resolution: Fixed > Locators should not start when ClusterConfigurationService is on but JMX > Manager is off > --- > > Key: GEODE-6709 > URL: https://issues.apache.org/jira/browse/GEODE-6709 > Project: Geode > Issue Type: Improvement > Components: docs, management >Reporter: Peter Tran >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > ClusterConfigurationService provides the ability for deployed jars to be > shared between members. When JMX Manager is off this is not possible. > Locators should not start with the misconfiguration of ClusterManagement on > and JMX Manager off. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6749) Prevent gfsh from creating duplicate named disk stores
[ https://issues.apache.org/jira/browse/GEODE-6749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6749. --- Resolution: Fixed Fix Version/s: 1.10.0 > Prevent gfsh from creating duplicate named disk stores > -- > > Key: GEODE-6749 > URL: https://issues.apache.org/jira/browse/GEODE-6749 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6728) Generify ClusterManagementService.list
[ https://issues.apache.org/jira/browse/GEODE-6728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6728. --- Resolution: Fixed Fix Version/s: 1.10.0 > Generify ClusterManagementService.list > -- > > Key: GEODE-6728 > URL: https://issues.apache.org/jira/browse/GEODE-6728 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Jens Deppe >Priority: Major > Fix For: 1.10.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > By introducing generics we will be able to unsure better type safety for > return values. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5896) Function sendResult can not finish correctly when client stop receive data
[
https://issues.apache.org/jira/browse/GEODE-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869576#comment-16869576
]
Juan José Ramos Cassella commented on GEODE-5896:
-
I have a {{DUnit}} test that reproduces the behaviour (attached to the ticket)
and, after looking through the source code, the function execution _*works like
this by design*_.
Whenever a member acts as the _coordinator_ for function execution on a
partitioned region, it basically creates a map of buckets to member, fires a
message to each member containing the buckets on which the function will
execute and waits to aggregate all responses to return to the client. If the
client "dies" in the middle of the execution the _coordinator_ will know and
stop all local threads related to that function execution *BUT* it has no way
(currently) of letting the remote members know about this, so the remote
members will continue to execute the function until it finishes.
> Function sendResult can not finish correctly when client stop receive data
> --
>
> Key: GEODE-5896
> URL: https://issues.apache.org/jira/browse/GEODE-5896
> Project: Geode
> Issue Type: Bug
> Components: functions
>Reporter: Dong Yang
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: SmallFeature
> Attachments:
> ClientServerFunctionExecutionWithCoordinatorDUnitTest.java
>
>
> Scenario:
> # TCP client-server mode
> # on Region with filter invocation
> # single-hop enabled at client-side
> # lots of data transfer from server to client
> # Using sendResult send data from server to client as streaming style
> Incident:
> Client program killed or exit normally. Server-side can not detect the
> exception so still sending data to client. Resources occupied sometimes a
> very long time and get more worse when client resent the request. As result,
> the cluster looks like hang in and can not response any request include api
> invocation, gfsh comand , etc.
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6744) Cluster Management service rest API should be able to list index
[ https://issues.apache.org/jira/browse/GEODE-6744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6744. --- Resolution: Fixed Fix Version/s: 1.10.0 > Cluster Management service rest API should be able to list index > > > Key: GEODE-6744 > URL: https://issues.apache.org/jira/browse/GEODE-6744 > Project: Geode > Issue Type: New Feature > Components: configuration >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Using the v2 CMS api, user should be able to list the existing index managed > by the current cluster configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5896) Function sendResult can not finish correctly when client stop receive data
[ https://issues.apache.org/jira/browse/GEODE-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José Ramos Cassella updated GEODE-5896: Attachment: ClientServerFunctionExecutionWithCoordinatorDUnitTest.java > Function sendResult can not finish correctly when client stop receive data > -- > > Key: GEODE-5896 > URL: https://issues.apache.org/jira/browse/GEODE-5896 > Project: Geode > Issue Type: Bug > Components: functions >Reporter: Dong Yang >Assignee: Juan José Ramos Cassella >Priority: Major > Labels: SmallFeature > Attachments: > ClientServerFunctionExecutionWithCoordinatorDUnitTest.java > > > Scenario: > # TCP client-server mode > # on Region with filter invocation > # single-hop enabled at client-side > # lots of data transfer from server to client > # Using sendResult send data from server to client as streaming style > Incident: > Client program killed or exit normally. Server-side can not detect the > exception so still sending data to client. Resources occupied sometimes a > very long time and get more worse when client resent the request. As result, > the cluster looks like hang in and can not response any request include api > invocation, gfsh comand , etc. > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6756) Allow key/value contraints to be specified for region creation in V2 Management API
[ https://issues.apache.org/jira/browse/GEODE-6756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6756. --- Resolution: Fixed Fix Version/s: 1.10.0 > Allow key/value contraints to be specified for region creation in V2 > Management API > --- > > Key: GEODE-6756 > URL: https://issues.apache.org/jira/browse/GEODE-6756 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jinmei Liao >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6784) CI failure: StandaloneClientManagementAPIAcceptanceTest.clientCreatesRegionUsingClusterManagementService
[ https://issues.apache.org/jira/browse/GEODE-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6784. --- Resolution: Fixed Fix Version/s: 1.10.0 > CI failure: > StandaloneClientManagementAPIAcceptanceTest.clientCreatesRegionUsingClusterManagementService > > > Key: GEODE-6784 > URL: https://issues.apache.org/jira/browse/GEODE-6784 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Owen Nichols >Priority: Major > Fix For: 1.10.0 > > > This test has been flaky on Windows, failing about once a week on average. > Here is a recent failure: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsAcceptanceTestOpenJDK11/builds/456] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > [http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0236/test-results/acceptanceTest/1556747062/] > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0236/test-artifacts/1556747062/windows-acceptancetestfiles-OpenJDK11-1.10.0-SNAPSHOT.0236.tgz] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6793) Mangement REST API should throw an error when request json has unrecognized attributes
[
https://issues.apache.org/jira/browse/GEODE-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-6793.
---
Resolution: Fixed
Fix Version/s: 1.10.0
> Mangement REST API should throw an error when request json has unrecognized
> attributes
> ---
>
> Key: GEODE-6793
> URL: https://issues.apache.org/jira/browse/GEODE-6793
> Project: Geode
> Issue Type: New Feature
> Components: management
>Reporter: Jinmei Liao
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For example, when doing something like this:
> [POST] /geode-management/v2/regions
> {
> "name": "Foo6_g1",
> "Type": "PERSISTENT_PARTITION",
> "group": "g1",
> "disk-store": "ds1",
> "enable-synchronous-disk": "false"
> }
> both disk-store and enable-synchronous-disk are invalid, however the command
> appears to succeed as the region is created, however no disk store is
> attached to it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6786) Provide ability to delete a region using V2 REST API
[ https://issues.apache.org/jira/browse/GEODE-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6786. --- Resolution: Fixed Fix Version/s: 1.10.0 > Provide ability to delete a region using V2 REST API > > > Key: GEODE-6786 > URL: https://issues.apache.org/jira/browse/GEODE-6786 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jens Deppe >Priority: Major > Fix For: 1.10.0 > > Time Spent: 2h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6796) Improve error message when gfsh connect fails
[ https://issues.apache.org/jira/browse/GEODE-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6796. --- Resolution: Fixed Fix Version/s: 1.10.0 > Improve error message when gfsh connect fails > - > > Key: GEODE-6796 > URL: https://issues.apache.org/jira/browse/GEODE-6796 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Peter Tran >Assignee: Jack Weissburg >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Currently when gfsh connect fails we see > [code] > gfsh -e "connect --locator=l192.168.99.1[52326]" > Connecting to Locator at [host=l192.168.99.1, port=52326] .. > l192.168.99.1: nodename nor servname provided, or not known > [/code] > The language "nor servname" can be more helpful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (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:all-tabpanel ] Jens Deppe resolved GEODE-6803. --- Resolution: Fixed Fix Version/s: 1.10.0 > 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 > Fix For: 1.10.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6829) AttributesFactory synchronization issues
[ https://issues.apache.org/jira/browse/GEODE-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6829. --- Resolution: Fixed > AttributesFactory synchronization issues > > > Key: GEODE-6829 > URL: https://issues.apache.org/jira/browse/GEODE-6829 > Project: Geode > Issue Type: Improvement > Components: core, management >Reporter: Joris Melchior >Priority: Minor > Fix For: 1.10.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > AttributesFactory has several synchronized blocks on method variables that in > effect mean there is no synchronization in those instances. > Improve the code to provide meaningful synchronization on attributes that are > manipulated by public and protected methods. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6824) CI Failure: BackupIntegrationTest
[
https://issues.apache.org/jira/browse/GEODE-6824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-6824.
---
Resolution: Fixed
Fix Version/s: 1.10.0
> CI Failure: BackupIntegrationTest
> --
>
> Key: GEODE-6824
> URL: https://issues.apache.org/jira/browse/GEODE-6824
> Project: Geode
> Issue Type: Test
> Components: persistence
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> On Windows 2016, this test fails with errors like this:
> {noformat}
> org.apache.geode.internal.cache.backup.BackupIntegrationTest >
> testIncrementalBackupAndRecover FAILED
> java.lang.AssertionError: Restore scripts [] expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.internal.cache.backup.BackupIntegrationTest.restoreBackup(BackupIntegrationTest.java:443)
> at
> org.apache.geode.internal.cache.backup.BackupIntegrationTest.testIncrementalBackupAndRecover(BackupIntegrationTest.java:235)
> {noformat}
> The logs contain more indicators of what's going wrong:
> {noformat}
> [warn 2019/05/31 10:08:47.953 GMT tid=0xf5] Unable to
> delete temporary directory created during backup,
> C:\Users\geode\AppData\Local\Temp\backup_15592973278755095066745076642151
> java.io.IOException: Unable to delete file:
> C:\Users\geode\AppData\Local\Temp\junit2122524286779777274\disk_Dir2\backupTemp_1559297327875\BACKUPdiskStore_2.crf
> at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2400)
> at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1721)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1617)
> at
> org.apache.geode.internal.cache.backup.TemporaryBackupFiles.deleteDirectory(TemporaryBackupFiles.java:133)
> at
> org.apache.geode.internal.cache.backup.TemporaryBackupFiles.cleanupFiles(TemporaryBackupFiles.java:126)
> at
> org.apache.geode.internal.cache.backup.BackupTask.cleanup(BackupTask.java:183)
> at
> org.apache.geode.internal.cache.backup.BackupTask.doBackup(BackupTask.java:125)
> at
> org.apache.geode.internal.cache.backup.BackupTask.backup(BackupTask.java:82)
> at
> org.apache.geode.internal.cache.backup.BackupService.lambda$prepareBackup$0(BackupService.java:62)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Way under the covers, during a backup, we create hard links from the original
> file to a backup file (if hard linking fails then there is a fallback to
> simply copy the file).
> My guess is that the semantics of hard links may have changed between Windows
> versions (which is why we're suddenly seeing this on Windows 2016).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6892) Default entryCount for newly created region to 0
[
https://issues.apache.org/jira/browse/GEODE-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-6892.
---
Resolution: Fixed
Fix Version/s: 1.10.0
> Default entryCount for newly created region to 0
>
>
> Key: GEODE-6892
> URL: https://issues.apache.org/jira/browse/GEODE-6892
> Project: Geode
> Issue Type: Bug
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Using the v2 API, if a newly created region is immediately listed, it may
> show the {{entryCount}} as {{-1}}. This is due MBeans being queried for this
> data and those beans may not be ready at the time of querying. This will be
> confusing to users.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6869) decouple ClusterManagementService query and response types
[ https://issues.apache.org/jira/browse/GEODE-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6869. --- Resolution: Fixed Fix Version/s: 1.10.0 > decouple ClusterManagementService query and response types > -- > > Key: GEODE-6869 > URL: https://issues.apache.org/jira/browse/GEODE-6869 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.10.0 > > Time Spent: 2h > Remaining Estimate: 0h > > currently CMS calls like `list(CacheElement)` return CacheElement (or > sometimes RuntimeCacheElement which uses inheritance+copy constructor rather > than composition to add additional stats alongside the static config info) > this has been "ok" so far, since most CMS calls focus on CRUD operations on > things in cache.xml which already extend CacheElement. However, it would be > cleaner to decouple the return type from the filter class, and not require > either one to extend CacheElement, to give us more flexibility to expose > things via CMS that aren't strictly elements of cache.xml > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6861) generify ClusterManagementService APIs
[ https://issues.apache.org/jira/browse/GEODE-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-6861. --- Resolution: Fixed Fix Version/s: 1.10.0 > generify ClusterManagementService APIs > -- > > Key: GEODE-6861 > URL: https://issues.apache.org/jira/browse/GEODE-6861 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.10.0 > > Time Spent: 6h 20m > Remaining Estimate: 0h > > currently CMS calls like `list(CacheElement)` return ` RuntimeCacheElement>` which then has to be cast to the appropriate actual > type. > if we create a link between the filter type and result type, then generics > can be used to give the correct actual return type in all cases, and we can > get rid of a ton of warnings and sketchy workarounds like passing `class` > parameters to methods that shouldn't need them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-751) RegionMXBean shouldn't rely on Eviction Algorithm for getEntrySize
[
https://issues.apache.org/jira/browse/GEODE-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Bustamante Reyes updated GEODE-751:
---
Description:
We have the following in the javadoc for method {{getEntrySize}} on interface
{{RegionMXBean}}:
{quote}
Returns the aggregate entry size (in bytes) of all entries. This will provide a
correct value only if the eviction algorithm has been set to
{{EvictionAlgorithm.LRU_MEMORY}}. For all partition regions it will show entry
size in bytes. It will also include size of all the secondary entries in the
data store. So while referring to size one should take redundancy into account.
{quote}
The region memory consumption and the eviction algorithm are two separate
concepts, we should not obligate customers to use a custom eviction algorithm
to report the correct memory consumption for a region.
We rely on this attribute to show information on PULSE, so neither the member
memory usage nor cluster memory usage are accurate if the eviction algorithm is
not configured as {{EvictionAlgorithm.LRU_MEMORY}}.
To reproduce, start up a cluster with a simple replicated region and insert
some data. You can check afterwards (from JConsole) that the attribute
"EntrySize" for the replicated region is set as "-1".
was:
We have the following in the javadoc for method {{getEntrySize}} on interface
{{RegionMXBean}}:
{quote}
Returns the aggregate entry size (in bytes) of all entries. This will provide a
correct value only if the eviction algorithm has been set to
{{EvictionAlgorithm.LRU_MEMORY}}. For all partition regions it will show entry
size in bytes. It will also include size of all the secondary entries in the
data store. So while referring to size one should take redundancy into account.
{quote}
The region memory consumption and the eviction algorithm are two separate
concepts, we should not obligate customers to use a custom eviction algorithm
to report the correct memory consumption for a region.
We rely on this attribute to show information on PULSE, so neither the member
memory usage nor cluster memory usage are accurate if the eviction algorithm is
not configured as {{EvictionAlgorithm.LRU_MEMORY}}.
To reproduce, start up a cluster with a simple replicated region and insert
some data. You can check afterwards (from JConsole) that the attribute
"EntrySize" for the replicated region is set as "-1".
We rely on this attribute to show information on PULSE, so neither the member
memory usage nor cluster memory usage are accurate if the eviction algorithm is
not configured as {{EvictionAlgorithm.LRU_MEMORY}}.
> RegionMXBean shouldn't rely on Eviction Algorithm for getEntrySize
> --
>
> Key: GEODE-751
> URL: https://issues.apache.org/jira/browse/GEODE-751
> Project: Geode
> Issue Type: Improvement
> Components: jmx, statistics
>Affects Versions: 1.0.0-incubating
>Reporter: Jens Deppe
>Priority: Major
>
> We have the following in the javadoc for method {{getEntrySize}} on interface
> {{RegionMXBean}}:
> {quote}
> Returns the aggregate entry size (in bytes) of all entries. This will provide
> a correct value only if the eviction algorithm has been set to
> {{EvictionAlgorithm.LRU_MEMORY}}. For all partition regions it will show
> entry size in bytes. It will also include size of all the secondary entries
> in the data store. So while referring to size one should take redundancy into
> account.
> {quote}
> The region memory consumption and the eviction algorithm are two separate
> concepts, we should not obligate customers to use a custom eviction algorithm
> to report the correct memory consumption for a region.
> We rely on this attribute to show information on PULSE, so neither the member
> memory usage nor cluster memory usage are accurate if the eviction algorithm
> is not configured as {{EvictionAlgorithm.LRU_MEMORY}}.
> To reproduce, start up a cluster with a simple replicated region and insert
> some data. You can check afterwards (from JConsole) that the attribute
> "EntrySize" for the replicated region is set as "-1".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6885) desribe config shows ssl keystore and truststore password in plaintext
[ https://issues.apache.org/jira/browse/GEODE-6885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869430#comment-16869430 ] Ashish Choudhary commented on GEODE-6885: - behavior seems to be same in latest geode 1.9 version also > desribe config shows ssl keystore and truststore password in plaintext > -- > > Key: GEODE-6885 > URL: https://issues.apache.org/jira/browse/GEODE-6885 > Project: Geode > Issue Type: Bug > Components: security >Reporter: Ashish Choudhary >Priority: Major > > when you run describe config --member=memberName with ssl enabled on cluster > then it shows > ssl keystore and truststore password in plaintext. Is it acceptable or it's > being fixed in newer versions as with geode 1.2 version we see similar > behaviour that shows secrets in plain text?. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
