[jira] [Updated] (GEODE-5071) Update the gfsh limitations documentation
[ https://issues.apache.org/jira/browse/GEODE-5071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5071: -- Labels: pull-request-available (was: ) > Update the gfsh limitations documentation > - > > Key: GEODE-5071 > URL: https://issues.apache.org/jira/browse/GEODE-5071 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Barbara Pruijn >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > > The list of gfsh limitations should be updated on this page: > https://geode.apache.org/docs/guide/14/configuring/cluster_config/gfsh_persist.html#concept_r22_hyw_bl__section_bn3_23p_y4 > Under the line: "You cannot directly modify the attributes of the following > objects:" > Please remove: > cache-listener > cache-loader > cache-writer > custom-expiry > declarable > Further down, please remove: > Adding JNDI bindings > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-974) CI Failure: PersistentPartitionedRegionDUnitTest.testRevokeBeforeStartup failed with AssertionError
[
https://issues.apache.org/jira/browse/GEODE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483218#comment-16483218
]
Anilkumar Gingade commented on GEODE-974:
-
Another testcase in this DUnitTest:
Relating to testRecoverAfterConflict()
https://issues.apache.org/jira/browse/GEODE-5231
> CI Failure: PersistentPartitionedRegionDUnitTest.testRevokeBeforeStartup
> failed with AssertionError
> ---
>
> Key: GEODE-974
> URL: https://issues.apache.org/jira/browse/GEODE-974
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Reporter: Barry Oglesby
>Assignee: Kirk Lund
>Priority: Major
> Labels: CI, Flaky, pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Geode_develop_DistributedTests
> Private Build #1602 (Feb 13, 2016 9:09:53 AM)
> Revision: 781277f31f37388f7247cbdf05025c12de825d2a
> Error Message
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use DistributedTestCase.addExpectedException to ignore.
> ---
> Found suspect string in log4j at line 2919
> [fatal 2016/02/13 11:30:42.638 PST tid=0x580]
> Uncaught exception processing Alert "Error processing request class
> com.gemstone.gemfire.internal.admin.remote.PrepareRevokePersistentIDRequest."
> level ERROR
> java.lang.NullPointerException
> at
> com.gemstone.gemfire.internal.admin.remote.RemoteGfManagerAgent.getApplicationById(RemoteGfManagerAgent.java:606)
> at
> com.gemstone.gemfire.internal.admin.remote.RemoteGfManagerAgent.getMemberById(RemoteGfManagerAgent.java:592)
> at
> com.gemstone.gemfire.internal.admin.remote.AlertListenerMessage.process(AlertListenerMessage.java:83)
> at
> com.gemstone.gemfire.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:380)
> at
> com.gemstone.gemfire.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:451)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> com.gemstone.gemfire.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:656)
> at
> com.gemstone.gemfire.distributed.internal.DistributionManager$4$1.run(DistributionManager.java:930)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Stacktrace
> {noformat}
> com.gemstone.gemfire.test.dunit.RMIException: While invoking
> com.gemstone.gemfire.management.internal.cli.commands.CliCommandTestBase$1.call
> in VM 0 running on Host cc4-rh6.gemstone.com with 4 VMs
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:372)
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:315)
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:281)
> at
> com.gemstone.gemfire.management.internal.cli.commands.CliCommandTestBase.createDefaultSetup(CliCommandTestBase.java:105)
> at
> com.gemstone.gemfire.management.internal.cli.commands.CreateAlterDestroyRegionCommandsDUnitTest.testCreateRegion46391(CreateAlterDestroyRegionCommandsDUnitTest.java:290)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> at
[jira] [Resolved] (GEODE-4815) ParallelGatewaySenderOperation_2_DUnitTest testParallelGatewaySender_SingleNode_UserPR_Destroy_SimultaneousPut_RecreateRegion failed with suspect string
[
https://issues.apache.org/jira/browse/GEODE-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barry Oglesby resolved GEODE-4815.
--
The current failure wasn't exactly the same issue. I opened GEODE-5238 for the
new occurrence.
> ParallelGatewaySenderOperation_2_DUnitTest
> testParallelGatewaySender_SingleNode_UserPR_Destroy_SimultaneousPut_RecreateRegion
> failed with suspect string
>
>
> Key: GEODE-4815
> URL: https://issues.apache.org/jira/browse/GEODE-4815
> Project: Geode
> Issue Type: Improvement
> Components: tests, wan
>Reporter: Barry Oglesby
>Priority: Major
> Labels: pull-request-available
> Attachments:
> TEST-org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest.xml
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> ParallelGatewaySenderOperation_2_DUnitTest
> testParallelGatewaySender_SingleNode_UserPR_Destroy_SimultaneousPut_RecreateRegion
> failed with suspect string
> {noformat}
> Found suspect string in log4j at line 2444
> [fatal 2018/03/06 23:47:36.347 UTC tid=770]
> Possible loss of quorum due to the loss of 1 cache processes:
> [172.17.0.5(181):32771]
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:403)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:561)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:508)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:495)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5238) CI failure: SerialWANPropagationsFeatureDUnitTest.testSerialPropagationWithFilter fails with Possible loss of quorum suspect string
[
https://issues.apache.org/jira/browse/GEODE-5238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan reassigned GEODE-5238:
---
Assignee: Galen O'Sullivan
> CI failure:
> SerialWANPropagationsFeatureDUnitTest.testSerialPropagationWithFilter fails
> with Possible loss of quorum suspect string
> ---
>
> Key: GEODE-5238
> URL: https://issues.apache.org/jira/browse/GEODE-5238
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Barry Oglesby
>Assignee: Galen O'Sullivan
>Priority: Major
> Attachments:
> TEST-org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest.xml
>
>
> The members startup:
> {noformat}
> [vm1] [info 2018/05/19 02:18:54.055 UTC
> tid=27] Starting DistributionManager 172.17.0.5(154:locator):32771.
> (took 49 ms)
> [vm2] [info 2018/05/19 02:18:54.479 UTC
> tid=27] Starting DistributionManager 172.17.0.5(159):32772. (took 336 ms)
> [vm3] [info 2018/05/19 02:18:55.477 UTC
> tid=27] Starting DistributionManager 172.17.0.5(168):32773. (took 401 ms)
> [vm3] [info 2018/05/19 02:18:55.478 UTC
> tid=27] Initial (distribution manager) view =
> View[172.17.0.5(154:locator):32771|2] members:
> [172.17.0.5(154:locator):32771, 172.17.0.5(159):32772\{lead},
> 172.17.0.5(168):32773]
> {noformat}
> So the members are:
> {noformat}
> vm1 - locator, coordinator (weight=3)
> vm2 - lead member (weight=15)
> vm3 - member (weight=10)``
> vm1 - locator, coordinator (weight=3)
> vm2 - lead member (weight=15)
> vm3 - member (weight=10)
> {noformat}
> The WANTestBase cleanupVM method shuts down the members simultaneously.
> Log messages show vm1 (locator) shutting down first (and the other two
> members realize it):
> {noformat}
> [vm1] [info 2018/05/19 02:19:10.400 UTC
> tid=27] Shutting down DistributionManager
> 172.17.0.5(154:locator):32771.
> [vm1] [info 2018/05/19 02:19:10.513 UTC
> tid=27] Now closing distribution for 172.17.0.5(154:locator):32771
> [vm1] [info 2018/05/19 02:19:10.513 UTC
> tid=27] Stopping membership services
> [vm1] [info 2018/05/19 02:19:10.513 UTC
> tid=27] Now closing distribution for 172.17.0.5(154:locator):32771
> [vm2] [info 2018/05/19 02:19:10.420 UTC Processor 1> tid=310] Member at 172.17.0.5(154:locator):32771
> gracefully left the distributed cache: shutdown message received
> [vm3] [info 2018/05/19 02:19:10.622 UTC Processor 1> tid=310] Member at 172.17.0.5(154:locator):32771
> gracefully left the distributed cache: shutdown message received
> {noformat}
> Then vm2 becomes coordinator:
> {noformat}
> [vm2] [info 2018/05/19 02:19:10.402 UTC Processor 1> tid=310] This member is becoming the membership coordinator with
> address 172.17.0.5(159):32772
> {noformat}
> Then vm2 shuts down its DistributionManager:
> {noformat}
> [vm2] [info 2018/05/19 02:19:11.239 UTC
> tid=27] Shutting down DistributionManager 172.17.0.5(159):32772.
> [vm2] [info 2018/05/19 02:19:11.352 UTC
> tid=27] Now closing distribution for 172.17.0.5(159):32772
> [vm2] [info 2018/05/19 02:19:11.352 UTC
> tid=27] Stopping membership services
> [vm2] [info 2018/05/19 02:19:11.377 UTC
> tid=27] DistributionManager stopped in 138ms.
> [vm2] [info 2018/05/19 02:19:11.377 UTC
> tid=27] Marking DistributionManager 172.17.0.5(159):32772 as closed.
> {noformat}
> Then vm3 does some suspect checking and logs the quorum loss warning:
> {noformat}
> [vm3] [info 2018/05/19 02:19:11.414 UTC 172.17.0.5(159):32772 shared unordered uid=14 port=35502> tid=296]
> Performing final check for suspect member 172.17.0.5(159):32772
> reason=member unexpectedly shut down shared, unordered connection
> [vm3] [info 2018/05/19 02:19:11.434 UTC 172.17.0.5(159):32772 shared unordered uid=14 port=35502> tid=296] This
> member is becoming the membership coordinator with address
> 172.17.0.5(168):32773
> [vm3] [info 2018/05/19 02:19:11.436 UTC
> tid=360] View Creator thread is starting
> [vm3] [info 2018/05/19 02:19:11.436 UTC
> tid=360] 172.17.0.5(159):32772 had a weight of 15
> [vm3] [warn 2018/05/19 02:19:11.436 UTC
> tid=360] total weight lost in this view change is 15 of 25. Quorum has been
> lost!
> [vm3] [fatal 2018/05/19 02:19:11.438 UTC
> tid=360] Possible loss of quorum due to the loss of 1 cache processes:
> [172.17.0.5(159):32772]
> {noformat}
> Then vm3 shuts down its DistributionManager:
> {noformat}
> [vm3] [info 2018/05/19 02:19:11.448 UTC
> tid=27] Shutting down DistributionManager 172.17.0.5(168):32773.
> [vm3] [info 2018/05/19 02:19:11.588 UTC
> tid=27] Now closing distribution for 172.17.0.5(168):32773
> [vm3] [info 2018/05/19 02:19:11.588 UTC
> tid=27] Stopping membership services
> [vm3] [info
[jira] [Assigned] (GEODE-5237) DiskAccessException can sometimes state that actual usage is less than critical
[ https://issues.apache.org/jira/browse/GEODE-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lynn Gallinat reassigned GEODE-5237: Assignee: Lynn Gallinat > DiskAccessException can sometimes state that actual usage is less than > critical > --- > > Key: GEODE-5237 > URL: https://issues.apache.org/jira/browse/GEODE-5237 > Project: Geode > Issue Type: Bug > Components: persistence >Reporter: Lynn Gallinat >Assignee: Lynn Gallinat >Priority: Major > > It's possible that GEODE can throw a DiskAccessException stating that the > current file system usage exceeds the critical threshold, but the exception's > message states that the file system usage is UNDER the critical threshold, as > follows. This appears to be only an error in what is logged and GEODE really > is over critical. > org.apache.geode.cache.DiskAccessException: For DiskStore: dmDiskStore_3604: > Critical disk usage threshold exceeded for volume > /var/vcap/data/scratch/serialParRegHABridgePersistParOffline-0516-200217/vm_2_bridge3_disk_1: > the file system is 5% full, which exceeds the critical threshold of > 5.203678%. > The problem is that GEODE rounds the file system usage before logging it in > the message in the method DiskUsage.update(float, float), and this can cause > the problem when it gets rounded down: > double use = 100.0 * (total - remaining) / total; > recordStats(total, remaining, elapsed); > String pct = Math.round(use) + "%"; <= -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5238) CI failure: SerialWANPropagationsFeatureDUnitTest.testSerialPropagationWithFilter fails with Possible loss of quorum suspect string
[
https://issues.apache.org/jira/browse/GEODE-5238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barry Oglesby updated GEODE-5238:
-
Attachment:
TEST-org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest.xml
> CI failure:
> SerialWANPropagationsFeatureDUnitTest.testSerialPropagationWithFilter fails
> with Possible loss of quorum suspect string
> ---
>
> Key: GEODE-5238
> URL: https://issues.apache.org/jira/browse/GEODE-5238
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Barry Oglesby
>Priority: Major
> Attachments:
> TEST-org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest.xml
>
>
> The members startup:
> {noformat}
> [vm1] [info 2018/05/19 02:18:54.055 UTC
> tid=27] Starting DistributionManager 172.17.0.5(154:locator):32771.
> (took 49 ms)
> [vm2] [info 2018/05/19 02:18:54.479 UTC
> tid=27] Starting DistributionManager 172.17.0.5(159):32772. (took 336 ms)
> [vm3] [info 2018/05/19 02:18:55.477 UTC
> tid=27] Starting DistributionManager 172.17.0.5(168):32773. (took 401 ms)
> [vm3] [info 2018/05/19 02:18:55.478 UTC
> tid=27] Initial (distribution manager) view =
> View[172.17.0.5(154:locator):32771|2] members:
> [172.17.0.5(154:locator):32771, 172.17.0.5(159):32772\{lead},
> 172.17.0.5(168):32773]
> {noformat}
> So the members are:
> {noformat}
> vm1 - locator, coordinator (weight=3)
> vm2 - lead member (weight=15)
> vm3 - member (weight=10)``
> vm1 - locator, coordinator (weight=3)
> vm2 - lead member (weight=15)
> vm3 - member (weight=10)
> {noformat}
> The WANTestBase cleanupVM method shuts down the members simultaneously.
> Log messages show vm1 (locator) shutting down first (and the other two
> members realize it):
> {noformat}
> [vm1] [info 2018/05/19 02:19:10.400 UTC
> tid=27] Shutting down DistributionManager
> 172.17.0.5(154:locator):32771.
> [vm1] [info 2018/05/19 02:19:10.513 UTC
> tid=27] Now closing distribution for 172.17.0.5(154:locator):32771
> [vm1] [info 2018/05/19 02:19:10.513 UTC
> tid=27] Stopping membership services
> [vm1] [info 2018/05/19 02:19:10.513 UTC
> tid=27] Now closing distribution for 172.17.0.5(154:locator):32771
> [vm2] [info 2018/05/19 02:19:10.420 UTC Processor 1> tid=310] Member at 172.17.0.5(154:locator):32771
> gracefully left the distributed cache: shutdown message received
> [vm3] [info 2018/05/19 02:19:10.622 UTC Processor 1> tid=310] Member at 172.17.0.5(154:locator):32771
> gracefully left the distributed cache: shutdown message received
> {noformat}
> Then vm2 becomes coordinator:
> {noformat}
> [vm2] [info 2018/05/19 02:19:10.402 UTC Processor 1> tid=310] This member is becoming the membership coordinator with
> address 172.17.0.5(159):32772
> {noformat}
> Then vm2 shuts down its DistributionManager:
> {noformat}
> [vm2] [info 2018/05/19 02:19:11.239 UTC
> tid=27] Shutting down DistributionManager 172.17.0.5(159):32772.
> [vm2] [info 2018/05/19 02:19:11.352 UTC
> tid=27] Now closing distribution for 172.17.0.5(159):32772
> [vm2] [info 2018/05/19 02:19:11.352 UTC
> tid=27] Stopping membership services
> [vm2] [info 2018/05/19 02:19:11.377 UTC
> tid=27] DistributionManager stopped in 138ms.
> [vm2] [info 2018/05/19 02:19:11.377 UTC
> tid=27] Marking DistributionManager 172.17.0.5(159):32772 as closed.
> {noformat}
> Then vm3 does some suspect checking and logs the quorum loss warning:
> {noformat}
> [vm3] [info 2018/05/19 02:19:11.414 UTC 172.17.0.5(159):32772 shared unordered uid=14 port=35502> tid=296]
> Performing final check for suspect member 172.17.0.5(159):32772
> reason=member unexpectedly shut down shared, unordered connection
> [vm3] [info 2018/05/19 02:19:11.434 UTC 172.17.0.5(159):32772 shared unordered uid=14 port=35502> tid=296] This
> member is becoming the membership coordinator with address
> 172.17.0.5(168):32773
> [vm3] [info 2018/05/19 02:19:11.436 UTC
> tid=360] View Creator thread is starting
> [vm3] [info 2018/05/19 02:19:11.436 UTC
> tid=360] 172.17.0.5(159):32772 had a weight of 15
> [vm3] [warn 2018/05/19 02:19:11.436 UTC
> tid=360] total weight lost in this view change is 15 of 25. Quorum has been
> lost!
> [vm3] [fatal 2018/05/19 02:19:11.438 UTC
> tid=360] Possible loss of quorum due to the loss of 1 cache processes:
> [172.17.0.5(159):32772]
> {noformat}
> Then vm3 shuts down its DistributionManager:
> {noformat}
> [vm3] [info 2018/05/19 02:19:11.448 UTC
> tid=27] Shutting down DistributionManager 172.17.0.5(168):32773.
> [vm3] [info 2018/05/19 02:19:11.588 UTC
> tid=27] Now closing distribution for 172.17.0.5(168):32773
> [vm3] [info 2018/05/19 02:19:11.588 UTC
> tid=27] Stopping membership services
[jira] [Created] (GEODE-5238) CI failure: SerialWANPropagationsFeatureDUnitTest.testSerialPropagationWithFilter fails with Possible loss of quorum suspect string
Barry Oglesby created GEODE-5238:
Summary: CI failure:
SerialWANPropagationsFeatureDUnitTest.testSerialPropagationWithFilter fails
with Possible loss of quorum suspect string
Key: GEODE-5238
URL: https://issues.apache.org/jira/browse/GEODE-5238
Project: Geode
Issue Type: Bug
Components: membership
Reporter: Barry Oglesby
The members startup:
{noformat}
[vm1] [info 2018/05/19 02:18:54.055 UTC
tid=27] Starting DistributionManager 172.17.0.5(154:locator):32771.
(took 49 ms)
[vm2] [info 2018/05/19 02:18:54.479 UTC
tid=27] Starting DistributionManager 172.17.0.5(159):32772. (took 336 ms)
[vm3] [info 2018/05/19 02:18:55.477 UTC
tid=27] Starting DistributionManager 172.17.0.5(168):32773. (took 401 ms)
[vm3] [info 2018/05/19 02:18:55.478 UTC
tid=27] Initial (distribution manager) view =
View[172.17.0.5(154:locator):32771|2] members:
[172.17.0.5(154:locator):32771, 172.17.0.5(159):32772\{lead},
172.17.0.5(168):32773]
{noformat}
So the members are:
{noformat}
vm1 - locator, coordinator (weight=3)
vm2 - lead member (weight=15)
vm3 - member (weight=10)``
vm1 - locator, coordinator (weight=3)
vm2 - lead member (weight=15)
vm3 - member (weight=10)
{noformat}
The WANTestBase cleanupVM method shuts down the members simultaneously.
Log messages show vm1 (locator) shutting down first (and the other two members
realize it):
{noformat}
[vm1] [info 2018/05/19 02:19:10.400 UTC
tid=27] Shutting down DistributionManager
172.17.0.5(154:locator):32771.
[vm1] [info 2018/05/19 02:19:10.513 UTC
tid=27] Now closing distribution for 172.17.0.5(154:locator):32771
[vm1] [info 2018/05/19 02:19:10.513 UTC
tid=27] Stopping membership services
[vm1] [info 2018/05/19 02:19:10.513 UTC
tid=27] Now closing distribution for 172.17.0.5(154:locator):32771
[vm2] [info 2018/05/19 02:19:10.420 UTC tid=310] Member at 172.17.0.5(154:locator):32771 gracefully left the
distributed cache: shutdown message received
[vm3] [info 2018/05/19 02:19:10.622 UTC tid=310] Member at 172.17.0.5(154:locator):32771 gracefully left the
distributed cache: shutdown message received
{noformat}
Then vm2 becomes coordinator:
{noformat}
[vm2] [info 2018/05/19 02:19:10.402 UTC tid=310] This member is becoming the membership coordinator with address
172.17.0.5(159):32772
{noformat}
Then vm2 shuts down its DistributionManager:
{noformat}
[vm2] [info 2018/05/19 02:19:11.239 UTC
tid=27] Shutting down DistributionManager 172.17.0.5(159):32772.
[vm2] [info 2018/05/19 02:19:11.352 UTC
tid=27] Now closing distribution for 172.17.0.5(159):32772
[vm2] [info 2018/05/19 02:19:11.352 UTC
tid=27] Stopping membership services
[vm2] [info 2018/05/19 02:19:11.377 UTC
tid=27] DistributionManager stopped in 138ms.
[vm2] [info 2018/05/19 02:19:11.377 UTC
tid=27] Marking DistributionManager 172.17.0.5(159):32772 as closed.
{noformat}
Then vm3 does some suspect checking and logs the quorum loss warning:
{noformat}
[vm3] [info 2018/05/19 02:19:11.414 UTC :32772 shared unordered uid=14 port=35502> tid=296]
Performing final check for suspect member 172.17.0.5(159):32772
reason=member unexpectedly shut down shared, unordered connection
[vm3] [info 2018/05/19 02:19:11.434 UTC :32772 shared unordered uid=14 port=35502> tid=296] This
member is becoming the membership coordinator with address
172.17.0.5(168):32773
[vm3] [info 2018/05/19 02:19:11.436 UTC
tid=360] View Creator thread is starting
[vm3] [info 2018/05/19 02:19:11.436 UTC
tid=360] 172.17.0.5(159):32772 had a weight of 15
[vm3] [warn 2018/05/19 02:19:11.436 UTC
tid=360] total weight lost in this view change is 15 of 25. Quorum has been
lost!
[vm3] [fatal 2018/05/19 02:19:11.438 UTC
tid=360] Possible loss of quorum due to the loss of 1 cache processes:
[172.17.0.5(159):32772]
{noformat}
Then vm3 shuts down its DistributionManager:
{noformat}
[vm3] [info 2018/05/19 02:19:11.448 UTC
tid=27] Shutting down DistributionManager 172.17.0.5(168):32773.
[vm3] [info 2018/05/19 02:19:11.588 UTC
tid=27] Now closing distribution for 172.17.0.5(168):32773
[vm3] [info 2018/05/19 02:19:11.588 UTC
tid=27] Stopping membership services
[vm3] [info 2018/05/19 02:19:11.617 UTC
tid=27] DistributionManager stopped in 168ms.
[vm3] [info 2018/05/19 02:19:11.617 UTC
tid=27] Marking DistributionManager 172.17.0.5(168):32773 as closed.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5071) Update the gfsh limitations documentation
[ https://issues.apache.org/jira/browse/GEODE-5071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-5071: -- Assignee: Karen Smoler Miller > Update the gfsh limitations documentation > - > > Key: GEODE-5071 > URL: https://issues.apache.org/jira/browse/GEODE-5071 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Barbara Pruijn >Assignee: Karen Smoler Miller >Priority: Major > > The list of gfsh limitations should be updated on this page: > https://geode.apache.org/docs/guide/14/configuring/cluster_config/gfsh_persist.html#concept_r22_hyw_bl__section_bn3_23p_y4 > Under the line: "You cannot directly modify the attributes of the following > objects:" > Please remove: > cache-listener > cache-loader > cache-writer > custom-expiry > declarable > Further down, please remove: > Adding JNDI bindings > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5237) DiskAccessException can sometimes state that actual usage is less than critical
Lynn Gallinat created GEODE-5237: Summary: DiskAccessException can sometimes state that actual usage is less than critical Key: GEODE-5237 URL: https://issues.apache.org/jira/browse/GEODE-5237 Project: Geode Issue Type: Bug Components: persistence Reporter: Lynn Gallinat It's possible that GEODE can throw a DiskAccessException stating that the current file system usage exceeds the critical threshold, but the exception's message states that the file system usage is UNDER the critical threshold, as follows. This appears to be only an error in what is logged and GEODE really is over critical. org.apache.geode.cache.DiskAccessException: For DiskStore: dmDiskStore_3604: Critical disk usage threshold exceeded for volume /var/vcap/data/scratch/serialParRegHABridgePersistParOffline-0516-200217/vm_2_bridge3_disk_1: the file system is 5% full, which exceeds the critical threshold of 5.203678%. The problem is that GEODE rounds the file system usage before logging it in the message in the method DiskUsage.update(float, float), and this can cause the problem when it gets rounded down: double use = 100.0 * (total - remaining) / total; recordStats(total, remaining, elapsed); String pct = Math.round(use) + "%"; <= -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5071) Update the gfsh limitations documentation
[ https://issues.apache.org/jira/browse/GEODE-5071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483122#comment-16483122 ] Karen Smoler Miller commented on GEODE-5071: When updating this info, let's also get rid of the very bad advice within the subsection titled "Individual Configuration Files and Cluster Configuration Files." Customers should only use cache.xml file configuration when they cannot do what they need to using a gfsh command. I think that we should make this statement explicit. > Update the gfsh limitations documentation > - > > Key: GEODE-5071 > URL: https://issues.apache.org/jira/browse/GEODE-5071 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Barbara Pruijn >Priority: Major > > The list of gfsh limitations should be updated on this page: > https://geode.apache.org/docs/guide/14/configuring/cluster_config/gfsh_persist.html#concept_r22_hyw_bl__section_bn3_23p_y4 > Under the line: "You cannot directly modify the attributes of the following > objects:" > Please remove: > cache-listener > cache-loader > cache-writer > custom-expiry > declarable > Further down, please remove: > Adding JNDI bindings > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5010) Introduce *ResultModel objects to replace *ResultData
[ https://issues.apache.org/jira/browse/GEODE-5010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483107#comment-16483107 ] ASF subversion and git services commented on GEODE-5010: Commit 5403732b3b97aa5bc69befab43090a05d6a5c807 in geode's branch refs/heads/develop from [~jinmeiliao] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5403732 ] GEODE-5010: have post interceptor uses ResultModel as an input if com… (#1974) > Introduce *ResultModel objects to replace *ResultData > - > > Key: GEODE-5010 > URL: https://issues.apache.org/jira/browse/GEODE-5010 > Project: Geode > Issue Type: Sub-task > Components: docs, gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 4h 10m > Remaining Estimate: 0h > > Introduce POJOs to be used as replacements for CompositeResultData, > TabularResultData, InfoResultData and ErrorResultData. > These POJOs will be json serializable using Jackson > Provide ability to use both legacy and these new POJOs until all commands > have been migrated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5236) Intermittent NoSubscriptionServersAvailableException
Swapnil Bawaskar created GEODE-5236:
---
Summary: Intermittent NoSubscriptionServersAvailableException
Key: GEODE-5236
URL: https://issues.apache.org/jira/browse/GEODE-5236
Project: Geode
Issue Type: Bug
Components: client queues, cq
Reporter: Swapnil Bawaskar
When the client connects to the server, the server creates a queue for the
events to send the client, whether the client is *durable* or not. If that
server-side queue is not ready, then a interest registration or CQ will cause
the \{{NoSubscriptionServersAvailableException}}.
When the request for RI or CQ reaches the server, I think, the server should be
able to check if queue initialization is in progress, and the call should block
until the queue is ready.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4815) ParallelGatewaySenderOperation_2_DUnitTest testParallelGatewaySender_SingleNode_UserPR_Destroy_SimultaneousPut_RecreateRegion failed with suspect string
[
https://issues.apache.org/jira/browse/GEODE-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barry Oglesby updated GEODE-4815:
-
Attachment:
TEST-org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest.xml
> ParallelGatewaySenderOperation_2_DUnitTest
> testParallelGatewaySender_SingleNode_UserPR_Destroy_SimultaneousPut_RecreateRegion
> failed with suspect string
>
>
> Key: GEODE-4815
> URL: https://issues.apache.org/jira/browse/GEODE-4815
> Project: Geode
> Issue Type: Improvement
> Components: tests, wan
>Reporter: Barry Oglesby
>Priority: Major
> Labels: pull-request-available
> Attachments:
> TEST-org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest.xml
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> ParallelGatewaySenderOperation_2_DUnitTest
> testParallelGatewaySender_SingleNode_UserPR_Destroy_SimultaneousPut_RecreateRegion
> failed with suspect string
> {noformat}
> Found suspect string in log4j at line 2444
> [fatal 2018/03/06 23:47:36.347 UTC tid=770]
> Possible loss of quorum due to the loss of 1 cache processes:
> [172.17.0.5(181):32771]
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:403)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:561)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:508)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:495)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4815) ParallelGatewaySenderOperation_2_DUnitTest testParallelGatewaySender_SingleNode_UserPR_Destroy_SimultaneousPut_RecreateRegion failed with suspect string
[
https://issues.apache.org/jira/browse/GEODE-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482995#comment-16482995
]
Barry Oglesby commented on GEODE-4815:
--
Reoccurred in SerialWANPropagationsFeatureDUnitTest. I attached the out put of
the failed test.
{noformat}
org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest
> testSerialPropagationWithFilter 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 6809
[fatal 2018/05/19 02:19:11.438 UTC tid=360]
Possible loss of quorum due to the loss of 1 cache processes:
[172.17.0.5(159):32772]
{noformat}
> ParallelGatewaySenderOperation_2_DUnitTest
> testParallelGatewaySender_SingleNode_UserPR_Destroy_SimultaneousPut_RecreateRegion
> failed with suspect string
>
>
> Key: GEODE-4815
> URL: https://issues.apache.org/jira/browse/GEODE-4815
> Project: Geode
> Issue Type: Improvement
> Components: tests, wan
>Reporter: Barry Oglesby
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> ParallelGatewaySenderOperation_2_DUnitTest
> testParallelGatewaySender_SingleNode_UserPR_Destroy_SimultaneousPut_RecreateRegion
> failed with suspect string
> {noformat}
> Found suspect string in log4j at line 2444
> [fatal 2018/03/06 23:47:36.347 UTC tid=770]
> Possible loss of quorum due to the loss of 1 cache processes:
> [172.17.0.5(181):32771]
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:403)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:561)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:508)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:495)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GEODE-4815) ParallelGatewaySenderOperation_2_DUnitTest testParallelGatewaySender_SingleNode_UserPR_Destroy_SimultaneousPut_RecreateRegion failed with suspect string
[
https://issues.apache.org/jira/browse/GEODE-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482995#comment-16482995
]
Barry Oglesby edited comment on GEODE-4815 at 5/21/18 8:15 PM:
---
Reoccurred in SerialWANPropagationsFeatureDUnitTest. I attached the output of
the failed test.
{noformat}
org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest
> testSerialPropagationWithFilter 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 6809
[fatal 2018/05/19 02:19:11.438 UTC tid=360]
Possible loss of quorum due to the loss of 1 cache processes:
[172.17.0.5(159):32772]
{noformat}
was (Author: barry.oglesby):
Reoccurred in SerialWANPropagationsFeatureDUnitTest. I attached the out put of
the failed test.
{noformat}
org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest
> testSerialPropagationWithFilter 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 6809
[fatal 2018/05/19 02:19:11.438 UTC tid=360]
Possible loss of quorum due to the loss of 1 cache processes:
[172.17.0.5(159):32772]
{noformat}
> ParallelGatewaySenderOperation_2_DUnitTest
> testParallelGatewaySender_SingleNode_UserPR_Destroy_SimultaneousPut_RecreateRegion
> failed with suspect string
>
>
> Key: GEODE-4815
> URL: https://issues.apache.org/jira/browse/GEODE-4815
> Project: Geode
> Issue Type: Improvement
> Components: tests, wan
>Reporter: Barry Oglesby
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> ParallelGatewaySenderOperation_2_DUnitTest
> testParallelGatewaySender_SingleNode_UserPR_Destroy_SimultaneousPut_RecreateRegion
> failed with suspect string
> {noformat}
> Found suspect string in log4j at line 2444
> [fatal 2018/03/06 23:47:36.347 UTC tid=770]
> Possible loss of quorum due to the loss of 1 cache processes:
> [172.17.0.5(181):32771]
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:403)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:561)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:508)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:495)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5230) Pulse does not work when SSL is enabled for JMX
[
https://issues.apache.org/jira/browse/GEODE-5230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-5230.
---
Resolution: Fixed
> Pulse does not work when SSL is enabled for JMX
> ---
>
> Key: GEODE-5230
> URL: https://issues.apache.org/jira/browse/GEODE-5230
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> If I start a locator with SSL enabled {{ssl-components=ALL}} then Pulse does
> not work. When logging in I see an error message like:
> {noformat}
> Connecting ...
> Failed to retrieve RMIServer stub: javax.naming.CommunicationException [Root
> exception is java.rmi.ConnectIOException: error during JRMP connection
> establishment; nested exception is: javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target]
> {noformat}
> pulse.log shows the same:
> {noformat}
> Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable
> to find valid certification path to requested target
> at
> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
> ~[?:1.8.0_161]
> at
> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
> ~[?:1.8.0_161]
> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
> ~[?:1.8.0_161]
> at
> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
> ~[?:1.8.0_161]
> at
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
> ~[?:1.8.0_161]
> at sun.security.validator.Validator.validate(Validator.java:260)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1596)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> ~[?:1.8.0_161]
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
> ~[?:1.8.0_161]
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:987)
> ~[?:1.8.0_161]
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
> ~[?:1.8.0_161]
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:757)
> ~[?:1.8.0_161]
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> ~[?:1.8.0_161]
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> ~[?:1.8.0_161]
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> ~[?:1.8.0_161]
> at java.io.DataOutputStream.flush(DataOutputStream.java:123)
> ~[?:1.8.0_161]
> at
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:229)
> ~[?:1.8.0_161]
> at
> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
> ~[?:1.8.0_161]
> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:338)
> ~[?:1.8.0_161]
> at
> sun.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_Stub.java:112)
> ~[?:1.8.0_161]
> at
> com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:132)
> ~[?:1.8.0_161]
> at
> com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:205)
> ~[?:1.8.0_161]
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> ~[?:1.8.0_161]
> at
> javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1955)
> ~[?:1.8.0_161]
> at
> javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1922)
> ~[?:1.8.0_161]
> at
> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:287)
> ~[?:1.8.0_161]
> ... 92 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5230) Pulse does not work when SSL is enabled for JMX
[
https://issues.apache.org/jira/browse/GEODE-5230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-5230:
--
Fix Version/s: 1.7.0
> Pulse does not work when SSL is enabled for JMX
> ---
>
> Key: GEODE-5230
> URL: https://issues.apache.org/jira/browse/GEODE-5230
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> If I start a locator with SSL enabled {{ssl-components=ALL}} then Pulse does
> not work. When logging in I see an error message like:
> {noformat}
> Connecting ...
> Failed to retrieve RMIServer stub: javax.naming.CommunicationException [Root
> exception is java.rmi.ConnectIOException: error during JRMP connection
> establishment; nested exception is: javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target]
> {noformat}
> pulse.log shows the same:
> {noformat}
> Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable
> to find valid certification path to requested target
> at
> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
> ~[?:1.8.0_161]
> at
> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
> ~[?:1.8.0_161]
> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
> ~[?:1.8.0_161]
> at
> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
> ~[?:1.8.0_161]
> at
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
> ~[?:1.8.0_161]
> at sun.security.validator.Validator.validate(Validator.java:260)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1596)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> ~[?:1.8.0_161]
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
> ~[?:1.8.0_161]
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:987)
> ~[?:1.8.0_161]
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
> ~[?:1.8.0_161]
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:757)
> ~[?:1.8.0_161]
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> ~[?:1.8.0_161]
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> ~[?:1.8.0_161]
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> ~[?:1.8.0_161]
> at java.io.DataOutputStream.flush(DataOutputStream.java:123)
> ~[?:1.8.0_161]
> at
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:229)
> ~[?:1.8.0_161]
> at
> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
> ~[?:1.8.0_161]
> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:338)
> ~[?:1.8.0_161]
> at
> sun.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_Stub.java:112)
> ~[?:1.8.0_161]
> at
> com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:132)
> ~[?:1.8.0_161]
> at
> com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:205)
> ~[?:1.8.0_161]
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> ~[?:1.8.0_161]
> at
> javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1955)
> ~[?:1.8.0_161]
> at
> javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1922)
> ~[?:1.8.0_161]
> at
> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:287)
> ~[?:1.8.0_161]
> ... 92 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5230) Pulse does not work when SSL is enabled for JMX
[
https://issues.apache.org/jira/browse/GEODE-5230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482980#comment-16482980
]
ASF subversion and git services commented on GEODE-5230:
Commit 75e8b9e4fe8006982f7bfee1e5702af41c6c341e in geode's branch
refs/heads/develop from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=75e8b9e ]
GEODE-5230: Pulse does not work when SSL is enabled for JMX (#1976)
> Pulse does not work when SSL is enabled for JMX
> ---
>
> Key: GEODE-5230
> URL: https://issues.apache.org/jira/browse/GEODE-5230
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> If I start a locator with SSL enabled {{ssl-components=ALL}} then Pulse does
> not work. When logging in I see an error message like:
> {noformat}
> Connecting ...
> Failed to retrieve RMIServer stub: javax.naming.CommunicationException [Root
> exception is java.rmi.ConnectIOException: error during JRMP connection
> establishment; nested exception is: javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target]
> {noformat}
> pulse.log shows the same:
> {noformat}
> Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable
> to find valid certification path to requested target
> at
> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
> ~[?:1.8.0_161]
> at
> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
> ~[?:1.8.0_161]
> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
> ~[?:1.8.0_161]
> at
> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
> ~[?:1.8.0_161]
> at
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
> ~[?:1.8.0_161]
> at sun.security.validator.Validator.validate(Validator.java:260)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1596)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> ~[?:1.8.0_161]
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
> ~[?:1.8.0_161]
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:987)
> ~[?:1.8.0_161]
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
> ~[?:1.8.0_161]
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:757)
> ~[?:1.8.0_161]
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> ~[?:1.8.0_161]
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> ~[?:1.8.0_161]
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> ~[?:1.8.0_161]
> at java.io.DataOutputStream.flush(DataOutputStream.java:123)
> ~[?:1.8.0_161]
> at
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:229)
> ~[?:1.8.0_161]
> at
> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
> ~[?:1.8.0_161]
> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:338)
> ~[?:1.8.0_161]
> at
> sun.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_Stub.java:112)
> ~[?:1.8.0_161]
> at
> com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:132)
> ~[?:1.8.0_161]
> at
> com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:205)
> ~[?:1.8.0_161]
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> ~[?:1.8.0_161]
> at
> javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1955)
> ~[?:1.8.0_161]
> at
> javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1922)
> ~[?:1.8.0_161]
> at
> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:287)
> ~[?:1.8.0_161]
> ... 92 more
> {noformat}
--
This message was sent by Atlassian JIRA
[jira] [Commented] (GEODE-4858) refactor internal commands to use the public ClusterConfigService
[ https://issues.apache.org/jira/browse/GEODE-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482910#comment-16482910 ] ASF subversion and git services commented on GEODE-4858: Commit ec7a162b09faa87ac7d7f119fbf46827602e166c in geode's branch refs/heads/develop from [~prhomberg] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ec7a162 ] GEODE-4858: CreateAsyncEventQueue and tests refactor. (#1969) * Unsupported ModelCommandResult methods failedToPersist, setCommandPersisted, and setFileToDownload now throw exceptions to avoid accidental use in testing. * Extracted cluster configuration messages in CommandExecutor to public class fields, for test consumption. * Extracted several message strings in ModelCommandResult to public class fields, for test consumption * Serialized necessary AsyncEventQueue configuration classes and updated sanctioned-geode-core-serializables > refactor internal commands to use the public ClusterConfigService > - > > Key: GEODE-4858 > URL: https://issues.apache.org/jira/browse/GEODE-4858 > Project: Geode > Issue Type: Sub-task > Components: configuration >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Time Spent: 15h 50m > Remaining Estimate: 0h > > # except the ones that would need to access the internal cluster > configuration regions, like importClusterConfigCommand, > exportClusterConfigCommand or deploy > # use the configuration object as much as possible to pass parameters to the > functions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4155) Lucene search in gfsh fails for integer values
[
https://issues.apache.org/jira/browse/GEODE-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482808#comment-16482808
]
xiaojian zhou commented on GEODE-4155:
--
syntax should be:
search lucene --name=simpleIndex --region=example-region
--queryStrings="salary=75000"
--queryProvider=org.apache.geode.cache.lucene.test.IntRangeQueryProvider
--defaultField=salary
> Lucene search in gfsh fails for integer values
> --
>
> Key: GEODE-4155
> URL: https://issues.apache.org/jira/browse/GEODE-4155
> Project: Geode
> Issue Type: Improvement
> Components: gfsh, lucene
>Reporter: Diane Hardman
>Priority: Major
> Fix For: 1.3.0
>
>
> Using the geode-example/lucene, follow the README file to build the example,
> start up the cluster, and load the Employee data.
> In gfsh, I can successfully use OQL to query for entries with salary=75000,
> but a Lucene query for the same salary returns no results:
> OQL Query:
> {code}
> gfsh>query --query="select * from /example-region where salary=75000"
> Result : true
> Limit : 100
> Rows : 2
> contacts | email | emplNumber | firstName |
> hoursPerWeek | lastName | salary | startDate
> -- | - | -- | - |
> | | -- | -
> org.json.JSONArray | kris.c...@example.com | 10003 | Kris | 40
> | Call | 75000 | 1502397254080
> org.json.JSONArray | pat.p...@example.com | 10028 | Pat | 40
> | Puts | 75000 | 1502397254080
> {code}
> Lucene Query:
> {code}
> gfsh>search lucene --name=simpleIndex --region=example-region
> --queryStrings="salary:75000" --defaultField=salary
> No results
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4386) gfsh command to describe jndi binding
[
https://issues.apache.org/jira/browse/GEODE-4386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller resolved GEODE-4386.
Fix Version/s: 1.7.0
Code is in Geode 1.6.0. Docs completed for Geode version 1.7.0.
> gfsh command to describe jndi binding
> -
>
> Key: GEODE-4386
> URL: https://issues.apache.org/jira/browse/GEODE-4386
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Barbara Pruijn
>Assignee: Karen Smoler Miller
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0, 1.6.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> In cache.xml user can specify jndi binding like so:
> {code:java}
>
> jdbc-driver-class="org.postgresql.Driver" user-name="gpadmin"
> password="changeme"
> connection-url="jdbc:postgresql://localhost:5432/gemfire_db">
>
>
> {code}
> A user should be able to describe a datasource using the gfsh command
> {{describe jndi-binding --name=jndi-binding-name}}
> Then list the particular datasource with attributes and don't display the
> password.
> The
> {code:java}
> describe jndi-binding{code} command should be able to describe any
> jndi-binding that is output by the {code} list jndi-binding{code} command.
> The output of the {code} describe jndi-binding{code} needs to indicate
> whether a binding is active or not.
> Please look at Geode's schema for a list of attributes that can be set:
> [https://github.com/apache/geode-site/blob/master/website/content/schema/cache/cache-1.0.xsd#L1331]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5234) Geode OSS should include Geode-Native tar
[ https://issues.apache.org/jira/browse/GEODE-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482762#comment-16482762 ] Anthony Baker commented on GEODE-5234: -- Releases in ASF are *only* source releases. Binary artifacts may be provided for convenience, but are not officially part of a release. For the first release of geode-native, I recommend not providing binary artifacts so we can focus on getting the source release correct. I would also advocate that the geode-native release provides its own tarball separate from the geode tarball. > Geode OSS should include Geode-Native tar > - > > Key: GEODE-5234 > URL: https://issues.apache.org/jira/browse/GEODE-5234 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Addison >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5235) Concourse failure: HAStartupAndFailoverDUnitTest. testTwoPrimaryFailedOneAfterTheAnother
Brian Rowe created GEODE-5235:
-
Summary: Concourse failure: HAStartupAndFailoverDUnitTest.
testTwoPrimaryFailedOneAfterTheAnother
Key: GEODE-5235
URL: https://issues.apache.org/jira/browse/GEODE-5235
Project: Geode
Issue Type: Bug
Components: client/server
Reporter: Brian Rowe
Saw this failure once, was unable to reproduce:
{code:java}
org.apache.geode.internal.cache.tier.sockets.HAStartupAndFailoverDUnitTest >
testTwoPrimaryFailedOneAfterTheAnother 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 1823
[fatal 2018/05/11 19:48:36.531 UTC tid=0x214] Server connection from
[identity(172.17.0.6(1:loner):35608:b579bf50,connection=1; port=57978] :
Unexpected Error on server
org.apache.geode.InternalGemFireError: No cache client proxy on this node
for proxyId identity(172.17.0.6(1:loner):35608:b579bf50,connection=1
at
org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.makePrimary(CacheClientNotifier.java:668)
at
org.apache.geode.internal.cache.tier.sockets.command.MakePrimary.cmdExecute(MakePrimary.java:54)
at
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:163)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:868)
at
org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:85)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1248)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$4$1.run(AcceptorImpl.java:644)
at java.lang.Thread.run(Thread.java:748){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5206) Add an 'ignoreFailure' flag to CliFunctionResult
[
https://issues.apache.org/jira/browse/GEODE-5206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-5206:
--
Fix Version/s: 1.7.0
> Add an 'ignoreFailure' flag to CliFunctionResult
>
>
> Key: GEODE-5206
> URL: https://issues.apache.org/jira/browse/GEODE-5206
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Various commands have the ability to be idempotent with a
> {{--skip-if-exists}} (typically creation) or {{\-\-if-exists}} (typically
> deletion). This flag is passed to the function performing the actual work.
> With new cluster config POJOs we want to have the functions *only* accept the
> POJO as an argument. To that end the function should be able to set this new
> flag if the action fails because of a missing or already existing component.
> It will then be up to the command to process the returned
> {{CliFunctionResult}} to determine what to present to the user.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5206) Add an 'ignoreFailure' flag to CliFunctionResult
[
https://issues.apache.org/jira/browse/GEODE-5206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-5206.
---
Resolution: Fixed
Assignee: Jens Deppe
> Add an 'ignoreFailure' flag to CliFunctionResult
>
>
> Key: GEODE-5206
> URL: https://issues.apache.org/jira/browse/GEODE-5206
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Various commands have the ability to be idempotent with a
> {{--skip-if-exists}} (typically creation) or {{\-\-if-exists}} (typically
> deletion). This flag is passed to the function performing the actual work.
> With new cluster config POJOs we want to have the functions *only* accept the
> POJO as an argument. To that end the function should be able to set this new
> flag if the action fails because of a missing or already existing component.
> It will then be up to the command to process the returned
> {{CliFunctionResult}} to determine what to present to the user.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5234) Geode OSS should include Geode-Native tar
[ https://issues.apache.org/jira/browse/GEODE-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482707#comment-16482707 ] Addison commented on GEODE-5234: We need to have a conversation on if this should be a tar of the source or a binary for convenience. > Geode OSS should include Geode-Native tar > - > > Key: GEODE-5234 > URL: https://issues.apache.org/jira/browse/GEODE-5234 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Addison >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5234) Geode OSS should include Geode-Native tar
Addison created GEODE-5234: -- Summary: Geode OSS should include Geode-Native tar Key: GEODE-5234 URL: https://issues.apache.org/jira/browse/GEODE-5234 Project: Geode Issue Type: Sub-task Components: native client Reporter: Addison -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5222) JMX metric exposed in an MBean
[ https://issues.apache.org/jira/browse/GEODE-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Vallely updated GEODE-5222: Description: 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 was: 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 Store Free % AND Disk Store Used in Bytes AND Disk Store Used % AND Disk Store Used in Bytes > 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 >Priority: Major > > 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)
