[jira] [Assigned] (GEODE-1915) Registering instantiators can cause a deadlock with gateways
[
https://issues.apache.org/jira/browse/GEODE-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reassigned GEODE-1915:
Assignee: Dan Smith
> Registering instantiators can cause a deadlock with gateways
>
>
> Key: GEODE-1915
> URL: https://issues.apache.org/jira/browse/GEODE-1915
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Dan Smith
>Assignee: Dan Smith
>
> If two WAN sites are connected bidirectionally, registering an instantiator
> in one of the sites can cause a deadlock.
> The issue is that when an instantiator is registered, a message is sent
> synchronously from one site to the other, while holding a static lock on the
> InternalInstantiator class. Unfortunately, when the second site receives the
> registration, it tries to send it back to the first site. In the first site,
> the registeration message then is stuck trying to get the same lock.
> {code}
> "ServerConnection on port 28517 Thread 4" #80 daemon prio=5 os_prio=0
> tid=0x7fce78007000 nid=0xc48a runnable [0x7fce377f7000]
>java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:170)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at
> org.apache.geode.internal.cache.tier.sockets.Message.fetchHeader(Message.java:693)
> at
> org.apache.geode.internal.cache.tier.sockets.Message.readHeaderAndPayload(Message.java:710)
> at
> org.apache.geode.internal.cache.tier.sockets.Message.read(Message.java:661)
> at
> org.apache.geode.internal.cache.tier.sockets.Message.recv(Message.java:1103)
> - locked <0xfb3aec38> (a java.nio.HeapByteBuffer)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:171)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:388)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:272)
> - locked <0xfb3ad430> (a
> org.apache.geode.cache.client.internal.ConnectionImpl)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:328)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:937)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:155)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:711)
> at
> org.apache.geode.cache.client.internal.RegisterInstantiatorsOp.execute(RegisterInstantiatorsOp.java:49)
> at
> org.apache.geode.internal.cache.PoolManagerImpl.allPoolsRegisterInstantiator(PoolManagerImpl.java:227)
> at
> org.apache.geode.internal.InternalInstantiator.sendRegistrationMessageToServers(InternalInstantiator.java:219)
> at
> org.apache.geode.internal.InternalInstantiator._register(InternalInstantiator.java:174)
> - locked <0xfb3ad678> (a java.lang.Class for
> org.apache.geode.internal.InternalInstantiator)
> at
> org.apache.geode.internal.InternalInstantiator.register(InternalInstantiator.java:310)
> at
> org.apache.geode.internal.cache.tier.sockets.command.RegisterInstantiators.cmdExecute(RegisterInstantiators.java:100)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:145)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:783)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:913)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1180)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:546)
> at java.lang.Thread.run(Thread.java:745)
> "ServerConnection on port 28517 Thread 3" #78 daemon prio=5 os_prio=0
> tid=0x7fce78005000 nid=0xc487 waiting for monitor entry
> [0x7fce379fa000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.geode.internal.InternalInstantiator._register(InternalInstantiator.java:117)
> - waiting to lock <0xfb3ad678> (a java.lang.Class for
> org.apache.geode.internal.InternalInstantiator)
> at
> org.apache.geode.internal.InternalInstantiator.register(InternalInstantiator.java:310)
>
[jira] [Created] (GEODE-1915) Registering instantiators can cause a deadlock with gateways
Dan Smith created GEODE-1915:
Summary: Registering instantiators can cause a deadlock with
gateways
Key: GEODE-1915
URL: https://issues.apache.org/jira/browse/GEODE-1915
Project: Geode
Issue Type: Bug
Components: wan
Reporter: Dan Smith
If two WAN sites are connected bidirectionally, registering an instantiator in
one of the sites can cause a deadlock.
The issue is that when an instantiator is registered, a message is sent
synchronously from one site to the other, while holding a static lock on the
InternalInstantiator class. Unfortunately, when the second site receives the
registration, it tries to send it back to the first site. In the first site,
the registeration message then is stuck trying to get the same lock.
{code}
"ServerConnection on port 28517 Thread 4" #80 daemon prio=5 os_prio=0
tid=0x7fce78007000 nid=0xc48a runnable [0x7fce377f7000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at
org.apache.geode.internal.cache.tier.sockets.Message.fetchHeader(Message.java:693)
at
org.apache.geode.internal.cache.tier.sockets.Message.readHeaderAndPayload(Message.java:710)
at
org.apache.geode.internal.cache.tier.sockets.Message.read(Message.java:661)
at
org.apache.geode.internal.cache.tier.sockets.Message.recv(Message.java:1103)
- locked <0xfb3aec38> (a java.nio.HeapByteBuffer)
at
org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:171)
at
org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:388)
at
org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:272)
- locked <0xfb3ad430> (a
org.apache.geode.cache.client.internal.ConnectionImpl)
at
org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:328)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:937)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:155)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:711)
at
org.apache.geode.cache.client.internal.RegisterInstantiatorsOp.execute(RegisterInstantiatorsOp.java:49)
at
org.apache.geode.internal.cache.PoolManagerImpl.allPoolsRegisterInstantiator(PoolManagerImpl.java:227)
at
org.apache.geode.internal.InternalInstantiator.sendRegistrationMessageToServers(InternalInstantiator.java:219)
at
org.apache.geode.internal.InternalInstantiator._register(InternalInstantiator.java:174)
- locked <0xfb3ad678> (a java.lang.Class for
org.apache.geode.internal.InternalInstantiator)
at
org.apache.geode.internal.InternalInstantiator.register(InternalInstantiator.java:310)
at
org.apache.geode.internal.cache.tier.sockets.command.RegisterInstantiators.cmdExecute(RegisterInstantiators.java:100)
at
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:145)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:783)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:913)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1180)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:546)
at java.lang.Thread.run(Thread.java:745)
"ServerConnection on port 28517 Thread 3" #78 daemon prio=5 os_prio=0
tid=0x7fce78005000 nid=0xc487 waiting for monitor entry [0x7fce379fa000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.geode.internal.InternalInstantiator._register(InternalInstantiator.java:117)
- waiting to lock <0xfb3ad678> (a java.lang.Class for
org.apache.geode.internal.InternalInstantiator)
at
org.apache.geode.internal.InternalInstantiator.register(InternalInstantiator.java:310)
at
org.apache.geode.internal.cache.tier.sockets.command.RegisterInstantiators.cmdExecute(RegisterInstantiators.java:100)
at
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:145)
at
[jira] [Commented] (GEODE-37) Package renaming - com.gemstone.gemfire -> org.apache.geode
[ https://issues.apache.org/jira/browse/GEODE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508100#comment-15508100 ] ASF subversion and git services commented on GEODE-37: -- Commit 16a19e9d34c4b6de6bfed1164efc942e3a66318d in incubator-geode's branch refs/heads/develop from [~hitesh.khamesra] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=16a19e9 ] GEODE-37 changed md file to point org.apache > Package renaming - com.gemstone.gemfire -> org.apache.geode > --- > > Key: GEODE-37 > URL: https://issues.apache.org/jira/browse/GEODE-37 > Project: Geode > Issue Type: Task > Components: client/server, docs, general >Affects Versions: 1.0.0-incubating >Reporter: William Markito Oliveira >Assignee: Hitesh Khamesra >Priority: Blocker > Fix For: 1.0.0-incubating > > > Geode packages should be renamed from com.gemstone -> org.apache.geode in > order to allow an easy transition from incubation to become a TLP. > Also, it allow the necessary work that may need to be done at the protocol > level in order to allow serialization/message exchange between nodes before > an actual release using the definitive class/package naming. > The issue was discussed in the following thread at dev@: > http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201505.mbox/ajax/%3C554B38C3.5050500%40pidster.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-1914) Need to look all dtd for com.gemstone reference
Hitesh Khamesra created GEODE-1914: -- Summary: Need to look all dtd for com.gemstone reference Key: GEODE-1914 URL: https://issues.apache.org/jira/browse/GEODE-1914 Project: Geode Issue Type: Bug Components: general Reporter: Hitesh Khamesra Fix For: 1.0.0-incubating -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-37) Package renaming - com.gemstone.gemfire -> org.apache.geode
[ https://issues.apache.org/jira/browse/GEODE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508072#comment-15508072 ] ASF subversion and git services commented on GEODE-37: -- Commit 03e60a672577ffde93cfe3633ccd1d1ab7f3387e in incubator-geode's branch refs/heads/develop from [~hitesh.khamesra] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=03e60a6 ] GEODE-37 change package name from io.pivotal.geode (for ./geode-spark-connector/src/it/scala/ittest/io/pivotal)to org.apache.geode for(to ./geode-spark-connector/src/it/scala/ittest/org/apache) > Package renaming - com.gemstone.gemfire -> org.apache.geode > --- > > Key: GEODE-37 > URL: https://issues.apache.org/jira/browse/GEODE-37 > Project: Geode > Issue Type: Task > Components: client/server, docs, general >Affects Versions: 1.0.0-incubating >Reporter: William Markito Oliveira >Assignee: Hitesh Khamesra >Priority: Blocker > Fix For: 1.0.0-incubating > > > Geode packages should be renamed from com.gemstone -> org.apache.geode in > order to allow an easy transition from incubation to become a TLP. > Also, it allow the necessary work that may need to be done at the protocol > level in order to allow serialization/message exchange between nodes before > an actual release using the definitive class/package naming. > The issue was discussed in the following thread at dev@: > http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201505.mbox/ajax/%3C554B38C3.5050500%40pidster.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-37) Package renaming - com.gemstone.gemfire -> org.apache.geode
[ https://issues.apache.org/jira/browse/GEODE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508070#comment-15508070 ] ASF subversion and git services commented on GEODE-37: -- Commit 54cf6bf5d826814a4cd82b100a9f638896e48945 in incubator-geode's branch refs/heads/develop from [~hitesh.khamesra] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=54cf6bf ] GEODE-37 change package name from io.pivotal.geode (for ./geode-functions/src/main/java/io/pivotal)to org.apache.geode for(to ./geode-functions/src/main/java/org/apache) > Package renaming - com.gemstone.gemfire -> org.apache.geode > --- > > Key: GEODE-37 > URL: https://issues.apache.org/jira/browse/GEODE-37 > Project: Geode > Issue Type: Task > Components: client/server, docs, general >Affects Versions: 1.0.0-incubating >Reporter: William Markito Oliveira >Assignee: Hitesh Khamesra >Priority: Blocker > Fix For: 1.0.0-incubating > > > Geode packages should be renamed from com.gemstone -> org.apache.geode in > order to allow an easy transition from incubation to become a TLP. > Also, it allow the necessary work that may need to be done at the protocol > level in order to allow serialization/message exchange between nodes before > an actual release using the definitive class/package naming. > The issue was discussed in the following thread at dev@: > http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201505.mbox/ajax/%3C554B38C3.5050500%40pidster.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-37) Package renaming - com.gemstone.gemfire -> org.apache.geode
[ https://issues.apache.org/jira/browse/GEODE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508079#comment-15508079 ] ASF subversion and git services commented on GEODE-37: -- Commit 97658f046e0c2f7a9f0a7eb366c07a91acb7650f in incubator-geode's branch refs/heads/develop from [~hitesh.khamesra] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=97658f0 ] GEODE-37 change package name from io.pivotal.geode (for ./geode-spark-connector/src/test/scala/io/pivotal)to org.apache.geode for(to ./geode-spark-connector/src/test/scala/org/apache) > Package renaming - com.gemstone.gemfire -> org.apache.geode > --- > > Key: GEODE-37 > URL: https://issues.apache.org/jira/browse/GEODE-37 > Project: Geode > Issue Type: Task > Components: client/server, docs, general >Affects Versions: 1.0.0-incubating >Reporter: William Markito Oliveira >Assignee: Hitesh Khamesra >Priority: Blocker > Fix For: 1.0.0-incubating > > > Geode packages should be renamed from com.gemstone -> org.apache.geode in > order to allow an easy transition from incubation to become a TLP. > Also, it allow the necessary work that may need to be done at the protocol > level in order to allow serialization/message exchange between nodes before > an actual release using the definitive class/package naming. > The issue was discussed in the following thread at dev@: > http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201505.mbox/ajax/%3C554B38C3.5050500%40pidster.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-37) Package renaming - com.gemstone.gemfire -> org.apache.geode
[ https://issues.apache.org/jira/browse/GEODE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508078#comment-15508078 ] ASF subversion and git services commented on GEODE-37: -- Commit f530d3af7e412f8097d408a1001e37e57a70b4c0 in incubator-geode's branch refs/heads/develop from [~hitesh.khamesra] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=f530d3a ] GEODE-37 change package name from io.pivotal.geode (for ./geode-spark-connector/src/test/java/io/pivotal)to org.apache.geode for(to ./geode-spark-connector/src/test/java/org/apache) > Package renaming - com.gemstone.gemfire -> org.apache.geode > --- > > Key: GEODE-37 > URL: https://issues.apache.org/jira/browse/GEODE-37 > Project: Geode > Issue Type: Task > Components: client/server, docs, general >Affects Versions: 1.0.0-incubating >Reporter: William Markito Oliveira >Assignee: Hitesh Khamesra >Priority: Blocker > Fix For: 1.0.0-incubating > > > Geode packages should be renamed from com.gemstone -> org.apache.geode in > order to allow an easy transition from incubation to become a TLP. > Also, it allow the necessary work that may need to be done at the protocol > level in order to allow serialization/message exchange between nodes before > an actual release using the definitive class/package naming. > The issue was discussed in the following thread at dev@: > http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201505.mbox/ajax/%3C554B38C3.5050500%40pidster.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-37) Package renaming - com.gemstone.gemfire -> org.apache.geode
[ https://issues.apache.org/jira/browse/GEODE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508071#comment-15508071 ] ASF subversion and git services commented on GEODE-37: -- Commit 2d374c9de5a48d7e08eb29594470aa62c3be3f87 in incubator-geode's branch refs/heads/develop from [~hitesh.khamesra] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=2d374c9 ] GEODE-37 change package name from io.pivotal.geode (for ./geode-spark-connector/src/it/java/ittest/io/pivotal)to org.apache.geode for(to ./geode-spark-connector/src/it/java/ittest/org/apache) > Package renaming - com.gemstone.gemfire -> org.apache.geode > --- > > Key: GEODE-37 > URL: https://issues.apache.org/jira/browse/GEODE-37 > Project: Geode > Issue Type: Task > Components: client/server, docs, general >Affects Versions: 1.0.0-incubating >Reporter: William Markito Oliveira >Assignee: Hitesh Khamesra >Priority: Blocker > Fix For: 1.0.0-incubating > > > Geode packages should be renamed from com.gemstone -> org.apache.geode in > order to allow an easy transition from incubation to become a TLP. > Also, it allow the necessary work that may need to be done at the protocol > level in order to allow serialization/message exchange between nodes before > an actual release using the definitive class/package naming. > The issue was discussed in the following thread at dev@: > http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201505.mbox/ajax/%3C554B38C3.5050500%40pidster.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-37) Package renaming - com.gemstone.gemfire -> org.apache.geode
[ https://issues.apache.org/jira/browse/GEODE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508080#comment-15508080 ] ASF subversion and git services commented on GEODE-37: -- Commit c32fccba55db48bbdca7567bb62470895fcb5b05 in incubator-geode's branch refs/heads/develop from [~hitesh.khamesra] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=c32fccb ] GEODE-37 changed package name in spark-connector > Package renaming - com.gemstone.gemfire -> org.apache.geode > --- > > Key: GEODE-37 > URL: https://issues.apache.org/jira/browse/GEODE-37 > Project: Geode > Issue Type: Task > Components: client/server, docs, general >Affects Versions: 1.0.0-incubating >Reporter: William Markito Oliveira >Assignee: Hitesh Khamesra >Priority: Blocker > Fix For: 1.0.0-incubating > > > Geode packages should be renamed from com.gemstone -> org.apache.geode in > order to allow an easy transition from incubation to become a TLP. > Also, it allow the necessary work that may need to be done at the protocol > level in order to allow serialization/message exchange between nodes before > an actual release using the definitive class/package naming. > The issue was discussed in the following thread at dev@: > http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201505.mbox/ajax/%3C554B38C3.5050500%40pidster.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-37) Package renaming - com.gemstone.gemfire -> org.apache.geode
[ https://issues.apache.org/jira/browse/GEODE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508073#comment-15508073 ] ASF subversion and git services commented on GEODE-37: -- Commit f7eaa26c0009a8a4ec4f0c692de2c07c1ca4eb78 in incubator-geode's branch refs/heads/develop from [~hitesh.khamesra] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=f7eaa26 ] GEODE-37 change package name from io.pivotal.geode (for ./geode-spark-connector/src/main/java/io/pivotal)to org.apache.geode for(to ./geode-spark-connector/src/main/java/org/apache) > Package renaming - com.gemstone.gemfire -> org.apache.geode > --- > > Key: GEODE-37 > URL: https://issues.apache.org/jira/browse/GEODE-37 > Project: Geode > Issue Type: Task > Components: client/server, docs, general >Affects Versions: 1.0.0-incubating >Reporter: William Markito Oliveira >Assignee: Hitesh Khamesra >Priority: Blocker > Fix For: 1.0.0-incubating > > > Geode packages should be renamed from com.gemstone -> org.apache.geode in > order to allow an easy transition from incubation to become a TLP. > Also, it allow the necessary work that may need to be done at the protocol > level in order to allow serialization/message exchange between nodes before > an actual release using the definitive class/package naming. > The issue was discussed in the following thread at dev@: > http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201505.mbox/ajax/%3C554B38C3.5050500%40pidster.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-37) Package renaming - com.gemstone.gemfire -> org.apache.geode
[ https://issues.apache.org/jira/browse/GEODE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508077#comment-15508077 ] ASF subversion and git services commented on GEODE-37: -- Commit 106cc60fc92ed8e594db44ceeed8d53df43188aa in incubator-geode's branch refs/heads/develop from [~hitesh.khamesra] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=106cc60 ] GEODE-37 change package name from io.pivotal.geode (for ./geode-spark-connector/src/main/scala/io/pivotal)to org.apache.geode for(to ./geode-spark-connector/src/main/scala/org/apache) > Package renaming - com.gemstone.gemfire -> org.apache.geode > --- > > Key: GEODE-37 > URL: https://issues.apache.org/jira/browse/GEODE-37 > Project: Geode > Issue Type: Task > Components: client/server, docs, general >Affects Versions: 1.0.0-incubating >Reporter: William Markito Oliveira >Assignee: Hitesh Khamesra >Priority: Blocker > Fix For: 1.0.0-incubating > > > Geode packages should be renamed from com.gemstone -> org.apache.geode in > order to allow an easy transition from incubation to become a TLP. > Also, it allow the necessary work that may need to be done at the protocol > level in order to allow serialization/message exchange between nodes before > an actual release using the definitive class/package naming. > The issue was discussed in the following thread at dev@: > http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201505.mbox/ajax/%3C554B38C3.5050500%40pidster.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1900) Missing update (subsctiption) event with partitioned region during bucket rebalance.
[
https://issues.apache.org/jira/browse/GEODE-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508068#comment-15508068
]
Darrel Schneider commented on GEODE-1900:
-
When I add these tests, I do see them fail but I think that is because the test
is doing a localDestroyRegion on a bucket in the middle of the transaction
commit. The product never does this. What it does is either ask the
PartitionedRegionDataStore to remove a bucket and that operation always does a
state flush which would cause the bucket move to not happen until the
transaction commit completes.
What happens when these new tests fail is that they get into the
AbstractRegionMap txApplyPut code and since an update is being done they do a
test "getEntry" to see if the entry exists. Since the test called
localRegionDestroy on the bucket no entries exist. So the txApplyPut returns
early and does not add the event to the pendingCallbacks list and that is what
causes the event to not be sent to clients registered with this server.
So I'm going to close this bug since it is not a valid test.
> Missing update (subsctiption) event with partitioned region during bucket
> rebalance.
>
>
> Key: GEODE-1900
> URL: https://issues.apache.org/jira/browse/GEODE-1900
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Anilkumar Gingade
>
> Similar to GEODE-1885...In this case the issue is with update and with both
> offheap and non-offheap regions.
> During transaction operation, if there is concurrent redundant bucket
> re-balance is in progress, the client can miss update event, if its primary
> queue is hosted on the node where bucket gets moved from.
> Consider, three node cluster N1, N2 and N3. With:
> Client C1 connected to node N2.
> Primary bucket region B1 on N1. And secondary bucket for B1 on N2.
> A Transaction is started on N2, which updates an entry on B1.
> When the TX is committed. At the same time the Bucket B1 on N2 is moved
> to N3.
> The Tx commit message from N1 is sent to N2. This also includes the
> subscription message, satisfying the client C1.
> On N2, for offheap region, when bucket is not found locally, the
> exception response is sent to back to N1 without processing the subscription
> message.
> How to reproduce:
> Add following tests/lines in ClientServerTransactionDUnitTest:
> public void
> testUpdateSubscriptionEventsWithOffheapPrWhileBucketRegionIsDestroyed() {
> testSubscriptionEventsWithOffheapPrWhenBucketRegionIsDestroyed(forop.UPDATE);
> }
> public void
> testUpdateSubscriptionEventsWithPrWhileBucketRegionIsDestroyed() {
> testSubscriptionEventsWhenBucketRegionIsDestroyed(false, forop.UPDATE);
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GEODE-1900) Missing update (subsctiption) event with partitioned region during bucket rebalance.
[
https://issues.apache.org/jira/browse/GEODE-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-1900.
-
Resolution: Invalid
> Missing update (subsctiption) event with partitioned region during bucket
> rebalance.
>
>
> Key: GEODE-1900
> URL: https://issues.apache.org/jira/browse/GEODE-1900
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Anilkumar Gingade
>
> Similar to GEODE-1885...In this case the issue is with update and with both
> offheap and non-offheap regions.
> During transaction operation, if there is concurrent redundant bucket
> re-balance is in progress, the client can miss update event, if its primary
> queue is hosted on the node where bucket gets moved from.
> Consider, three node cluster N1, N2 and N3. With:
> Client C1 connected to node N2.
> Primary bucket region B1 on N1. And secondary bucket for B1 on N2.
> A Transaction is started on N2, which updates an entry on B1.
> When the TX is committed. At the same time the Bucket B1 on N2 is moved
> to N3.
> The Tx commit message from N1 is sent to N2. This also includes the
> subscription message, satisfying the client C1.
> On N2, for offheap region, when bucket is not found locally, the
> exception response is sent to back to N1 without processing the subscription
> message.
> How to reproduce:
> Add following tests/lines in ClientServerTransactionDUnitTest:
> public void
> testUpdateSubscriptionEventsWithOffheapPrWhileBucketRegionIsDestroyed() {
> testSubscriptionEventsWithOffheapPrWhenBucketRegionIsDestroyed(forop.UPDATE);
> }
> public void
> testUpdateSubscriptionEventsWithPrWhileBucketRegionIsDestroyed() {
> testSubscriptionEventsWhenBucketRegionIsDestroyed(false, forop.UPDATE);
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-420) locator ssl configuration
[ https://issues.apache.org/jira/browse/GEODE-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508056#comment-15508056 ] ASF subversion and git services commented on GEODE-420: --- Commit f9a022aaf725b321a9665be0f54ce8f67299 in incubator-geode's branch refs/heads/develop from [~ukohlmeyer] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=f9a022a ] GEODE-420: removed JUnit4DistributedTestCase from Test to make it JUnit test > locator ssl configuration > - > > Key: GEODE-420 > URL: https://issues.apache.org/jira/browse/GEODE-420 > Project: Geode > Issue Type: New Feature > Components: docs, locator >Reporter: Darrel Schneider >Assignee: Udo Kohlmeyer > Fix For: 1.0.0-incubating > > > We currently allow separate SSL configuration for cluster, server, gateway, > jmx-manager, and http-service. > The "server" attributes configure the ssl connections from clients to a cache > server. > The "gateway" attributes configure the ssl connections between a gateway > sender and receiver. > The "jmx-manager" attributes configure the ssl connections between an admin > client (for example gfsh) and the jmx-manager. > The "http-service" attributes configure the ssl connections between REST > clients and the http-service. > The "cluster" attributes configure the ssl connections between the members of > a distributed system (peer-to-peer connections) AND to the locators. > Using "cluster" for the connections to a locator can be a problem. > Say you trust all your members of a distributed system since they are running > on your private network. So no need for ssl on the p2p connections. > So you disable cluster-ssl. These means that your peers are locators are all > using unsecure connections. > But some of these members are hosting a cache server and have clients > connecting to them. So you configure "server" ssl for the client to server > connections. But for your clients to find you servers they need to talk to > the locator. Since the clients are coming from the outside world you want > them to use SSL. So you configure "server" ssl on them for when they connect > to the cache server and "cluster" SSL on them for when they connect to the > locator. But your locators are configured with "cluster" SSL disabled so that > the p2p connects on the internal network will not be SSL. > So you are either forced to have you client to locator connections to be > unsecure or you need to secure all the cluster connections forcing the peers > to also use SSL. > I think we should introduce "locator" SSL configuration options that would > allow you to have just the locator and server using SSL and the "cluster" to > have SSL disabled. > Something else to consider would be for the locator to be able to use SSL for > clients but non-SSL for locator-to-locator and peers-to-locator connections. > I think this would be more complicated because we would need to have > different ports that the locator listens on (one for clients and one for > locators and members). > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-37) Package renaming - com.gemstone.gemfire -> org.apache.geode
[ https://issues.apache.org/jira/browse/GEODE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508008#comment-15508008 ] ASF subversion and git services commented on GEODE-37: -- Commit e9bf1176b4fb840c28b9dab91dac36c5f8d0d559 in incubator-geode's branch refs/heads/develop from [~hitesh.khamesra] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=e9bf117 ] GEODE-37 import change in pulse module > Package renaming - com.gemstone.gemfire -> org.apache.geode > --- > > Key: GEODE-37 > URL: https://issues.apache.org/jira/browse/GEODE-37 > Project: Geode > Issue Type: Task > Components: client/server, docs, general >Affects Versions: 1.0.0-incubating >Reporter: William Markito Oliveira >Assignee: Hitesh Khamesra >Priority: Blocker > Fix For: 1.0.0-incubating > > > Geode packages should be renamed from com.gemstone -> org.apache.geode in > order to allow an easy transition from incubation to become a TLP. > Also, it allow the necessary work that may need to be done at the protocol > level in order to allow serialization/message exchange between nodes before > an actual release using the definitive class/package naming. > The issue was discussed in the following thread at dev@: > http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201505.mbox/ajax/%3C554B38C3.5050500%40pidster.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-37) Package renaming - com.gemstone.gemfire -> org.apache.geode
[ https://issues.apache.org/jira/browse/GEODE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508005#comment-15508005 ] ASF subversion and git services commented on GEODE-37: -- Commit 5ba853daac384a5d8a0b6490cedbd556682e7034 in incubator-geode's branch refs/heads/develop from [~hitesh.khamesra] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=5ba853d ] GEODE-37 changed sequence.gemfire to org.apache.geode > Package renaming - com.gemstone.gemfire -> org.apache.geode > --- > > Key: GEODE-37 > URL: https://issues.apache.org/jira/browse/GEODE-37 > Project: Geode > Issue Type: Task > Components: client/server, docs, general >Affects Versions: 1.0.0-incubating >Reporter: William Markito Oliveira >Assignee: Hitesh Khamesra >Priority: Blocker > Fix For: 1.0.0-incubating > > > Geode packages should be renamed from com.gemstone -> org.apache.geode in > order to allow an easy transition from incubation to become a TLP. > Also, it allow the necessary work that may need to be done at the protocol > level in order to allow serialization/message exchange between nodes before > an actual release using the definitive class/package naming. > The issue was discussed in the following thread at dev@: > http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201505.mbox/ajax/%3C554B38C3.5050500%40pidster.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-37) Package renaming - com.gemstone.gemfire -> org.apache.geode
[ https://issues.apache.org/jira/browse/GEODE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508006#comment-15508006 ] ASF subversion and git services commented on GEODE-37: -- Commit 9a2b5d7b2d00c8ebe7a849487aea3df01063000f in incubator-geode's branch refs/heads/develop from [~hitesh.khamesra] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=9a2b5d7 ] GEODE-37 renamed pulse package to geode > Package renaming - com.gemstone.gemfire -> org.apache.geode > --- > > Key: GEODE-37 > URL: https://issues.apache.org/jira/browse/GEODE-37 > Project: Geode > Issue Type: Task > Components: client/server, docs, general >Affects Versions: 1.0.0-incubating >Reporter: William Markito Oliveira >Assignee: Hitesh Khamesra >Priority: Blocker > Fix For: 1.0.0-incubating > > > Geode packages should be renamed from com.gemstone -> org.apache.geode in > order to allow an easy transition from incubation to become a TLP. > Also, it allow the necessary work that may need to be done at the protocol > level in order to allow serialization/message exchange between nodes before > an actual release using the definitive class/package naming. > The issue was discussed in the following thread at dev@: > http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201505.mbox/ajax/%3C554B38C3.5050500%40pidster.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-37) Package renaming - com.gemstone.gemfire -> org.apache.geode
[ https://issues.apache.org/jira/browse/GEODE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508007#comment-15508007 ] ASF subversion and git services commented on GEODE-37: -- Commit 46307d00886391fc56572aebaa4dc452f2f168cd in incubator-geode's branch refs/heads/develop from [~hitesh.khamesra] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=46307d0 ] GEODE-37 changed package name in comment > Package renaming - com.gemstone.gemfire -> org.apache.geode > --- > > Key: GEODE-37 > URL: https://issues.apache.org/jira/browse/GEODE-37 > Project: Geode > Issue Type: Task > Components: client/server, docs, general >Affects Versions: 1.0.0-incubating >Reporter: William Markito Oliveira >Assignee: Hitesh Khamesra >Priority: Blocker > Fix For: 1.0.0-incubating > > > Geode packages should be renamed from com.gemstone -> org.apache.geode in > order to allow an easy transition from incubation to become a TLP. > Also, it allow the necessary work that may need to be done at the protocol > level in order to allow serialization/message exchange between nodes before > an actual release using the definitive class/package naming. > The issue was discussed in the following thread at dev@: > http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201505.mbox/ajax/%3C554B38C3.5050500%40pidster.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-1913) Calling the CQ API without the geode-cq module loaded should give a more descriptive exception
Jared Stewart created GEODE-1913:
Summary: Calling the CQ API without the geode-cq module loaded
should give a more descriptive exception
Key: GEODE-1913
URL: https://issues.apache.org/jira/browse/GEODE-1913
Project: Geode
Issue Type: Improvement
Components: querying
Reporter: Jared Stewart
The interfaces for continuous query functionality (CqEvent, CqListener, etc)
reside in the geode-core module but their implementations reside in the
geode-cq module. This results in a non-descriptive exception if CQs are
invoked from an application which has loaded geode-core but not geode-cq.
For example,
{code}
ClientCache cache = new ClientCacheFactory()
.addPoolLocator("localhost", 10334)
.setPoolSubscriptionEnabled(true)
.create();
Region region = cache
.createClientRegionFactory(ClientRegionShortcut.CACHING_PROXY)
.create("regionA");
CqAttributesFactory cqf = new CqAttributesFactory();
cqf.addCqListener(new ExampleContinuousQueryListener());
CqAttributes cqa = cqf.create();
QueryService queryService = region.getRegionService().getQueryService();
CqQuery priceTracker = queryService.newCq(cqName, queryStr, cqa);
{code}
gives the following exception:
{code}
Exception in thread "main" java.lang.IllegalStateException: CqService is not
available.
at
com.gemstone.gemfire.cache.query.internal.cq.MissingCqService.start(MissingCqService.java:171)
at
com.gemstone.gemfire.cache.query.internal.DefaultQueryService.getCqService(DefaultQueryService.java:777)
at
com.gemstone.gemfire.cache.query.internal.DefaultQueryService.newCq(DefaultQueryService.java:562)
at com.jaredjstewart.HelloWorld.main(HelloWorld.java:40)
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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
{code}
It would be helpful to check whether the geode-cq module is available on the
classpath before throwing this exception so that we could give the user a more
explanatory message in the stack trace like "Continuous query functionality
relies on the geode-cq module being loaded".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-1912) gfsh does not validate start server command
[
https://issues.apache.org/jira/browse/GEODE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar updated GEODE-1912:
Priority: Minor (was: Major)
> 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] [Created] (GEODE-1912) gfsh does not validate start server command
Swapnil Bawaskar created GEODE-1912:
---
Summary: 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
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] [Commented] (GEODE-1900) Missing update (subsctiption) event with partitioned region during bucket rebalance.
[
https://issues.apache.org/jira/browse/GEODE-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507406#comment-15507406
]
Darrel Schneider commented on GEODE-1900:
-
The actual test lines that need to be added are:
{noformat}
@Test
public void
testUpdateSubscriptionEventsWithOffheapPrWhileBucketRegionIsDestroyed()
{ testSubscriptionEventsWhenBucketRegionIsDestroyed(true, forop.UPDATE); }
@Test
public void testUpdateSubscriptionEventsWithPrWhileBucketRegionIsDestroyed()
{ testSubscriptionEventsWhenBucketRegionIsDestroyed(false, forop.UPDATE); }
{noformat}
> Missing update (subsctiption) event with partitioned region during bucket
> rebalance.
>
>
> Key: GEODE-1900
> URL: https://issues.apache.org/jira/browse/GEODE-1900
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Anilkumar Gingade
>
> Similar to GEODE-1885...In this case the issue is with update and with both
> offheap and non-offheap regions.
> During transaction operation, if there is concurrent redundant bucket
> re-balance is in progress, the client can miss update event, if its primary
> queue is hosted on the node where bucket gets moved from.
> Consider, three node cluster N1, N2 and N3. With:
> Client C1 connected to node N2.
> Primary bucket region B1 on N1. And secondary bucket for B1 on N2.
> A Transaction is started on N2, which updates an entry on B1.
> When the TX is committed. At the same time the Bucket B1 on N2 is moved
> to N3.
> The Tx commit message from N1 is sent to N2. This also includes the
> subscription message, satisfying the client C1.
> On N2, for offheap region, when bucket is not found locally, the
> exception response is sent to back to N1 without processing the subscription
> message.
> How to reproduce:
> Add following tests/lines in ClientServerTransactionDUnitTest:
> public void
> testUpdateSubscriptionEventsWithOffheapPrWhileBucketRegionIsDestroyed() {
> testSubscriptionEventsWithOffheapPrWhenBucketRegionIsDestroyed(forop.UPDATE);
> }
> public void
> testUpdateSubscriptionEventsWithPrWhileBucketRegionIsDestroyed() {
> testSubscriptionEventsWhenBucketRegionIsDestroyed(false, forop.UPDATE);
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1860) CI Failure: ConcurrentRegionOperationsJUnitTest.testNVPersistAndOverflowSyncConcurrency
[ https://issues.apache.org/jira/browse/GEODE-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507370#comment-15507370 ] ASF subversion and git services commented on GEODE-1860: Commit 06436dba03b38c281a159a239fb84bd0c956ee81 in incubator-geode's branch refs/heads/develop from [~dschneider] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=06436db ] GEODE-1860: change unit test to wait longer > CI Failure: > ConcurrentRegionOperationsJUnitTest.testNVPersistAndOverflowSyncConcurrency > --- > > Key: GEODE-1860 > URL: https://issues.apache.org/jira/browse/GEODE-1860 > Project: Geode > Issue Type: Bug > Components: eviction, persistence >Reporter: Udo Kohlmeyer >Assignee: Darrel Schneider > Labels: ci > > Revision: bb829d3dcaa7105d517868a6fc060981e95643f3 > java.lang.AssertionError: Thread did not terminate after 1 ms: > Thread[ClearThread0,5,] > at org.junit.Assert.fail(Assert.java:88) > at > com.gemstone.gemfire.test.dunit.ThreadUtils.join(ThreadUtils.java:154) > at > com.gemstone.gemfire.internal.cache.ConcurrentRegionOperationsJUnitTest.concurrencyTest(ConcurrentRegionOperationsJUnitTest.java:533) > at > com.gemstone.gemfire.internal.cache.ConcurrentRegionOperationsJUnitTest.testNVPersistAndOverflowSyncConcurrency(ConcurrentRegionOperationsJUnitTest.java:274) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.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.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] [Updated] (GEODE-1911) Provide CqAttributes Builder in addition to existing Factory
[
https://issues.apache.org/jira/browse/GEODE-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jared Stewart updated GEODE-1911:
-
Priority: Trivial (was: Major)
> Provide CqAttributes Builder in addition to existing Factory
>
>
> Key: GEODE-1911
> URL: https://issues.apache.org/jira/browse/GEODE-1911
> Project: Geode
> Issue Type: Wish
> Components: client queues, querying
>Reporter: Jared Stewart
>Priority: Trivial
>
> As a user, it requires at three lines of code to create a minimal
> {{CqAttributes}} object with one {{CqListener}}:
> {code}
> CqAttributesFactory cqf = new CqAttributesFactory();
> cqf.addCqListener(new CQListener());
> CqAttributes cqa = cqf.create();
> {code}
> This could be done in one line with less boilerplate if we also provided a
> CqAttributesBuilder. (See [the builder
> pattern|http://www.informit.com/articles/article.aspx?p=1216151=2].)
> {code}
> CqAttributes cqa = new CqAttributes.Builder().withCqListener(new
> CQListener()).build();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (GEODE-1860) CI Failure: ConcurrentRegionOperationsJUnitTest.testNVPersistAndOverflowSyncConcurrency
[ https://issues.apache.org/jira/browse/GEODE-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-1860: --- Assignee: Darrel Schneider > CI Failure: > ConcurrentRegionOperationsJUnitTest.testNVPersistAndOverflowSyncConcurrency > --- > > Key: GEODE-1860 > URL: https://issues.apache.org/jira/browse/GEODE-1860 > Project: Geode > Issue Type: Bug > Components: eviction, persistence >Reporter: Udo Kohlmeyer >Assignee: Darrel Schneider > Labels: ci > > Revision: bb829d3dcaa7105d517868a6fc060981e95643f3 > java.lang.AssertionError: Thread did not terminate after 1 ms: > Thread[ClearThread0,5,] > at org.junit.Assert.fail(Assert.java:88) > at > com.gemstone.gemfire.test.dunit.ThreadUtils.join(ThreadUtils.java:154) > at > com.gemstone.gemfire.internal.cache.ConcurrentRegionOperationsJUnitTest.concurrencyTest(ConcurrentRegionOperationsJUnitTest.java:533) > at > com.gemstone.gemfire.internal.cache.ConcurrentRegionOperationsJUnitTest.testNVPersistAndOverflowSyncConcurrency(ConcurrentRegionOperationsJUnitTest.java:274) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.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.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 java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at >
[jira] [Commented] (GEODE-1648) Provide ability to disable security for some components
[
https://issues.apache.org/jira/browse/GEODE-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507240#comment-15507240
]
ASF subversion and git services commented on GEODE-1648:
Commit f77f46d40ff512892e1fba04792429745132e030 in incubator-geode's branch
refs/heads/GEODE-1648 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=f77f46d ]
GEODE-1648: commits related to security-enabled-components.
> Provide ability to disable security for some components
> ---
>
> Key: GEODE-1648
> URL: https://issues.apache.org/jira/browse/GEODE-1648
> Project: Geode
> Issue Type: Sub-task
> Components: security
>Reporter: Swapnil Bawaskar
>Assignee: Jinmei Liao
> Fix For: 1.0.0-incubating
>
>
> When the new {{SecurityManager}} interface is used, it will enable
> authentication and authorization for client-server, jmx, peer-to-peer and
> WAN. Not all users will want authentication and authorization for all these
> components as explained in this comment:
> https://issues.apache.org/jira/browse/GEODE-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369089#comment-15369089
> We should add new geode properties:
> {noformat}
> enable-peer-to-peer-authentication
> enable-client-server-security
> enable-msnsgement-security
> {noformat}
> Update:
> Rather than introducing three new properties, we should add a single new
> property: {{security-enabled-components}} which will have a default value of
> {{all}} and can be configured with the same list of components being worked
> on in GEODE-420.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1511) geode-core Maven POM File incorrectly includes the log4j-slf4j-impl bridge JAR
[
https://issues.apache.org/jira/browse/GEODE-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507224#comment-15507224
]
Anthony Baker commented on GEODE-1511:
--
You're right. And application projects that depend on geode-core don't pull in
optional deps.
> geode-core Maven POM File incorrectly includes the log4j-slf4j-impl bridge JAR
> --
>
> Key: GEODE-1511
> URL: https://issues.apache.org/jira/browse/GEODE-1511
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: John Blum
>Priority: Critical
>
> The {{log4j-slf4j-impl}} SLF4J bridge JAR has been erroneously declared in
> the _Apache Geode_ {{geode-core}} Maven POM file.
> The inclusion of this declaration can have unintended consequences in a
> user's Geode-based application that might potentially rely on different
> and/or several logging frameworks (e.g. SLF4J, logback, etc), depending on
> the transitive dependencies of the application.
> Geode should not be including SLF4J bridge JARs in the applications CLASSPATH
> at runtime or otherwise.
> Additionally, the Geode POM file includes references to *test* dependencies
> that should be removed, specifically...
> junit
> asm
> system-rules
> mockito-core
> geode-junit
> hadoop-auth
> awaitility
> catch-exception
> cglib
> powermock-module-junit4
> jmock-junit4
> catch-throwable
> tempus-fugit
> commons-collections
> JUnitParams
> bcel
> assertj-core
> powermock-core
> jedis
> jmock-legacy
> powermock-api-mockito
> hamcrest-all
> commons-configuration
> spymemcached
> multithreadedtc
> derby
> The more dependencies you include, the greater chance for conflict an
> application developer may have when integrating with Apache Geode. The
> distributed/deployed (to Maven Central) is less about "building" the Apache
> Geode project and more about running an application built with Apache Geode.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1511) geode-core Maven POM File incorrectly includes the log4j-slf4j-impl bridge JAR
[
https://issues.apache.org/jira/browse/GEODE-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507205#comment-15507205
]
Dan Smith commented on GEODE-1511:
--
This was already fixed as part of GEODE-1811. slf4j was being erroneously
included because although it was marked as optional in the gradle file, we were
not passing the optional flag on into the generated pom for runtime
dependencies. From the [latest
snapshot|https://repository.apache.org/content/repositories/snapshots/org/apache/geode/geode-core/1.0.0-incubating-SNAPSHOT/geode-core-1.0.0-incubating-20160920.160327-73.pom]
{code}
org.apache.logging.log4j
log4j-slf4j-impl
2.6.1
runtime
true
{code}
> geode-core Maven POM File incorrectly includes the log4j-slf4j-impl bridge JAR
> --
>
> Key: GEODE-1511
> URL: https://issues.apache.org/jira/browse/GEODE-1511
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: John Blum
>Priority: Critical
>
> The {{log4j-slf4j-impl}} SLF4J bridge JAR has been erroneously declared in
> the _Apache Geode_ {{geode-core}} Maven POM file.
> The inclusion of this declaration can have unintended consequences in a
> user's Geode-based application that might potentially rely on different
> and/or several logging frameworks (e.g. SLF4J, logback, etc), depending on
> the transitive dependencies of the application.
> Geode should not be including SLF4J bridge JARs in the applications CLASSPATH
> at runtime or otherwise.
> Additionally, the Geode POM file includes references to *test* dependencies
> that should be removed, specifically...
> junit
> asm
> system-rules
> mockito-core
> geode-junit
> hadoop-auth
> awaitility
> catch-exception
> cglib
> powermock-module-junit4
> jmock-junit4
> catch-throwable
> tempus-fugit
> commons-collections
> JUnitParams
> bcel
> assertj-core
> powermock-core
> jedis
> jmock-legacy
> powermock-api-mockito
> hamcrest-all
> commons-configuration
> spymemcached
> multithreadedtc
> derby
> The more dependencies you include, the greater chance for conflict an
> application developer may have when integrating with Apache Geode. The
> distributed/deployed (to Maven Central) is less about "building" the Apache
> Geode project and more about running an application built with Apache Geode.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GEODE-1886) StoredObject instanceof checks in EntryEventImpl slow down heap operations
[ https://issues.apache.org/jira/browse/GEODE-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-1886. - Resolution: Fixed Fix Version/s: 1.0.0-incubating > StoredObject instanceof checks in EntryEventImpl slow down heap operations > -- > > Key: GEODE-1886 > URL: https://issues.apache.org/jira/browse/GEODE-1886 > Project: Geode > Issue Type: Bug > Components: offheap >Reporter: Darrel Schneider >Assignee: Darrel Schneider > Fix For: 1.0.0-incubating > > > The instanceof checks added to EntryEventImpl for offheap have slowed down > the performance of heap. This slow down will probably only be noticed when > the cache operation is local. When the operations is distributed the network > adds enough overhead that the extra time in the instanceof checks is not > noticed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-1643) The new SecurityManager need to authenticate the gateway sender/receiver as well.
[ https://issues.apache.org/jira/browse/GEODE-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-1643. Resolution: Fixed security added > The new SecurityManager need to authenticate the gateway sender/receiver as > well. > - > > Key: GEODE-1643 > URL: https://issues.apache.org/jira/browse/GEODE-1643 > Project: Geode > Issue Type: Sub-task > Components: security >Reporter: Jinmei Liao >Assignee: Jinmei Liao > > Currently the gateway authentication still only uses > security-client-authenticator, need to have security-manager manage the > authentication there as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-1648) Provide ability to disable security for some components
[
https://issues.apache.org/jira/browse/GEODE-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-1648.
Resolution: Fixed
the work related for security-enabled-components are reverted in this commit.
45ecd4c Jinmei Liao on 9/15/16 at 1:39 PM (committed on 9/15/16 at 3:00 PM)
[open]
GEODE-1648: revert commits related to security-enabled-components.
The approach is make authInit optional, so that we can provide
username/password in the security properties file.
> Provide ability to disable security for some components
> ---
>
> Key: GEODE-1648
> URL: https://issues.apache.org/jira/browse/GEODE-1648
> Project: Geode
> Issue Type: Sub-task
> Components: security
>Reporter: Swapnil Bawaskar
>Assignee: Jinmei Liao
> Fix For: 1.0.0-incubating
>
>
> When the new {{SecurityManager}} interface is used, it will enable
> authentication and authorization for client-server, jmx, peer-to-peer and
> WAN. Not all users will want authentication and authorization for all these
> components as explained in this comment:
> https://issues.apache.org/jira/browse/GEODE-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369089#comment-15369089
> We should add new geode properties:
> {noformat}
> enable-peer-to-peer-authentication
> enable-client-server-security
> enable-msnsgement-security
> {noformat}
> Update:
> Rather than introducing three new properties, we should add a single new
> property: {{security-enabled-components}} which will have a default value of
> {{all}} and can be configured with the same list of components being worked
> on in GEODE-420.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (GEODE-1648) Provide ability to disable security for some components
[
https://issues.apache.org/jira/browse/GEODE-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-1648:
--
Assignee: Jinmei Liao (was: Kirk Lund)
> Provide ability to disable security for some components
> ---
>
> Key: GEODE-1648
> URL: https://issues.apache.org/jira/browse/GEODE-1648
> Project: Geode
> Issue Type: Sub-task
> Components: security
>Reporter: Swapnil Bawaskar
>Assignee: Jinmei Liao
> Fix For: 1.0.0-incubating
>
>
> When the new {{SecurityManager}} interface is used, it will enable
> authentication and authorization for client-server, jmx, peer-to-peer and
> WAN. Not all users will want authentication and authorization for all these
> components as explained in this comment:
> https://issues.apache.org/jira/browse/GEODE-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369089#comment-15369089
> We should add new geode properties:
> {noformat}
> enable-peer-to-peer-authentication
> enable-client-server-security
> enable-msnsgement-security
> {noformat}
> Update:
> Rather than introducing three new properties, we should add a single new
> property: {{security-enabled-components}} which will have a default value of
> {{all}} and can be configured with the same list of components being worked
> on in GEODE-420.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GEODE-1569) add post authorization processing in JMX and CLI commands
[ https://issues.apache.org/jira/browse/GEODE-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-1569. Resolution: Fixed Post processing added > add post authorization processing in JMX and CLI commands > - > > Key: GEODE-1569 > URL: https://issues.apache.org/jira/browse/GEODE-1569 > Project: Geode > Issue Type: Sub-task > Components: security >Reporter: Swapnil Bawaskar >Assignee: Jinmei Liao > > For the new authorization interface that uses Resource:Operation permissions, > need to provide post-authorization processing for get and query operations, > so that geode can filter the results before sending them back to the client. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-1571) Client security should be able to use Resource:Operation permissions
[
https://issues.apache.org/jira/browse/GEODE-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-1571.
Resolution: Fixed
Client security is secured by SecurityManager now.
> Client security should be able to use Resource:Operation permissions
>
>
> Key: GEODE-1571
> URL: https://issues.apache.org/jira/browse/GEODE-1571
> Project: Geode
> Issue Type: Sub-task
> Components: security
>Reporter: Swapnil Bawaskar
>Assignee: Jinmei Liao
>
> While providing role based access control for JMX and CLI, noun-verby
> permission of the form of RESOURCE:OPERATION[:REGION] have been introduced.
> Please refer to the wiki for more details:
> https://cwiki.apache.org/confluence/display/GEODE/How+to+secure+JMX+and+GFSH
> We now need to provide a new interface so that client-server security can
> also use these noun-verby permissions.
> To make Geode security "integrated", users will only have to provide an
> implementation of this new interface and it will work for JMX, gfsh and
> client-server.
> {{com.gemstone.gemfire.security.AccessControl}} should be deprecated once we
> have this new interface.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (GEODE-1569) add post authorization processing in JMX and CLI commands
[ https://issues.apache.org/jira/browse/GEODE-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-1569: -- Assignee: Jinmei Liao > add post authorization processing in JMX and CLI commands > - > > Key: GEODE-1569 > URL: https://issues.apache.org/jira/browse/GEODE-1569 > Project: Geode > Issue Type: Sub-task > Components: security >Reporter: Swapnil Bawaskar >Assignee: Jinmei Liao > > For the new authorization interface that uses Resource:Operation permissions, > need to provide post-authorization processing for get and query operations, > so that geode can filter the results before sending them back to the client. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-1571) Client security should be able to use Resource:Operation permissions
[
https://issues.apache.org/jira/browse/GEODE-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-1571:
--
Assignee: Jinmei Liao
> Client security should be able to use Resource:Operation permissions
>
>
> Key: GEODE-1571
> URL: https://issues.apache.org/jira/browse/GEODE-1571
> Project: Geode
> Issue Type: Sub-task
> Components: security
>Reporter: Swapnil Bawaskar
>Assignee: Jinmei Liao
>
> While providing role based access control for JMX and CLI, noun-verby
> permission of the form of RESOURCE:OPERATION[:REGION] have been introduced.
> Please refer to the wiki for more details:
> https://cwiki.apache.org/confluence/display/GEODE/How+to+secure+JMX+and+GFSH
> We now need to provide a new interface so that client-server security can
> also use these noun-verby permissions.
> To make Geode security "integrated", users will only have to provide an
> implementation of this new interface and it will work for JMX, gfsh and
> client-server.
> {{com.gemstone.gemfire.security.AccessControl}} should be deprecated once we
> have this new interface.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (GEODE-1570) developer REST API should be secured
[ https://issues.apache.org/jira/browse/GEODE-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Duling reassigned GEODE-1570: --- Assignee: Kevin Duling > developer REST API should be secured > > > Key: GEODE-1570 > URL: https://issues.apache.org/jira/browse/GEODE-1570 > Project: Geode > Issue Type: Sub-task > Components: rest (dev), security >Reporter: Swapnil Bawaskar >Assignee: Kevin Duling > > The developer REST API should require authentication when security is > enabled. For authorization, the implementation should use the new > Resource:Operation permissions API that is used by JMX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1524) Swagger UI does not show query errors
[
https://issues.apache.org/jira/browse/GEODE-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15505814#comment-15505814
]
ASF subversion and git services commented on GEODE-1524:
Commit ccb514c29207dfaa7d5e109d0c5e21151797fc24 in incubator-geode's branch
refs/heads/develop from [~ukohlmeyer]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=ccb514c ]
GEODE-1524: Reverting Swagger version
> Swagger UI does not show query errors
> -
>
> Key: GEODE-1524
> URL: https://issues.apache.org/jira/browse/GEODE-1524
> Project: Geode
> Issue Type: Improvement
> Components: rest (dev)
>Reporter: Jens Deppe
>Assignee: Udo Kohlmeyer
> Labels: bug-hunt
> Fix For: 1.0.0-incubating
>
>
> I'm playing with UDA and running adhoc queries through the Swagger UI.
> However, if I have a catastrophic error in my query the Swagger UI doesn't
> display it and I'm left with a 'progress spinner' bar. However, the same
> query from the command line does produce an appropriate error. For example,
> here I'm trying to use my {{sumuda}} function in a query:
> {noformat}
> (2.7)jdeppe@deppe-mbp bughunt-2016 $ curl -v -H "Accept: application/json"
> 'http://127.0.0.1:8080/gemfire-api/v1/queries/adhoc?q=select%20sumuda(index)%20from%20%2Ffoo'
> * Trying 127.0.0.1...
> * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> > GET /gemfire-api/v1/queries/adhoc?q=select%20sumuda(index)%20from%20%2Ffoo
> > HTTP/1.1
> > Host: 127.0.0.1:8080
> > User-Agent: curl/7.43.0
> > Accept: application/json
> >
> < HTTP/1.1 500 Server Error
> < Date: Fri, 10 Jun 2016 19:52:26 GMT
> < Content-Type: application/json
> < Accept-Charset: big5, big5-hkscs, cesu-8, euc-jp, euc-kr, gb18030, gb2312,
> gbk, ibm-thai, ibm00858, ibm01140, ibm01141, ibm01142, ibm01143, ibm01144,
> ibm01145, ibm01146, ibm01147, ibm01148, ibm01149, ibm037, ibm1026, ibm1047,
> ibm273, ibm277, ibm278, ibm280, ibm284, ibm285, ibm290, ibm297, ibm420,
> ibm424, ibm437, ibm500, ibm775, ibm850, ibm852, ibm855, ibm857, ibm860,
> ibm861, ibm862, ibm863, ibm864, ibm865, ibm866, ibm868, ibm869, ibm870,
> ibm871, ibm918, iso-2022-cn, iso-2022-jp, iso-2022-jp-2, iso-2022-kr,
> iso-8859-1, iso-8859-13, iso-8859-15, iso-8859-2, iso-8859-3, iso-8859-4,
> iso-8859-5, iso-8859-6, iso-8859-7, iso-8859-8, iso-8859-9, jis_x0201,
> jis_x0212-1990, koi8-r, koi8-u, shift_jis, tis-620, us-ascii, utf-16,
> utf-16be, utf-16le, utf-32, utf-32be, utf-32le, utf-8, windows-1250,
> windows-1251, windows-1252, windows-1253, windows-1254, windows-1255,
> windows-1256, windows-1257, windows-1258, windows-31j, x-big5-hkscs-2001,
> x-big5-solaris, x-compound_text, x-euc-jp-linux, x-euc-tw, x-eucjp-open,
> x-ibm1006, x-ibm1025, x-ibm1046, x-ibm1097, x-ibm1098, x-ibm1112, x-ibm1122,
> x-ibm1123, x-ibm1124, x-ibm1166, x-ibm1364, x-ibm1381, x-ibm1383, x-ibm300,
> x-ibm33722, x-ibm737, x-ibm833, x-ibm834, x-ibm856, x-ibm874, x-ibm875,
> x-ibm921, x-ibm922, x-ibm930, x-ibm933, x-ibm935, x-ibm937, x-ibm939,
> x-ibm942, x-ibm942c, x-ibm943, x-ibm943c, x-ibm948, x-ibm949, x-ibm949c,
> x-ibm950, x-ibm964, x-ibm970, x-iscii91, x-iso-2022-cn-cns, x-iso-2022-cn-gb,
> x-iso-8859-11, x-jis0208, x-jisautodetect, x-johab, x-macarabic,
> x-maccentraleurope, x-maccroatian, x-maccyrillic, x-macdingbat, x-macgreek,
> x-machebrew, x-maciceland, x-macroman, x-macromania, x-macsymbol, x-macthai,
> x-macturkish, x-macukraine, x-ms932_0213, x-ms950-hkscs, x-ms950-hkscs-xp,
> x-mswin-936, x-pck, x-sjis_0213, x-utf-16le-bom, x-utf-32be-bom,
> x-utf-32le-bom, x-windows-50220, x-windows-50221, x-windows-874,
> x-windows-949, x-windows-950, x-windows-iso2022jp
> < Content-Length: 5211
> < Server: Jetty(9.3.6.v20151106)
> <
> {"message" : "Server has encountered while executing Adhoc query!",
> "stackTrace" :
> "com.gemstone.gemfire.rest.internal.web.exception.GemfireRestException:
> Server has encountered while executing Adhoc query!
> at
> com.gemstone.gemfire.rest.internal.web.controllers.QueryAccessController.runAdhocQuery(QueryAccessController.java:208)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:222)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:137)
> at
>
[jira] [Commented] (GEODE-420) locator ssl configuration
[ https://issues.apache.org/jira/browse/GEODE-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15505815#comment-15505815 ] ASF subversion and git services commented on GEODE-420: --- Commit 61c6ae0378310b970ecd5cd826f9bc3af8dde13e in incubator-geode's branch refs/heads/develop from [~ukohlmeyer] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=61c6ae0 ] GEODE-420: Renaming SSLConfigurationFactoryTest.java to SSLConfigurationFactoryJUnitTest.java > locator ssl configuration > - > > Key: GEODE-420 > URL: https://issues.apache.org/jira/browse/GEODE-420 > Project: Geode > Issue Type: New Feature > Components: docs, locator >Reporter: Darrel Schneider >Assignee: Udo Kohlmeyer > Fix For: 1.0.0-incubating > > > We currently allow separate SSL configuration for cluster, server, gateway, > jmx-manager, and http-service. > The "server" attributes configure the ssl connections from clients to a cache > server. > The "gateway" attributes configure the ssl connections between a gateway > sender and receiver. > The "jmx-manager" attributes configure the ssl connections between an admin > client (for example gfsh) and the jmx-manager. > The "http-service" attributes configure the ssl connections between REST > clients and the http-service. > The "cluster" attributes configure the ssl connections between the members of > a distributed system (peer-to-peer connections) AND to the locators. > Using "cluster" for the connections to a locator can be a problem. > Say you trust all your members of a distributed system since they are running > on your private network. So no need for ssl on the p2p connections. > So you disable cluster-ssl. These means that your peers are locators are all > using unsecure connections. > But some of these members are hosting a cache server and have clients > connecting to them. So you configure "server" ssl for the client to server > connections. But for your clients to find you servers they need to talk to > the locator. Since the clients are coming from the outside world you want > them to use SSL. So you configure "server" ssl on them for when they connect > to the cache server and "cluster" SSL on them for when they connect to the > locator. But your locators are configured with "cluster" SSL disabled so that > the p2p connects on the internal network will not be SSL. > So you are either forced to have you client to locator connections to be > unsecure or you need to secure all the cluster connections forcing the peers > to also use SSL. > I think we should introduce "locator" SSL configuration options that would > allow you to have just the locator and server using SSL and the "cluster" to > have SSL disabled. > Something else to consider would be for the locator to be able to use SSL for > clients but non-SSL for locator-to-locator and peers-to-locator connections. > I think this would be more complicated because we would need to have > different ports that the locator listens on (one for clients and one for > locators and members). > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
