[jira] [Created] (GEODE-3031) Extract startLocator and startServer from LauncherLifecycleCommands

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-3031:


 Summary: Extract startLocator and startServer from 
LauncherLifecycleCommands
 Key: GEODE-3031
 URL: https://issues.apache.org/jira/browse/GEODE-3031
 Project: Geode
  Issue Type: Improvement
  Components: gfsh
Reporter: Jared Stewart


LauncherLifecycleCommands is a huge class that contains both startServer and 
startLocator.  We ought to extract those command methods into their own 
classes, and figure out a sensible home for the shared, common methods from 
LauncherLifecycleCommands used by both commands.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-3007) Simplify support for custom GFSH commands

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-3007:


Assignee: Jared Stewart

> Simplify support for custom GFSH commands
> -
>
> Key: GEODE-3007
> URL: https://issues.apache.org/jira/browse/GEODE-3007
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> Geode currently supports three ways to load GFSH commands: 
> 1. Scan the classpath for commands in 
> "org.apache.geode.management.internal.cli.commands”
> 2. Scan the classpath for commands in a package specified by a user via the 
> “user-command-packages” system property. 
> 3. Scan the classpath for commands registered in files inside 
> META-INF.services (e.g. 
> "geode-core/src/test/resources/META-INF/services/org.springframework.shell.core.CommandMarker”)
>  
> After the improvements made by GEODE-2989, there is no reason to require a 
> user to specify the location of their custom commands via one of these 
> mechanisms.  Instead, we should simply scan the entire classpath for any 
> classes implementing CommandMarker (regardless of whatever packages they live 
> in).  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2989) Improve mechanism for scanning the classpath to find gfsh commands

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2989.
--
Resolution: Fixed

> Improve mechanism for scanning the classpath to find gfsh commands
> --
>
> Key: GEODE-2989
> URL: https://issues.apache.org/jira/browse/GEODE-2989
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh, management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.3.0
>
>
> The current mechanism for scanning the classpath to find gfsh commands 
> (ClasspathScanLoadHelper) has some deficiencies, including: 
> 1) Commands can only be scanned for in an exact package 
> ("org.apache.geode.management.internal.cli.commands").  We can't pick up 
> commands from any subpackages,  prevents us from better organizing the 
> package structure of our commands (e.g. 
> "org.apache.geode.management.internal.cli.commands.lifecycle").
> 2) All classes in the target package are eagerly loaded, whether or not they 
> contain commands.  
> Both of these deficiencies can be removed if we replace the implementation of 
> ClasspathScanLoadHelper with calls to FastClasspathScanner.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2933) jmx-manager-hostname-for-clients should be a gfsh option

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2933:
-
Fix Version/s: 1.3.0

> jmx-manager-hostname-for-clients should be a gfsh option
> 
>
> Key: GEODE-2933
> URL: https://issues.apache.org/jira/browse/GEODE-2933
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Swapnil Bawaskar
>Assignee: Jared Stewart
>
> When jmx manager is started in the cloud, the command to start the locator so 
> that one can connect gfsh from outside the cloud is:
> {noformat}
> start locator --name=test 
> --J=-Dgemfire.jmx-manager-hostname-for-clients=
> {noformat}
> We should make jmx-manager-hostname-for-clients a top level option to the 
> {{start server}} and {{start locator}} commands.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2966) Refactor LauncherLifecycleCommands

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2966:
-
Fix Version/s: 1.3.0

> Refactor LauncherLifecycleCommands
> --
>
> Key: GEODE-2966
> URL: https://issues.apache.org/jira/browse/GEODE-2966
> Project: Geode
>  Issue Type: Sub-task
>  Components: gfsh, management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.3.0
>
>
> LauncherLifecycleCommands is over 2000 lines of code, and could be made a lot 
> more readable by introducing proper OO abstraction.  There are also many 
> private static final strings like {{CliStrings.START_LOCATOR__MEMBER_NAME}} 
> that could be made shorter and more contextual, e.g. 
> {{StartLocatorCommand.MEMBER_NAME}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2933) jmx-manager-hostname-for-clients should be a gfsh option

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2933:
-
Fix Version/s: (was: 1.3.0)

> jmx-manager-hostname-for-clients should be a gfsh option
> 
>
> Key: GEODE-2933
> URL: https://issues.apache.org/jira/browse/GEODE-2933
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Swapnil Bawaskar
>Assignee: Jared Stewart
>
> When jmx manager is started in the cloud, the command to start the locator so 
> that one can connect gfsh from outside the cloud is:
> {noformat}
> start locator --name=test 
> --J=-Dgemfire.jmx-manager-hostname-for-clients=
> {noformat}
> We should make jmx-manager-hostname-for-clients a top level option to the 
> {{start server}} and {{start locator}} commands.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2989) Improve mechanism for scanning the classpath to find gfsh commands

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2989:
-
Fix Version/s: 1.3.0

> Improve mechanism for scanning the classpath to find gfsh commands
> --
>
> Key: GEODE-2989
> URL: https://issues.apache.org/jira/browse/GEODE-2989
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh, management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.3.0
>
>
> The current mechanism for scanning the classpath to find gfsh commands 
> (ClasspathScanLoadHelper) has some deficiencies, including: 
> 1) Commands can only be scanned for in an exact package 
> ("org.apache.geode.management.internal.cli.commands").  We can't pick up 
> commands from any subpackages,  prevents us from better organizing the 
> package structure of our commands (e.g. 
> "org.apache.geode.management.internal.cli.commands.lifecycle").
> 2) All classes in the target package are eagerly loaded, whether or not they 
> contain commands.  
> Both of these deficiencies can be removed if we replace the implementation of 
> ClasspathScanLoadHelper with calls to FastClasspathScanner.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-3007) Simplify support for custom GFSH commands

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-3007:


 Summary: Simplify support for custom GFSH commands
 Key: GEODE-3007
 URL: https://issues.apache.org/jira/browse/GEODE-3007
 Project: Geode
  Issue Type: Improvement
  Components: gfsh
Reporter: Jared Stewart


Geode currently supports three ways to load GFSH commands: 

1. Scan the classpath for commands in 
"org.apache.geode.management.internal.cli.commands”
2. Scan the classpath for commands in a package specified by a user via the 
“user-command-packages” system property. 
3. Scan the classpath for commands registered in files inside META-INF.services 
(e.g. 
"geode-core/src/test/resources/META-INF/services/org.springframework.shell.core.CommandMarker”)
 

After the improvements made by GEODE-2989, there is no reason to require a user 
to specify the location of their custom commands via one of these mechanisms.  
Instead, we should simply scan the entire classpath for any classes 
implementing CommandMarker (regardless of whatever packages they live in).  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2989) Improve mechanism for scanning the classpath to find gfsh commands

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2989:


Assignee: Jared Stewart

> Improve mechanism for scanning the classpath to find gfsh commands
> --
>
> Key: GEODE-2989
> URL: https://issues.apache.org/jira/browse/GEODE-2989
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh, management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> The current mechanism for scanning the classpath to find gfsh commands 
> (ClasspathScanLoadHelper) has some deficiencies, including: 
> 1) Commands can only be scanned for in an exact package 
> ("org.apache.geode.management.internal.cli.commands").  We can't pick up 
> commands from any subpackages,  prevents us from better organizing the 
> package structure of our commands (e.g. 
> "org.apache.geode.management.internal.cli.commands.lifecycle").
> 2) All classes in the target package are eagerly loaded, whether or not they 
> contain commands.  
> Both of these deficiencies can be removed if we replace the implementation of 
> ClasspathScanLoadHelper with calls to FastClasspathScanner.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2989) Improve mechanism for scanning the classpath to find gfsh commands

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2989:


 Summary: Improve mechanism for scanning the classpath to find gfsh 
commands
 Key: GEODE-2989
 URL: https://issues.apache.org/jira/browse/GEODE-2989
 Project: Geode
  Issue Type: Improvement
  Components: gfsh, management
Reporter: Jared Stewart


The current mechanism for scanning the classpath to find gfsh commands 
(ClasspathScanLoadHelper) has some deficiencies, including: 

1) Commands can only be scanned for in an exact package 
("org.apache.geode.management.internal.cli.commands").  We can't pick up 
commands from any subpackages,  prevents us from better organizing the package 
structure of our commands (e.g. 
"org.apache.geode.management.internal.cli.commands.lifecycle").

2) All classes in the target package are eagerly loaded, whether or not they 
contain commands.  

Both of these deficiencies can be removed if we replace the implementation of 
ClasspathScanLoadHelper with calls to FastClasspathScanner.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2966) Refactor LauncherLifecycleCommands

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2966:
-
Description: LauncherLifecycleCommands is over 2000 lines of code, and 
could be made a lot more readable by introducing proper OO abstraction.  There 
are also many private static final strings like 
{{CliStrings.START_LOCATOR__MEMBER_NAME}} that could be made shorter and more 
contextual, e.g. {{StartLocatorCommand.MEMBER_NAME}}.  (was: 
LauncherLifecycleCommands is over 2000 lines of code, and could be made a lot 
more readable by introducing proper OO abstraction.  There are also many 
private static final strings like `CliStrings.START_LOCATOR__MEMBER_NAME` that 
could be made shorter and more contextual, e.g. 
`StartLocatorCommand.MEMBER_NAME`.)

> Refactor LauncherLifecycleCommands
> --
>
> Key: GEODE-2966
> URL: https://issues.apache.org/jira/browse/GEODE-2966
> Project: Geode
>  Issue Type: Sub-task
>  Components: gfsh, management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> LauncherLifecycleCommands is over 2000 lines of code, and could be made a lot 
> more readable by introducing proper OO abstraction.  There are also many 
> private static final strings like {{CliStrings.START_LOCATOR__MEMBER_NAME}} 
> that could be made shorter and more contextual, e.g. 
> {{StartLocatorCommand.MEMBER_NAME}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2966) Refactor LauncherLifecycleCommands

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2966:


Assignee: Jared Stewart

> Refactor LauncherLifecycleCommands
> --
>
> Key: GEODE-2966
> URL: https://issues.apache.org/jira/browse/GEODE-2966
> Project: Geode
>  Issue Type: Sub-task
>  Components: gfsh, management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> LauncherLifecycleCommands is over 2000 lines of code, and could be made a lot 
> more readable by introducing proper OO abstraction.  There are also many 
> private static final strings like `CliStrings.START_LOCATOR__MEMBER_NAME` 
> that could be made shorter and more contextual, e.g. 
> `StartLocatorCommand.MEMBER_NAME`.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2966) Refactor LauncherLifecycleCommands

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2966:


 Summary: Refactor LauncherLifecycleCommands
 Key: GEODE-2966
 URL: https://issues.apache.org/jira/browse/GEODE-2966
 Project: Geode
  Issue Type: Sub-task
  Components: gfsh, management
Reporter: Jared Stewart


LauncherLifecycleCommands is over 2000 lines of code, and could be made a lot 
more readable by introducing proper OO abstraction.  There are also many 
private static final strings like `CliStrings.START_LOCATOR__MEMBER_NAME` that 
could be made shorter and more contextual, e.g. 
`StartLocatorCommand.MEMBER_NAME`.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2933) jmx-manager-hostname-for-clients should be a gfsh option

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2933:


Assignee: Jared Stewart

> jmx-manager-hostname-for-clients should be a gfsh option
> 
>
> Key: GEODE-2933
> URL: https://issues.apache.org/jira/browse/GEODE-2933
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Assignee: Jared Stewart
>
> When jmx manager is started in the cloud, the command to start the locator so 
> that one can connect gfsh from outside the cloud is:
> {noformat}
> start locator --name=test 
> --J=-Dgemfire.jmx-manager-hostname-for-clients=
> {noformat}
> We should make jmx-manager-hostname-for-clients a top level option to the 
> {{start server}} and {{start locator}} commands.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2874) StringIndexOutOfBoundsException while initializing logger

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2874:
-
Fix Version/s: 1.2.0

> StringIndexOutOfBoundsException while initializing logger
> -
>
> Key: GEODE-2874
> URL: https://issues.apache.org/jira/browse/GEODE-2874
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
> index out of range: -1
>   at java.lang.String.substring(String.java:1967)
>   at 
> org.apache.geode.internal.io.MainWithChildrenRollingFileHandler.calcNextChildId(MainWithChildrenRollingFileHandler.java:47)
>   at 
> org.apache.geode.internal.logging.ManagerLogWriter.getLogNameForOldMainLog(ManagerLogWriter.java:330)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.createLogWriterAppender(LogWriterAppenders.java:144)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:72)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:88)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:591)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:304)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:207)
>   at GeodeClient.GeodeClient(GeodeClient.java:22)
>   at GeodeClient.main(GeodeClient.java:10)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2874) StringIndexOutOfBoundsException while initializing logger

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2874.
--
Resolution: Fixed

