[jira] [Resolved] (GEODE-1247) Unable to stop members by name when using gfsh over http
[
https://issues.apache.org/jira/browse/GEODE-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-1247.
Resolution: Fixed
Assignee: Jinmei Liao
Fix Version/s: 1.1.0-incubating
> Unable to stop members by name when using gfsh over http
>
>
> Key: GEODE-1247
> URL: https://issues.apache.org/jira/browse/GEODE-1247
> Project: Geode
> Issue Type: Bug
> Components: gfsh, rest (admin)
>Reporter: Jens Deppe
>Assignee: Jinmei Liao
> Fix For: 1.1.0-incubating
>
>
> I'm connecting to my cluster with http:
> {noformat}
> gfsh>connect --use-http=true --url=http://localhost:7070/gemfire/v1
> {noformat}
> And creating a server...
> {noformat}
> gfsh>start server --name=server1
> Starting a GemFire Server in /Users/jdeppe/debug/server1...
> .
> Server in /Users/jdeppe/debug/server1 on 192.168.99.1[40404] as server1 is
> currently online.
> Process ID: 97639
> Uptime: 2 seconds
> GemFire Version: 1.0.0-incubating.M3-SNAPSHOT
> Java Version: 1.8.0_77
> Log File: /Users/jdeppe/debug/server1/server1.log
> JVM Arguments: -Dgemfire.default.locators=192.168.99.1[19991]
> -Dgemfire.use-cluster-configuration=true -XX:OnOutOfMemoryError=kill -KILL %p
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /Users/jdeppe/git/gemfire-develop/open/geode-assembly/build/install/apache-geode/lib/geode-core-1.0.0-incubating.M3-SNAPSHOT.jar:/Users/jdeppe/git/gemfire-develop/open/geode-assembly/build/install/apache-geode/lib/geode-dependencies.jar
> gfsh>list members;
> Name | Id
> | -
> locator1 | 192.168.99.1(locator1:97595:locator):1024
> server1 | 192.168.99.1(server1:97639):1025
> {noformat}
> But cannot stop it...
> {noformat}
> gfsh>stop server --name=server1
> An error occurred while attempting to stop a Cache Server: The HTTP request
> failed with: 500 - Server Error
> {noformat}
> The locator log shows this error:
> {noformat}
> [severe 2016/04/18 13:54:49.754 PDT locator1 tid=0x42]
> org.springframework.http.converter.HttpMessageNotReadableException: Could not
> read document: invalid stream header: 7B226F62; nested exception is
> java.io.StreamCorruptedException: invalid stream header: 7B226F62
> at
> org.springframework.web.servlet.mvc.method.annotation.AbstractMessageConverterMethodArgumentResolver.readWithMessageConverters(AbstractMessageConverterMethodArgumentResolver.java:227)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor.readWithMessageConverters(RequestResponseBodyMethodProcessor.java:147)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor.resolveArgument(RequestResponseBodyMethodProcessor.java:125)
> at
> org.springframework.web.method.support.HandlerMethodArgumentResolverComposite.resolveArgument(HandlerMethodArgumentResolverComposite.java:78)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.getMethodArgumentValues(InvocableHandlerMethod.java:162)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:129)
> at
> org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:110)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:814)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:737)
> at
> org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
> at
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:959)
> at
> org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:893)
> at
> org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:969)
> at
> org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:871)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> at
> org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:845)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:821)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1685)
> at
>
[jira] [Commented] (GEODE-2076) --locators option on start server is broken when specifying an embedded locator
[ https://issues.apache.org/jira/browse/GEODE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15668236#comment-15668236 ] Jinmei Liao commented on GEODE-2076: The error you encounter must be because of the gfsh parsing issue we've just discovered: GEODE-2104. > --locators option on start server is broken when specifying an embedded > locator > --- > > Key: GEODE-2076 > URL: https://issues.apache.org/jira/browse/GEODE-2076 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Diane Hardman >Assignee: Jinmei Liao > Fix For: 1.1.0-incubating > > > This is a follow-on bug from comments in GEODE-1986 from John Blum. > "2. Second, the --locators option on start server is broken, hence the reason > I specified --server-port for both servers on start to avoid bind Exceptions > and used the --J option to specify the embedded Locator of "Server1" with the > gemfire.locators System property when starting "Server2". > Otherwise, "Server2" starts in standalone mode!" > Steps to reproduce: > gfsh>start server --name=Server1 --log-level=config > --locators=localhost[10334] > Starting a Geode Server in /Users/dhardman/test/Server1... > The Cache Server process terminated unexpectedly with exit status 1. Please > refer to the log file in /Users/dhardman/test/Server1 for full details. > objc[9851]: Class JavaLaunchHelper is implemented in both > /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/bin/java > and > /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/lib/libinstrument.dylib. > One of the two will be used. Which one is undefined. > Exception in thread "main" org.apache.geode.GemFireConfigException: Unable to > join the distributed system. Operation either timed out, was stopped or > Locator does not exist. > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.join(GMSMembershipManager.java:659) > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.joinDistributedSystem(GMSMembershipManager.java:745) > at > org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:181) > at > org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102) > at > org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89) > at > org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1112) > at > org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1160) > at > org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:683) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:297) > at > org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:202) > at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:216) > at > org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52) > at > org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:857) > at > org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:769) > at > org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:696) > at > org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:228) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2075) --disable-default-server does not prevent "Geode Server" from attempting the default CacheServer port (40404)
[
https://issues.apache.org/jira/browse/GEODE-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15668232#comment-15668232
]
Jinmei Liao commented on GEODE-2075:
actually the error must be because of the parsing error.
> --disable-default-server does not prevent "Geode Server" from attempting the
> default CacheServer port (40404)
> --
>
> Key: GEODE-2075
> URL: https://issues.apache.org/jira/browse/GEODE-2075
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: Diane Hardman
>Assignee: Jared Stewart
> Fix For: 1.1.0-incubating
>
>
> This is a follow-up bug from issues reported in GEODE-1986 from John Blum.
> "--disable-default-server does not prevent the "Geode Server" from trying to
> start on the default CacheServer port (40404) anyway
> When I attempt to start my second server ("Server2") the firs time if failed
> with..."
> --disable-default-server should choose a different port
> Steps to reproduce:
> gfsh>start server --name=Server1 --log-level=config
> --J=-Dgemfire.start-locator=localhost[10334]
> gfsh>start server --name=Server2 --log-level=config
> --J=-Dgemfire.locators=localhost[10334] --disable-default-server
> Starting a Geode Server in /Users/jblum/pivdev/lab/Server2...
> The Cache Server process terminated unexpectedly with exit status 1. Please
> refer to the log file in /Users/jblum/pivdev/lab/Server2 for full details.
> Exception in thread "main" java.lang.RuntimeException: An IO error occurred
> while starting a Server in /Users/jblum/pivdev/lab/Server2 on
> 10.99.199.3[40404]: Network is unreachable; port (40404) is not available on
> localhost.
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:735)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:633)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:184)
> Caused by: java.net.BindException: Network is unreachable; port (40404) is
> not available on localhost.
> at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:127)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:688)
> ... 2 more
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-2076) --locators option on start server is broken when specifying an embedded locator
[ https://issues.apache.org/jira/browse/GEODE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15668227#comment-15668227 ] Jinmei Liao commented on GEODE-2076: Must be you are using an older version of gfsh. I'll close this for now. > --locators option on start server is broken when specifying an embedded > locator > --- > > Key: GEODE-2076 > URL: https://issues.apache.org/jira/browse/GEODE-2076 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Diane Hardman >Assignee: Jinmei Liao > Fix For: 1.1.0-incubating > > > This is a follow-on bug from comments in GEODE-1986 from John Blum. > "2. Second, the --locators option on start server is broken, hence the reason > I specified --server-port for both servers on start to avoid bind Exceptions > and used the --J option to specify the embedded Locator of "Server1" with the > gemfire.locators System property when starting "Server2". > Otherwise, "Server2" starts in standalone mode!" > Steps to reproduce: > gfsh>start server --name=Server1 --log-level=config > --locators=localhost[10334] > Starting a Geode Server in /Users/dhardman/test/Server1... > The Cache Server process terminated unexpectedly with exit status 1. Please > refer to the log file in /Users/dhardman/test/Server1 for full details. > objc[9851]: Class JavaLaunchHelper is implemented in both > /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/bin/java > and > /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/lib/libinstrument.dylib. > One of the two will be used. Which one is undefined. > Exception in thread "main" org.apache.geode.GemFireConfigException: Unable to > join the distributed system. Operation either timed out, was stopped or > Locator does not exist. > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.join(GMSMembershipManager.java:659) > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.joinDistributedSystem(GMSMembershipManager.java:745) > at > org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:181) > at > org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102) > at > org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89) > at > org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1112) > at > org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1160) > at > org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:683) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:297) > at > org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:202) > at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:216) > at > org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52) > at > org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:857) > at > org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:769) > at > org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:696) > at > org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:228) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2075) --disable-default-server does not prevent "Geode Server" from attempting the default CacheServer port (40404)
[
https://issues.apache.org/jira/browse/GEODE-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15668229#comment-15668229
]
Jinmei Liao commented on GEODE-2075:
close this for now according to [~jblum]'s comment in GEODE-2076
> --disable-default-server does not prevent "Geode Server" from attempting the
> default CacheServer port (40404)
> --
>
> Key: GEODE-2075
> URL: https://issues.apache.org/jira/browse/GEODE-2075
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: Diane Hardman
>Assignee: Jared Stewart
> Fix For: 1.1.0-incubating
>
>
> This is a follow-up bug from issues reported in GEODE-1986 from John Blum.
> "--disable-default-server does not prevent the "Geode Server" from trying to
> start on the default CacheServer port (40404) anyway
> When I attempt to start my second server ("Server2") the firs time if failed
> with..."
> --disable-default-server should choose a different port
> Steps to reproduce:
> gfsh>start server --name=Server1 --log-level=config
> --J=-Dgemfire.start-locator=localhost[10334]
> gfsh>start server --name=Server2 --log-level=config
> --J=-Dgemfire.locators=localhost[10334] --disable-default-server
> Starting a Geode Server in /Users/jblum/pivdev/lab/Server2...
> The Cache Server process terminated unexpectedly with exit status 1. Please
> refer to the log file in /Users/jblum/pivdev/lab/Server2 for full details.
> Exception in thread "main" java.lang.RuntimeException: An IO error occurred
> while starting a Server in /Users/jblum/pivdev/lab/Server2 on
> 10.99.199.3[40404]: Network is unreachable; port (40404) is not available on
> localhost.
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:735)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:633)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:184)
> Caused by: java.net.BindException: Network is unreachable; port (40404) is
> not available on localhost.
> at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:127)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:688)
> ... 2 more
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GEODE-2076) --locators option on start server is broken when specifying an embedded locator
[ https://issues.apache.org/jira/browse/GEODE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2076. Resolution: Fixed Fix Version/s: 1.1.0-incubating > --locators option on start server is broken when specifying an embedded > locator > --- > > Key: GEODE-2076 > URL: https://issues.apache.org/jira/browse/GEODE-2076 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Diane Hardman >Assignee: Jinmei Liao > Fix For: 1.1.0-incubating > > > This is a follow-on bug from comments in GEODE-1986 from John Blum. > "2. Second, the --locators option on start server is broken, hence the reason > I specified --server-port for both servers on start to avoid bind Exceptions > and used the --J option to specify the embedded Locator of "Server1" with the > gemfire.locators System property when starting "Server2". > Otherwise, "Server2" starts in standalone mode!" > Steps to reproduce: > gfsh>start server --name=Server1 --log-level=config > --locators=localhost[10334] > Starting a Geode Server in /Users/dhardman/test/Server1... > The Cache Server process terminated unexpectedly with exit status 1. Please > refer to the log file in /Users/dhardman/test/Server1 for full details. > objc[9851]: Class JavaLaunchHelper is implemented in both > /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/bin/java > and > /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/lib/libinstrument.dylib. > One of the two will be used. Which one is undefined. > Exception in thread "main" org.apache.geode.GemFireConfigException: Unable to > join the distributed system. Operation either timed out, was stopped or > Locator does not exist. > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.join(GMSMembershipManager.java:659) > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.joinDistributedSystem(GMSMembershipManager.java:745) > at > org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:181) > at > org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102) > at > org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89) > at > org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1112) > at > org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1160) > at > org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:683) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:297) > at > org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:202) > at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:216) > at > org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52) > at > org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:857) > at > org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:769) > at > org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:696) > at > org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:228) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2076) --locators option on start server is broken when specifying an embedded locator
[ https://issues.apache.org/jira/browse/GEODE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15667453#comment-15667453 ] Jinmei Liao commented on GEODE-2076: [~jblum] I tried the following gfsh commands, it's working, please let me know what I need to do to reproduce the error. thanks! gfsh>start server --name=server1 --J=-Dgemfire.start-locator=localhost[10334] gfsh>start server --name=server2 --locators=localhost[10334] --server-port=40405 > --locators option on start server is broken when specifying an embedded > locator > --- > > Key: GEODE-2076 > URL: https://issues.apache.org/jira/browse/GEODE-2076 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Diane Hardman >Assignee: Jinmei Liao > > This is a follow-on bug from comments in GEODE-1986 from John Blum. > "2. Second, the --locators option on start server is broken, hence the reason > I specified --server-port for both servers on start to avoid bind Exceptions > and used the --J option to specify the embedded Locator of "Server1" with the > gemfire.locators System property when starting "Server2". > Otherwise, "Server2" starts in standalone mode!" > Steps to reproduce: > gfsh>start server --name=Server1 --log-level=config > --locators=localhost[10334] > Starting a Geode Server in /Users/dhardman/test/Server1... > The Cache Server process terminated unexpectedly with exit status 1. Please > refer to the log file in /Users/dhardman/test/Server1 for full details. > objc[9851]: Class JavaLaunchHelper is implemented in both > /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/bin/java > and > /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/lib/libinstrument.dylib. > One of the two will be used. Which one is undefined. > Exception in thread "main" org.apache.geode.GemFireConfigException: Unable to > join the distributed system. Operation either timed out, was stopped or > Locator does not exist. > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.join(GMSMembershipManager.java:659) > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.joinDistributedSystem(GMSMembershipManager.java:745) > at > org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:181) > at > org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102) > at > org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89) > at > org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1112) > at > org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1160) > at > org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:683) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:297) > at > org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:202) > at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:216) > at > org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52) > at > org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:857) > at > org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:769) > at > org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:696) > at > org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:228) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-2076) --locators option on start server is broken when specifying an embedded locator
[ https://issues.apache.org/jira/browse/GEODE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-2076: -- Assignee: Jinmei Liao > --locators option on start server is broken when specifying an embedded > locator > --- > > Key: GEODE-2076 > URL: https://issues.apache.org/jira/browse/GEODE-2076 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Diane Hardman >Assignee: Jinmei Liao > > This is a follow-on bug from comments in GEODE-1986 from John Blum. > "2. Second, the --locators option on start server is broken, hence the reason > I specified --server-port for both servers on start to avoid bind Exceptions > and used the --J option to specify the embedded Locator of "Server1" with the > gemfire.locators System property when starting "Server2". > Otherwise, "Server2" starts in standalone mode!" > Steps to reproduce: > gfsh>start server --name=Server1 --log-level=config > --locators=localhost[10334] > Starting a Geode Server in /Users/dhardman/test/Server1... > The Cache Server process terminated unexpectedly with exit status 1. Please > refer to the log file in /Users/dhardman/test/Server1 for full details. > objc[9851]: Class JavaLaunchHelper is implemented in both > /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/bin/java > and > /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/lib/libinstrument.dylib. > One of the two will be used. Which one is undefined. > Exception in thread "main" org.apache.geode.GemFireConfigException: Unable to > join the distributed system. Operation either timed out, was stopped or > Locator does not exist. > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.join(GMSMembershipManager.java:659) > at > org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.joinDistributedSystem(GMSMembershipManager.java:745) > at > org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:181) > at > org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102) > at > org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89) > at > org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1112) > at > org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1160) > at > org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:683) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:297) > at > org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:202) > at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:216) > at > org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52) > at > org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:857) > at > org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:769) > at > org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:696) > at > org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:228) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1247) Unable to stop members by name when using gfsh over http
[
https://issues.apache.org/jira/browse/GEODE-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15664801#comment-15664801
]
Jinmei Liao commented on GEODE-1247:
The problem occurs when we use the --name option, the command tries to issue a
query over http first to find out the server mBean, It's the query that chokes
up. Here is a simple test that reproduce this issue:
public class QueryNamesOverHttpDUnitTest {
protected static int[] ports =
AvailablePortHelper.getRandomAvailableTCPPorts(2);
protected static int jmxPort = ports[0];
protected static int httpPort = ports[1];
private static Properties locatorProps = new Properties(){{
setProperty(HTTP_SERVICE_BIND_ADDRESS, "localhost");
setProperty(HTTP_SERVICE_PORT, httpPort+"");
setProperty(JMX_MANAGER_PORT, jmxPort+"");
}};
@Rule
public LocatorStarterRule locatorRule = new LocatorStarterRule(locatorProps);
@Test
public void testQueryNameOverHttp() throws Exception{
LinkIndex links = new LinkIndex();
links.add(new Link("mbean-query", new
URI("http://localhost:"+httpPort+"/gemfire/v1/mbean/query;),
HttpMethod.POST));
RestHttpOperationInvoker invoker = new RestHttpOperationInvoker(links,
mock(Gfsh.class), new HashMap<>());
ObjectName objectName = ObjectName.getInstance("GemFire:type=Member,*");
QueryExp query = Query.eq(Query.attr("Name"), Query.value("mock"));
invoker.queryNames(objectName, query);
}
}
> Unable to stop members by name when using gfsh over http
>
>
> Key: GEODE-1247
> URL: https://issues.apache.org/jira/browse/GEODE-1247
> Project: Geode
> Issue Type: Bug
> Components: gfsh, rest (admin)
>Reporter: Jens Deppe
>
> I'm connecting to my cluster with http:
> {noformat}
> gfsh>connect --use-http=true --url=http://localhost:7070/gemfire/v1
> {noformat}
> And creating a server...
> {noformat}
> gfsh>start server --name=server1
> Starting a GemFire Server in /Users/jdeppe/debug/server1...
> .
> Server in /Users/jdeppe/debug/server1 on 192.168.99.1[40404] as server1 is
> currently online.
> Process ID: 97639
> Uptime: 2 seconds
> GemFire Version: 1.0.0-incubating.M3-SNAPSHOT
> Java Version: 1.8.0_77
> Log File: /Users/jdeppe/debug/server1/server1.log
> JVM Arguments: -Dgemfire.default.locators=192.168.99.1[19991]
> -Dgemfire.use-cluster-configuration=true -XX:OnOutOfMemoryError=kill -KILL %p
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /Users/jdeppe/git/gemfire-develop/open/geode-assembly/build/install/apache-geode/lib/geode-core-1.0.0-incubating.M3-SNAPSHOT.jar:/Users/jdeppe/git/gemfire-develop/open/geode-assembly/build/install/apache-geode/lib/geode-dependencies.jar
> gfsh>list members;
> Name | Id
> | -
> locator1 | 192.168.99.1(locator1:97595:locator):1024
> server1 | 192.168.99.1(server1:97639):1025
> {noformat}
> But cannot stop it...
> {noformat}
> gfsh>stop server --name=server1
> An error occurred while attempting to stop a Cache Server: The HTTP request
> failed with: 500 - Server Error
> {noformat}
> The locator log shows this error:
> {noformat}
> [severe 2016/04/18 13:54:49.754 PDT locator1 tid=0x42]
> org.springframework.http.converter.HttpMessageNotReadableException: Could not
> read document: invalid stream header: 7B226F62; nested exception is
> java.io.StreamCorruptedException: invalid stream header: 7B226F62
> at
> org.springframework.web.servlet.mvc.method.annotation.AbstractMessageConverterMethodArgumentResolver.readWithMessageConverters(AbstractMessageConverterMethodArgumentResolver.java:227)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor.readWithMessageConverters(RequestResponseBodyMethodProcessor.java:147)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor.resolveArgument(RequestResponseBodyMethodProcessor.java:125)
> at
> org.springframework.web.method.support.HandlerMethodArgumentResolverComposite.resolveArgument(HandlerMethodArgumentResolverComposite.java:78)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.getMethodArgumentValues(InvocableHandlerMethod.java:162)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:129)
> at
> org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:110)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:814)
> at
>
[jira] [Comment Edited] (GEODE-1247) Unable to stop members by name when using gfsh over http
[
https://issues.apache.org/jira/browse/GEODE-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15664801#comment-15664801
]
Jinmei Liao edited comment on GEODE-1247 at 11/14/16 7:39 PM:
--
The problem occurs when we use the --name option, the command tries to issue a
query over http first to find out the server mBean, It's the query that chokes
up. Here is a simple test that reproduce this issue:
public class QueryNamesOverHttpDUnitTest {
protected static int[] ports =
AvailablePortHelper.getRandomAvailableTCPPorts(2);
protected static int jmxPort = ports[0];
protected static int httpPort = ports[1];
private static Properties locatorProps = new Properties(){{
setProperty(HTTP_SERVICE_BIND_ADDRESS, "localhost");
setProperty(HTTP_SERVICE_PORT, httpPort+"");
setProperty(JMX_MANAGER_PORT, jmxPort+"");
}};
@Rule
public LocatorStarterRule locatorRule = new LocatorStarterRule(locatorProps);
@Test
public void testQueryNameOverHttp() throws Exception{
LinkIndex links = new LinkIndex();
links.add(new Link("mbean-query", new
URI("http://localhost:"+httpPort+"/gemfire/v1/mbean/query;),
HttpMethod.POST));
RestHttpOperationInvoker invoker = new RestHttpOperationInvoker(links,
mock(Gfsh.class), new HashMap<>());
ObjectName objectName = ObjectName.getInstance("GemFire:type=Member,*");
QueryExp query = Query.eq(Query.attr("Name"), Query.value("mock"));
invoker.queryNames(objectName, query);
}
}
was (Author: jinmeiliao):
The problem occurs when we use the --name option, the command tries to issue a
query over http first to find out the server mBean, It's the query that chokes
up. Here is a simple test that reproduce this issue:
public class QueryNamesOverHttpDUnitTest {
protected static int[] ports =
AvailablePortHelper.getRandomAvailableTCPPorts(2);
protected static int jmxPort = ports[0];
protected static int httpPort = ports[1];
private static Properties locatorProps = new Properties(){{
setProperty(HTTP_SERVICE_BIND_ADDRESS, "localhost");
setProperty(HTTP_SERVICE_PORT, httpPort+"");
setProperty(JMX_MANAGER_PORT, jmxPort+"");
}};
@Rule
public LocatorStarterRule locatorRule = new LocatorStarterRule(locatorProps);
@Test
public void testQueryNameOverHttp() throws Exception{
LinkIndex links = new LinkIndex();
links.add(new Link("mbean-query", new
URI("http://localhost:"+httpPort+"/gemfire/v1/mbean/query;),
HttpMethod.POST));
RestHttpOperationInvoker invoker = new RestHttpOperationInvoker(links,
mock(Gfsh.class), new HashMap<>());
ObjectName objectName = ObjectName.getInstance("GemFire:type=Member,*");
QueryExp query = Query.eq(Query.attr("Name"), Query.value("mock"));
invoker.queryNames(objectName, query);
}
}
> Unable to stop members by name when using gfsh over http
>
>
> Key: GEODE-1247
> URL: https://issues.apache.org/jira/browse/GEODE-1247
> Project: Geode
> Issue Type: Bug
> Components: gfsh, rest (admin)
>Reporter: Jens Deppe
>
> I'm connecting to my cluster with http:
> {noformat}
> gfsh>connect --use-http=true --url=http://localhost:7070/gemfire/v1
> {noformat}
> And creating a server...
> {noformat}
> gfsh>start server --name=server1
> Starting a GemFire Server in /Users/jdeppe/debug/server1...
> .
> Server in /Users/jdeppe/debug/server1 on 192.168.99.1[40404] as server1 is
> currently online.
> Process ID: 97639
> Uptime: 2 seconds
> GemFire Version: 1.0.0-incubating.M3-SNAPSHOT
> Java Version: 1.8.0_77
> Log File: /Users/jdeppe/debug/server1/server1.log
> JVM Arguments: -Dgemfire.default.locators=192.168.99.1[19991]
> -Dgemfire.use-cluster-configuration=true -XX:OnOutOfMemoryError=kill -KILL %p
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /Users/jdeppe/git/gemfire-develop/open/geode-assembly/build/install/apache-geode/lib/geode-core-1.0.0-incubating.M3-SNAPSHOT.jar:/Users/jdeppe/git/gemfire-develop/open/geode-assembly/build/install/apache-geode/lib/geode-dependencies.jar
> gfsh>list members;
> Name | Id
> | -
> locator1 | 192.168.99.1(locator1:97595:locator):1024
> server1 | 192.168.99.1(server1:97639):1025
> {noformat}
> But cannot stop it...
> {noformat}
> gfsh>stop server --name=server1
> An error occurred while attempting to stop a Cache Server: The HTTP request
> failed with: 500 - Server Error
> {noformat}
> The locator log shows this error:
> {noformat}
> [severe 2016/04/18 13:54:49.754 PDT locator1 tid=0x42]
> org.springframework.http.converter.HttpMessageNotReadableException: Could not
> read document: invalid stream header: 7B226F62; nested
[jira] [Comment Edited] (GEODE-1247) Unable to stop members by name when using gfsh over http
[
https://issues.apache.org/jira/browse/GEODE-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15664801#comment-15664801
]
Jinmei Liao edited comment on GEODE-1247 at 11/14/16 7:39 PM:
--
The problem occurs when we use the --name option, the command tries to issue a
query over http first to find out the server mBean, It's the query that chokes
up. Here is a simple test that reproduce this issue:
public class QueryNamesOverHttpDUnitTest {
protected static int[] ports =
AvailablePortHelper.getRandomAvailableTCPPorts(2);
protected static int jmxPort = ports[0];
protected static int httpPort = ports[1];
private static Properties locatorProps = new Properties(){{
setProperty(HTTP_SERVICE_BIND_ADDRESS, "localhost");
setProperty(HTTP_SERVICE_PORT, httpPort+"");
setProperty(JMX_MANAGER_PORT, jmxPort+"");
}};
@Rule
public LocatorStarterRule locatorRule = new LocatorStarterRule(locatorProps);
@Test
public void testQueryNameOverHttp() throws Exception{
LinkIndex links = new LinkIndex();
links.add(new Link("mbean-query", new
URI("http://localhost:"+httpPort+"/gemfire/v1/mbean/query;),
HttpMethod.POST));
RestHttpOperationInvoker invoker = new RestHttpOperationInvoker(links,
mock(Gfsh.class), new HashMap<>());
ObjectName objectName = ObjectName.getInstance("GemFire:type=Member,*");
QueryExp query = Query.eq(Query.attr("Name"), Query.value("mock"));
invoker.queryNames(objectName, query);
}
}
was (Author: jinmeiliao):
The problem occurs when we use the --name option, the command tries to issue a
query over http first to find out the server mBean, It's the query that chokes
up. Here is a simple test that reproduce this issue:
public class QueryNamesOverHttpDUnitTest {
protected static int[] ports =
AvailablePortHelper.getRandomAvailableTCPPorts(2);
protected static int jmxPort = ports[0];
protected static int httpPort = ports[1];
private static Properties locatorProps = new Properties(){{
setProperty(HTTP_SERVICE_BIND_ADDRESS, "localhost");
setProperty(HTTP_SERVICE_PORT, httpPort+"");
setProperty(JMX_MANAGER_PORT, jmxPort+"");
}};
@Rule
public LocatorStarterRule locatorRule = new LocatorStarterRule(locatorProps);
@Test
public void testQueryNameOverHttp() throws Exception{
LinkIndex links = new LinkIndex();
links.add(new Link("mbean-query", new
URI("http://localhost:"+httpPort+"/gemfire/v1/mbean/query;),
HttpMethod.POST));
RestHttpOperationInvoker invoker = new RestHttpOperationInvoker(links,
mock(Gfsh.class), new HashMap<>());
ObjectName objectName = ObjectName.getInstance("GemFire:type=Member,*");
QueryExp query = Query.eq(Query.attr("Name"), Query.value("mock"));
invoker.queryNames(objectName, query);
}
}
> Unable to stop members by name when using gfsh over http
>
>
> Key: GEODE-1247
> URL: https://issues.apache.org/jira/browse/GEODE-1247
> Project: Geode
> Issue Type: Bug
> Components: gfsh, rest (admin)
>Reporter: Jens Deppe
>
> I'm connecting to my cluster with http:
> {noformat}
> gfsh>connect --use-http=true --url=http://localhost:7070/gemfire/v1
> {noformat}
> And creating a server...
> {noformat}
> gfsh>start server --name=server1
> Starting a GemFire Server in /Users/jdeppe/debug/server1...
> .
> Server in /Users/jdeppe/debug/server1 on 192.168.99.1[40404] as server1 is
> currently online.
> Process ID: 97639
> Uptime: 2 seconds
> GemFire Version: 1.0.0-incubating.M3-SNAPSHOT
> Java Version: 1.8.0_77
> Log File: /Users/jdeppe/debug/server1/server1.log
> JVM Arguments: -Dgemfire.default.locators=192.168.99.1[19991]
> -Dgemfire.use-cluster-configuration=true -XX:OnOutOfMemoryError=kill -KILL %p
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /Users/jdeppe/git/gemfire-develop/open/geode-assembly/build/install/apache-geode/lib/geode-core-1.0.0-incubating.M3-SNAPSHOT.jar:/Users/jdeppe/git/gemfire-develop/open/geode-assembly/build/install/apache-geode/lib/geode-dependencies.jar
> gfsh>list members;
> Name | Id
> | -
> locator1 | 192.168.99.1(locator1:97595:locator):1024
> server1 | 192.168.99.1(server1:97639):1025
> {noformat}
> But cannot stop it...
> {noformat}
> gfsh>stop server --name=server1
> An error occurred while attempting to stop a Cache Server: The HTTP request
> failed with: 500 - Server Error
> {noformat}
> The locator log shows this error:
> {noformat}
> [severe 2016/04/18 13:54:49.754 PDT locator1 tid=0x42]
> org.springframework.http.converter.HttpMessageNotReadableException: Could not
> read document: invalid stream header: 7B226F62; nested
[jira] [Updated] (GEODE-2053) Improve Geode Security Framework
[ https://issues.apache.org/jira/browse/GEODE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2053: --- Component/s: management > Improve Geode Security Framework > - > > Key: GEODE-2053 > URL: https://issues.apache.org/jira/browse/GEODE-2053 > Project: Geode > Issue Type: Improvement > Components: management, security >Reporter: Jinmei Liao > > This is based on the feedback that John provided by using Geode Security in > SDG. > Below is his email: > This is will be my final feedback (for now) regarding Geode's Integrated > Security framework/feature. My following recommendations are based on > extensive testing and experience trying to configure and enable Geode's > security services. > As you know, my goal was to be able to quickly, easily and conveniently > configure Geode's security framework services and features using Spring. > However, my techniques could equally apply in any context (e.g. PCF, or a > simple test environment without any framework/container). > To make it quick, easy and convenient, I added support for Geode Integrated > Security in SD Geode by way of the new Annotation configuration model, > specifically with the addition of the new @EnableSecurity annotation [1]. > The new @EnableSecurity annotation can be seen in action in the SDG Contacts > Application RI [2] (apache-geode branch [3]), security-example [4], > GeodeSecurityIntegrationTests class [5]. In this test class, I demonstrate 4 > different ways, each employing different methods an application developer > might use to configure and enable Geode's Integrated Security feature to > secure Apache Geode operationally: > 1. I use Geode's security-manager (System) property to refer to an > application implementation of "Geode's" SecurityManager interface. See here > [6]. > As you may recall, the SimpleSecurityManager [7] implementation is a custom > application implementation of Geode's SecurityManager interface [8] (not to > be confused with Shiro's [20], or even Java's [21] SecurityManager, for that > matter) employing the Repository (DAO) Design Pattern (via the > SecurityRepository interface [9]) to load security configuration meta-data > (e.g. Users, Roles and Permissions) from a variety of data sources. This is > not at all unlike how the Apache Shiro framework, itself, is organized [10] > (i.e. SecurityManager -> (pluggable) Realms). > 2. Next [11], I use Geode's security-shiro-init (System) property to refer to > a Apache Shiro INI security configuration file (e.g. geode-security-shiro.ini > [12]). > NOTE: the Users, Roles and Permissions I define are configured consistently > throughout all my security configurations and data source examples (all based > on my SecurityRepository implementations [13]). > 3. Then [14], I create a custom Apache Shiro Realm based on my > SecurityRepository interface (the SecurityRepositoryAuthorizingRealm [15]), > enabling me, as a application developer, to plug in 1 of my implementations > (i.e. JDBC or XML). > NOTE:, I use XML since Apache Shiro provides no, OOTB implementation for XML, > ironically (Shiro only supports Active Directory, JDBC, JNDI, LDAP and TEXT; > see sub-packages below org.apache.shiro.realm [16]). > 4. Finally [17], I use a canned, OOTB, Apache Shiro provided Realm > implementation (PropertiesRealm [18]), that, as the name suggests, is based > on the Java Properties file format (e.g. geode-security-shiro.properties > [19]). > This may seem like a lot of work, even overkill, but all these were pertinent > in finding a number of bugs not only in SDG's @EnableSecurity annotation and > supporting classes, but with Geode's own Integrated Security framework, and > specifically the API [22]. Individually, or if I had stopped my testing > efforts prematurely with only 1 or 2 examples, I definitely would not have > uncovered all the problems I found. > 1. First, the GeodePermissionResolver [23] is necessary to configure Apache > Shiro's provided (OOTB) Realms correctly. Otherwise, the security > Permissions are not enforced properly (in a hierarchical fashion as > advertised [24], i.e. in section "3. Introduction of ResourcePermission"). > I used [25] the GeodePermissionResolver class to configure the Apache Shiro > provided (OOTB) PropertiesRealm implementation [18]. > Therefore, the GeodePermissionResolver class must NOT be internal. This is > particularly important if the user is using Apache Shiro to the fullest > extent to configure and secure Apache Geode. > Of course, I could have provided my own implementation of the Apache Shiro > PermissionResolver interface [26] (especially given the simplicity of the > GeodePermissionResolver implementation) but if that implementation every > involves more logic behind the scenes,
[jira] [Updated] (GEODE-2053) Improve Geode Security Framework
[ https://issues.apache.org/jira/browse/GEODE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2053: --- Component/s: security > Improve Geode Security Framework > - > > Key: GEODE-2053 > URL: https://issues.apache.org/jira/browse/GEODE-2053 > Project: Geode > Issue Type: Improvement > Components: security >Reporter: Jinmei Liao > > This is based on the feedback that John provided by using Geode Security in > SDG. > Below is his email: > This is will be my final feedback (for now) regarding Geode's Integrated > Security framework/feature. My following recommendations are based on > extensive testing and experience trying to configure and enable Geode's > security services. > As you know, my goal was to be able to quickly, easily and conveniently > configure Geode's security framework services and features using Spring. > However, my techniques could equally apply in any context (e.g. PCF, or a > simple test environment without any framework/container). > To make it quick, easy and convenient, I added support for Geode Integrated > Security in SD Geode by way of the new Annotation configuration model, > specifically with the addition of the new @EnableSecurity annotation [1]. > The new @EnableSecurity annotation can be seen in action in the SDG Contacts > Application RI [2] (apache-geode branch [3]), security-example [4], > GeodeSecurityIntegrationTests class [5]. In this test class, I demonstrate 4 > different ways, each employing different methods an application developer > might use to configure and enable Geode's Integrated Security feature to > secure Apache Geode operationally: > 1. I use Geode's security-manager (System) property to refer to an > application implementation of "Geode's" SecurityManager interface. See here > [6]. > As you may recall, the SimpleSecurityManager [7] implementation is a custom > application implementation of Geode's SecurityManager interface [8] (not to > be confused with Shiro's [20], or even Java's [21] SecurityManager, for that > matter) employing the Repository (DAO) Design Pattern (via the > SecurityRepository interface [9]) to load security configuration meta-data > (e.g. Users, Roles and Permissions) from a variety of data sources. This is > not at all unlike how the Apache Shiro framework, itself, is organized [10] > (i.e. SecurityManager -> (pluggable) Realms). > 2. Next [11], I use Geode's security-shiro-init (System) property to refer to > a Apache Shiro INI security configuration file (e.g. geode-security-shiro.ini > [12]). > NOTE: the Users, Roles and Permissions I define are configured consistently > throughout all my security configurations and data source examples (all based > on my SecurityRepository implementations [13]). > 3. Then [14], I create a custom Apache Shiro Realm based on my > SecurityRepository interface (the SecurityRepositoryAuthorizingRealm [15]), > enabling me, as a application developer, to plug in 1 of my implementations > (i.e. JDBC or XML). > NOTE:, I use XML since Apache Shiro provides no, OOTB implementation for XML, > ironically (Shiro only supports Active Directory, JDBC, JNDI, LDAP and TEXT; > see sub-packages below org.apache.shiro.realm [16]). > 4. Finally [17], I use a canned, OOTB, Apache Shiro provided Realm > implementation (PropertiesRealm [18]), that, as the name suggests, is based > on the Java Properties file format (e.g. geode-security-shiro.properties > [19]). > This may seem like a lot of work, even overkill, but all these were pertinent > in finding a number of bugs not only in SDG's @EnableSecurity annotation and > supporting classes, but with Geode's own Integrated Security framework, and > specifically the API [22]. Individually, or if I had stopped my testing > efforts prematurely with only 1 or 2 examples, I definitely would not have > uncovered all the problems I found. > 1. First, the GeodePermissionResolver [23] is necessary to configure Apache > Shiro's provided (OOTB) Realms correctly. Otherwise, the security > Permissions are not enforced properly (in a hierarchical fashion as > advertised [24], i.e. in section "3. Introduction of ResourcePermission"). > I used [25] the GeodePermissionResolver class to configure the Apache Shiro > provided (OOTB) PropertiesRealm implementation [18]. > Therefore, the GeodePermissionResolver class must NOT be internal. This is > particularly important if the user is using Apache Shiro to the fullest > extent to configure and secure Apache Geode. > Of course, I could have provided my own implementation of the Apache Shiro > PermissionResolver interface [26] (especially given the simplicity of the > GeodePermissionResolver implementation) but if that implementation every > involves more logic behind the scenes, better to
[jira] [Created] (GEODE-2099) Race condition in ConnectToLocatorSSLDUnitTest
Jinmei Liao created GEODE-2099: -- Summary: 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 Fix For: 1.1.0-incubating 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] [Updated] (GEODE-2094) Update admin/dev REST API documentation
[ https://issues.apache.org/jira/browse/GEODE-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2094: --- Description: The commands to start a server can be simplified in the prose on using gfsh with REST commands. 1. In the docs file geode-docs/configuring/cluster_config/gfsh_remote.html.md.erb, about using the admin REST interface, the sample gfsh start server command can be simplified. --J=-Dgemfire.http-service-port=8080 becomes --http-service-port=8080 --J=-Dgemfire.http-service-bind-address=myremotecluster.example.com becomes --http-service-bind-address=myremotecluster.example.com 2. In the docs file geode-docs/rest_apps/setup_config.html.md.erb, about using the dev REST API, the gfsh start server commands given in steps 2 and 3 can be simplified (corrected). --J=-Dgemfire.start-dev-rest-api=true becomes --start-rest-api=true --J=-Dgemfire.http-service-port=8080 becomes --http-service-port=8080 --J=-Dgemfire.http-service-bind-address=localhost becomes --http-service-bind-address=localhost was: The commands to start a server can be simplified in the prose on using gfsh with REST commands. 1. In the docs file geode-docs/configuring/cluster_config/gfsh_remote.html.md.erb, about using the admin REST interface, the sample gfsh start server command can be simplified. --J=-Dgemfire.http-service-port=8080 becomes --http-service-port=8080 --J=-Dgemfire.http-service-bind-address=myremotecluster.example.com becomes --http-service-bind-address=myremotecluster.example.com 2. In the docs file geode-docs/rest_apps/setup_config.html.md.erb, about using the dev REST API, the gfsh start server commands given in steps 2 and 3 can be simplified (corrected). --J=-Dgemfire.start-dev-rest-api=true becomes --J=-Dgemfire.start-rest-api=true --J=-Dgemfire.http-service-port=8080 becomes --http-service-port=8080 --J=-Dgemfire.http-service-bind-address=localhost becomes --http-service-bind-address=localhost > Update admin/dev REST API documentation > --- > > Key: GEODE-2094 > URL: https://issues.apache.org/jira/browse/GEODE-2094 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller > > The commands to start a server can be simplified in the prose on using gfsh > with REST commands. > 1. In the docs file > geode-docs/configuring/cluster_config/gfsh_remote.html.md.erb, about using > the admin REST interface, the sample gfsh start server command can be > simplified. > --J=-Dgemfire.http-service-port=8080 > becomes > --http-service-port=8080 > --J=-Dgemfire.http-service-bind-address=myremotecluster.example.com > becomes > --http-service-bind-address=myremotecluster.example.com > 2. In the docs file geode-docs/rest_apps/setup_config.html.md.erb, about > using the dev REST API, the gfsh start server commands given in steps 2 and 3 > can be simplified (corrected). > --J=-Dgemfire.start-dev-rest-api=true > becomes > --start-rest-api=true > --J=-Dgemfire.http-service-port=8080 > becomes > --http-service-port=8080 > --J=-Dgemfire.http-service-bind-address=localhost > becomes > --http-service-bind-address=localhost -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2085) GEODE-2083
Jinmei Liao created GEODE-2085: -- Summary: GEODE-2083 Key: GEODE-2085 URL: https://issues.apache.org/jira/browse/GEODE-2085 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2084) When executing a rest api in a browser, the login page presented in the browser is not setting the username/password correctly
Jinmei Liao created GEODE-2084: -- Summary: When executing a rest api in a browser, the login page presented in the browser is not setting the username/password correctly Key: GEODE-2084 URL: https://issues.apache.org/jira/browse/GEODE-2084 Project: Geode Issue Type: Bug Reporter: Jinmei Liao Steps to reproduce: 1. start up a server with security 2. in a browser address bar, type in: http://:7070/geode/v1/servers, after putting in username/password, I should see the result json, but instead, I keep getting the login page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2081) ConnectToLocatorSSLDUnitTest.testConnectToLocatorWithLegacyJMXSSL setup fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-2081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-2081.
Resolution: Duplicate
> ConnectToLocatorSSLDUnitTest.testConnectToLocatorWithLegacyJMXSSL setup fails
> intermittently
>
>
> Key: GEODE-2081
> URL: https://issues.apache.org/jira/browse/GEODE-2081
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.1.0-incubating
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
> Labels: CI, Flaky
>
> The setUpLocatorAndConnect methods uses gfshConnector to connect and then
> asserts that it's connected -- this assertion is failing intermittently:
> {noformat}
> org.apache.geode.management.ConnectToLocatorSSLDUnitTest >
> testConnectToLocatorWithLegacyJMXSSL FAILED
> org.apache.geode.InternalGemFireError
> at org.apache.geode.internal.Assert.throwError(Assert.java:96)
> at org.apache.geode.internal.Assert.assertTrue(Assert.java:56)
> at
> org.apache.geode.management.ConnectToLocatorSSLDUnitTest.setUpLocatorAndConnect(ConnectToLocatorSSLDUnitTest.java:132)
> at
> org.apache.geode.management.ConnectToLocatorSSLDUnitTest.testConnectToLocatorWithLegacyJMXSSL(ConnectToLocatorSSLDUnitTest.java:118)
> {noformat}
> See: https://builds.apache.org/job/Geode-nightly/646/console and search down
> for ConnectToLocatorSSLDUnitTest.
> Because it's the setup that's failing, I'm going to annotate every test
> potentially affected with FlakyTest.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1912) gfsh does not validate start server command
[
https://issues.apache.org/jira/browse/GEODE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15645023#comment-15645023
]
Jinmei Liao commented on GEODE-1912:
a feature branch is started (feature/GEODE-1912) to begin the effort of remove
Gfsh parser and joptSimple parser to simplify parsing implementation. We should
rely only in Spring Shell's parsing capability. This branch removes the
dependency, but more work is needed on help and hint.
> 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.4#6332)
[jira] [Updated] (GEODE-2079) CI failure: ConnectToLocatorSSLDUnitTest.testConnectToLocatorWithLegacyJMXSSL
[ https://issues.apache.org/jira/browse/GEODE-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2079: --- Component/s: management > CI failure: ConnectToLocatorSSLDUnitTest.testConnectToLocatorWithLegacyJMXSSL > - > > Key: GEODE-2079 > URL: https://issues.apache.org/jira/browse/GEODE-2079 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Jinmei Liao > Labels: CI, flaky > > org.apache.geode.InternalGemFireError > at org.apache.geode.internal.Assert.throwError(Assert.java:96) > at org.apache.geode.internal.Assert.assertTrue(Assert.java:56) > at > org.apache.geode.management.ConnectToLocatorSSLDUnitTest.setUpLocatorAndConnect(ConnectToLocatorSSLDUnitTest.java:132) > at > org.apache.geode.management.ConnectToLocatorSSLDUnitTest.testConnectToLocatorWithLegacyJMXSSL(ConnectToLocatorSSLDUnitTest.java:118) > 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.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at > org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at >
[jira] [Updated] (GEODE-2079) CI failure: ConnectToLocatorSSLDUnitTest.testConnectToLocatorWithLegacyJMXSSL
[ https://issues.apache.org/jira/browse/GEODE-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2079: --- Labels: CI flaky (was: ) > CI failure: ConnectToLocatorSSLDUnitTest.testConnectToLocatorWithLegacyJMXSSL > - > > Key: GEODE-2079 > URL: https://issues.apache.org/jira/browse/GEODE-2079 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao > Labels: CI, flaky > > org.apache.geode.InternalGemFireError > at org.apache.geode.internal.Assert.throwError(Assert.java:96) > at org.apache.geode.internal.Assert.assertTrue(Assert.java:56) > at > org.apache.geode.management.ConnectToLocatorSSLDUnitTest.setUpLocatorAndConnect(ConnectToLocatorSSLDUnitTest.java:132) > at > org.apache.geode.management.ConnectToLocatorSSLDUnitTest.testConnectToLocatorWithLegacyJMXSSL(ConnectToLocatorSSLDUnitTest.java:118) > 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.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at > org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at >
[jira] [Created] (GEODE-2079) CI failure: ConnectToLocatorSSLDUnitTest.testConnectToLocatorWithLegacyJMXSSL
Jinmei Liao created GEODE-2079: -- Summary: CI failure: ConnectToLocatorSSLDUnitTest.testConnectToLocatorWithLegacyJMXSSL Key: GEODE-2079 URL: https://issues.apache.org/jira/browse/GEODE-2079 Project: Geode Issue Type: Bug Reporter: Jinmei Liao org.apache.geode.InternalGemFireError at org.apache.geode.internal.Assert.throwError(Assert.java:96) at org.apache.geode.internal.Assert.assertTrue(Assert.java:56) at org.apache.geode.management.ConnectToLocatorSSLDUnitTest.setUpLocatorAndConnect(ConnectToLocatorSSLDUnitTest.java:132) at org.apache.geode.management.ConnectToLocatorSSLDUnitTest.testConnectToLocatorWithLegacyJMXSSL(ConnectToLocatorSSLDUnitTest.java:118) 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.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54) at
[jira] [Assigned] (GEODE-1875) com.gemstone.gemfire.security.IntegratedClientAuthDUnitTest.authWithIncorrectPasswordShouldFail
[
https://issues.apache.org/jira/browse/GEODE-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-1875:
--
Assignee: Jinmei Liao
> com.gemstone.gemfire.security.IntegratedClientAuthDUnitTest.authWithIncorrectPasswordShouldFail
> ---
>
> Key: GEODE-1875
> URL: https://issues.apache.org/jira/browse/GEODE-1875
> Project: Geode
> Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: Jinmei Liao
> Labels: CI
>
> {noformat}
> Geode_develop_DistributedTests/3924
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 85
> [fatal 2016/09/07 14:10:19.642 PDT tid=0x1dc]
> (tid=476 msgId=10) No longer connected to localhost[23655].
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:358)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:542)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:491)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:480)
> at sun.reflect.GeneratedMethodAccessor155.invoke(Unknown Source)
> 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.RunAfters.evaluate(RunAfters.java:33)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java: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.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
[jira] [Assigned] (GEODE-1869) IntegratedClientExecuteRegionFunctionAuthDistributedTest.testExecuteRegionFunction
[
https://issues.apache.org/jira/browse/GEODE-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-1869:
--
Assignee: Jinmei Liao
> IntegratedClientExecuteRegionFunctionAuthDistributedTest.testExecuteRegionFunction
> --
>
> Key: GEODE-1869
> URL: https://issues.apache.org/jira/browse/GEODE-1869
> Project: Geode
> Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: Jinmei Liao
> Labels: CI
> Fix For: 1.0.0-incubating
>
>
> {noformat}
> Geode_develop_DistributedTests/3843
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 162
> [fatal 2016/08/31 18:08:45.159 PDT tid=0x47c]
> (tid=1148 msgId=18) No longer connected to localhost[24980].
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:358)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:542)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:491)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:480)
> at sun.reflect.GeneratedMethodAccessor165.invoke(Unknown Source)
> 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.RunAfters.evaluate(RunAfters.java:33)
> 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.GeneratedMethodAccessor528.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.GeneratedMethodAccessor527.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
>
[jira] [Resolved] (GEODE-1875) com.gemstone.gemfire.security.IntegratedClientAuthDUnitTest.authWithIncorrectPasswordShouldFail
[
https://issues.apache.org/jira/browse/GEODE-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-1875.
Resolution: Duplicate
Fix Version/s: 1.1.0-incubating
> com.gemstone.gemfire.security.IntegratedClientAuthDUnitTest.authWithIncorrectPasswordShouldFail
> ---
>
> Key: GEODE-1875
> URL: https://issues.apache.org/jira/browse/GEODE-1875
> Project: Geode
> Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: Jinmei Liao
> Labels: CI
> Fix For: 1.1.0-incubating
>
>
> {noformat}
> Geode_develop_DistributedTests/3924
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 85
> [fatal 2016/09/07 14:10:19.642 PDT tid=0x1dc]
> (tid=476 msgId=10) No longer connected to localhost[23655].
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:358)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:542)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:491)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:480)
> at sun.reflect.GeneratedMethodAccessor155.invoke(Unknown Source)
> 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.RunAfters.evaluate(RunAfters.java:33)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java: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.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Resolved] (GEODE-1878) com.gemstone.gemfire.management.RegionCreateDestroyDUnitTest.testCreateDestroyReservedRegion
[
https://issues.apache.org/jira/browse/GEODE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-1878.
Resolution: Duplicate
Fix Version/s: 1.1.0-incubating
> com.gemstone.gemfire.management.RegionCreateDestroyDUnitTest.testCreateDestroyReservedRegion
>
>
> Key: GEODE-1878
> URL: https://issues.apache.org/jira/browse/GEODE-1878
> Project: Geode
> Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: Jinmei Liao
> Labels: CI
> Fix For: 1.1.0-incubating
>
>
> {noformat}
> Geode_develop_DistributedTests/3933
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 41
> [fatal 2016/09/08 03:40:08.524 PDT tid=0x179]
> (tid=377 msgId=23) No longer connected to cc6-co6.gemstone.com[21361].
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:358)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:542)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:491)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:480)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> 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.RunAfters.evaluate(RunAfters.java:33)
> 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.GeneratedMethodAccessor13.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.GeneratedMethodAccessor12.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
>
[jira] [Resolved] (GEODE-1876) com.gemstone.gemfire.security.IntegratedClientRegionClearAuthDistributedTest.testRegionClear
[
https://issues.apache.org/jira/browse/GEODE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-1876.
Resolution: Duplicate
Fix Version/s: 1.1.0-incubating
> com.gemstone.gemfire.security.IntegratedClientRegionClearAuthDistributedTest.testRegionClear
>
>
> Key: GEODE-1876
> URL: https://issues.apache.org/jira/browse/GEODE-1876
> Project: Geode
> Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: Jinmei Liao
> Labels: CI
> Fix For: 1.1.0-incubating
>
>
> {noformat}
> Geode_develop_DistributedTests/3920
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 41
> [fatal 2016/09/07 06:08:54.299 PDT tid=0x69c]
> (tid=1692 msgId=18) No longer connected to localhost[23844].
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:358)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:542)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:491)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:480)
> at sun.reflect.GeneratedMethodAccessor214.invoke(Unknown Source)
> 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.RunAfters.evaluate(RunAfters.java:33)
> 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.GeneratedMethodAccessor531.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.GeneratedMethodAccessor530.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
>
[jira] [Assigned] (GEODE-1876) com.gemstone.gemfire.security.IntegratedClientRegionClearAuthDistributedTest.testRegionClear
[
https://issues.apache.org/jira/browse/GEODE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-1876:
--
Assignee: Jinmei Liao
> com.gemstone.gemfire.security.IntegratedClientRegionClearAuthDistributedTest.testRegionClear
>
>
> Key: GEODE-1876
> URL: https://issues.apache.org/jira/browse/GEODE-1876
> Project: Geode
> Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: Jinmei Liao
> Labels: CI
> Fix For: 1.1.0-incubating
>
>
> {noformat}
> Geode_develop_DistributedTests/3920
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 41
> [fatal 2016/09/07 06:08:54.299 PDT tid=0x69c]
> (tid=1692 msgId=18) No longer connected to localhost[23844].
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:358)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:542)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:491)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:480)
> at sun.reflect.GeneratedMethodAccessor214.invoke(Unknown Source)
> 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.RunAfters.evaluate(RunAfters.java:33)
> 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.GeneratedMethodAccessor531.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.GeneratedMethodAccessor530.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
>
[jira] [Resolved] (GEODE-1879) com.gemstone.gemfire.management.UniversalMembershipListenerAdapterDUnitTest.testServerEventsInPeerSystem
[
https://issues.apache.org/jira/browse/GEODE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-1879.
Resolution: Duplicate
Fix Version/s: 1.1.0-incubating
> com.gemstone.gemfire.management.UniversalMembershipListenerAdapterDUnitTest.testServerEventsInPeerSystem
>
>
> Key: GEODE-1879
> URL: https://issues.apache.org/jira/browse/GEODE-1879
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: xiaojian zhou
>Assignee: Jinmei Liao
> Labels: CI
> Fix For: 1.1.0-incubating
>
>
> {noformat}
> Geode_develop_DistributedTests/3935
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 417
> [fatal 2016/09/08 09:19:29.240 PDT tid=0xc2]
> (tid=194 msgId=28) No longer connected to latvia.gemstone.com[22692].
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:358)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:542)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:491)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:480)
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> 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.RunAfters.evaluate(RunAfters.java:33)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java: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.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Assigned] (GEODE-1879) com.gemstone.gemfire.management.UniversalMembershipListenerAdapterDUnitTest.testServerEventsInPeerSystem
[
https://issues.apache.org/jira/browse/GEODE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-1879:
--
Assignee: Jinmei Liao (was: Bruce Schuchardt)
> com.gemstone.gemfire.management.UniversalMembershipListenerAdapterDUnitTest.testServerEventsInPeerSystem
>
>
> Key: GEODE-1879
> URL: https://issues.apache.org/jira/browse/GEODE-1879
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: xiaojian zhou
>Assignee: Jinmei Liao
> Labels: CI
>
> {noformat}
> Geode_develop_DistributedTests/3935
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 417
> [fatal 2016/09/08 09:19:29.240 PDT tid=0xc2]
> (tid=194 msgId=28) No longer connected to latvia.gemstone.com[22692].
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:358)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:542)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:491)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:480)
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> 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.RunAfters.evaluate(RunAfters.java:33)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java: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.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Resolved] (GEODE-1877) com.gemstone.gemfire.security.IntegratedClientAuthDUnitTest.authWithCorrectPasswordShouldPass
[
https://issues.apache.org/jira/browse/GEODE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-1877.
Resolution: Duplicate
Fix Version/s: 1.1.0-incubating
> com.gemstone.gemfire.security.IntegratedClientAuthDUnitTest.authWithCorrectPasswordShouldPass
> -
>
> Key: GEODE-1877
> URL: https://issues.apache.org/jira/browse/GEODE-1877
> Project: Geode
> Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: Jinmei Liao
> Labels: CI
> Fix For: 1.1.0-incubating
>
>
> {noformat}
> Geode_develop_DistributedTests/3931
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 123
> [fatal 2016/09/08 03:33:05.727 PDT tid=0x1de]
> (tid=478 msgId=10) No longer connected to localhost[22062].
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:358)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:542)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:491)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:480)
> at sun.reflect.GeneratedMethodAccessor155.invoke(Unknown Source)
> 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.RunAfters.evaluate(RunAfters.java:33)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java: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.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Assigned] (GEODE-1877) com.gemstone.gemfire.security.IntegratedClientAuthDUnitTest.authWithCorrectPasswordShouldPass
[
https://issues.apache.org/jira/browse/GEODE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-1877:
--
Assignee: Jinmei Liao
> com.gemstone.gemfire.security.IntegratedClientAuthDUnitTest.authWithCorrectPasswordShouldPass
> -
>
> Key: GEODE-1877
> URL: https://issues.apache.org/jira/browse/GEODE-1877
> Project: Geode
> Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: Jinmei Liao
> Labels: CI
> Fix For: 1.1.0-incubating
>
>
> {noformat}
> Geode_develop_DistributedTests/3931
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 123
> [fatal 2016/09/08 03:33:05.727 PDT tid=0x1de]
> (tid=478 msgId=10) No longer connected to localhost[22062].
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:358)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:542)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:491)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:480)
> at sun.reflect.GeneratedMethodAccessor155.invoke(Unknown Source)
> 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.RunAfters.evaluate(RunAfters.java:33)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java: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.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Assigned] (GEODE-1878) com.gemstone.gemfire.management.RegionCreateDestroyDUnitTest.testCreateDestroyReservedRegion
[
https://issues.apache.org/jira/browse/GEODE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-1878:
--
Assignee: Jinmei Liao
> com.gemstone.gemfire.management.RegionCreateDestroyDUnitTest.testCreateDestroyReservedRegion
>
>
> Key: GEODE-1878
> URL: https://issues.apache.org/jira/browse/GEODE-1878
> Project: Geode
> Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: Jinmei Liao
> Labels: CI
> Fix For: 1.1.0-incubating
>
>
> {noformat}
> Geode_develop_DistributedTests/3933
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 41
> [fatal 2016/09/08 03:40:08.524 PDT tid=0x179]
> (tid=377 msgId=23) No longer connected to cc6-co6.gemstone.com[21361].
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:358)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:542)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:491)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:480)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> 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.RunAfters.evaluate(RunAfters.java:33)
> 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.GeneratedMethodAccessor13.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.GeneratedMethodAccessor12.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
>
[jira] [Resolved] (GEODE-1482) CI Failure: MemberMBeanAttributesDUnitTest.testConfigAttributes
[ https://issues.apache.org/jira/browse/GEODE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-1482. Resolution: Duplicate Fix Version/s: 1.1.0-incubating > CI Failure: MemberMBeanAttributesDUnitTest.testConfigAttributes > --- > > Key: GEODE-1482 > URL: https://issues.apache.org/jira/browse/GEODE-1482 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Udo Kohlmeyer > Labels: CI > Fix For: 1.1.0-incubating > > > Build #2712 (May 27, 2016 7:09:13 PM) > Revision: 3e8fe7af0ced64d2a15b6c3ce52eb9560a83d097 > https://brazil.gemstone.com:8080/job/Geode_develop_DistributedTests/2712/testReport/com.gemstone.gemfire.management/MemberMBeanAttributesDUnitTest/testConfigAttributes/ > java.lang.AssertionError: Suspicious strings were written to the log during > this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 419 > [fatal 2016/05/27 23:43:44.251 PDT tid=0x1b6] > (tid=438 msgId=303) No longer connected to cc1-co[24095]. > at org.junit.Assert.fail(Assert.java:88) > at > com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:354) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:540) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:489) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:478) > at > com.gemstone.gemfire.test.dunit.internal.JUnit3DistributedTestCase.tearDown(JUnit3DistributedTestCase.java:206) > at junit.framework.TestCase.runBare(TestCase.java:146) > at junit.framework.TestResult$1.protect(TestResult.java:122) > at junit.framework.TestResult.runProtected(TestResult.java:142) > at junit.framework.TestResult.run(TestResult.java:125) > at junit.framework.TestCase.run(TestCase.java:129) > at junit.framework.TestSuite.runTest(TestSuite.java:252) > at junit.framework.TestSuite.run(TestSuite.java:247) > at > org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at > org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360) > at > org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54) > at > org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA
[jira] [Resolved] (GEODE-1538) RegionManagementDUnitTest.testDistributedRegion
[ https://issues.apache.org/jira/browse/GEODE-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-1538. Resolution: Duplicate > RegionManagementDUnitTest.testDistributedRegion > --- > > Key: GEODE-1538 > URL: https://issues.apache.org/jira/browse/GEODE-1538 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Jinmei Liao >Assignee: Jinmei Liao > Labels: CI > > Geode_develop_DistributedTests/2885 > Error Message > java.lang.AssertionError: Suspicious strings were written to the log during > this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 635 > [fatal 2016/06/12 01:46:01.785 PDT tid=0x37c] > (tid=892 msgId=75) No longer connected to cc1-co[25609]. > Stacktrace > java.lang.AssertionError: Suspicious strings were written to the log during > this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 635 > [fatal 2016/06/12 01:46:01.785 PDT tid=0x37c] > (tid=892 msgId=75) No longer connected to cc1-co[25609]. > at org.junit.Assert.fail(Assert.java:88) > at > com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:345) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:532) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:470) > 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.RunAfters.evaluate(RunAfters.java:33) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at >
[jira] [Resolved] (GEODE-1922) CI Failure: RegionCreateDestroyDUnitTest.testCreateDestroyValidRegion
[ https://issues.apache.org/jira/browse/GEODE-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-1922. Resolution: Duplicate Fix Version/s: 1.1.0-incubating > CI Failure: RegionCreateDestroyDUnitTest.testCreateDestroyValidRegion > - > > Key: GEODE-1922 > URL: https://issues.apache.org/jira/browse/GEODE-1922 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Eric Shu >Assignee: Jinmei Liao > Labels: ci > Fix For: 1.1.0-incubating > > > java.lang.AssertionError: Suspicious strings were written to the log during > this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 84 > [fatal 2016/09/16 04:18:58.969 PDT tid=0x191] > (tid=401 msgId=44) No longer connected to cc6-co6.gemstone.com[24253]. > at org.junit.Assert.fail(Assert.java:88) > at > org.apache.geode.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:358) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:545) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:493) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:482) > at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) > 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.RunAfters.evaluate(RunAfters.java:33) > 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.GeneratedMethodAccessor177.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.GeneratedMethodAccessor176.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 >
[jira] [Assigned] (GEODE-1922) CI Failure: RegionCreateDestroyDUnitTest.testCreateDestroyValidRegion
[ https://issues.apache.org/jira/browse/GEODE-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-1922: -- Assignee: Jinmei Liao > CI Failure: RegionCreateDestroyDUnitTest.testCreateDestroyValidRegion > - > > Key: GEODE-1922 > URL: https://issues.apache.org/jira/browse/GEODE-1922 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Eric Shu >Assignee: Jinmei Liao > Labels: ci > Fix For: 1.1.0-incubating > > > java.lang.AssertionError: Suspicious strings were written to the log during > this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 84 > [fatal 2016/09/16 04:18:58.969 PDT tid=0x191] > (tid=401 msgId=44) No longer connected to cc6-co6.gemstone.com[24253]. > at org.junit.Assert.fail(Assert.java:88) > at > org.apache.geode.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:358) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:545) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:493) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:482) > at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) > 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.RunAfters.evaluate(RunAfters.java:33) > 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.GeneratedMethodAccessor177.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.GeneratedMethodAccessor176.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) >
[jira] [Assigned] (GEODE-1538) RegionManagementDUnitTest.testDistributedRegion
[ https://issues.apache.org/jira/browse/GEODE-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-1538: -- Assignee: Jinmei Liao > RegionManagementDUnitTest.testDistributedRegion > --- > > Key: GEODE-1538 > URL: https://issues.apache.org/jira/browse/GEODE-1538 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Jinmei Liao >Assignee: Jinmei Liao > Labels: CI > > Geode_develop_DistributedTests/2885 > Error Message > java.lang.AssertionError: Suspicious strings were written to the log during > this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 635 > [fatal 2016/06/12 01:46:01.785 PDT tid=0x37c] > (tid=892 msgId=75) No longer connected to cc1-co[25609]. > Stacktrace > java.lang.AssertionError: Suspicious strings were written to the log during > this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 635 > [fatal 2016/06/12 01:46:01.785 PDT tid=0x37c] > (tid=892 msgId=75) No longer connected to cc1-co[25609]. > at org.junit.Assert.fail(Assert.java:88) > at > com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:345) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:532) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:470) > 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.RunAfters.evaluate(RunAfters.java:33) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at >
[jira] [Assigned] (GEODE-1539) QueryDataDUnitTest.testMemberWise
[ https://issues.apache.org/jira/browse/GEODE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-1539: -- Assignee: Jinmei Liao > QueryDataDUnitTest.testMemberWise > - > > Key: GEODE-1539 > URL: https://issues.apache.org/jira/browse/GEODE-1539 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao > Labels: CI > > Geode_develop_DistributedTests/2886 > Error Message > java.lang.AssertionError: Suspicious strings were written to the log during > this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 633 > [fatal 2016/06/12 00:22:24.537 PDT tid=0x11a] > (tid=282 msgId=75) No longer connected to cc2-ub[20251]. > Stacktrace > java.lang.AssertionError: Suspicious strings were written to the log during > this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 633 > [fatal 2016/06/12 00:22:24.537 PDT tid=0x11a] > (tid=282 msgId=75) No longer connected to cc2-ub[20251]. > at org.junit.Assert.fail(Assert.java:88) > at > com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:345) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:532) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:470) > 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.RunAfters.evaluate(RunAfters.java:33) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at >
[jira] [Resolved] (GEODE-1539) QueryDataDUnitTest.testMemberWise
[ https://issues.apache.org/jira/browse/GEODE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-1539. Resolution: Duplicate > QueryDataDUnitTest.testMemberWise > - > > Key: GEODE-1539 > URL: https://issues.apache.org/jira/browse/GEODE-1539 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao > Labels: CI > > Geode_develop_DistributedTests/2886 > Error Message > java.lang.AssertionError: Suspicious strings were written to the log during > this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 633 > [fatal 2016/06/12 00:22:24.537 PDT tid=0x11a] > (tid=282 msgId=75) No longer connected to cc2-ub[20251]. > Stacktrace > java.lang.AssertionError: Suspicious strings were written to the log during > this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 633 > [fatal 2016/06/12 00:22:24.537 PDT tid=0x11a] > (tid=282 msgId=75) No longer connected to cc2-ub[20251]. > at org.junit.Assert.fail(Assert.java:88) > at > com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:345) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:532) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:470) > 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.RunAfters.evaluate(RunAfters.java:33) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at >
[jira] [Assigned] (GEODE-1492) CI Failure: CompositeTypeTestDUnitTest.testCompositeTypeGetters
[ https://issues.apache.org/jira/browse/GEODE-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-1492: -- Assignee: Jinmei Liao > CI Failure: CompositeTypeTestDUnitTest.testCompositeTypeGetters > --- > > Key: GEODE-1492 > URL: https://issues.apache.org/jira/browse/GEODE-1492 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.0.0-incubating.M3 >Reporter: Jason Huynh >Assignee: Jinmei Liao > Labels: CI > > This test failed in a private run with the following exception: > java.lang.AssertionError: Suspicious strings were written to the log during > this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 635 > [fatal 2016/05/30 03:43:58.791 PDT tid=0x316] > (tid=790 msgId=295) No longer connected to cc2-rh6[27242]. > at org.junit.Assert.fail(Assert.java:88) > at > com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:354) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:540) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:489) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:478) > at > com.gemstone.gemfire.test.dunit.internal.JUnit3DistributedTestCase.tearDown(JUnit3DistributedTestCase.java:206) > at junit.framework.TestCase.runBare(TestCase.java:146) > at junit.framework.TestResult$1.protect(TestResult.java:122) > at junit.framework.TestResult.runProtected(TestResult.java:142) > at junit.framework.TestResult.run(TestResult.java:125) > at junit.framework.TestCase.run(TestCase.java:129) > at junit.framework.TestSuite.runTest(TestSuite.java:252) > at junit.framework.TestSuite.run(TestSuite.java:247) > at > org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86) > ... > Previously run tests: [TestSubscriptionsDUnitTest, > SharedConfigurationDUnitTest, SharedConfigurationUsingDirDUnitTest, > MultiUserDUnitTest, CompositeTypeTestDUnitTest] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-1492) CI Failure: CompositeTypeTestDUnitTest.testCompositeTypeGetters
[ https://issues.apache.org/jira/browse/GEODE-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-1492. Resolution: Duplicate > CI Failure: CompositeTypeTestDUnitTest.testCompositeTypeGetters > --- > > Key: GEODE-1492 > URL: https://issues.apache.org/jira/browse/GEODE-1492 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.0.0-incubating.M3 >Reporter: Jason Huynh >Assignee: Jinmei Liao > Labels: CI > > This test failed in a private run with the following exception: > java.lang.AssertionError: Suspicious strings were written to the log during > this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 635 > [fatal 2016/05/30 03:43:58.791 PDT tid=0x316] > (tid=790 msgId=295) No longer connected to cc2-rh6[27242]. > at org.junit.Assert.fail(Assert.java:88) > at > com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:354) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:540) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:489) > at > com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.tearDown(JUnit4DistributedTestCase.java:478) > at > com.gemstone.gemfire.test.dunit.internal.JUnit3DistributedTestCase.tearDown(JUnit3DistributedTestCase.java:206) > at junit.framework.TestCase.runBare(TestCase.java:146) > at junit.framework.TestResult$1.protect(TestResult.java:122) > at junit.framework.TestResult.runProtected(TestResult.java:142) > at junit.framework.TestResult.run(TestResult.java:125) > at junit.framework.TestCase.run(TestCase.java:129) > at junit.framework.TestSuite.runTest(TestSuite.java:252) > at junit.framework.TestSuite.run(TestSuite.java:247) > at > org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86) > ... > Previously run tests: [TestSubscriptionsDUnitTest, > SharedConfigurationDUnitTest, SharedConfigurationUsingDirDUnitTest, > MultiUserDUnitTest, CompositeTypeTestDUnitTest] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-1955) JMX suspect string causes tests to fail
[ https://issues.apache.org/jira/browse/GEODE-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-1955. Resolution: Fixed > JMX suspect string causes tests to fail > --- > > Key: GEODE-1955 > URL: https://issues.apache.org/jira/browse/GEODE-1955 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Bruce Schuchardt >Assignee: Jinmei Liao > Labels: ci > > This suspect string is causing periodic failures in a number of unit tests: > Error Message > java.lang.AssertionError: Suspicious strings were written to the log during > this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 283 > [fatal 2016/09/29 12:12:03.891 PDT tid=0x18d] > (tid=397 msgId=39) No longer connected to cc6-co6.gemstone.com[27162]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-1955) JMX suspect string causes tests to fail
[ https://issues.apache.org/jira/browse/GEODE-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-1955: -- Assignee: Jinmei Liao > JMX suspect string causes tests to fail > --- > > Key: GEODE-1955 > URL: https://issues.apache.org/jira/browse/GEODE-1955 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Bruce Schuchardt >Assignee: Jinmei Liao > Labels: ci > > This suspect string is causing periodic failures in a number of unit tests: > Error Message > java.lang.AssertionError: Suspicious strings were written to the log during > this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 283 > [fatal 2016/09/29 12:12:03.891 PDT tid=0x18d] > (tid=397 msgId=39) No longer connected to cc6-co6.gemstone.com[27162]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (GEODE-1506) gfsh should not display call stack, just the error message
[ https://issues.apache.org/jira/browse/GEODE-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15317166#comment-15317166 ] Jinmei Liao edited comment on GEODE-1506 at 11/4/16 2:58 PM: - When server is started with an error, it writes the errors to System.err because the log writer isn't available at that point yet. Gfsh just blindly displays the System.err messages line by line. We have these three choices: 1. Have the server only sending the message line to the system.err instead of the entire stack. -- low effort. 2. Have Gfsh parse the entire errors, and only shows the first message line, and logs the stack trace into gfsh log. ( We will also need to deal with the line saying "going to the server log for more details"). - more code change 3. Leave as it is. - no effort was (Author: jinmeiliao): When server is started with an error, it writes the errors to System.err because the log writer isn't available at that point yet. Gfsh just blindly displays the System.err messages line by line. We have these three choices: 1. Have the server only sending the message line to the system.err instead of the entire stack. -- low effort. 2. Have Gfsh parse the entire errors, and only shows the first message line, and logs the stack trace into gfsh log. ( We will also need to deal with the line saying "going to the server log for more details"). - more code change 3. Leave as it is. - no effort Assigning to PM for assessment. > gfsh should not display call stack, just the error message > -- > > Key: GEODE-1506 > URL: https://issues.apache.org/jira/browse/GEODE-1506 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Anthony Baker >Assignee: Swapnil Bawaskar > > See the following email thread: > http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201606.mbox/%3ccafdh8_1xbyzf44ksai_p9jeu43tajamovagqrtucwvstlgt...@mail.gmail.com%3e > Instead of printing the call stack, we should just display the error message. > Perhaps the full details can be written to the log instead of the console. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2067) Refactor SecurableCommunicationChannels and SecurableCommunicationChannel
Jinmei Liao created GEODE-2067: -- Summary: Refactor SecurableCommunicationChannels and SecurableCommunicationChannel Key: GEODE-2067 URL: https://issues.apache.org/jira/browse/GEODE-2067 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao We should combine org.apache.geode.security.SecurableCommunicationChannels and org.apache.geode.internal.security.SecurableCommunicationChannel into a single class. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2058) reorganize security examples
[ https://issues.apache.org/jira/browse/GEODE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2058. Resolution: Fixed > reorganize security examples > > > Key: GEODE-2058 > URL: https://issues.apache.org/jira/browse/GEODE-2058 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2057) reorganize security packages
[ https://issues.apache.org/jira/browse/GEODE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15633642#comment-15633642 ] Jinmei Liao commented on GEODE-2057: Rather than having a org.apache.geode.security.templates package [31] in the public API, I might consider moving these classes to the examples. I would not want users thinking these Security classes/components are actually sufficient to securing Geode in a production environment (yikes)! Additionally, I would probably even package the classes under org.apache.geode.security [32] a bit differently, having more organization/cleanliness with sub-packages. The security packages feels like a dumping ground for anything and everything, all handling related but slightly different things, functionally... client vs. the server, authentication vs. authorization, securing communication channels, managing over all security, etc, etc. Organization is the key to architecture and making things easy to consume and understand by users. > reorganize security packages > > > Key: GEODE-2057 > URL: https://issues.apache.org/jira/browse/GEODE-2057 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao > > move everything under org.apache.geode.internal.security into > org.apache.geode.security.internal -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2057) reorganize security packages
[ https://issues.apache.org/jira/browse/GEODE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2057: --- Description: move everything under org.apache.geode.internal.security into org.apache.geode.security.internal > reorganize security packages > > > Key: GEODE-2057 > URL: https://issues.apache.org/jira/browse/GEODE-2057 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao > > move everything under org.apache.geode.internal.security into > org.apache.geode.security.internal -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2056) Expose GeodeSecurityService as needed
[ https://issues.apache.org/jira/browse/GEODE-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15633617#comment-15633617 ] Jinmei Liao commented on GEODE-2056: Some of the methods in SecurityService do make sense to be exposed, like all the authorize methods, login, getSubject, keep all the rest internal. > Expose GeodeSecurityService as needed > - > > Key: GEODE-2056 > URL: https://issues.apache.org/jira/browse/GEODE-2056 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao > > 2. I also think it is pertinent that the SecurityService interface [27] be in > Geode's public API. Given this is just an interface, I am not sure why it > was decided to make it "internal" anyway? I see no good reason NOT to expose > this interface, especially since it would be particularly useful for both > API/Framework (e.g. SDG) as well as tools developers developing extensions to > Apache Geode. > I actually did make use of the SecurityService interface [28] in SDG, despite > my (usually) hard rule of NOT ever using any GemFire/Geode internal classes > at all in SDG. Unfortunately, and all too often, in certain cases, such as > the currently released version of Apache Geode, 1.0.0-incubating GA, there is > simply no other way around it when providing support for securing Apache > Geode, especially for making Apache Shiro first-class (something I want to > similarly do for Spring Security). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (GEODE-2053) Improve Geode Security Framework
[ https://issues.apache.org/jira/browse/GEODE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15633607#comment-15633607 ] Jinmei Liao edited comment on GEODE-2053 at 11/3/16 5:45 PM: - 1. First, the GeodePermissionResolver [23] is necessary to configure Apache Shiro's provided (OOTB) Realms correctly. Otherwise, the security Permissions are not enforced properly (in a hierarchical fashion as advertised [24], i.e. in section "3. Introduction of ResourcePermission"). I used [25] the GeodePermissionResolver class to configure the Apache Shiro provided (OOTB) PropertiesRealm implementation [18]. Therefore, the GeodePermissionResolver class must NOT be internal. This is particularly important if the user is using Apache Shiro to the fullest extent to configure and secure Apache Geode. Of course, I could have provided my own implementation of the Apache Shiro PermissionResolver interface [26] (especially given the simplicity of the GeodePermissionResolver implementation) but if that implementation every involves more logic behind the scenes, better to "reuse" then "reinvent" in this case. 2. I also think it is pertinent that the SecurityService interface [27] be in Geode's public API. Given this is just an interface, I am not sure why it was decided to make it "internal" anyway? I see no good reason NOT to expose this interface, especially since it would be particularly useful for both API/Framework (e.g. SDG) as well as tools developers developing extensions to Apache Geode. I actually did make use of the SecurityService interface [28] in SDG, despite my (usually) hard rule of NOT ever using any GemFire/Geode internal classes at all in SDG. Unfortunately, and all too often, in certain cases, such as the currently released version of Apache Geode, 1.0.0-incubating GA, there is simply no other way around it when providing support for securing Apache Geode, especially for making Apache Shiro first-class (something I want to similarly do for Spring Security). The usage in [28] is, well, a hack! I can certainly think of better uses of the SecurityService interface as alluded to above. 3. That brings me to a more general problem I have with the Geode (and GemFires) APIs and organization, which surfaces many anti-patterns. There is only 1 thing I will focus on here... We seem to keep propagating the broken "global", internal package organization [29] that has many, many, cross-cutting concerns in it, and recently adds "security" [30] into the fold. While Security IS a "cross-cutting" concern, it is definitely NOT a recommended way to organize a modular codebase. It will only make it more difficult to organize and modularize Geode into logical, (hopefully, "pluggable") functional units in the future. It would be better to see the org.apache.geode.internal.security package move under org.apache.geode.security. If Security is truly cross-cutting, then it ought to be a separate "module", independent of the other geode modules which can depend on it. While OSGi has lost it steam in recent years, the current organization would be problematic in this environment, especially where some of these classes/interface should have been made public. Still, given Java 9 is moving to a modular architecture, you might want to be a bit more forward thinking in how the codebase organization is going to affect modularity. You can bet users are going to want to leverage Geode in a very modular way once Java 9 is readily available. 4. Rather than having a org.apache.geode.security.templates package [31] in the public API, I might consider moving these classes to the examples. I would not want users thinking these Security classes/components are actually sufficient to securing Geode in a production environment (yikes)! Additionally, I would probably even package the classes under org.apache.geode.security [32] a bit differently, having more organization/cleanliness with sub-packages. The security packages feels like a dumping ground for anything and everything, all handling related but slightly different things, functionally... client vs. the server, authentication vs. authorization, securing communication channels, managing over all security, etc, etc. Organization is the key to architecture and making things easy to consume and understand by users. You could make a SecurableCommunicationChannels [33] an enum, too. 5. One more, and I will leave it at that for now... so I am thinking ahead, and... I really want to build support for Spring Security. This support can come by way of SDG to auto-enable this provider. Anyway, I think it is of paramount importance that we nail down the Geode Integrated Security SPI, allowing different "security providers" to be "plugged" in to secure Apache Geode in different contexts. Initially I was thinking the Geode
[jira] [Commented] (GEODE-2053) Improve Geode Security Framework
[ https://issues.apache.org/jira/browse/GEODE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15633607#comment-15633607 ] Jinmei Liao commented on GEODE-2053: [1] https://github.com/spring-projects/spring-data-gemfire/blob/apache-geode/src/main/java/org/springframework/data/gemfire/config/annotation/EnableSecurity.java [2] https://github.com/jxblum/contacts-application [3] https://github.com/jxblum/contacts-application/tree/apache-geode [4] https://github.com/jxblum/contacts-application/tree/apache-geode/security-example [5] https://github.com/jxblum/contacts-application/blob/apache-geode/security-example/src/test/java/example/app/geode/security/GeodeSecurityIntegrationTests.java [6] https://github.com/jxblum/contacts-application/blob/apache-geode/security-example/src/test/java/example/app/geode/security/GeodeSecurityIntegrationTests.java#L280-L286 [7] https://github.com/jxblum/contacts-application/blob/apache-geode/contacts-core/src/main/java/example/app/geode/security/provider/SimpleSecurityManager.java [8] http://geode.incubator.apache.org/releases/latest/javadoc/org/apache/geode/security/SecurityManager.html [9] https://github.com/jxblum/contacts-application/blob/apache-geode/contacts-core/src/main/java/example/app/geode/security/repository/SecurityRepository.java [10] http://shiro.apache.org/architecture.html#detailed-architecture [11] https://github.com/jxblum/contacts-application/blob/apache-geode/security-example/src/test/java/example/app/geode/security/GeodeSecurityIntegrationTests.java#L311-L315 [12] https://github.com/jxblum/contacts-application/blob/apache-geode/contacts-core/src/main/resources/geode-security-shiro.ini [13] https://github.com/jxblum/contacts-application/tree/apache-geode/contacts-core/src/main/java/example/app/geode/security/repository/support [14] https://github.com/jxblum/contacts-application/blob/apache-geode/security-example/src/test/java/example/app/geode/security/GeodeSecurityIntegrationTests.java#L317-L331 [15] https://github.com/jxblum/contacts-application/blob/apache-geode/contacts-core/src/main/java/example/app/shiro/realm/SecurityRepositoryAuthorizingRealm.java [16] http://shiro.apache.org/static/1.3.2/apidocs/org/apache/shiro/realm/package-summary.html [17] https://github.com/jxblum/contacts-application/blob/apache-geode/security-example/src/test/java/example/app/geode/security/GeodeSecurityIntegrationTests.java#L333-L345 [18] http://shiro.apache.org/static/1.3.2/apidocs/org/apache/shiro/realm/text/PropertiesRealm.html [19] https://github.com/jxblum/contacts-application/blob/apache-geode/contacts-core/src/main/resources/geode-security-shiro.properties [20] http://shiro.apache.org/static/1.3.2/apidocs/org/apache/shiro/mgt/SecurityManager.html [21] http://docs.oracle.com/javase/8/docs/api/java/lang/SecurityManager.html [22] http://geode.incubator.apache.org/releases/latest/javadoc/org/apache/geode/security/package-frame.html [23] https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/security/shiro/GeodePermissionResolver.java [24] https://cwiki.apache.org/confluence/display/GEODE/Geode+Integrated+Security [25] https://github.com/jxblum/contacts-application/blob/apache-geode/security-example/src/test/java/example/app/geode/security/GeodeSecurityIntegrationTests.java#L342 [26] http://shiro.apache.org/static/1.3.2/apidocs/org/apache/shiro/authz/permission/PermissionResolver.html [27] https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java [28] https://github.com/spring-projects/spring-data-gemfire/blob/apache-geode/src/main/java/org/springframework/data/gemfire/config/annotation/ApacheShiroSecurityConfiguration.java#L208-L224 [29] https://github.com/apache/incubator-geode/tree/develop/geode-core/src/main/java/org/apache/geode/internal [30] https://github.com/apache/incubator-geode/tree/develop/geode-core/src/main/java/org/apache/geode/internal/security [31] https://github.com/apache/incubator-geode/tree/develop/geode-core/src/main/java/org/apache/geode/security/templates [32] https://github.com/apache/incubator-geode/tree/develop/geode-core/src/main/java/org/apache/geode/security [33] https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/security/SecurableCommunicationChannels.java [34] http://shiro.apache.org/static/1.3.2/apidocs/org/apache/shiro/subject/Subject.html [35] http://docs.oracle.com/javase/8/docs/api/javax/security/auth/Subject.html > Improve Geode Security Framework > - > > Key: GEODE-2053 > URL: https://issues.apache.org/jira/browse/GEODE-2053 > Project: Geode > Issue Type: Improvement >Reporter: Jinmei Liao > > This is based on the feedback that John provided by using Geode
[jira] [Comment Edited] (GEODE-2053) Improve Geode Security Framework
[ https://issues.apache.org/jira/browse/GEODE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15633607#comment-15633607 ] Jinmei Liao edited comment on GEODE-2053 at 11/3/16 5:45 PM: - [1] https://github.com/spring-projects/spring-data-gemfire/blob/apache-geode/src/main/java/org/springframework/data/gemfire/config/annotation/EnableSecurity.java [2] https://github.com/jxblum/contacts-application [3] https://github.com/jxblum/contacts-application/tree/apache-geode [4] https://github.com/jxblum/contacts-application/tree/apache-geode/security-example [5] https://github.com/jxblum/contacts-application/blob/apache-geode/security-example/src/test/java/example/app/geode/security/GeodeSecurityIntegrationTests.java [6] https://github.com/jxblum/contacts-application/blob/apache-geode/security-example/src/test/java/example/app/geode/security/GeodeSecurityIntegrationTests.java#L280-L286 [7] https://github.com/jxblum/contacts-application/blob/apache-geode/contacts-core/src/main/java/example/app/geode/security/provider/SimpleSecurityManager.java [8] http://geode.incubator.apache.org/releases/latest/javadoc/org/apache/geode/security/SecurityManager.html [9] https://github.com/jxblum/contacts-application/blob/apache-geode/contacts-core/src/main/java/example/app/geode/security/repository/SecurityRepository.java [10] http://shiro.apache.org/architecture.html#detailed-architecture [11] https://github.com/jxblum/contacts-application/blob/apache-geode/security-example/src/test/java/example/app/geode/security/GeodeSecurityIntegrationTests.java#L311-L315 [12] https://github.com/jxblum/contacts-application/blob/apache-geode/contacts-core/src/main/resources/geode-security-shiro.ini [13] https://github.com/jxblum/contacts-application/tree/apache-geode/contacts-core/src/main/java/example/app/geode/security/repository/support [14] https://github.com/jxblum/contacts-application/blob/apache-geode/security-example/src/test/java/example/app/geode/security/GeodeSecurityIntegrationTests.java#L317-L331 [15] https://github.com/jxblum/contacts-application/blob/apache-geode/contacts-core/src/main/java/example/app/shiro/realm/SecurityRepositoryAuthorizingRealm.java [16] http://shiro.apache.org/static/1.3.2/apidocs/org/apache/shiro/realm/package-summary.html [17] https://github.com/jxblum/contacts-application/blob/apache-geode/security-example/src/test/java/example/app/geode/security/GeodeSecurityIntegrationTests.java#L333-L345 [18] http://shiro.apache.org/static/1.3.2/apidocs/org/apache/shiro/realm/text/PropertiesRealm.html [19] https://github.com/jxblum/contacts-application/blob/apache-geode/contacts-core/src/main/resources/geode-security-shiro.properties [20] http://shiro.apache.org/static/1.3.2/apidocs/org/apache/shiro/mgt/SecurityManager.html [21] http://docs.oracle.com/javase/8/docs/api/java/lang/SecurityManager.html [22] http://geode.incubator.apache.org/releases/latest/javadoc/org/apache/geode/security/package-frame.html [23] https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/security/shiro/GeodePermissionResolver.java [24] https://cwiki.apache.org/confluence/display/GEODE/Geode+Integrated+Security [25] https://github.com/jxblum/contacts-application/blob/apache-geode/security-example/src/test/java/example/app/geode/security/GeodeSecurityIntegrationTests.java#L342 [26] http://shiro.apache.org/static/1.3.2/apidocs/org/apache/shiro/authz/permission/PermissionResolver.html [27] https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java [28] https://github.com/spring-projects/spring-data-gemfire/blob/apache-geode/src/main/java/org/springframework/data/gemfire/config/annotation/ApacheShiroSecurityConfiguration.java#L208-L224 [29] https://github.com/apache/incubator-geode/tree/develop/geode-core/src/main/java/org/apache/geode/internal [30] https://github.com/apache/incubator-geode/tree/develop/geode-core/src/main/java/org/apache/geode/internal/security [31] https://github.com/apache/incubator-geode/tree/develop/geode-core/src/main/java/org/apache/geode/security/templates [32] https://github.com/apache/incubator-geode/tree/develop/geode-core/src/main/java/org/apache/geode/security [33] https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/security/SecurableCommunicationChannels.java [34] http://shiro.apache.org/static/1.3.2/apidocs/org/apache/shiro/subject/Subject.html [35] http://docs.oracle.com/javase/8/docs/api/javax/security/auth/Subject.html was (Author: jinmeiliao): 1. First, the GeodePermissionResolver [23] is necessary to configure Apache Shiro's provided (OOTB) Realms correctly. Otherwise, the security Permissions are not enforced properly (in a hierarchical fashion as advertised [24], i.e. in section "3. Introduction of
[jira] [Updated] (GEODE-2056) Expose GeodeSecurityService as needed
[ https://issues.apache.org/jira/browse/GEODE-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2056: --- Description: 2. I also think it is pertinent that the SecurityService interface [27] be in Geode's public API. Given this is just an interface, I am not sure why it was decided to make it "internal" anyway? I see no good reason NOT to expose this interface, especially since it would be particularly useful for both API/Framework (e.g. SDG) as well as tools developers developing extensions to Apache Geode. I actually did make use of the SecurityService interface [28] in SDG, despite my (usually) hard rule of NOT ever using any GemFire/Geode internal classes at all in SDG. Unfortunately, and all too often, in certain cases, such as the currently released version of Apache Geode, 1.0.0-incubating GA, there is simply no other way around it when providing support for securing Apache Geode, especially for making Apache Shiro first-class (something I want to similarly do for Spring Security). > Expose GeodeSecurityService as needed > - > > Key: GEODE-2056 > URL: https://issues.apache.org/jira/browse/GEODE-2056 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao > > 2. I also think it is pertinent that the SecurityService interface [27] be in > Geode's public API. Given this is just an interface, I am not sure why it > was decided to make it "internal" anyway? I see no good reason NOT to expose > this interface, especially since it would be particularly useful for both > API/Framework (e.g. SDG) as well as tools developers developing extensions to > Apache Geode. > I actually did make use of the SecurityService interface [28] in SDG, despite > my (usually) hard rule of NOT ever using any GemFire/Geode internal classes > at all in SDG. Unfortunately, and all too often, in certain cases, such as > the currently released version of Apache Geode, 1.0.0-incubating GA, there is > simply no other way around it when providing support for securing Apache > Geode, especially for making Apache Shiro first-class (something I want to > similarly do for Spring Security). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2055) Expose GeodePermissionResolver
[ https://issues.apache.org/jira/browse/GEODE-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2055: --- Description: 1. First, the GeodePermissionResolver [23] is necessary to configure Apache Shiro's provided (OOTB) Realms correctly. Otherwise, the security Permissions are not enforced properly (in a hierarchical fashion as advertised [24], i.e. in section "3. Introduction of ResourcePermission"). I used [25] the GeodePermissionResolver class to configure the Apache Shiro provided (OOTB) PropertiesRealm implementation [18]. Therefore, the GeodePermissionResolver class must NOT be internal. This is particularly important if the user is using Apache Shiro to the fullest extent to configure and secure Apache Geode. Of course, I could have provided my own implementation of the Apache Shiro PermissionResolver interface [26] (especially given the simplicity of the GeodePermissionResolver implementation) but if that implementation every involves more logic behind the scenes, better to "reuse" then "reinvent" in this case. > Expose GeodePermissionResolver > -- > > Key: GEODE-2055 > URL: https://issues.apache.org/jira/browse/GEODE-2055 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao > > 1. First, the GeodePermissionResolver [23] is necessary to configure Apache > Shiro's provided (OOTB) Realms correctly. Otherwise, the security > Permissions are not enforced properly (in a hierarchical fashion as > advertised [24], i.e. in section "3. Introduction of ResourcePermission"). > I used [25] the GeodePermissionResolver class to configure the Apache Shiro > provided (OOTB) PropertiesRealm implementation [18]. > Therefore, the GeodePermissionResolver class must NOT be internal. This is > particularly important if the user is using Apache Shiro to the fullest > extent to configure and secure Apache Geode. > Of course, I could have provided my own implementation of the Apache Shiro > PermissionResolver interface [26] (especially given the simplicity of the > GeodePermissionResolver implementation) but if that implementation every > involves more logic behind the scenes, better to "reuse" then "reinvent" in > this case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2054) Do not use classpath: when looking for seucrity-shiro-ini files
[ https://issues.apache.org/jira/browse/GEODE-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2054: --- Description: 1. Hardcoding [1] the "resource path prefix" [2] (i.e. "classpath:") when the user decides to use Apache Shiro [3] to configure security for Apache Geode [4] is well, again, rather limiting. If a user specifies the Geode (System) property, "security-shiro-init", referencing an Apache Shiro INI configuration file, why not let the user decide the resource path source (i.e. classpath:, file:, or url:) of the INI file. For example... -Dgeode.security-shiro-init=file:/absolute/file/system/path/to/users/application/shiro.ini I would not arbitrarily restrict users to only the classapth for locating resources. It is unlikely the INI file will contain "sensitive" data (e.g. usernames/passwords, or even permission meta-data) in a production environment. It is more likely, that the users will be configuring 1 or more Shiro Realms declared in the [main] section of the INI file to load the security configuration meta-data from an external repository. Additionally, Apache Shiro has the ability to detect file changes, and dynamically reload the INI security configuration file [5] when the file: resource path (i.e. file system) is used. > Do not use classpath: when looking for seucrity-shiro-ini files > --- > > Key: GEODE-2054 > URL: https://issues.apache.org/jira/browse/GEODE-2054 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao > > 1. Hardcoding [1] the "resource path prefix" [2] (i.e. "classpath:") when the > user decides to use Apache Shiro [3] to configure security for Apache Geode > [4] is well, again, rather limiting. > If a user specifies the Geode (System) property, "security-shiro-init", > referencing an Apache Shiro INI configuration file, why not let the user > decide the resource path source (i.e. classpath:, file:, or url:) of the INI > file. For example... > -Dgeode.security-shiro-init=file:/absolute/file/system/path/to/users/application/shiro.ini > I would not arbitrarily restrict users to only the classapth for locating > resources. It is unlikely the INI file will contain "sensitive" data (e.g. > usernames/passwords, or even permission meta-data) in a production > environment. It is more likely, that the users will be configuring 1 or more > Shiro Realms declared in the [main] section of the INI file to load the > security configuration meta-data from an external repository. > Additionally, Apache Shiro has the ability to detect file changes, and > dynamically reload the INI security configuration file [5] when the file: > resource path (i.e. file system) is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2054) Do not use classpath: when looking for security-shiro-ini files
[ https://issues.apache.org/jira/browse/GEODE-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2054: --- Summary: Do not use classpath: when looking for security-shiro-ini files (was: Do not use classpath: when looking for seucrity-shiro-ini files) > Do not use classpath: when looking for security-shiro-ini files > --- > > Key: GEODE-2054 > URL: https://issues.apache.org/jira/browse/GEODE-2054 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao > > 1. Hardcoding [1] the "resource path prefix" [2] (i.e. "classpath:") when the > user decides to use Apache Shiro [3] to configure security for Apache Geode > [4] is well, again, rather limiting. > If a user specifies the Geode (System) property, "security-shiro-init", > referencing an Apache Shiro INI configuration file, why not let the user > decide the resource path source (i.e. classpath:, file:, or url:) of the INI > file. For example... > -Dgeode.security-shiro-init=file:/absolute/file/system/path/to/users/application/shiro.ini > I would not arbitrarily restrict users to only the classapth for locating > resources. It is unlikely the INI file will contain "sensitive" data (e.g. > usernames/passwords, or even permission meta-data) in a production > environment. It is more likely, that the users will be configuring 1 or more > Shiro Realms declared in the [main] section of the INI file to load the > security configuration meta-data from an external repository. > Additionally, Apache Shiro has the ability to detect file changes, and > dynamically reload the INI security configuration file [5] when the file: > resource path (i.e. file system) is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2066) Log UnauthorizedException message at INFO and stack at DEBUG
Jinmei Liao created GEODE-2066: -- Summary: Log UnauthorizedException message at INFO and stack at DEBUG Key: GEODE-2066 URL: https://issues.apache.org/jira/browse/GEODE-2066 Project: Geode Issue Type: Sub-task Components: security Reporter: Jinmei Liao 1. First, a similar Stack Trace appears at the INFO log-level every time a security violation (e.g. authentication or authorization failure) occurs... [info 2016/10/25 21:09:08.339 PDT tid=0x24] (tid=36 msgId=0) Could not execute "list members". org.apache.geode.security.NotAuthorizedException: guest not authorized for CLUSTER:READ at org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:303) at org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:280) at org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:275) at org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:217) at org.apache.geode.management.internal.cli.remote.CommandProcessor.executeCommand(CommandProcessor.java:116) at org.apache.geode.management.internal.cli.remote.CommandStatementImpl.process(CommandStatementImpl.java:66) at org.apache.geode.management.internal.cli.remote.MemberCommandService.processCommand(MemberCommandService.java:54) at org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1690) at org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:406) at org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:399) 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.GeneratedMethodAccessor8.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 org.apache.geode.management.internal.security.MBeanServerWrapper.invoke(MBeanServerWrapper.java:208) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1471) at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1312) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1411) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:832) 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.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323) at sun.rmi.transport.Transport$1.run(Transport.java:200) at sun.rmi.transport.Transport$1.run(Transport.java:197) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:196) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826) at
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15632873#comment-15632873
]
Jinmei Liao edited comment on GEODE-1986 at 11/3/16 2:32 PM:
-
The fix was put in on 10/11, I believe by that time, 1.0.0 is already out. I've
updated the fixed version of this ticket. The fix is also in 9.0 support branch.
Do we need to backport this to 1.0.0? A simple workaround of this problem is to
set enable-cluster-configuration=false when you start up the embedded locator
(your server 1).
was (Author: jinmeiliao):
The fix was put in on 10/11, I believe by that time, 1.0.0 is already out. I've
updated the fixed version of this ticket. The fix is also in 9.0 support branch.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Fix For: 1.1.0-incubating
>
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15632873#comment-15632873
]
Jinmei Liao commented on GEODE-1986:
The fix was put in on 10/11, I believe by that time, 1.0.0 is already out. I've
updated the fixed version of this ticket. The fix is also in 9.0 support branch.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Fix For: 1.1.0-incubating
>
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-1986:
---
Fix Version/s: (was: 1.0.0-incubating)
1.1.0-incubating
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Fix For: 1.1.0-incubating
>
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GEODE-2058) reorganize security examples
Jinmei Liao created GEODE-2058: -- Summary: reorganize security examples Key: GEODE-2058 URL: https://issues.apache.org/jira/browse/GEODE-2058 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2056) Expose GeodeSecurityService as needed
Jinmei Liao created GEODE-2056: -- Summary: Expose GeodeSecurityService as needed Key: GEODE-2056 URL: https://issues.apache.org/jira/browse/GEODE-2056 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2057) reorganize security packages
Jinmei Liao created GEODE-2057: -- Summary: reorganize security packages Key: GEODE-2057 URL: https://issues.apache.org/jira/browse/GEODE-2057 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2055) Expose GeodePermissionResolver
Jinmei Liao created GEODE-2055: -- Summary: Expose GeodePermissionResolver Key: GEODE-2055 URL: https://issues.apache.org/jira/browse/GEODE-2055 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2054) Do not use classpath: when looking for seucrity-shiro-ini files
Jinmei Liao created GEODE-2054: -- Summary: Do not use classpath: when looking for seucrity-shiro-ini files Key: GEODE-2054 URL: https://issues.apache.org/jira/browse/GEODE-2054 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2053) Improve Geode Security Framework
Jinmei Liao created GEODE-2053: -- Summary: Improve Geode Security Framework Key: GEODE-2053 URL: https://issues.apache.org/jira/browse/GEODE-2053 Project: Geode Issue Type: Improvement Reporter: Jinmei Liao This is based on the feedback that John provided by using Geode Security in SDG. Below is his email: This is will be my final feedback (for now) regarding Geode's Integrated Security framework/feature. My following recommendations are based on extensive testing and experience trying to configure and enable Geode's security services. As you know, my goal was to be able to quickly, easily and conveniently configure Geode's security framework services and features using Spring. However, my techniques could equally apply in any context (e.g. PCF, or a simple test environment without any framework/container). To make it quick, easy and convenient, I added support for Geode Integrated Security in SD Geode by way of the new Annotation configuration model, specifically with the addition of the new @EnableSecurity annotation [1]. The new @EnableSecurity annotation can be seen in action in the SDG Contacts Application RI [2] (apache-geode branch [3]), security-example [4], GeodeSecurityIntegrationTests class [5]. In this test class, I demonstrate 4 different ways, each employing different methods an application developer might use to configure and enable Geode's Integrated Security feature to secure Apache Geode operationally: 1. I use Geode's security-manager (System) property to refer to an application implementation of "Geode's" SecurityManager interface. See here [6]. As you may recall, the SimpleSecurityManager [7] implementation is a custom application implementation of Geode's SecurityManager interface [8] (not to be confused with Shiro's [20], or even Java's [21] SecurityManager, for that matter) employing the Repository (DAO) Design Pattern (via the SecurityRepository interface [9]) to load security configuration meta-data (e.g. Users, Roles and Permissions) from a variety of data sources. This is not at all unlike how the Apache Shiro framework, itself, is organized [10] (i.e. SecurityManager -> (pluggable) Realms). 2. Next [11], I use Geode's security-shiro-init (System) property to refer to a Apache Shiro INI security configuration file (e.g. geode-security-shiro.ini [12]). NOTE: the Users, Roles and Permissions I define are configured consistently throughout all my security configurations and data source examples (all based on my SecurityRepository implementations [13]). 3. Then [14], I create a custom Apache Shiro Realm based on my SecurityRepository interface (the SecurityRepositoryAuthorizingRealm [15]), enabling me, as a application developer, to plug in 1 of my implementations (i.e. JDBC or XML). NOTE:, I use XML since Apache Shiro provides no, OOTB implementation for XML, ironically (Shiro only supports Active Directory, JDBC, JNDI, LDAP and TEXT; see sub-packages below org.apache.shiro.realm [16]). 4. Finally [17], I use a canned, OOTB, Apache Shiro provided Realm implementation (PropertiesRealm [18]), that, as the name suggests, is based on the Java Properties file format (e.g. geode-security-shiro.properties [19]). This may seem like a lot of work, even overkill, but all these were pertinent in finding a number of bugs not only in SDG's @EnableSecurity annotation and supporting classes, but with Geode's own Integrated Security framework, and specifically the API [22]. Individually, or if I had stopped my testing efforts prematurely with only 1 or 2 examples, I definitely would not have uncovered all the problems I found. 1. First, the GeodePermissionResolver [23] is necessary to configure Apache Shiro's provided (OOTB) Realms correctly. Otherwise, the security Permissions are not enforced properly (in a hierarchical fashion as advertised [24], i.e. in section "3. Introduction of ResourcePermission"). I used [25] the GeodePermissionResolver class to configure the Apache Shiro provided (OOTB) PropertiesRealm implementation [18]. Therefore, the GeodePermissionResolver class must NOT be internal. This is particularly important if the user is using Apache Shiro to the fullest extent to configure and secure Apache Geode. Of course, I could have provided my own implementation of the Apache Shiro PermissionResolver interface [26] (especially given the simplicity of the GeodePermissionResolver implementation) but if that implementation every involves more logic behind the scenes, better to "reuse" then "reinvent" in this case. 2. I also think it is pertinent that the SecurityService interface [27] be in Geode's public API. Given this is just an interface, I am not sure why it was decided to make it "internal" anyway? I see no good reason NOT to expose this interface, especially since it would be
[jira] [Resolved] (GEODE-17) Provide Integrated Security
[ https://issues.apache.org/jira/browse/GEODE-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-17. -- Resolution: Fixed > Provide Integrated Security > --- > > Key: GEODE-17 > URL: https://issues.apache.org/jira/browse/GEODE-17 > Project: Geode > Issue Type: New Feature > Components: client/server, docs, security >Reporter: Tushar Khairnar >Assignee: Jens Deppe > Labels: security > > Integrated Security: Purpose of integrated security feature is to provide > uniform authentication and authorization capabilities for all Geode clients. > Geode distributed systems has different clients, some perform cache/region > operations, some perform management operations. In order to authenticate and > authorize these actions we need single consistent framework or interface. > Such interface should allow configuration of access levels from single place > and/or repository. > The key requirements being met here are > - Authentication of all clients from single plugin > - Authorization of cache/data operations (through cache-client and REST) and > managements (GFSH/JMX) operations from single plugin > - Extend existing Client-Server security framework -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2025) When starting a geode server from gfsh, the default http-service-port it's using is 8080
[ https://issues.apache.org/jira/browse/GEODE-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2025. Resolution: Fixed > When starting a geode server from gfsh, the default http-service-port it's > using is 8080 > > > Key: GEODE-2025 > URL: https://issues.apache.org/jira/browse/GEODE-2025 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao > > This is different from the default-http-service-port defined in > DistributionConfig. As a result, if we stat a locator, the default > http-service-port is 7070, but if we start a server, it's using 8080. This > will be confusing to users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-2025) When starting a geode server from gfsh, the default http-service-port it's using is 8080
[ https://issues.apache.org/jira/browse/GEODE-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-2025: -- Assignee: Jinmei Liao > When starting a geode server from gfsh, the default http-service-port it's > using is 8080 > > > Key: GEODE-2025 > URL: https://issues.apache.org/jira/browse/GEODE-2025 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao > > This is different from the default-http-service-port defined in > DistributionConfig. As a result, if we stat a locator, the default > http-service-port is 7070, but if we start a server, it's using 8080. This > will be confusing to users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2030) Geode Security framework needs to support easier integration in SDG
[ https://issues.apache.org/jira/browse/GEODE-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2030: --- Component/s: management > Geode Security framework needs to support easier integration in SDG > --- > > Key: GEODE-2030 > URL: https://issues.apache.org/jira/browse/GEODE-2030 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Jinmei Liao > > While using gemfire properties to configure security is doable in SDG, they > would prefer an object based injection model to configure security. Here are > the two things they would need: > 1. directly inject a Gemfire SecurityManager object into CacheFactory. > 2. directly configure Shiro Security using their xml based configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2030) Geode Security framework needs to support easier integration in SDG
[
https://issues.apache.org/jira/browse/GEODE-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602398#comment-15602398
]
Jinmei Liao commented on GEODE-2030:
John's email:
To make my example a bit more concrete in Geode terms... as a developer, I
would like to have the ability to do the following...
SecurityConfigurationRepository repository = ...;
SecurityManager securityManager = new
example.app.security.MySecurityManager(repository);
new CacheFactory()
.set("name", "Example")
.set("log-level", "config")
.setSecurityManager(securityManager)
...
.create();
This would be very similar to configuring a PdxSerializer using...
CacheFactory.setPdxSerializer(:PdxSerializer); [1]
In fact, having the ability to configure PDX in this manner was very
useful/instrumental in creating a "composable" [2] PdxSerializer, in this SDG
test class (defined here [3], configured using a Spring FactoryBean [4], and
configuration here [5]). As you can see, I use individual PdxSerializer for
each application domain object type (here [6] and here [7]). However, since
GemFire/Geode can only accept a single PdxSerializer instance, I compose them.
All too often, I see Geode developers naively cram all the de/serialization
logic for all their application domain objects into a single PdxSerializer
instance.
Employing the appropriate application design patterns makes this much easier to
configure, test and maintain.
Using a similar approach in Security would be very beneficial, IMO.
> Geode Security framework needs to support easier integration in SDG
> ---
>
> Key: GEODE-2030
> URL: https://issues.apache.org/jira/browse/GEODE-2030
> Project: Geode
> Issue Type: Bug
>Reporter: Jinmei Liao
>
> While using gemfire properties to configure security is doable in SDG, they
> would prefer an object based injection model to configure security. Here are
> the two things they would need:
> 1. directly inject a Gemfire SecurityManager object into CacheFactory.
> 2. directly configure Shiro Security using their xml based configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GEODE-2030) Geode Security framework needs to support easier integration in SDG
Jinmei Liao created GEODE-2030: -- Summary: Geode Security framework needs to support easier integration in SDG Key: GEODE-2030 URL: https://issues.apache.org/jira/browse/GEODE-2030 Project: Geode Issue Type: Bug Reporter: Jinmei Liao While using gemfire properties to configure security is doable in SDG, they would prefer an object based injection model to configure security. Here are the two things they would need: 1. directly inject a Gemfire SecurityManager object into CacheFactory. 2. directly configure Shiro Security using their xml based configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2025) When starting a geode server from gfsh, the default http-service-port it's using is 8080
Jinmei Liao created GEODE-2025: -- Summary: When starting a geode server from gfsh, the default http-service-port it's using is 8080 Key: GEODE-2025 URL: https://issues.apache.org/jira/browse/GEODE-2025 Project: Geode Issue Type: Bug Components: management Reporter: Jinmei Liao This is different from the default-http-service-port defined in DistributionConfig. As a result, if we stat a locator, the default http-service-port is 7070, but if we start a server, it's using 8080. This will be confusing to users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2020) Add more tests to replace the legacy tests
[ https://issues.apache.org/jira/browse/GEODE-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2020: --- Description: Whenever a legacy test failed, we should write an integration test or Dunit test to reproduce it and then fix it. > Add more tests to replace the legacy tests > -- > > Key: GEODE-2020 > URL: https://issues.apache.org/jira/browse/GEODE-2020 > Project: Geode > Issue Type: Task > Components: management >Reporter: Jinmei Liao > > Whenever a legacy test failed, we should write an integration test or Dunit > test to reproduce it and then fix it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2020) Add more tests to replace the legacy tests
Jinmei Liao created GEODE-2020: -- Summary: Add more tests to replace the legacy tests Key: GEODE-2020 URL: https://issues.apache.org/jira/browse/GEODE-2020 Project: Geode Issue Type: Task Components: management Reporter: Jinmei Liao -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2004) Create/update/delete query through rest api should require DATA:READ instead of DATA:WRITE
[ https://issues.apache.org/jira/browse/GEODE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-2004. Resolution: Fixed > Create/update/delete query through rest api should require DATA:READ instead > of DATA:WRITE > -- > > Key: GEODE-2004 > URL: https://issues.apache.org/jira/browse/GEODE-2004 > Project: Geode > Issue Type: Bug > Components: management, security >Reporter: Jinmei Liao >Assignee: Kevin Duling > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2004) Create/update/delete query through rest api should require DATA:READ instead of DATA:WRITE
[ https://issues.apache.org/jira/browse/GEODE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2004: --- Summary: Create/update/delete query through rest api should require DATA:READ instead of DATA:WRITE (was: Create/update/delete query through rest api should require DATA:MANAGE instead of DATA:READ.) > Create/update/delete query through rest api should require DATA:READ instead > of DATA:WRITE > -- > > Key: GEODE-2004 > URL: https://issues.apache.org/jira/browse/GEODE-2004 > Project: Geode > Issue Type: Bug > Components: management, security >Reporter: Jinmei Liao > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2004) Create/update/delete query through rest api should require DATA:MANAGE instead of DATA:READ.
Jinmei Liao created GEODE-2004: -- Summary: Create/update/delete query through rest api should require DATA:MANAGE instead of DATA:READ. Key: GEODE-2004 URL: https://issues.apache.org/jira/browse/GEODE-2004 Project: Geode Issue Type: Bug Components: management, security Reporter: Jinmei Liao -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1883) AuthInitializer should be made optional
[
https://issues.apache.org/jira/browse/GEODE-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15582647#comment-15582647
]
Jinmei Liao commented on GEODE-1883:
Currently in peer to peer communication, security-auth-init is optional. But in
client-server, it is still required. It's going to be a very involved change on
the client side to make it optional in the current state of java client.
> AuthInitializer should be made optional
> ---
>
> Key: GEODE-1883
> URL: https://issues.apache.org/jira/browse/GEODE-1883
> Project: Geode
> Issue Type: New Feature
> Components: management
>Reporter: Swapnil Bawaskar
>
> {{AuthInitializer}} is the interface that a client must implement that
> provides credentials that are verified by the server. The same interface is
> also used for peer authentication.
> In order to configure {{AuthInitialize}} any Geode property starting with
> {{security-}} is passed through to the {{AuthInitialize.getCredentials}}
> method.
> For simple authentication where only a username and a password are required,
> users should not really be required to implement the AuthInitialize interface
> in the presence of property passthrough.
> Geode should detect {{security-username}} and {{security-password}}
> properties in gemfire.security OR gfsecurity.properties file and use those
> for authentication.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-1883) AuthInitializer should be made optional
[
https://issues.apache.org/jira/browse/GEODE-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-1883:
---
Component/s: (was: security)
> AuthInitializer should be made optional
> ---
>
> Key: GEODE-1883
> URL: https://issues.apache.org/jira/browse/GEODE-1883
> Project: Geode
> Issue Type: Improvement
> Components: management
>Reporter: Swapnil Bawaskar
>
> {{AuthInitializer}} is the interface that a client must implement that
> provides credentials that are verified by the server. The same interface is
> also used for peer authentication.
> In order to configure {{AuthInitialize}} any Geode property starting with
> {{security-}} is passed through to the {{AuthInitialize.getCredentials}}
> method.
> For simple authentication where only a username and a password are required,
> users should not really be required to implement the AuthInitialize interface
> in the presence of property passthrough.
> Geode should detect {{security-username}} and {{security-password}}
> properties in gemfire.security OR gfsecurity.properties file and use those
> for authentication.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-1883) AuthInitializer should be made optional
[
https://issues.apache.org/jira/browse/GEODE-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-1883:
---
Issue Type: New Feature (was: Improvement)
> AuthInitializer should be made optional
> ---
>
> Key: GEODE-1883
> URL: https://issues.apache.org/jira/browse/GEODE-1883
> Project: Geode
> Issue Type: New Feature
> Components: management
>Reporter: Swapnil Bawaskar
>
> {{AuthInitializer}} is the interface that a client must implement that
> provides credentials that are verified by the server. The same interface is
> also used for peer authentication.
> In order to configure {{AuthInitialize}} any Geode property starting with
> {{security-}} is passed through to the {{AuthInitialize.getCredentials}}
> method.
> For simple authentication where only a username and a password are required,
> users should not really be required to implement the AuthInitialize interface
> in the presence of property passthrough.
> Geode should detect {{security-username}} and {{security-password}}
> properties in gemfire.security OR gfsecurity.properties file and use those
> for authentication.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-1883) AuthInitializer should be made optional
[
https://issues.apache.org/jira/browse/GEODE-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-1883:
---
Assignee: (was: Jinmei Liao)
> AuthInitializer should be made optional
> ---
>
> Key: GEODE-1883
> URL: https://issues.apache.org/jira/browse/GEODE-1883
> Project: Geode
> Issue Type: Improvement
> Components: management, security
>Reporter: Swapnil Bawaskar
>
> {{AuthInitializer}} is the interface that a client must implement that
> provides credentials that are verified by the server. The same interface is
> also used for peer authentication.
> In order to configure {{AuthInitialize}} any Geode property starting with
> {{security-}} is passed through to the {{AuthInitialize.getCredentials}}
> method.
> For simple authentication where only a username and a password are required,
> users should not really be required to implement the AuthInitialize interface
> in the presence of property passthrough.
> Geode should detect {{security-username}} and {{security-password}}
> properties in gemfire.security OR gfsecurity.properties file and use those
> for authentication.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-1883) AuthInitializer should be made optional
[
https://issues.apache.org/jira/browse/GEODE-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-1883:
---
Component/s: management
> AuthInitializer should be made optional
> ---
>
> Key: GEODE-1883
> URL: https://issues.apache.org/jira/browse/GEODE-1883
> Project: Geode
> Issue Type: Improvement
> Components: management, security
>Reporter: Swapnil Bawaskar
>Assignee: Jinmei Liao
>
> {{AuthInitializer}} is the interface that a client must implement that
> provides credentials that are verified by the server. The same interface is
> also used for peer authentication.
> In order to configure {{AuthInitialize}} any Geode property starting with
> {{security-}} is passed through to the {{AuthInitialize.getCredentials}}
> method.
> For simple authentication where only a username and a password are required,
> users should not really be required to implement the AuthInitialize interface
> in the presence of property passthrough.
> Geode should detect {{security-username}} and {{security-password}}
> properties in gemfire.security OR gfsecurity.properties file and use those
> for authentication.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (GEODE-1883) AuthInitializer should be made optional
[
https://issues.apache.org/jira/browse/GEODE-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-1883:
--
Assignee: Jinmei Liao
> AuthInitializer should be made optional
> ---
>
> Key: GEODE-1883
> URL: https://issues.apache.org/jira/browse/GEODE-1883
> Project: Geode
> Issue Type: Improvement
> Components: security
>Reporter: Swapnil Bawaskar
>Assignee: Jinmei Liao
>
> {{AuthInitializer}} is the interface that a client must implement that
> provides credentials that are verified by the server. The same interface is
> also used for peer authentication.
> In order to configure {{AuthInitialize}} any Geode property starting with
> {{security-}} is passed through to the {{AuthInitialize.getCredentials}}
> method.
> For simple authentication where only a username and a password are required,
> users should not really be required to implement the AuthInitialize interface
> in the presence of property passthrough.
> Geode should detect {{security-username}} and {{security-password}}
> properties in gemfire.security OR gfsecurity.properties file and use those
> for authentication.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15572773#comment-15572773
]
Jinmei Liao commented on GEODE-1986:
Yes, the fix was pushed to develop yesterday and is available in the nightly
build.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Fix For: 1.0.0-incubating
>
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15572623#comment-15572623
]
Jinmei Liao commented on GEODE-1986:
Ok. got you now. Is there a use case that a peer cache member would need to
join another peer's locator that has enabled cluster config?
We did lump the security config inside the cluster configuration because we
decided it should be a cluster-wide configuration. Maybe your concern lies in
the fact that currently there are limitations of what cluster config service
can do, so users would disable them to get what they need to do. We will look
at how to improve cluster config post 1.0. For now, I want to make sure your
immediate concern is addressed by our current fix.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15572521#comment-15572521
]
Jinmei Liao commented on GEODE-1986:
"This suggests the joining member (server) must enable cluster config in order
to pick up the security configuration"
No, they don't have to "enable" cluster config, they just have to "use" cluster
config, which are two different configurations.
If a locator is secured but does not have cluster config service running, a
server can connect to it as long as it has correct credentials. At that point,
we do no check if their security settings are matched up. It will totally up to
the person starting them up to make sure they use the same security settings to
protect their data.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569869#comment-15569869
]
Jinmei Liao edited comment on GEODE-1986 at 10/13/16 6:23 AM:
--
The scenario you provided in the beginning of the bug is fixed by correcting
setting the "enable-cluster-configuration" flag when starting an embedded
locator. Cluster configuration is not a required service, if the locator does
not have cluster configuration service running, then regardless of its
security, a member can join with its own security manager. But if a locator has
cluster config running and is secured, any member without use-cluster-config
will be rejected. Are there other use cases that would fail with current
implementation? We will add it to our Dunit test suite to uncover it and fix it.
Also, without our current implementation, a server with correct credentials
and use SSL would successfully join a secured locator but itself can be
unprotected. Client can directly connect to that server without any credential
to get the data even though the locator is secured.
was (Author: jinmeiliao):
The scenario you provided in the beginning of the bug is fixed by correcting
setting the "enable-cluster-configuration" flag when starting an embedded
locator. Cluster configuration is not a required service, if the locator does
not have cluster configuration service running, then regardless of its
security, a member can join with its own security manager. But if a locator has
cluster config running and is secured, any member without use-cluster-config
will be rejected. Are there other use cases that would render this requirement
unacceptable? We will add it to our Dunit test suite to accommodate it.
Also, a server with correct credentials and use SSL will successfully join the
locator, but itself can be unprotected. Client can directly connect to that
server.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
>
[jira] [Updated] (GEODE-1993) value returned through /region/key rest service needs to be post processed
[ https://issues.apache.org/jira/browse/GEODE-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-1993: --- Component/s: (was: rest (dev)) management > value returned through /region/key rest service needs to be post processed > -- > > Key: GEODE-1993 > URL: https://issues.apache.org/jira/browse/GEODE-1993 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jinmei Liao > > The new rest security did not use post processor before returning the value > back to the client. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-1993) value returned through /region/key rest service needs to be post processed
Jinmei Liao created GEODE-1993: -- Summary: value returned through /region/key rest service needs to be post processed Key: GEODE-1993 URL: https://issues.apache.org/jira/browse/GEODE-1993 Project: Geode Issue Type: New Feature Reporter: Jinmei Liao The new rest security did not use post processor before returning the value back to the client. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-1993) value returned through /region/key rest service needs to be post processed
[ https://issues.apache.org/jira/browse/GEODE-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-1993: --- Component/s: rest (dev) > value returned through /region/key rest service needs to be post processed > -- > > Key: GEODE-1993 > URL: https://issues.apache.org/jira/browse/GEODE-1993 > Project: Geode > Issue Type: New Feature > Components: rest (dev) >Reporter: Jinmei Liao > > The new rest security did not use post processor before returning the value > back to the client. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566533#comment-15566533
]
Jinmei Liao edited comment on GEODE-1986 at 10/11/16 10:03 PM:
---
This was true before we put security-manager in the cluster configuration.
Before, if a member joins and has use-cluster-configuration set to false, it
won't request any cluster config, just starts up using its own config, joins
the cluster and all good. But in 9.0. PM wants:
1. If a locator is secured, a server who wants to join has to use the same
security manager as the locator.
2. If a locator is secured, a server who wants to join the secured server has
to set use-cluster-configuration to be true in order to join,
With these two new requirements, when a server joins, even it has
use-cluster-configuration set to be false, we still need to check if the
locator it's trying to join is a secured one or not, if it is, we need to
prevent it from starting up by throwing an exception, otherwise, we will let it
start. If we don't do that, a server can join a secured locator but itself is
not secured. This would leads to security leak.
was (Author: jinmeiliao):
This was true before we put security-manager in the cluster configuration.
Before, if a member joins and has use-cluster-configuration set to false, it
won't request any cluster config, just starts up using its own config, joins
the cluster and all good. But in 9.0. PM wants:
1. If a locator is secured, a server who wants to join the secured server has
to set use-cluster-configuration to be true in order to join,
2. If a locator is secured, a server who wants to join has to use the same
security manager as the locator.
With these two new requirements, when a server joins, even it has
use-cluster-configuration set to be false, we still need to check if the
locator it's trying to join is a secured one or not, if it is, we need to
prevent it from starting up by throwing an exception, otherwise, we will let it
start. If we don't do that, a server can join a secured locator but itself is
not secured. This would leads to security leak.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
>
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566533#comment-15566533
]
Jinmei Liao edited comment on GEODE-1986 at 10/11/16 10:04 PM:
---
This was true before we put security-manager in the cluster configuration.
Before, if a member joins and has use-cluster-configuration set to false, it
won't request any cluster config, just starts up using its own config, joins
the cluster and all good. But in 9.0. PM wants:
1. If a locator is secured, a server who wants to join has to use the same
security manager as the locator.
2. If a locator is secured, a server who wants to join has to set
use-cluster-configuration to be true in order to join,
With these two new requirements, when a server joins, even it has
use-cluster-configuration set to be false, we still need to check if the
locator it's trying to join is a secured one or not, if it is, we need to
prevent it from starting up by throwing an exception, otherwise, we will let it
start. If we don't do that, a server can join a secured locator but itself is
not secured. This would leads to security leak.
was (Author: jinmeiliao):
This was true before we put security-manager in the cluster configuration.
Before, if a member joins and has use-cluster-configuration set to false, it
won't request any cluster config, just starts up using its own config, joins
the cluster and all good. But in 9.0. PM wants:
1. If a locator is secured, a server who wants to join has to use the same
security manager as the locator.
2. If a locator is secured, a server who wants to join the secured server has
to set use-cluster-configuration to be true in order to join,
With these two new requirements, when a server joins, even it has
use-cluster-configuration set to be false, we still need to check if the
locator it's trying to join is a secured one or not, if it is, we need to
prevent it from starting up by throwing an exception, otherwise, we will let it
start. If we don't do that, a server can join a secured locator but itself is
not secured. This would leads to security leak.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
>
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566533#comment-15566533
]
Jinmei Liao edited comment on GEODE-1986 at 10/11/16 10:02 PM:
---
This was true before we put security-manager in the cluster configuration.
Before, if a member joins and has use-cluster-configuration set to false, it
won't request any cluster config, just starts up using its own config, joins
the cluster and all good. But in 9.0. PM wants:
1. If a locator is secured, a server who wants to join the secured server has
to set use-cluster-configuration to be true in order to join,
2. If a locator is secured, a server who wants to join has to use the same
security manager as the locator.
With these two new requirements, when a server joins, even it has
use-cluster-configuration set to be false, we still need to check if the
locator it's trying to join is a secured one or not, if it is, we need to
prevent it from starting up by throwing an exception, otherwise, we will let it
start. If we don't do that, a server can join a secured locator but itself is
not secured. This would leads to security leak.
was (Author: jinmeiliao):
This was true before we put security-manager in the cluster configuration.
Before, if a member joins and has use-cluster-configuration set to false, it
won't request any cluster config, just starts up using its own config, joins
the cluster and all good. But in 9.0. PM wants:
1. If security-manager is set on a locator, cluster service needs to be running.
2. If a locator is secured, a server who wants to join the secured server has
to set use-cluster-configuration to be true in order to join, this prevents the
server to be configured with a different security manager than the locator.
With these two new requirements, when a server joins, even it has
use-cluster-configuration set to be false, we still need to check if the
locator it's trying to join is a secured one or not, if it is, we need to
prevent it from starting up by throwing an exception, otherwise, we will let it
start. If we don't do that, a server can join a secured locator but itself is
not secured. This would leads to security leak.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
>
[jira] [Commented] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566533#comment-15566533
]
Jinmei Liao commented on GEODE-1986:
This was true before we put security-manager in the cluster configuration.
Before, if a member joins and has use-cluster-configuration set to false, it
won't request any cluster config, just starts up using its own config, joins
the cluster and all good. But in 9.0. PM wants:
1. If security-manager is set on a locator, cluster service needs to be running.
2. If a locator is secured, a server who wants to join the secured server has
to set use-cluster-configuration to be true in order to join, this prevents the
server to be configured with a different security manager than the locator.
With these two new requirements, when a server joins, even it has
use-cluster-configuration set to be false, we still need to check if the
locator it's trying to join is a secured one or not, if it is, we need to
prevent it from starting up by throwing an exception, otherwise, we will let it
start. If we don't do that, a server can join a secured locator but itself is
not secured. This would leads to security leak.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566351#comment-15566351
]
Jinmei Liao commented on GEODE-1986:
the use-cluser-configuration flag is checked, The problem here is that the
enable-cluster-configuration is wrongfully set.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-1986.
Resolution: Workaround
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GEODE-1990) String a locator in the embedded mode should set the enable-cluster-configuration correctly
Jinmei Liao created GEODE-1990:
--
Summary: String a locator in the embedded mode should set the
enable-cluster-configuration correctly
Key: GEODE-1990
URL: https://issues.apache.org/jira/browse/GEODE-1990
Project: Geode
Issue Type: Bug
Reporter: Jinmei Liao
A locator started using the following does not start the cluster configuration,
but the enabled-cluster-configuration flag is true, this will result in other
server who joins to request the cluster config and then fail with an exception.
locator.invoke(()->{
new CacheFactory()
.set("name", this.getName()+".server1")
.set("mcast-port", "0")
.set("log-level", "config")
.set("start-locator", "localhost["+locatorPort+"]")
.create();
});
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566138#comment-15566138
]
Jinmei Liao commented on GEODE-1986:
So looks like the real problem is that when starting a locator in the embedded
mode, even though the enable-cluster-configuration is by default, true, it's
not really starting up the cluster config service, but when a server joins,
it's sending the message telling the server that it has cluster service
enabled. The above test will pass, if the locator is started setting an extra
flag:
new CacheFactory()
.set("name", this.getName()+".server1")
.set("mcast-port", "0")
.set("log-level", "config")
.set("start-locator", "localhost["+locatorPort+"]")
.set("enable-cluster-configuration", "false")
.create();
I'll create another bug and reference this to that one.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
