[jira] [Commented] (GEODE-6783) Remove Thread.sleep() from GatewayReceiverMetricsTest @before method
[ https://issues.apache.org/jira/browse/GEODE-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16842574#comment-16842574 ] Aaron Lindsey commented on GEODE-6783: -- Linked issue must be resolved before removing Thread.sleep() > Remove Thread.sleep() from GatewayReceiverMetricsTest @before method > > > Key: GEODE-6783 > URL: https://issues.apache.org/jira/browse/GEODE-6783 > Project: Geode > Issue Type: Improvement > Components: statistics >Reporter: Aaron Lindsey >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6783) Remove Thread.sleep() from GatewayReceiverMetricsTest @before method
Aaron Lindsey created GEODE-6783: Summary: Remove Thread.sleep() from GatewayReceiverMetricsTest @before method Key: GEODE-6783 URL: https://issues.apache.org/jira/browse/GEODE-6783 Project: Geode Issue Type: Improvement Components: statistics Reporter: Aaron Lindsey -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5222) JMX metric exposed in an MBean
[ https://issues.apache.org/jira/browse/GEODE-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852358#comment-16852358 ] Aaron Lindsey commented on GEODE-5222: -- In [RegionMXBean|[https://geode.apache.org/releases/latest/javadoc/org/apache/geode/management/RegionMXBean.html]], there are examples of metrics that return -1 (int) or -1.0 (float) under scenarios when the value is not applicable. In one such example, getPutLocalRate() returns ManagementConstants.NOT_AVAILABLE_FLOAT when the region is not a partitioned region . I think we could do the same thing here when the operator does not specify directory sizes. > JMX metric exposed in an MBean > -- > > Key: GEODE-5222 > URL: https://issues.apache.org/jira/browse/GEODE-5222 > Project: Geode > Issue Type: Improvement > Components: docs, persistence >Reporter: Nick Vallely >Assignee: Alberto Bustamante Reyes >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > Given I need to scale down or scale up my servers based on usage > When I setup my monitoring of JMX metrics through an MBean > Then I have the ability to see Disk Free Percentage > AND Disk Free in Bytes > AND Disk Used Percentage > AND Disk Used in Bytes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GEODE-5222) JMX metric exposed in an MBean
[ https://issues.apache.org/jira/browse/GEODE-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852358#comment-16852358 ] Aaron Lindsey edited comment on GEODE-5222 at 5/30/19 8:59 PM: --- In RegionMXBean, there are examples of metrics that return -1 (int) or -1.0 (float) under scenarios when the value is not applicable. In one such example, getPutLocalRate() returns ManagementConstants.NOT_AVAILABLE_FLOAT when the region is not a partitioned region . I think we could do the same thing here when the operator does not specify directory sizes. was (Author: aaronlindsey): In [RegionMXBean|[https://geode.apache.org/releases/latest/javadoc/org/apache/geode/management/RegionMXBean.html]], there are examples of metrics that return -1 (int) or -1.0 (float) under scenarios when the value is not applicable. In one such example, getPutLocalRate() returns ManagementConstants.NOT_AVAILABLE_FLOAT when the region is not a partitioned region . I think we could do the same thing here when the operator does not specify directory sizes. > JMX metric exposed in an MBean > -- > > Key: GEODE-5222 > URL: https://issues.apache.org/jira/browse/GEODE-5222 > Project: Geode > Issue Type: Improvement > Components: docs, persistence >Reporter: Nick Vallely >Assignee: Alberto Bustamante Reyes >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > Given I need to scale down or scale up my servers based on usage > When I setup my monitoring of JMX metrics through an MBean > Then I have the ability to see Disk Free Percentage > AND Disk Free in Bytes > AND Disk Used Percentage > AND Disk Used in Bytes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5222) JMX metric exposed in an MBean
[ https://issues.apache.org/jira/browse/GEODE-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16851367#comment-16851367 ] Aaron Lindsey commented on GEODE-5222: -- The operator has the ability to not specify a directory size when creating a disk store. In this case, the system will assume unlimited storage. What should these metrics show for disk free and disk free/used percentage when the directory size is not specified? > JMX metric exposed in an MBean > -- > > Key: GEODE-5222 > URL: https://issues.apache.org/jira/browse/GEODE-5222 > Project: Geode > Issue Type: Improvement > Components: docs, persistence >Reporter: Nick Vallely >Assignee: Alberto Bustamante Reyes >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Given I need to scale down or scale up my servers based on usage > When I setup my monitoring of JMX metrics through an MBean > Then I have the ability to see Disk Free Percentage > AND Disk Free in Bytes > AND Disk Used Percentage > AND Disk Used in Bytes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6777) Create gateway senders command should only return when DistributedSystemMXBean reflects creation status
[
https://issues.apache.org/jira/browse/GEODE-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860409#comment-16860409
]
Aaron Lindsey commented on GEODE-6777:
--
Can this be closed since the PR is merged?
> Create gateway senders command should only return when
> DistributedSystemMXBean reflects creation status
> ---
>
> Key: GEODE-6777
> URL: https://issues.apache.org/jira/browse/GEODE-6777
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently, the following sequence of commands will fail:
> {noformat}
> $GEODE_HOME/bin/gfsh -e "connect --locator=localhost[10334]" \
> -e "create gateway-sender --id=gs --parallel=false
> --remote-distributed-system-id=1" \
> -e "create region --name=region --type=REPLICATE
> --gateway-sender-id=gs"{noformat}
> With an error indicating that the gateway sender does not exist. This is due
> to the time it takes for the creation to be registered in the
> {{DistributedSystemMXBean}}. We should only return from this command once the
> appropriate constructs are visible in the bean.
> Once fixed, we can remove
> {{MemberVM.waitUntilGatewaySendersAreReadyOnExactlyThisManyServers}}.
--
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-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] [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-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] [Updated] (GEODE-6683) java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-6683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey updated GEODE-6683:
-
Fix Version/s: 1.10.0
> java.lang.NullPointerException
> --
>
> Key: GEODE-6683
> URL: https://issues.apache.org/jira/browse/GEODE-6683
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Affects Versions: 1.6.0
>Reporter: YE LIN
>Assignee: Aaron Lindsey
>Priority: Major
> Labels: observability
> Fix For: 1.10.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> when Pulse is ran without embedded mode in Locator, throw NullPointException
> during running code : repository.getJavaSslProperties().stringPropertyNames()
> look like repository.javaSslProperties is null.
> {noformat}
> 2019-04-24 02:08:06,767 INFO o.a.g.t.p.i.d.JMXDataUpdater
> [http-nio-7070-exec-1] Locator has found a jmx manager: Host=10.116.37.211 &
> Port=1099, with SSL
> 2019-04-24 02:08:06,773 FATAL o.a.g.t.p.i.d.JMXDataUpdater
> [http-nio-7070-exec-1] null
> java.lang.NullPointerException: null
> at
> org.apache.geode.tools.pulse.internal.data.JMXDataUpdater.connect(JMXDataUpdater.java:217)
> [classes/:?]
> at
> org.apache.geode.tools.pulse.internal.data.Cluster.connectToGemFire(Cluster.java:2805)
> [classes/:?]
> at
> org.apache.geode.tools.pulse.internal.data.Repository.getCluster(Repository.java:139)
> [classes/:?]
> at
> org.apache.geode.tools.pulse.internal.security.GemFireAuthenticationProvider.authenticate(GemFireAuthenticationProvider.java:57)
> [classes/:?]
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6683) java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-6683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey resolved GEODE-6683.
--
Resolution: Fixed
> java.lang.NullPointerException
> --
>
> Key: GEODE-6683
> URL: https://issues.apache.org/jira/browse/GEODE-6683
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Affects Versions: 1.6.0
>Reporter: YE LIN
>Assignee: Aaron Lindsey
>Priority: Major
> Labels: observability
> Fix For: 1.10.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> when Pulse is ran without embedded mode in Locator, throw NullPointException
> during running code : repository.getJavaSslProperties().stringPropertyNames()
> look like repository.javaSslProperties is null.
> {noformat}
> 2019-04-24 02:08:06,767 INFO o.a.g.t.p.i.d.JMXDataUpdater
> [http-nio-7070-exec-1] Locator has found a jmx manager: Host=10.116.37.211 &
> Port=1099, with SSL
> 2019-04-24 02:08:06,773 FATAL o.a.g.t.p.i.d.JMXDataUpdater
> [http-nio-7070-exec-1] null
> java.lang.NullPointerException: null
> at
> org.apache.geode.tools.pulse.internal.data.JMXDataUpdater.connect(JMXDataUpdater.java:217)
> [classes/:?]
> at
> org.apache.geode.tools.pulse.internal.data.Cluster.connectToGemFire(Cluster.java:2805)
> [classes/:?]
> at
> org.apache.geode.tools.pulse.internal.data.Repository.getCluster(Repository.java:139)
> [classes/:?]
> at
> org.apache.geode.tools.pulse.internal.security.GemFireAuthenticationProvider.authenticate(GemFireAuthenticationProvider.java:57)
> [classes/:?]
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6683) java.lang.NullPointerException
[ https://issues.apache.org/jira/browse/GEODE-6683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-6683: Assignee: Aaron Lindsey (was: Kirk Lund) > java.lang.NullPointerException > -- > > Key: GEODE-6683 > URL: https://issues.apache.org/jira/browse/GEODE-6683 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.6.0 >Reporter: YE LIN >Assignee: Aaron Lindsey >Priority: Major > Labels: observability > > *Context:* > when Pulse is ran without embedded mode in Locator, throw NullPointException > during running code : repository.getJavaSslProperties().stringPropertyNames() > look like repository.javaSslProperties is null. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-7044) RebalanceIntegrationTest failures
[ https://issues.apache.org/jira/browse/GEODE-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-7044: Assignee: Aaron Lindsey > RebalanceIntegrationTest failures > - > > Key: GEODE-7044 > URL: https://issues.apache.org/jira/browse/GEODE-7044 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > > The following 2 tests fail in our PR check and also when I run the > integration tests on the develop branch. > org.apache.geode.management.internal.rest.RebalanceIntegrationTest > list > FAILED > java.lang.AssertionError: JSON path "$.result[0].uri" > Expected: a string containing "rebalance/" > but: was > "/management/experimental/operations/rebalances/52cd4c7a-4c3e-4fcb-a482-b0123744280e" > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) > at > org.springframework.test.util.JsonPathExpectationsHelper.assertValue(JsonPathExpectationsHelper.java:74) > at > org.springframework.test.web.servlet.result.JsonPathResultMatchers$1.match(JsonPathResultMatchers.java:89) > at > org.springframework.test.web.servlet.MockMvc$1.andExpect(MockMvc.java:164) > at > org.apache.geode.management.internal.rest.RebalanceIntegrationTest.list(RebalanceIntegrationTest.java:91) > org.apache.geode.management.internal.rest.RebalanceIntegrationTest > > doListOperations FAILED > java.lang.AssertionError: > Expecting: > > <"/management/experimental/operations/rebalances/2836b5aa-2866-4fd5-92ef-9152fa2087bf"> > to contain: > <"rebalance/"> > at > org.apache.geode.management.internal.rest.RebalanceIntegrationTest.doListOperations(RebalanceIntegrationTest.java:115) -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7044) RebalanceIntegrationTest failures
Aaron Lindsey created GEODE-7044: Summary: RebalanceIntegrationTest failures Key: GEODE-7044 URL: https://issues.apache.org/jira/browse/GEODE-7044 Project: Geode Issue Type: Bug Components: management Reporter: Aaron Lindsey The following 2 tests fail in our PR check and also when I run the integration tests on the develop branch. org.apache.geode.management.internal.rest.RebalanceIntegrationTest > list FAILED java.lang.AssertionError: JSON path "$.result[0].uri" Expected: a string containing "rebalance/" but: was "/management/experimental/operations/rebalances/52cd4c7a-4c3e-4fcb-a482-b0123744280e" at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at org.springframework.test.util.JsonPathExpectationsHelper.assertValue(JsonPathExpectationsHelper.java:74) at org.springframework.test.web.servlet.result.JsonPathResultMatchers$1.match(JsonPathResultMatchers.java:89) at org.springframework.test.web.servlet.MockMvc$1.andExpect(MockMvc.java:164) at org.apache.geode.management.internal.rest.RebalanceIntegrationTest.list(RebalanceIntegrationTest.java:91) org.apache.geode.management.internal.rest.RebalanceIntegrationTest > doListOperations FAILED java.lang.AssertionError: Expecting: <"/management/experimental/operations/rebalances/2836b5aa-2866-4fd5-92ef-9152fa2087bf"> to contain: <"rebalance/"> at org.apache.geode.management.internal.rest.RebalanceIntegrationTest.doListOperations(RebalanceIntegrationTest.java:115) -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (GEODE-7044) RebalanceIntegrationTest failures
[ https://issues.apache.org/jira/browse/GEODE-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey closed GEODE-7044. > RebalanceIntegrationTest failures > - > > Key: GEODE-7044 > URL: https://issues.apache.org/jira/browse/GEODE-7044 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > > The following 2 tests fail in our PR check and also when I run the > integration tests on the develop branch. > org.apache.geode.management.internal.rest.RebalanceIntegrationTest > list > FAILED > java.lang.AssertionError: JSON path "$.result[0].uri" > Expected: a string containing "rebalance/" > but: was > "/management/experimental/operations/rebalances/52cd4c7a-4c3e-4fcb-a482-b0123744280e" > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) > at > org.springframework.test.util.JsonPathExpectationsHelper.assertValue(JsonPathExpectationsHelper.java:74) > at > org.springframework.test.web.servlet.result.JsonPathResultMatchers$1.match(JsonPathResultMatchers.java:89) > at > org.springframework.test.web.servlet.MockMvc$1.andExpect(MockMvc.java:164) > at > org.apache.geode.management.internal.rest.RebalanceIntegrationTest.list(RebalanceIntegrationTest.java:91) > org.apache.geode.management.internal.rest.RebalanceIntegrationTest > > doListOperations FAILED > java.lang.AssertionError: > Expecting: > > <"/management/experimental/operations/rebalances/2836b5aa-2866-4fd5-92ef-9152fa2087bf"> > to contain: > <"rebalance/"> > at > org.apache.geode.management.internal.rest.RebalanceIntegrationTest.doListOperations(RebalanceIntegrationTest.java:115) -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-7044) RebalanceIntegrationTest failures
[ https://issues.apache.org/jira/browse/GEODE-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey resolved GEODE-7044. -- Resolution: Invalid Already fixed on develop. > RebalanceIntegrationTest failures > - > > Key: GEODE-7044 > URL: https://issues.apache.org/jira/browse/GEODE-7044 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > > The following 2 tests fail in our PR check and also when I run the > integration tests on the develop branch. > org.apache.geode.management.internal.rest.RebalanceIntegrationTest > list > FAILED > java.lang.AssertionError: JSON path "$.result[0].uri" > Expected: a string containing "rebalance/" > but: was > "/management/experimental/operations/rebalances/52cd4c7a-4c3e-4fcb-a482-b0123744280e" > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) > at > org.springframework.test.util.JsonPathExpectationsHelper.assertValue(JsonPathExpectationsHelper.java:74) > at > org.springframework.test.web.servlet.result.JsonPathResultMatchers$1.match(JsonPathResultMatchers.java:89) > at > org.springframework.test.web.servlet.MockMvc$1.andExpect(MockMvc.java:164) > at > org.apache.geode.management.internal.rest.RebalanceIntegrationTest.list(RebalanceIntegrationTest.java:91) > org.apache.geode.management.internal.rest.RebalanceIntegrationTest > > doListOperations FAILED > java.lang.AssertionError: > Expecting: > > <"/management/experimental/operations/rebalances/2836b5aa-2866-4fd5-92ef-9152fa2087bf"> > to contain: > <"rebalance/"> > at > org.apache.geode.management.internal.rest.RebalanceIntegrationTest.doListOperations(RebalanceIntegrationTest.java:115) -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-7095) addsMetersForFileDescriptorMetricsBinder test fails: meters is empty
[
https://issues.apache.org/jira/browse/GEODE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey resolved GEODE-7095.
--
Resolution: Fixed
Fix Version/s: 1.11.0
> addsMetersForFileDescriptorMetricsBinder test fails: meters is empty
>
>
> Key: GEODE-7095
> URL: https://issues.apache.org/jira/browse/GEODE-7095
> Project: Geode
> Issue Type: Bug
>Reporter: Bill Burcham
>Assignee: Aaron Lindsey
>Priority: Major
> Fix For: 1.11.0
>
>
> In this CI build:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK8/builds/766
> The brand new test fails:
> {code}
> org.apache.geode.internal.metrics.CacheMeterRegistryFactoryTest >
> addsMetersForFileDescriptorMetricsBinder FAILED
> java.lang.AssertionError:
> Expecting actual not to be empty
> at
> org.apache.geode.internal.metrics.CacheMeterRegistryFactoryTest.addsMetersForFileDescriptorMetricsBinder(CacheMeterRegistryFactoryTest.java:181)
> {code}
> 10 runs on laptop did not reproduce the issue.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Reopened] (GEODE-7091) Add Micrometer binders to default meter registry
[ https://issues.apache.org/jira/browse/GEODE-7091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reopened GEODE-7091: -- Still adding tests for this. > Add Micrometer binders to default meter registry > > > Key: GEODE-7091 > URL: https://issues.apache.org/jira/browse/GEODE-7091 > Project: Geode > Issue Type: Improvement > Components: statistics >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Fix For: 1.11.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > As a user, there are specific JVM metrics, GC metrics, Uptime, and > FileDescriptor metrics that help indicate and track down issues with health > of the cluster, that I want to access in order to understand the health of my > cluster. > Add the following Micrometer binders: > * JvmGcMetrics > * ProcessorMetrics > * JvmThreadMetrics > * UptimeMetrics > * FileDescriptorMetrics -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-7091) Add Micrometer binders to default meter registry
[ https://issues.apache.org/jira/browse/GEODE-7091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey resolved GEODE-7091. -- Resolution: Fixed Fix Version/s: 1.11.0 > Add Micrometer binders to default meter registry > > > Key: GEODE-7091 > URL: https://issues.apache.org/jira/browse/GEODE-7091 > Project: Geode > Issue Type: Improvement > Components: statistics >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > As a user, there are specific JVM metrics, GC metrics, Uptime, and > FileDescriptor metrics that help indicate and track down issues with health > of the cluster, that I want to access in order to understand the health of my > cluster. > Add the following Micrometer binders: > * JvmGcMetrics > * ProcessorMetrics > * JvmThreadMetrics > * UptimeMetrics > * FileDescriptorMetrics -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-7081) NPE in PartitionedRegion.getLocalSize()
[ https://issues.apache.org/jira/browse/GEODE-7081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey resolved GEODE-7081. -- Resolution: Fixed Fix Version/s: 1.10.0 > NPE in PartitionedRegion.getLocalSize() > --- > > Key: GEODE-7081 > URL: https://issues.apache.org/jira/browse/GEODE-7081 > Project: Geode > Issue Type: Bug >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Fix For: 1.10.0 > > Time Spent: 40m > Remaining Estimate: 0h > > PartitionedRegion.getLocalSize() throws a NullPointerException if called > before PartitionedRegion.initialize(). It should return zero instead of > throwing. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-7091) Add Micrometer binders to default meter registry
[ https://issues.apache.org/jira/browse/GEODE-7091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-7091: Assignee: Aaron Lindsey > Add Micrometer binders to default meter registry > > > Key: GEODE-7091 > URL: https://issues.apache.org/jira/browse/GEODE-7091 > Project: Geode > Issue Type: Improvement > Components: statistics >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > As a user, there are specific JVM metrics, GC metrics, Uptime, and > FileDescriptor metrics that help indicate and track down issues with health > of the cluster, that I want to access in order to understand the health of my > cluster. > Add the following Micrometer binders: > * JvmGcMetrics > * ProcessorMetrics > * JvmThreadMetrics > * UptimeMetrics > * FileDescriptorMetrics -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7091) Add Micrometer binders to default meter registry
Aaron Lindsey created GEODE-7091: Summary: Add Micrometer binders to default meter registry Key: GEODE-7091 URL: https://issues.apache.org/jira/browse/GEODE-7091 Project: Geode Issue Type: Improvement Components: statistics Reporter: Aaron Lindsey As a user, there are specific JVM metrics, GC metrics, Uptime, and FileDescriptor metrics that help indicate and track down issues with health of the cluster, that I want to access in order to understand the health of my cluster. Add the following Micrometer binders: * JvmGcMetrics * ProcessorMetrics * JvmThreadMetrics * UptimeMetrics * FileDescriptorMetrics -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-7095) addsMetersForFileDescriptorMetricsBinder test fails: meters is empty
[
https://issues.apache.org/jira/browse/GEODE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908584#comment-16908584
]
Aaron Lindsey commented on GEODE-7095:
--
The commit that caused this issue has been reverted.
> addsMetersForFileDescriptorMetricsBinder test fails: meters is empty
>
>
> Key: GEODE-7095
> URL: https://issues.apache.org/jira/browse/GEODE-7095
> Project: Geode
> Issue Type: Bug
>Reporter: Bill Burcham
>Priority: Major
>
> In this CI build:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK8/builds/766
> The brand new test fails:
> {code}
> org.apache.geode.internal.metrics.CacheMeterRegistryFactoryTest >
> addsMetersForFileDescriptorMetricsBinder FAILED
> java.lang.AssertionError:
> Expecting actual not to be empty
> at
> org.apache.geode.internal.metrics.CacheMeterRegistryFactoryTest.addsMetersForFileDescriptorMetricsBinder(CacheMeterRegistryFactoryTest.java:181)
> {code}
> 10 runs on laptop did not reproduce the issue.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (GEODE-7095) addsMetersForFileDescriptorMetricsBinder test fails: meters is empty
[
https://issues.apache.org/jira/browse/GEODE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey reassigned GEODE-7095:
Assignee: Aaron Lindsey
> addsMetersForFileDescriptorMetricsBinder test fails: meters is empty
>
>
> Key: GEODE-7095
> URL: https://issues.apache.org/jira/browse/GEODE-7095
> Project: Geode
> Issue Type: Bug
>Reporter: Bill Burcham
>Assignee: Aaron Lindsey
>Priority: Major
>
> In this CI build:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK8/builds/766
> The brand new test fails:
> {code}
> org.apache.geode.internal.metrics.CacheMeterRegistryFactoryTest >
> addsMetersForFileDescriptorMetricsBinder FAILED
> java.lang.AssertionError:
> Expecting actual not to be empty
> at
> org.apache.geode.internal.metrics.CacheMeterRegistryFactoryTest.addsMetersForFileDescriptorMetricsBinder(CacheMeterRegistryFactoryTest.java:181)
> {code}
> 10 runs on laptop did not reproduce the issue.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (GEODE-7081) NPE in PartitionedRegion.getLocalSize()
Aaron Lindsey created GEODE-7081: Summary: NPE in PartitionedRegion.getLocalSize() Key: GEODE-7081 URL: https://issues.apache.org/jira/browse/GEODE-7081 Project: Geode Issue Type: Bug Reporter: Aaron Lindsey PartitionedRegion.getLocalSize() throws a NullPointerException if called before PartitionedRegion.initialize(). It should return zero instead of throwing. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-7081) NPE in PartitionedRegion.getLocalSize()
[ https://issues.apache.org/jira/browse/GEODE-7081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-7081: Assignee: Aaron Lindsey > NPE in PartitionedRegion.getLocalSize() > --- > > Key: GEODE-7081 > URL: https://issues.apache.org/jira/browse/GEODE-7081 > Project: Geode > Issue Type: Bug >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > > PartitionedRegion.getLocalSize() throws a NullPointerException if called > before PartitionedRegion.initialize(). It should return zero instead of > throwing. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6903) CI Failure: GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection failed with Assertion
[ https://issues.apache.org/jira/browse/GEODE-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912511#comment-16912511 ] Aaron Lindsey commented on GEODE-6903: -- Failed again: [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/997] > CI Failure: > GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection > failed with Assertion > > > Key: GEODE-6903 > URL: https://issues.apache.org/jira/browse/GEODE-6903 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Assignee: Mark Hanson >Priority: Major > > org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest > > testExceptionHandlingGetConnection FAILED > org.junit.ComparisonFailure: expected:<[0]> but was:<[2]> > at sun.reflect.GeneratedConstructorAccessor26.newInstance(Unknown > Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection(GemFireTransactionDataSourceIntegrationTest.java:141) > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0399/test-results/integrationTest/1561170841/ > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0399/test-artifacts/1561170841/integrationtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0399.tgz -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-6616) Flaky: AutoConnectionSourceDUnitTest > testClientDynamicallyDropsStoppedLocator FAILED
[
https://issues.apache.org/jira/browse/GEODE-6616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912505#comment-16912505
]
Aaron Lindsey commented on GEODE-6616:
--
and again:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1006]
> Flaky: AutoConnectionSourceDUnitTest >
> testClientDynamicallyDropsStoppedLocator FAILED
> --
>
> Key: GEODE-6616
> URL: https://issues.apache.org/jira/browse/GEODE-6616
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Minor
>
> Failed connection..
> {noformat}
> [vm3] [info 2019/04/09 06:48:44.919 UTC
> tid=0x20] Got result: EXCEPTION_OCCURRED
> [vm3] org.apache.geode.cache.client.ServerOperationException: remote server
> on 16f27a14ad79(255:loner):52816:5f2bdb00: : While performing a remote put
> [vm3] at
> org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processAck(PutOp.java:389)
> [vm3] at
> org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processResponse(PutOp.java:313)
> [vm3] at
> org.apache.geode.cache.client.internal.PutOp$PutOpImpl.attemptReadResponse(PutOp.java:454)
> [vm3] at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:387)
> [vm3] at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:289)
> [vm3] at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:351)
> [vm3] at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:908)
> [vm3] at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:172)
> [vm3] at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:130)
> [vm3] at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:792)
> [vm3] at
> org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:90)
> [vm3] at
> org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:155)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3070)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3222)
> [vm3] at
> org.apache.geode.internal.cache.map.RegionMapPut.invokeCacheWriter(RegionMapPut.java:230)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutIfPreconditionsSatisified(AbstractRegionMapPut.java:295)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutOnSynchronizedRegionEntry(AbstractRegionMapPut.java:282)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutOnRegionEntryInMap(AbstractRegionMapPut.java:273)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.addRegionEntryToMapAndDoPut(AbstractRegionMapPut.java:251)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutRetryingIfNeeded(AbstractRegionMapPut.java:216)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doWithIndexInUpdateMode(AbstractRegionMapPut.java:198)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:180)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> [vm3] at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:150)
> [vm3] at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
> [vm3] at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5695)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5123)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1652)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.lambda$put$3(LocalRegion.java:1638)
> [vm3] at
> io.micrometer.core.instrument.composite.CompositeTimer.record(CompositeTimer.java:57)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1634)
> [vm3] at
> org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:425)
> [vm3] at
>
[jira] [Reopened] (GEODE-7072) CI Failure: WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo > EventProcessingMixedSiteOneCurrentSiteTwo[from_v130] FAILED
[
https://issues.apache.org/jira/browse/GEODE-7072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey reopened GEODE-7072:
--
Assignee: Bruce Schuchardt
Bruce is investigating another failure of this test.
> CI Failure: WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo >
> EventProcessingMixedSiteOneCurrentSiteTwo[from_v130] FAILED
>
>
> Key: GEODE-7072
> URL: https://issues.apache.org/jira/browse/GEODE-7072
> Project: Geode
> Issue Type: Test
> Components: wan
>Reporter: Owen Nichols
>Assignee: Bruce Schuchardt
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.cache.wan.WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo
> > EventProcessingMixedSiteOneCurrentSiteTwo[from_v130] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.wan.WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo$$Lambda$47/1509632157.run
> in VM 0 running on Host aac3b458d9ea with 7 VMs with version 130
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo.EventProcessingMixedSiteOneCurrentSiteTwo(WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo.java:63)
> Caused by:
> org.apache.geode.InternalGemFireException: Unable to recover previous
> membership view from locator26547view.dat
> at
> org.apache.geode.distributed.internal.membership.gms.locator.GMSLocator.recoverFromFile(GMSLocator.java:462)
> at
> org.apache.geode.distributed.internal.membership.gms.locator.GMSLocator.recover(GMSLocator.java:387)
> at
> org.apache.geode.distributed.internal.membership.gms.locator.GMSLocator.init(GMSLocator.java:146)
> at
> org.apache.geode.distributed.internal.InternalLocator$PrimaryHandler.init(InternalLocator.java:1225)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:232)
> at
> org.apache.geode.distributed.internal.InternalLocator.startTcpServer(InternalLocator.java:517)
> at
> org.apache.geode.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:575)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:321)
> at
> org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startLocator(WANRollingUpgradeDUnitTest.java:105)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startLocator(WANRollingUpgradeDUnitTest.java:97)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo.lambda$EventProcessingMixedSiteOneCurrentSiteTwo$6f8ee815$1(WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo.java:63)
> Caused by:
> org.apache.geode.SerializationException: Could not create an
> instance of org.apache.geode.distributed.internal.membership.NetView .
> at
> org.apache.geode.internal.InternalDataSerializer.invokeFromData(InternalDataSerializer.java:2381)
> at
> org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:986)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2693)
> at
> org.apache.geode.DataSerializer.readObject(DataSerializer.java:2961)
> at
> org.apache.geode.distributed.internal.membership.gms.locator.GMSLocator.recoverFromFile(GMSLocator.java:440)
> ... 12 more
> Caused by:
> org.apache.geode.SerializationException: Could not create an
> instance of org.apache.geode.distributed.internal.membership.gms.GMSMember .
> at
> org.apache.geode.internal.InternalDataSerializer.invokeFromData(InternalDataSerializer.java:2381)
> at
> org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:986)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2693)
> at
> org.apache.geode.DataSerializer.readObject(DataSerializer.java:2961)
> at
> org.apache.geode.distributed.internal.membership.NetView.fromData(NetView.java:603)
>
[jira] [Assigned] (GEODE-750) Expose evictionStartEvents and heapCriticalEvents as attributes on MemberMXBean
[ https://issues.apache.org/jira/browse/GEODE-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-750: --- Assignee: Jens Deppe > Expose evictionStartEvents and heapCriticalEvents as attributes on > MemberMXBean > --- > > Key: GEODE-750 > URL: https://issues.apache.org/jira/browse/GEODE-750 > Project: Geode > Issue Type: Improvement > Components: jmx, statistics >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-751) RegionMXBean shouldn't rely on Eviction Algorithm for getEntrySize
[
https://issues.apache.org/jira/browse/GEODE-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey reassigned GEODE-751:
---
Assignee: Jens Deppe
We intent to de-couple the need for eviction information to exist in order to
get a measurement on the amount of bytes in a replicate region when we get to
this measurement in Micrometer. Can we create a new Jira ticket for fixing this
in Micrometer?
> RegionMXBean shouldn't rely on Eviction Algorithm for getEntrySize
> --
>
> Key: GEODE-751
> URL: https://issues.apache.org/jira/browse/GEODE-751
> Project: Geode
> Issue Type: Improvement
> Components: jmx, statistics
>Affects Versions: 1.0.0-incubating
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> We have the following in the javadoc for method {{getEntrySize}} on interface
> {{RegionMXBean}}:
> {quote}
> Returns the aggregate entry size (in bytes) of all entries. This will provide
> a correct value only if the eviction algorithm has been set to
> {{EvictionAlgorithm.LRU_MEMORY}}. For all partition regions it will show
> entry size in bytes. It will also include size of all the secondary entries
> in the data store. So while referring to size one should take redundancy into
> account.
> {quote}
> The region memory consumption and the eviction algorithm are two separate
> concepts, we should not obligate customers to use a custom eviction algorithm
> to report the correct memory consumption for a region.
> We rely on this attribute to show information on PULSE, so neither the member
> memory usage nor cluster memory usage are accurate if the eviction algorithm
> is not configured as {{EvictionAlgorithm.LRU_MEMORY}}.
> To reproduce, start up a cluster with a simple replicated region and insert
> some data. You can check afterwards (from JConsole) that the attribute
> "EntrySize" for the replicated region is set as "-1".
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-2946) Extend pulse data browser to support lucene queries
[ https://issues.apache.org/jira/browse/GEODE-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-2946: - Labels: observability (was: ) > Extend pulse data browser to support lucene queries > --- > > Key: GEODE-2946 > URL: https://issues.apache.org/jira/browse/GEODE-2946 > Project: Geode > Issue Type: New Feature > Components: lucene, pulse >Reporter: Shelley Lynn Hughes-Godfrey >Priority: Major > Labels: observability > > It would be nice to allow lucene queries through the pulse data browser -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-750) Expose evictionStartEvents and heapCriticalEvents as attributes on MemberMXBean
[ https://issues.apache.org/jira/browse/GEODE-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911799#comment-16911799 ] Aaron Lindsey commented on GEODE-750: - [~jens.deppe] assigned to you. We're evaluating observability related tickets, and this doesn't seem in-line with our path of exposing metrics via Micrometer. Would you have any issues with us closing it, or would you push for us exposing this through Micrometer? > Expose evictionStartEvents and heapCriticalEvents as attributes on > MemberMXBean > --- > > Key: GEODE-750 > URL: https://issues.apache.org/jira/browse/GEODE-750 > Project: Geode > Issue Type: Improvement > Components: jmx, statistics >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-1383) LogBanner is missing from rolled log files
[ https://issues.apache.org/jira/browse/GEODE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-1383: - Labels: LogBanner observability starter (was: LogBanner starter) > LogBanner is missing from rolled log files > -- > > Key: GEODE-1383 > URL: https://issues.apache.org/jira/browse/GEODE-1383 > Project: Geode > Issue Type: Bug > Components: logging >Reporter: Jens Deppe >Assignee: Kirk Lund >Priority: Major > Labels: LogBanner, observability, starter > > Please add gemfire,heap, xml configuration information to start of every log > file > We often have situations where we have difficulty establishing the > configuration or JVM startup arguments, or XML configuration without multiple > interactions with the customer, even when they've provided logs. When the > customer has rolled over enough, and we overwrite the "parent" first log, we > then lose all of that detail from startup that often proves very helpful. > If it would be easy to incorporate this startup configuration information > into the beginning of each log file as we rollover, we would always have it > and be able to be more productive debugging prod issues and ultimately have > happier users. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-1210) MemberMBeanBridge DiskDirectoryStats are not monitored for PartitionedRegions
[
https://issues.apache.org/jira/browse/GEODE-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey reassigned GEODE-1210:
Assignee: Barry Oglesby
Is this still an issue? If so, what is the expected behavior for a partitioned
region DiskDirectoryStats?
> MemberMBeanBridge DiskDirectoryStats are not monitored for PartitionedRegions
> -
>
> Key: GEODE-1210
> URL: https://issues.apache.org/jira/browse/GEODE-1210
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
> Labels: observability
>
> This means that {{TotalDiskUsage}} is 0 for {{PartitionedRegions}}.
> The member's {{TotalDiskUsage}} JMX attribute comes from
> {{MemberMBeanBridge.getTotalDiskUsage}} which does:
> {noformat}
> public long getTotalDiskUsage() {
> long diskSpaceUsage = regionMonitor.getDiskSpace();
> return diskSpaceUsage;
> }
> {noformat}
> The {{regionMonitor}} gets the {{diskSpace}} by monitoring the
> {{DiskDirectoryStats}} of all its persistent {{Regions}}.
> For each region, {{MemberMBeanBridge.addRegion}} adds the
> {{DiskDirectoryStats}} of that region to its {{regionMonitor}}.
> If the region is a {{PartitionedRegion}}, then its {{DiskRegion}} is null
> since the {{DiskRegions}} are on the {{BucketRegions}} so no
> {{DiskDirectoryStats}} are monitored.
> This code in {{MemberMBeanBridge.addRegion}} falls through for
> {{PartitionedRegions}} since {{dr}} is null:
> {noformat}
> DiskRegion dr = l.getDiskRegion();
> if(dr != null){
> for(DirectoryHolder dh:dr.getDirectories()){
> addDirectoryStats(dh.getDiskDirectoryStats());
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-2650) Need an integration test to scan logs for clear-text passwords
[ https://issues.apache.org/jira/browse/GEODE-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-2650: - Labels: observability (was: ) > Need an integration test to scan logs for clear-text passwords > -- > > Key: GEODE-2650 > URL: https://issues.apache.org/jira/browse/GEODE-2650 > Project: Geode > Issue Type: Improvement > Components: gfsh, logging >Reporter: Kevin Duling >Priority: Major > Labels: observability > > This issue keeps creeping up, so it would be good to have a test that scans > log files for any password in the clear. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-2299) Integrate Geode with Grafana for historical and real-time metrics analysis
[ https://issues.apache.org/jira/browse/GEODE-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911817#comment-16911817 ] Aaron Lindsey commented on GEODE-2299: -- With the addition of Micrometer, you can now integrate with different time-series databases which can be read by Grafana or other visualization tools. > Integrate Geode with Grafana for historical and real-time metrics analysis > -- > > Key: GEODE-2299 > URL: https://issues.apache.org/jira/browse/GEODE-2299 > Project: Geode > Issue Type: Improvement > Components: docs, jmx, management, pulse, statistics >Reporter: Christian Tzolov >Priority: Major > > Use Grafana dashboards for querying, visualizing and analysing Apache Geode > statistics archives and JMX real-time metrics. > Solution should provide unified technical stack for visualizing and analysing > both real-time (e.g JMX metrics) and historical (archive files) cluster > statistics. > Initial work: https://github.com/tzolov/geode-dashboard -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-2299) Integrate Geode with Grafana for historical and real-time metrics analysis
[ https://issues.apache.org/jira/browse/GEODE-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-2299: Assignee: Nick Vallely (was: Aaron Lindsey) > Integrate Geode with Grafana for historical and real-time metrics analysis > -- > > Key: GEODE-2299 > URL: https://issues.apache.org/jira/browse/GEODE-2299 > Project: Geode > Issue Type: Improvement > Components: docs, jmx, management, pulse, statistics >Reporter: Christian Tzolov >Assignee: Nick Vallely >Priority: Major > > Use Grafana dashboards for querying, visualizing and analysing Apache Geode > statistics archives and JMX real-time metrics. > Solution should provide unified technical stack for visualizing and analysing > both real-time (e.g JMX metrics) and historical (archive files) cluster > statistics. > Initial work: https://github.com/tzolov/geode-dashboard -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-2299) Integrate Geode with Grafana for historical and real-time metrics analysis
[ https://issues.apache.org/jira/browse/GEODE-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-2299: Assignee: Aaron Lindsey > Integrate Geode with Grafana for historical and real-time metrics analysis > -- > > Key: GEODE-2299 > URL: https://issues.apache.org/jira/browse/GEODE-2299 > Project: Geode > Issue Type: Improvement > Components: docs, jmx, management, pulse, statistics >Reporter: Christian Tzolov >Assignee: Aaron Lindsey >Priority: Major > > Use Grafana dashboards for querying, visualizing and analysing Apache Geode > statistics archives and JMX real-time metrics. > Solution should provide unified technical stack for visualizing and analysing > both real-time (e.g JMX metrics) and historical (archive files) cluster > statistics. > Initial work: https://github.com/tzolov/geode-dashboard -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (GEODE-536) Remove i18n code
[ https://issues.apache.org/jira/browse/GEODE-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey resolved GEODE-536. - Resolution: Not A Problem > Remove i18n code > > > Key: GEODE-536 > URL: https://issues.apache.org/jira/browse/GEODE-536 > Project: Geode > Issue Type: Task > Components: logging >Reporter: Roman Shtykh >Priority: Minor > > i18n is not needed. No plans to support it so far. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (GEODE-536) Remove i18n code
[ https://issues.apache.org/jira/browse/GEODE-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey closed GEODE-536. --- > Remove i18n code > > > Key: GEODE-536 > URL: https://issues.apache.org/jira/browse/GEODE-536 > Project: Geode > Issue Type: Task > Components: logging >Reporter: Roman Shtykh >Priority: Minor > > i18n is not needed. No plans to support it so far. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-1080) Move JettyHelper and related classes to a subproject
[ https://issues.apache.org/jira/browse/GEODE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-1080: - Labels: commons (was: ) > Move JettyHelper and related classes to a subproject > > > Key: GEODE-1080 > URL: https://issues.apache.org/jira/browse/GEODE-1080 > Project: Geode > Issue Type: Sub-task > Components: pulse, rest (admin), rest (dev) >Reporter: Dan Smith >Priority: Major > Labels: commons > > geode-core pulls in jetty because there is some code that bootstraps a > webserver for the REST, admin REST, and pulse web applications. > Those web applications shouldn't be required for all geode-core users, > especially geode clients. This bootstrap code should be moved to a separate > subproject called geode-web-launcher or something like that. The jetty > dependencies should be moved to that project. > The launcher code can implement CacheService and use the service loader > mechanism to be launched when the cache is created. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-1383) LogBanner is missing from rolled log files
[ https://issues.apache.org/jira/browse/GEODE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-1383: Assignee: (was: Kirk Lund) > LogBanner is missing from rolled log files > -- > > Key: GEODE-1383 > URL: https://issues.apache.org/jira/browse/GEODE-1383 > Project: Geode > Issue Type: Bug > Components: logging >Reporter: Jens Deppe >Priority: Major > Labels: LogBanner, observability, starter > > Please add gemfire,heap, xml configuration information to start of every log > file > We often have situations where we have difficulty establishing the > configuration or JVM startup arguments, or XML configuration without multiple > interactions with the customer, even when they've provided logs. When the > customer has rolled over enough, and we overwrite the "parent" first log, we > then lose all of that detail from startup that often proves very helpful. > If it would be easy to incorporate this startup configuration information > into the beginning of each log file as we rollover, we would always have it > and be able to be more productive debugging prod issues and ultimately have > happier users. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-3689) Unable to specify custom log4j configuration file from gfsh
[
https://issues.apache.org/jira/browse/GEODE-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911821#comment-16911821
]
Aaron Lindsey commented on GEODE-3689:
--
[~klund] does the work around splitting out log4j-core into a submodule fix
this issue?
> Unable to specify custom log4j configuration file from gfsh
> ---
>
> Key: GEODE-3689
> URL: https://issues.apache.org/jira/browse/GEODE-3689
> Project: Geode
> Issue Type: Bug
> Components: gfsh, logging
>Reporter: Jens Deppe
>Assignee: Kirk Lund
>Priority: Major
>
> When starting a server with gfsh, it does not honor a log4j configuration
> location by specifying {{--J=-Dlog4j.configurationFile=/path/to/log4j2.xml}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-3689) Unable to specify custom log4j configuration file from gfsh
[
https://issues.apache.org/jira/browse/GEODE-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey updated GEODE-3689:
-
Labels: observability (was: )
> Unable to specify custom log4j configuration file from gfsh
> ---
>
> Key: GEODE-3689
> URL: https://issues.apache.org/jira/browse/GEODE-3689
> Project: Geode
> Issue Type: Bug
> Components: gfsh, logging
>Reporter: Jens Deppe
>Assignee: Kirk Lund
>Priority: Major
> Labels: observability
>
> When starting a server with gfsh, it does not honor a log4j configuration
> location by specifying {{--J=-Dlog4j.configurationFile=/path/to/log4j2.xml}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-1444) Need a gfsh command/tool to analyze customer basic health
[ https://issues.apache.org/jira/browse/GEODE-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-1444: - Component/s: (was: statistics) > Need a gfsh command/tool to analyze customer basic health > - > > Key: GEODE-1444 > URL: https://issues.apache.org/jira/browse/GEODE-1444 > Project: Geode > Issue Type: New Feature > Components: gfsh >Reporter: David Wisler >Priority: Major > > Customers have been increasingly asking for a nice gfsh command that will > assess the basic health of their systems to help stave off at the earliest > time any issues that might soon impact their clusters. > Such a command would greatly increase customer confidence that the system is > indeed operating within healthy parameters. In addition, it could be used by > the Global Support Team to greatly decrease the time spent attempting to > assess such health issues as we generally take the first 30 minutes > attempting to establish such basic health criteria prior to drilling down to > some specific issue. > It is my understanding the most recent Hack Day produced a small prototype of > such a command, created by the Lynn's and others. > Please take this and prioritize this work now that it has some footing. I > believe the benefits of this command would be very evident both externally, > becoming a part of customer runbooks, and internally for our teams trying to > discover Root Cause of many issues. > If you need some emails from customers for this one, let me know and I will > drive that forward. > Such a tool/command could be customized based upon what the customer wants to > monitor via use of the command. This could be configured using properties > and/or xml ultimately, or simply use a basic set of 5-10 statistics which can > be very effective an early indicators of issues impacting the system. > Can we take this prototype and drive it forward? I believe the benefit of > such a command would increase customer confidence greatly. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7164) IntelliJ IDEA 2019 error: the output path is not specified for modules
[ https://issues.apache.org/jira/browse/GEODE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-7164: - Description: When delegating build/run actions to IntelliJ IDEA instead of Gradle, IntelliJ IDEA 2019 fails to build geode with an error similar to the one shown in the screenshot below: !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! h4. Steps to Reproduce: (Tested on IntelliJ IDEA CE versions 2019.1.4 and 2019.2.1) # Make sure Gradle delegation is disabled for build/run ** Instructions for 2019.1.4: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner *** Make sure "Delegate build/run actions to Gradle" is unchecked ** Instructions for 2019.2.1: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle *** Make sure "Build and Run using:" is set to "IntelliJ IDEA" # Clone geode into an empty directory # Follow the instructions [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and build geode using IntelliJ IDEA # Enable Gradle build/run delegation ** Instructions for 2019.1.4: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner *** Check "Delegate build/run actions to Gradle" ** Instructions for 2019.2.1: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle *** Set "Build and Run using:" to "Gradle" # Select "Build Project" from the Build menu to build geode # After the build succeeds, revert the change from step 4 to switch back to the IntelliJ build runner # Repeat step 5 to build the project again # The popup error message shown in the screenshot should show and IntelliJ will not initiate the build was: When delegating build/run actions to the IDE instead of Gradle, IntelliJ IDEA 2019 fails to build geode with an error similar to the one shown in the screenshot below: !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! h4. Steps to Reproduce: (Tested on IntelliJ IDEA CE versions 2019.1.4 and 2019.2.1) # Make sure Gradle delegation is disabled for build/run ** Instructions for 2019.1.4: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner *** Make sure "Delegate build/run actions to Gradle" is unchecked ** Instructions for 2019.2.1: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle *** Make sure "Build and Run using:" is set to "IntelliJ IDEA" # Clone geode into an empty directory # Follow the instructions [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and build geode using IntelliJ IDEA # Enable Gradle build/run delegation ** Instructions for 2019.1.4: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner *** Check "Delegate build/run actions to Gradle" ** Instructions for 2019.2.1: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle *** Set "Build and Run using:" to "Gradle" # Select "Build Project" from the Build menu to build geode # After the build succeeds, revert the change from step 4 to switch back to the IntelliJ build runner # Repeat step 5 to build the project again # The popup error message shown in the screenshot should show and IntelliJ will not initiate the build > IntelliJ IDEA 2019 error: the output path is not specified for modules > -- > > Key: GEODE-7164 > URL: https://issues.apache.org/jira/browse/GEODE-7164 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Attachments: Screen Shot 2019-09-04 at 10.45.47 AM.png > > > When delegating build/run actions to IntelliJ IDEA instead of Gradle, > IntelliJ IDEA 2019 fails to build geode with an error similar to the one > shown in the screenshot below: > !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! > h4. Steps to Reproduce: > (Tested on IntelliJ IDEA CE versions 2019.1.4 and 2019.2.1) > # Make sure Gradle delegation is disabled for build/run > ** Instructions for 2019.1.4: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > | Runner > *** Make sure "Delegate build/run actions to Gradle" is unchecked > ** Instructions for 2019.2.1: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > *** Make sure "Build and Run using:" is set to "IntelliJ IDEA" > # Clone geode into an empty directory > # Follow the instructions > [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and > build geode using IntelliJ IDEA > # Enable Gradle build/run delegation > ** Instructions for 2019.1.4: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle
[jira] [Updated] (GEODE-7164) IntelliJ IDEA 2019 error: the output path is not specified for modules
[ https://issues.apache.org/jira/browse/GEODE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-7164: - Description: IntelliJ IDEA 2019 fails to build geode with an error similar to the one shown in the screenshot below: !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! h4. Steps to Reproduce: (Tested on IntelliJ IDEA CE 2019.1.4) # Make sure Gradle delegation is disabled for build/run ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner ** Make sure "Delegate build/run actions to Gradle" is unchecked # Clone geode into an empty directory # Follow the instructions [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and build geode using IntelliJ IDEA # Enable Gradle build/run delegation ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner ** Check "Delegate build/run actions to Gradle" # Select "Build Project" from the Build menu to build geode # After the build succeeds, revert the change from step 4 by unchecking the "Delegate build/run actions to Gradle" checkbox # Repeat step 5 to build the project again # The popup error message shown in the screenshot should show and IntelliJ will not initiate the build was: IntelliJ IDEA 2019 fails to build geode with an error similar to the one shown in the screenshot below: !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! h3. Steps to Reproduce: # Make sure Gradle delegation is disabled for build/run ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner ** Make sure "Delegate build/run actions to Gradle" is unchecked # Clone geode into an empty directory # Follow the instructions [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and build geode using IntelliJ IDEA # Enable Gradle build/run delegation ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner ** Check "Delegate build/run actions to Gradle" # Select "Build Project" from the Build menu to build geode # After the build succeeds, revert the change from step 4 by unchecking the "Delegate build/run actions to Gradle" checkbox # Repeat step 5 to build the project again # The popup error message shown in the screenshot should show and IntelliJ will not initiate the build > IntelliJ IDEA 2019 error: the output path is not specified for modules > -- > > Key: GEODE-7164 > URL: https://issues.apache.org/jira/browse/GEODE-7164 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Attachments: Screen Shot 2019-09-04 at 10.45.47 AM.png > > > IntelliJ IDEA 2019 fails to build geode with an error similar to the one > shown in the screenshot below: > !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! > h4. Steps to Reproduce: > (Tested on IntelliJ IDEA CE 2019.1.4) > # Make sure Gradle delegation is disabled for build/run > ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | > Runner > ** Make sure "Delegate build/run actions to Gradle" is unchecked > # Clone geode into an empty directory > # Follow the instructions > [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and > build geode using IntelliJ IDEA > # Enable Gradle build/run delegation > ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | > Runner > ** Check "Delegate build/run actions to Gradle" > # Select "Build Project" from the Build menu to build geode > # After the build succeeds, revert the change from step 4 by unchecking the > "Delegate build/run actions to Gradle" checkbox > # Repeat step 5 to build the project again > # The popup error message shown in the screenshot should show and IntelliJ > will not initiate the build -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (GEODE-7164) IntelliJ IDEA 2019 error: the output path is not specified for modules
Aaron Lindsey created GEODE-7164: Summary: IntelliJ IDEA 2019 error: the output path is not specified for modules Key: GEODE-7164 URL: https://issues.apache.org/jira/browse/GEODE-7164 Project: Geode Issue Type: Improvement Reporter: Aaron Lindsey -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7164) IntelliJ IDEA 2019 error: the output path is not specified for modules
[ https://issues.apache.org/jira/browse/GEODE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-7164: - Description: IntelliJ IDEA 2019 fails to build geode with an error similar to the one shown in the screenshot below: !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! h3. Steps to Reproduce: # Make sure Gradle delegation is disabled for build/run ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner ** Make sure "Delegate build/run actions to Gradle" is unchecked # Clone geode into an empty directory # Follow the instructions [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and build geode using IntelliJ IDEA # Enable Gradle build/run delegation ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner ** Check "Delegate build/run actions to Gradle" # Select "Build Project" from the Build menu to build geode # After the build succeeds, revert the change from step 4 by unchecking the "Delegate build/run actions to Gradle" checkbox # Repeat step 5 to build the project again # The popup error message shown in the screenshot should show and IntelliJ will not initiate the build was: IntelliJ IDEA fails to build geode with an error similar to the one shown in the screenshot below: !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! h3. Steps to Reproduce: # Make sure Gradle delegation is disabled for build/run ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner ** Make sure "Delegate build/run actions to Gradle" is unchecked # Clone geode into an empty directory # Follow the instructions [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and build geode using IntelliJ IDEA # Enable Gradle build/run delegation ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner ** Check "Delegate build/run actions to Gradle" # Select "Build Project" from the Build menu to build geode # After the build succeeds, revert the change from step 4 by unchecking the "Delegate build/run actions to Gradle" checkbox # Repeat step 5 to build the project again # The popup error message shown in the screenshot should show and IntelliJ will not initiate the build > IntelliJ IDEA 2019 error: the output path is not specified for modules > -- > > Key: GEODE-7164 > URL: https://issues.apache.org/jira/browse/GEODE-7164 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Priority: Major > Attachments: Screen Shot 2019-09-04 at 10.45.47 AM.png > > > IntelliJ IDEA 2019 fails to build geode with an error similar to the one > shown in the screenshot below: > !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! > h3. Steps to Reproduce: > # Make sure Gradle delegation is disabled for build/run > ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | > Runner > ** Make sure "Delegate build/run actions to Gradle" is unchecked > # Clone geode into an empty directory > # Follow the instructions > [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and > build geode using IntelliJ IDEA > # Enable Gradle build/run delegation > ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | > Runner > ** Check "Delegate build/run actions to Gradle" > # Select "Build Project" from the Build menu to build geode > # After the build succeeds, revert the change from step 4 by unchecking the > "Delegate build/run actions to Gradle" checkbox > # Repeat step 5 to build the project again > # The popup error message shown in the screenshot should show and IntelliJ > will not initiate the build -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-7164) IntelliJ IDEA 2019 error: the output path is not specified for modules
[ https://issues.apache.org/jira/browse/GEODE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-7164: Assignee: Aaron Lindsey > IntelliJ IDEA 2019 error: the output path is not specified for modules > -- > > Key: GEODE-7164 > URL: https://issues.apache.org/jira/browse/GEODE-7164 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Attachments: Screen Shot 2019-09-04 at 10.45.47 AM.png > > > IntelliJ IDEA 2019 fails to build geode with an error similar to the one > shown in the screenshot below: > !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! > h3. Steps to Reproduce: > # Make sure Gradle delegation is disabled for build/run > ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | > Runner > ** Make sure "Delegate build/run actions to Gradle" is unchecked > # Clone geode into an empty directory > # Follow the instructions > [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and > build geode using IntelliJ IDEA > # Enable Gradle build/run delegation > ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | > Runner > ** Check "Delegate build/run actions to Gradle" > # Select "Build Project" from the Build menu to build geode > # After the build succeeds, revert the change from step 4 by unchecking the > "Delegate build/run actions to Gradle" checkbox > # Repeat step 5 to build the project again > # The popup error message shown in the screenshot should show and IntelliJ > will not initiate the build -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7164) IntelliJ IDEA 2019 error: the output path is not specified for modules
[ https://issues.apache.org/jira/browse/GEODE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-7164: - Description: When delegating build/run actions to the IDE instead of Gradle, IntelliJ IDEA 2019 fails to build geode with an error similar to the one shown in the screenshot below: !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! h4. Steps to Reproduce: (Tested on IntelliJ IDEA CE 2019.1.4) # Make sure Gradle delegation is disabled for build/run ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner ** Make sure "Delegate build/run actions to Gradle" is unchecked # Clone geode into an empty directory # Follow the instructions [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and build geode using IntelliJ IDEA # Enable Gradle build/run delegation ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner ** Check "Delegate build/run actions to Gradle" # Select "Build Project" from the Build menu to build geode # After the build succeeds, revert the change from step 4 by unchecking the "Delegate build/run actions to Gradle" checkbox # Repeat step 5 to build the project again # The popup error message shown in the screenshot should show and IntelliJ will not initiate the build was: IntelliJ IDEA 2019 fails to build geode with an error similar to the one shown in the screenshot below: !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! h4. Steps to Reproduce: (Tested on IntelliJ IDEA CE 2019.1.4) # Make sure Gradle delegation is disabled for build/run ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner ** Make sure "Delegate build/run actions to Gradle" is unchecked # Clone geode into an empty directory # Follow the instructions [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and build geode using IntelliJ IDEA # Enable Gradle build/run delegation ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner ** Check "Delegate build/run actions to Gradle" # Select "Build Project" from the Build menu to build geode # After the build succeeds, revert the change from step 4 by unchecking the "Delegate build/run actions to Gradle" checkbox # Repeat step 5 to build the project again # The popup error message shown in the screenshot should show and IntelliJ will not initiate the build > IntelliJ IDEA 2019 error: the output path is not specified for modules > -- > > Key: GEODE-7164 > URL: https://issues.apache.org/jira/browse/GEODE-7164 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Attachments: Screen Shot 2019-09-04 at 10.45.47 AM.png > > > When delegating build/run actions to the IDE instead of Gradle, IntelliJ IDEA > 2019 fails to build geode with an error similar to the one shown in the > screenshot below: > !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! > h4. Steps to Reproduce: > (Tested on IntelliJ IDEA CE 2019.1.4) > # Make sure Gradle delegation is disabled for build/run > ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | > Runner > ** Make sure "Delegate build/run actions to Gradle" is unchecked > # Clone geode into an empty directory > # Follow the instructions > [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and > build geode using IntelliJ IDEA > # Enable Gradle build/run delegation > ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | > Runner > ** Check "Delegate build/run actions to Gradle" > # Select "Build Project" from the Build menu to build geode > # After the build succeeds, revert the change from step 4 by unchecking the > "Delegate build/run actions to Gradle" checkbox > # Repeat step 5 to build the project again > # The popup error message shown in the screenshot should show and IntelliJ > will not initiate the build -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7164) IntelliJ IDEA 2019 error: the output path is not specified for modules
[ https://issues.apache.org/jira/browse/GEODE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-7164: - Description: IntelliJ IDEA fails to build geode with an error similar to the one shown in the screenshot below: !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! h3. Steps to Reproduce: # Make sure Gradle delegation is disabled for build/run ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner ** Make sure "Delegate build/run actions to Gradle" is unchecked # Clone geode into an empty directory # Follow the instructions [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and build geode using IntelliJ IDEA # Enable Gradle build/run delegation ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner ** Check "Delegate build/run actions to Gradle" # Select "Build Project" from the Build menu to build geode # After the build succeeds, revert the change from step 4 by unchecking the "Delegate build/run actions to Gradle" checkbox # Repeat step 5 to build the project again # The popup error message shown in the screenshot should show and IntelliJ will not initiate the build > IntelliJ IDEA 2019 error: the output path is not specified for modules > -- > > Key: GEODE-7164 > URL: https://issues.apache.org/jira/browse/GEODE-7164 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Priority: Major > Attachments: Screen Shot 2019-09-04 at 10.45.47 AM.png > > > IntelliJ IDEA fails to build geode with an error similar to the one shown in > the screenshot below: > !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! > h3. Steps to Reproduce: > # Make sure Gradle delegation is disabled for build/run > ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | > Runner > ** Make sure "Delegate build/run actions to Gradle" is unchecked > # Clone geode into an empty directory > # Follow the instructions > [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and > build geode using IntelliJ IDEA > # Enable Gradle build/run delegation > ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | > Runner > ** Check "Delegate build/run actions to Gradle" > # Select "Build Project" from the Build menu to build geode > # After the build succeeds, revert the change from step 4 by unchecking the > "Delegate build/run actions to Gradle" checkbox > # Repeat step 5 to build the project again > # The popup error message shown in the screenshot should show and IntelliJ > will not initiate the build -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-7164) IntelliJ IDEA 2019 error: the output path is not specified for modules
[
https://issues.apache.org/jira/browse/GEODE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16922773#comment-16922773
]
Aaron Lindsey commented on GEODE-7164:
--
The best solution I've found involves 2 parts:
# Set the Project compiler output as shown in this SO answer:
[https://stackoverflow.com/a/40675201].
# Add "{{inheritOutputDirs = true}}" to the idea plugin configuration in
{{ide.gradle}}. This causes IntelliJ to import gradle sub-projects with the
"Inherit project compile output path" option checked by default. You may need
to reimport gradle projects after making this change if you do not have
auto-import enabled.
> IntelliJ IDEA 2019 error: the output path is not specified for modules
> --
>
> Key: GEODE-7164
> URL: https://issues.apache.org/jira/browse/GEODE-7164
> Project: Geode
> Issue Type: Improvement
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
> Attachments: Screen Shot 2019-09-04 at 10.45.47 AM.png
>
>
> When delegating build/run actions to IntelliJ IDEA instead of Gradle,
> IntelliJ IDEA 2019 fails to build geode with an error similar to the one
> shown in the screenshot below:
> !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298!
> h4. Steps to Reproduce:
> (Tested on IntelliJ IDEA CE versions 2019.1.4 and 2019.2.1)
> # Make sure Gradle delegation is disabled for build/run
> ** Instructions for 2019.1.4:
> *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle
> | Runner
> *** Make sure "Delegate build/run actions to Gradle" is unchecked
> ** Instructions for 2019.2.1:
> *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle
> *** Make sure "Build and Run using:" is set to "IntelliJ IDEA"
> # Clone geode into an empty directory
> # Follow the instructions
> [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and
> build geode using IntelliJ IDEA
> # Enable Gradle build/run delegation
> ** Instructions for 2019.1.4:
> *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle
> | Runner
> *** Check "Delegate build/run actions to Gradle"
> ** Instructions for 2019.2.1:
> *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle
> *** Set "Build and Run using:" to "Gradle"
> # Select "Build Project" from the Build menu to build geode
> # After the build succeeds, revert the change from step 4 to switch back to
> the IntelliJ build runner
> # Repeat step 5 to build the project again
> # The popup error message shown in the screenshot should show and IntelliJ
> will not initiate the build
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-7164) IntelliJ IDEA 2019 error: the output path is not specified for modules
[ https://issues.apache.org/jira/browse/GEODE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-7164: - Attachment: Screen Shot 2019-09-04 at 10.45.47 AM.png > IntelliJ IDEA 2019 error: the output path is not specified for modules > -- > > Key: GEODE-7164 > URL: https://issues.apache.org/jira/browse/GEODE-7164 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Priority: Major > Attachments: Screen Shot 2019-09-04 at 10.45.47 AM.png > > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7164) IntelliJ IDEA 2019 error: the output path is not specified for modules
[ https://issues.apache.org/jira/browse/GEODE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-7164: - Description: When delegating build/run actions to the IDE instead of Gradle, IntelliJ IDEA 2019 fails to build geode with an error similar to the one shown in the screenshot below: !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! h4. Steps to Reproduce: (Tested on IntelliJ IDEA CE 2019.1.4) # Make sure Gradle delegation is disabled for build/run ** Instructions for 2019.1.4: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner *** Make sure "Delegate build/run actions to Gradle" is unchecked ** Instructions for 2019.2.1: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle *** Make sure "Build and Run using:" is set to "IntelliJ IDEA" # Clone geode into an empty directory # Follow the instructions [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and build geode using IntelliJ IDEA # Enable Gradle build/run delegation ** Instructions for 2019.1.4: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner *** Check "Delegate build/run actions to Gradle" ** Instructions for 2019.2.1: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle *** Set "Build and Run using:" to "Gradle" # Select "Build Project" from the Build menu to build geode # After the build succeeds, revert the change from step 4 to switch back to the IntelliJ build runner # Repeat step 5 to build the project again # The popup error message shown in the screenshot should show and IntelliJ will not initiate the build was: When delegating build/run actions to the IDE instead of Gradle, IntelliJ IDEA 2019 fails to build geode with an error similar to the one shown in the screenshot below: !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! h4. Steps to Reproduce: (Tested on IntelliJ IDEA CE 2019.1.4) # Make sure Gradle delegation is disabled for build/run ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner ** Make sure "Delegate build/run actions to Gradle" is unchecked # Clone geode into an empty directory # Follow the instructions [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and build geode using IntelliJ IDEA # Enable Gradle build/run delegation ** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner ** Check "Delegate build/run actions to Gradle" # Select "Build Project" from the Build menu to build geode # After the build succeeds, revert the change from step 4 by unchecking the "Delegate build/run actions to Gradle" checkbox # Repeat step 5 to build the project again # The popup error message shown in the screenshot should show and IntelliJ will not initiate the build > IntelliJ IDEA 2019 error: the output path is not specified for modules > -- > > Key: GEODE-7164 > URL: https://issues.apache.org/jira/browse/GEODE-7164 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Attachments: Screen Shot 2019-09-04 at 10.45.47 AM.png > > > When delegating build/run actions to the IDE instead of Gradle, IntelliJ IDEA > 2019 fails to build geode with an error similar to the one shown in the > screenshot below: > !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! > h4. Steps to Reproduce: > (Tested on IntelliJ IDEA CE 2019.1.4) > # Make sure Gradle delegation is disabled for build/run > ** Instructions for 2019.1.4: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > | Runner > *** Make sure "Delegate build/run actions to Gradle" is unchecked > ** Instructions for 2019.2.1: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > *** Make sure "Build and Run using:" is set to "IntelliJ IDEA" > # Clone geode into an empty directory > # Follow the instructions > [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and > build geode using IntelliJ IDEA > # Enable Gradle build/run delegation > ** Instructions for 2019.1.4: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > | Runner > *** Check "Delegate build/run actions to Gradle" > ** Instructions for 2019.2.1: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > *** Set "Build and Run using:" to "Gradle" > # Select "Build Project" from the Build menu to build geode > # After the build succeeds, revert the change from step 4 to switch back to > the IntelliJ build runner > # Repeat step 5 to build the project again > # The
[jira] [Updated] (GEODE-7164) IntelliJ IDEA 2019 error: the output path is not specified for modules
[ https://issues.apache.org/jira/browse/GEODE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-7164: - Description: When delegating build/run actions to the IDE instead of Gradle, IntelliJ IDEA 2019 fails to build geode with an error similar to the one shown in the screenshot below: !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! h4. Steps to Reproduce: (Tested on IntelliJ IDEA CE versions 2019.1.4 and 2019.2.1) # Make sure Gradle delegation is disabled for build/run ** Instructions for 2019.1.4: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner *** Make sure "Delegate build/run actions to Gradle" is unchecked ** Instructions for 2019.2.1: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle *** Make sure "Build and Run using:" is set to "IntelliJ IDEA" # Clone geode into an empty directory # Follow the instructions [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and build geode using IntelliJ IDEA # Enable Gradle build/run delegation ** Instructions for 2019.1.4: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner *** Check "Delegate build/run actions to Gradle" ** Instructions for 2019.2.1: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle *** Set "Build and Run using:" to "Gradle" # Select "Build Project" from the Build menu to build geode # After the build succeeds, revert the change from step 4 to switch back to the IntelliJ build runner # Repeat step 5 to build the project again # The popup error message shown in the screenshot should show and IntelliJ will not initiate the build was: When delegating build/run actions to the IDE instead of Gradle, IntelliJ IDEA 2019 fails to build geode with an error similar to the one shown in the screenshot below: !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! h4. Steps to Reproduce: (Tested on IntelliJ IDEA CE 2019.1.4) # Make sure Gradle delegation is disabled for build/run ** Instructions for 2019.1.4: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner *** Make sure "Delegate build/run actions to Gradle" is unchecked ** Instructions for 2019.2.1: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle *** Make sure "Build and Run using:" is set to "IntelliJ IDEA" # Clone geode into an empty directory # Follow the instructions [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and build geode using IntelliJ IDEA # Enable Gradle build/run delegation ** Instructions for 2019.1.4: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle | Runner *** Check "Delegate build/run actions to Gradle" ** Instructions for 2019.2.1: *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle *** Set "Build and Run using:" to "Gradle" # Select "Build Project" from the Build menu to build geode # After the build succeeds, revert the change from step 4 to switch back to the IntelliJ build runner # Repeat step 5 to build the project again # The popup error message shown in the screenshot should show and IntelliJ will not initiate the build > IntelliJ IDEA 2019 error: the output path is not specified for modules > -- > > Key: GEODE-7164 > URL: https://issues.apache.org/jira/browse/GEODE-7164 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Attachments: Screen Shot 2019-09-04 at 10.45.47 AM.png > > > When delegating build/run actions to the IDE instead of Gradle, IntelliJ IDEA > 2019 fails to build geode with an error similar to the one shown in the > screenshot below: > !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! > h4. Steps to Reproduce: > (Tested on IntelliJ IDEA CE versions 2019.1.4 and 2019.2.1) > # Make sure Gradle delegation is disabled for build/run > ** Instructions for 2019.1.4: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > | Runner > *** Make sure "Delegate build/run actions to Gradle" is unchecked > ** Instructions for 2019.2.1: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > *** Make sure "Build and Run using:" is set to "IntelliJ IDEA" > # Clone geode into an empty directory > # Follow the instructions > [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and > build geode using IntelliJ IDEA > # Enable Gradle build/run delegation > ** Instructions for 2019.1.4: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > | Runner > *** Check "Delegate
[jira] [Updated] (GEODE-7164) IntelliJ IDEA 2019 error: the output path is not specified for modules
[ https://issues.apache.org/jira/browse/GEODE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-7164: - Attachment: Screen Shot 2019-09-04 at 10.51.04 AM.png > IntelliJ IDEA 2019 error: the output path is not specified for modules > -- > > Key: GEODE-7164 > URL: https://issues.apache.org/jira/browse/GEODE-7164 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Attachments: Screen Shot 2019-09-04 at 10.45.47 AM.png, Screen Shot > 2019-09-04 at 10.51.04 AM.png > > > When delegating build/run actions to IntelliJ IDEA instead of Gradle, > IntelliJ IDEA 2019 fails to build geode with an error similar to the one > shown in the screenshot below: > !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! > h4. Steps to Reproduce: > (Tested on IntelliJ IDEA CE versions 2019.1.4 and 2019.2.1) > # Make sure Gradle delegation is disabled for build/run > ** Instructions for 2019.1.4: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > | Runner > *** Make sure "Delegate build/run actions to Gradle" is unchecked > ** Instructions for 2019.2.1: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > *** Make sure "Build and Run using:" is set to "IntelliJ IDEA" > # Clone geode into an empty directory > # Follow the instructions > [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and > build geode using IntelliJ IDEA > # Enable Gradle build/run delegation > ** Instructions for 2019.1.4: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > | Runner > *** Check "Delegate build/run actions to Gradle" > ** Instructions for 2019.2.1: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > *** Set "Build and Run using:" to "Gradle" > # Select "Build Project" from the Build menu to build geode > # After the build succeeds, revert the change from step 4 to switch back to > the IntelliJ build runner > # Repeat step 5 to build the project again > # The popup error message shown in the screenshot should show and IntelliJ > will not initiate the build -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (GEODE-7164) IntelliJ IDEA 2019 error: the output path is not specified for modules
[
https://issues.apache.org/jira/browse/GEODE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16922773#comment-16922773
]
Aaron Lindsey edited comment on GEODE-7164 at 9/4/19 7:38 PM:
--
I was able to reproduce the "output path not specified for modules..." issue on
IntelliJ IDEA CE versions 2019.1.4 and 2019.2.1 (see description for details).
The issue seems to occur when IntelliJ imports Gradle sub-projects as modules
that have "Use module compile output path" checked but don't have an Output
path specified, as shown in the screenshot below:
!Screen Shot 2019-09-04 at 10.51.04 AM.png|width=809,height=501!
The best solution I've found involves 2 parts:
# Set the Project compiler output as shown in this SO answer:
[https://stackoverflow.com/a/40675201].
# Add "{{inheritOutputDirs = true}}" to the idea plugin configuration in
{{ide.gradle}}. This causes IntelliJ to import gradle sub-projects with the
"Inherit project compile output path" option checked by default. You may need
to reimport gradle projects after making this change if you do not have
auto-import enabled.
was (Author: aaronlindsey):
The best solution I've found involves 2 parts:
# Set the Project compiler output as shown in this SO answer:
[https://stackoverflow.com/a/40675201].
# Add "{{inheritOutputDirs = true}}" to the idea plugin configuration in
{{ide.gradle}}. This causes IntelliJ to import gradle sub-projects with the
"Inherit project compile output path" option checked by default. You may need
to reimport gradle projects after making this change if you do not have
auto-import enabled.
> IntelliJ IDEA 2019 error: the output path is not specified for modules
> --
>
> Key: GEODE-7164
> URL: https://issues.apache.org/jira/browse/GEODE-7164
> Project: Geode
> Issue Type: Improvement
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
> Attachments: Screen Shot 2019-09-04 at 10.45.47 AM.png, Screen Shot
> 2019-09-04 at 10.51.04 AM.png
>
>
> When delegating build/run actions to IntelliJ IDEA instead of Gradle,
> IntelliJ IDEA 2019 fails to build geode with an error similar to the one
> shown in the screenshot below:
> !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298!
> h4. Steps to Reproduce:
> (Tested on IntelliJ IDEA CE versions 2019.1.4 and 2019.2.1)
> # Make sure Gradle delegation is disabled for build/run
> ** Instructions for 2019.1.4:
> *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle
> | Runner
> *** Make sure "Delegate build/run actions to Gradle" is unchecked
> ** Instructions for 2019.2.1:
> *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle
> *** Make sure "Build and Run using:" is set to "IntelliJ IDEA"
> # Clone geode into an empty directory
> # Follow the instructions
> [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and
> build geode using IntelliJ IDEA
> # Enable Gradle build/run delegation
> ** Instructions for 2019.1.4:
> *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle
> | Runner
> *** Check "Delegate build/run actions to Gradle"
> ** Instructions for 2019.2.1:
> *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle
> *** Set "Build and Run using:" to "Gradle"
> # Select "Build Project" from the Build menu to build geode
> # After the build succeeds, revert the change from step 4 to switch back to
> the IntelliJ build runner
> # Repeat step 5 to build the project again
> # The popup error message shown in the screenshot should show and IntelliJ
> will not initiate the build
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (GEODE-7164) IntelliJ IDEA 2019 error: the output path is not specified for modules
[ https://issues.apache.org/jira/browse/GEODE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey resolved GEODE-7164. -- Resolution: Fixed > IntelliJ IDEA 2019 error: the output path is not specified for modules > -- > > Key: GEODE-7164 > URL: https://issues.apache.org/jira/browse/GEODE-7164 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Attachments: Screen Shot 2019-09-04 at 10.45.47 AM.png, Screen Shot > 2019-09-04 at 10.51.04 AM.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > When delegating build/run actions to IntelliJ IDEA instead of Gradle, > IntelliJ IDEA 2019 fails to build geode with an error similar to the one > shown in the screenshot below: > !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! > h4. Steps to Reproduce: > (Tested on IntelliJ IDEA CE versions 2019.1.4 and 2019.2.1) > # Make sure Gradle delegation is disabled for build/run > ** Instructions for 2019.1.4: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > | Runner > *** Make sure "Delegate build/run actions to Gradle" is unchecked > ** Instructions for 2019.2.1: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > *** Make sure "Build and Run using:" is set to "IntelliJ IDEA" > # Clone geode into an empty directory > # Follow the instructions > [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and > build geode using IntelliJ IDEA > # Enable Gradle build/run delegation > ** Instructions for 2019.1.4: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > | Runner > *** Check "Delegate build/run actions to Gradle" > ** Instructions for 2019.2.1: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > *** Set "Build and Run using:" to "Gradle" > # Select "Build Project" from the Build menu to build geode > # After the build succeeds, revert the change from step 4 to switch back to > the IntelliJ build runner > # Repeat step 5 to build the project again > # The popup error message shown in the screenshot should show and IntelliJ > will not initiate the build -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7184) Add function executions timer
[ https://issues.apache.org/jira/browse/GEODE-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-7184: - Description: Developers oftentimes deploy their own functions to the system to enable decorator pattern for caching to add information to specific key/value pairs. In doing so, they can introduce bottlenecks into the system where server-side functions can cause issues or make things slower than intended. We want a way that users can view functions that they create, and see what the average execution time looks like. * *Meter Type*: Timer * *Name*: geode.function.executions * *Description*: TBD * *Tags*: , function (getId on function, if DNE present getClass.getname of deployed function), succeeded (true/false) h3. Acceptance Criteria *Meter creation/deletion*: Create meter on function deployment/register, delete on un-deploy/unregister of a function or re-deploy of the same function *Measurement*: On an individual server, start the timer when a **USER** deployed function is invoked, and stop the timer when the user function completes OR errors. If it throws a Function Execution or another error then the tag function.isSuccessful=false Details on Functions and their execution: [https://gemfire.docs.pivotal.io/97/geode/developing/function_exec/function_execution.html] h3. Scenarios *Scenario: The timers are created when the function is deployed* Given a user deployed function with ID functionToTime exists on a cluster with 1 locator/1 server And functionToTime has not been triggered Then the server has the following timer: - name: geode.function.executions - tag: id = functionToTime - tag: succeeded = true - count = 0 - totalTime = 0 And the server has the following timer: - name: geode.function.executions - tag: id = functionToTime - tag: succeeded = false - count = 0 - totalTime = 0 *Scenario: Successful singular function execution* Given a user deployed function with ID functionToTime (that waits for 5 seconds) exists on a cluster with 1 locator/1 server When functionToTime is triggered using gfsh command: "execute function --id=functionToTime" And the function completes without error Then the server has the following timer: - name: geode.function.executions - tag: id = functionToTime - tag: succeeded = true - count = 1 - totalTime >= 5,000,000,000ns *Scenario: Singular function execution with Any Exception* Given a user deployed function with ID functionToTime exists on a cluster with 1 locator /1 server When that function execution is triggered using gfsh command: "execute function --id=functionToTime" And the function exits with a Any exception error after running for 5 seconds Then the server has the following timer: - name: geode.function.executions - tag: id = functionToTime - tag: succeeded = false - count = 1 - totalTime >= 5,000,000,000ns *Scenario: Function execution on multi-servers* Given a user deployed function with ID functionToTime (that waits for 5 seconds) is deployed with 'onRegion' to a replicate region named RR1 And exists on both servers of a cluster with 1 locator (named L1) as well as 2 servers (named S1,S2) When that function execution is triggered against that replicate region using gfsh command: "execute function --id=functionToTime --region=RR1" Then one server has the following timer: - name: geode.function.executions - tag: id = functionToTime - tag: succeeded = true - count = 1 - totalTime >= 5,000,000,000ns And the other server has the following timer: - name: geode.cache.function.executions - tag: id = functionToTime - tag: succeeded = true - count = 0 - totalTime = 0}} *Scenario: Function execution multiple times* Given a user deployed function with ID functionToTime (that waits for 5 seconds) is deployed with 'onRegion' to a replicate region And exists on both servers of a cluster with 1 locator (named L1) as well as 2 servers (named S1,S2) When that function execution is triggered 10 times against that replicate region using gfsh command: "execute function --id=functionToTime --region=RR1 --members=S1" Then S1 has the following timer: - name: geode.function.executions - tag:id = functionToTime - tag:succeeded = true - count = 10 And S2 has the following timer: - name: geode.cache.function.executions - tag:id = functionToTime - tag:succeeded = true - count = 0 *Scenario: The timers are deleted when the function is undeployed* Given a user deployed function with ID functionToTime exists on a cluster with 1 locator/1 server When the user undeploys the function by `undeploy --jar=.jar` Then the server does not have any timer with the following name and tag: - name: geode.function.executions - tag: id = functionToTime *Scenario: Non-user deployed functions shouldn't count* Given a cluster with 1 locator/1 server When the system starts up the cache with internal functions
[jira] [Assigned] (GEODE-7184) Add function executions timer
[ https://issues.apache.org/jira/browse/GEODE-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-7184: Assignee: Aaron Lindsey > Add function executions timer > - > > Key: GEODE-7184 > URL: https://issues.apache.org/jira/browse/GEODE-7184 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > > Developers oftentimes deploy their own functions to the system to enable > decorator pattern for caching to add information to specific key/value pairs. > In doing so, they can introduce bottlenecks into the system where server-side > functions can cause issues or make things slower than intended. We want a way > that users can view functions that they create, and see what the average > execution time looks like. > * *Meter Type*: Timer > * *Name*: geode.function.executions > * *Description*: TBD > * *Tags*: , function (getId on function, if DNE present > getClass.getname of deployed function), succeeded (true/false) > h3. Acceptance Criteria > *Meter creation/deletion*: Create meter on function deployment/register, > delete on un-deploy/unregister of a function or re-deploy of the same function > *Measurement*: On an individual server, start the timer when a **USER** > deployed function is invoked, and stop the timer when the user function > completes OR errors. If it throws a Function Execution or another error then > the tag function.isSuccessful=false > Details on Functions and their execution: > [https://gemfire.docs.pivotal.io/97/geode/developing/function_exec/function_execution.html] > h3. Scenarios > *Scenario: The timers are created when the function is deployed* > Given a user deployed function with ID functionToTime exists on a cluster > with 1 locator/1 server > And functionToTime has not been triggered > Then the server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = true > - count = 0 > - totalTime = 0 > And the server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = false > - count = 0 > - totalTime = 0 > *Scenario: Successful singular function execution* > Given a user deployed function with ID functionToTime (that waits for 5 > seconds) exists on a cluster with 1 locator/1 server > When functionToTime is triggered using gfsh command: "execute function > --id=functionToTime" > And the function completes without error > Then the server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = true > - count = 1 > - totalTime >= 5,000,000,000ns > *Scenario: Singular function execution with Any Exception* > Given a user deployed function with ID functionToTime exists on a cluster > with 1 locator /1 server > When that function execution is triggered using gfsh command: "execute > function --id=functionToTime" > And the function exits with a Any exception error after running for 5 seconds > Then the server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = false > - count = 1 > - totalTime >= 5,000,000,000ns > *Scenario: Function execution on multi-servers* > Given a user deployed function with ID functionToTime (that waits for 5 > seconds) is deployed with 'onRegion' to a replicate region named RR1 > And exists on both servers of a cluster with 1 locator (named L1) as well as > 2 servers (named S1,S2) > When that function execution is triggered against that replicate region > using gfsh command: "execute function --id=functionToTime --region=RR1" > Then one server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = true > - count = 1 > - totalTime >= 5,000,000,000ns > And the other server has the following timer: > - name: geode.cache.function.executions > - tag: id = functionToTime > - tag: succeeded = true > - count = 0 > - totalTime = 0}} > *Scenario: Function execution multiple times* > Given a user deployed function with ID functionToTime (that waits for 5 > seconds) is deployed with 'onRegion' to a replicate region > And exists on both servers of a cluster with 1 locator (named L1) as well as > 2 servers (named S1,S2) > When that function execution is triggered 10 times against that replicate > region using gfsh command: "execute function --id=functionToTime --region=RR1 > --members=S1" > Then S1 has the following timer: > - name: geode.function.executions > - tag:id = functionToTime > - tag:succeeded = true > - count = 10 > And S2 has the following timer: > - name: geode.cache.function.executions > - tag:id = functionToTime > - tag:succeeded =
[jira] [Created] (GEODE-7184) Add function executions timer
Aaron Lindsey created GEODE-7184: Summary: Add function executions timer Key: GEODE-7184 URL: https://issues.apache.org/jira/browse/GEODE-7184 Project: Geode Issue Type: Improvement Reporter: Aaron Lindsey Developers oftentimes deploy their own functions to the system to enable decorator pattern for caching to add information to specific key/value pairs. In doing so, they can introduce bottlenecks into the system where server-side functions can cause issues or make things slower than intended. We want a way that users can view functions that they create, and see what the average execution time looks like. * *Meter Type*: Timer * *Name*: geode.function.executions * *Description*: TBD * *Tags*: , function (getId on function, if DNE present getClass.getname of deployed function), succeeded (true/false) h3. Acceptance Criteria *Meter creation/deletion*: Create meter on function deployment/register, delete on un-deploy/unregister of a function or re-deploy of the same function *Measurement*: On an individual server, start the timer when a **USER** deployed function is invoked, and stop the timer when the user function completes OR errors. If it throws a Function Execution or another error then the tag function.isSuccessful=false Details on Functions and their execution: [https://gemfire.docs.pivotal.io/97/geode/developing/function_exec/function_execution.html] *Scenario: The timers are created when the function is deployed* Given a user deployed function with ID functionToTime exists on a cluster with 1 locator/1 server And functionToTime has not been triggered Then the server has the following timer: - name: geode.function.executions - tag: id = functionToTime - tag: succeeded = true - count = 0 - totalTime = 0 And the server has the following timer: - name: geode.function.executions - tag: id = functionToTime - tag: succeeded = false - count = 0 - totalTime = 0 *Scenario: Successful singular function execution* Given a user deployed function with ID functionToTime (that waits for 5 seconds) exists on a cluster with 1 locator/1 server When functionToTime is triggered using gfsh command: "execute function --id=functionToTime" And the function completes without error Then the server has the following timer: - name: geode.function.executions - tag: id = functionToTime - tag: succeeded = true - count = 1 - totalTime >= 5,000,000,000ns *Scenario: Singular function execution with Any Exception* Given a user deployed function with ID functionToTime exists on a cluster with 1 locator /1 server When that function execution is triggered using gfsh command: "execute function --id=functionToTime" And the function exits with a Any exception error after running for 5 seconds Then the server has the following timer: - name: geode.function.executions - tag: id = functionToTime - tag: succeeded = false - count = 1 - totalTime >= 5,000,000,000ns *Scenario: Function execution on multi-servers* Given a user deployed function with ID functionToTime (that waits for 5 seconds) is deployed with 'onRegion' to a replicate region named RR1 And exists on both servers of a cluster with 1 locator (named L1) as well as 2 servers (named S1,S2) When that function execution is triggered against that replicate region using gfsh command: "execute function --id=functionToTime --region=RR1" Then one server has the following timer: - name: geode.function.executions - tag: id = functionToTime - tag: succeeded = true - count = 1 - totalTime >= 5,000,000,000ns And the other server has the following timer: - name: geode.cache.function.executions - tag: id = functionToTime - tag: succeeded = true - count = 0 - totalTime = 0}} *Scenario: Function execution multiple times* Given a user deployed function with ID functionToTime (that waits for 5 seconds) is deployed with 'onRegion' to a replicate region And exists on both servers of a cluster with 1 locator (named L1) as well as 2 servers (named S1,S2) When that function execution is triggered 10 times against that replicate region using gfsh command: "execute function --id=functionToTime --region=RR1 --members=S1" Then S1 has the following timer: - name: geode.function.executions - tag:id = functionToTime - tag:succeeded = true - count = 10 And S2 has the following timer: - name: geode.cache.function.executions - tag:id = functionToTime - tag:succeeded = true - count = 0 *Scenario: The timers are deleted when the function is undeployed* Given a user deployed function with ID functionToTime exists on a cluster with 1 locator/1 server When the user undeploys the function by `undeploy --jar=.jar` Then the server does not have any timer with the following name and tag: - name: geode.function.executions - tag: id = functionToTime *Scenario: Non-user deployed functions shouldn't count* Given a
[jira] [Updated] (GEODE-3863) EmbeddedPulseRule does not cleanup in some instances
[
https://issues.apache.org/jira/browse/GEODE-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey updated GEODE-3863:
-
Labels: observability (was: )
> EmbeddedPulseRule does not cleanup in some instances
>
>
> Key: GEODE-3863
> URL: https://issues.apache.org/jira/browse/GEODE-3863
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Jens Deppe
>Priority: Major
> Labels: observability
>
> We're using this rule in a couple of places in an inconsistent way. The rule
> should really be called 'StandalonePulseRule' because it only works correctly
> when Pulse is *not* running in embedded mode.
> Specifically, in {{PulseSecurityTest}} we're interacting with Pulse embedded
> in a locator. The rule is used in this test to 'cleanup' various backend
> structures. However, in this context the {{Repository}} is instantiated by
> both Pulse (via Jetty and it's classloader) as well as by the test itself
> (different classloader). So the rule doesn't actually end up cleaning up the
> real (Jetty/Pulse embedded) {{Repository}}.
> I'd suggest the rule be renamed to {{StandalonePulseRule}} and a new
> {{EmbeddedPulseRule}} should do cleanup via Pulse endpoints and not try and
> 'reach around' for its cleanup.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-3863) EmbeddedPulseRule does not cleanup in some instances
[
https://issues.apache.org/jira/browse/GEODE-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey updated GEODE-3863:
-
Priority: Trivial (was: Major)
> EmbeddedPulseRule does not cleanup in some instances
>
>
> Key: GEODE-3863
> URL: https://issues.apache.org/jira/browse/GEODE-3863
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Jens Deppe
>Priority: Trivial
> Labels: observability
>
> We're using this rule in a couple of places in an inconsistent way. The rule
> should really be called 'StandalonePulseRule' because it only works correctly
> when Pulse is *not* running in embedded mode.
> Specifically, in {{PulseSecurityTest}} we're interacting with Pulse embedded
> in a locator. The rule is used in this test to 'cleanup' various backend
> structures. However, in this context the {{Repository}} is instantiated by
> both Pulse (via Jetty and it's classloader) as well as by the test itself
> (different classloader). So the rule doesn't actually end up cleaning up the
> real (Jetty/Pulse embedded) {{Repository}}.
> I'd suggest the rule be renamed to {{StandalonePulseRule}} and a new
> {{EmbeddedPulseRule}} should do cleanup via Pulse endpoints and not try and
> 'reach around' for its cleanup.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (GEODE-4488) Remove singleton calls from all tests in org.apache.geode.management.internal.unsafe
[ https://issues.apache.org/jira/browse/GEODE-4488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-4488: Assignee: Kirk Lund > Remove singleton calls from all tests in > org.apache.geode.management.internal.unsafe > > > Key: GEODE-4488 > URL: https://issues.apache.org/jira/browse/GEODE-4488 > Project: Geode > Issue Type: Sub-task > Components: jmx, tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > These tests in org.apache.geode.management.internal.unsafe invoke singleton > getters. > GemFireCacheImpl.getInstance(): > * ReadOpFileAccessControllerJUnitTest -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-4488) Remove singleton calls from all tests in org.apache.geode.management.internal.unsafe
[ https://issues.apache.org/jira/browse/GEODE-4488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927055#comment-16927055 ] Aaron Lindsey commented on GEODE-4488: -- [~klund] it looks like this might be done already. Is this still an issue? > Remove singleton calls from all tests in > org.apache.geode.management.internal.unsafe > > > Key: GEODE-4488 > URL: https://issues.apache.org/jira/browse/GEODE-4488 > Project: Geode > Issue Type: Sub-task > Components: jmx, tests >Reporter: Kirk Lund >Priority: Major > > These tests in org.apache.geode.management.internal.unsafe invoke singleton > getters. > GemFireCacheImpl.getInstance(): > * ReadOpFileAccessControllerJUnitTest -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-4837) Remove unneeded JNA code
[ https://issues.apache.org/jira/browse/GEODE-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-4837: Assignee: Aaron Lindsey > Remove unneeded JNA code > > > Key: GEODE-4837 > URL: https://issues.apache.org/jira/browse/GEODE-4837 > Project: Geode > Issue Type: Improvement > Components: core, gfsh, statistics >Reporter: Jens Deppe >Assignee: Aaron Lindsey >Priority: Major > > We have quite a bit of JNA code but it seems that a lot of it is unused now. > Let's clean that up so we only keep what's actually being run. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-4837) Remove unneeded JNA code
[ https://issues.apache.org/jira/browse/GEODE-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-4837: Assignee: Jens Deppe (was: Aaron Lindsey) > Remove unneeded JNA code > > > Key: GEODE-4837 > URL: https://issues.apache.org/jira/browse/GEODE-4837 > Project: Geode > Issue Type: Improvement > Components: core, gfsh, statistics >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > We have quite a bit of JNA code but it seems that a lot of it is unused now. > Let's clean that up so we only keep what's actually being run. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-4837) Remove unneeded JNA code
[ https://issues.apache.org/jira/browse/GEODE-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-4837: - Component/s: (was: statistics) > Remove unneeded JNA code > > > Key: GEODE-4837 > URL: https://issues.apache.org/jira/browse/GEODE-4837 > Project: Geode > Issue Type: Improvement > Components: core, gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > We have quite a bit of JNA code but it seems that a lot of it is unused now. > Let's clean that up so we only keep what's actually being run. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-4837) Remove unneeded JNA code
[ https://issues.apache.org/jira/browse/GEODE-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927070#comment-16927070 ] Aaron Lindsey commented on GEODE-4837: -- [~jens.deppe], could you specify which classes contain the unused code and address Alberto's question? > Remove unneeded JNA code > > > Key: GEODE-4837 > URL: https://issues.apache.org/jira/browse/GEODE-4837 > Project: Geode > Issue Type: Improvement > Components: core, gfsh, statistics >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > We have quite a bit of JNA code but it seems that a lot of it is unused now. > Let's clean that up so we only keep what's actually being run. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-5790) gfsh command alter runtime --log-level has no effect
[
https://issues.apache.org/jira/browse/GEODE-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927079#comment-16927079
]
Aaron Lindsey commented on GEODE-5790:
--
{{It looks like there is a DUnit test that uses this option:
geode/geode-web/src/distributedTest/java/org/apache/geode/management/internal/cli/commands/AlterRuntimeCommandDUnitTest.java}}
> gfsh command alter runtime --log-level has no effect
>
>
> Key: GEODE-5790
> URL: https://issues.apache.org/jira/browse/GEODE-5790
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> The gfsh command alter runtime --log-level has no effect. It looks to me like
> this option was never implemented in the code.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-4173) Destroy entry fails on size calculation in eviction to disk flow
[ https://issues.apache.org/jira/browse/GEODE-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-4173: - Component/s: (was: statistics) > Destroy entry fails on size calculation in eviction to disk flow > -- > > Key: GEODE-4173 > URL: https://issues.apache.org/jira/browse/GEODE-4173 > Project: Geode > Issue Type: Bug > Components: core, eviction >Reporter: Igor Barchak >Priority: Major > Fix For: 1.3.0 > > > We get exception like below , geode 1.2 and 1.3, while sending load of > destroy requests to entries in a flow where some of them were evicted to > disk > info 2017/12/26 14:45:20.788 IST illin3964-pwinfo1 Processor66> tid=0x178] Unexpected exception during function execution on > local node Partitioned Region > org.apache.geode.InternalGemFireError: Bucket > BucketRegion[path='/__PR/_B__PWINFO__1_8;serial=2943;primary=false] size > (-275) negative after applying delta of -4213 > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.BucketRegion.updateBucketMemoryStats(BucketRegion.java:2294) >at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' in > org.apache.geode.internal.cache.BucketRegion.updateBucket2Size(BucketRegion.java:2282) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.BucketRegion.updateSizeOnRemove(BucketRegion.java:2154) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.AbstractRegionMap.destroyEntry(AbstractRegionMap.java:3098) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1424) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6452) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6426) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.BucketRegion.basicDestroy(BucketRegion.java:1177) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.DestroyOperation$DestroyMessage.operateOnRegion(DestroyOperation.java:87) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1190) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.process(DistributedCacheOperation.java:1091) -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-4494) Remove singleton calls from all tests in org.apache.geode.management.internal.beans
[ https://issues.apache.org/jira/browse/GEODE-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-4494: Assignee: Kirk Lund > Remove singleton calls from all tests in > org.apache.geode.management.internal.beans > --- > > Key: GEODE-4494 > URL: https://issues.apache.org/jira/browse/GEODE-4494 > Project: Geode > Issue Type: Sub-task > Components: jmx, tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > These tests in org.apache.geode.management.internal.beans invoke singleton > getters. > GemFireCacheImpl.setInstanceForTests(GemFireCacheImpl): > * DistributedSystemBridgeJUnitTest -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-4494) Remove singleton calls from all tests in org.apache.geode.management.internal.beans
[ https://issues.apache.org/jira/browse/GEODE-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927056#comment-16927056 ] Aaron Lindsey commented on GEODE-4494: -- [~klund] it looks like this might be done already. Is this still an issue? > Remove singleton calls from all tests in > org.apache.geode.management.internal.beans > --- > > Key: GEODE-4494 > URL: https://issues.apache.org/jira/browse/GEODE-4494 > Project: Geode > Issue Type: Sub-task > Components: jmx, tests >Reporter: Kirk Lund >Priority: Major > > These tests in org.apache.geode.management.internal.beans invoke singleton > getters. > GemFireCacheImpl.setInstanceForTests(GemFireCacheImpl): > * DistributedSystemBridgeJUnitTest -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-5790) gfsh command alter runtime --log-level has no effect
[ https://issues.apache.org/jira/browse/GEODE-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-5790: - Component/s: (was: logging) > gfsh command alter runtime --log-level has no effect > > > Key: GEODE-5790 > URL: https://issues.apache.org/jira/browse/GEODE-5790 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > The gfsh command alter runtime --log-level has no effect. It looks to me like > this option was never implemented in the code. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-4173) Destroy entry fails on size calculation in eviction to disk flow
[ https://issues.apache.org/jira/browse/GEODE-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927004#comment-16927004 ] Aaron Lindsey commented on GEODE-4173: -- Removing statistics component as this is more of an issue with BucketRegion itself rather than statistics. > Destroy entry fails on size calculation in eviction to disk flow > -- > > Key: GEODE-4173 > URL: https://issues.apache.org/jira/browse/GEODE-4173 > Project: Geode > Issue Type: Bug > Components: core, eviction >Reporter: Igor Barchak >Priority: Major > Fix For: 1.3.0 > > > We get exception like below , geode 1.2 and 1.3, while sending load of > destroy requests to entries in a flow where some of them were evicted to > disk > info 2017/12/26 14:45:20.788 IST illin3964-pwinfo1 Processor66> tid=0x178] Unexpected exception during function execution on > local node Partitioned Region > org.apache.geode.InternalGemFireError: Bucket > BucketRegion[path='/__PR/_B__PWINFO__1_8;serial=2943;primary=false] size > (-275) negative after applying delta of -4213 > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.BucketRegion.updateBucketMemoryStats(BucketRegion.java:2294) >at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' in > org.apache.geode.internal.cache.BucketRegion.updateBucket2Size(BucketRegion.java:2282) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.BucketRegion.updateSizeOnRemove(BucketRegion.java:2154) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.AbstractRegionMap.destroyEntry(AbstractRegionMap.java:3098) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1424) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6452) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6426) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.BucketRegion.basicDestroy(BucketRegion.java:1177) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.DestroyOperation$DestroyMessage.operateOnRegion(DestroyOperation.java:87) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1190) > at Remote Member '10.232.147.91(illin3964-pwinfo2:26687):40008' > in > org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.process(DistributedCacheOperation.java:1091) -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-4687) Impossible to execute query on some specific member in Pulse DataBrowser
[
https://issues.apache.org/jira/browse/GEODE-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey updated GEODE-4687:
-
Priority: Minor (was: Major)
> Impossible to execute query on some specific member in Pulse DataBrowser
>
>
> Key: GEODE-4687
> URL: https://issues.apache.org/jira/browse/GEODE-4687
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Vadim Lotarev
>Priority: Minor
> Labels: starter
> Attachments: screenshot.91.jpg, screenshot.92.jpg
>
>
> It is impossible to execute query on some specific member. The reason is in
> difference between member ID values used in Pulse and
> {{org.apache.geode.management.internal.beans.QueryDataFunction}} class. For
> example, Pulse passes the following ID:
> {{VLOTAREV(inventory-vlotarev-40405:11780):1026}} but
> {{QueryDataFunction}} tries to compare it with the following value:
> {{192.168.63.37(inventory-vlotarev-40405:11780):1026}}. See
> screenshots attached.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-5785) Add file permissions support to LogWriter appender
[ https://issues.apache.org/jira/browse/GEODE-5785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-5785: - Labels: observability (was: ) > Add file permissions support to LogWriter appender > -- > > Key: GEODE-5785 > URL: https://issues.apache.org/jira/browse/GEODE-5785 > Project: Geode > Issue Type: New Feature > Components: logging >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Minor > Labels: observability > > Log4J2 FileAppender supports specifying file permissions during > configuration. It may be valuable to provide similar support for LogWriter > appender, especially the SecurityLogWriter. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (GEODE-5692) ClassNotFound error with fine level loggging
[ https://issues.apache.org/jira/browse/GEODE-5692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey closed GEODE-5692. > ClassNotFound error with fine level loggging > > > Key: GEODE-5692 > URL: https://issues.apache.org/jira/browse/GEODE-5692 > Project: Geode > Issue Type: Bug > Components: logging >Reporter: Gregory Green >Priority: Major > > When performing a > CacheTransactionManager.commit() with client side code. > With fine level logging on server, I observed a ClassNotFoundException being > found server side. > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-4486) Remove singleton calls from all tests in org.apache.geode.management.bean.stats
[ https://issues.apache.org/jira/browse/GEODE-4486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-4486: Assignee: Kirk Lund > Remove singleton calls from all tests in > org.apache.geode.management.bean.stats > --- > > Key: GEODE-4486 > URL: https://issues.apache.org/jira/browse/GEODE-4486 > Project: Geode > Issue Type: Sub-task > Components: jmx, tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > These tests in org.apache.geode.management.bean.stats invoke singleton > getters. > GemFireCacheImpl.getInstance(): > * MemberLevelStatsJUnitTest -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-4486) Remove singleton calls from all tests in org.apache.geode.management.bean.stats
[ https://issues.apache.org/jira/browse/GEODE-4486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927052#comment-16927052 ] Aaron Lindsey commented on GEODE-4486: -- [~klund] it looks like this might be done already. Is this still an issue? > Remove singleton calls from all tests in > org.apache.geode.management.bean.stats > --- > > Key: GEODE-4486 > URL: https://issues.apache.org/jira/browse/GEODE-4486 > Project: Geode > Issue Type: Sub-task > Components: jmx, tests >Reporter: Kirk Lund >Priority: Major > > These tests in org.apache.geode.management.bean.stats invoke singleton > getters. > GemFireCacheImpl.getInstance(): > * MemberLevelStatsJUnitTest -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-4515) Remove singleton calls from product code in org.apache.geode.management.internal.beans
[ https://issues.apache.org/jira/browse/GEODE-4515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-4515: - Priority: Trivial (was: Major) > Remove singleton calls from product code in > org.apache.geode.management.internal.beans > -- > > Key: GEODE-4515 > URL: https://issues.apache.org/jira/browse/GEODE-4515 > Project: Geode > Issue Type: Sub-task > Components: gfsh, jmx, management >Reporter: Kirk Lund >Priority: Trivial > > These product classes in org.apache.geode.management.internal.beans invoke > singleton getters. > CacheFactory.getAnyInstance(): > * BeanUtilFuncs > * CacheServerBridge > * QueryDataFunction > * QueryDataFunction$LocalQueryFunction > GemFireCacheImpl.getInstance(): > * LocatorMBeanBridge > * ManagementListener > * RegionMBeanBridge -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-4515) Remove singleton calls from product code in org.apache.geode.management.internal.beans
[ https://issues.apache.org/jira/browse/GEODE-4515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-4515: - Labels: observability (was: ) > Remove singleton calls from product code in > org.apache.geode.management.internal.beans > -- > > Key: GEODE-4515 > URL: https://issues.apache.org/jira/browse/GEODE-4515 > Project: Geode > Issue Type: Sub-task > Components: gfsh, jmx, management >Reporter: Kirk Lund >Priority: Trivial > Labels: observability > > These product classes in org.apache.geode.management.internal.beans invoke > singleton getters. > CacheFactory.getAnyInstance(): > * BeanUtilFuncs > * CacheServerBridge > * QueryDataFunction > * QueryDataFunction$LocalQueryFunction > GemFireCacheImpl.getInstance(): > * LocatorMBeanBridge > * ManagementListener > * RegionMBeanBridge -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-4530) Remove singleton calls from product code in org.apache.geode.management.internal
[ https://issues.apache.org/jira/browse/GEODE-4530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-4530: - Labels: observability (was: ) > Remove singleton calls from product code in > org.apache.geode.management.internal > > > Key: GEODE-4530 > URL: https://issues.apache.org/jira/browse/GEODE-4530 > Project: Geode > Issue Type: Sub-task > Components: jmx, management, rest (admin) >Reporter: Kirk Lund >Priority: Trivial > Labels: observability > > These product classes in org.apache.geode.management.internal invoke > singleton getters. > CacheFactory.getAnyInstance(): > * ManagementAgent > * RestAgent > * StartJmxManagerFunction > GemFireCacheImpl.getInstance(): > * ManagementFunction -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-4530) Remove singleton calls from product code in org.apache.geode.management.internal
[ https://issues.apache.org/jira/browse/GEODE-4530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-4530: - Priority: Trivial (was: Major) > Remove singleton calls from product code in > org.apache.geode.management.internal > > > Key: GEODE-4530 > URL: https://issues.apache.org/jira/browse/GEODE-4530 > Project: Geode > Issue Type: Sub-task > Components: jmx, management, rest (admin) >Reporter: Kirk Lund >Priority: Trivial > > These product classes in org.apache.geode.management.internal invoke > singleton getters. > CacheFactory.getAnyInstance(): > * ManagementAgent > * RestAgent > * StartJmxManagerFunction > GemFireCacheImpl.getInstance(): > * ManagementFunction -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (GEODE-5692) ClassNotFound error with fine level loggging
[ https://issues.apache.org/jira/browse/GEODE-5692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey resolved GEODE-5692. -- Resolution: Incomplete Closing as there is no way to assign back to reporter to get further details. Please open a separate ticket with a stack trace and geode version number. > ClassNotFound error with fine level loggging > > > Key: GEODE-5692 > URL: https://issues.apache.org/jira/browse/GEODE-5692 > Project: Geode > Issue Type: Bug > Components: logging >Reporter: Gregory Green >Priority: Major > > When performing a > CacheTransactionManager.commit() with client side code. > With fine level logging on server, I observed a ClassNotFoundException being > found server side. > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-4490) Remove singleton calls from all tests in org.apache.geode.management.internal.pulse
[ https://issues.apache.org/jira/browse/GEODE-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-4490: - Labels: observability (was: ) > Remove singleton calls from all tests in > org.apache.geode.management.internal.pulse > --- > > Key: GEODE-4490 > URL: https://issues.apache.org/jira/browse/GEODE-4490 > Project: Geode > Issue Type: Sub-task > Components: pulse, tests >Reporter: Kirk Lund >Priority: Trivial > Labels: observability > > These tests in org.apache.geode.management.internal.pulse invoke singleton > getters. > GemFireCacheImpl.getInstance(): > * TestSubscriptionsDUnitTest -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-4490) Remove singleton calls from all tests in org.apache.geode.management.internal.pulse
[ https://issues.apache.org/jira/browse/GEODE-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-4490: - Priority: Trivial (was: Major) > Remove singleton calls from all tests in > org.apache.geode.management.internal.pulse > --- > > Key: GEODE-4490 > URL: https://issues.apache.org/jira/browse/GEODE-4490 > Project: Geode > Issue Type: Sub-task > Components: pulse, tests >Reporter: Kirk Lund >Priority: Trivial > > These tests in org.apache.geode.management.internal.pulse invoke singleton > getters. > GemFireCacheImpl.getInstance(): > * TestSubscriptionsDUnitTest -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (GEODE-3911) Authentication failures produce exception stacktraces in log files.
[
https://issues.apache.org/jira/browse/GEODE-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey resolved GEODE-3911.
--
Resolution: Won't Fix
Based on [~alberto.bustamante.reyes]'s comment, it seems this is an issue with
a third-party library. Closing this ticket as we don't intend to fix it.
> Authentication failures produce exception stacktraces in log files.
> ---
>
> Key: GEODE-3911
> URL: https://issues.apache.org/jira/browse/GEODE-3911
> Project: Geode
> Issue Type: Bug
> Components: pulse, security
>Reporter: Jens Deppe
>Priority: Major
> Labels: starter
>
> When running pulse along with the `SimpleSecurityManager` I notice quite a
> few authentication failure stacktraces like:
> {noformat}
> [warning 2017/10/26 07:14:27.773 PDT locator1 Connection(9)-10.118.33.247> tid=0x7d] Authentication failed for token
> submission [org.apache.geode.internal.security.shiro.GeodeAuthenticationToken
> - cluster,data, rememberMe=false]. Possible unexpected error? (Typical or
> expected login exceptions should extend from AuthenticationException).
> org.apache.geode.security.AuthenticationFailedException: invalid
> username/password
> at
> org.apache.geode.examples.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:41)
> at
> org.apache.geode.internal.security.shiro.CustomAuthRealm.doGetAuthenticationInfo(CustomAuthRealm.java:52)
> at
> org.apache.shiro.realm.AuthenticatingRealm.getAuthenticationInfo(AuthenticatingRealm.java:568)
> at
> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doSingleRealmAuthentication(ModularRealmAuthenticator.java:180)
> at
> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doAuthenticate(ModularRealmAuthenticator.java:267)
> at
> org.apache.shiro.authc.AbstractAuthenticator.authenticate(AbstractAuthenticator.java:198)
> at
> org.apache.shiro.mgt.AuthenticatingSecurityManager.authenticate(AuthenticatingSecurityManager.java:106)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:270)
> at
> org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:256)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.login(IntegratedSecurityService.java:139)
> at
> org.apache.geode.internal.security.shiro.JMXShiroAuthenticator.authenticate(JMXShiroAuthenticator.java:60)
> at
> javax.management.remote.rmi.RMIServerImpl.doNewClient(RMIServerImpl.java:232)
> at
> javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:346)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> We shouldn't need to dump these out, but just log a message.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-4687) Impossible to execute query on some specific member in Pulse DataBrowser
[
https://issues.apache.org/jira/browse/GEODE-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey updated GEODE-4687:
-
Labels: observability starter (was: starter)
> Impossible to execute query on some specific member in Pulse DataBrowser
>
>
> Key: GEODE-4687
> URL: https://issues.apache.org/jira/browse/GEODE-4687
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Vadim Lotarev
>Priority: Minor
> Labels: observability, starter
> Attachments: screenshot.91.jpg, screenshot.92.jpg
>
>
> It is impossible to execute query on some specific member. The reason is in
> difference between member ID values used in Pulse and
> {{org.apache.geode.management.internal.beans.QueryDataFunction}} class. For
> example, Pulse passes the following ID:
> {{VLOTAREV(inventory-vlotarev-40405:11780):1026}} but
> {{QueryDataFunction}} tries to compare it with the following value:
> {{192.168.63.37(inventory-vlotarev-40405:11780):1026}}. See
> screenshots attached.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (GEODE-7177) Move membership's logging dependencies to its own module
[ https://issues.apache.org/jira/browse/GEODE-7177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927705#comment-16927705 ] Aaron Lindsey commented on GEODE-7177: -- There is an open PR to move classes that depend on log4j-core to a submodule: [https://github.com/apache/geode/pull/4003]. That might be relevant to this issue. You may want to coordinate with [~klund] as he is in the process of refactoring a large amount of logging code. > Move membership's logging dependencies to its own module > > > Key: GEODE-7177 > URL: https://issues.apache.org/jira/browse/GEODE-7177 > Project: Geode > Issue Type: Improvement > Components: logging, membership >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > > As part of eliminating membership's dependency on geode-core, we want to move > LogService and some other supporting classes to its own module which > membership can depend on. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (GEODE-7042) Wait until all startup tasks complete to update server status as "online"
[ https://issues.apache.org/jira/browse/GEODE-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey resolved GEODE-7042. -- Resolution: Fixed Fix Version/s: 1.11.0 > Wait until all startup tasks complete to update server status as "online" > - > > Key: GEODE-7042 > URL: https://issues.apache.org/jira/browse/GEODE-7042 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Labels: observability > Fix For: 1.11.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Currently, the server status is set to "online" before all of the startup > tasks have completed. This tells users incorrect facts about the system and > its availability. > *Scenario:* > Given a server has just been started > When the following threads have completed: > [Async] [Optional] Begin redundancy recovery > [Async] [Optional] Begin recovery of values from disk > And when the synchronous thread of .start() for the ServerLauncher that > started the server completes without exception > Then the 'status' bit of the ServerLauncher should be set to 'online' > (currently this is set to online regardless of Async processes) > *Notes:* > GFSH utilizes this 'online' status to return from the 'start server' command. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-6298) CI Failure: LRUListWithAsyncSortingTest.scanMovesRecentlyUsedNodeToTail
[
https://issues.apache.org/jira/browse/GEODE-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey resolved GEODE-6298.
--
Resolution: Fixed
> CI Failure: LRUListWithAsyncSortingTest.scanMovesRecentlyUsedNodeToTail
>
>
> Key: GEODE-6298
> URL: https://issues.apache.org/jira/browse/GEODE-6298
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Bruce Schuchardt
>Assignee: Aaron Lindsey
>Priority: Major
> Labels: CI
> Fix For: 1.10.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Failed in Windows JDK 11 run
> [234|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/234]
> {noformat}
> org.apache.geode.internal.cache.eviction.LRUListWithAsyncSortingTest >
> scanMovesRecentlyUsedNodeToTail FAILED
> org.junit.ComparisonFailure: expected:<[first]> but was:<[third]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.eviction.LRUListWithAsyncSortingTest.scanMovesRecentlyUsedNodeToTail(LRUListWithAsyncSortingTest.java:231)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-6298) CI Failure: LRUListWithAsyncSortingTest.scanMovesRecentlyUsedNodeToTail
[
https://issues.apache.org/jira/browse/GEODE-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey updated GEODE-6298:
-
Fix Version/s: 1.10.0
> CI Failure: LRUListWithAsyncSortingTest.scanMovesRecentlyUsedNodeToTail
>
>
> Key: GEODE-6298
> URL: https://issues.apache.org/jira/browse/GEODE-6298
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Bruce Schuchardt
>Assignee: Aaron Lindsey
>Priority: Major
> Labels: CI
> Fix For: 1.10.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Failed in Windows JDK 11 run
> [234|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/234]
> {noformat}
> org.apache.geode.internal.cache.eviction.LRUListWithAsyncSortingTest >
> scanMovesRecentlyUsedNodeToTail FAILED
> org.junit.ComparisonFailure: expected:<[first]> but was:<[third]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.eviction.LRUListWithAsyncSortingTest.scanMovesRecentlyUsedNodeToTail(LRUListWithAsyncSortingTest.java:231)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (GEODE-7003) CI failure: GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingRegisterTranxConnection failed with java.sql.SQLNonTransientConnectionException: No current
[
https://issues.apache.org/jira/browse/GEODE-7003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey resolved GEODE-7003.
--
Resolution: Fixed
Fix Version/s: 1.10.0
> CI failure:
> GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingRegisterTranxConnection
> failed with java.sql.SQLNonTransientConnectionException: No current
> connection.
>
>
> Key: GEODE-7003
> URL: https://issues.apache.org/jira/browse/GEODE-7003
> Project: Geode
> Issue Type: Bug
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Failed on Windows JDK 8 run on 7/22/19:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK8/builds/147]
> Archive results:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0468/test-results/integrationTest/1563834111/]
> Stack trace:
> {{org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest
> > testExceptionHandlingRegisterTranxConnection FAILED}}
> {{java.sql.SQLNonTransientConnectionException: No current connection.}}
> {{at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
> Source)}}
> {{at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
> Source)}}
> {{at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
> Source)}}
> {{at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
> Source)}}
> {{at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Unknown
> Source)}}
> {{at org.apache.derby.jdbc.EmbedPooledConnection.checkActive(Unknown
> Source)}}
> {{at
> org.apache.derby.jdbc.EmbedPooledConnection.getRealConnection(Unknown
> Source)}}
> {{at
> org.apache.derby.jdbc.EmbedXAConnection.getRealConnection(Unknown Source)}}
> {{at
> org.apache.derby.iapi.jdbc.BrokeredConnection.getRealConnection(Unknown
> Source)}}
> {{at org.apache.derby.iapi.jdbc.BrokeredConnection.isClosed(Unknown
> Source)}}
> {{at
> org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest.lambda$testExceptionHandlingRegisterTranxConnection$1(GemFireTransactionDataSourceIntegrationTest.java:103)}}
> {{Caused by:}}
> {{ERROR 08003: No current connection.}}
> {{at
> org.apache.derby.iapi.error.StandardException.newException(Unknown Source)}}
> {{at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.wrapArgsForTransportAcrossDRDA(Unknown
> Source)}}
> {{... 11 more}}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (GEODE-7042) Wait until all startup tasks complete to update server status as "online"
[ https://issues.apache.org/jira/browse/GEODE-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-7042: Assignee: Aaron Lindsey > Wait until all startup tasks complete to update server status as "online" > - > > Key: GEODE-7042 > URL: https://issues.apache.org/jira/browse/GEODE-7042 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > > Currently, the server status is set to "online" before all of the startup > tasks have completed. This tells users incorrect facts about the system and > its availability. > *Scenario:* > Given a server has just been started > When the following threads have completed: > [Async] [Optional] Begin redundancy recovery > [Async] [Optional] Begin recovery of values from disk > And when the synchronous thread of .start() for the ServerLauncher that > started the server completes without exception > Then the 'status' bit of the ServerLauncher should be set to 'online' > (currently this is set to online regardless of Async processes) > *Notes:* > GFSH utilizes this 'online' status to return from the 'start server' command. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-7042) Wait until all startup tasks complete to update server status as "online"
[ https://issues.apache.org/jira/browse/GEODE-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-7042: - Labels: observability (was: ) > Wait until all startup tasks complete to update server status as "online" > - > > Key: GEODE-7042 > URL: https://issues.apache.org/jira/browse/GEODE-7042 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Labels: observability > > Currently, the server status is set to "online" before all of the startup > tasks have completed. This tells users incorrect facts about the system and > its availability. > *Scenario:* > Given a server has just been started > When the following threads have completed: > [Async] [Optional] Begin redundancy recovery > [Async] [Optional] Begin recovery of values from disk > And when the synchronous thread of .start() for the ServerLauncher that > started the server completes without exception > Then the 'status' bit of the ServerLauncher should be set to 'online' > (currently this is set to online regardless of Async processes) > *Notes:* > GFSH utilizes this 'online' status to return from the 'start server' command. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7042) Wait until all startup tasks complete to update server status as "online"
Aaron Lindsey created GEODE-7042: Summary: Wait until all startup tasks complete to update server status as "online" Key: GEODE-7042 URL: https://issues.apache.org/jira/browse/GEODE-7042 Project: Geode Issue Type: Improvement Reporter: Aaron Lindsey Currently, the server status is set to "online" before all of the startup tasks have completed. This tells users incorrect facts about the system and its availability. *Scenario:* Given a server has just been started When the following threads have completed: [Async] [Optional] Begin redundancy recovery [Async] [Optional] Begin recovery of values from disk And when the synchronous thread of .start() for the ServerLauncher that started the server completes without exception Then the 'status' bit of the ServerLauncher should be set to 'online' (currently this is set to online regardless of Async processes) *Notes:* GFSH utilizes this 'online' status to return from the 'start server' command. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