> StringIndexOutOfBoundsException while initializing logger
> -
>
> Key: GEODE-2874
> URL: https://issues.apache.org/jira/browse/GEODE-2874
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
> index out of range: -1
>   at java.lang.String.substring(String.java:1967)
>   at 
> org.apache.geode.internal.io.MainWithChildrenRollingFileHandler.calcNextChildId(MainWithChildrenRollingFileHandler.java:47)
>   at 
> org.apache.geode.internal.logging.ManagerLogWriter.getLogNameForOldMainLog(ManagerLogWriter.java:330)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.createLogWriterAppender(LogWriterAppenders.java:144)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:72)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:88)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:591)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:304)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:207)
>   at GeodeClient.GeodeClient(GeodeClient.java:22)
>   at GeodeClient.main(GeodeClient.java:10)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2836) CacheLoader should extend Declarable

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2836.
--
Resolution: Fixed

> CacheLoader should extend Declarable
> 
>
> Key: GEODE-2836
> URL: https://issues.apache.org/jira/browse/GEODE-2836
> Project: Geode
>  Issue Type: Improvement
>  Components: configuration
>Reporter: Anthony Baker
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> In order to implement a {{CacheLoader}} that is usable from {{cache.xml}} the 
> developer should also implement {{Declarable}}.  It would be nice to make 
> {{CacheLoader}} extend from {{Declarable}} with a default implementation for 
> {{init}} to simplify this requirement.
> Note that this could be applied to all user callbacks like {{CacheListener}} 
> and friends.
> If a developer does not implement {{Declarable}} and uses {{gfsh}} to add the 
> callback to the region, it's possible to get a startup failure since the 
> cluster config service uses {{cache.xml}} to persist config changes.  This is 
> BAD.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2836) CacheLoader should extend Declarable

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2836:


Assignee: Jared Stewart  (was: Jinmei Liao)

> CacheLoader should extend Declarable
> 
>
> Key: GEODE-2836
> URL: https://issues.apache.org/jira/browse/GEODE-2836
> Project: Geode
>  Issue Type: Improvement
>  Components: configuration
>Reporter: Anthony Baker
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> In order to implement a {{CacheLoader}} that is usable from {{cache.xml}} the 
> developer should also implement {{Declarable}}.  It would be nice to make 
> {{CacheLoader}} extend from {{Declarable}} with a default implementation for 
> {{init}} to simplify this requirement.
> Note that this could be applied to all user callbacks like {{CacheListener}} 
> and friends.
> If a developer does not implement {{Declarable}} and uses {{gfsh}} to add the 
> callback to the region, it's possible to get a startup failure since the 
> cluster config service uses {{cache.xml}} to persist config changes.  This is 
> BAD.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2859:
-
Fix Version/s: 1.2.0

> ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
> 
>
> Key: GEODE-2859
> URL: https://issues.apache.org/jira/browse/GEODE-2859
> Project: Geode
>  Issue Type: Test
>  Components: gfsh, membership, messaging, tests
>Reporter: Galen O'Sullivan
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> https://builds.apache.org/job/Geode-nightly/821/
> This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was 
> recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). 
> Probably it needs the same fix or related.
> ShowDeadlockDUnitTest.testNoDeadlock also fails in this test run.
> {code}
> Error Message
> java.lang.AssertionError
> Stacktrace
> 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.management.internal.cli.commands.ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction(ShowDeadlockDUnitTest.java:156)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 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.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:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   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.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 

[jira] [Resolved] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2859.
--
Resolution: Fixed

> ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
> 
>
> Key: GEODE-2859
> URL: https://issues.apache.org/jira/browse/GEODE-2859
> Project: Geode
>  Issue Type: Test
>  Components: gfsh, membership, messaging, tests
>Reporter: Galen O'Sullivan
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> https://builds.apache.org/job/Geode-nightly/821/
> This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was 
> recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). 
> Probably it needs the same fix or related.
> ShowDeadlockDUnitTest.testNoDeadlock also fails in this test run.
> {code}
> Error Message
> java.lang.AssertionError
> Stacktrace
> 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.management.internal.cli.commands.ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction(ShowDeadlockDUnitTest.java:156)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 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.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:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   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.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 

[jira] [Resolved] (GEODE-2912) Real hot deploy of functions via gfsh

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2912.
--
Resolution: Fixed

> Real hot deploy of functions via gfsh
> -
>
> Key: GEODE-2912
> URL: https://issues.apache.org/jira/browse/GEODE-2912
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> A user ought to be able to deploy a Jar file containing a new version of a 
> Function without resulting in any failed function executions.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2874) StringIndexOutOfBoundsException while initializing logger

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2874:


Assignee: Jared Stewart

> StringIndexOutOfBoundsException while initializing logger
> -
>
> Key: GEODE-2874
> URL: https://issues.apache.org/jira/browse/GEODE-2874
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>Assignee: Jared Stewart
>
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
> index out of range: -1
>   at java.lang.String.substring(String.java:1967)
>   at 
> org.apache.geode.internal.io.MainWithChildrenRollingFileHandler.calcNextChildId(MainWithChildrenRollingFileHandler.java:47)
>   at 
> org.apache.geode.internal.logging.ManagerLogWriter.getLogNameForOldMainLog(ManagerLogWriter.java:330)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.createLogWriterAppender(LogWriterAppenders.java:144)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:72)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:88)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:591)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:304)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:207)
>   at GeodeClient.GeodeClient(GeodeClient.java:22)
>   at GeodeClient.main(GeodeClient.java:10)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2874) StringIndexOutOfBoundsException while initializing logger

[Jared Stewart (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16007191#comment-16007191
 ] 

Jared Stewart commented on GEODE-2874:
--

[~hitesh.khamesra] Do you have any info about how to reproduce this error?  
Thanks!

> StringIndexOutOfBoundsException while initializing logger
> -
>
> Key: GEODE-2874
> URL: https://issues.apache.org/jira/browse/GEODE-2874
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
> index out of range: -1
>   at java.lang.String.substring(String.java:1967)
>   at 
> org.apache.geode.internal.io.MainWithChildrenRollingFileHandler.calcNextChildId(MainWithChildrenRollingFileHandler.java:47)
>   at 
> org.apache.geode.internal.logging.ManagerLogWriter.getLogNameForOldMainLog(ManagerLogWriter.java:330)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.createLogWriterAppender(LogWriterAppenders.java:144)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:72)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:88)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:591)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:304)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:207)
>   at GeodeClient.GeodeClient(GeodeClient.java:22)
>   at GeodeClient.main(GeodeClient.java:10)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2912) Real hot deploy of functions via gfsh

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2912:


Assignee: Jared Stewart

> Real hot deploy of functions via gfsh
> -
>
> Key: GEODE-2912
> URL: https://issues.apache.org/jira/browse/GEODE-2912
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> A user ought to be able to deploy a Jar file containing a new version of a 
> Function without resulting in any failed function executions.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2883) gfsh gc reports incorrect heap sizes

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2883:
-
Fix Version/s: 1.2.0

> gfsh gc reports incorrect heap sizes
> 
>
> Key: GEODE-2883
> URL: https://issues.apache.org/jira/browse/GEODE-2883
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1
>Reporter: Barry Oglesby
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> I have 3 servers each with -Xms1g and -Xmx1g, and I load some data.
> If I run a gfsh gc, it reports:
> {noformat}
> GC Summary
>   Member ID/Name| HeapSize (MB) Before GC | HeapSize(MB) After GC 
> | Time Taken for GC in ms
> --- | --- | - 
> | ---
> 192.168.2.7(98588):1025 | 2078| 1098  
> | 516
> 192.168.2.7(98602):1027 | 1942| 1110  
> | 530
> 192.168.2.7(98595):1026 | 2019| 1109  
> | 531
> {noformat}
> The heap sizes before and after are higher than they should be.
> I added some debugging in the GarbageCollectionFunction, and it shows:
> {noformat}
> GarbageCollectionFunction.execute freeMemoryBeforeGC=765581248; 
> totalMemoryBeforeGC=1037959168
> GarbageCollectionFunction.execute freeMemoryAfterGC=893946464; 
> totalMemoryAfterGC=1037959168
> GarbageCollectionFunction.execute HeapSizeBeforeGC=2078
> GarbageCollectionFunction.execute HeapSizeAfterGC=1098
> GarbageCollectionFunction.execute freeMemoryBeforeGC=773307528; 
> totalMemoryBeforeGC=1037959168
> GarbageCollectionFunction.execute freeMemoryAfterGC=892508088; 
> totalMemoryAfterGC=1037959168
> GarbageCollectionFunction.execute HeapSizeBeforeGC=2019
> GarbageCollectionFunction.execute HeapSizeAfterGC=1109
> GarbageCollectionFunction.execute freeMemoryBeforeGC=783373464; 
> totalMemoryBeforeGC=1037959168
> GarbageCollectionFunction.execute freeMemoryAfterGC=892349664; 
> totalMemoryAfterGC=1037959168
> GarbageCollectionFunction.execute HeapSizeBeforeGC=1942
> GarbageCollectionFunction.execute HeapSizeAfterGC=1110
> {noformat}
> The free and total memory are fine, but the heap sizes before and after are 
> incorrect.
> The function is using 131072 as its divisor
> {noformat}
> 1037959168-765581248=272377920 / 131072 = 2078
> 1037959168-893946464=144012704 / 131072 = 1098
> {noformat}
> It should be using 1024*1024.
> {noformat}
> 1037959168-765581248=272377920 / (1024*1024) = 259
> 1037959168-893946464=144012704 / (1024*1024) = 137
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2883) gfsh gc reports incorrect heap sizes

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2883:
-
Affects Version/s: 1.0.0-incubating
   1.1.0
   1.1.1

> gfsh gc reports incorrect heap sizes
> 
>
> Key: GEODE-2883
> URL: https://issues.apache.org/jira/browse/GEODE-2883
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1
>Reporter: Barry Oglesby
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> I have 3 servers each with -Xms1g and -Xmx1g, and I load some data.
> If I run a gfsh gc, it reports:
> {noformat}
> GC Summary
>   Member ID/Name| HeapSize (MB) Before GC | HeapSize(MB) After GC 
> | Time Taken for GC in ms
> --- | --- | - 
> | ---
> 192.168.2.7(98588):1025 | 2078| 1098  
> | 516
> 192.168.2.7(98602):1027 | 1942| 1110  
> | 530
> 192.168.2.7(98595):1026 | 2019| 1109  
> | 531
> {noformat}
> The heap sizes before and after are higher than they should be.
> I added some debugging in the GarbageCollectionFunction, and it shows:
> {noformat}
> GarbageCollectionFunction.execute freeMemoryBeforeGC=765581248; 
> totalMemoryBeforeGC=1037959168
> GarbageCollectionFunction.execute freeMemoryAfterGC=893946464; 
> totalMemoryAfterGC=1037959168
> GarbageCollectionFunction.execute HeapSizeBeforeGC=2078
> GarbageCollectionFunction.execute HeapSizeAfterGC=1098
> GarbageCollectionFunction.execute freeMemoryBeforeGC=773307528; 
> totalMemoryBeforeGC=1037959168
> GarbageCollectionFunction.execute freeMemoryAfterGC=892508088; 
> totalMemoryAfterGC=1037959168
> GarbageCollectionFunction.execute HeapSizeBeforeGC=2019
> GarbageCollectionFunction.execute HeapSizeAfterGC=1109
> GarbageCollectionFunction.execute freeMemoryBeforeGC=783373464; 
> totalMemoryBeforeGC=1037959168
> GarbageCollectionFunction.execute freeMemoryAfterGC=892349664; 
> totalMemoryAfterGC=1037959168
> GarbageCollectionFunction.execute HeapSizeBeforeGC=1942
> GarbageCollectionFunction.execute HeapSizeAfterGC=1110
> {noformat}
> The free and total memory are fine, but the heap sizes before and after are 
> incorrect.
> The function is using 131072 as its divisor
> {noformat}
> 1037959168-765581248=272377920 / 131072 = 2078
> 1037959168-893946464=144012704 / 131072 = 1098
> {noformat}
> It should be using 1024*1024.
> {noformat}
> 1037959168-765581248=272377920 / (1024*1024) = 259
> 1037959168-893946464=144012704 / (1024*1024) = 137
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2859:


Assignee: Jared Stewart

> ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
> 
>
> Key: GEODE-2859
> URL: https://issues.apache.org/jira/browse/GEODE-2859
> Project: Geode
>  Issue Type: Test
>  Components: gfsh, membership, messaging, tests
>Reporter: Galen O'Sullivan
>Assignee: Jared Stewart
>
> https://builds.apache.org/job/Geode-nightly/821/
> This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was 
> recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). 
> Probably it needs the same fix or related.
> ShowDeadlockDUnitTest.testNoDeadlock also fails in this test run.
> {code}
> Error Message
> java.lang.AssertionError
> Stacktrace
> 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.management.internal.cli.commands.ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction(ShowDeadlockDUnitTest.java:156)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 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.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:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   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.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 

