[jira] [Created] (GEODE-3703) rename JAR resource to DEPLOY
Swapnil Bawaskar created GEODE-3703: --- Summary: rename JAR resource to DEPLOY Key: GEODE-3703 URL: https://issues.apache.org/jira/browse/GEODE-3703 Project: Geode Issue Type: Sub-task Components: docs, security Reporter: Swapnil Bawaskar We currently have a JAR resource introduced with finer grained security (not released yet). Since the idea behind this resource is to control who has authorization to deploy jar files to the geode cluster, I think a better name for this resource would be DEPLOY. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (GEODE-3578) Creating and closing a cq from a client should only require DATA:READ
[ https://issues.apache.org/jira/browse/GEODE-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reopened GEODE-3578: Assignee: Karen Smoler Miller (was: Jason Huynh) Reopening ticket to complete the documentation for this change. > Creating and closing a cq from a client should only require DATA:READ > - > > Key: GEODE-3578 > URL: https://issues.apache.org/jira/browse/GEODE-3578 > Project: Geode > Issue Type: Bug > Components: cq, docs, security >Reporter: Jason Huynh >Assignee: Karen Smoler Miller > Labels: 1.3 > Fix For: 1.3.0 > > > A client should not be required to have CLUSTER:MANAGE:QUERY to create a cq. > Otherwise, we would be giving clients the ability to create/drop indexes as a > side effect of wanting to allow them to create a cq. > Instead a client creating a cq should require just DATA:READ. The client > should also be able to close their own cq, therefore only needing DATA:READ > for that. > However an admin should be able to close cq's. They may not have DATA:READ. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3702) New framework for concurrency testing
[ https://issues.apache.org/jira/browse/GEODE-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179933#comment-16179933 ] ASF subversion and git services commented on GEODE-3702: Commit 13f3c396038fe5e2a8f7fe84d937969976f6dcac in geode's branch refs/heads/develop from [~upthewaterspout] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=13f3c39 ] GEODE-3702 Adding a new framework for concurrency testing in geode Added a new junit runner, ConcurrentTestRunner, for running a test that has parallel threads. The runner currently runs the test using Java PathFinder, which will run the test with all interleavings of the threads. Added an example test to geode-core for the FilterProfile serialization logic. There are options to configure which concurrent test runner to use, and configuration for the JPF runner to pass jpf properties. > New framework for concurrency testing > - > > Key: GEODE-3702 > URL: https://issues.apache.org/jira/browse/GEODE-3702 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Dan Smith >Assignee: Dan Smith > > From the mailing list discussion: > I'd like to propose two things: > 1) We introduce a framework for writing unit tests of code that is > supposed to be thread safe. This framework should let a developer > easily write a test with multiple things going on in parallel. The > framework can then take that code and try to run it with different > thread interleavings. > Here's an example of what this could look like: > @RunWith(ConcurrentTestRunner.class) > public class AtomicIntegerTest { > @Test > public void parallelIncrementReturns2(ParallelExecutor executor) > throws ExecutionException, InterruptedException { > AtomicInteger atomicInteger = new AtomicInteger(); > executor.inParallel(() -> atomicInteger.incrementAndGet()); > executor.inParallel(() -> atomicInteger.incrementAndGet()); > executor.execute(); > assertEquals(2, atomicInteger.get()); > } > 2) We implement this framework initially using Java Pathfinder, but > allow for other methods of testing the code to be plugged in for > example just running the test in the loop. Java pathfinder is cool > because it can run the code with different interleavings but it does > have some serious limitations. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3702) New framework for concurrency testing
Dan Smith created GEODE-3702: Summary: New framework for concurrency testing Key: GEODE-3702 URL: https://issues.apache.org/jira/browse/GEODE-3702 Project: Geode Issue Type: Improvement Components: tests Reporter: Dan Smith >From the mailing list discussion: I'd like to propose two things: 1) We introduce a framework for writing unit tests of code that is supposed to be thread safe. This framework should let a developer easily write a test with multiple things going on in parallel. The framework can then take that code and try to run it with different thread interleavings. Here's an example of what this could look like: @RunWith(ConcurrentTestRunner.class) public class AtomicIntegerTest { @Test public void parallelIncrementReturns2(ParallelExecutor executor) throws ExecutionException, InterruptedException { AtomicInteger atomicInteger = new AtomicInteger(); executor.inParallel(() -> atomicInteger.incrementAndGet()); executor.inParallel(() -> atomicInteger.incrementAndGet()); executor.execute(); assertEquals(2, atomicInteger.get()); } 2) We implement this framework initially using Java Pathfinder, but allow for other methods of testing the code to be plugged in for example just running the test in the loop. Java pathfinder is cool because it can run the code with different interleavings but it does have some serious limitations. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GEODE-3702) New framework for concurrency testing
[ https://issues.apache.org/jira/browse/GEODE-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reassigned GEODE-3702: Assignee: Dan Smith > New framework for concurrency testing > - > > Key: GEODE-3702 > URL: https://issues.apache.org/jira/browse/GEODE-3702 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Dan Smith >Assignee: Dan Smith > > From the mailing list discussion: > I'd like to propose two things: > 1) We introduce a framework for writing unit tests of code that is > supposed to be thread safe. This framework should let a developer > easily write a test with multiple things going on in parallel. The > framework can then take that code and try to run it with different > thread interleavings. > Here's an example of what this could look like: > @RunWith(ConcurrentTestRunner.class) > public class AtomicIntegerTest { > @Test > public void parallelIncrementReturns2(ParallelExecutor executor) > throws ExecutionException, InterruptedException { > AtomicInteger atomicInteger = new AtomicInteger(); > executor.inParallel(() -> atomicInteger.incrementAndGet()); > executor.inParallel(() -> atomicInteger.incrementAndGet()); > executor.execute(); > assertEquals(2, atomicInteger.get()); > } > 2) We implement this framework initially using Java Pathfinder, but > allow for other methods of testing the code to be plugged in for > example just running the test in the loop. Java pathfinder is cool > because it can run the code with different interleavings but it does > have some serious limitations. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3701) Improve docs on hash index performance
Karen Smoler Miller created GEODE-3701: -- Summary: Improve docs on hash index performance Key: GEODE-3701 URL: https://issues.apache.org/jira/browse/GEODE-3701 Project: Geode Issue Type: Improvement Reporter: Karen Smoler Miller Stronger language is warranted for hash indexes. In a simple test, there was an order of magnitude difference in load and GII performance between the two types of indexes. Range: Client: Loaded 2,000,000 entries in 20,487 ms Server 1 Size: 1,272,322,680 bytes Server 2: GIIed in 12,523 ms Server 2 Size: 1,272,088,544 bytes Hash: Client: Loaded 2,000,000 entries in 257,016 ms Server 1 Size: 1,228,010,280 bytes Server 2: GIIed in 218,983 ms Server 2 Size: 1,228,161,664 bytes So, the difference in size was ~45MB, but the difference in time was an order of magnitude. Better wording suggested for file developing/query_index/creating_hash_indexes.html: Using hash index will degrade put performance and recovery time substantially. If memory is not a concern, it is recommended that you use range index. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (GEODE-3636) GatewaySender stop can hang with SSL enabled
[ https://issues.apache.org/jira/browse/GEODE-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shelley Lynn Hughes-Godfrey resolved GEODE-3636. Resolution: Fixed Assignee: Shelley Lynn Hughes-Godfrey Fix Version/s: 1.3.0 > GatewaySender stop can hang with SSL enabled > > > Key: GEODE-3636 > URL: https://issues.apache.org/jira/browse/GEODE-3636 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.1.0, 1.1.1, 1.2.0 >Reporter: Shelley Lynn Hughes-Godfrey >Assignee: Shelley Lynn Hughes-Godfrey > Fix For: 1.3.0 > > > SSLSockets throw the following exception if shutdownOutput() invoked: > java.lang.UnsupportedOperationException: > The method shutdownOutput() is not supported in SSLSocket > GatewaySender code tries to interrupt the AckReaderThread in the middle of a > socket read by calling Connection.destroy. Unfortunately, that throws and > then swallows this UnsupportedOperationException and doesn't close the socket > when SSL is enabled. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3530) All DistributedTests that extend CliCommandTestBase are Flaky
[ https://issues.apache.org/jira/browse/GEODE-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Stewart updated GEODE-3530: - Description: All DistributedTests that extend CliCommandTestBase are Flaky. The tests need to be rewritten with GfshShellConnectionRule so we can delete CliCommandTestBase. List of test classes extending CliCommandTestBase and existing Flaky tickets: * AlterRegionCommandDUnitTest (GEODE-3018) * ClusterConfigurationDUnitTest (GEODE-1333, GEODE-1334) * ConfigCommandsDUnitTest (GEODE-1449) * ConnectCommandWithHttpAndSSLDUnitTest * CreateAlterDestroyRegionCommandsDUnitTest (GEODE-973, GEODE-2009, GEODE-3018) * CreateRegionCommandDUnitTest (GEODE-973) * DescribeClientCommandDUnitTest (GEODE-910) * DestroyRegionCommandDUnitTest * DiskStoreCommandsDUnitTest (GEODE-1206, GEODE-1406, GEODE-2102) * DurableClientCommandsDUnitTest (GEODE-1705, GEODE-3404, GEODE-3359) * FunctionCommandsDUnitTest (GEODE-1563) * GemfireDataCommandsDUnitTest (GEODE-1182, GEODE-1249, GEODE-1404, GEODE-1430, GEODE-1487, GEODE-1496, GEODE-1561, GEODE-1822, GEODE-2006) * GetCommandOnRegionWithCacheLoaderDuringCacheMissDUnitTest * LauncherLifecycleCommandsDUnitTest * ListAndDescribeDiskStoreCommandsDUnitTest * ListClientCommandDUnitTest (GEODE-908) * ListIndexCommandDUnitTest * LuceneIndexCommandsDUnitTest *- MiscellaneousCommandsDUnitTest (GEODE-1034, GEODE-1385, GEODE-1518, GEODE-1605, GEODE-1706, GEODE-2126)- * QueueCommandsDUnitTest (GEODE-1429, GEODE-1976) * RebalanceCommandDistributedTest * RebalanceCommandOverHttpDistributedTest * ShellCommandsDUnitTest (GEODE-989) * ShowMetricsDUnitTest (GEODE-1764) * ShowStackTraceDUnitTest * WANCommandTestBase (and subclasses) was: All DistributedTests that extend CliCommandTestBase are Flaky. The tests need to be rewritten with GfshShellConnectionRule so we can delete CliCommandTestBase. List of test classes extending CliCommandTestBase and existing Flaky tickets: * AlterRegionCommandDUnitTest (GEODE-3018) * ClusterConfigurationDUnitTest (GEODE-1333, GEODE-1334) * ConfigCommandsDUnitTest (GEODE-1449) * ConnectCommandWithHttpAndSSLDUnitTest * CreateAlterDestroyRegionCommandsDUnitTest (GEODE-973, GEODE-2009, GEODE-3018) * CreateRegionCommandDUnitTest (GEODE-973) * DescribeClientCommandDUnitTest (GEODE-910) * DestroyRegionCommandDUnitTest * DiskStoreCommandsDUnitTest (GEODE-1206, GEODE-1406, GEODE-2102) * DurableClientCommandsDUnitTest (GEODE-1705, GEODE-3404, GEODE-3359) * FunctionCommandsDUnitTest (GEODE-1563) * GemfireDataCommandsDUnitTest (GEODE-1182, GEODE-1249, GEODE-1404, GEODE-1430, GEODE-1487, GEODE-1496, GEODE-1561, GEODE-1822, GEODE-2006) * GetCommandOnRegionWithCacheLoaderDuringCacheMissDUnitTest * LauncherLifecycleCommandsDUnitTest * ListAndDescribeDiskStoreCommandsDUnitTest * ListClientCommandDUnitTest (GEODE-908) * ListIndexCommandDUnitTest * LuceneIndexCommandsDUnitTest * MiscellaneousCommandsDUnitTest (GEODE-1034, GEODE-1385, GEODE-1518, GEODE-1605, GEODE-1706, GEODE-2126) * QueueCommandsDUnitTest (GEODE-1429, GEODE-1976) * RebalanceCommandDistributedTest * RebalanceCommandOverHttpDistributedTest * ShellCommandsDUnitTest (GEODE-989) * ShowMetricsDUnitTest (GEODE-1764) * ShowStackTraceDUnitTest * WANCommandTestBase (and subclasses) > All DistributedTests that extend CliCommandTestBase are Flaky > - > > Key: GEODE-3530 > URL: https://issues.apache.org/jira/browse/GEODE-3530 > Project: Geode > Issue Type: Bug > Components: management, tests >Reporter: Kirk Lund > Labels: CliCommandTestBase, DistributedTest, Flaky > > All DistributedTests that extend CliCommandTestBase are Flaky. The tests need > to be rewritten with GfshShellConnectionRule so we can delete > CliCommandTestBase. > List of test classes extending CliCommandTestBase and existing Flaky tickets: > * AlterRegionCommandDUnitTest (GEODE-3018) > * ClusterConfigurationDUnitTest (GEODE-1333, GEODE-1334) > * ConfigCommandsDUnitTest (GEODE-1449) > * ConnectCommandWithHttpAndSSLDUnitTest > * CreateAlterDestroyRegionCommandsDUnitTest (GEODE-973, GEODE-2009, > GEODE-3018) > * CreateRegionCommandDUnitTest (GEODE-973) > * DescribeClientCommandDUnitTest (GEODE-910) > * DestroyRegionCommandDUnitTest > * DiskStoreCommandsDUnitTest (GEODE-1206, GEODE-1406, GEODE-2102) > * DurableClientCommandsDUnitTest (GEODE-1705, GEODE-3404, GEODE-3359) > * FunctionCommandsDUnitTest (GEODE-1563) > * GemfireDataCommandsDUnitTest (GEODE-1182, GEODE-1249, GEODE-1404, > GEODE-1430, GEODE-1487, GEODE-1496, GEODE-1561, GEODE-1822, GEODE-2006) > * GetCommandOnRegionWithCacheLoaderDuringCacheMissDUnitTest > * LauncherLifecycleCommandsDUnitTest > * ListAndDescribeDiskStoreCommandsDUnitTest > * ListClientCommandDUnitTest (GEODE-908) > * ListIndexCommandDUnitTest > * LuceneIndexCommandsDUnitTest > *-
[jira] [Updated] (GEODE-3530) All DistributedTests that extend CliCommandTestBase are Flaky
[ https://issues.apache.org/jira/browse/GEODE-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Stewart updated GEODE-3530: - Description: All DistributedTests that extend CliCommandTestBase are Flaky. The tests need to be rewritten with GfshShellConnectionRule so we can delete CliCommandTestBase. List of test classes extending CliCommandTestBase and existing Flaky tickets: * AlterRegionCommandDUnitTest (GEODE-3018) * ClusterConfigurationDUnitTest (GEODE-1333, GEODE-1334) * ConfigCommandsDUnitTest (GEODE-1449) * ConnectCommandWithHttpAndSSLDUnitTest * CreateAlterDestroyRegionCommandsDUnitTest (GEODE-973, GEODE-2009, GEODE-3018) * CreateRegionCommandDUnitTest (GEODE-973) * DescribeClientCommandDUnitTest (GEODE-910) * DestroyRegionCommandDUnitTest * DiskStoreCommandsDUnitTest (GEODE-1206, GEODE-1406, GEODE-2102) * DurableClientCommandsDUnitTest (GEODE-1705, GEODE-3404, GEODE-3359) * FunctionCommandsDUnitTest (GEODE-1563) * GemfireDataCommandsDUnitTest (GEODE-1182, GEODE-1249, GEODE-1404, GEODE-1430, GEODE-1487, GEODE-1496, GEODE-1561, GEODE-1822, GEODE-2006) * GetCommandOnRegionWithCacheLoaderDuringCacheMissDUnitTest * LauncherLifecycleCommandsDUnitTest * ListAndDescribeDiskStoreCommandsDUnitTest * ListClientCommandDUnitTest (GEODE-908) * ListIndexCommandDUnitTest * LuceneIndexCommandsDUnitTest * - MiscellaneousCommandsDUnitTest (GEODE-1034, GEODE-1385, GEODE-1518, GEODE-1605, GEODE-1706, GEODE-2126)- * QueueCommandsDUnitTest (GEODE-1429, GEODE-1976) * RebalanceCommandDistributedTest * RebalanceCommandOverHttpDistributedTest * ShellCommandsDUnitTest (GEODE-989) * ShowMetricsDUnitTest (GEODE-1764) * ShowStackTraceDUnitTest * WANCommandTestBase (and subclasses) was: All DistributedTests that extend CliCommandTestBase are Flaky. The tests need to be rewritten with GfshShellConnectionRule so we can delete CliCommandTestBase. List of test classes extending CliCommandTestBase and existing Flaky tickets: * AlterRegionCommandDUnitTest (GEODE-3018) * ClusterConfigurationDUnitTest (GEODE-1333, GEODE-1334) * ConfigCommandsDUnitTest (GEODE-1449) * ConnectCommandWithHttpAndSSLDUnitTest * CreateAlterDestroyRegionCommandsDUnitTest (GEODE-973, GEODE-2009, GEODE-3018) * CreateRegionCommandDUnitTest (GEODE-973) * DescribeClientCommandDUnitTest (GEODE-910) * DestroyRegionCommandDUnitTest * DiskStoreCommandsDUnitTest (GEODE-1206, GEODE-1406, GEODE-2102) * DurableClientCommandsDUnitTest (GEODE-1705, GEODE-3404, GEODE-3359) * FunctionCommandsDUnitTest (GEODE-1563) * GemfireDataCommandsDUnitTest (GEODE-1182, GEODE-1249, GEODE-1404, GEODE-1430, GEODE-1487, GEODE-1496, GEODE-1561, GEODE-1822, GEODE-2006) * GetCommandOnRegionWithCacheLoaderDuringCacheMissDUnitTest * LauncherLifecycleCommandsDUnitTest * ListAndDescribeDiskStoreCommandsDUnitTest * ListClientCommandDUnitTest (GEODE-908) * ListIndexCommandDUnitTest * LuceneIndexCommandsDUnitTest *- MiscellaneousCommandsDUnitTest (GEODE-1034, GEODE-1385, GEODE-1518, GEODE-1605, GEODE-1706, GEODE-2126)- * QueueCommandsDUnitTest (GEODE-1429, GEODE-1976) * RebalanceCommandDistributedTest * RebalanceCommandOverHttpDistributedTest * ShellCommandsDUnitTest (GEODE-989) * ShowMetricsDUnitTest (GEODE-1764) * ShowStackTraceDUnitTest * WANCommandTestBase (and subclasses) > All DistributedTests that extend CliCommandTestBase are Flaky > - > > Key: GEODE-3530 > URL: https://issues.apache.org/jira/browse/GEODE-3530 > Project: Geode > Issue Type: Bug > Components: management, tests >Reporter: Kirk Lund > Labels: CliCommandTestBase, DistributedTest, Flaky > > All DistributedTests that extend CliCommandTestBase are Flaky. The tests need > to be rewritten with GfshShellConnectionRule so we can delete > CliCommandTestBase. > List of test classes extending CliCommandTestBase and existing Flaky tickets: > * AlterRegionCommandDUnitTest (GEODE-3018) > * ClusterConfigurationDUnitTest (GEODE-1333, GEODE-1334) > * ConfigCommandsDUnitTest (GEODE-1449) > * ConnectCommandWithHttpAndSSLDUnitTest > * CreateAlterDestroyRegionCommandsDUnitTest (GEODE-973, GEODE-2009, > GEODE-3018) > * CreateRegionCommandDUnitTest (GEODE-973) > * DescribeClientCommandDUnitTest (GEODE-910) > * DestroyRegionCommandDUnitTest > * DiskStoreCommandsDUnitTest (GEODE-1206, GEODE-1406, GEODE-2102) > * DurableClientCommandsDUnitTest (GEODE-1705, GEODE-3404, GEODE-3359) > * FunctionCommandsDUnitTest (GEODE-1563) > * GemfireDataCommandsDUnitTest (GEODE-1182, GEODE-1249, GEODE-1404, > GEODE-1430, GEODE-1487, GEODE-1496, GEODE-1561, GEODE-1822, GEODE-2006) > * GetCommandOnRegionWithCacheLoaderDuringCacheMissDUnitTest > * LauncherLifecycleCommandsDUnitTest > * ListAndDescribeDiskStoreCommandsDUnitTest > * ListClientCommandDUnitTest (GEODE-908) > * ListIndexCommandDUnitTest > * LuceneIndexCommandsDUnitTest > * -
[jira] [Updated] (GEODE-3530) All DistributedTests that extend CliCommandTestBase are Flaky
[ https://issues.apache.org/jira/browse/GEODE-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Stewart updated GEODE-3530: - Description: All DistributedTests that extend CliCommandTestBase are Flaky. The tests need to be rewritten with GfshShellConnectionRule so we can delete CliCommandTestBase. List of test classes extending CliCommandTestBase and existing Flaky tickets: * AlterRegionCommandDUnitTest (GEODE-3018) * ClusterConfigurationDUnitTest (GEODE-1333, GEODE-1334) * ConfigCommandsDUnitTest (GEODE-1449) * ConnectCommandWithHttpAndSSLDUnitTest * CreateAlterDestroyRegionCommandsDUnitTest (GEODE-973, GEODE-2009, GEODE-3018) * CreateRegionCommandDUnitTest (GEODE-973) * DescribeClientCommandDUnitTest (GEODE-910) * DestroyRegionCommandDUnitTest * DiskStoreCommandsDUnitTest (GEODE-1206, GEODE-1406, GEODE-2102) * DurableClientCommandsDUnitTest (GEODE-1705, GEODE-3404, GEODE-3359) * FunctionCommandsDUnitTest (GEODE-1563) * GemfireDataCommandsDUnitTest (GEODE-1182, GEODE-1249, GEODE-1404, GEODE-1430, GEODE-1487, GEODE-1496, GEODE-1561, GEODE-1822, GEODE-2006) * GetCommandOnRegionWithCacheLoaderDuringCacheMissDUnitTest * LauncherLifecycleCommandsDUnitTest * ListAndDescribeDiskStoreCommandsDUnitTest * ListClientCommandDUnitTest (GEODE-908) * ListIndexCommandDUnitTest * LuceneIndexCommandsDUnitTest * -MiscellaneousCommandsDUnitTest (GEODE-1034, GEODE-1385, GEODE-1518, GEODE-1605, GEODE-1706, GEODE-2126)- * QueueCommandsDUnitTest (GEODE-1429, GEODE-1976) * RebalanceCommandDistributedTest * RebalanceCommandOverHttpDistributedTest * ShellCommandsDUnitTest (GEODE-989) * ShowMetricsDUnitTest (GEODE-1764) * ShowStackTraceDUnitTest * WANCommandTestBase (and subclasses) was: All DistributedTests that extend CliCommandTestBase are Flaky. The tests need to be rewritten with GfshShellConnectionRule so we can delete CliCommandTestBase. List of test classes extending CliCommandTestBase and existing Flaky tickets: * AlterRegionCommandDUnitTest (GEODE-3018) * ClusterConfigurationDUnitTest (GEODE-1333, GEODE-1334) * ConfigCommandsDUnitTest (GEODE-1449) * ConnectCommandWithHttpAndSSLDUnitTest * CreateAlterDestroyRegionCommandsDUnitTest (GEODE-973, GEODE-2009, GEODE-3018) * CreateRegionCommandDUnitTest (GEODE-973) * DescribeClientCommandDUnitTest (GEODE-910) * DestroyRegionCommandDUnitTest * DiskStoreCommandsDUnitTest (GEODE-1206, GEODE-1406, GEODE-2102) * DurableClientCommandsDUnitTest (GEODE-1705, GEODE-3404, GEODE-3359) * FunctionCommandsDUnitTest (GEODE-1563) * GemfireDataCommandsDUnitTest (GEODE-1182, GEODE-1249, GEODE-1404, GEODE-1430, GEODE-1487, GEODE-1496, GEODE-1561, GEODE-1822, GEODE-2006) * GetCommandOnRegionWithCacheLoaderDuringCacheMissDUnitTest * LauncherLifecycleCommandsDUnitTest * ListAndDescribeDiskStoreCommandsDUnitTest * ListClientCommandDUnitTest (GEODE-908) * ListIndexCommandDUnitTest * LuceneIndexCommandsDUnitTest * - MiscellaneousCommandsDUnitTest (GEODE-1034, GEODE-1385, GEODE-1518, GEODE-1605, GEODE-1706, GEODE-2126)- * QueueCommandsDUnitTest (GEODE-1429, GEODE-1976) * RebalanceCommandDistributedTest * RebalanceCommandOverHttpDistributedTest * ShellCommandsDUnitTest (GEODE-989) * ShowMetricsDUnitTest (GEODE-1764) * ShowStackTraceDUnitTest * WANCommandTestBase (and subclasses) > All DistributedTests that extend CliCommandTestBase are Flaky > - > > Key: GEODE-3530 > URL: https://issues.apache.org/jira/browse/GEODE-3530 > Project: Geode > Issue Type: Bug > Components: management, tests >Reporter: Kirk Lund > Labels: CliCommandTestBase, DistributedTest, Flaky > > All DistributedTests that extend CliCommandTestBase are Flaky. The tests need > to be rewritten with GfshShellConnectionRule so we can delete > CliCommandTestBase. > List of test classes extending CliCommandTestBase and existing Flaky tickets: > * AlterRegionCommandDUnitTest (GEODE-3018) > * ClusterConfigurationDUnitTest (GEODE-1333, GEODE-1334) > * ConfigCommandsDUnitTest (GEODE-1449) > * ConnectCommandWithHttpAndSSLDUnitTest > * CreateAlterDestroyRegionCommandsDUnitTest (GEODE-973, GEODE-2009, > GEODE-3018) > * CreateRegionCommandDUnitTest (GEODE-973) > * DescribeClientCommandDUnitTest (GEODE-910) > * DestroyRegionCommandDUnitTest > * DiskStoreCommandsDUnitTest (GEODE-1206, GEODE-1406, GEODE-2102) > * DurableClientCommandsDUnitTest (GEODE-1705, GEODE-3404, GEODE-3359) > * FunctionCommandsDUnitTest (GEODE-1563) > * GemfireDataCommandsDUnitTest (GEODE-1182, GEODE-1249, GEODE-1404, > GEODE-1430, GEODE-1487, GEODE-1496, GEODE-1561, GEODE-1822, GEODE-2006) > * GetCommandOnRegionWithCacheLoaderDuringCacheMissDUnitTest > * LauncherLifecycleCommandsDUnitTest > * ListAndDescribeDiskStoreCommandsDUnitTest > * ListClientCommandDUnitTest (GEODE-908) > * ListIndexCommandDUnitTest > * LuceneIndexCommandsDUnitTest > *
[jira] [Assigned] (GEODE-1385) CI Failure: MiscellaneousCommandsDUnitTest.testShutDownForTIMEOUT
[ https://issues.apache.org/jira/browse/GEODE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Stewart reassigned GEODE-1385: Assignee: Jared Stewart (was: Kirk Lund) > CI Failure: MiscellaneousCommandsDUnitTest.testShutDownForTIMEOUT > - > > Key: GEODE-1385 > URL: https://issues.apache.org/jira/browse/GEODE-1385 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Barry Oglesby >Assignee: Jared Stewart > Labels: BindException, Flaky, MiscellaneousCommands, > ShutdownCommand > > Geode_develop_DistributedTests > Private Build #2546 (May 10, 2016 7:09:11 AM) > Revision: 44c2f398ff0a67d3e639c224c7df3ec861fe2c70 > Error Message > {noformat} > com.gemstone.gemfire.test.dunit.RMIException: While invoking > com.gemstone.gemfire.test.dunit.NamedCallable.call in VM 0 running on Host > buildtest.gemstone.com with 4 VMs > {noformat} > Stacktrace > {noformat} > com.gemstone.gemfire.test.dunit.RMIException: While invoking > com.gemstone.gemfire.test.dunit.NamedCallable.call in VM 0 running on Host > buildtest.gemstone.com with 4 VMs > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:308) > at > com.gemstone.gemfire.management.internal.cli.commands.CliCommandTestBase.setUpJMXManagerOnVM(CliCommandTestBase.java:117) > at > com.gemstone.gemfire.management.internal.cli.commands.CliCommandTestBase.setUpJmxManagerOnVm0ThenConnect(CliCommandTestBase.java:111) > at > com.gemstone.gemfire.management.internal.cli.commands.MiscellaneousCommandsDUnitTest.setupForShutDown(MiscellaneousCommandsDUnitTest.java:357) > at > com.gemstone.gemfire.management.internal.cli.commands.MiscellaneousCommandsDUnitTest.testShutDownForTIMEOUT(MiscellaneousCommandsDUnitTest.java:306) > 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 > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112) > 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:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.GeneratedMethodAccessor335.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at >
[jira] [Assigned] (GEODE-1605) CI failure: MiscellaneousCommandsDUnitTest.testChangeLogLevelForMembers
[ https://issues.apache.org/jira/browse/GEODE-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Stewart reassigned GEODE-1605: Assignee: Jared Stewart > CI failure: MiscellaneousCommandsDUnitTest.testChangeLogLevelForMembers > --- > > Key: GEODE-1605 > URL: https://issues.apache.org/jira/browse/GEODE-1605 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Dan Smith >Assignee: Jared Stewart > Labels: CI, Flaky > > Revision: 7ad9cc9451212f1c8a0acba3ec78a9eb562d3780 > {noformat} > java.lang.AssertionError: Connect command failed to connect to manager > japan[29850] result=Could not connect to : [host=japan, port=29850]. Failed > to retrieve RMIServer stub: javax.naming.CommunicationException [Root > exception is java.rmi.NoSuchObjectException: no such object in table] > at > com.gemstone.gemfire.management.internal.cli.commands.CliCommandTestBase.connect(CliCommandTestBase.java:248) > at > com.gemstone.gemfire.management.internal.cli.commands.CliCommandTestBase.connect(CliCommandTestBase.java:221) > at > com.gemstone.gemfire.management.internal.cli.commands.CliCommandTestBase.setUpJmxManagerOnVm0ThenConnect(CliCommandTestBase.java:109) > at > com.gemstone.gemfire.management.internal.cli.commands.MiscellaneousCommandsDUnitTest.setupForChangeLogLelvel(MiscellaneousCommandsDUnitTest.java:325) > at > com.gemstone.gemfire.management.internal.cli.commands.MiscellaneousCommandsDUnitTest.testChangeLogLevelForMembers(MiscellaneousCommandsDUnitTest.java:400) > 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 > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112) > 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:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.GeneratedMethodAccessor168.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at >
[jira] [Assigned] (GEODE-2126) CI failure: MiscellaneousCommandsDUnitTest.testShowLogNumLines
[ https://issues.apache.org/jira/browse/GEODE-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Stewart reassigned GEODE-2126: Assignee: Jared Stewart (was: Kirk Lund) > CI failure: MiscellaneousCommandsDUnitTest.testShowLogNumLines > -- > > Key: GEODE-2126 > URL: https://issues.apache.org/jira/browse/GEODE-2126 > Project: Geode > Issue Type: Bug > Components: management, tests >Reporter: Kirk Lund >Assignee: Jared Stewart > Labels: CI, Flaky > > {noformat} > :geode-core:distributedTest > org.apache.geode.management.internal.cli.commands.MiscellaneousCommandsDUnitTest > > testShowLogNumLines FAILED > java.lang.AssertionError: Connect command failed to connect to manager > 9e344091c4a9[20863] result=Could not connect to : [host=9e344091c4a9, > port=20863]. Failed to retrieve RMIServer stub: > javax.naming.CommunicationException [Root exception is > java.rmi.NoSuchObjectException: no such object in table] > at > org.apache.geode.management.internal.cli.commands.CliCommandTestBase.connect(CliCommandTestBase.java:252) > at > org.apache.geode.management.internal.cli.commands.CliCommandTestBase.connect(CliCommandTestBase.java:224) > at > org.apache.geode.management.internal.cli.commands.CliCommandTestBase.setUpJmxManagerOnVm0ThenConnect(CliCommandTestBase.java:111) > at > org.apache.geode.management.internal.cli.commands.MiscellaneousCommandsDUnitTest.testShowLogNumLines(MiscellaneousCommandsDUnitTest.java:152) > 6742 tests completed, 1 failed, 600 skipped > :geode-core:distributedTest FAILED > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3700) Gfsh 'remove --all' does not work when connected to a Locator
[ https://issues.apache.org/jira/browse/GEODE-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Stewart updated GEODE-3700: - Affects Version/s: 1.1.0 1.1.1 1.2.0 1.2.1 > Gfsh 'remove --all' does not work when connected to a Locator > - > > Key: GEODE-3700 > URL: https://issues.apache.org/jira/browse/GEODE-3700 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.2.1 >Reporter: Jared Stewart > > It looks like there is some code in RemoveCommand that only works correctly > when connected to a JMX-manager-enabled server (but not when connected to a > Locator). > {noformat} > Command result for : > List of regions > - > partitionedRegion > replicateRegion > Command result for : > Region not found in any of the members > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GEODE-3700) Gfsh 'remove --all' does not work when connected to a Locator
[ https://issues.apache.org/jira/browse/GEODE-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Stewart reassigned GEODE-3700: Assignee: Jared Stewart > Gfsh 'remove --all' does not work when connected to a Locator > - > > Key: GEODE-3700 > URL: https://issues.apache.org/jira/browse/GEODE-3700 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.2.1 >Reporter: Jared Stewart >Assignee: Jared Stewart > > It looks like there is some code in RemoveCommand that only works correctly > when connected to a JMX-manager-enabled server (but not when connected to a > Locator). > {noformat} > Command result for : > List of regions > - > partitionedRegion > replicateRegion > Command result for : > Region not found in any of the members > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3700) Gfsh 'remove --all' does not work when connected to a Locator
Jared Stewart created GEODE-3700: Summary: Gfsh 'remove --all' does not work when connected to a Locator Key: GEODE-3700 URL: https://issues.apache.org/jira/browse/GEODE-3700 Project: Geode Issue Type: Bug Components: gfsh Reporter: Jared Stewart It looks like there is some code in RemoveCommand that only works correctly when connected to a JMX-manager-enabled server (but not when connected to a Locator). {noformat} Command result for : List of regions - partitionedRegion replicateRegion Command result for : Region not found in any of the members {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (GEODE-3187) CI failure (windows): org.apache.geode.internal.cache.persistence.BackupInspectorJUnitTest.testIncrementalBackupScript
[ https://issues.apache.org/jira/browse/GEODE-3187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lynn Gallinat resolved GEODE-3187. -- Resolution: Fixed commit 94dcc622c0a9615df4bf83dc57653eb749bbd0b1 Author: Lynn GallinatDate: Wed Sep 20 16:09:43 2017 -0700 GEODE-3187 Fix backup inspector and restore script for windows. Refactor RestoreScript.java and BackupInspector.java > CI failure (windows): > org.apache.geode.internal.cache.persistence.BackupInspectorJUnitTest.testIncrementalBackupScript > -- > > Key: GEODE-3187 > URL: https://issues.apache.org/jira/browse/GEODE-3187 > Project: Geode > Issue Type: Bug > Components: persistence >Reporter: Lynn Gallinat >Assignee: Lynn Gallinat > Labels: storage_3, windows_test > Fix For: 1.3.0 > > > {noformat} > org.apache.geode.internal.cache.persistence.BackupInspectorJUnitTest > > testIncrementalBackupScript FAILED > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at > org.apache.geode.internal.cache.persistence.BackupInspectorJUnitTest.testIncrementalBackupScript(BackupInspectorJUnitTest.java:198) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GEODE-3699) Remove use of Task.leftShift in gradle
[ https://issues.apache.org/jira/browse/GEODE-3699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dodge reassigned GEODE-3699: Assignee: Michael Dodge > Remove use of Task.leftShift in gradle > -- > > Key: GEODE-3699 > URL: https://issues.apache.org/jira/browse/GEODE-3699 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Michael Dodge >Assignee: Michael Dodge > > The gradle target build produces messages similar to: > The Task.leftShift(Closure) method has been deprecated and is scheduled to be > removed in Gradle 5.0. Please use Task.doLast(Action) instead. > at > dependency_resolution_4mwsjq1wats4p3ew7q043cll9$_run_closure1.doCall(/Users/mdodge/geode/gradle/dependency-resolution.gradle:20) > The messages arise because the use of '<<' has been deprecated and 'doLast' > is the recommended replacement. '<<' is used in a handful of places in the > gradle files and ought to be replaced with 'doLast'. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3187) CI failure (windows): org.apache.geode.internal.cache.persistence.BackupInspectorJUnitTest.testIncrementalBackupScript
[ https://issues.apache.org/jira/browse/GEODE-3187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179825#comment-16179825 ] ASF subversion and git services commented on GEODE-3187: Commit 94dcc622c0a9615df4bf83dc57653eb749bbd0b1 in geode's branch refs/heads/develop from [~lgallinat] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=94dcc62 ] GEODE-3187 Fix backup inspector and restore script for windows. Refactor RestoreScript.java and BackupInspector.java > CI failure (windows): > org.apache.geode.internal.cache.persistence.BackupInspectorJUnitTest.testIncrementalBackupScript > -- > > Key: GEODE-3187 > URL: https://issues.apache.org/jira/browse/GEODE-3187 > Project: Geode > Issue Type: Bug > Components: persistence >Reporter: Lynn Gallinat >Assignee: Lynn Gallinat > Labels: storage_3, windows_test > Fix For: 1.3.0 > > > {noformat} > org.apache.geode.internal.cache.persistence.BackupInspectorJUnitTest > > testIncrementalBackupScript FAILED > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at > org.apache.geode.internal.cache.persistence.BackupInspectorJUnitTest.testIncrementalBackupScript(BackupInspectorJUnitTest.java:198) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3699) Remove use of Task.leftShift in gradle
Michael Dodge created GEODE-3699: Summary: Remove use of Task.leftShift in gradle Key: GEODE-3699 URL: https://issues.apache.org/jira/browse/GEODE-3699 Project: Geode Issue Type: Improvement Components: build Reporter: Michael Dodge The gradle target build produces messages similar to: The Task.leftShift(Closure) method has been deprecated and is scheduled to be removed in Gradle 5.0. Please use Task.doLast(Action) instead. at dependency_resolution_4mwsjq1wats4p3ew7q043cll9$_run_closure1.doCall(/Users/mdodge/geode/gradle/dependency-resolution.gradle:20) The messages arise because the use of '<<' has been deprecated and 'doLast' is the recommended replacement. '<<' is used in a handful of places in the gradle files and ought to be replaced with 'doLast'. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3632) LocalDataSet.getAll -- NotAuthorizedExceptions should be thrown, not only logged.
[ https://issues.apache.org/jira/browse/GEODE-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg updated GEODE-3632: Component/s: (was: querying) core > LocalDataSet.getAll -- NotAuthorizedExceptions should be thrown, not only > logged. > - > > Key: GEODE-3632 > URL: https://issues.apache.org/jira/browse/GEODE-3632 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Patrick Rhomberg > > Refer to the geode-example clientSecurity, currently in [pull request > 17](https://github.com/apache/geode-examples/pull/17). Unauthorized getAll > method calls log the lack of authorization but do not rethrow the exception. > This is inconsistent with behavior of put, putAll, and get. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3697) New protocol - destroy region message
Brian Baynes created GEODE-3697: --- Summary: New protocol - destroy region message Key: GEODE-3697 URL: https://issues.apache.org/jira/browse/GEODE-3697 Project: Geode Issue Type: New Feature Components: client/server Reporter: Brian Baynes As a dev using the new protocol, I'd like to be able to destroy regions using the protocol. [Scope/additional details forthcoming] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3695) Remove unused protobuf messages from new protocol
Brian Baynes created GEODE-3695: --- Summary: Remove unused protobuf messages from new protocol Key: GEODE-3695 URL: https://issues.apache.org/jira/browse/GEODE-3695 Project: Geode Issue Type: Task Components: client/server Reporter: Brian Baynes In the interest of clarity and to avoid confusion, remove any unused protobuf messages/handlers from the new protocol code (e.g., create/destroy region messages). We'll add these back as we implement the messages. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3694) New protocol should create unique client IDs
Brian Baynes created GEODE-3694: --- Summary: New protocol should create unique client IDs Key: GEODE-3694 URL: https://issues.apache.org/jira/browse/GEODE-3694 Project: Geode Issue Type: Improvement Components: client/server Reporter: Brian Baynes As a dev/admin using the new protocol, I'd like to be able to see client connection/socket use in the aggregate -- for example, if I have a single client opening many more sockets than others, this info may help me figure out if there's a problem. Just knowing the kind of load a particular client may be introducing would also be valuable. Implement unique client IDs for new protocol clients so we can associate multiple connections from the same client with one another. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3590) Disconnect command fails to an NPE when executed from the command line.
[ https://issues.apache.org/jira/browse/GEODE-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg updated GEODE-3590: Labels: gfsh (was: ) > Disconnect command fails to an NPE when executed from the command line. > --- > > Key: GEODE-3590 > URL: https://issues.apache.org/jira/browse/GEODE-3590 > Project: Geode > Issue Type: Bug >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg > Labels: gfsh > > Should a script desire to disconnect from one cluster and connect to another, > it will fail without the continue-on-error option set. > To reproduce: > {noformat} > $> gfsh -e "start locator" -e "disconnect" > (1) Executing - start locator > > Locator in [...] is currently online. > [Details banner] > Successfully connected to: JMX Manager [host=10.118.33.172, port=1099] > Cluster configuration service is up and running. > (2) Executing - disconnect > Disconnecting from: 10.118.33.172[1099] > Error occurred while disconnecting: null > {noformat} > Cause of NPE is in the disconnect command, currently belonging to > ShellCommands.disconnect:199 in the line > {noformat} > > gfshInstance.setPromptPath(RegionPathConverter.DEFAULT_APP_CONTEXT_PATH); > {noformat} > which attempts to invoke a method on the member `reader`, which has not been > initialized in headless mode. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GEODE-3693) Improve test coverage of PartitionedRegions
[ https://issues.apache.org/jira/browse/GEODE-3693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-3693: Assignee: Kirk Lund > Improve test coverage of PartitionedRegions > --- > > Key: GEODE-3693 > URL: https://issues.apache.org/jira/browse/GEODE-3693 > Project: Geode > Issue Type: Test > Components: regions, tests >Reporter: Kirk Lund >Assignee: Kirk Lund > > We need to improve test coverage of PartitionedRegions involving > CacheListener callbacks and lifecycle (create/close/destroy/recreate). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3693) Improve test coverage of PartitionedRegions
Kirk Lund created GEODE-3693: Summary: Improve test coverage of PartitionedRegions Key: GEODE-3693 URL: https://issues.apache.org/jira/browse/GEODE-3693 Project: Geode Issue Type: Test Components: regions, tests Reporter: Kirk Lund We need to improve test coverage of PartitionedRegions involving CacheListener callbacks and lifecycle (create/close/destroy/recreate). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (GEODE-3678) When a member is lost, gateway sender queues are not synchronized with surviving members
[ https://issues.apache.org/jira/browse/GEODE-3678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barry Oglesby resolved GEODE-3678. -- Resolution: Fixed Fix Version/s: 1.3.0 > When a member is lost, gateway sender queues are not synchronized with > surviving members > > > Key: GEODE-3678 > URL: https://issues.apache.org/jira/browse/GEODE-3678 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Barry Oglesby >Assignee: Barry Oglesby > Fix For: 1.3.0 > > > DistributedRegion synchronizeForLostMember is invoked in each surviving > member. This method synchronizes the region with all replicates as long as > concurrency checks are enabled for that region. Concurrency checks are > disabled for GatewaySender queue regions so they don't get synchronized. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3692) Intermittent test failure: ClientAuthDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179500#comment-16179500 ] ASF subversion and git services commented on GEODE-3692: Commit 8dd29920193f91140b499d35ee9681bd3e3aa90e in geode's branch refs/heads/develop from [~khowe] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8dd2992 ] GEODE-3692: Add Flaky tag to intemittent test failure > Intermittent test failure: ClientAuthDUnitTest > -- > > Key: GEODE-3692 > URL: https://issues.apache.org/jira/browse/GEODE-3692 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.2.1 >Reporter: Kenneth Howe > > This {{authWithCorrectPasswordShouldPass}} fails intermittently in Geode > nightly builds. > {code} > [vm1] [info 2017/09/19 21:27:57.967 UTC tid=0x1bc] > Error prefilling connections : > org.apache.geode.security.AuthenticationFailedException: No SecurityManager > accessible to the calling code, either bound to the > org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an > invalid application configuration. > [vm1] org.apache.geode.security.AuthenticationFailedException: No > SecurityManager accessible to the calling code, either bound to the > org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an > invalid application configuration. > [vm1] at > org.apache.geode.internal.cache.tier.sockets.HandShake.verifyCredentials(HandShake.java:1696) > [vm1] at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.setCredentials(ServerConnection.java:1029) > [vm1] at > org.apache.geode.internal.cache.tier.sockets.command.PutUserCredentials.cmdExecute(PutUserCredentials.java:52) > [vm1] at > org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:162) > [vm1] at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:785) > [vm1] at > org.apache.geode.internal.cache.tier.sockets.LegacyServerConnection.doOneMessage(LegacyServerConnection.java:85) > [vm1] at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1166) > [vm1] at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > [vm1] at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > [vm1] at > org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:557) > [vm1] at java.lang.Thread.run(Thread.java:748) > [vm1] Caused by: org.apache.shiro.UnavailableSecurityManagerException: No > SecurityManager accessible to the calling code, either bound to the > org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an > invalid application configuration. > [vm1] at > org.apache.shiro.SecurityUtils.getSecurityManager(SecurityUtils.java:123) > [vm1] at > org.apache.shiro.subject.Subject$Builder.(Subject.java:627) > [vm1] at > org.apache.shiro.SecurityUtils.getSubject(SecurityUtils.java:56) > [vm1] at > org.apache.geode.internal.security.IntegratedSecurityService.login(IntegratedSecurityService.java:133) > [vm1] at > org.apache.geode.internal.cache.tier.sockets.HandShake.verifyCredentials(HandShake.java:1686) > [vm1] ... 10 more > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3678) When a member is lost, gateway sender queues are not synchronized with surviving members
[ https://issues.apache.org/jira/browse/GEODE-3678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179450#comment-16179450 ] ASF subversion and git services commented on GEODE-3678: Commit af4012f5f934c7e8f21025c528d8ba18e3aad794 in geode's branch refs/heads/develop from [~barry.oglesby] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=af4012f ] GEODE-3678: Added support to synchronize parallel gateway sender queues > When a member is lost, gateway sender queues are not synchronized with > surviving members > > > Key: GEODE-3678 > URL: https://issues.apache.org/jira/browse/GEODE-3678 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Barry Oglesby >Assignee: Barry Oglesby > > DistributedRegion synchronizeForLostMember is invoked in each surviving > member. This method synchronizes the region with all replicates as long as > concurrency checks are enabled for that region. Concurrency checks are > disabled for GatewaySender queue regions so they don't get synchronized. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3692) Intermittent test failure: ClientAuthDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe updated GEODE-3692: Affects Version/s: 1.2.1 Description: This {{authWithCorrectPasswordShouldPass}} fails intermittently in Geode nightly builds. {code} [vm1] [info 2017/09/19 21:27:57.967 UTC tid=0x1bc] Error prefilling connections : org.apache.geode.security.AuthenticationFailedException: No SecurityManager accessible to the calling code, either bound to the org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an invalid application configuration. [vm1] org.apache.geode.security.AuthenticationFailedException: No SecurityManager accessible to the calling code, either bound to the org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an invalid application configuration. [vm1] at org.apache.geode.internal.cache.tier.sockets.HandShake.verifyCredentials(HandShake.java:1696) [vm1] at org.apache.geode.internal.cache.tier.sockets.ServerConnection.setCredentials(ServerConnection.java:1029) [vm1] at org.apache.geode.internal.cache.tier.sockets.command.PutUserCredentials.cmdExecute(PutUserCredentials.java:52) [vm1] at org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:162) [vm1] at org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:785) [vm1] at org.apache.geode.internal.cache.tier.sockets.LegacyServerConnection.doOneMessage(LegacyServerConnection.java:85) [vm1] at org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1166) [vm1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [vm1] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [vm1] at org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:557) [vm1] at java.lang.Thread.run(Thread.java:748) [vm1] Caused by: org.apache.shiro.UnavailableSecurityManagerException: No SecurityManager accessible to the calling code, either bound to the org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an invalid application configuration. [vm1] at org.apache.shiro.SecurityUtils.getSecurityManager(SecurityUtils.java:123) [vm1] at org.apache.shiro.subject.Subject$Builder.(Subject.java:627) [vm1] at org.apache.shiro.SecurityUtils.getSubject(SecurityUtils.java:56) [vm1] at org.apache.geode.internal.security.IntegratedSecurityService.login(IntegratedSecurityService.java:133) [vm1] at org.apache.geode.internal.cache.tier.sockets.HandShake.verifyCredentials(HandShake.java:1686) [vm1] ... 10 more {code} was: {code} [vm1] [info 2017/09/19 21:27:57.967 UTC tid=0x1bc] Error prefilling connections : org.apache.geode.security.AuthenticationFailedException: No SecurityManager accessible to the calling code, either bound to the org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an invalid application configuration. [vm1] org.apache.geode.security.AuthenticationFailedException: No SecurityManager accessible to the calling code, either bound to the org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an invalid application configuration. [vm1] at org.apache.geode.internal.cache.tier.sockets.HandShake.verifyCredentials(HandShake.java:1696) [vm1] at org.apache.geode.internal.cache.tier.sockets.ServerConnection.setCredentials(ServerConnection.java:1029) [vm1] at org.apache.geode.internal.cache.tier.sockets.command.PutUserCredentials.cmdExecute(PutUserCredentials.java:52) [vm1] at org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:162) [vm1] at org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:785) [vm1] at org.apache.geode.internal.cache.tier.sockets.LegacyServerConnection.doOneMessage(LegacyServerConnection.java:85) [vm1] at org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1166) [vm1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [vm1] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [vm1] at org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:557) [vm1] at java.lang.Thread.run(Thread.java:748) [vm1] Caused by: org.apache.shiro.UnavailableSecurityManagerException: No SecurityManager accessible to the calling code, either bound to the org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an invalid application configuration. [vm1] at org.apache.shiro.SecurityUtils.getSecurityManager(SecurityUtils.java:123) [vm1] at org.apache.shiro.subject.Subject$Builder.(Subject.java:627) [vm1] at org.apache.shiro.SecurityUtils.getSubject(SecurityUtils.java:56) [vm1] at
[jira] [Created] (GEODE-3692) Intermittent test failure: ClientAuthDUnitTest
Kenneth Howe created GEODE-3692: --- Summary: Intermittent test failure: ClientAuthDUnitTest Key: GEODE-3692 URL: https://issues.apache.org/jira/browse/GEODE-3692 Project: Geode Issue Type: Bug Components: gfsh Reporter: Kenneth Howe {code} [vm1] [info 2017/09/19 21:27:57.967 UTC tid=0x1bc] Error prefilling connections : org.apache.geode.security.AuthenticationFailedException: No SecurityManager accessible to the calling code, either bound to the org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an invalid application configuration. [vm1] org.apache.geode.security.AuthenticationFailedException: No SecurityManager accessible to the calling code, either bound to the org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an invalid application configuration. [vm1] at org.apache.geode.internal.cache.tier.sockets.HandShake.verifyCredentials(HandShake.java:1696) [vm1] at org.apache.geode.internal.cache.tier.sockets.ServerConnection.setCredentials(ServerConnection.java:1029) [vm1] at org.apache.geode.internal.cache.tier.sockets.command.PutUserCredentials.cmdExecute(PutUserCredentials.java:52) [vm1] at org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:162) [vm1] at org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:785) [vm1] at org.apache.geode.internal.cache.tier.sockets.LegacyServerConnection.doOneMessage(LegacyServerConnection.java:85) [vm1] at org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1166) [vm1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [vm1] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [vm1] at org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:557) [vm1] at java.lang.Thread.run(Thread.java:748) [vm1] Caused by: org.apache.shiro.UnavailableSecurityManagerException: No SecurityManager accessible to the calling code, either bound to the org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an invalid application configuration. [vm1] at org.apache.shiro.SecurityUtils.getSecurityManager(SecurityUtils.java:123) [vm1] at org.apache.shiro.subject.Subject$Builder.(Subject.java:627) [vm1] at org.apache.shiro.SecurityUtils.getSubject(SecurityUtils.java:56) [vm1] at org.apache.geode.internal.security.IntegratedSecurityService.login(IntegratedSecurityService.java:133) [vm1] at org.apache.geode.internal.cache.tier.sockets.HandShake.verifyCredentials(HandShake.java:1686) [vm1] ... 10 more {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GEODE-3473) Change new protocol package to use *internal* naming convention
[ https://issues.apache.org/jira/browse/GEODE-3473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dodge reassigned GEODE-3473: Assignee: Michael Dodge > Change new protocol package to use *internal* naming convention > --- > > Key: GEODE-3473 > URL: https://issues.apache.org/jira/browse/GEODE-3473 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Brian Baynes >Assignee: Michael Dodge > Fix For: 1.3.0 > > > New protocol needs to follow established conventions for Geode APIs. > Change new protocol package to use *internal* naming convention. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3691) Create new geode-example about cache writers
[ https://issues.apache.org/jira/browse/GEODE-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dodge updated GEODE-3691: - Description: Create an example of a cache writer. (was: Create an example of a cache loader and a cache writer.) Summary: Create new geode-example about cache writers (was: Create new geode-example about cache loaders and cache writers) > Create new geode-example about cache writers > > > Key: GEODE-3691 > URL: https://issues.apache.org/jira/browse/GEODE-3691 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Michael Dodge >Assignee: Michael Dodge > > Create an example of a cache writer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3691) Create new geode-example about cache loaders and cache writers
Michael Dodge created GEODE-3691: Summary: Create new geode-example about cache loaders and cache writers Key: GEODE-3691 URL: https://issues.apache.org/jira/browse/GEODE-3691 Project: Geode Issue Type: New Feature Components: examples Reporter: Michael Dodge Create an example of a cache loader and a cache writer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GEODE-3691) Create new geode-example about cache loaders and cache writers
[ https://issues.apache.org/jira/browse/GEODE-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dodge reassigned GEODE-3691: Assignee: Michael Dodge > Create new geode-example about cache loaders and cache writers > -- > > Key: GEODE-3691 > URL: https://issues.apache.org/jira/browse/GEODE-3691 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Michael Dodge >Assignee: Michael Dodge > > Create an example of a cache loader and a cache writer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3688) Query engine cannot compare int to long
[ https://issues.apache.org/jira/browse/GEODE-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179255#comment-16179255 ] Jason Huynh commented on GEODE-3688: The query would work if you add the L to let the query engine know to covert it to a long. "select c.name from /customer c where c.id=9L" > Query engine cannot compare int to long > --- > > Key: GEODE-3688 > URL: https://issues.apache.org/jira/browse/GEODE-3688 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Swapnil Bawaskar > > I created an object with a long field: > {noformat} > public class Customer implements Serializable { > private long id; > private String name; > private String address; > private List accounts; > ... > } > {noformat} > and inserted 10 objects (with id 0 to 9) but the simple query to get customer > with id=9 did not give any results > {noformat} > gfsh>query --query=" select c.name from /customer c where c.id=9" > Result : true > Limit : 100 > Rows : 0 > {noformat} > I then changed the domain object to make id an {{int}} type after which the > query worked: > {noformat} > gfsh>query --query=" select c.name from /customer c where c.id=9" > Result : true > Limit : 100 > Rows : 1 > Result > -- > Customer_9 > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3690) References to generating self signed certs should use '-keyalg EC'
Jens Deppe created GEODE-3690: - Summary: References to generating self signed certs should use '-keyalg EC' Key: GEODE-3690 URL: https://issues.apache.org/jira/browse/GEODE-3690 Project: Geode Issue Type: Bug Components: docs Reporter: Jens Deppe After looking at an issue on StackOverflow, it seems that wherever we're providing an example of creating a self-signed certificate using {{keytool}}, that we now also need to specify a key algorithm with {{-keyalg EC}}, otherwise the certificates may not be useable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[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 ] Jens Deppe updated GEODE-3689: -- Summary: Unable to specify custom log4j configuration file from gfsh (was: Unable to set custom log4j configuration from gfsh) > 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 > > 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 (v6.4.14#64029)
[jira] [Created] (GEODE-3689) Unable to set custom log4j configuration from gfsh
Jens Deppe created GEODE-3689: - Summary: Unable to set custom log4j configuration 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 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 (v6.4.14#64029)