[jira] [Assigned] (GEODE-2981) Fix the line feed code of the test expected value
[ https://issues.apache.org/jira/browse/GEODE-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-2981: -- Assignee: Jinmei Liao > Fix the line feed code of the test expected value > - > > Key: GEODE-2981 > URL: https://issues.apache.org/jira/browse/GEODE-2981 > Project: Geode > Issue Type: Test > Components: management, tests >Reporter: Masaki Yamakawa >Assignee: Jinmei Liao >Priority: Minor > > I mainly use the Windows. When I run the test on Windows, because Assertion > fails due to the difference in line feed code, I want to change this so that > it does not depend on the runtime environment. > The target classes are as follows: > - org.apache.geode.management.internal.cli.shell.GfshJunitTest > - org.apache.geode.management.internal.cli.help.HelpBlockUnitTest > - org.apache.geode.management.internal.cli.help.HelperUnitTest -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-3000) Refactor Admin rest request to send credentials in Authentication header and use spring security to authenticate it.
[ https://issues.apache.org/jira/browse/GEODE-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-3000: --- Fix Version/s: 1.2.0 > Refactor Admin rest request to send credentials in Authentication header and > use spring security to authenticate it. > > > Key: GEODE-3000 > URL: https://issues.apache.org/jira/browse/GEODE-3000 > Project: Geode > Issue Type: Improvement >Reporter: Jinmei Liao > Fix For: 1.2.0 > > > Currently, admin rest put security-password in the header and Jetty would log > it in debug level, we should send the authentication information in the > authentication header so that Jetty won't log them, and have the server side > be able to authenticate that way. > Currently the way these rest requests are sent are different for different > request. We need to uniform that first before we can do this refactoring. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2983) gfsh doesn't return user friendly error message when java property has comma separated values
[ https://issues.apache.org/jira/browse/GEODE-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2983: --- Fix Version/s: 1.2.0 > gfsh doesn't return user friendly error message when java property has comma > separated values > - > > Key: GEODE-2983 > URL: https://issues.apache.org/jira/browse/GEODE-2983 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Hitesh Khamesra >Assignee: Jinmei Liao > Fix For: 1.2.0 > > > Here is the gfsh command and output. It is telling "Error: Could not find or > load main class http", which slightly misleading > -bash-4.2$ gfsh start locator --dir=gemfire-locator --name=locator > --port=56661 --enable-cluster-configuration=true --force=true > --J=-Dgemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true > --J=-Dgemfire.http-service-port=8080 > --J=-Dgemfire.security-manager=SecurityManager > --J=-Dgemfire.security-enabled-components=server,http,jmx,gateway > .The Locator process terminated unexpectedly with exit status 1. Please refer > to the log file in tmp/gemfire-locator for full details. > Error: Could not find or load main class http -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-3006) busy login/logout message in the logs when gfsh connects via http
[ https://issues.apache.org/jira/browse/GEODE-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-3006: --- Fix Version/s: 1.2.0 > busy login/logout message in the logs when gfsh connects via http > - > > Key: GEODE-3006 > URL: https://issues.apache.org/jira/browse/GEODE-3006 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao > Fix For: 1.2.0 > > > the ping request is constantly login and logout resulting in busy log > messages in the logs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-3006) busy login/logout message in the logs when gfsh connects via http
Jinmei Liao created GEODE-3006: -- Summary: busy login/logout message in the logs when gfsh connects via http Key: GEODE-3006 URL: https://issues.apache.org/jira/browse/GEODE-3006 Project: Geode Issue Type: Bug Reporter: Jinmei Liao the ping request is constantly login and logout resulting in busy log messages in the logs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GEODE-2964) NPE on gfsh put command
[
https://issues.apache.org/jira/browse/GEODE-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16021551#comment-16021551
]
Jinmei Liao commented on GEODE-2964:
this is actually Caused by: java.lang.ClassNotFoundException:
org.apache.commons.collections.CollectionUtils
It looks like the usage the usage of CollectionUtils is added recently.
Reverting that fixed this problem.
> NPE on gfsh put command
> ---
>
> Key: GEODE-2964
> URL: https://issues.apache.org/jira/browse/GEODE-2964
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Swapnil Bawaskar
>
> After seeing up one locator one server, I created a partitioned region and
> try to put a value in it from gfsh which resulted in a NPE:
> {noformat}
> gfsh>start locator --name=loc1
> gfsh>start server --name=serv1
> gfsh>create region --name=foo --type=PARTITION
> gfsh>put --key=1 --value=one --region=/foo
> Exception in thread "Gfsh Launcher" java.lang.NoClassDefFoundError:
> org/apache/commons/collections/CollectionUtils
> at
> org.apache.geode.management.internal.cli.commands.DataCommands.put(DataCommands.java:895)
> 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:113)
> 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:1597)
> 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
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:346)
> at
[jira] [Created] (GEODE-2977) commands should take string[] as the value for --group and --memberId(--name) whenever possible
Jinmei Liao created GEODE-2977: -- Summary: commands should take string[] as the value for --group and --memberId(--name) whenever possible Key: GEODE-2977 URL: https://issues.apache.org/jira/browse/GEODE-2977 Project: Geode Issue Type: Bug Components: gfsh Reporter: Jinmei Liao some commands takes string[], and some takes only String and split them manually. We should make this consistent and the help message would be a lot clearer if taking string[]. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GEODE-2970) CI Failure: org.apache.geode.management.internal.cli.commands.ConfigCommandsDUnitTest.testAlterRuntimeConfigOnAllMembers
[ https://issues.apache.org/jira/browse/GEODE-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16020213#comment-16020213 ] Jinmei Liao commented on GEODE-2970: This particular test fails due to a NPE in the AlterRuntimeConfigFunction. This is due to Locator's started by Locator.startLocatorAndDS is not clearing the LogWriterAppenders for subsequent tests, > CI Failure: > org.apache.geode.management.internal.cli.commands.ConfigCommandsDUnitTest.testAlterRuntimeConfigOnAllMembers > > > Key: GEODE-2970 > URL: https://issues.apache.org/jira/browse/GEODE-2970 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Jinmei Liao > > https://builds.apache.org/job/Geode-nightly/840/testReport/junit/org.apache.geode.management.internal.cli.commands/ConfigCommandsDUnitTest/testAlterRuntimeConfigOnAllMembers/ > Error Message > java.lang.AssertionError: expected: but was: > Stacktrace > java.lang.AssertionError: expected: but was: > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:144) > at > org.apache.geode.management.internal.cli.commands.ConfigCommandsDUnitTest.testAlterRuntimeConfigOnAllMembers(ConfigCommandsDUnitTest.java:424) > 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.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 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.GeneratedMethodAccessor45.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
[jira] [Created] (GEODE-2970) CI Failure: org.apache.geode.management.internal.cli.commands.ConfigCommandsDUnitTest.testAlterRuntimeConfigOnAllMembers
Jinmei Liao created GEODE-2970: -- Summary: CI Failure: org.apache.geode.management.internal.cli.commands.ConfigCommandsDUnitTest.testAlterRuntimeConfigOnAllMembers Key: GEODE-2970 URL: https://issues.apache.org/jira/browse/GEODE-2970 Project: Geode Issue Type: Bug Components: management Reporter: Jinmei Liao https://builds.apache.org/job/Geode-nightly/840/testReport/junit/org.apache.geode.management.internal.cli.commands/ConfigCommandsDUnitTest/testAlterRuntimeConfigOnAllMembers/ Error Message java.lang.AssertionError: expected: but was: Stacktrace java.lang.AssertionError: expected: but was: at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:118) at org.junit.Assert.assertEquals(Assert.java:144) at org.apache.geode.management.internal.cli.commands.ConfigCommandsDUnitTest.testAlterRuntimeConfigOnAllMembers(ConfigCommandsDUnitTest.java:424) 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.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 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.GeneratedMethodAccessor45.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.GeneratedMethodAccessor44.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
[jira] [Assigned] (GEODE-2928) Get rid of the CliUtil.isGfshVM static variables
[ https://issues.apache.org/jira/browse/GEODE-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-2928: -- Assignee: Jinmei Liao > Get rid of the CliUtil.isGfshVM static variables > > > Key: GEODE-2928 > URL: https://issues.apache.org/jira/browse/GEODE-2928 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Jinmei Liao > > this is unnecessary. We can rely on Gfsh instance is null or not to test that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2941) Pulse documentation is outdated
[ https://issues.apache.org/jira/browse/GEODE-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2941: --- Component/s: docs > Pulse documentation is outdated > --- > > Key: GEODE-2941 > URL: https://issues.apache.org/jira/browse/GEODE-2941 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Jinmei Liao > > the pulse documentation: > http://geode.apache.org/docs/guide/11/tools_modules/pulse/quickstart.html#topic_523F6DE33FE54307BBE8F83BB7D9355D > is no longer accurate anymore. > 1. jmxUsername and jmxpassword no long applies > 2. the logging configurations has changed too. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2941) Pulse documentation is outdated
Jinmei Liao created GEODE-2941: -- Summary: Pulse documentation is outdated Key: GEODE-2941 URL: https://issues.apache.org/jira/browse/GEODE-2941 Project: Geode Issue Type: Bug Reporter: Jinmei Liao the pulse documentation: http://geode.apache.org/docs/guide/11/tools_modules/pulse/quickstart.html#topic_523F6DE33FE54307BBE8F83BB7D9355D is no longer accurate anymore. 1. jmxUsername and jmxpassword no long applies 2. the logging configurations has changed too. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-1274) Pulse logging does not appear in Geode log file.
[
https://issues.apache.org/jira/browse/GEODE-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-1274:
---
Fix Version/s: 1.2.0
> Pulse logging does not appear in Geode log file.
>
>
> Key: GEODE-1274
> URL: https://issues.apache.org/jira/browse/GEODE-1274
> Project: Geode
> Issue Type: Bug
> Components: logging, pulse
>Affects Versions: 1.0.0-incubating, 1.1.0
>Reporter: Jens Deppe
> Labels: Log4j2
> Fix For: 1.2.0
>
>
> While trying to enable debug logging for Pulse, I found that no Pulse logging
> appears in the Geode log. The Admin REST logging does appear though.
> I had tried to enable debug logging by starting a locator with the followiing
> log4j config:
> {noformat}
>
> packages="com.gemstone.gemfire.internal.logging.log4j">
>
> [%level{lowerCase=true} %date{/MM/dd
> HH:mm:ss.SSS z} %thread tid=%tid] %message%n%throwable%n
>
>
>
>
>
>
>
>
>
>onMismatch="NEUTRAL"/>
>
>
>
>
>
>
>
>
> {noformat}
> However, only the Admin REST app produced debug log output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GEODE-2927) Verify pulse connectivity to locator/jmx manager and logging both in the embedded and un-embedded mode.
[ https://issues.apache.org/jira/browse/GEODE-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2927. Resolution: Fixed Fix Version/s: 1.2.0 > Verify pulse connectivity to locator/jmx manager and logging both in the > embedded and un-embedded mode. > --- > > Key: GEODE-2927 > URL: https://issues.apache.org/jira/browse/GEODE-2927 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Jinmei Liao > Fix For: 1.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-2775) Pulse is not using certificate to connect to JMX when ssl is turned for jmx connection
[ https://issues.apache.org/jira/browse/GEODE-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2775. Resolution: Fixed Fix Version/s: 1.2.0 > Pulse is not using certificate to connect to JMX when ssl is turned for jmx > connection > -- > > Key: GEODE-2775 > URL: https://issues.apache.org/jira/browse/GEODE-2775 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.1.1 >Reporter: Jinmei Liao > Fix For: 1.2.0 > > > Steps to reproduce: > 1) start a locator with a SecurityManager and with this property: > ssl-enabled-components=jmx > 2) start a browser and tries to login to pulse. > Actual result: not able to log in using valid username/password -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2928) Get rid of the CliUtil.isGfshVM static variables
Jinmei Liao created GEODE-2928: -- Summary: Get rid of the CliUtil.isGfshVM static variables Key: GEODE-2928 URL: https://issues.apache.org/jira/browse/GEODE-2928 Project: Geode Issue Type: Bug Reporter: Jinmei Liao this is unnecessary. We can rely on Gfsh instance is null or not to test that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GEODE-2927) Verify pulse connectivity to locator/jmx manager and logging both in the embedded and un-embedded mode.
[ https://issues.apache.org/jira/browse/GEODE-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-2927: -- Assignee: Jinmei Liao > Verify pulse connectivity to locator/jmx manager and logging both in the > embedded and un-embedded mode. > --- > > Key: GEODE-2927 > URL: https://issues.apache.org/jira/browse/GEODE-2927 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Jinmei Liao > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2927) Verify pulse connectivity to locator/jmx manager both in the embedded and un-embedded mode.
Jinmei Liao created GEODE-2927: -- Summary: Verify pulse connectivity to locator/jmx manager both in the embedded and un-embedded mode. Key: GEODE-2927 URL: https://issues.apache.org/jira/browse/GEODE-2927 Project: Geode Issue Type: Bug Reporter: Jinmei Liao -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2927) Verify pulse connectivity to locator/jmx manager and logging both in the embedded and un-embedded mode.
[ https://issues.apache.org/jira/browse/GEODE-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2927: --- Summary: Verify pulse connectivity to locator/jmx manager and logging both in the embedded and un-embedded mode. (was: Verify pulse connectivity to locator/jmx manager both in the embedded and un-embedded mode.) > Verify pulse connectivity to locator/jmx manager and logging both in the > embedded and un-embedded mode. > --- > > Key: GEODE-2927 > URL: https://issues.apache.org/jira/browse/GEODE-2927 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2880) value auto complete for member and file names does not work
[ https://issues.apache.org/jira/browse/GEODE-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2880: --- Component/s: gfsh > value auto complete for member and file names does not work > --- > > Key: GEODE-2880 > URL: https://issues.apache.org/jira/browse/GEODE-2880 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Jinmei Liao > Fix For: 1.2.0 > > > those command should be auto-completed with the correct values: > connect --locator=yy > stop server --member=xx > start server --property-file=filename -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2880) value auto complete for member and file names does not work
Jinmei Liao created GEODE-2880: -- Summary: value auto complete for member and file names does not work Key: GEODE-2880 URL: https://issues.apache.org/jira/browse/GEODE-2880 Project: Geode Issue Type: Bug Reporter: Jinmei Liao Fix For: 1.2.0 those command should be auto-completed with the correct values: connect --locator=yy stop server --member=xx start server --property-file=filename -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-2840) add a dunit test to test concurrent deploy scenario
[ https://issues.apache.org/jira/browse/GEODE-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2840. Resolution: Fixed > add a dunit test to test concurrent deploy scenario > --- > > Key: GEODE-2840 > URL: https://issues.apache.org/jira/browse/GEODE-2840 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao > > as summary -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GEODE-2840) add a dunit test to test concurrent deploy scenario
[ https://issues.apache.org/jira/browse/GEODE-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-2840: -- Assignee: Jinmei Liao > add a dunit test to test concurrent deploy scenario > --- > > Key: GEODE-2840 > URL: https://issues.apache.org/jira/browse/GEODE-2840 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao > > as summary -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2840) add a dunit test to test concurrent deploy scenario
Jinmei Liao created GEODE-2840: -- Summary: add a dunit test to test concurrent deploy scenario Key: GEODE-2840 URL: https://issues.apache.org/jira/browse/GEODE-2840 Project: Geode Issue Type: Bug Components: management Reporter: Jinmei Liao as summary -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2818) add alias to any command's options that involves "group", "member", "jar"
Jinmei Liao created GEODE-2818: -- Summary: add alias to any command's options that involves "group", "member", "jar" Key: GEODE-2818 URL: https://issues.apache.org/jira/browse/GEODE-2818 Project: Geode Issue Type: New Feature Components: gfsh Reporter: Jinmei Liao Or anything that would have confusion about if we are going to use singular or plural at all. 1) add alias for those options 2) make sure it parameter type is an array type, some method only accepts a string and split it inside the command. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2817) Have the function author determine what permissions the function execution requires
Jinmei Liao created GEODE-2817: -- Summary: Have the function author determine what permissions the function execution requires Key: GEODE-2817 URL: https://issues.apache.org/jira/browse/GEODE-2817 Project: Geode Issue Type: New Feature Components: security Reporter: Jinmei Liao Currently to execute a function, you will need "data:write" permission, but it really depends on what the function is doing. So we should either: 1) externalize the authorize* api so that function author can use it in the function.execute code to check authorization. 2) add a function api to tell the framework what permission this function needs to execute, so that the framework will check the permission before executing the function. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-1912) gfsh does not validate start server command
[
https://issues.apache.org/jira/browse/GEODE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-1912.
Resolution: Duplicate
> gfsh does not validate start server command
> ---
>
> Key: GEODE-1912
> URL: https://issues.apache.org/jira/browse/GEODE-1912
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Swapnil Bawaskar
>Priority: Minor
>
> When I tried to start a server from gfsh I accidently used {{--locator}}
> (singular) rather than -{{-locators}}. gfsh did not throw an error and
> started the server without connecting to the locator.
> We should throw an error for unrecognized command options in gfsh.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GEODE-2775) Pulse is not using certificate to connect to JMX when ssl is turned for jmx connection
[ https://issues.apache.org/jira/browse/GEODE-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15966599#comment-15966599 ] Jinmei Liao commented on GEODE-2775: The problem lies in the fact that when in the embedded mode, the useSSL flag of pulse is not correctly set. Here is the workaround with the current release: In the embedded mode: * once a locator/server is started with ssl, go to the working directory of the member and find the pulse.properties file. Change the property "pulse.useSSL.manager" to true. * restart the locator/server to pick up the change in the properties file, now pulse should be able to connect. In the standalone mode: * follow this guide to set up the pulse.properties and pulsesecurity.properties with the ssl information: http://gemfirexd.docs.pivotal.io/1.3.1/userguide/manage_guide/pulse/quickstart.html * remember to put "pulse.useSSL.manager=true" in the pulse.properties > Pulse is not using certificate to connect to JMX when ssl is turned for jmx > connection > -- > > Key: GEODE-2775 > URL: https://issues.apache.org/jira/browse/GEODE-2775 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.1.1 >Reporter: Jinmei Liao > > Steps to reproduce: > 1) start a locator with a SecurityManager and with this property: > ssl-enabled-components=jmx > 2) start a browser and tries to login to pulse. > Actual result: not able to log in using valid username/password -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GEODE-1975) CI Failure: SecurityClusterConfigDUnitTest.serverWithDifferentSecurityManagerShouldThrowException
[ https://issues.apache.org/jira/browse/GEODE-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-1975: -- Assignee: Jinmei Liao > CI Failure: > SecurityClusterConfigDUnitTest.serverWithDifferentSecurityManagerShouldThrowException > - > > Key: GEODE-1975 > URL: https://issues.apache.org/jira/browse/GEODE-1975 > Project: Geode > Issue Type: Bug > Components: configuration, gfsh, security >Reporter: Barry Oglesby >Assignee: Jinmei Liao > Labels: CI, Flaky > > Geode_develop_DistributedTests > Private Build #4129 > Revision: 0a6e1a5339243b069a04d8010a869bfd1f4172c1 > java.lang.AssertionError: > Expecting message: > <"A server cannot specify its own security-manager or > security-post-processor when using cluster configuration"> > but was: > <"cluster configuration service not available"> > at > org.apache.geode.security.SecurityClusterConfigDUnitTest.serverWithDifferentSecurityManagerShouldThrowException(SecurityClusterConfigDUnitTest.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:497) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java: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.GeneratedMethodAccessor560.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > 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.GeneratedMethodAccessor559.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at >
[jira] [Updated] (GEODE-2775) Pulse is not using certificate to connect to JMX when ssl is turned for jmx connection
[ https://issues.apache.org/jira/browse/GEODE-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2775: --- Affects Version/s: 1.1.1 > Pulse is not using certificate to connect to JMX when ssl is turned for jmx > connection > -- > > Key: GEODE-2775 > URL: https://issues.apache.org/jira/browse/GEODE-2775 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.1.1 >Reporter: Jinmei Liao > > Steps to reproduce: > 1) start a locator with a SecurityManager and with this property: > ssl-enabled-components=jmx > 2) start a browser and tries to login to pulse. > Actual result: not able to log in using valid username/password -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2775) Pulse is not using certificate to connect to JMX when ssl is turned for jmx connection
Jinmei Liao created GEODE-2775: -- Summary: Pulse is not using certificate to connect to JMX when ssl is turned for jmx connection Key: GEODE-2775 URL: https://issues.apache.org/jira/browse/GEODE-2775 Project: Geode Issue Type: Bug Components: pulse Reporter: Jinmei Liao Steps to reproduce: 1) start a locator with a SecurityManager and with this property: ssl-enabled-components=jmx 2) start a browser and tries to login to pulse. Actual result: not able to log in using valid username/password -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-2756) export logs integration with security
[
https://issues.apache.org/jira/browse/GEODE-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-2756.
Resolution: Fixed
Fix Version/s: 1.2.0
> export logs integration with security
> -
>
> Key: GEODE-2756
> URL: https://issues.apache.org/jira/browse/GEODE-2756
> Project: Geode
> Issue Type: Sub-task
> Components: logging
>Reporter: Swapnil Bawaskar
>Assignee: Jinmei Liao
> Fix For: 1.2.0
>
>
> We need to make sure that a user is able to export logs when a
> {{security-manager}} has been configured.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (GEODE-2756) export logs integration with security
[
https://issues.apache.org/jira/browse/GEODE-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-2756:
--
Assignee: Jinmei Liao
> export logs integration with security
> -
>
> Key: GEODE-2756
> URL: https://issues.apache.org/jira/browse/GEODE-2756
> Project: Geode
> Issue Type: Sub-task
> Components: logging
>Reporter: Swapnil Bawaskar
>Assignee: Jinmei Liao
>
> We need to make sure that a user is able to export logs when a
> {{security-manager}} has been configured.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (GEODE-2670) pulse with integrated security has authentication and authorization issues
[ https://issues.apache.org/jira/browse/GEODE-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-2670: -- Assignee: Jinmei Liao > pulse with integrated security has authentication and authorization issues > -- > > Key: GEODE-2670 > URL: https://issues.apache.org/jira/browse/GEODE-2670 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Jinmei Liao > > Steps to reproduce: > 1) in gfsh, start up a locator with a security manager > 2) in the browser, try to connect to pulse: http://localhost:7070/pulse > 3) when presented a login page, try a invalid username/password. > 4) when getting "incorrect password" hint, use the same username, try using > the correct password for that user. It would still say "incorrect password". > Also, repeat above step 1 and 2, > 3), use a correct username and password that only have cluster:read previlage. > 4) try to access the dataBrowser.html, expect to get denied access, but is > still able to access. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2671) when a locator is started with a jmx-manager-port that is not 1099, the embedded pulse server still tries to connect to jmx using 1099
Jinmei Liao created GEODE-2671: -- Summary: when a locator is started with a jmx-manager-port that is not 1099, the embedded pulse server still tries to connect to jmx using 1099 Key: GEODE-2671 URL: https://issues.apache.org/jira/browse/GEODE-2671 Project: Geode Issue Type: Bug Components: pulse Reporter: Jinmei Liao embedded pulse does not use the jmx-manager-port used by the locator to connect. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2670) pulse with integrated security has authentication and authorization issues
Jinmei Liao created GEODE-2670: -- Summary: pulse with integrated security has authentication and authorization issues Key: GEODE-2670 URL: https://issues.apache.org/jira/browse/GEODE-2670 Project: Geode Issue Type: Bug Reporter: Jinmei Liao Steps to reproduce: 1) in gfsh, start up a locator with a security manager 2) in the browser, try to connect to pulse: http://localhost:7070/pulse 3) when presented a login page, try a invalid username/password. 4) when getting "incorrect password" hint, use the same username, try using the correct password for that user. It would still say "incorrect password". Also, repeat above step 1 and 2, 3), use a correct username and password that only have cluster:read previlage. 4) try to access the dataBrowser.html, expect to get denied access, but is still able to access. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege
[
https://issues.apache.org/jira/browse/GEODE-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15922735#comment-15922735
]
Jinmei Liao edited comment on GEODE-2605 at 3/13/17 7:06 PM:
-
Created this dunit test to verify the behavior.
{quote}
public class LuceneSecuritydUnitTest {
@Rule
public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();
@Rule
public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();
@Test
public void test() throws Exception{
Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER,
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);
Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());
gfsh.connectAndVerify(locator, "user", "data", "password", "data");
gfsh.executeAndVerifyCommand("create lucene index --name=testIndex
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");
assertThat(result).contains("Unauthorized. Reason : data not authorized for
CLUSTER:READ");
}
}
{quote}
This passes because in LuceneIndexCommand, the searchIndex command is annotated
as requiring "cluster:read" permission:
{quote}
@ResourceOperation(resource = Resource.CLUSTER, operation = Operation.READ)
{quote}
was (Author: jinmeiliao):
Created this dunit test to verify the behavior.
{quote}
public class LuceneSecuritydUnitTest {
@Rule
public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();
@Rule
public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();
@Test
public void test() throws Exception{
Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER,
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);
Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());
gfsh.connectAndVerify(locator, "user", "data", "password", "data");
gfsh.executeAndVerifyCommand("create lucene index --name=testIndex
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");
assertThat(result).contains("Unauthorized. Reason : data not authorized for
CLUSTER:READ");
}
}
{quote}
This passes because in LuceneIndexCommand, the searchIndex command is annotated
as requiring "cluster:read" permission:
{quote}
@CliCommand(value = LuceneCliStrings.LUCENE_DESTROY_INDEX,
help = LuceneCliStrings.LUCENE_DESTROY_INDEX__HELP)
@CliMetaData(shellOnly = false,
relatedTopic = {CliStrings.TOPIC_GEODE_REGION,
CliStrings.TOPIC_GEODE_DATA})
@ResourceOperation(resource = Resource.CLUSTER, operation = Operation.READ)
{quote}
> Unable to do a Lucene query without CLUSTER:READ privilege
> --
>
> Key: GEODE-2605
> URL: https://issues.apache.org/jira/browse/GEODE-2605
> Project: Geode
> Issue Type: Bug
> Components: docs, lucene, security
>Reporter: Diane Hardman
> Attachments: security.json
>
>
> I have configured a small cluster with security and am testing the privileges
> I need for creating a Lucene index and then executing a query/search using
> Lucene.
> I have confirmed that DATA:MANAGE privilege allows me to create a lucene
> index (similar to creating OQL indexes).
> I assumed I needed DATA:WRITE privilege to execute 'search lucene' because
> the implementation uses a function. Instead, I am getting an error that I
> need CLUSTER:READ privilege. I don't know why.
> As an aside, we may want to document that all DATA privileges automatically
> include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but
> could not list the indexes I created without CLUSTER:READ... go figure.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege
[
https://issues.apache.org/jira/browse/GEODE-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15922735#comment-15922735
]
Jinmei Liao edited comment on GEODE-2605 at 3/13/17 7:04 PM:
-
Created this dunit test to verify the behavior.
{quote}
public class LuceneSecuritydUnitTest {
@Rule
public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();
@Rule
public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();
@Test
public void test() throws Exception{
Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER,
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);
Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());
gfsh.connectAndVerify(locator, "user", "data", "password", "data");
gfsh.executeAndVerifyCommand("create lucene index --name=testIndex
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");
assertThat(result).contains("Unauthorized. Reason : data not authorized for
CLUSTER:READ");
}
}
{quote}
was (Author: jinmeiliao):
Created this dunit test to verify the behavior.
{{
public class LuceneSecuritydUnitTest {
@Rule
public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();
@Rule
public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();
@Test
public void test() throws Exception{
Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER,
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);
Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());
gfsh.connectAndVerify(locator, "user", "data", "password", "data");
gfsh.executeAndVerifyCommand("create lucene index --name=testIndex
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");
assertThat(result).contains("Unauthorized. Reason : data not authorized for
CLUSTER:READ");
}
}
}}
> Unable to do a Lucene query without CLUSTER:READ privilege
> --
>
> Key: GEODE-2605
> URL: https://issues.apache.org/jira/browse/GEODE-2605
> Project: Geode
> Issue Type: Bug
> Components: docs, lucene, security
>Reporter: Diane Hardman
> Attachments: security.json
>
>
> I have configured a small cluster with security and am testing the privileges
> I need for creating a Lucene index and then executing a query/search using
> Lucene.
> I have confirmed that DATA:MANAGE privilege allows me to create a lucene
> index (similar to creating OQL indexes).
> I assumed I needed DATA:WRITE privilege to execute 'search lucene' because
> the implementation uses a function. Instead, I am getting an error that I
> need CLUSTER:READ privilege. I don't know why.
> As an aside, we may want to document that all DATA privileges automatically
> include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but
> could not list the indexes I created without CLUSTER:READ... go figure.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege
[
https://issues.apache.org/jira/browse/GEODE-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15922735#comment-15922735
]
Jinmei Liao edited comment on GEODE-2605 at 3/13/17 7:03 PM:
-
Created this dunit test to verify the behavior.
{{
public class LuceneSecuritydUnitTest {
@Rule
public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();
@Rule
public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();
@Test
public void test() throws Exception{
Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER,
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);
Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());
gfsh.connectAndVerify(locator, "user", "data", "password", "data");
gfsh.executeAndVerifyCommand("create lucene index --name=testIndex
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");
assertThat(result).contains("Unauthorized. Reason : data not authorized for
CLUSTER:READ");
}
}
}}
was (Author: jinmeiliao):
Created this dunit test to verify the behavior.
public class LuceneSecuritydUnitTest {
@Rule
public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();
@Rule
public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();
@Test
public void test() throws Exception{
Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER,
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);
Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());
gfsh.connectAndVerify(locator, "user", "data", "password", "data");
gfsh.executeAndVerifyCommand("create lucene index --name=testIndex
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");
assertThat(result).contains("Unauthorized. Reason : data not authorized for
CLUSTER:READ");
}
}
> Unable to do a Lucene query without CLUSTER:READ privilege
> --
>
> Key: GEODE-2605
> URL: https://issues.apache.org/jira/browse/GEODE-2605
> Project: Geode
> Issue Type: Bug
> Components: docs, lucene, security
>Reporter: Diane Hardman
> Attachments: security.json
>
>
> I have configured a small cluster with security and am testing the privileges
> I need for creating a Lucene index and then executing a query/search using
> Lucene.
> I have confirmed that DATA:MANAGE privilege allows me to create a lucene
> index (similar to creating OQL indexes).
> I assumed I needed DATA:WRITE privilege to execute 'search lucene' because
> the implementation uses a function. Instead, I am getting an error that I
> need CLUSTER:READ privilege. I don't know why.
> As an aside, we may want to document that all DATA privileges automatically
> include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but
> could not list the indexes I created without CLUSTER:READ... go figure.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege
[
https://issues.apache.org/jira/browse/GEODE-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15922735#comment-15922735
]
Jinmei Liao edited comment on GEODE-2605 at 3/13/17 7:01 PM:
-
Created this dunit test to verify the behavior.
public class LuceneSecuritydUnitTest {
@Rule
public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();
@Rule
public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();
@Test
public void test() throws Exception{
Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER,
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);
Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());
gfsh.connectAndVerify(locator, "user", "data", "password", "data");
gfsh.executeAndVerifyCommand("create lucene index --name=testIndex
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");
assertThat(result).contains("Unauthorized. Reason : data not authorized for
CLUSTER:READ");
}
}
was (Author: jinmeiliao):
Created this dunit test to verify the behavior. the test is passing because the
LuceneIndexCommand declares that searchIndex requires "cluster:read".
public class LuceneSecuritydUnitTest {
@Rule
public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();
@Rule
public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();
@Test
public void test() throws Exception{
Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER,
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);
Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());
gfsh.connectAndVerify(locator, "user", "data", "password", "data");
gfsh.executeAndVerifyCommand("create lucene index --name=testIndex
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");
assertThat(result).contains("Unauthorized. Reason : data not authorized for
CLUSTER:READ");
}
}
> Unable to do a Lucene query without CLUSTER:READ privilege
> --
>
> Key: GEODE-2605
> URL: https://issues.apache.org/jira/browse/GEODE-2605
> Project: Geode
> Issue Type: Bug
> Components: docs, lucene, security
>Reporter: Diane Hardman
> Attachments: security.json
>
>
> I have configured a small cluster with security and am testing the privileges
> I need for creating a Lucene index and then executing a query/search using
> Lucene.
> I have confirmed that DATA:MANAGE privilege allows me to create a lucene
> index (similar to creating OQL indexes).
> I assumed I needed DATA:WRITE privilege to execute 'search lucene' because
> the implementation uses a function. Instead, I am getting an error that I
> need CLUSTER:READ privilege. I don't know why.
> As an aside, we may want to document that all DATA privileges automatically
> include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but
> could not list the indexes I created without CLUSTER:READ... go figure.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege
[
https://issues.apache.org/jira/browse/GEODE-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15922735#comment-15922735
]
Jinmei Liao commented on GEODE-2605:
Created this dunit test to verify the behavior. the test is passing because the
LuceneIndexCommand declares that searchIndex requires "cluster:read".
public class LuceneSecuritydUnitTest {
@Rule
public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();
@Rule
public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();
@Test
public void test() throws Exception{
Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER,
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);
Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());
gfsh.connectAndVerify(locator, "user", "data", "password", "data");
gfsh.executeAndVerifyCommand("create lucene index --name=testIndex
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");
assertThat(result).contains("Unauthorized. Reason : data not authorized for
CLUSTER:READ");
}
}
> Unable to do a Lucene query without CLUSTER:READ privilege
> --
>
> Key: GEODE-2605
> URL: https://issues.apache.org/jira/browse/GEODE-2605
> Project: Geode
> Issue Type: Bug
> Components: docs, lucene, security
>Reporter: Diane Hardman
> Attachments: security.json
>
>
> I have configured a small cluster with security and am testing the privileges
> I need for creating a Lucene index and then executing a query/search using
> Lucene.
> I have confirmed that DATA:MANAGE privilege allows me to create a lucene
> index (similar to creating OQL indexes).
> I assumed I needed DATA:WRITE privilege to execute 'search lucene' because
> the implementation uses a function. Instead, I am getting an error that I
> need CLUSTER:READ privilege. I don't know why.
> As an aside, we may want to document that all DATA privileges automatically
> include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but
> could not list the indexes I created without CLUSTER:READ... go figure.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GEODE-2354) Use of security-manager results in UnknownSessionExceptions after 30 minutes idle
[ https://issues.apache.org/jira/browse/GEODE-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2354. Resolution: Fixed > Use of security-manager results in UnknownSessionExceptions after 30 minutes > idle > - > > Key: GEODE-2354 > URL: https://issues.apache.org/jira/browse/GEODE-2354 > Project: Geode > Issue Type: Bug > Components: security >Reporter: Kirk Lund >Assignee: Jinmei Liao > > If the User specifies a SecurityManager with security-manager, all authorized > operations start to fail with UnknownSessionExceptions after 30 minutes idle > which is the default globalSessionTimeout in Apache Shiro. > Workaround: specify security-shiro-init in gemfire.properties and configure > everything via Shiro within a shiro.ini. > Fixing this will require changes to IntegratedSecurityService to set the > globalSessionTimeout higher or to re-authenticate after a timeout. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2641) export logs help strings has [--group=value(nullvalue)*] [--member=value(nullvalue)*]
Jinmei Liao created GEODE-2641: -- Summary: export logs help strings has [--group=value(nullvalue)*] [--member=value(nullvalue)*] Key: GEODE-2641 URL: https://issues.apache.org/jira/browse/GEODE-2641 Project: Geode Issue Type: Bug Reporter: Jinmei Liao export logs help strings has [--group=value(nullvalue)*] [--member=value(nullvalue)*] Also, merge-log option is deprecated, need to say that in the help -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2379) Document new behavior of export logs
[ https://issues.apache.org/jira/browse/GEODE-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2379: --- Description: the new command help: NAME export logs IS AVAILABLE false SYNOPSIS Export the log files for a member or members. SYNTAX export logs [--dir=value] [--group=value(,value)*] [--member=value(,value)*] [--log-level=value] [--only-log-level=value] [--merge-log=value] [--start-time=value] [--end-time=value] [--logs-only(=value)?] [--stats-only(=value)?] PARAMETERS dir Local directory to which log files will be written. This is only used when you are exporting logs using http connection. If not specified, user.dir will be used. Required: false group Group of members whose log files will be exported. Required: false member Name/Id of the member whose log files will be exported. Required: false log-level Minimum level of log entries to export. Valid values are: fatal, error, warn, info, debug, trace and all. The default is "INFO". Required: false Default (if the parameter is not specified): INFO only-log-level Whether to only include those entries that exactly match the --log-level specified. Required: false Default (if the parameter is not specified): false merge-log Whether to merge logs after exporting to the target directory. -- deprecated Required: false Default (if the parameter is not specified): false start-time Log entries that occurred after this time will be exported. The default is no limit. Format: /MM/dd/HH/mm/ss/SSS/z OR /MM/dd Required: false end-time Log entries that occurred before this time will be exported. The default is no limit. Format: /MM/dd/HH/mm/ss/SSS/z OR /MM/dd Required: false logs-only Whether to only export logs Required: false Default (if the parameter is specified without value): true Default (if the parameter is not specified): false stats-only Whether to only export statistics Required: false Default (if the parameter is specified without value): true Default (if the parameter is not specified): false changes are: --dir is not required anymore. added logs-only and stats-only options. --merge-log is deprecated, group and member can be comma separated strings. Also note down in the docs: when this command is executed over jmx, the exported logs will be saved as exportedlogs_xxx.zip in the connected locator's working directory. If executed over http, the zip will be saved in specified dir in the user's client machine. 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. > Document new behavior of export logs > > > Key: GEODE-2379 > URL: https://issues.apache.org/jira/browse/GEODE-2379 > Project: Geode > Issue Type: Sub-task > Components: docs >Reporter: Joey McAllister > > the new command help: > NAME > export logs > IS AVAILABLE > false > SYNOPSIS > Export the log files for a member or members. > SYNTAX > export logs [--dir=value] [--group=value(,value)*] > [--member=value(,value)*] [--log-level=value] [--only-log-level=value] > [--merge-log=value] [--start-time=value] [--end-time=value] > [--logs-only(=value)?] [--stats-only(=value)?] > PARAMETERS > dir > Local directory to which log files will be written. This is only used > when you are exporting logs using http connection. If not specified, user.dir > will be used. > Required: false > group > Group of members whose log files will be exported. > Required: false > member > Name/Id of the member whose log files will be exported. > Required: false > log-level > Minimum level of log entries to export. Valid values are: fatal, > error, warn, info, debug, trace and all. The default is "INFO". > Required: false > Default (if the parameter is not specified): INFO > only-log-level > Whether to only include those entries that exactly match the > --log-level specified. > Required: false > Default (if the parameter is not specified): false > merge-log > Whether to merge logs after exporting to the target directory. -- > deprecated > Required: false > Default (if the parameter is not specified): false > start-time > Log entries that occurred after this time will be exported. The > default is no limit. Format: /MM/dd/HH/mm/ss/SSS/z OR /MM/dd >
[jira] [Updated] (GEODE-2379) Document new behavior of export logs
[ https://issues.apache.org/jira/browse/GEODE-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2379: --- Summary: Document new behavior of export logs (was: Document new gfsh command to export cluster artifacts) > Document new behavior of export logs > > > Key: GEODE-2379 > URL: https://issues.apache.org/jira/browse/GEODE-2379 > Project: Geode > Issue Type: Sub-task > Components: docs >Reporter: Joey McAllister > > 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. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2632) Integrated Security performance improvements
Jinmei Liao created GEODE-2632: -- Summary: Integrated Security performance improvements Key: GEODE-2632 URL: https://issues.apache.org/jira/browse/GEODE-2632 Project: Geode Issue Type: Improvement Reporter: Jinmei Liao There is a security check in Put65.cmdExecute() that, if removed, improved the performance. The expense of this security call needs to be reduced in order to get the performance back. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-2614) Build generates javadoc warnings
[
https://issues.apache.org/jira/browse/GEODE-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-2614.
Resolution: Fixed
Fix Version/s: 1.2.0
> Build generates javadoc warnings
>
>
> Key: GEODE-2614
> URL: https://issues.apache.org/jira/browse/GEODE-2614
> Project: Geode
> Issue Type: Bug
> Components: gfsh, jmx
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
> Labels: javadocs
> Fix For: 1.2.0
>
>
> {noformat}
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
> warning - @param argument "logFilter:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
> warning - @param argument "baseLogFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
> warning - @param argument "baseStatsFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/CliAroundInterceptor.java:45:
> warning - @param argument "tempFile:" is not a parameter name.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (GEODE-2614) Build generates javadoc warnings
[
https://issues.apache.org/jira/browse/GEODE-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-2614:
--
Assignee: Jinmei Liao
> Build generates javadoc warnings
>
>
> Key: GEODE-2614
> URL: https://issues.apache.org/jira/browse/GEODE-2614
> Project: Geode
> Issue Type: Bug
> Components: gfsh, jmx
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
> Labels: javadocs
>
> {noformat}
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
> warning - @param argument "logFilter:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
> warning - @param argument "baseLogFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
> warning - @param argument "baseStatsFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/CliAroundInterceptor.java:45:
> warning - @param argument "tempFile:" is not a parameter name.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GEODE-2570) Export cluster-configuration returns "GemFire error" message
[ https://issues.apache.org/jira/browse/GEODE-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2570. Resolution: Fixed already fixed on develop. workaround supplied if using 1.1.0. > Export cluster-configuration returns "GemFire error" message > > > Key: GEODE-2570 > URL: https://issues.apache.org/jira/browse/GEODE-2570 > Project: Geode > Issue Type: Bug > Components: configuration, gfsh >Reporter: Wes Williams > Fix For: 1.2.0 > > > gfsh>version > 1.1.0 > gfsh>start locator --name=locator1 --port=10334 > --properties-file=config/locator.properties > --load-cluster-configuration-from-dir=true --initial-heap=256m --max-heap=256m > gfsh>start server --name=server1 --server-port=0 > --properties-file=config/gemfire.properties --initial-heap=1g --max-heap=1g > gfsh>list regions > No Regions Found > gfsh>list members > Name | Id > | > locator1 | 192.168.0.5(locator1:43398:locator):1024 > server1 | 192.168.0.5(server1:43404):1025 > gfsh>create region --name=Test --type=PARTITION > Member | Status > --- | --- > server1 | Region "/Test" created on "server1" > gfsh>export cluster-configuration --zip-file-name=test.zip > Could not process command due to GemFire error. Error while processing > command Reason : null > [info 2017/03/01 16:27:55.414 EST locator1 Connection(6)-192.168.0.5> tid=0x6c] (tid=108 msgId=72) Could not execute > "export cluster-configuration --zip-file-name=test.zip". > java.lang.NullPointerException > at > org.apache.geode.management.internal.cli.commands.ExportImportClusterConfigurationCommands.exportSharedConfig(ExportImportClusterConfigurationCommands.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:497) > 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:497) > 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:497) > 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:1466) > at > javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76) > at >
[jira] [Assigned] (GEODE-2570) Export cluster-configuration returns "GemFire error" message
[ https://issues.apache.org/jira/browse/GEODE-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-2570: -- Assignee: Jinmei Liao > Export cluster-configuration returns "GemFire error" message > > > Key: GEODE-2570 > URL: https://issues.apache.org/jira/browse/GEODE-2570 > Project: Geode > Issue Type: Bug > Components: configuration, gfsh >Reporter: Wes Williams >Assignee: Jinmei Liao > Fix For: 1.2.0 > > > gfsh>version > 1.1.0 > gfsh>start locator --name=locator1 --port=10334 > --properties-file=config/locator.properties > --load-cluster-configuration-from-dir=true --initial-heap=256m --max-heap=256m > gfsh>start server --name=server1 --server-port=0 > --properties-file=config/gemfire.properties --initial-heap=1g --max-heap=1g > gfsh>list regions > No Regions Found > gfsh>list members > Name | Id > | > locator1 | 192.168.0.5(locator1:43398:locator):1024 > server1 | 192.168.0.5(server1:43404):1025 > gfsh>create region --name=Test --type=PARTITION > Member | Status > --- | --- > server1 | Region "/Test" created on "server1" > gfsh>export cluster-configuration --zip-file-name=test.zip > Could not process command due to GemFire error. Error while processing > command Reason : null > [info 2017/03/01 16:27:55.414 EST locator1 Connection(6)-192.168.0.5> tid=0x6c] (tid=108 msgId=72) Could not execute > "export cluster-configuration --zip-file-name=test.zip". > java.lang.NullPointerException > at > org.apache.geode.management.internal.cli.commands.ExportImportClusterConfigurationCommands.exportSharedConfig(ExportImportClusterConfigurationCommands.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:497) > 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:497) > 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:497) > 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:1466) > at > javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76) > at >
[jira] [Assigned] (GEODE-2570) Export cluster-configuration returns "GemFire error" message
[ https://issues.apache.org/jira/browse/GEODE-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-2570: -- Assignee: (was: Jinmei Liao) > Export cluster-configuration returns "GemFire error" message > > > Key: GEODE-2570 > URL: https://issues.apache.org/jira/browse/GEODE-2570 > Project: Geode > Issue Type: Bug > Components: configuration, gfsh >Reporter: Wes Williams > Fix For: 1.2.0 > > > gfsh>version > 1.1.0 > gfsh>start locator --name=locator1 --port=10334 > --properties-file=config/locator.properties > --load-cluster-configuration-from-dir=true --initial-heap=256m --max-heap=256m > gfsh>start server --name=server1 --server-port=0 > --properties-file=config/gemfire.properties --initial-heap=1g --max-heap=1g > gfsh>list regions > No Regions Found > gfsh>list members > Name | Id > | > locator1 | 192.168.0.5(locator1:43398:locator):1024 > server1 | 192.168.0.5(server1:43404):1025 > gfsh>create region --name=Test --type=PARTITION > Member | Status > --- | --- > server1 | Region "/Test" created on "server1" > gfsh>export cluster-configuration --zip-file-name=test.zip > Could not process command due to GemFire error. Error while processing > command Reason : null > [info 2017/03/01 16:27:55.414 EST locator1 Connection(6)-192.168.0.5> tid=0x6c] (tid=108 msgId=72) Could not execute > "export cluster-configuration --zip-file-name=test.zip". > java.lang.NullPointerException > at > org.apache.geode.management.internal.cli.commands.ExportImportClusterConfigurationCommands.exportSharedConfig(ExportImportClusterConfigurationCommands.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:497) > 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:497) > 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:497) > 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:1466) > at > javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76) > at >
[jira] [Updated] (GEODE-2570) Export cluster-configuration returns "GemFire error" message
[ https://issues.apache.org/jira/browse/GEODE-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2570: --- Fix Version/s: (was: 1.1.0) > Export cluster-configuration returns "GemFire error" message > > > Key: GEODE-2570 > URL: https://issues.apache.org/jira/browse/GEODE-2570 > Project: Geode > Issue Type: Bug > Components: configuration, gfsh >Reporter: Wes Williams > Fix For: 1.2.0 > > > gfsh>version > 1.1.0 > gfsh>start locator --name=locator1 --port=10334 > --properties-file=config/locator.properties > --load-cluster-configuration-from-dir=true --initial-heap=256m --max-heap=256m > gfsh>start server --name=server1 --server-port=0 > --properties-file=config/gemfire.properties --initial-heap=1g --max-heap=1g > gfsh>list regions > No Regions Found > gfsh>list members > Name | Id > | > locator1 | 192.168.0.5(locator1:43398:locator):1024 > server1 | 192.168.0.5(server1:43404):1025 > gfsh>create region --name=Test --type=PARTITION > Member | Status > --- | --- > server1 | Region "/Test" created on "server1" > gfsh>export cluster-configuration --zip-file-name=test.zip > Could not process command due to GemFire error. Error while processing > command Reason : null > [info 2017/03/01 16:27:55.414 EST locator1 Connection(6)-192.168.0.5> tid=0x6c] (tid=108 msgId=72) Could not execute > "export cluster-configuration --zip-file-name=test.zip". > java.lang.NullPointerException > at > org.apache.geode.management.internal.cli.commands.ExportImportClusterConfigurationCommands.exportSharedConfig(ExportImportClusterConfigurationCommands.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:497) > 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:497) > 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:497) > 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:1466) > at > javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76) > at > javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
[jira] [Updated] (GEODE-2577) merge-log option is ignored for now
[ https://issues.apache.org/jira/browse/GEODE-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2577: --- Summary: merge-log option is ignored for now (was: merge-log option is ignored) > merge-log option is ignored for now > --- > > Key: GEODE-2577 > URL: https://issues.apache.org/jira/browse/GEODE-2577 > Project: Geode > Issue Type: Sub-task > Components: configuration, gfsh >Reporter: Jinmei Liao > > We don't merge logs on the server/locator anymore when exporting. We might be > able to merge them once they are downloaded to the client machine. Not sure > how much value-add this will be. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2577) merge-log option is ignored
Jinmei Liao created GEODE-2577: -- Summary: merge-log option is ignored Key: GEODE-2577 URL: https://issues.apache.org/jira/browse/GEODE-2577 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao We don't merge logs on the server/locator anymore when exporting. We might be able to merge them once they are downloaded to the client machine. Not sure how much value-add this will be. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2576) delete the old exported zip on the locator
Jinmei Liao created GEODE-2576: -- Summary: delete the old exported zip on the locator Key: GEODE-2576 URL: https://issues.apache.org/jira/browse/GEODE-2576 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao Currently when user is exporting logs over jmx connection, a zip file will be created in the locator's working dir with a unique file name. If user does exports for multiple times, all these zips will be created and we have no mechanism to clean them up unless user go in there to delete them. May need to decide whether this is a problem or not. If it is, we need to implement a way to delete these stale zip files periodically. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2575) When user is exporting large amount of data, the http/jmx connection may run into the risk of timing out.
Jinmei Liao created GEODE-2575: -- Summary: When user is exporting large amount of data, the http/jmx connection may run into the risk of timing out. Key: GEODE-2575 URL: https://issues.apache.org/jira/browse/GEODE-2575 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao something should be implemented to keep the connection alive when user is exporting large amount of data. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2574) be able to handle other log/stats files suffix or restrict file suffix
Jinmei Liao created GEODE-2574: -- Summary: be able to handle other log/stats files suffix or restrict file suffix Key: GEODE-2574 URL: https://issues.apache.org/jira/browse/GEODE-2574 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao Currently the log exporter only look for .log and .gfs files to export in the log and stats file directory. We should either restrict user to specify other file suffix or allow them to use whatever suffix they want. Also consider .log.gz files for compression. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GEODE-2425) Refactor tests for export logs
[
https://issues.apache.org/jira/browse/GEODE-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-2425:
--
Assignee: Jinmei Liao
> Refactor tests for export logs
> --
>
> Key: GEODE-2425
> URL: https://issues.apache.org/jira/browse/GEODE-2425
> Project: Geode
> Issue Type: Sub-task
> Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jinmei Liao
>
> 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] [Resolved] (GEODE-2425) Refactor tests for export logs
[
https://issues.apache.org/jira/browse/GEODE-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-2425.
Resolution: Fixed
> Refactor tests for export logs
> --
>
> Key: GEODE-2425
> URL: https://issues.apache.org/jira/browse/GEODE-2425
> Project: Geode
> Issue Type: Sub-task
> Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jinmei Liao
>
> 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] [Assigned] (GEODE-2418) Add gfsh post execution handler to detect and download file URLs
[ https://issues.apache.org/jira/browse/GEODE-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-2418: -- Assignee: Jinmei Liao > 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 > Components: configuration, gfsh >Reporter: Jared Stewart >Assignee: Jinmei Liao > > 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] [Assigned] (GEODE-2417) Generate zip file HTTP URL and manage deletion of zip files
[ https://issues.apache.org/jira/browse/GEODE-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-2417: -- Assignee: Jinmei Liao > 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 >Assignee: Jinmei Liao > > 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] [Resolved] (GEODE-2417) Generate zip file HTTP URL and manage deletion of zip files
[ https://issues.apache.org/jira/browse/GEODE-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2417. Resolution: Fixed > 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 >Assignee: Jinmei Liao > > 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] [Resolved] (GEODE-2418) Add gfsh post execution handler to detect and download file URLs
[ https://issues.apache.org/jira/browse/GEODE-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2418. Resolution: Fixed > 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 > Components: configuration, gfsh >Reporter: Jared Stewart >Assignee: Jinmei Liao > > 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] [Assigned] (GEODE-2419) Outputting proper message telling where the files are exported to.
[ https://issues.apache.org/jira/browse/GEODE-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-2419: -- Assignee: Jinmei Liao > Outputting proper message telling where the files are exported to. > -- > > Key: GEODE-2419 > URL: https://issues.apache.org/jira/browse/GEODE-2419 > Project: Geode > Issue Type: Sub-task > Components: configuration, gfsh >Reporter: Jared Stewart >Assignee: Jinmei Liao > > When user is exporting over jmx connection, we need to tell them that files > are exported to the connected member's local file system. If they are > connecting over http, then we need to tell them that files are exported to > their local system. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-2419) Outputting proper message telling where the files are exported to.
[ https://issues.apache.org/jira/browse/GEODE-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2419. Resolution: Fixed > Outputting proper message telling where the files are exported to. > -- > > Key: GEODE-2419 > URL: https://issues.apache.org/jira/browse/GEODE-2419 > Project: Geode > Issue Type: Sub-task > Components: configuration, gfsh >Reporter: Jared Stewart >Assignee: Jinmei Liao > > When user is exporting over jmx connection, we need to tell them that files > are exported to the connected member's local file system. If they are > connecting over http, then we need to tell them that files are exported to > their local system. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-2414) Determine a mechanism to stream a zip file from server to locator
[ https://issues.apache.org/jira/browse/GEODE-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2414. Resolution: Fixed > 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] [Resolved] (GEODE-2415) Write a function to return a zip file for a single server
[ https://issues.apache.org/jira/browse/GEODE-2415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2415. Resolution: Fixed > 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-2419) Outputting proper message telling where the files are exported to.
[ https://issues.apache.org/jira/browse/GEODE-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2419: --- Description: When user is exporting over jmx connection, we need to tell them that files are exported to the connected member's local file system. If they are connecting over http, then we need to tell them that files are exported to their local system. (was: Our strategy for the revised `export logs` command relies on the locator running the Admin REST API, which is enabled by default but can be optionally disabled. We need to add a good error message for the `export logs` command if Admin REST is disabled on the locator.) > Outputting proper message telling where the files are exported to. > -- > > Key: GEODE-2419 > URL: https://issues.apache.org/jira/browse/GEODE-2419 > Project: Geode > Issue Type: Sub-task > Components: configuration, gfsh >Reporter: Jared Stewart > > When user is exporting over jmx connection, we need to tell them that files > are exported to the connected member's local file system. If they are > connecting over http, then we need to tell them that files are exported to > their local system. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2419) Outputting proper message telling where the files are exported to.
[ https://issues.apache.org/jira/browse/GEODE-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2419: --- Summary: Outputting proper message telling where the files are exported to. (was: Add error message for export logs if Admin REST is disabled) > Outputting proper message telling where the files are exported to. > -- > > Key: GEODE-2419 > URL: https://issues.apache.org/jira/browse/GEODE-2419 > Project: Geode > Issue Type: Sub-task > Components: configuration, gfsh >Reporter: Jared Stewart > > Our strategy for the revised `export logs` command relies on the locator > running the Admin REST API, which is enabled by default but can be optionally > disabled. We need to add a good error message for the `export logs` command > if Admin REST is disabled on the locator. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GEODE-2427) JMXMBeanDUnitTest.testJMXOverLegacySSL cannot run with the other tests
[
https://issues.apache.org/jira/browse/GEODE-2427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15866132#comment-15866132
]
Jinmei Liao commented on GEODE-2427:
fixed
> JMXMBeanDUnitTest.testJMXOverLegacySSL cannot run with the other tests
> --
>
> Key: GEODE-2427
> URL: https://issues.apache.org/jira/browse/GEODE-2427
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
> Fix For: 1.2.0
>
>
> JMXMBeanDUnitTest.testJMXOverLegacySSL is currently marked as a FlakyTest. If
> you run this test with the other tests in JMXMBeanDUnitTest it fails 100% of
> the time. By marking it as FlakyTest, it runs separately in its own JVMs
> during the FlakyTest task. This seems to be caused by the other tests setting
> some statics that don't get cleaned up before running testJMXOverLegacySSL.
> So there's some sort of product configuration pollution going on here.
> JMXMBeanDUnitTest is cleaning up all System properties between tests, so the
> problem is not caused by a System property remaining set. It seems like it
> might have something to do with SSL configuration in JDK classes being static.
> The FlakyTest task forks the testing JVMs for every test case so
> testJMXOverLegacySSL ends up with fresh JVMs under FlakyTest and it passes
> 100% that way.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host
> 10.118.33.232 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
> at
> org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverLegacySSL(JMXMBeanDUnitTest.java:139)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub:
> javax.naming.CommunicationException [Root
[jira] [Assigned] (GEODE-2427) JMXMBeanDUnitTest.testJMXOverLegacySSL cannot run with the other tests
[
https://issues.apache.org/jira/browse/GEODE-2427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-2427:
--
Assignee: Jinmei Liao
> JMXMBeanDUnitTest.testJMXOverLegacySSL cannot run with the other tests
> --
>
> Key: GEODE-2427
> URL: https://issues.apache.org/jira/browse/GEODE-2427
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
> Fix For: 1.2.0
>
>
> JMXMBeanDUnitTest.testJMXOverLegacySSL is currently marked as a FlakyTest. If
> you run this test with the other tests in JMXMBeanDUnitTest it fails 100% of
> the time. By marking it as FlakyTest, it runs separately in its own JVMs
> during the FlakyTest task. This seems to be caused by the other tests setting
> some statics that don't get cleaned up before running testJMXOverLegacySSL.
> So there's some sort of product configuration pollution going on here.
> JMXMBeanDUnitTest is cleaning up all System properties between tests, so the
> problem is not caused by a System property remaining set. It seems like it
> might have something to do with SSL configuration in JDK classes being static.
> The FlakyTest task forks the testing JVMs for every test case so
> testJMXOverLegacySSL ends up with fresh JVMs under FlakyTest and it passes
> 100% that way.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host
> 10.118.33.232 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
> at
> org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverLegacySSL(JMXMBeanDUnitTest.java:139)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub:
> javax.naming.CommunicationException [Root exception is
>
[jira] [Resolved] (GEODE-2427) JMXMBeanDUnitTest.testJMXOverLegacySSL cannot run with the other tests
[
https://issues.apache.org/jira/browse/GEODE-2427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-2427.
Resolution: Fixed
Fix Version/s: 1.2.0
> JMXMBeanDUnitTest.testJMXOverLegacySSL cannot run with the other tests
> --
>
> Key: GEODE-2427
> URL: https://issues.apache.org/jira/browse/GEODE-2427
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
> Fix For: 1.2.0
>
>
> JMXMBeanDUnitTest.testJMXOverLegacySSL is currently marked as a FlakyTest. If
> you run this test with the other tests in JMXMBeanDUnitTest it fails 100% of
> the time. By marking it as FlakyTest, it runs separately in its own JVMs
> during the FlakyTest task. This seems to be caused by the other tests setting
> some statics that don't get cleaned up before running testJMXOverLegacySSL.
> So there's some sort of product configuration pollution going on here.
> JMXMBeanDUnitTest is cleaning up all System properties between tests, so the
> problem is not caused by a System property remaining set. It seems like it
> might have something to do with SSL configuration in JDK classes being static.
> The FlakyTest task forks the testing JVMs for every test case so
> testJMXOverLegacySSL ends up with fresh JVMs under FlakyTest and it passes
> 100% that way.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host
> 10.118.33.232 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
> at
> org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverLegacySSL(JMXMBeanDUnitTest.java:139)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub:
> javax.naming.CommunicationException
[jira] [Commented] (GEODE-2413) peer-to-peer authentication: Peer need to re-authenticate coordinator while accepting view message
[ https://issues.apache.org/jira/browse/GEODE-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15850493#comment-15850493 ] Jinmei Liao commented on GEODE-2413: Is this a feature request or a bug? I thought gateway sender/receiver should have mutual auth (even though it's not implemented in 8.2.x either), should peer-to-peer have mutual-auth as well? > peer-to-peer authentication: Peer need to re-authenticate coordinator while > accepting view message > -- > > Key: GEODE-2413 > URL: https://issues.apache.org/jira/browse/GEODE-2413 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Hitesh Khamesra > Fix For: 1.1.0 > > > In peer-to-peer authentication, coordinator authenticates the joining member. > Then coordinator includes that new member in the cluster and sends new view > message. This view message should include coordinator's credential so that > joining member can authenticate coordinator as well (i.e. mutual > authentication) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GEODE-2196) Write more tests to cover the current behavior of cluster config
[ https://issues.apache.org/jira/browse/GEODE-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-2196: -- Assignee: Jinmei Liao > Write more tests to cover the current behavior of cluster config > > > Key: GEODE-2196 > URL: https://issues.apache.org/jira/browse/GEODE-2196 > Project: Geode > Issue Type: Sub-task > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao > Fix For: 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2199) deploy/undeploy should continue even if there is no running servers in the cluster
[ https://issues.apache.org/jira/browse/GEODE-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2199. Resolution: Fixed Assignee: Jinmei Liao (was: Kirk Lund) Fix Version/s: 1.1.0 > deploy/undeploy should continue even if there is no running servers in the > cluster > -- > > Key: GEODE-2199 > URL: https://issues.apache.org/jira/browse/GEODE-2199 > Project: Geode > Issue Type: Sub-task > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao > Labels: DeployCommand, deploy > Fix For: 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2198) import cluster-config should continue if the running servers have no data in their application regions
[ https://issues.apache.org/jira/browse/GEODE-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2198. Resolution: Fixed Fix Version/s: 1.1.0 > import cluster-config should continue if the running servers have no data in > their application regions > -- > > Key: GEODE-2198 > URL: https://issues.apache.org/jira/browse/GEODE-2198 > Project: Geode > Issue Type: Sub-task > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao > Fix For: 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-2195) Hot Deploy of cluster configuration without bouncing the servers
[ https://issues.apache.org/jira/browse/GEODE-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-2195: -- Assignee: Jinmei Liao (was: Kirk Lund) > Hot Deploy of cluster configuration without bouncing the servers > > > Key: GEODE-2195 > URL: https://issues.apache.org/jira/browse/GEODE-2195 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao > Labels: DeployCommand, deploy > Fix For: 1.1.0 > > > user should be able to import a new set of cluster configuration without > having to shutdown all servers at least in the initial phases of trying out > cluster configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-2198) import cluster-config should continue if the running servers have no data in their application regions
[ https://issues.apache.org/jira/browse/GEODE-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-2198: -- Assignee: Jinmei Liao (was: Kirk Lund) > import cluster-config should continue if the running servers have no data in > their application regions > -- > > Key: GEODE-2198 > URL: https://issues.apache.org/jira/browse/GEODE-2198 > Project: Geode > Issue Type: Sub-task > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao > Fix For: 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (GEODE-2195) Hot Deploy of cluster configuration without bouncing the servers
[ https://issues.apache.org/jira/browse/GEODE-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reopened GEODE-2195: closed by accident. > Hot Deploy of cluster configuration without bouncing the servers > > > Key: GEODE-2195 > URL: https://issues.apache.org/jira/browse/GEODE-2195 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao > Labels: DeployCommand, deploy > Fix For: 1.1.0 > > > user should be able to import a new set of cluster configuration without > having to shutdown all servers at least in the initial phases of trying out > cluster configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2195) Hot Deploy of cluster configuration without bouncing the servers
[ https://issues.apache.org/jira/browse/GEODE-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2195. Resolution: Fixed Fix Version/s: 1.1.0 > Hot Deploy of cluster configuration without bouncing the servers > > > Key: GEODE-2195 > URL: https://issues.apache.org/jira/browse/GEODE-2195 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao > Labels: DeployCommand, deploy > Fix For: 1.1.0 > > > user should be able to import a new set of cluster configuration without > having to shutdown all servers at least in the initial phases of trying out > cluster configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2315) Improve cluster config: starting a second locator which joins a locator with cluster configuration should inherit the first locator's security settings.
Jinmei Liao created GEODE-2315: -- Summary: Improve cluster config: starting a second locator which joins a locator with cluster configuration should inherit the first locator's security settings. Key: GEODE-2315 URL: https://issues.apache.org/jira/browse/GEODE-2315 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2198) import cluster-config should continue if the running servers have no data in their application regions
[ https://issues.apache.org/jira/browse/GEODE-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15826833#comment-15826833 ] Jinmei Liao commented on GEODE-2198: [~dhardman] I just read your previous comment? Are you saying that we can't recreate the region with different attribute even if there is no data existing in the region? > import cluster-config should continue if the running servers have no data in > their application regions > -- > > Key: GEODE-2198 > URL: https://issues.apache.org/jira/browse/GEODE-2198 > Project: Geode > Issue Type: Sub-task > Components: management >Reporter: Jinmei Liao >Assignee: Kirk Lund > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2296) GetFunctionAttribute command is throwing an Anonymouse User Exception
[ https://issues.apache.org/jira/browse/GEODE-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2296: --- Component/s: docs > GetFunctionAttribute command is throwing an Anonymouse User Exception > - > > Key: GEODE-2296 > URL: https://issues.apache.org/jira/browse/GEODE-2296 > Project: Geode > Issue Type: Bug > Components: docs, management, security >Reporter: Jinmei Liao > Fix For: 1.1.0 > > > When trying to execute a function from a client, we sometimes would get this > exception. This is because GetFunctionAttribute is regarded as an internal > message, so it's not getting the subject bound to the executing thread, but > the cmdExecute method of this command is checking for authorization. Need to > remove that check and update the docs to not include this client command. > [error 2017/01/12 15:25:20.968567 Pacific Standard Time mmartell-Win10:3084 > 7460] Region::GET_FUNCTION_ATTRIBUTES: An exception > (org.apache.geode.security.GemFireSecurityException: Error: Anonymous User >at > org.apache.geode.internal.security.IntegratedSecurityService.getSubject(IntegratedSecurityService.java:114) >at > org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:273) >at > org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:269) >at > org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:264) >at > org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:260) >at > org.apache.geode.internal.security.IntegratedSecurityService.authorizeClusterRead(IntegratedSecurityService.java:220) >at > org.apache.geode.internal.cache.tier.sockets.command.GetFunctionAttribute.cmdExecute(GetFunctionAttribute.java:60) >at > org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:141) >at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:776) >at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:904) >at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1160) >at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >at > org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:519) >at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2197) Refactor cluster config so that cluster.xml and properties don't need to be saved in the file system.
[ https://issues.apache.org/jira/browse/GEODE-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2197: --- Fix Version/s: 1.1.0 > Refactor cluster config so that cluster.xml and properties don't need to be > saved in the file system. > - > > Key: GEODE-2197 > URL: https://issues.apache.org/jira/browse/GEODE-2197 > Project: Geode > Issue Type: Sub-task > Components: management >Reporter: Jinmei Liao >Assignee: Jared Stewart > Fix For: 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2229) Backup old cluster config before importing new one
[ https://issues.apache.org/jira/browse/GEODE-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2229: --- Fix Version/s: 1.1.0 > Backup old cluster config before importing new one > -- > > Key: GEODE-2229 > URL: https://issues.apache.org/jira/browse/GEODE-2229 > Project: Geode > Issue Type: Improvement > Components: configuration, management >Reporter: Jared Stewart >Assignee: Jared Stewart > Fix For: 1.1.0 > > > Cluster configuration, including cluster.xml and cluster.properties, used to > be stored in the filesystem of each locator. Before an `import > cluster-configuration` command would run, that configuration directory would > be copied and renamed to back up the existing configuration. As of > [GEODE-2197], the cluster.xml and cluster.properties files are no longer > stored on disk, so this backup strategy will no longer work. Instead, we > probably should automatically run `export cluster-configuration` before > proceeding with the import. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-2229) Backup old cluster config before importing new one
[ https://issues.apache.org/jira/browse/GEODE-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-2229: -- Assignee: Jinmei Liao > Backup old cluster config before importing new one > -- > > Key: GEODE-2229 > URL: https://issues.apache.org/jira/browse/GEODE-2229 > Project: Geode > Issue Type: Improvement > Components: configuration, management >Reporter: Jared Stewart >Assignee: Jinmei Liao > > Cluster configuration, including cluster.xml and cluster.properties, used to > be stored in the filesystem of each locator. Before an `import > cluster-configuration` command would run, that configuration directory would > be copied and renamed to back up the existing configuration. As of > [GEODE-2197], the cluster.xml and cluster.properties files are no longer > stored on disk, so this backup strategy will no longer work. Instead, we > probably should automatically run `export cluster-configuration` before > proceeding with the import. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2229) Backup old cluster config before importing new one
[ https://issues.apache.org/jira/browse/GEODE-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2229. Resolution: Fixed > Backup old cluster config before importing new one > -- > > Key: GEODE-2229 > URL: https://issues.apache.org/jira/browse/GEODE-2229 > Project: Geode > Issue Type: Improvement > Components: configuration, management >Reporter: Jared Stewart >Assignee: Jared Stewart > > Cluster configuration, including cluster.xml and cluster.properties, used to > be stored in the filesystem of each locator. Before an `import > cluster-configuration` command would run, that configuration directory would > be copied and renamed to back up the existing configuration. As of > [GEODE-2197], the cluster.xml and cluster.properties files are no longer > stored on disk, so this backup strategy will no longer work. Instead, we > probably should automatically run `export cluster-configuration` before > proceeding with the import. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2268) Store jar bytes in cluster configuration region
Jinmei Liao created GEODE-2268: -- Summary: Store jar bytes in cluster configuration region Key: GEODE-2268 URL: https://issues.apache.org/jira/browse/GEODE-2268 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao Currently xml and properties are stored in an internal cluster configuration region. However, for jar files only the name is stored in this region, while the jar bytes are stored in the filesystem of each locator. We should simplify things by storing the jar bytes in the same internal region. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2262) Improve cluster config: do not allow mix of locators that has CC enabled and not enabled in one cluster.
Jinmei Liao created GEODE-2262: -- Summary: Improve cluster config: do not allow mix of locators that has CC enabled and not enabled in one cluster. Key: GEODE-2262 URL: https://issues.apache.org/jira/browse/GEODE-2262 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao When a locator is started with CC enabled, do not allow another locator without CC to join it or vise versa. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2197) Refactor cluster config so that cluster.xml and properties don't need to be saved in the file system.
[ https://issues.apache.org/jira/browse/GEODE-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2197. Resolution: Fixed > Refactor cluster config so that cluster.xml and properties don't need to be > saved in the file system. > - > > Key: GEODE-2197 > URL: https://issues.apache.org/jira/browse/GEODE-2197 > Project: Geode > Issue Type: Sub-task > Components: management >Reporter: Jinmei Liao >Assignee: Jared Stewart > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-2261) refactor ClusterConfigWriter do not need to use remote call to change cluster config
[ https://issues.apache.org/jira/browse/GEODE-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-2261: -- Assignee: Jinmei Liao > refactor ClusterConfigWriter do not need to use remote call to change cluster > config > > > Key: GEODE-2261 > URL: https://issues.apache.org/jira/browse/GEODE-2261 > Project: Geode > Issue Type: Sub-task > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao > > Currently the ClusterConfigWriter gets a list of locators with CC enabled and > uses remote function calls to change CC. Since it's very uncommon that a > cluster would have a mix of locators with and without CC. We should just > change the CC on the current locator. If, in the rare case of this locator > not having cc enabled, we will just output a warning message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2261) refactor ClusterConfigWriter do not need to use remote call to change cluster config
[ https://issues.apache.org/jira/browse/GEODE-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2261: --- Summary: refactor ClusterConfigWriter do not need to use remote call to change cluster config (was: ClusterConfigWriter do not need to use remote call to change cluster config) > refactor ClusterConfigWriter do not need to use remote call to change cluster > config > > > Key: GEODE-2261 > URL: https://issues.apache.org/jira/browse/GEODE-2261 > Project: Geode > Issue Type: Sub-task > Components: management >Reporter: Jinmei Liao > > Currently the ClusterConfigWriter gets a list of locators with CC enabled and > uses remote function calls to change CC. Since it's very uncommon that a > cluster would have a mix of locators with and without CC. We should just > change the CC on the current locator. If, in the rare case of this locator > not having cc enabled, we will just output a warning message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2261) ClusterConfigWriter do not need to use remote call to change cluster config
Jinmei Liao created GEODE-2261: -- Summary: ClusterConfigWriter do not need to use remote call to change cluster config Key: GEODE-2261 URL: https://issues.apache.org/jira/browse/GEODE-2261 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao Currently the ClusterConfigWriter gets a list of locators with CC enabled and uses remote function calls to change CC. Since it's very uncommon that a cluster would have a mix of locators with and without CC. We should just change the CC on the current locator. If, in the rare case of this locator not having cc enabled, we will just output a warning message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2099) Race condition in ConnectToLocatorSSLDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2099: --- Fix Version/s: 1.1.0 > Race condition in ConnectToLocatorSSLDUnitTest > -- > > Key: GEODE-2099 > URL: https://issues.apache.org/jira/browse/GEODE-2099 > Project: Geode > Issue Type: Bug > Components: management, tests >Reporter: Jinmei Liao >Assignee: Jinmei Liao > Labels: Flaky > Fix For: 1.1.0 > > > This test contains 3 tests, if put a long enough wait or a break point in > between the tests, the tests would pass, otherwise the last two tests would > fail. Need to get to the bottom of this. For the last tests are ignored. This > is happening after we have to put "disconnect" after each connect to properly > close the jmx thread so that it wouldn't pollute other tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2203) gfsh status locator/server - Give more descriptive output on empty parameter
[
https://issues.apache.org/jira/browse/GEODE-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15740382#comment-15740382
]
Jinmei Liao commented on GEODE-2203:
Here is my branch https://github.com/jinmeiliao/geode/tree/GEODE-1912
> gfsh status locator/server - Give more descriptive output on empty parameter
>
>
> Key: GEODE-2203
> URL: https://issues.apache.org/jira/browse/GEODE-2203
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Alyssa Kim
>Assignee: Mark Bretl
>Priority: Minor
>
> Currently, executing some status commands in gfsh without valid parameters
> gives a vague explanation/output that might be misleading. Although we have
> help for usage description, displaying 'null' as an output
> might not be the best idea.
> Current Result
> {code}
> gfsh>status locator
> null
> {code}
> {code}
> gfsh>status server
> Server in
> C:\Users\XXX\git\incubator-geode\geode-assembly\build\install\apache-geode\bin
> on null is currently not responding.
> {code}
> Improvement
> {code}
> gfsh>status locator
> SYNTAX
> status locator [--name=value] [--host=value] [--port=value] [--pid=value]
> Use help status locator to display detailed usage information
> {code}
> {code}
> gfsh>status server
> SYNTAX
> status server [--name=value] [--pid=value] [--dir=value]
> Use help status server to display detailed usage information
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GEODE-2198) import cluster-config should continue if the running servers have no data in their application regions
Jinmei Liao created GEODE-2198: -- Summary: import cluster-config should continue if the running servers have no data in their application regions Key: GEODE-2198 URL: https://issues.apache.org/jira/browse/GEODE-2198 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao Assignee: Mark Bretl -- This message was sent by Atlassian JIRA (v6.3.4#6332)