[jira] [Assigned] (GEODE-2883) gfsh gc reports incorrect heap sizes

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2883:


Assignee: Jared Stewart

> gfsh gc reports incorrect heap sizes
> 
>
> Key: GEODE-2883
> URL: https://issues.apache.org/jira/browse/GEODE-2883
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Barry Oglesby
>Assignee: Jared Stewart
>
> I have 3 servers each with -Xms1g and -Xmx1g, and I load some data.
> If I run a gfsh gc, it reports:
> {noformat}
> GC Summary
>   Member ID/Name| HeapSize (MB) Before GC | HeapSize(MB) After GC 
> | Time Taken for GC in ms
> --- | --- | - 
> | ---
> 192.168.2.7(98588):1025 | 2078| 1098  
> | 516
> 192.168.2.7(98602):1027 | 1942| 1110  
> | 530
> 192.168.2.7(98595):1026 | 2019| 1109  
> | 531
> {noformat}
> The heap sizes before and after are higher than they should be.
> I added some debugging in the GarbageCollectionFunction, and it shows:
> {noformat}
> GarbageCollectionFunction.execute freeMemoryBeforeGC=765581248; 
> totalMemoryBeforeGC=1037959168
> GarbageCollectionFunction.execute freeMemoryAfterGC=893946464; 
> totalMemoryAfterGC=1037959168
> GarbageCollectionFunction.execute HeapSizeBeforeGC=2078
> GarbageCollectionFunction.execute HeapSizeAfterGC=1098
> GarbageCollectionFunction.execute freeMemoryBeforeGC=773307528; 
> totalMemoryBeforeGC=1037959168
> GarbageCollectionFunction.execute freeMemoryAfterGC=892508088; 
> totalMemoryAfterGC=1037959168
> GarbageCollectionFunction.execute HeapSizeBeforeGC=2019
> GarbageCollectionFunction.execute HeapSizeAfterGC=1109
> GarbageCollectionFunction.execute freeMemoryBeforeGC=783373464; 
> totalMemoryBeforeGC=1037959168
> GarbageCollectionFunction.execute freeMemoryAfterGC=892349664; 
> totalMemoryAfterGC=1037959168
> GarbageCollectionFunction.execute HeapSizeBeforeGC=1942
> GarbageCollectionFunction.execute HeapSizeAfterGC=1110
> {noformat}
> The free and total memory are fine, but the heap sizes before and after are 
> incorrect.
> The function is using 131072 as its divisor
> {noformat}
> 1037959168-765581248=272377920 / 131072 = 2078
> 1037959168-893946464=144012704 / 131072 = 1098
> {noformat}
> It should be using 1024*1024.
> {noformat}
> 1037959168-765581248=272377920 / (1024*1024) = 259
> 1037959168-893946464=144012704 / (1024*1024) = 137
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2876) CI Failure: org.apache.geode.management.internal.cli.commands.ConcurrentDeployDUnitTest#testMultipleGfshClientToOneServer

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2876:


 Summary: CI Failure: 
org.apache.geode.management.internal.cli.commands.ConcurrentDeployDUnitTest#testMultipleGfshClientToOneServer
 Key: GEODE-2876
 URL: https://issues.apache.org/jira/browse/GEODE-2876
 Project: Geode
  Issue Type: Bug
  Components: gfsh, management
Reporter: Jared Stewart


ConcurrentDeployDUnitTest is failing due to a parsing error.


{noformat}
Error
java.lang.AssertionError: An exception occurred during asynchronous invocation.
Stacktrace
java.lang.AssertionError: An exception occurred during asynchronous invocation.
at 
org.apache.geode.test.dunit.AsyncInvocation.checkException(AsyncInvocation.java:148)
at 
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:341)
at 
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:364)
at 
org.apache.geode.management.internal.cli.commands.ConcurrentDeployDUnitTest.testMultipleGfshClientToOneServer(ConcurrentDeployDUnitTest.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
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.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
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.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
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.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at 
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at 
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
at 

[jira] [Resolved] (GEODE-2837) Start server fails if specified `--dir` does not exist

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2837.
--
Resolution: Fixed

> Start server fails if specified `--dir` does not exist
> --
>
> Key: GEODE-2837
> URL: https://issues.apache.org/jira/browse/GEODE-2837
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> When you execute {{gfsh> start server --name=server1}}, the default working 
> directory will be {{./server1}}, and gfsh will create that directory if 
> necessary.  However, {{gfsh> start server --name=server1 --dir=foo}} will 
> fail if the directory {{./foo}} does not exist. 
> For consistency ease of use, we should instead have gfsh attempt to create 
> the specified directory if necessary.  {{start locator}} may or may not have 
> the same deficiency.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2837) Start server fails if specified `--dir` does not exist

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2837:
-
Fix Version/s: 1.2.0

> Start server fails if specified `--dir` does not exist
> --
>
> Key: GEODE-2837
> URL: https://issues.apache.org/jira/browse/GEODE-2837
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> When you execute {{gfsh> start server --name=server1}}, the default working 
> directory will be {{./server1}}, and gfsh will create that directory if 
> necessary.  However, {{gfsh> start server --name=server1 --dir=foo}} will 
> fail if the directory {{./foo}} does not exist. 
> For consistency ease of use, we should instead have gfsh attempt to create 
> the specified directory if necessary.  {{start locator}} may or may not have 
> the same deficiency.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2871) CI Failure: org.apache.geode.management.internal.cli.commands.CommandOverHttpDUnitTest#testAlterUpdatesSharedConfig

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2871:


 Summary: CI Failure: 
org.apache.geode.management.internal.cli.commands.CommandOverHttpDUnitTest#testAlterUpdatesSharedConfig
 Key: GEODE-2871
 URL: https://issues.apache.org/jira/browse/GEODE-2871
 Project: Geode
  Issue Type: Bug
  Components: management
Reporter: Jared Stewart


This test failed in the nightly 
build(https://builds.apache.org/blue/organizations/jenkins/Geode-nightly/detail/Geode-nightly/824/tests):
{noformat}
Error
java.lang.AssertionError: Suspicious strings were written to the log during 
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in log4j at line 584
[fatal 2017/05/03 17:42:29.785 UTC  tid=0x4b2] 
java.nio.channels.ClosedChannelException
at 
org.eclipse.jetty.util.IteratingCallback.close(IteratingCallback.java:427)
at 
org.eclipse.jetty.server.HttpConnection.onClose(HttpConnection.java:491)
at 
org.eclipse.jetty.io.SelectorManager.connectionClosed(SelectorManager.java:345)
at org.eclipse.jetty.io.ManagedSelector$2.run(ManagedSelector.java:442)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:745)
Stacktrace
java.lang.AssertionError: Suspicious strings were written to the log during 
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in log4j at line 584
[fatal 2017/05/03 17:42:29.785 UTC  tid=0x4b2] 
java.nio.channels.ClosedChannelException
at 
org.eclipse.jetty.util.IteratingCallback.close(IteratingCallback.java:427)
at 
org.eclipse.jetty.server.HttpConnection.onClose(HttpConnection.java:491)
at 
org.eclipse.jetty.io.SelectorManager.connectionClosed(SelectorManager.java:345)
at org.eclipse.jetty.io.ManagedSelector$2.run(ManagedSelector.java:442)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:745)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.geode.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:385)
at 
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:577)
at 
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:523)
at 
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:509)
at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
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.RunAfters.evaluate(RunAfters.java:33)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
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 

[jira] [Created] (GEODE-2869) CI Failure: org.apache.geode.management.internal.cli.commands.ConfigCommandsDUnitTest

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2869:


 Summary: CI Failure: 
org.apache.geode.management.internal.cli.commands.ConfigCommandsDUnitTest
 Key: GEODE-2869
 URL: https://issues.apache.org/jira/browse/GEODE-2869
 Project: Geode
  Issue Type: Bug
  Components: management
Reporter: Jared Stewart


testAlterRuntimeConfigOnAllMembers and testAlterUpdatesSharedConfig failed in 
the nightly build 
(https://builds.apache.org/blue/organizations/jenkins/Geode-nightly/detail/Geode-nightly/824/tests)





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2868) CI Failure: org.apache.geode.management.internal.cli.commands.ConcurrentDeployDUnitTest#testMultipleGfshClientToOneServer

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2868:


 Summary: CI Failure: 
org.apache.geode.management.internal.cli.commands.ConcurrentDeployDUnitTest#testMultipleGfshClientToOneServer
 Key: GEODE-2868
 URL: https://issues.apache.org/jira/browse/GEODE-2868
 Project: Geode
  Issue Type: Bug
Reporter: Jared Stewart


This test failed in the nightly build 
(https://builds.apache.org/blue/organizations/jenkins/Geode-nightly/detail/Geode-nightly/824/tests)
{noformat}
Error
java.lang.AssertionError: An exception occurred during asynchronous invocation.
Stacktrace
java.lang.AssertionError: An exception occurred during asynchronous invocation.
at 
org.apache.geode.test.dunit.AsyncInvocation.checkException(AsyncInvocation.java:148)
at 
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:341)
at 
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:364)
at 
org.apache.geode.management.internal.cli.commands.ConcurrentDeployDUnitTest.testMultipleGfshClientToOneServer(ConcurrentDeployDUnitTest.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
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.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
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.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
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.GeneratedMethodAccessor370.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at 
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at 
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
at sun.reflect.GeneratedMethodAccessor369.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
at 
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at 

[jira] [Created] (GEODE-2867) CI Failure: org.apache.geode.management.LocatorManagementDUnitTest

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2867:


 Summary: CI Failure: 
org.apache.geode.management.LocatorManagementDUnitTest
 Key: GEODE-2867
 URL: https://issues.apache.org/jira/browse/GEODE-2867
 Project: Geode
  Issue Type: Bug
Reporter: Jared Stewart


The following tests failed in the nightly build 
(https://builds.apache.org/blue/organizations/jenkins/Geode-nightly/detail/Geode-nightly/824/tests)
 
{noformat}
testPeerLocationWithPortZero - 
org.apache.geode.management.LocatorManagementDUnitTest

testWillingManagers - org.apache.geode.management.LocatorManagementDUnitTest

testPeerLocation - org.apache.geode.management.LocatorManagementDUnitTest

testWillingManagersWithPortZero 
 - org.apache.geode.management.LocatorManagementDUnitTest
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-958) AgentUtilJUnitTest.testRESTApiExists failed with java.lang.AssertionError: GemFire REST API WAR File was not found

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-958.
-
Resolution: Fixed

> AgentUtilJUnitTest.testRESTApiExists failed with java.lang.AssertionError: 
> GemFire REST API WAR File was not found
> --
>
> Key: GEODE-958
> URL: https://issues.apache.org/jira/browse/GEODE-958
> Project: Geode
>  Issue Type: Bug
>  Components: rest (dev)
>Reporter: Hitesh Khamesra
>Assignee: Jared Stewart
>  Labels: ci
> Fix For: 1.0.0-incubating.M2
>
>
> java.lang.AssertionError: GemFire REST API WAR File was not found
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertNotNull(Assert.java:712)
>   at 
> com.gemstone.gemfire.management.internal.AgentUtilJUnitTest.testRESTApiExists(AgentUtilJUnitTest.java:55)
>   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.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.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at 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.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 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   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.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   at 
> 

[jira] [Resolved] (GEODE-2369) Exporting cluster-config with just a filename throws an NPE

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2369.
--
Resolution: Fixed

> Exporting cluster-config with just a filename throws an NPE
> ---
>
> Key: GEODE-2369
> URL: https://issues.apache.org/jira/browse/GEODE-2369
> Project: Geode
>  Issue Type: Bug
>  Components: docs, gfsh, management
>Reporter: Kevin Duling
>Assignee: Jared Stewart
>  Labels: ClusterConfig, ExportClusterConfigurationCommand, 
> export, gfsh
>
> When running export cluster-configuration from gfsh and providing just a 
> filename rather than an absolute path, or a filename and the --dir parameter, 
> an exception is thrown.
> The {{--dir}} option appears to be unused.
> {noformat}
> [info 2017/01/25 13:10:08.436 PST locator1  Connection(3)-192.168.1.45> tid=0x46] (tid=70 msgId=67) Could not execute 
> "export
>  cluster-configuration --zip-file-name=cluster.zip --dir=/tmp".
> java.lang.NullPointerException
> at 
> org.apache.geode.management.internal.cli.commands.ExportImportClusterConfigurationCommands.exportSharedConfig(ExportImport
> ClusterConfigurationCommands.java:85)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
> at 
> org.apache.geode.management.internal.cli.remote.RemoteExecutionStrategy.execute(RemoteExecutionStrategy.java:91)
> at 
> org.apache.geode.management.internal.cli.remote.CommandProcessor.executeCommand(CommandProcessor.java:117)
> at 
> org.apache.geode.management.internal.cli.remote.CommandStatementImpl.process(CommandStatementImpl.java:71)
> at 
> org.apache.geode.management.internal.cli.remote.MemberCommandService.processCommand(MemberCommandService.java:52)
> at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1639)
> at 
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:404)
> at 
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:397)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at 
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
> at 
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
> at 
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
> at 
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> 

