[jira] [Created] (GEODE-3703) rename JAR resource to DEPLOY

2017-09-25 Thread Swapnil Bawaskar (JIRA)
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

2017-09-25 Thread Karen Smoler Miller (JIRA)

 [ 
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

2017-09-25 Thread ASF subversion and git services (JIRA)

[ 
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

2017-09-25 Thread Dan Smith (JIRA)
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

2017-09-25 Thread Dan Smith (JIRA)

 [ 
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

2017-09-25 Thread Karen Smoler Miller (JIRA)
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

2017-09-25 Thread Shelley Lynn Hughes-Godfrey (JIRA)

 [ 
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

2017-09-25 Thread Jared Stewart (JIRA)

 [ 
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

2017-09-25 Thread Jared Stewart (JIRA)

 [ 
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

2017-09-25 Thread Jared Stewart (JIRA)

 [ 
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

2017-09-25 Thread Jared Stewart (JIRA)

 [ 
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

2017-09-25 Thread Jared Stewart (JIRA)

 [ 
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

2017-09-25 Thread Jared Stewart (JIRA)

 [ 
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

2017-09-25 Thread Jared Stewart (JIRA)

 [ 
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

2017-09-25 Thread Jared Stewart (JIRA)

 [ 
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

2017-09-25 Thread Jared Stewart (JIRA)
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

2017-09-25 Thread Lynn Gallinat (JIRA)

 [ 
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 Gallinat 
Date:   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

2017-09-25 Thread Michael Dodge (JIRA)

 [ 
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

2017-09-25 Thread ASF subversion and git services (JIRA)

[ 
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

2017-09-25 Thread Michael Dodge (JIRA)
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.

2017-09-25 Thread Patrick Rhomberg (JIRA)

 [ 
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

2017-09-25 Thread Brian Baynes (JIRA)
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

2017-09-25 Thread Brian Baynes (JIRA)
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

2017-09-25 Thread Brian Baynes (JIRA)
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.

2017-09-25 Thread Patrick Rhomberg (JIRA)

 [ 
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

2017-09-25 Thread Kirk Lund (JIRA)

 [ 
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

2017-09-25 Thread Kirk Lund (JIRA)
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

2017-09-25 Thread Barry Oglesby (JIRA)

 [ 
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

2017-09-25 Thread ASF subversion and git services (JIRA)

[ 
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

2017-09-25 Thread ASF subversion and git services (JIRA)

[ 
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

2017-09-25 Thread Kenneth Howe (JIRA)

 [ 
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

2017-09-25 Thread Kenneth Howe (JIRA)
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

2017-09-25 Thread Michael Dodge (JIRA)

 [ 
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

2017-09-25 Thread Michael Dodge (JIRA)

 [ 
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

2017-09-25 Thread Michael Dodge (JIRA)
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

2017-09-25 Thread Michael Dodge (JIRA)

 [ 
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

2017-09-25 Thread Jason Huynh (JIRA)

[ 
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'

2017-09-25 Thread Jens Deppe (JIRA)
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

2017-09-25 Thread Jens Deppe (JIRA)

 [ 
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

2017-09-25 Thread Jens Deppe (JIRA)
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)