[jira] [Commented] (GEODE-6070) CI Failure: ShutdownCommandOverHttpDUnitTest > testShutdownAll
[
https://issues.apache.org/jira/browse/GEODE-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867144#comment-16867144
]
Aaron Lindsey commented on GEODE-6070:
--
Failed here:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsGfshDistributedTestOpenJDK8/builds/589]
> CI Failure: ShutdownCommandOverHttpDUnitTest > testShutdownAll
> --
>
> Key: GEODE-6070
> URL: https://issues.apache.org/jira/browse/GEODE-6070
> Project: Geode
> Issue Type: Bug
>Reporter: Helena Bales
>Assignee: Patrick Rhomberg
>Priority: Major
>
> Failed with stacktrace:
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShutdownCommandOverHttpDUnitTest
> > testShutdownAll 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 302
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on 172.17.0.3(server-1:496):41002 started at Thu Nov
> 15 19:47:58 UTC 2018: Message distribution has terminated
> {noformat}
> Test results can be found here:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.158/test-results/distributedTest/1542315851/classes/org.apache.geode.management.internal.cli.commands.ShutdownCommandOverHttpDUnitTest.html#testShutdownAll
>
> Test Artifacts can be found here:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.158/test-artifacts/1542315851/distributedtestfiles-OpenJDK8-1.9.0-build.158.tgz
--
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=16867141#comment-16867141 ] Aaron Lindsey commented on GEODE-6888: -- Notes on this failure: * I ran this test locally, and I saw the suspect string "java.net.ConnectException: Connection refused (Connection refused)" in the logs. * However, it was a WARN level log message, and those should be skipped according to LogConsumer.skipLevelPattern. * Looking at the logs in std out for this failure, all of the suspect strings are found in WARN level log messages. * Therefore, I am surprised this resulted in a failure since WARN level messages are supposed to be ignored. > 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 >Priority: Major > > 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]
[jira] [Assigned] (GEODE-6884) Execution.withFilter() and friends introduce type parameters inconsistent with class' type parameters
[
https://issues.apache.org/jira/browse/GEODE-6884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham reassigned GEODE-6884:
---
Assignee: Jens Deppe
> Execution.withFilter() and friends introduce type parameters inconsistent
> with class' type parameters
> -
>
> Key: GEODE-6884
> URL: https://issues.apache.org/jira/browse/GEODE-6884
> Project: Geode
> Issue Type: Bug
>Reporter: Bill Burcham
>Assignee: Jens Deppe
>Priority: Major
>
> A recent change to {{Execution}} changed {{withFilter()}} and friends so they
> introduce their own type parameters:
> {code:java}
>Execution AggregatorT> withFilter(
> Set filter);
> {code}
> This eliminates a compile error over in {{FunctionRetryTestBase}} where
> chaining was happening:
> {code:java}
> final Execution> execution;
> switch (executionTarget) {
> case REGION:
> execution =
>
> FunctionService.onRegion(clusterStartupRule.getClientCache().getRegion(regionName))
> .setArguments(200);
> {code}
> Unfortunately though, this change introduces a "hole" in the typing so that
> the client (of {{Execution}}) is able to produce instances parameterized on
> arbitrary types. The compiler is happy with just about anything, but runtime
> exceptions ({{ClassCastException}}) will ensue.
> Here is an example of code that compiles
> [https://gist.github.com/Bill/5e2ad2ba4b60461dd0af8adfa4adc91b:]
> {code:java}
> final Execution execution =
> FunctionService.onRegion(null);
>
> //Add a string argument, which appears to be typesafe
> final Execution addedArgument =
> execution.setArguments("hello");
> //But wait! If we call withFilter, we get to change the type of Execution
> with no warning
> //or casts. We won't see the class cast exceptions until runtime.
> final Execution execution1 =
> execution.withFilter(Collections.singleton(5));
> {code}
>
> A hint at the problem is that IntelliJ inspections highlights the new type
> parameters on e.g. the {{withFilter()}} method indicating that the type
> parameters on the method are hiding the type parameters on the class. This is
> an indication that even though the names are the same—the type parameters to
> the method are completely different from the ones on the class. There is no
> enforced correspondence. The compiler gives you complete freedom here.
>
> !image-2019-06-17-16-11-39-678.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6891) ClusterDistributionManager.SerialQueuedExecutorPool.getThrottledSerialExecutor has some problems
Darrel Schneider created GEODE-6891: --- Summary: ClusterDistributionManager.SerialQueuedExecutorPool.getThrottledSerialExecutor has some problems Key: GEODE-6891 URL: https://issues.apache.org/jira/browse/GEODE-6891 Project: Geode Issue Type: Bug Components: messaging Reporter: Darrel Schneider The getThrottledSerialExecutor has the following issues: 1. It reads that stat: DistributionStats.getSerialQueueBytes(). If stats are disabled then the throttling would be disabled. Someone needs to maintain this value in a local atomic. 2. It reads the stat in three different places. One of those is outside the loop but that seems wrong. Each time it is used inside the loop to calculate how long to sleep it should be using the current value. 3. It is compared against two different constants. To get in the loop it must be greater than TOTAL_SERIAL_QUEUE_THROTTLE. To exit the loop it must be >= to TOTAL_SERIAL_QUEUE_BYTE_LIMIT. This seems wrong but it might be correct. 4. The constant TOTAL_SERIAL_QUEUE_THROTTLE is calculated from SERIAL_QUEUE_BYTE_LIMIT. This looks like a copy and past mistake. I think it should be TOTAL_SERIAL_QUEUE_BYTE_LIMIT 5. It looks like the intent of this code is to block message senders if we currently have more than TOTAL_SERIAL_QUEUE_BYTE_LIMIT message bytes queued up for sending. But the whole sleep calculation is scary. If we want this throttling then it seems like instead of sleeping we should wait until we see the value go below a threshold. We can make this event driven since it is our code that will decrement the value as messages are removed from the queue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4263) CI Failure: ResourceManagerWithQueryMonitorDUnitTest. testRMAndTimeoutSet
[
https://issues.apache.org/jira/browse/GEODE-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867133#comment-16867133
]
Aaron Lindsey commented on GEODE-4263:
--
Failed here:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/815]
{quote}{{org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest
> testRMButDisabledQueryMonitorForLowMemAndNoTimeoutSet FAILED}}
{{java.lang.AssertionError: queryExecution.getResult() threw Exception
java.lang.AssertionError: An exception occurred during asynchronous
invocation.}}
{{at org.junit.Assert.fail(Assert.java:88)}}
{{at
org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest.doTestCriticalHeapAndQueryTimeout(ResourceManagerWithQueryMonitorDUnitTest.java:848)}}
{{at
org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest.doCriticalMemoryHitTest(ResourceManagerWithQueryMonitorDUnitTest.java:358)}}
{{at
org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest.testRMButDisabledQueryMonitorForLowMemAndNoTimeoutSet(ResourceManagerWithQueryMonitorDUnitTest.java:165)}}
{{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 1604}}
{{[fatal 2019/06/18 22:20:07.696 GMT tid=1559] Server connection from
[identity(172.17.0.12(155:loner):54608:61ceac6c,connection=1; port=54612] :
Unexpected Error on server}}
{{java.lang.AssertionError: query was never unlatched}}
{{ at org.junit.Assert.fail(Assert.java:88)}}
{{ at
org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest$PauseTestHook.doTestHook(ResourceManagerWithQueryMonitorDUnitTest.java:1306)}}
{{ at
org.apache.geode.cache.query.internal.DefaultQuery.executeUsingContext(DefaultQuery.java:428)}}
{{ at
org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:265)}}
{{ at
org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:197)}}
{{ at
org.apache.geode.internal.cache.tier.sockets.BaseCommandQuery.processQueryUsingParams(BaseCommandQuery.java:122)}}
{{ at
org.apache.geode.internal.cache.tier.sockets.BaseCommandQuery.processQuery(BaseCommandQuery.java:68)}}
{{ at
org.apache.geode.internal.cache.tier.sockets.command.Query.cmdExecute(Query.java:94)}}
{{ at
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)}}
{{ at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:847)}}
{{ at
org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)}}
{{ at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1211)}}
{{ at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
{{ at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
{{ at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:665)}}
{{ at
org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)}}
{{ at java.base/java.lang.Thread.run(Thread.java:834)}}
{quote}
> CI Failure: ResourceManagerWithQueryMonitorDUnitTest. testRMAndTimeoutSet
> -
>
> Key: GEODE-4263
> URL: https://issues.apache.org/jira/browse/GEODE-4263
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: nabarun
>Priority: Major
>
> {noformat}
> java.lang.AssertionError: queryExecution.getResult() threw Exception
> java.lang.AssertionError: An exception occurred during asynchronous
> invocation.
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest.doTestCriticalHeapAndQueryTimeout(ResourceManagerWithQueryMonitorDUnitTest.java:738)
> at
> org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest.doCriticalMemoryHitTest(ResourceManagerWithQueryMonitorDUnitTest.java:321)
> at
> org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest.testRMAndTimeoutSet(ResourceManagerWithQueryMonitorDUnitTest.java:157)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Commented] (GEODE-6805) MacOS home shorthand ~ is not support for `--jar` path in gfsh
[ https://issues.apache.org/jira/browse/GEODE-6805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867131#comment-16867131 ] Maria Shtutman commented on GEODE-6805: --- It relates not only to MacOS, but any unix environment. > MacOS home shorthand ~ is not support for `--jar` path in gfsh > -- > > Key: GEODE-6805 > URL: https://issues.apache.org/jira/browse/GEODE-6805 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Ryan McMahon >Priority: Major > Labels: gfsh, management, starter > > On MacOS, which is a supported development platform, it would be nice if the > path given for the `–jar` argument supported the MacOS shorthand `~`, rather > than needing to type /Users/user/. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6822) Deploying a jar causes a new class loader to be created, causing possible mismatch
[ https://issues.apache.org/jira/browse/GEODE-6822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867115#comment-16867115 ] ASF subversion and git services commented on GEODE-6822: Commit 628b8ddd3c0ef0a5267eb64790d7871ed1ec4d34 in geode's branch refs/heads/develop from Jason Huynh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=628b8dd ] GEODE-6822: removed test duplication (#3725) * tests were having difficulty with existing rules and been fixed by moving to their own class * removing tests that should have originally been removed > Deploying a jar causes a new class loader to be created, causing possible > mismatch > -- > > Key: GEODE-6822 > URL: https://issues.apache.org/jira/browse/GEODE-6822 > Project: Geode > Issue Type: Bug >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h > Remaining Estimate: 0h > > When a jar is deployed, a new class loader is created. Deserialized objects > in the system will no longer match because the objects classes are from > different loaders. This is true even if the newly deployed jar is unrelated > to the deserialized objects This can be problematic if we have non primitive > region keys. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6861) generify ClusterManagementService APIs
[ https://issues.apache.org/jira/browse/GEODE-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867092#comment-16867092 ] ASF subversion and git services commented on GEODE-6861: Commit a60ade270e3dc1901fe900e2521351bdc93ecced in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a60ade2 ] GEODE-6861: Generify ClusterManagementService (#3708) * GEODE-6861: Generify ClusterManagementService > 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 > 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] [Commented] (GEODE-6861) generify ClusterManagementService APIs
[ https://issues.apache.org/jira/browse/GEODE-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867091#comment-16867091 ] ASF subversion and git services commented on GEODE-6861: Commit a60ade270e3dc1901fe900e2521351bdc93ecced in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a60ade2 ] GEODE-6861: Generify ClusterManagementService (#3708) * GEODE-6861: Generify ClusterManagementService > 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 > 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-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 updated GEODE-6890:
Description:
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}
was:
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 = replyWaitMaxTime.compareAndSet(currentSentMessagesMaxTime,
millis);
+ if (done) {
+stats.setLong(sentMessagesMaxTimeId, millis);
+ }
+} else {
+ done = true;
+}
}
}
}
{noformat}
> 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: Darrel Schneider
>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) {
>
[jira] [Created] (GEODE-6890) sentMessagesMaxTime stat calculation needs improvement
Darrel Schneider created GEODE-6890:
---
Summary: 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
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 = replyWaitMaxTime.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-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 reassigned GEODE-6890:
---
Assignee: Darrel Schneider
> 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: Darrel Schneider
>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 = replyWaitMaxTime.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-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 reassigned GEODE-6889:
---
Assignee: Darrel Schneider
> 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: Darrel Schneider
>Priority: Major
> Labels: performance
>
> 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] [Created] (GEODE-6889) replyWaitMaxTime stat calculation code needs improvement
Darrel Schneider created GEODE-6889:
---
Summary: 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
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] [Updated] (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 updated GEODE-6889:
Labels: performance (was: )
> 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
>Priority: Major
> Labels: performance
>
> 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] [Updated] (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 ] Anilkumar Gingade updated GEODE-6888: - Description: 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] cluster-ssl-keystore-type= [vm2] cluster-ssl-protocols=any [vm2] cluster-ssl-require-authentication=true [vm2] cluster-ssl-truststore= [vm2] cluster-ssl-truststore-password= [vm2] conflate-events=server [vm2] conserve-sockets=true [vm2] delta-propagation=true [vm2] deploy-working-dir=/home/geode/geode/geode-core/build/distributedTest933/dunit/vm2 [vm2] disable-jmx=false [vm2] disable-tcp=false [vm2] distributed-system-id=-1 [vm2] distributed-transactions=false [vm2] durable-client-id= [vm2] durable-client-timeout=300 [vm2] enable-network-partition-detection=true [vm2] enable-time-statistics=false [vm2] enforce-unique-host=false [vm2] gateway-ssl-ciphers=any [vm2]
[jira] [Updated] (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
]
Anilkumar Gingade updated GEODE-6888:
-
Description:
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:
{noformat}
[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]
cluster-ssl-keystore-type= [vm2] cluster-ssl-protocols=any [vm2]
cluster-ssl-require-authentication=true [vm2] cluster-ssl-truststore= [vm2]
cluster-ssl-truststore-password= [vm2] conflate-events=server [vm2]
conserve-sockets=true [vm2] delta-propagation=true [vm2]
deploy-working-dir=/home/geode/geode/geode-core/build/distributedTest933/dunit/vm2
[vm2] disable-jmx=false [vm2] disable-tcp=false [vm2] distributed-system-id=-1
[vm2] distributed-transactions=false [vm2] durable-client-id= [vm2]
durable-client-timeout=300 [vm2] enable-network-partition-detection=true [vm2]
enable-time-statistics=false [vm2] enforce-unique-host=false [vm2]
gateway-ssl-ciphers=any
[jira] [Created] (GEODE-6888) CI failure: HAGIIDUnitTest.testGIIRegionQueue Suspect string in the log
Anilkumar Gingade created GEODE-6888: Summary: 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 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] cluster-ssl-keystore-type= [vm2] cluster-ssl-protocols=any [vm2] cluster-ssl-require-authentication=true [vm2] cluster-ssl-truststore= [vm2] cluster-ssl-truststore-password= [vm2] conflate-events=server [vm2] conserve-sockets=true [vm2] delta-propagation=true [vm2] deploy-working-dir=/home/geode/geode/geode-core/build/distributedTest933/dunit/vm2 [vm2] disable-jmx=false [vm2] disable-tcp=false [vm2] distributed-system-id=-1 [vm2] distributed-transactions=false [vm2] durable-client-id= [vm2]
[jira] [Commented] (GEODE-6833) p2p SSL connections always require clients to authenticate
[
https://issues.apache.org/jira/browse/GEODE-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867047#comment-16867047
]
ASF subversion and git services commented on GEODE-6833:
Commit b347bca908205f81881534c1b5ae418f0bafd170 in geode's branch
refs/heads/develop from Ernie Burghardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b347bca ]
GEODE-6833: Updating P2P SSL auth (#3699)
* Adding new test and test cert files.
* Connection uses the more proper way of setNeedClientAuth
> p2p SSL connections always require clients to authenticate
> --
>
> Key: GEODE-6833
> URL: https://issues.apache.org/jira/browse/GEODE-6833
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Bruce Schuchardt
>Priority: Major
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> The SSL over NIO code is configuring the SSL engine to always require a
> connection to do two-way authentication. Connection.createIoFilter() is
> currently doing this:
> {code:java}
> if (!clientSocket) {
> engine.setWantClientAuth(true);
> engine.setNeedClientAuth(true);
> }
> {code}
> but needs to do this instead:
> {code:java}
> if (!clientSocket) {
>
> engine.setNeedClientAuth(SSLConfigurationFactory.getSSLConfigForComponent(getConduit().config,
> SecurableCommunicationChannel.CLUSTER).isRequireAuth());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6822) Deploying a jar causes a new class loader to be created, causing possible mismatch
[ https://issues.apache.org/jira/browse/GEODE-6822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh resolved GEODE-6822. Resolution: Fixed Fix Version/s: 1.10.0 > Deploying a jar causes a new class loader to be created, causing possible > mismatch > -- > > Key: GEODE-6822 > URL: https://issues.apache.org/jira/browse/GEODE-6822 > Project: Geode > Issue Type: Bug >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Fix For: 1.10.0 > > Time Spent: 40m > Remaining Estimate: 0h > > When a jar is deployed, a new class loader is created. Deserialized objects > in the system will no longer match because the objects classes are from > different loaders. This is true even if the newly deployed jar is unrelated > to the deserialized objects This can be problematic if we have non primitive > region keys. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6822) Deploying a jar causes a new class loader to be created, causing possible mismatch
[ https://issues.apache.org/jira/browse/GEODE-6822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867035#comment-16867035 ] ASF subversion and git services commented on GEODE-6822: Commit a51015ac467336c0731c010f8918e4c6364e4d26 in geode's branch refs/heads/develop from Jason Huynh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a51015a ] GEODE-6822: Deploying jars only creates new classloader for the newly deployed jar (#3537) * Deserialized objects of classes unrelated to the latest deployed jar should now compare correctly after an unrelated new jar is deployed * This solution causes each deployed jar to create it's own class loader and chains them together. * The class loaders are now child first class loaders and If a class cannot be found, it will search all 'sibling'/other deployed jars * When a jar is redeployed (new version), we keep some meta data in a map so we no longer crawl the 'old' jar when possible and only search through the latest version of a specific jar. * Java does some caching of classes and in the undeploy scenario, we may still be able to load classes that have been "removed" from the new jar (only if it was already cached by some other class loader). This can happen when we have inter jar dependencies. * Geode also caches classes, so whenever a redeploy occurs, the geode class cache gets wiped, and first lookups take a minor performance hit, but subsequent lookups go through geodes caching of the classes (so the for name and class lookups through chaining should have a minimal impact) > Deploying a jar causes a new class loader to be created, causing possible > mismatch > -- > > Key: GEODE-6822 > URL: https://issues.apache.org/jira/browse/GEODE-6822 > Project: Geode > Issue Type: Bug >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > When a jar is deployed, a new class loader is created. Deserialized objects > in the system will no longer match because the objects classes are from > different loaders. This is true even if the newly deployed jar is unrelated > to the deserialized objects This can be problematic if we have non primitive > region keys. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-2878) If an exception occurs after retrieving an XAConnection from the ConnectionProvider but before returning it to the application, the GemFireTransactionDataSource doesn't
[
https://issues.apache.org/jira/browse/GEODE-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivanac resolved GEODE-2878.
-
Resolution: Fixed
Fix Version/s: 1.10.0
> If an exception occurs after retrieving an XAConnection from the
> ConnectionProvider but before returning it to the application, the
> GemFireTransactionDataSource doesn't return it to the pool
> --
>
> Key: GEODE-2878
> URL: https://issues.apache.org/jira/browse/GEODE-2878
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Barry Oglesby
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, pull-request-available, storage_3
> Fix For: 1.10.0
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> In my test, I have 5 threads inserting rows into a derby database.
> At first, as connections are being used and returned, the
> {{activeConnections}} is updated correctly:
> {noformat}
> Thread-16: AbstractPoolCache.getPooledConnectionFromPool activeConnections=1
> Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=2
> Thread-17: AbstractPoolCache.getPooledConnectionFromPool activeConnections=3
> Thread-14: AbstractPoolCache.getPooledConnectionFromPool activeConnections=4
> Thread-18: AbstractPoolCache.getPooledConnectionFromPool activeConnections=5
> Thread-16: AbstractPoolCache.returnPooledConnectionToPool activeConnections=4
> Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=3
> Thread-18: AbstractPoolCache.returnPooledConnectionToPool activeConnections=2
> Thread-17: AbstractPoolCache.returnPooledConnectionToPool activeConnections=1
> Thread-15: AbstractPoolCache.returnPooledConnectionToPool activeConnections=0
> {noformat}
> But, then if an exception occurs after retrieving the {{XAConnection}}, it is
> not return to the {{ConnectionProvider}}.
> In my test, the exception occurs in
> {{GemFireTransactionDataSource.registerTranxConnection}}:
> {noformat}
> java.lang.Exception: GemFireTransactionDataSource-registerTranxConnection().
> Exception in registering the XAResource with the Transaction.Exception
> occurred= javax.transaction.SystemException:
> GlobalTransaction::enlistResource::error while enlisting XAResource
> org.apache.derby.client.am.XaException: XAER_RMFAIL : An error occurred
> during a deferred connect reset and the connection has been terminated.
> at
> org.apache.geode.internal.datasource.GemFireTransactionDataSource.registerTranxConnection(GemFireTransactionDataSource.java:218)
> at
> org.apache.geode.internal.datasource.GemFireTransactionDataSource.getConnection(GemFireTransactionDataSource.java:127)
> at TestServer.saveToDB(TestServer.java:177)
> at TestServer.save(TestServer.java:154)
> at TestServer.loadEntriesIntoDerby(TestServer.java:127)
> at TestServer$1.run(TestServer.java:112)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This is after the {{XAConnection}} has been retrieved from the
> {{ConnectionProvider}} and the {{activeConnections}} incremented, but before
> it has been returned to the application. Neither the
> {{registerTranxConnection}} method nor its caller ({{getConnection}}) does
> anything other than to throw the exception. The {{XAConnection}} is not
> returned to the pool nor is the {{activeConnections}} decremented.
> Finally, if enough of these exceptions occur, the test stops because all 30
> (default max) connections are in use. They aren't really in use, its just
> that the activeConnections counter hasn't been properly maintained.
> {noformat}
> Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=28
> Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=29
> Thread-14: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
> Thread-16: AbstractPoolCache.returnPooledConnectionToPool activeConnections=29
> Thread-18: AbstractPoolCache.returnPooledConnectionToPool activeConnections=28
> Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=29
> Thread-17: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
> Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=29
> Thread-18: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
> Thread-17: AbstractPoolCache.returnPooledConnectionToPool activeConnections=29
> Thread-14: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
> {noformat}
> It doesn't really matter what the exception is. If one occurs after
> retrieving the {{XAConnection}}, it needs to be
[jira] [Created] (GEODE-6887) Implement wrapper-style meters to route measurements to both meters and stats
Dale Emery created GEODE-6887:
-
Summary: 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
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] [Commented] (GEODE-6886) Region Sync should not be invoked when lost member is an empty accessor of persistent replicate region
[ https://issues.apache.org/jira/browse/GEODE-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866849#comment-16866849 ] ASF subversion and git services commented on GEODE-6886: Commit 67fc72b75276733d3e41d0edaf9c7953cafe35b1 in geode's branch refs/heads/feature/GEODE-6886 from eshu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=67fc72b ] GEODE-6886: Do not region sync if lost member is an empty accessor * Avoid region sync for empty accessor of persistent replicate region in correct place. > Region Sync should not be invoked when lost member is an empty accessor of > persistent replicate region > -- > > Key: GEODE-6886 > URL: https://issues.apache.org/jira/browse/GEODE-6886 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > > The following ClassCastException would be thrown: > [warn 2019/06/17 13:51:57.025 PDT tid=0x39] Timer task > encountered > exception > org.apache.geode.ToDataException: class > org.apache.geode.internal.cache.versions.DiskRegionVersionVector > 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:2138) > 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:1338) > at > org.apache.geode.internal.cache.DistributedRegion.synchronizeForLostMember(DistributedRegion.java:1327) > at > org.apache.geode.internal.cache.DistributedRegion.performSynchronizeForLostMemberTask(DistributedRegion.java:1309) > at > org.apache.geode.internal.cache.DistributedRegion$1.run2(DistributedRegion.java:1283) > 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.distributed.internal.membership.InternalDistributedMember > cannot be cast to org.apache.geode.internal.cache.persistence.DiskStoreID > at > org.apache.geode.internal.cache.versions.DiskRegionVersionVector.writeMember(DiskRegionVersionVector.java:30) > at > org.apache.geode.internal.cache.versions.RegionVersionVector.toData(RegionVersionVector.java:1205) > at > org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2300) > ... 24 more > The reason there is no need to sync with empty accessor is that it forwards > the writes to actual region hosts, and only a host could generate a region > version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-2878) If an exception occurs after retrieving an XAConnection from the ConnectionProvider but before returning it to the application, the GemFireTransactionDataSource doesn't
[
https://issues.apache.org/jira/browse/GEODE-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866837#comment-16866837
]
ASF subversion and git services commented on GEODE-2878:
Commit d05adfa3380d890358cb01089625d8c33f1674c4 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d05adfa ]
GEODE-2878: Fixup GemFireTransactionDataSourceIntegrationTest
* Use TemporaryFolder
* Remove thread sleeps
* Disable ENABLE_NETWORK_PARTITION_DETECTION
* Convert assertions to AssertJ
Closes #3538
> If an exception occurs after retrieving an XAConnection from the
> ConnectionProvider but before returning it to the application, the
> GemFireTransactionDataSource doesn't return it to the pool
> --
>
> Key: GEODE-2878
> URL: https://issues.apache.org/jira/browse/GEODE-2878
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Barry Oglesby
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, pull-request-available, storage_3
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> In my test, I have 5 threads inserting rows into a derby database.
> At first, as connections are being used and returned, the
> {{activeConnections}} is updated correctly:
> {noformat}
> Thread-16: AbstractPoolCache.getPooledConnectionFromPool activeConnections=1
> Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=2
> Thread-17: AbstractPoolCache.getPooledConnectionFromPool activeConnections=3
> Thread-14: AbstractPoolCache.getPooledConnectionFromPool activeConnections=4
> Thread-18: AbstractPoolCache.getPooledConnectionFromPool activeConnections=5
> Thread-16: AbstractPoolCache.returnPooledConnectionToPool activeConnections=4
> Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=3
> Thread-18: AbstractPoolCache.returnPooledConnectionToPool activeConnections=2
> Thread-17: AbstractPoolCache.returnPooledConnectionToPool activeConnections=1
> Thread-15: AbstractPoolCache.returnPooledConnectionToPool activeConnections=0
> {noformat}
> But, then if an exception occurs after retrieving the {{XAConnection}}, it is
> not return to the {{ConnectionProvider}}.
> In my test, the exception occurs in
> {{GemFireTransactionDataSource.registerTranxConnection}}:
> {noformat}
> java.lang.Exception: GemFireTransactionDataSource-registerTranxConnection().
> Exception in registering the XAResource with the Transaction.Exception
> occurred= javax.transaction.SystemException:
> GlobalTransaction::enlistResource::error while enlisting XAResource
> org.apache.derby.client.am.XaException: XAER_RMFAIL : An error occurred
> during a deferred connect reset and the connection has been terminated.
> at
> org.apache.geode.internal.datasource.GemFireTransactionDataSource.registerTranxConnection(GemFireTransactionDataSource.java:218)
> at
> org.apache.geode.internal.datasource.GemFireTransactionDataSource.getConnection(GemFireTransactionDataSource.java:127)
> at TestServer.saveToDB(TestServer.java:177)
> at TestServer.save(TestServer.java:154)
> at TestServer.loadEntriesIntoDerby(TestServer.java:127)
> at TestServer$1.run(TestServer.java:112)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This is after the {{XAConnection}} has been retrieved from the
> {{ConnectionProvider}} and the {{activeConnections}} incremented, but before
> it has been returned to the application. Neither the
> {{registerTranxConnection}} method nor its caller ({{getConnection}}) does
> anything other than to throw the exception. The {{XAConnection}} is not
> returned to the pool nor is the {{activeConnections}} decremented.
> Finally, if enough of these exceptions occur, the test stops because all 30
> (default max) connections are in use. They aren't really in use, its just
> that the activeConnections counter hasn't been properly maintained.
> {noformat}
> Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=28
> Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=29
> Thread-14: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
> Thread-16: AbstractPoolCache.returnPooledConnectionToPool activeConnections=29
> Thread-18: AbstractPoolCache.returnPooledConnectionToPool activeConnections=28
> Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=29
> Thread-17: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
> Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=29
> Thread-18:
[jira] [Commented] (GEODE-2878) If an exception occurs after retrieving an XAConnection from the ConnectionProvider but before returning it to the application, the GemFireTransactionDataSource doesn't
[
https://issues.apache.org/jira/browse/GEODE-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866836#comment-16866836
]
ASF subversion and git services commented on GEODE-2878:
Commit fc0409fc71799ab8a51c39e62393db4bcee85f29 in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=fc0409f ]
GEODE-2878: Returning XAConnection to pool after exception
> If an exception occurs after retrieving an XAConnection from the
> ConnectionProvider but before returning it to the application, the
> GemFireTransactionDataSource doesn't return it to the pool
> --
>
> Key: GEODE-2878
> URL: https://issues.apache.org/jira/browse/GEODE-2878
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Barry Oglesby
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, pull-request-available, storage_3
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> In my test, I have 5 threads inserting rows into a derby database.
> At first, as connections are being used and returned, the
> {{activeConnections}} is updated correctly:
> {noformat}
> Thread-16: AbstractPoolCache.getPooledConnectionFromPool activeConnections=1
> Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=2
> Thread-17: AbstractPoolCache.getPooledConnectionFromPool activeConnections=3
> Thread-14: AbstractPoolCache.getPooledConnectionFromPool activeConnections=4
> Thread-18: AbstractPoolCache.getPooledConnectionFromPool activeConnections=5
> Thread-16: AbstractPoolCache.returnPooledConnectionToPool activeConnections=4
> Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=3
> Thread-18: AbstractPoolCache.returnPooledConnectionToPool activeConnections=2
> Thread-17: AbstractPoolCache.returnPooledConnectionToPool activeConnections=1
> Thread-15: AbstractPoolCache.returnPooledConnectionToPool activeConnections=0
> {noformat}
> But, then if an exception occurs after retrieving the {{XAConnection}}, it is
> not return to the {{ConnectionProvider}}.
> In my test, the exception occurs in
> {{GemFireTransactionDataSource.registerTranxConnection}}:
> {noformat}
> java.lang.Exception: GemFireTransactionDataSource-registerTranxConnection().
> Exception in registering the XAResource with the Transaction.Exception
> occurred= javax.transaction.SystemException:
> GlobalTransaction::enlistResource::error while enlisting XAResource
> org.apache.derby.client.am.XaException: XAER_RMFAIL : An error occurred
> during a deferred connect reset and the connection has been terminated.
> at
> org.apache.geode.internal.datasource.GemFireTransactionDataSource.registerTranxConnection(GemFireTransactionDataSource.java:218)
> at
> org.apache.geode.internal.datasource.GemFireTransactionDataSource.getConnection(GemFireTransactionDataSource.java:127)
> at TestServer.saveToDB(TestServer.java:177)
> at TestServer.save(TestServer.java:154)
> at TestServer.loadEntriesIntoDerby(TestServer.java:127)
> at TestServer$1.run(TestServer.java:112)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This is after the {{XAConnection}} has been retrieved from the
> {{ConnectionProvider}} and the {{activeConnections}} incremented, but before
> it has been returned to the application. Neither the
> {{registerTranxConnection}} method nor its caller ({{getConnection}}) does
> anything other than to throw the exception. The {{XAConnection}} is not
> returned to the pool nor is the {{activeConnections}} decremented.
> Finally, if enough of these exceptions occur, the test stops because all 30
> (default max) connections are in use. They aren't really in use, its just
> that the activeConnections counter hasn't been properly maintained.
> {noformat}
> Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=28
> Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=29
> Thread-14: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
> Thread-16: AbstractPoolCache.returnPooledConnectionToPool activeConnections=29
> Thread-18: AbstractPoolCache.returnPooledConnectionToPool activeConnections=28
> Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=29
> Thread-17: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
> Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=29
> Thread-18: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
> Thread-17: AbstractPoolCache.returnPooledConnectionToPool
[jira] [Created] (GEODE-6886) Region Sync should not be invoked when lost member is an empty accessor of persistent replicate region
Eric Shu created GEODE-6886: --- Summary: Region Sync should not be invoked when lost member is an empty accessor of persistent replicate region Key: GEODE-6886 URL: https://issues.apache.org/jira/browse/GEODE-6886 Project: Geode Issue Type: Bug Components: regions Reporter: Eric Shu The following ClassCastException would be thrown: [warn 2019/06/17 13:51:57.025 PDT tid=0x39] Timer task encountered exception org.apache.geode.ToDataException: class org.apache.geode.internal.cache.versions.DiskRegionVersionVector 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:2138) 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:1338) at org.apache.geode.internal.cache.DistributedRegion.synchronizeForLostMember(DistributedRegion.java:1327) at org.apache.geode.internal.cache.DistributedRegion.performSynchronizeForLostMemberTask(DistributedRegion.java:1309) at org.apache.geode.internal.cache.DistributedRegion$1.run2(DistributedRegion.java:1283) 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.distributed.internal.membership.InternalDistributedMember cannot be cast to org.apache.geode.internal.cache.persistence.DiskStoreID at org.apache.geode.internal.cache.versions.DiskRegionVersionVector.writeMember(DiskRegionVersionVector.java:30) at org.apache.geode.internal.cache.versions.RegionVersionVector.toData(RegionVersionVector.java:1205) at org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2300) ... 24 more The reason there is no need to sync with empty accessor is that it forwards the writes to actual region hosts, and only a host could generate a region version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6886) Region Sync should not be invoked when lost member is an empty accessor of persistent replicate region
[ https://issues.apache.org/jira/browse/GEODE-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-6886: --- Assignee: Eric Shu > Region Sync should not be invoked when lost member is an empty accessor of > persistent replicate region > -- > > Key: GEODE-6886 > URL: https://issues.apache.org/jira/browse/GEODE-6886 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > > The following ClassCastException would be thrown: > [warn 2019/06/17 13:51:57.025 PDT tid=0x39] Timer task > encountered > exception > org.apache.geode.ToDataException: class > org.apache.geode.internal.cache.versions.DiskRegionVersionVector > 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:2138) > 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:1338) > at > org.apache.geode.internal.cache.DistributedRegion.synchronizeForLostMember(DistributedRegion.java:1327) > at > org.apache.geode.internal.cache.DistributedRegion.performSynchronizeForLostMemberTask(DistributedRegion.java:1309) > at > org.apache.geode.internal.cache.DistributedRegion$1.run2(DistributedRegion.java:1283) > 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.distributed.internal.membership.InternalDistributedMember > cannot be cast to org.apache.geode.internal.cache.persistence.DiskStoreID > at > org.apache.geode.internal.cache.versions.DiskRegionVersionVector.writeMember(DiskRegionVersionVector.java:30) > at > org.apache.geode.internal.cache.versions.RegionVersionVector.toData(RegionVersionVector.java:1205) > at > org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2300) > ... 24 more > The reason there is no need to sync with empty accessor is that it forwards > the writes to actual region hosts, and only a host could generate a region > version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3490) LocatorLauncherRemoteIntegrationTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-3490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866792#comment-16866792
]
Aaron Lindsey commented on GEODE-3490:
--
See:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/53]
org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTest >
startOverwritesStalePidFile FAILED
org.awaitility.core.ConditionTimeoutException: Assertion condition defined
as a lambda expression in
org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase
expected:<[online]> but was:<[not responding]> within 300 seconds.
at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
at
org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:200)
at
org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:183)
at
org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:193)
at
org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.startLocator(LocatorLauncherRemoteIntegrationTestCase.java:143)
at
org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTest.startOverwritesStalePidFile(LocatorLauncherRemoteIntegrationTest.java:88)
> LocatorLauncherRemoteIntegrationTest fails on Windows
> -
>
> Key: GEODE-3490
> URL: https://issues.apache.org/jira/browse/GEODE-3490
> Project: Geode
> Issue Type: Sub-task
> Components: gfsh, tests
> Environment: Windows
>Reporter: Kirk Lund
>Priority: Major
> Labels: CI, IntegrationTest, Windows, flaky
>
> {noformat}
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTest >
> pidFileContainsServerPid FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:196)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:179)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:189)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.startLocator(LocatorLauncherRemoteIntegrationTestCase.java:139)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTest.pidFileContainsServerPid(LocatorLauncherRemoteIntegrationTest.java:59)
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTest >
> startWithForceOverwritesExistingPidFile FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:196)
> at
>
[jira] [Commented] (GEODE-6545) Geode-Native User Guide - document 'pdxserializable' example
[ https://issues.apache.org/jira/browse/GEODE-6545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866789#comment-16866789 ] ASF subversion and git services commented on GEODE-6545: Commit 5b33ed66df0e2b5fd49d62f33f837e3b90c15ae2 in geode-native's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=5b33ed6 ] GEODE-6545: Language corrections to Pdx-related API docs. (#495) * GEODE-6545: Language corrections to Pdx-related API docs. No code changes, only comments. > Geode-Native User Guide - document 'pdxserializable' example > > > Key: GEODE-6545 > URL: https://issues.apache.org/jira/browse/GEODE-6545 > Project: Geode > Issue Type: Sub-task > Components: docs, native client >Reporter: Dave Barnes >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Document the 'pdxserializable' example. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6545) Geode-Native User Guide - document 'pdxserializable' example
[ https://issues.apache.org/jira/browse/GEODE-6545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866788#comment-16866788 ] ASF subversion and git services commented on GEODE-6545: Commit 5b33ed66df0e2b5fd49d62f33f837e3b90c15ae2 in geode-native's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=5b33ed6 ] GEODE-6545: Language corrections to Pdx-related API docs. (#495) * GEODE-6545: Language corrections to Pdx-related API docs. No code changes, only comments. > Geode-Native User Guide - document 'pdxserializable' example > > > Key: GEODE-6545 > URL: https://issues.apache.org/jira/browse/GEODE-6545 > Project: Geode > Issue Type: Sub-task > Components: docs, native client >Reporter: Dave Barnes >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Document the 'pdxserializable' example. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6849) PRHARedundancyProvider.buildPartitionedRegionInfo should not depend on the value of PartitionedRegionStats
[ https://issues.apache.org/jira/browse/GEODE-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murtuza Boxwala reassigned GEODE-6849: -- Assignee: Murtuza Boxwala > PRHARedundancyProvider.buildPartitionedRegionInfo should not depend on the > value of PartitionedRegionStats > -- > > Key: GEODE-6849 > URL: https://issues.apache.org/jira/browse/GEODE-6849 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Murtuza Boxwala >Priority: Major > > Since geode stats can be disabled, geode features should not depend on the > value of stats. > Instead that information should be obtained from some other internal product > counter that can not be disabled. > PRHARedundancyProvider.buildPartitionedRegionInfo reads the following from > PartitionedRegionStats: getLowRedundancyBucketCount() and > getActualRedundantCopies() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6588) Cleanup internal use of generics and other static analyzer warnings
[ https://issues.apache.org/jira/browse/GEODE-6588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866770#comment-16866770 ] ASF subversion and git services commented on GEODE-6588: Commit a5aba9165d2fab083c7c2543f38beb61c82e6c8c in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a5aba91 ] Revert "GEODE-6588: Properly type Function execution related interfaces. (#3691)" This reverts commit 6c62540edd5637d5e2bd3a51b11279a2ba825c33. > Cleanup internal use of generics and other static analyzer warnings > --- > > Key: GEODE-6588 > URL: https://issues.apache.org/jira/browse/GEODE-6588 > Project: Geode > Issue Type: Task >Reporter: Jacob S. Barrett >Assignee: Jacob S. Barrett >Priority: Major > Time Spent: 8h 40m > Remaining Estimate: 0h > > Use generics where possible. > Cleanup other static analyzer issues along the way. > Generally make the IntelliJ analyzer gutter less cluttered. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6677) Function with timeout, isHA==true and retries can lead to issues
[
https://issues.apache.org/jira/browse/GEODE-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866769#comment-16866769
]
ASF subversion and git services commented on GEODE-6677:
Commit 1572758b30f8cccbd9ffa52edc83789c4fdab1ec in geode's branch
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1572758 ]
Revert "GEODE-6677: Fix compile errors (#3715)"
This reverts commit 51d4b744cc689485676d20dc423469a29821374c.
> Function with timeout, isHA==true and retries can lead to issues
>
>
> Key: GEODE-6677
> URL: https://issues.apache.org/jira/browse/GEODE-6677
> Project: Geode
> Issue Type: Bug
>Reporter: Charlie Black
>Assignee: Bill Burcham
>Priority: Major
> Labels: SmallFeature
> Fix For: 1.10.0
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> A user can set `isHA() == true`, retries == -1, and `CLIENT_FUNCTION_TIMEOUT`.
> The timeout is currently implemented as per attempt. The default is 1
> ms.
> The default for retries is -1.
> With the default of -1 Geode will continually attempt to call the function
> and ignore the expected behavior.
>
> The expected behavior with respect to the default of -1 that means each
> server will be retried once and the system should throw an exception.
> From query the exception that is thrown is for system with 2 servers when the
> query exceeds the time out and retry of -1:
> {{Exception in thread "main"
> org.apache.geode.cache.client.ServerConnectivityException: Pool unexpected
> socket timed out on client connection=Pooled Connection to voltron:64615:
> Connection[voltron:64615]@1279740095 attempt=2). Server unreachable: could
> not connect after 2 attempts}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6660) Remove non-Linux OS statistics classes
[ https://issues.apache.org/jira/browse/GEODE-6660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-6660. - Resolution: Fixed > Remove non-Linux OS statistics classes > -- > > Key: GEODE-6660 > URL: https://issues.apache.org/jira/browse/GEODE-6660 > Project: Geode > Issue Type: Improvement > Components: docs, statistics >Reporter: Alberto Bustamante Reyes >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.10.0 > > Time Spent: 6h 20m > Remaining Estimate: 0h > > Remove the following legacy classes from > org.apache.geode.internal.statistics.platform package: > * OSXProcessStats > * OSXSystemStats > * SolarisProcessStats > * SolarisSystemStats > * WindowsProcessStats > * WindowsSystemStats > They are not needed, as OS statistics are only generated in Linux systems -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6660) Remove non-Linux OS statistics classes
[ https://issues.apache.org/jira/browse/GEODE-6660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866762#comment-16866762 ] ASF subversion and git services commented on GEODE-6660: Commit 77aec66eadb3a9466b1253a71b63176a24864ae6 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=77aec66 ] GEODE-6660: Remove non-Linux OS statistics classes (#3716) * OsStatisticsProvider.build() no longer throws IllegalStateException. It was doing this before if the operating system name did not match a well known one. But we want Geode to work on any OS that java supports. The OS stats currently only work on Linux, but the build method is called by GemFireStatSampler and we want that class to work on any OS. * PureJavaMode.osStatsAreAvailable is marked as deprecated. > Remove non-Linux OS statistics classes > -- > > Key: GEODE-6660 > URL: https://issues.apache.org/jira/browse/GEODE-6660 > Project: Geode > Issue Type: Improvement > Components: docs, statistics >Reporter: Alberto Bustamante Reyes >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.10.0 > > Time Spent: 6h 20m > Remaining Estimate: 0h > > Remove the following legacy classes from > org.apache.geode.internal.statistics.platform package: > * OSXProcessStats > * OSXSystemStats > * SolarisProcessStats > * SolarisSystemStats > * WindowsProcessStats > * WindowsSystemStats > They are not needed, as OS statistics are only generated in Linux systems -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6885) desribe config shows ssl keystore and truststore password in plainttext
Ashish Choudhary created GEODE-6885: --- Summary: desribe config shows ssl keystore and truststore password in plainttext Key: GEODE-6885 URL: https://issues.apache.org/jira/browse/GEODE-6885 Project: Geode Issue Type: Bug Components: security Reporter: Ashish Choudhary 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] [Updated] (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:all-tabpanel ] Ashish Choudhary updated GEODE-6885: Summary: desribe config shows ssl keystore and truststore password in plaintext (was: desribe config shows ssl keystore and truststore password in plainttext) > 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)
[jira] [Assigned] (GEODE-6880) Delete ModuleStatistics class and any related classes/documentation
[ https://issues.apache.org/jira/browse/GEODE-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes reassigned GEODE-6880: --- Assignee: Alberto Bustamante Reyes > Delete ModuleStatistics class and any related classes/documentation > --- > > Key: GEODE-6880 > URL: https://issues.apache.org/jira/browse/GEODE-6880 > Project: Geode > Issue Type: Improvement > Components: http session >Reporter: Ryan McMahon >Assignee: Alberto Bustamante Reyes >Priority: Major > > The ModuleStatistics class is completely unused and should be deleted. Any > documentation around it should also be deleted. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