[jira] [Resolved] (GEODE-2730) Refactor ServerStarterRule and LocatorStarterRule

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2730.
--
Resolution: Won't Fix

> Refactor ServerStarterRule and LocatorStarterRule
> -
>
> Key: GEODE-2730
> URL: https://issues.apache.org/jira/browse/GEODE-2730
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> Right now many tests that use ServerStarterRule and LocatorStarterRule are 
> flaky due to relying on default ports that intermittently cause 
> BindExceptions when those ports are in use. They also do not consistently use 
> the @Rule lifecycle to manage starting the member, but can optionally start 
> members when the rule is instantiated.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2796) NPE in ClassPathLoader

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2796.
--
Resolution: Fixed

> NPE in ClassPathLoader
> --
>
> Key: GEODE-2796
> URL: https://issues.apache.org/jira/browse/GEODE-2796
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> It looks like an NPE was introduced by the fix for GEODE-2290:
> {noformat}
> Caused by: java.lang.NullPointerException
> at 
> org.apache.geode.internal.ClassPathLoader.getResource(ClassPathLoader.java:130)
> at 
> org.apache.geode.internal.ClassPathLoader.getResourceAsStream(ClassPathLoader.java:239)
> at 
> org.apache.geode.internal.ClassPathLoader.getResourceAsStream(ClassPathLoader.java:264)
> at 
> org.apache.geode.internal.GemFireVersion$VersionDescription.(GemFireVersion.java:191)
> at 
> org.apache.geode.internal.GemFireVersion.getDescription(GemFireVersion.java:52)
> at 
> org.apache.geode.internal.GemFireVersion.getGemFireVersion(GemFireVersion.java:66)
> at org.apache.geode.cache.CacheFactory.getVersion(CacheFactory.java:305)
> ...
> {noformat}
> This is caused by the following method: 
> {noformat}
>  private List getClassLoaders() {
> ArrayList classLoaders = new ArrayList<>();
> if (!excludeTCCL) {
>   classLoaders.add(Thread.currentThread().getContextClassLoader());
> }
> classLoaders.add(classLoaderForDeployedJars);
> return classLoaders;
>   }
> {noformat}
> According to the JavaDocs, `getContextClassLoader()` actually returns null to 
> indicate the system class loader (rather than actually returning the system 
> class loader).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2842) Remove unnecessary @CliOption arguments

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2842:


Assignee: Jared Stewart

> Remove unnecessary @CliOption arguments
> ---
>
> Key: GEODE-2842
> URL: https://issues.apache.org/jira/browse/GEODE-2842
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> The {{@CliOption}} annotation specifies default values for some of its fields 
> (like {{mandatory}} and {{unspecifiedDefaultValue}}).  Yet, we often 
> explicitly set those fields to the default value.  For example,
> {noformat}  @CliOption(key = CliStrings.START_LOCATOR__MEMBER_NAME, 
> mandatory = false,
>   unspecifiedDefaultValue = CliMetaData.ANNOTATION_NULL_VALUE,
>   help = CliStrings.START_LOCATOR__MEMBER_NAME__HELP) String 
> memberName {noformat}
> could simply read   
> {noformat}  @CliOption(key = CliStrings.START_LOCATOR__MEMBER_NAME,
>   help = CliStrings.START_LOCATOR__MEMBER_NAME__HELP) String 
> memberName {noformat}
> Removing these redundant/unnecessary arguments will make the code a lot more 
> readable.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2842) Remove unnecessary @CliOption arguments

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2842:


 Summary: Remove unnecessary @CliOption arguments
 Key: GEODE-2842
 URL: https://issues.apache.org/jira/browse/GEODE-2842
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Jared Stewart


The {{@CliOption}} annotation specifies default values for some of its fields 
(like {{mandatory}} and {{unspecifiedDefaultValue}}).  Yet, we often explicitly 
set those fields to the default value.  For example,

{noformat}  @CliOption(key = CliStrings.START_LOCATOR__MEMBER_NAME, 
mandatory = false,
  unspecifiedDefaultValue = CliMetaData.ANNOTATION_NULL_VALUE,
  help = CliStrings.START_LOCATOR__MEMBER_NAME__HELP) String memberName 
{noformat}

could simply read   

{noformat}  @CliOption(key = CliStrings.START_LOCATOR__MEMBER_NAME,
  help = CliStrings.START_LOCATOR__MEMBER_NAME__HELP) String memberName 
{noformat}

Removing these redundant/unnecessary arguments will make the code a lot more 
readable.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2795) Nightly build failure: CreateAlterDestroyRegionCommandsDUnitTest

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2795:
-
Fix Version/s: 1.2.0

> Nightly build failure: CreateAlterDestroyRegionCommandsDUnitTest
> 
>
> Key: GEODE-2795
> URL: https://issues.apache.org/jira/browse/GEODE-2795
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> It looks like the nightly build is failing due to polluted DUnit vms.  
> (FastClassPathScanner uses the Path api instead of the File api, and while 
> File accepts modified values of System.getProperty("user.dir"), Path does 
> not).
> {noformat}
> :geode-core:distributedTest
> org.apache.geode.management.internal.cli.commands.CreateAlterDestroyRegionCommandsDUnitTest
>  > testAlterRegionResetCacheListeners FAILED
> java.lang.AssertionError: Suspicious strings were written to the log 
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 908
> [error 2017/04/18 10:12:26.647 UTC  
> tid=0x5d9] Could not deploy JAR file java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/server-1
> java.lang.RuntimeException: java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/server-1
>   at 
> io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1115)
>   at 
> io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1143)
>   at 
> io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1166)
>   at 
> org.apache.geode.internal.DeployedJar.findFunctionsInThisJar(DeployedJar.java:328)
>   at 
> org.apache.geode.internal.DeployedJar.loadClassesAndRegisterFunctions(DeployedJar.java:175)
>   at 
> org.apache.geode.internal.JarDeployer.registerNewVersions(JarDeployer.java:477)
>   at org.apache.geode.internal.JarDeployer.deploy(JarDeployer.java:516)
>   at 
> org.apache.geode.management.internal.cli.functions.DeployFunction.execute(DeployFunction.java:68)
>   at 
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:191)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:442)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:621)
>   at 
> org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1067)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: java.nio.file.NoSuchFileException: 
> /tmp/junit3985345267510453893/server-1
>   at 
> io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:217)
>   at 
> io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:61)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   ... 1 more
> Caused by: java.nio.file.NoSuchFileException: 
> /tmp/junit3985345267510453893/server-1
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at sun.nio.fs.UnixPath.toRealPath(UnixPath.java:876)
>   at 
> io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:215)
>   ... 5 more
> ---
> Found suspect string in log4j at line 945
> [error 2017/04/18 10:12:26.671 UTC  
> tid=0x5b1] Could not deploy JAR file java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/locator-0
> java.lang.RuntimeException: java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/locator-0
>   at 
> 

[jira] [Resolved] (GEODE-2795) Nightly build failure: CreateAlterDestroyRegionCommandsDUnitTest

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2795.
--
Resolution: Fixed

> Nightly build failure: CreateAlterDestroyRegionCommandsDUnitTest
> 
>
> Key: GEODE-2795
> URL: https://issues.apache.org/jira/browse/GEODE-2795
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> It looks like the nightly build is failing due to polluted DUnit vms.  
> (FastClassPathScanner uses the Path api instead of the File api, and while 
> File accepts modified values of System.getProperty("user.dir"), Path does 
> not).
> {noformat}
> :geode-core:distributedTest
> org.apache.geode.management.internal.cli.commands.CreateAlterDestroyRegionCommandsDUnitTest
>  > testAlterRegionResetCacheListeners FAILED
> java.lang.AssertionError: Suspicious strings were written to the log 
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 908
> [error 2017/04/18 10:12:26.647 UTC  
> tid=0x5d9] Could not deploy JAR file java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/server-1
> java.lang.RuntimeException: java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/server-1
>   at 
> io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1115)
>   at 
> io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1143)
>   at 
> io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1166)
>   at 
> org.apache.geode.internal.DeployedJar.findFunctionsInThisJar(DeployedJar.java:328)
>   at 
> org.apache.geode.internal.DeployedJar.loadClassesAndRegisterFunctions(DeployedJar.java:175)
>   at 
> org.apache.geode.internal.JarDeployer.registerNewVersions(JarDeployer.java:477)
>   at org.apache.geode.internal.JarDeployer.deploy(JarDeployer.java:516)
>   at 
> org.apache.geode.management.internal.cli.functions.DeployFunction.execute(DeployFunction.java:68)
>   at 
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:191)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:442)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:621)
>   at 
> org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1067)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: java.nio.file.NoSuchFileException: 
> /tmp/junit3985345267510453893/server-1
>   at 
> io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:217)
>   at 
> io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:61)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   ... 1 more
> Caused by: java.nio.file.NoSuchFileException: 
> /tmp/junit3985345267510453893/server-1
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at sun.nio.fs.UnixPath.toRealPath(UnixPath.java:876)
>   at 
> io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:215)
>   ... 5 more
> ---
> Found suspect string in log4j at line 945
> [error 2017/04/18 10:12:26.671 UTC  
> tid=0x5b1] Could not deploy JAR file java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/locator-0
> java.lang.RuntimeException: java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/locator-0
>   at 
> 

[jira] [Assigned] (GEODE-2837) Start server fails if specified `--dir` does not exist

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2837:


Assignee: Jared Stewart

> Start server fails if specified `--dir` does not exist
> --
>
> Key: GEODE-2837
> URL: https://issues.apache.org/jira/browse/GEODE-2837
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> When you execute {{gfsh> start server --name=server1}}, the default working 
> directory will be {{./server1}}, and gfsh will create that directory if 
> necessary.  However, {{gfsh> start server --name=server1 --dir=foo}} will 
> fail if the directory {{./foo}} does not exist. 
> For consistency ease of use, we should instead have gfsh attempt to create 
> the specified directory if necessary.  {{start locator}} may or may not have 
> the same deficiency.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2837) Start server fails if specified `--dir` does not exist

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2837:


 Summary: Start server fails if specified `--dir` does not exist
 Key: GEODE-2837
 URL: https://issues.apache.org/jira/browse/GEODE-2837
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Jared Stewart


When you execute {{gfsh> start server --name=server1}}, the default working 
directory will be {{./server1}}, and gfsh will create that directory if 
necessary.  However, {{gfsh> start server --name=server1 --dir=foo}} will fail 
if the directory {{./foo}} does not exist. 

For consistency ease of use, we should instead have gfsh attempt to create the 
specified directory if necessary.  {{start locator}} may or may not have the 
same deficiency.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2795) Nightly build failure: CreateAlterDestroyRegionCommandsDUnitTest

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2795:
-
Component/s: management

> Nightly build failure: CreateAlterDestroyRegionCommandsDUnitTest
> 
>
> Key: GEODE-2795
> URL: https://issues.apache.org/jira/browse/GEODE-2795
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> It looks like the nightly build is failing due to polluted DUnit vms.  
> (FastClassPathScanner uses the Path api instead of the File api, and while 
> File accepts modified values of System.getProperty("user.dir"), Path does 
> not).
> {noformat}
> :geode-core:distributedTest
> org.apache.geode.management.internal.cli.commands.CreateAlterDestroyRegionCommandsDUnitTest
>  > testAlterRegionResetCacheListeners FAILED
> java.lang.AssertionError: Suspicious strings were written to the log 
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 908
> [error 2017/04/18 10:12:26.647 UTC  
> tid=0x5d9] Could not deploy JAR file java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/server-1
> java.lang.RuntimeException: java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/server-1
>   at 
> io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1115)
>   at 
> io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1143)
>   at 
> io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1166)
>   at 
> org.apache.geode.internal.DeployedJar.findFunctionsInThisJar(DeployedJar.java:328)
>   at 
> org.apache.geode.internal.DeployedJar.loadClassesAndRegisterFunctions(DeployedJar.java:175)
>   at 
> org.apache.geode.internal.JarDeployer.registerNewVersions(JarDeployer.java:477)
>   at org.apache.geode.internal.JarDeployer.deploy(JarDeployer.java:516)
>   at 
> org.apache.geode.management.internal.cli.functions.DeployFunction.execute(DeployFunction.java:68)
>   at 
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:191)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:442)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:621)
>   at 
> org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1067)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: java.nio.file.NoSuchFileException: 
> /tmp/junit3985345267510453893/server-1
>   at 
> io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:217)
>   at 
> io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:61)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   ... 1 more
> Caused by: java.nio.file.NoSuchFileException: 
> /tmp/junit3985345267510453893/server-1
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at sun.nio.fs.UnixPath.toRealPath(UnixPath.java:876)
>   at 
> io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:215)
>   ... 5 more
> ---
> Found suspect string in log4j at line 945
> [error 2017/04/18 10:12:26.671 UTC  
> tid=0x5b1] Could not deploy JAR file java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/locator-0
> java.lang.RuntimeException: java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/locator-0
>   at 
> io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1115)
>   at 

[jira] [Assigned] (GEODE-2795) Nightly build failure: CreateAlterDestroyRegionCommandsDUnitTest

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2795:


Assignee: Jared Stewart

> Nightly build failure: CreateAlterDestroyRegionCommandsDUnitTest
> 
>
> Key: GEODE-2795
> URL: https://issues.apache.org/jira/browse/GEODE-2795
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> It looks like the nightly build is failing due to polluted DUnit vms.  
> (FastClassPathScanner uses the Path api instead of the File api, and while 
> File accepts modified values of System.getProperty("user.dir"), Path does 
> not).
> {noformat}
> :geode-core:distributedTest
> org.apache.geode.management.internal.cli.commands.CreateAlterDestroyRegionCommandsDUnitTest
>  > testAlterRegionResetCacheListeners FAILED
> java.lang.AssertionError: Suspicious strings were written to the log 
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 908
> [error 2017/04/18 10:12:26.647 UTC  
> tid=0x5d9] Could not deploy JAR file java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/server-1
> java.lang.RuntimeException: java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/server-1
>   at 
> io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1115)
>   at 
> io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1143)
>   at 
> io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1166)
>   at 
> org.apache.geode.internal.DeployedJar.findFunctionsInThisJar(DeployedJar.java:328)
>   at 
> org.apache.geode.internal.DeployedJar.loadClassesAndRegisterFunctions(DeployedJar.java:175)
>   at 
> org.apache.geode.internal.JarDeployer.registerNewVersions(JarDeployer.java:477)
>   at org.apache.geode.internal.JarDeployer.deploy(JarDeployer.java:516)
>   at 
> org.apache.geode.management.internal.cli.functions.DeployFunction.execute(DeployFunction.java:68)
>   at 
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:191)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:442)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:621)
>   at 
> org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1067)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: java.nio.file.NoSuchFileException: 
> /tmp/junit3985345267510453893/server-1
>   at 
> io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:217)
>   at 
> io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:61)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   ... 1 more
> Caused by: java.nio.file.NoSuchFileException: 
> /tmp/junit3985345267510453893/server-1
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at sun.nio.fs.UnixPath.toRealPath(UnixPath.java:876)
>   at 
> io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:215)
>   ... 5 more
> ---
> Found suspect string in log4j at line 945
> [error 2017/04/18 10:12:26.671 UTC  
> tid=0x5b1] Could not deploy JAR file java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/locator-0
> java.lang.RuntimeException: java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/locator-0
>   at 
> io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1115)
>   

[jira] [Created] (GEODE-2796) NPE in ClassPathLoader

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2796:


 Summary: NPE in ClassPathLoader
 Key: GEODE-2796
 URL: https://issues.apache.org/jira/browse/GEODE-2796
 Project: Geode
  Issue Type: Bug
  Components: management
Reporter: Jared Stewart


It looks like an NPE was introduced by the fix for GEODE-2290:

{noformat}
Caused by: java.lang.NullPointerException
at 
org.apache.geode.internal.ClassPathLoader.getResource(ClassPathLoader.java:130)
at 
org.apache.geode.internal.ClassPathLoader.getResourceAsStream(ClassPathLoader.java:239)
at 
org.apache.geode.internal.ClassPathLoader.getResourceAsStream(ClassPathLoader.java:264)
at 
org.apache.geode.internal.GemFireVersion$VersionDescription.(GemFireVersion.java:191)
at 
org.apache.geode.internal.GemFireVersion.getDescription(GemFireVersion.java:52)
at 
org.apache.geode.internal.GemFireVersion.getGemFireVersion(GemFireVersion.java:66)
at org.apache.geode.cache.CacheFactory.getVersion(CacheFactory.java:305)
...
{noformat}

This is caused by the following method: 
{noformat}
 private List getClassLoaders() {
ArrayList classLoaders = new ArrayList<>();

if (!excludeTCCL) {
  classLoaders.add(Thread.currentThread().getContextClassLoader());
}

classLoaders.add(classLoaderForDeployedJars);

return classLoaders;
  }
{noformat}

According to the JavaDocs, `getContextClassLoader()` actually returns null to 
indicate the system class loader (rather than actually returning the system 
class loader).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2705) Jars undeployed from cluster configuration while a server is offline will still be loaded from disk when the server comes back online

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2705:


Assignee: Jared Stewart

> Jars undeployed from cluster configuration while a server is offline will 
> still be loaded from disk when the server comes back online
> -
>
> Key: GEODE-2705
> URL: https://issues.apache.org/jira/browse/GEODE-2705
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, management
>Affects Versions: 1.1.0
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> 1. Start a locator and two servers
> 2. Deploy jar to cluster
> 3. Shutdown server 2
> 4. Undeploy jar from cluster
> 5. Start server 2 
> Then server 2 will load jar 1 from disk, even though it’s been removed from 
> the cluster configuration.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2705) Jars undeployed from cluster configuration while a server is offline will still be loaded from disk when the server comes back online

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2705.
--
Resolution: Fixed

> Jars undeployed from cluster configuration while a server is offline will 
> still be loaded from disk when the server comes back online
> -
>
> Key: GEODE-2705
> URL: https://issues.apache.org/jira/browse/GEODE-2705
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, management
>Affects Versions: 1.1.0
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> 1. Start a locator and two servers
> 2. Deploy jar to cluster
> 3. Shutdown server 2
> 4. Undeploy jar from cluster
> 5. Start server 2 
> Then server 2 will load jar 1 from disk, even though it’s been removed from 
> the cluster configuration.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2705) Jars undeployed from cluster configuration while a server is offline will still be loaded from disk when the server comes back online

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2705:
-
Fix Version/s: 1.2.0

> Jars undeployed from cluster configuration while a server is offline will 
> still be loaded from disk when the server comes back online
> -
>
> Key: GEODE-2705
> URL: https://issues.apache.org/jira/browse/GEODE-2705
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, management
>Affects Versions: 1.1.0
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> 1. Start a locator and two servers
> 2. Deploy jar to cluster
> 3. Shutdown server 2
> 4. Undeploy jar from cluster
> 5. Start server 2 
> Then server 2 will load jar 1 from disk, even though it’s been removed from 
> the cluster configuration.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2290) Provide way to limit scanning of deployed jars

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2290:
-
Fix Version/s: 1.2.0

> Provide way to limit scanning of deployed jars
> --
>
> Key: GEODE-2290
> URL: https://issues.apache.org/jira/browse/GEODE-2290
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh, management
>Reporter: Kirk Lund
>Assignee: Jared Stewart
>  Labels: ClassLoader, DeployCommand, deploy, gfsh
> Fix For: 1.2.0
>
>
> Currently if you use the GFSH command "deploy jar" the deployed jar will be 
> scanned in such a way that the deployer will load and resolve every .class 
> file in the jar file. The original intention of "deploy jar" was that only 
> Functions would be deployed. Any .class that is found to be a Function is 
> automatically registered with the FunctionService. 
> You can also include implementations of other Apache Geode callbacks such as 
> CacheListener. If you then follow up the deploy with "alter region" you can 
> alter the region to add the CacheListener or other callback.
> Some users have reported trying to deploy a jar with much more than just 
> Functions or CacheListeners or domain classes used for Region Entries. If the 
> jar includes a class that the callbacks or domain classes don't directly use 
> but that class requires a missing transitive dependency, then the deployer 
> will generate a NoClassDefFoundError when it tries to load and resolve that 
> class.
> Along with the potential NoClassDefFoundError, forcing every .class to be 
> loaded and resolved can consume a lot of PermGen memory.
> Various ideas have been tossed around to allow someone to deploy such a jar 
> without having the deployer generate NoClassDefFoundError. This requires 
> something like one of the following approaches:
> 1) add a new --do-not-deploy option flag
> 2) comma-delimited list of classes to load and deploy
> 3) regex list of classes to load and deploy
> 4) have I missed something?
> This would give the User better control over which classes to actually load 
> and resolve.
> [NOTE: I'll update this ticket based on feedback and discussion on 
> dev@geode.apache.org]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2686) Remove JarClassLoader

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2686.
--
Resolution: Fixed

> Remove JarClassLoader
> -
>
> Key: GEODE-2686
> URL: https://issues.apache.org/jira/browse/GEODE-2686
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> Before we can limit the scanning of deployed jars, we need to extricate 
> JarClassLoader, as its implementation eagerly loads all classes into memory.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2290) Provide way to limit scanning of deployed jars

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2290.
--
Resolution: Fixed

> Provide way to limit scanning of deployed jars
> --
>
> Key: GEODE-2290
> URL: https://issues.apache.org/jira/browse/GEODE-2290
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh, management
>Reporter: Kirk Lund
>Assignee: Jared Stewart
>  Labels: ClassLoader, DeployCommand, deploy, gfsh
> Fix For: 1.2.0
>
>
> Currently if you use the GFSH command "deploy jar" the deployed jar will be 
> scanned in such a way that the deployer will load and resolve every .class 
> file in the jar file. The original intention of "deploy jar" was that only 
> Functions would be deployed. Any .class that is found to be a Function is 
> automatically registered with the FunctionService. 
> You can also include implementations of other Apache Geode callbacks such as 
> CacheListener. If you then follow up the deploy with "alter region" you can 
> alter the region to add the CacheListener or other callback.
> Some users have reported trying to deploy a jar with much more than just 
> Functions or CacheListeners or domain classes used for Region Entries. If the 
> jar includes a class that the callbacks or domain classes don't directly use 
> but that class requires a missing transitive dependency, then the deployer 
> will generate a NoClassDefFoundError when it tries to load and resolve that 
> class.
> Along with the potential NoClassDefFoundError, forcing every .class to be 
> loaded and resolved can consume a lot of PermGen memory.
> Various ideas have been tossed around to allow someone to deploy such a jar 
> without having the deployer generate NoClassDefFoundError. This requires 
> something like one of the following approaches:
> 1) add a new --do-not-deploy option flag
> 2) comma-delimited list of classes to load and deploy
> 3) regex list of classes to load and deploy
> 4) have I missed something?
> This would give the User better control over which classes to actually load 
> and resolve.
> [NOTE: I'll update this ticket based on feedback and discussion on 
> dev@geode.apache.org]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2686) Remove JarClassLoader

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2686:
-
Fix Version/s: 1.2.0

> Remove JarClassLoader
> -
>
> Key: GEODE-2686
> URL: https://issues.apache.org/jira/browse/GEODE-2686
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> Before we can limit the scanning of deployed jars, we need to extricate 
> JarClassLoader, as its implementation eagerly loads all classes into memory.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2217) Add generic type parameter to FunctionContext interface

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2217:
-
Fix Version/s: 1.2.0

> Add generic type parameter to FunctionContext interface
> ---
>
> Key: GEODE-2217
> URL: https://issues.apache.org/jira/browse/GEODE-2217
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Jared Stewart
>Assignee: Alyssa Kim
> Fix For: 1.2.0
>
>
> FunctionContext has a method getArguments() that returns Object.  It would be 
> nice to have getArguments return a known type instead.
> ```
> public interface FunctionContext  {
>   public T getArguments();
> }
> ```
> The Function interface would then allow users to bound the expected argument 
> type:
> ```
> public interface Function {
>   public void execute(FunctionContext context);
> }
> ```



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2779) Inconsistent jars deployed on members belonging to the same group

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2779:


 Summary: Inconsistent jars deployed on members belonging to the 
same group
 Key: GEODE-2779
 URL: https://issues.apache.org/jira/browse/GEODE-2779
 Project: Geode
  Issue Type: Bug
  Components: configuration
Reporter: Jared Stewart


Members of a cluster (with cluster configuration enabled) can end up with 
inconsistent deployed jars even when they belong to the same groups. 

Here are the steps to reproduce:
```
gfsh> start locator --name=loc1
gfsh> start server --name=server1 --group=group1
gfsh> start server --name=server2 --group=group2
gfsh> start server --name=server3 --group=group1,group2

gfsh> deploy --jar=/myJar.jar --group=group1,group2
gfsh> undeploy --jar=myJar.jar --group=group1

gfsh> start server --name=server4 --group=group1,group2
```
Then server 4 will have myJar.jar (brought from cluster_config/group2/myJar.jar 
on the locator) whereas server 3 will not have myJar.jar (it got deleted from 
server 3 when we undeployed myJar from group 1).





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2724) NPE shutting down locator

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2724:
-
Fix Version/s: 1.2.0

> NPE shutting down locator
> -
>
> Key: GEODE-2724
> URL: https://issues.apache.org/jira/browse/GEODE-2724
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Bruce Schuchardt
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> Locator shutdown threw an NPE when stopping a Jetty server in Pulse code:
> {code}
> [warning 2017/03/28 08:56:25.493 IST locator1  tid=0x4a] Failed to 
> stop the HTTP service because: null
> java.lang.NullPointerException
> at 
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:225)
> at 
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:84)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
> at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at org.eclipse.jetty.server.Server.doStop(Server.java:476)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:328)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2146)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:536)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1314)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:964)
> at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge$1.run(MemberMBeanBridge.java:1000)
> at java.lang.Thread.run(Thread.java:745)
> [error 2017/03/28 08:56:25.494 IST locator1  tid=0x4a] Failed to 
> properly release resources held by the HTTP service: !STOPPED
> java.lang.IllegalStateException: !STOPPED
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:333)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> 

[jira] [Commented] (GEODE-2724) NPE shutting down locator

[Jared Stewart (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15966760#comment-15966760
 ] 

Jared Stewart commented on GEODE-2724:
--

I was able to reproduce this failure with Geode 1.1.0, but not with binaries 
built from the latest head of develop.  It appears that this bug was fixed 
incidentally by a recent commit:
{noformat}
31b6507 Patrick Rhomberg on 3/22/17 at 1:27 PM (committed by Jinmei Liao) 
GEODE-1274: Migration from PulseLogWriter to Log4j standard and removal of 
associated classes.
{noformat}

> NPE shutting down locator
> -
>
> Key: GEODE-2724
> URL: https://issues.apache.org/jira/browse/GEODE-2724
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Bruce Schuchardt
>
> Locator shutdown threw an NPE when stopping a Jetty server in Pulse code:
> {code}
> [warning 2017/03/28 08:56:25.493 IST locator1  tid=0x4a] Failed to 
> stop the HTTP service because: null
> java.lang.NullPointerException
> at 
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:225)
> at 
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:84)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
> at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at org.eclipse.jetty.server.Server.doStop(Server.java:476)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:328)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2146)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:536)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1314)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:964)
> at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge$1.run(MemberMBeanBridge.java:1000)
> at java.lang.Thread.run(Thread.java:745)
> [error 2017/03/28 08:56:25.494 IST locator1  tid=0x4a] Failed to 
> properly release resources held by the HTTP service: !STOPPED
> java.lang.IllegalStateException: !STOPPED
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:333)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> 

[jira] [Assigned] (GEODE-2724) NPE shutting down locator

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2724:


Assignee: Jared Stewart

> NPE shutting down locator
> -
>
> Key: GEODE-2724
> URL: https://issues.apache.org/jira/browse/GEODE-2724
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Bruce Schuchardt
>Assignee: Jared Stewart
>
> Locator shutdown threw an NPE when stopping a Jetty server in Pulse code:
> {code}
> [warning 2017/03/28 08:56:25.493 IST locator1  tid=0x4a] Failed to 
> stop the HTTP service because: null
> java.lang.NullPointerException
> at 
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:225)
> at 
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:84)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
> at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at org.eclipse.jetty.server.Server.doStop(Server.java:476)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:328)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2146)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:536)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1314)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:964)
> at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge$1.run(MemberMBeanBridge.java:1000)
> at java.lang.Thread.run(Thread.java:745)
> [error 2017/03/28 08:56:25.494 IST locator1  tid=0x4a] Failed to 
> properly release resources held by the HTTP service: !STOPPED
> java.lang.IllegalStateException: !STOPPED
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:333)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> 

[jira] [Resolved] (GEODE-2724) NPE shutting down locator

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2724.
--
Resolution: Fixed

> NPE shutting down locator
> -
>
> Key: GEODE-2724
> URL: https://issues.apache.org/jira/browse/GEODE-2724
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Bruce Schuchardt
>
> Locator shutdown threw an NPE when stopping a Jetty server in Pulse code:
> {code}
> [warning 2017/03/28 08:56:25.493 IST locator1  tid=0x4a] Failed to 
> stop the HTTP service because: null
> java.lang.NullPointerException
> at 
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:225)
> at 
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:84)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
> at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at org.eclipse.jetty.server.Server.doStop(Server.java:476)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:328)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2146)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:536)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1314)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:964)
> at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge$1.run(MemberMBeanBridge.java:1000)
> at java.lang.Thread.run(Thread.java:745)
> [error 2017/03/28 08:56:25.494 IST locator1  tid=0x4a] Failed to 
> properly release resources held by the HTTP service: !STOPPED
> java.lang.IllegalStateException: !STOPPED
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:333)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> 

[jira] [Commented] (GEODE-2724) NPE shutting down locator

[Jared Stewart (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15966631#comment-15966631
 ] 

Jared Stewart commented on GEODE-2724:
--

Can you provide any details about how to reproduce this failure?

> NPE shutting down locator
> -
>
> Key: GEODE-2724
> URL: https://issues.apache.org/jira/browse/GEODE-2724
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Bruce Schuchardt
>
> Locator shutdown threw an NPE when stopping a Jetty server in Pulse code:
> {code}
> [warning 2017/03/28 08:56:25.493 IST locator1  tid=0x4a] Failed to 
> stop the HTTP service because: null
> java.lang.NullPointerException
> at 
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:225)
> at 
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:84)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
> at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
> at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at org.eclipse.jetty.server.Server.doStop(Server.java:476)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:328)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2146)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:536)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1314)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:964)
> at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge$1.run(MemberMBeanBridge.java:1000)
> at java.lang.Thread.run(Thread.java:745)
> [error 2017/03/28 08:56:25.494 IST locator1  tid=0x4a] Failed to 
> properly release resources held by the HTTP service: !STOPPED
> java.lang.IllegalStateException: !STOPPED
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:333)
> at 
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at 
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at 
> 

[jira] [Assigned] (GEODE-2730) Refactor ServerStarterRule and LocatorStarterRule

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2730:


Assignee: Jared Stewart

> Refactor ServerStarterRule and LocatorStarterRule
> -
>
> Key: GEODE-2730
> URL: https://issues.apache.org/jira/browse/GEODE-2730
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> Right now many tests that use ServerStarterRule and LocatorStarterRule are 
> flaky due to relying on default ports that intermittently cause 
> BindExceptions when those ports are in use. They also do not consistently use 
> the @Rule lifecycle to manage starting the member, but can optionally start 
> members when the rule is instantiated.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2730) Refactor ServerStarterRule and LocatorStarterRule

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2730:


 Summary: Refactor ServerStarterRule and LocatorStarterRule
 Key: GEODE-2730
 URL: https://issues.apache.org/jira/browse/GEODE-2730
 Project: Geode
  Issue Type: Improvement
  Components: management
Reporter: Jared Stewart


Right now many tests that use ServerStarterRule and LocatorStarterRule are 
flaky due to relying on default ports that intermittently cause BindExceptions 
when those ports are in use. They also do not consistently use the @Rule 
lifecycle to manage starting the member, but can optionally start members when 
the rule is instantiated.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2692) ExportLogsStatsDUnitTest failing in CI

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2692.
--
Resolution: Fixed

> ExportLogsStatsDUnitTest failing in CI
> --
>
> Key: GEODE-2692
> URL: https://issues.apache.org/jira/browse/GEODE-2692
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> There are new flaky CI failures caused by the fix to GEODE-2649 which relied 
> on the old (now defunct) filtering based off of file creation time.  
> {code}
> ExportLogsStatsDUnitTest. startAndEndDateCanExcludeLogs
> ExportLogsStatsOverHttpDUnitTest. startAndEndDateCanExcludeLogs
> {code}
> {code}
> startAndEndDateCanExcludeLogs
> java.lang.AssertionError: 
> Expecting:
>  <"Logs exported to: 
> /tmp/build/ae3c03f4/geode/geode-web/build/distributedTest1664/exportedLogs_1489795206731.zip
> ">
> to contain:
>  <"No files to be exported"> 
>   at 
> org.apache.geode.management.internal.cli.commands.ExportLogsStatsDUnitTest.startAndEndDateCanExcludeLogs(ExportLogsStatsDUnitTest.java:140)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 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.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:37)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   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.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)

[jira] [Updated] (GEODE-2692) ExportLogsStatsDUnitTest failing in CI

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2692:
-
Fix Version/s: 1.2.0

> ExportLogsStatsDUnitTest failing in CI
> --
>
> Key: GEODE-2692
> URL: https://issues.apache.org/jira/browse/GEODE-2692
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> There are new flaky CI failures caused by the fix to GEODE-2649 which relied 
> on the old (now defunct) filtering based off of file creation time.  
> {code}
> ExportLogsStatsDUnitTest. startAndEndDateCanExcludeLogs
> ExportLogsStatsOverHttpDUnitTest. startAndEndDateCanExcludeLogs
> {code}
> {code}
> startAndEndDateCanExcludeLogs
> java.lang.AssertionError: 
> Expecting:
>  <"Logs exported to: 
> /tmp/build/ae3c03f4/geode/geode-web/build/distributedTest1664/exportedLogs_1489795206731.zip
> ">
> to contain:
>  <"No files to be exported"> 
>   at 
> org.apache.geode.management.internal.cli.commands.ExportLogsStatsDUnitTest.startAndEndDateCanExcludeLogs(ExportLogsStatsDUnitTest.java:140)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 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.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:37)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   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.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 

[jira] [Assigned] (GEODE-2692) ExportLogsStatsDUnitTest failing in CI

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2692:


Assignee: Jared Stewart

> ExportLogsStatsDUnitTest failing in CI
> --
>
> Key: GEODE-2692
> URL: https://issues.apache.org/jira/browse/GEODE-2692
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> There are new flaky CI failures caused by the fix to GEODE-2649 which relied 
> on the old (now defunct) filtering based off of file creation time.  
> {code}
> ExportLogsStatsDUnitTest. startAndEndDateCanExcludeLogs
> ExportLogsStatsOverHttpDUnitTest. startAndEndDateCanExcludeLogs
> {code}
> {code}
> startAndEndDateCanExcludeLogs
> java.lang.AssertionError: 
> Expecting:
>  <"Logs exported to: 
> /tmp/build/ae3c03f4/geode/geode-web/build/distributedTest1664/exportedLogs_1489795206731.zip
> ">
> to contain:
>  <"No files to be exported"> 
>   at 
> org.apache.geode.management.internal.cli.commands.ExportLogsStatsDUnitTest.startAndEndDateCanExcludeLogs(ExportLogsStatsDUnitTest.java:140)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 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.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:37)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   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.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 

[jira] [Created] (GEODE-2692) ExportLogsStatsDUnitTest failing in CI

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2692:


 Summary: ExportLogsStatsDUnitTest failing in CI
 Key: GEODE-2692
 URL: https://issues.apache.org/jira/browse/GEODE-2692
 Project: Geode
  Issue Type: Bug
  Components: management
Reporter: Jared Stewart


There are new flaky CI failures caused by the fix to GEODE-2649 which relied on 
the old (now defunct) filtering based off of file creation time.  

{code}
ExportLogsStatsDUnitTest. startAndEndDateCanExcludeLogs
ExportLogsStatsOverHttpDUnitTest. startAndEndDateCanExcludeLogs
{code}

{code}
startAndEndDateCanExcludeLogs

java.lang.AssertionError: 
Expecting:
 <"Logs exported to: 
/tmp/build/ae3c03f4/geode/geode-web/build/distributedTest1664/exportedLogs_1489795206731.zip

">
to contain:
 <"No files to be exported"> 
at 
org.apache.geode.management.internal.cli.commands.ExportLogsStatsDUnitTest.startAndEndDateCanExcludeLogs(ExportLogsStatsDUnitTest.java:140)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
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.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:37)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
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.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at 
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at 
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
at 

[jira] [Assigned] (GEODE-2686) Remove JarClassLoader

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2686:


Assignee: Jared Stewart

> Remove JarClassLoader
> -
>
> Key: GEODE-2686
> URL: https://issues.apache.org/jira/browse/GEODE-2686
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> Before we can limit the scanning of deployed jars, we need to extricate 
> JarClassLoader, as its implementation eagerly loads all classes into memory.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2651) Function service should provide built-in mechanism for streaming back large function results

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2651:


 Summary: Function service should provide built-in mechanism for 
streaming back large function results
 Key: GEODE-2651
 URL: https://issues.apache.org/jira/browse/GEODE-2651
 Project: Geode
  Issue Type: Improvement
  Components: functions
Reporter: Jared Stewart


It would be convenient to have a built-in mechanism for streaming back large 
function results that does not require keeping all results in memory on either 
end of the function execution.  Example use cases: 

- Executing a function to gather all logs on server (this may produce a very 
large zip file)
- Executing netstat -lsof currently runs out of memory in CI



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2621) CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2621:
-
Priority: Minor  (was: Major)

> CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering
> --
>
> Key: GEODE-2621
> URL: https://issues.apache.org/jira/browse/GEODE-2621
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>Priority: Minor
>  Labels: CI, Flaky
>
> {code}
> See 
> 
> Changes:
> [jiliao] GEODE-2267: mark local time sensitive tests as flaky
> [khowe] GEODE-2488: Remove test from flaky category
> [nnag] GEODE-2596: Lucene metrics moved to public API
> [nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java
> [nnag] GEODE-2604: Added measurement units to the javadoc comments
> --
> [...truncated 99.83 KB...]
> :geode-core:flakyTest
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
>java.lang.AssertionError: 
>Expected size:<3> but was:<1> in:
><[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2621) CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2621:
-
Affects Version/s: 1.1.0

> CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering
> --
>
> Key: GEODE-2621
> URL: https://issues.apache.org/jira/browse/GEODE-2621
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.1.0
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>Priority: Minor
>  Labels: CI, Flaky
>
> {code}
> See 
> 
> Changes:
> [jiliao] GEODE-2267: mark local time sensitive tests as flaky
> [khowe] GEODE-2488: Remove test from flaky category
> [nnag] GEODE-2596: Lucene metrics moved to public API
> [nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java
> [nnag] GEODE-2604: Added measurement units to the javadoc comments
> --
> [...truncated 99.83 KB...]
> :geode-core:flakyTest
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
>java.lang.AssertionError: 
>Expected size:<3> but was:<1> in:
><[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2621) CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2621:
-
Description: 
{code}
See 


Changes:

[jiliao] GEODE-2267: mark local time sensitive tests as flaky

[khowe] GEODE-2488: Remove test from flaky category

[nnag] GEODE-2596: Lucene metrics moved to public API

[nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java

[nnag] GEODE-2604: Added measurement units to the javadoc comments

--
[...truncated 99.83 KB...]
:geode-core:flakyTest

org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
testExportWithStartAndEndDateTimeFiltering FAILED
   java.lang.AssertionError: 
   Expected size:<3> but was:<1> in:
   <[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
   at 
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
   at 
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
{code}

  was:
```
See 


Changes:

[jiliao] GEODE-2267: mark local time sensitive tests as flaky

[khowe] GEODE-2488: Remove test from flaky category

[nnag] GEODE-2596: Lucene metrics moved to public API

[nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java

[nnag] GEODE-2604: Added measurement units to the javadoc comments

--
[...truncated 99.83 KB...]
:geode-core:flakyTest

org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
testExportWithStartAndEndDateTimeFiltering FAILED
   java.lang.AssertionError: 
   Expected size:<3> but was:<1> in:
   <[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
   at 
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
   at 
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
```


> CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering
> --
>
> Key: GEODE-2621
> URL: https://issues.apache.org/jira/browse/GEODE-2621
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> {code}
> See 
> 
> Changes:
> [jiliao] GEODE-2267: mark local time sensitive tests as flaky
> [khowe] GEODE-2488: Remove test from flaky category
> [nnag] GEODE-2596: Lucene metrics moved to public API
> [nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java
> [nnag] GEODE-2604: Added measurement units to the javadoc comments
> --
> [...truncated 99.83 KB...]
> :geode-core:flakyTest
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
>java.lang.AssertionError: 
>Expected size:<3> but was:<1> in:
><[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2621) CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2621:
-
Labels: CI Flaky  (was: )

> CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering
> --
>
> Key: GEODE-2621
> URL: https://issues.apache.org/jira/browse/GEODE-2621
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>  Labels: CI, Flaky
>
> {code}
> See 
> 
> Changes:
> [jiliao] GEODE-2267: mark local time sensitive tests as flaky
> [khowe] GEODE-2488: Remove test from flaky category
> [nnag] GEODE-2596: Lucene metrics moved to public API
> [nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java
> [nnag] GEODE-2604: Added measurement units to the javadoc comments
> --
> [...truncated 99.83 KB...]
> :geode-core:flakyTest
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
>java.lang.AssertionError: 
>Expected size:<3> but was:<1> in:
><[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2621) CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2621:


 Summary: CI Failure: 
ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering
 Key: GEODE-2621
 URL: https://issues.apache.org/jira/browse/GEODE-2621
 Project: Geode
  Issue Type: Bug
  Components: management
Reporter: Jared Stewart


```
See 


Changes:

[jiliao] GEODE-2267: mark local time sensitive tests as flaky

[khowe] GEODE-2488: Remove test from flaky category

[nnag] GEODE-2596: Lucene metrics moved to public API

[nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java

[nnag] GEODE-2604: Added measurement units to the javadoc comments

--
[...truncated 99.83 KB...]
:geode-core:flakyTest

org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
testExportWithStartAndEndDateTimeFiltering FAILED
   java.lang.AssertionError: 
   Expected size:<3> but was:<1> in:
   <[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
   at 
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
   at 
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
```



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2414) Determine a mechanism to stream a zip file from server to locator

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2414:


Assignee: Jared Stewart

> Determine a mechanism to stream a zip file from server to locator
> -
>
> Key: GEODE-2414
> URL: https://issues.apache.org/jira/browse/GEODE-2414
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> Our export command will execute a function on servers (one at a time) to 
> build up a zip file of the artifacts for that server.  Then, the zip file 
> needs to be sent back to the locator, so that the locator can aggregate 
> together the files from all servers.  However, we need to make sure to 
> chunk/stream the data that we send from server to locator so that neither 
> member will run out of memory if the file is very large.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2416) Collect together artifacts from individual servers into a single zip file

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2416:


Assignee: Jared Stewart

> Collect together artifacts from individual servers into a single zip file
> -
>
> Key: GEODE-2416
> URL: https://issues.apache.org/jira/browse/GEODE-2416
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> We need a locator to unzip the individual zip files produced by GEODE-2415 
> and re-zip them together into a single zip file (with a directory for each 
> member, containing the artifacts from that member).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2436) Geode doesn't handle byte[] as key

[Jared Stewart (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15862149#comment-15862149
 ] 

Jared Stewart commented on GEODE-2436:
--

One option which may or may not have an acceptable performance overhead would 
be to store the byte[] as a Base64 encoded string.

> Geode doesn't handle byte[] as key
> --
>
> Key: GEODE-2436
> URL: https://issues.apache.org/jira/browse/GEODE-2436
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Hitesh Khamesra
>
> Geode doesn't handle byte[] as key. "byte[]" doesn't implement 
> hashcode/equals method, it just returns native hashcode. Because of that 
> following code returns  null for key k2;
> {code}
> Cache c = CacheFactory.getAnyInstance();
>
> Region region = c.getRegion("primitiveKVStore");
>byte[] k1 = new byte[] {1,2};
>
> region.put(k1, k1);
> byte[] k2 = new byte[] {1,2};
> System.out.println(">> "  + region.get(k2));
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2430) Remove binary files from test resources

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2430.
--
Resolution: Fixed

> Remove binary files from test resources
> ---
>
> Key: GEODE-2430
> URL: https://issues.apache.org/jira/browse/GEODE-2430
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> We have some tests which rely on the following binary files:
> {code}
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group1.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group2.jar
> {code}
> We need to convert our tests to generate these files dynamically instead so 
> that we don't have binary files checked into our repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2325) Improve tests for JarDeployer

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2325.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> Improve tests for JarDeployer
> -
>
> Key: GEODE-2325
> URL: https://issues.apache.org/jira/browse/GEODE-2325
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> org.apache.geode.internal.JarDeployer only has a DUnit test right now.  Many 
> of those test methods are really just unit tests, and should be extracted to 
> run as such.  The tests can also be cleaned up a lot with AssertJ.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2430) Remove binary files from test resources

[Jared Stewart (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15854467#comment-15854467
 ] 

Jared Stewart commented on GEODE-2430:
--

Cluster.jar is used by: 
ClusterConfigDeployJarDUnitTest
ClusterConfigBaseTest.java

cluster_config.zip is used by:
ClusterConfigBaseTest.java

cluster_config_security.zip is used by:
ClusterConfigWithSecurityDUnitTest

group1.jar and group2.jar are used by:
ClusterConfigDeployJarDUnitTest.java

> Remove binary files from test resources
> ---
>
> Key: GEODE-2430
> URL: https://issues.apache.org/jira/browse/GEODE-2430
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> We have some tests which rely on the following binary files:
> {code}
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group1.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group2.jar
> {code}
> We need to convert our tests to generate these files dynamically instead so 
> that we don't have binary files checked into our repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2430) Remove binary files from test resources

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2430:


Assignee: Jared Stewart

> Remove binary files from test resources
> ---
>
> Key: GEODE-2430
> URL: https://issues.apache.org/jira/browse/GEODE-2430
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> We have some tests which rely on the following binary files:
> {code}
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group1.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group2.jar
> {code}
> We need to convert our tests to generate these files dynamically instead so 
> that we don't have binary files checked into our repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2430) Remove binary files from test resources

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2430:


 Summary: Remove binary files from test resources
 Key: GEODE-2430
 URL: https://issues.apache.org/jira/browse/GEODE-2430
 Project: Geode
  Issue Type: Improvement
  Components: management
Reporter: Jared Stewart


We have some tests which rely on the following binary files:
{code}
+ 
geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster.jar
+ 
geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config.zip
+ 
geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
+ 
geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group1.jar
+ 
geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group2.jar
{code}

We need to convert our tests to generate these files dynamically instead so 
that we don't have binary files checked into our repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2425) Refactor tests for export logs

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2425:


 Summary: Refactor tests for export logs
 Key: GEODE-2425
 URL: https://issues.apache.org/jira/browse/GEODE-2425
 Project: Geode
  Issue Type: Sub-task
Reporter: Jared Stewart


Right now we have the following tests for export logs:

{code}
MiscellaneousCommandsExportLogsPart1DUnitTest
MiscellaneousCommandsExportLogsPart2DUnitTest
MiscellaneousCommandsExportLogsPart3DUnitTest
MiscellaneousCommandsExportLogsPart4DUnitTest
{code}

We should endeavor to write unit tests for the rest of sub-tasks in this 
ticket.  After that is done, it would be prudent to come back to these DUnits 
and decide which tests are worth keeping, which should be discarded, and 
whether we need to add any more.





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2194) Initial, post-login Pulse page is /pulse/pulse/pulseVersion

[Jared Stewart (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15850790#comment-15850790
 ] 

Jared Stewart commented on GEODE-2194:
--

See
commit a881e9cb1b86bfd5b928b8719219421f5a26a954
commit 82966c466a219f6a3674af0e702b9b12194c8c38


> Initial, post-login Pulse page is /pulse/pulse/pulseVersion
> ---
>
> Key: GEODE-2194
> URL: https://issues.apache.org/jira/browse/GEODE-2194
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Jens Deppe
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> When I login to pulse (regular security) the page I end up on is 
> {{/pulse/pulse/pulseVersion}}. However the login is successful because if I 
> just switch the URL to {{/pulse}} I end up at {{/pulse/clusterDetail.html}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2415) Write a function to return a zip file for a single server

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2415:


Assignee: Jared Stewart

> Write a function to return a zip file for a single server
> -
>
> Key: GEODE-2415
> URL: https://issues.apache.org/jira/browse/GEODE-2415
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> We need to write a function to be executed on each server that will find the 
> desired artifacts (logs, stat files, stack traces) on that server given the 
> parameters of the export command (date limiting, --exclude-stats, etc) and 
> return that zip file to the calling locator using the mechanism determined by 
> GEODE-2414.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2417) Generate zip file HTTP URL and manage deletion of zip files

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2417:
-
Description: Once a locator has built the aggregated zip file described by 
GEODE-2416, we need that locator to expose an endpoint through the Admin REST 
api to allow access to that file (perhaps e.g. /exportedArtifact?exportId=foo 
or /exportedArtifact?name=myLogs.zip).  After the zip file has been 
successfully downloaded, it should be deleted and the URL invalidated.  Also, 
the URL should only be valid for some time period (say 24hrs) after which the 
file will be deleted and URL invalidated even if it is not downloaded, to 
prevent exported zip files from polluting the locator's disk.  This URL should 
be returned in the 'export log' command result JSON rather than the file 
contents.  [Cluster:Read] permissions should be required to access the URL if 
integrated security is enabled.  (was: Once a locator has built the aggregated 
zip file described by GEODE-2416, we need that locator to expose an endpoint 
through the Admin REST api to allow access to that file (perhaps e.g. 
/exportedArtifact?exportId=foo or /exportedArtifact?name=myLogs.zip).  After 
the zip file has been successfully downloaded, it should be deleted and the URL 
invalidated.  Also, the URL should only be valid for some time period (say 
24hrs) after which the file will be deleted and URL invalidated even if it is 
not downloaded, to prevent exported zip files from polluting the locator's 
disk.  This URL should be returned in the 'export log' command result JSON 
rather than the file contents.)

> Generate zip file HTTP URL and manage deletion of zip files
> ---
>
> Key: GEODE-2417
> URL: https://issues.apache.org/jira/browse/GEODE-2417
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>
> Once a locator has built the aggregated zip file described by GEODE-2416, we 
> need that locator to expose an endpoint through the Admin REST api to allow 
> access to that file (perhaps e.g. /exportedArtifact?exportId=foo or 
> /exportedArtifact?name=myLogs.zip).  After the zip file has been successfully 
> downloaded, it should be deleted and the URL invalidated.  Also, the URL 
> should only be valid for some time period (say 24hrs) after which the file 
> will be deleted and URL invalidated even if it is not downloaded, to prevent 
> exported zip files from polluting the locator's disk.  This URL should be 
> returned in the 'export log' command result JSON rather than the file 
> contents.  [Cluster:Read] permissions should be required to access the URL if 
> integrated security is enabled.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2420) Warn a user if they try to export too much data

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2420:


 Summary: Warn a user if they try to export too much data
 Key: GEODE-2420
 URL: https://issues.apache.org/jira/browse/GEODE-2420
 Project: Geode
  Issue Type: Sub-task
Reporter: Jared Stewart


We should warn a user and prompt for confirmation before trying to perform an 
`export logs` operation that would result in a file over some threshold.  (Logs 
and stats have the potential to be very large.)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (GEODE-2267) Add gfsh command to export all cluster artifacts

[Jared Stewart (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15850451#comment-15850451
 ] 

Jared Stewart edited comment on GEODE-2267 at 2/2/17 8:37 PM:
--

Per discussion on the dev list, we have decided to implement this as a change 
to the existing `export logs` command rather than as a new `export artifacts` 
command.  The default behavior should be to include stat files, but to provide 
an option like `--exclude-stats`.  We likely also want to run `export 
stacktrace` automatically for a user as the first step of running `export logs` 
to make the support/troubleshooting processes as easy as possible.


was (Author: jstewart):
Per discussion on the dev list, we have decided to implement this as a change 
to the existing `export logs` command rather than as a new `export artifacts` 
command.  The default behavior should be to include stat files, but to provide 
an option like `--exclude-stats`.  We likely also want to run `export 
stacktrace` automatically for a user as the first step of running `export logs` 
to make the support/troubleshooting processes as easy as possible.

> Add gfsh command to export all cluster artifacts
> 
>
> Key: GEODE-2267
> URL: https://issues.apache.org/jira/browse/GEODE-2267
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration, gfsh
>Reporter: Diane Hardman
>  Labels: ExportClusterArtifacts, export, gfsh, logging, statistics
>
> We would like a single gfsh command to collect and export all logfiles and 
> stat files into a single package that will be returned to the gfsh client 
> machine. This package (zipfile) can then be saved and attached to emails and 
> Jira tickets to help evaluate the Geode cluster status.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2267) Add gfsh command to export all cluster artifacts

[Jared Stewart (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15850451#comment-15850451
 ] 

Jared Stewart commented on GEODE-2267:
--

Per discussion on the dev list, we have decided to implement this as a change 
to the existing `export logs` command rather than as a new `export artifacts` 
command.  The default behavior should be to include stat files, but to provide 
an option like `--exclude-stats`.  We likely also want to run `export 
stacktrace` automatically for a user as the first step of running `export logs` 
to make the support/troubleshooting processes as easy as possible.

> Add gfsh command to export all cluster artifacts
> 
>
> Key: GEODE-2267
> URL: https://issues.apache.org/jira/browse/GEODE-2267
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration, gfsh
>Reporter: Diane Hardman
>  Labels: ExportClusterArtifacts, export, gfsh, logging, statistics
>
> We would like a single gfsh command to collect and export all logfiles and 
> stat files into a single package that will be returned to the gfsh client 
> machine. This package (zipfile) can then be saved and attached to emails and 
> Jira tickets to help evaluate the Geode cluster status.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2417) Generate zip file HTTP URL and manage deletion of zip files

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2417:
-
Description: Once a locator has built the aggregated zip file described by 
GEODE-2416, we need that locator to expose an endpoint through the Admin REST 
api to allow access to that file (perhaps e.g. /exportedArtifact?exportId=foo 
or /exportedArtifact?name=myLogs.zip).  After the zip file has been 
successfully downloaded, it should be deleted and the URL invalidated.  Also, 
the URL should only be valid for some time period (say 24hrs) after which the 
file will be deleted and URL invalidated even if it is not downloaded, to 
prevent exported zip files from polluting the locator's disk.  This URL should 
be returned in the 'export log' command result JSON rather than the file 
contents.  (was: Once a locator has built the aggregated zip file described by 
GEODE-2416, we need that locator to expose an endpoint through the Admin REST 
api to allow access to that file (perhaps e.g. /exportedArtifact?exportId=foo 
or /exportedArtifact?name=myLogs.zip).  After the zip file has been 
successfully downloaded, it should be deleted and the URL invalidated.  Also, 
the URL should only be valid for some time period (say 24hrs) after which the 
file will be deleted and URL invalidated even if it is not downloaded, to 
prevent exported zip files from polluting the locator's disk.)

> Generate zip file HTTP URL and manage deletion of zip files
> ---
>
> Key: GEODE-2417
> URL: https://issues.apache.org/jira/browse/GEODE-2417
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>
> Once a locator has built the aggregated zip file described by GEODE-2416, we 
> need that locator to expose an endpoint through the Admin REST api to allow 
> access to that file (perhaps e.g. /exportedArtifact?exportId=foo or 
> /exportedArtifact?name=myLogs.zip).  After the zip file has been successfully 
> downloaded, it should be deleted and the URL invalidated.  Also, the URL 
> should only be valid for some time period (say 24hrs) after which the file 
> will be deleted and URL invalidated even if it is not downloaded, to prevent 
> exported zip files from polluting the locator's disk.  This URL should be 
> returned in the 'export log' command result JSON rather than the file 
> contents.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2418) Add gfsh post execution handler to detect and download file URLs

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2418:


 Summary: Add gfsh post execution handler to detect and download 
file URLs
 Key: GEODE-2418
 URL: https://issues.apache.org/jira/browse/GEODE-2418
 Project: Geode
  Issue Type: Sub-task
Reporter: Jared Stewart


Rather than return the zip file contents in the 'export logs' command result 
from a locator to a gfsh client, we will return a URL to the exported zip file 
(GEODE-2417).  We need to write a gfsh post-execution handler (see 
`org.apache.geode.management.internal.cli.commands.ExportImportClusterConfigurationCommands.ExportInterceptor`)
 to extract the file URL from the result JSON and download that file via HTTP 
onto the gfsh client's disk.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2416) Collect together artifacts from individual servers

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2416:


 Summary: Collect together artifacts from individual servers
 Key: GEODE-2416
 URL: https://issues.apache.org/jira/browse/GEODE-2416
 Project: Geode
  Issue Type: Sub-task
Reporter: Jared Stewart


We need a locator to unzip the individual zip files produced by GEODE-2415 and 
re-zip them together into a single zip file (with a directory for each member, 
containing the artifacts from that member).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2415) Write a function to return a zip file for a single server

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2415:


 Summary: Write a function to return a zip file for a single server
 Key: GEODE-2415
 URL: https://issues.apache.org/jira/browse/GEODE-2415
 Project: Geode
  Issue Type: Sub-task
Reporter: Jared Stewart


We need to write a function to be executed on each server that will find the 
desired artifacts (logs, stat files, stack traces) on that server given the 
parameters of the export command (date limiting, --exclude-stats, etc) and 
return that zip file to the calling locator using the mechanism determined by 
GEODE-2414.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2414) Determine a mechanism to stream a zip file from server to locator

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2414:


 Summary: Determine a mechanism to stream a zip file from server to 
locator
 Key: GEODE-2414
 URL: https://issues.apache.org/jira/browse/GEODE-2414
 Project: Geode
  Issue Type: Sub-task
Reporter: Jared Stewart


Our export command will execute a function on servers (one at a time) to build 
up a zip file of the artifacts for that server.  Then, the zip file needs to be 
sent back to the locator, so that the locator can aggregate together the files 
from all servers.  However, we need to make sure to chunk/stream the data that 
we send from server to locator so that neither member will run out of memory if 
the file is very large.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2267) Add gfsh command to export all cluster artifacts

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart updated GEODE-2267:
-
Description: We would like a single gfsh command to collect and export all 
logfiles and stat files into a single package that will be returned to the gfsh 
client machine. This package (zipfile) can then be saved and attached to emails 
and Jira tickets to help evaluate the Geode cluster status.  (was: We would 
like a single gfsh command to collect and export all logfiles and stat files 
into a single package. This package (zipfile) can then be saved and attached to 
emails and Jira tickets to help evaluate the Geode cluster status.)

> Add gfsh command to export all cluster artifacts
> 
>
> Key: GEODE-2267
> URL: https://issues.apache.org/jira/browse/GEODE-2267
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration, gfsh
>Reporter: Diane Hardman
>  Labels: ExportClusterArtifacts, export, gfsh, logging, statistics
>
> We would like a single gfsh command to collect and export all logfiles and 
> stat files into a single package that will be returned to the gfsh client 
> machine. This package (zipfile) can then be saved and attached to emails and 
> Jira tickets to help evaluate the Geode cluster status.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2409) Beautify readme file

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart resolved GEODE-2409.
--
Resolution: Fixed

> Beautify readme file
> 
>
> Key: GEODE-2409
> URL: https://issues.apache.org/jira/browse/GEODE-2409
> Project: Geode
>  Issue Type: Wish
>  Components: docs
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> The github readme is the first introduction many people have to Apache Geode. 
>  I think it could be made a bit prettier (e.g. by adding an Apache Geode 
> banner to the top of the readme and adding an Apache License button.)  There 
> is a great curated list of examples from which to draw inspiration available 
> at https://github.com/matiassingers/awesome-readme.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2409) Beautify readme file

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2409:


 Summary: Beautify readme file
 Key: GEODE-2409
 URL: https://issues.apache.org/jira/browse/GEODE-2409
 Project: Geode
  Issue Type: Wish
  Components: docs
Reporter: Jared Stewart


The github readme is the first introduction many people have to Apache Geode.  
I think it could be made a bit prettier (e.g. by adding an Apache Geode banner 
to the top of the readme and adding an Apache License button.)  There is a 
great curated list of examples from which to draw inspiration available at 
https://github.com/matiassingers/awesome-readme.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2409) Beautify readme file

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2409:


Assignee: Jared Stewart

> Beautify readme file
> 
>
> Key: GEODE-2409
> URL: https://issues.apache.org/jira/browse/GEODE-2409
> Project: Geode
>  Issue Type: Wish
>  Components: docs
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> The github readme is the first introduction many people have to Apache Geode. 
>  I think it could be made a bit prettier (e.g. by adding an Apache Geode 
> banner to the top of the readme and adding an Apache License button.)  There 
> is a great curated list of examples from which to draw inspiration available 
> at https://github.com/matiassingers/awesome-readme.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2405) Update docs with changes to export cluster-configuration

[Jared Stewart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2405:


Assignee: Karen Smoler Miller  (was: Jared Stewart)

Hi Karen, let me know if what I wrote is unclear or if you need more details.  
Thanks!

> Update docs with changes to export cluster-configuration
> 
>
> Key: GEODE-2405
> URL: https://issues.apache.org/jira/browse/GEODE-2405
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Jared Stewart
>Assignee: Karen Smoler Miller
>
> The gfsh command {code} export cluster-configuration{code} used to have 
> separate parameters {code}--dir=value{code} and 
> {code}--zip-file-name=value{code}.  The {noformat}--dir{noformat} option has 
> been eliminated, and {code}--zip-file-name{code} can now take either just a 
> file name (e.g. myClusterConfiguration.zip) or a relative or absolute path 
> (e.g. export/myCC.zip or /export/myCC.zip).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)