[jira] [Updated] (GEODE-4774) When starting second locator without Security Manager, displaying incorrect status message
[
https://issues.apache.org/jira/browse/GEODE-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4774:
--
Description:
When I start a second locator without a Security Manager (inside a gfsh shell),
I get the following output:
{code:java}
Security Manager is enabled - unable to auto-connect. Please use "connect
--locator=10.118.19.11[13489]" to connect Gfsh to the locator.{code}
However, the output should state:
{code:java}
Cluster configuration service is up and running.{code}
How to reproduce:
{code:java}
gfsh> start locator --name=locator1
gfsh> start locator --name=locator2 --port=13489
{code}
was:
When I start a second locator without a Security Manager, I get the following
output:
{code:java}
Security Manager is enabled - unable to auto-connect. Please use "connect
--locator=10.118.19.11[13489]" to connect Gfsh to the locator.{code}
However, the output should state:
{code:java}
Cluster configuration service is up and running.{code}
How to reproduce:
{code}
start locator --name=locator1
start locator --name=locator2 --port=13489
{code}
> When starting second locator without Security Manager, displaying incorrect
> status message
> --
>
> Key: GEODE-4774
> URL: https://issues.apache.org/jira/browse/GEODE-4774
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Barbara Pruijn
>Priority: Major
>
> When I start a second locator without a Security Manager (inside a gfsh
> shell), I get the following output:
> {code:java}
> Security Manager is enabled - unable to auto-connect. Please use "connect
> --locator=10.118.19.11[13489]" to connect Gfsh to the locator.{code}
> However, the output should state:
> {code:java}
> Cluster configuration service is up and running.{code}
> How to reproduce:
> {code:java}
> gfsh> start locator --name=locator1
> gfsh> start locator --name=locator2 --port=13489
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'create region'
[
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388443#comment-16388443
]
John Blum commented on GEODE-4787:
--
Submitted [PR #1563|https://github.com/apache/geode/pull/1563] with the
necessary changes for review and merging to {{develop}} for the *1.5.0* release.
> Re-instate Management REST API endpoints for 'create index' and 'create
> region'
> ---
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
> Issue Type: Bug
> Components: management
>Affects Versions: 1.3.0, 1.4.0
>Reporter: John Blum
>Priority: Blocker
> Labels: pull-request-available
> Attachments: ClusterConfigurationExampleIntegrationTests.java,
> Customer.java, CustomerRepository.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache
> Geode community refactored and [reduced the
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
> and by extension, the Web service endpoints to, mostly, a [single Web
> service
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
> which essentially just accepts a _Gfsh_ command string, such as `{{create
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as
> measured against [Richardson Maturity
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources
> (e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for
> _Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager
> via HTTP in order to transcend firewalls when a devops team wanted to manage
> a remote cluster deployed in a cloud environment, such as AWS or GCP. By
> using HTTP over JMX/RMI, a user would not need to punch additional holes in
> the firewall to expose the JMX/RMI port (1099) for instance.
> Still, the "intent" was never to stop at supporting just _Gfsh_, but to
> become a true REST API that can be consumed by any client (not just _Gfsh_):
> application, framework, tool, etc, regardless of language (e.g. Java, C++/C#,
> Ruby, Python, etc).
> However, the team that modified this API failed to recognize the benefit of
> this design and actually took a step backwards. The HTTP Verbs are not
> properly used. The Web service API endpoints are not resourceful, and
> imposing the _Gfsh_ DSL on clients is foolish and too restrictive.
> While, it might be argued that this was an "internal" API, technically,
> speaking, guarding classes by putting them in an "internal" package is no
> safe-guard or guarantee that could have been properly enforced using Java
> access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only
> exposing an SPI for consumption.
> The fact remains that this API was changed in an incompatible way before an
> "alternative" solution was properly introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4788) parReg.execute.FunctionServiceTest.getSomeKeys failed with util.TestException: Test Issue - Got the exception
[
https://issues.apache.org/jira/browse/GEODE-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-4788:
--
Labels: pull-request-available (was: )
> parReg.execute.FunctionServiceTest.getSomeKeys failed with
> util.TestException: Test Issue - Got the exception
> -
>
> Key: GEODE-4788
> URL: https://issues.apache.org/jira/browse/GEODE-4788
> Project: Geode
> Issue Type: New Feature
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> CLIENT
> vm_12_thr_15_accessor1_rs-FullRegression-2018-03-03-05-01-17-client-8_4804
> TASK[0]
> parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions
> ERROR util.TestException: Test Issue - Got the exception
> util.TestException: Test Issue - Got the exception
> at
> parReg.execute.FunctionServiceTest.getSomeKeys(FunctionServiceTest.java:508)
> at
> parReg.execute.FunctionServiceTest.doRandomFunctionExecutions(FunctionServiceTest.java:473)
> at
> parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions(FunctionServiceTest.java:436)
> 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 hydra.MethExecutor.execute(MethExecutor.java:181)
> at hydra.MethExecutor.execute(MethExecutor.java:149)
> at hydra.TestTask.execute(TestTask.java:192)
> at hydra.RemoteTestModule$1.run(RemoteTestModule.java:212)
> Caused by: java.lang.RuntimeException:
> org.apache.geode.internal.cache.ForceReattemptException: FetchKeysResponse
> got remote CacheClosedException; forcing reattempt.
> at
> org.apache.geode.internal.cache.PartitionedRegionGetSomeKeys.getSomeKeys(PartitionedRegionGetSomeKeys.java:74)
> at
> parReg.execute.FunctionServiceTest.getSomeKeys(FunctionServiceTest.java:502)
> ... 10 more
> Caused by: org.apache.geode.internal.cache.ForceReattemptException:
> FetchKeysResponse got remote CacheClosedException; forcing reattempt.
> at
> org.apache.geode.internal.cache.partitioned.FetchKeysMessage$FetchKeysResponse.waitForKeys(FetchKeysMessage.java:546)
> at
> org.apache.geode.internal.cache.PartitionedRegionGetSomeKeys.getSomeKeys(PartitionedRegionGetSomeKeys.java:66)
> ... 11 more
> Caused by: org.apache.geode.cache.CacheClosedException: Remote cache is
> closed:
> rs-FullRegression-2018-03-03-05-01-17-client-8(dataStoregemfire5_rs-FullRegression-2018-03-03-05-01-17-client-8_4776:4776):1031
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1588)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1576)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:304)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:448)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1118)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$8$1.run(ClusterDistributionManager.java:943)
> at java.lang.Thread.run(Thread.java:748)
>
> CLIENT
> vm_15_thr_29_accessor4_rs-FullRegression-2018-03-03-05-01-17-client-8_4918
> TASK[0]
> parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions
> ERROR util.TestException: Test Issue - Got the exception
> util.TestException: Test Issue - Got the exception
> at
> parReg.execute.FunctionServiceTest.getSomeKeys(FunctionServiceTest.java:508)
> at
> parReg.execute.FunctionServiceTest.doRandomFunctionExecutions(FunctionServiceTest.java:473)
> at
> parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions(FunctionServiceTest.java:436)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
[jira] [Resolved] (GEODE-4781) Categorize Lucene tests
[ https://issues.apache.org/jira/browse/GEODE-4781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun resolved GEODE-4781. Resolution: Fixed > Categorize Lucene tests > --- > > Key: GEODE-4781 > URL: https://issues.apache.org/jira/browse/GEODE-4781 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: nabarun >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4781) Categorize Lucene tests
[ https://issues.apache.org/jira/browse/GEODE-4781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun closed GEODE-4781. -- > Categorize Lucene tests > --- > > Key: GEODE-4781 > URL: https://issues.apache.org/jira/browse/GEODE-4781 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: nabarun >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4786) Reconfigure sidenav and delete existing pages
Addison created GEODE-4786: -- Summary: Reconfigure sidenav and delete existing pages Key: GEODE-4786 URL: https://issues.apache.org/jira/browse/GEODE-4786 Project: Geode Issue Type: Sub-task Components: native client Reporter: Addison I propose that we start refactoring the geode native docs from a blank canvas. This story is about deleting the existing pages and sidenav structure and building out the docs, anew, one page at a time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4770) Destroying an unstarted GatewayReceiver throws an NPE
[
https://issues.apache.org/jira/browse/GEODE-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Huynh updated GEODE-4770:
---
Affects Version/s: (was: 1.4.0)
1.5.0
> Destroying an unstarted GatewayReceiver throws an NPE
> -
>
> Key: GEODE-4770
> URL: https://issues.apache.org/jira/browse/GEODE-4770
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.5.0
>Reporter: Kenneth Howe
>Assignee: Jason Huynh
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Found while writing tests for a new Gfsh command to destroy a GatewayReceiver:
> Create a GatewayReceiver with manualStart = true
> {{create gateway-receiver --manual-start==true ...}}
> NPE is thrown by the {{destroy()}} in the Function that implements the new
> {{destroy gateway-receiver}} command.
> {code:java}
> if (receiver.isRunning()) {
> receiver.stop();
> }
> receiver.destroy();
> {code}
> NPE is thrown here:
> {code:java|title=GatewayReceiverImpl}
> public void destroy() {
> if (receiver.isRunning()) {
> {code}
> because {{receiver}} is not set until the the GatewayReceiver is started.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4770) Destroying an unstarted GatewayReceiver throws an NPE
[
https://issues.apache.org/jira/browse/GEODE-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Huynh resolved GEODE-4770.
Resolution: Fixed
Fix Version/s: 1.6.0
> Destroying an unstarted GatewayReceiver throws an NPE
> -
>
> Key: GEODE-4770
> URL: https://issues.apache.org/jira/browse/GEODE-4770
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.5.0
>Reporter: Kenneth Howe
>Assignee: Jason Huynh
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Found while writing tests for a new Gfsh command to destroy a GatewayReceiver:
> Create a GatewayReceiver with manualStart = true
> {{create gateway-receiver --manual-start==true ...}}
> NPE is thrown by the {{destroy()}} in the Function that implements the new
> {{destroy gateway-receiver}} command.
> {code:java}
> if (receiver.isRunning()) {
> receiver.stop();
> }
> receiver.destroy();
> {code}
> NPE is thrown here:
> {code:java|title=GatewayReceiverImpl}
> public void destroy() {
> if (receiver.isRunning()) {
> {code}
> because {{receiver}} is not set until the the GatewayReceiver is started.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-4770) Destroying an unstarted GatewayReceiver throws an NPE
[
https://issues.apache.org/jira/browse/GEODE-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Huynh reassigned GEODE-4770:
--
Assignee: Jason Huynh
> Destroying an unstarted GatewayReceiver throws an NPE
> -
>
> Key: GEODE-4770
> URL: https://issues.apache.org/jira/browse/GEODE-4770
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.4.0
>Reporter: Kenneth Howe
>Assignee: Jason Huynh
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Found while writing tests for a new Gfsh command to destroy a GatewayReceiver:
> Create a GatewayReceiver with manualStart = true
> {{create gateway-receiver --manual-start==true ...}}
> NPE is thrown by the {{destroy()}} in the Function that implements the new
> {{destroy gateway-receiver}} command.
> {code:java}
> if (receiver.isRunning()) {
> receiver.stop();
> }
> receiver.destroy();
> {code}
> NPE is thrown here:
> {code:java|title=GatewayReceiverImpl}
> public void destroy() {
> if (receiver.isRunning()) {
> {code}
> because {{receiver}} is not set until the the GatewayReceiver is started.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'created region'.
[
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-4787:
-
Priority: Blocker (was: Major)
> Re-instate Management REST API endpoints for 'create index' and 'created
> region'.
> -
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: John Blum
>Priority: Blocker
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache
> Geode community refactored and [reduced the
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
> and by extension, the Web service endpoints to, mostly, a [single Web
> service
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
> which essentially just accepts a _Gfsh_ command string, such as `{{create
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as
> measured against [Richardson Maturity
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources
> (e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for
> _Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager
> via HTTP in order to transcend firewalls when a devops team wanted to manage
> a remote cluster deployed in a cloud environment, such as AWS or GCP. By
> using HTTP over JMX/RMI, a user would not need to punch additional holes in
> the firewall to expose the JMX/RMI port (1099) for instance.
> Still, the "intent" was never to stop at supporting just _Gfsh_, but to
> become a true REST API that can be consumed by any client (not just _Gfsh_):
> application, framework, tool, etc, regardless of language (e.g. Java, C++/C#,
> Ruby, Python, etc).
> However, the team that modified this API failed to recognize the benefit of
> this design and actually took a step backwards. The HTTP Verbs are not
> properly used. The Web service API endpoints are not resourceful, and
> imposing the _Gfsh_ DSL on clients is foolish and too restrictive.
> While, it might be argued that this was an "internal" API, technically,
> speaking, guarding classes by putting them in an "internal" package is no
> safe-guard or guarantee that could have been properly enforced using Java
> access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only
> exposing an SPI for consumption.
> The fact remains that this API was changed in an incompatible way before an
> "alternative" solution was properly introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'created region'.
[
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-4787:
-
Component/s: (was: gfsh)
> Re-instate Management REST API endpoints for 'create index' and 'created
> region'.
> -
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: John Blum
>Priority: Blocker
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache
> Geode community refactored and [reduced the
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
> and by extension, the Web service endpoints to, mostly, a [single Web
> service
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
> which essentially just accepts a _Gfsh_ command string, such as `{{create
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as
> measured against [Richardson Maturity
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources
> (e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for
> _Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager
> via HTTP in order to transcend firewalls when a devops team wanted to manage
> a remote cluster deployed in a cloud environment, such as AWS or GCP. By
> using HTTP over JMX/RMI, a user would not need to punch additional holes in
> the firewall to expose the JMX/RMI port (1099) for instance.
> Still, the "intent" was never to stop at supporting just _Gfsh_, but to
> become a true REST API that can be consumed by any client (not just _Gfsh_):
> application, framework, tool, etc, regardless of language (e.g. Java, C++/C#,
> Ruby, Python, etc).
> However, the team that modified this API failed to recognize the benefit of
> this design and actually took a step backwards. The HTTP Verbs are not
> properly used. The Web service API endpoints are not resourceful, and
> imposing the _Gfsh_ DSL on clients is foolish and too restrictive.
> While, it might be argued that this was an "internal" API, technically,
> speaking, guarding classes by putting them in an "internal" package is no
> safe-guard or guarantee that could have been properly enforced using Java
> access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only
> exposing an SPI for consumption.
> The fact remains that this API was changed in an incompatible way before an
> "alternative" solution was properly introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'create region'
[
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-4787:
-
Summary: Re-instate Management REST API endpoints for 'create index' and
'create region' (was: Re-instate Management REST API endpoints for 'create
index' and 'created region')
> Re-instate Management REST API endpoints for 'create index' and 'create
> region'
> ---
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: John Blum
>Priority: Blocker
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache
> Geode community refactored and [reduced the
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
> and by extension, the Web service endpoints to, mostly, a [single Web
> service
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
> which essentially just accepts a _Gfsh_ command string, such as `{{create
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as
> measured against [Richardson Maturity
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources
> (e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for
> _Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager
> via HTTP in order to transcend firewalls when a devops team wanted to manage
> a remote cluster deployed in a cloud environment, such as AWS or GCP. By
> using HTTP over JMX/RMI, a user would not need to punch additional holes in
> the firewall to expose the JMX/RMI port (1099) for instance.
> Still, the "intent" was never to stop at supporting just _Gfsh_, but to
> become a true REST API that can be consumed by any client (not just _Gfsh_):
> application, framework, tool, etc, regardless of language (e.g. Java, C++/C#,
> Ruby, Python, etc).
> However, the team that modified this API failed to recognize the benefit of
> this design and actually took a step backwards. The HTTP Verbs are not
> properly used. The Web service API endpoints are not resourceful, and
> imposing the _Gfsh_ DSL on clients is foolish and too restrictive.
> While, it might be argued that this was an "internal" API, technically,
> speaking, guarding classes by putting them in an "internal" package is no
> safe-guard or guarantee that could have been properly enforced using Java
> access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only
> exposing an SPI for consumption.
> The fact remains that this API was changed in an incompatible way before an
> "alternative" solution was properly introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4786) Reconfigure sidenav and delete existing pages
[ https://issues.apache.org/jira/browse/GEODE-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4786: -- Labels: pull-request-available (was: ) > Reconfigure sidenav and delete existing pages > - > > Key: GEODE-4786 > URL: https://issues.apache.org/jira/browse/GEODE-4786 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Addison >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > > I propose that we start refactoring the geode native docs from a blank > canvas. This story is about deleting the existing pages and sidenav > structure and building out the docs, anew, one page at a time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'create region'
[
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388413#comment-16388413
]
John Blum commented on GEODE-4787:
--
To help with testing and CI efforts, I have created a _Spring Data for Apache
Geode_ Integration Tests that properly tests that a {{ClientCache}} application
can properly create a required _Region_ in server cluster (e.g. PCC) and
subsequently access the required _Region_ (i.e. perform basic data access
operations like CRUD and querying).
The test class ("`ClusterConfigurationExampleIntegrationTests `" is
[here|https://github.com/jxblum/contacts-application/blob/master/cluster-configuration-example/src/test/java/example/test/client/ClusterConfigurationExampleIntegrationTests.java].
It relies on the
[`example.test.client.model.Customer`|https://github.com/jxblum/contacts-application/blob/master/cluster-configuration-example/src/test/java/example/test/client/model/Customer.java]
application domain object and corresponding
[_Repository_|https://github.com/jxblum/contacts-application/blob/master/cluster-configuration-example/src/test/java/example/test/client/repo/CustomerRepository.java].
Files attached for convenience.
The test is an _Spring (Data Geode)_, Apache Geode {{ClientCache}} application
([here|https://github.com/jxblum/contacts-application/blob/master/cluster-configuration-example/src/test/java/example/test/client/repo/CustomerRepository.java])
that enables the [_Cluster Configuration
Push_|https://github.com/jxblum/contacts-application/blob/master/cluster-configuration-example/src/test/java/example/test/client/ClusterConfigurationExampleIntegrationTests.java#L81].
The test goes on to
[assert|https://github.com/jxblum/contacts-application/blob/master/cluster-configuration-example/src/test/java/example/test/client/ClusterConfigurationExampleIntegrationTests.java#L66-L78]
that data can be accessed in the "_Customers_" _Region_.
It is real simple to adjust the {{Pool}} port that the {{ClientCache}} uses to
connect to the cluster by setting both or either the
{{spring.data.gemfire.locator.host}} and/or
{{spring.data.gemfire.locator.port}} properties as System properties
([here|https://github.com/jxblum/contacts-application/blob/master/cluster-configuration-example/src/test/java/example/test/client/ClusterConfigurationExampleIntegrationTests.java#L89-L90]).
Both properties default to "localhost" and the default Locator port, "10334",
by default.
This test class, with the right dependencies should be able to be included the
Apache Geode test suite.
NOTE: the _Spring Data Geode_ dependency only need be a "test" dependency to
avoid the vicious cyclic dependency.
> Re-instate Management REST API endpoints for 'create index' and 'create
> region'
> ---
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: John Blum
>Priority: Blocker
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache
> Geode community refactored and [reduced the
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
> and by extension, the Web service endpoints to, mostly, a [single Web
> service
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
> which essentially just accepts a _Gfsh_ command string, such as `{{create
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as
> measured against [Richardson Maturity
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources
> (e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource
[jira] [Updated] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'create region'
[
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-4787:
-
Attachment: ClusterConfigurationExampleIntegrationTests.java
> Re-instate Management REST API endpoints for 'create index' and 'create
> region'
> ---
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: John Blum
>Priority: Blocker
> Attachments: ClusterConfigurationExampleIntegrationTests.java,
> Customer.java, CustomerRepository.java
>
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache
> Geode community refactored and [reduced the
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
> and by extension, the Web service endpoints to, mostly, a [single Web
> service
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
> which essentially just accepts a _Gfsh_ command string, such as `{{create
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as
> measured against [Richardson Maturity
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources
> (e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for
> _Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager
> via HTTP in order to transcend firewalls when a devops team wanted to manage
> a remote cluster deployed in a cloud environment, such as AWS or GCP. By
> using HTTP over JMX/RMI, a user would not need to punch additional holes in
> the firewall to expose the JMX/RMI port (1099) for instance.
> Still, the "intent" was never to stop at supporting just _Gfsh_, but to
> become a true REST API that can be consumed by any client (not just _Gfsh_):
> application, framework, tool, etc, regardless of language (e.g. Java, C++/C#,
> Ruby, Python, etc).
> However, the team that modified this API failed to recognize the benefit of
> this design and actually took a step backwards. The HTTP Verbs are not
> properly used. The Web service API endpoints are not resourceful, and
> imposing the _Gfsh_ DSL on clients is foolish and too restrictive.
> While, it might be argued that this was an "internal" API, technically,
> speaking, guarding classes by putting them in an "internal" package is no
> safe-guard or guarantee that could have been properly enforced using Java
> access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only
> exposing an SPI for consumption.
> The fact remains that this API was changed in an incompatible way before an
> "alternative" solution was properly introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'create region'
[
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-4787:
-
Attachment: Customer.java
> Re-instate Management REST API endpoints for 'create index' and 'create
> region'
> ---
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: John Blum
>Priority: Blocker
> Attachments: ClusterConfigurationExampleIntegrationTests.java,
> Customer.java, CustomerRepository.java
>
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache
> Geode community refactored and [reduced the
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
> and by extension, the Web service endpoints to, mostly, a [single Web
> service
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
> which essentially just accepts a _Gfsh_ command string, such as `{{create
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as
> measured against [Richardson Maturity
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources
> (e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for
> _Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager
> via HTTP in order to transcend firewalls when a devops team wanted to manage
> a remote cluster deployed in a cloud environment, such as AWS or GCP. By
> using HTTP over JMX/RMI, a user would not need to punch additional holes in
> the firewall to expose the JMX/RMI port (1099) for instance.
> Still, the "intent" was never to stop at supporting just _Gfsh_, but to
> become a true REST API that can be consumed by any client (not just _Gfsh_):
> application, framework, tool, etc, regardless of language (e.g. Java, C++/C#,
> Ruby, Python, etc).
> However, the team that modified this API failed to recognize the benefit of
> this design and actually took a step backwards. The HTTP Verbs are not
> properly used. The Web service API endpoints are not resourceful, and
> imposing the _Gfsh_ DSL on clients is foolish and too restrictive.
> While, it might be argued that this was an "internal" API, technically,
> speaking, guarding classes by putting them in an "internal" package is no
> safe-guard or guarantee that could have been properly enforced using Java
> access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only
> exposing an SPI for consumption.
> The fact remains that this API was changed in an incompatible way before an
> "alternative" solution was properly introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'create region'
[
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-4787:
-
Attachment: CustomerRepository.java
> Re-instate Management REST API endpoints for 'create index' and 'create
> region'
> ---
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: John Blum
>Priority: Blocker
> Attachments: ClusterConfigurationExampleIntegrationTests.java,
> Customer.java, CustomerRepository.java
>
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache
> Geode community refactored and [reduced the
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
> and by extension, the Web service endpoints to, mostly, a [single Web
> service
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
> which essentially just accepts a _Gfsh_ command string, such as `{{create
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as
> measured against [Richardson Maturity
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources
> (e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for
> _Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager
> via HTTP in order to transcend firewalls when a devops team wanted to manage
> a remote cluster deployed in a cloud environment, such as AWS or GCP. By
> using HTTP over JMX/RMI, a user would not need to punch additional holes in
> the firewall to expose the JMX/RMI port (1099) for instance.
> Still, the "intent" was never to stop at supporting just _Gfsh_, but to
> become a true REST API that can be consumed by any client (not just _Gfsh_):
> application, framework, tool, etc, regardless of language (e.g. Java, C++/C#,
> Ruby, Python, etc).
> However, the team that modified this API failed to recognize the benefit of
> this design and actually took a step backwards. The HTTP Verbs are not
> properly used. The Web service API endpoints are not resourceful, and
> imposing the _Gfsh_ DSL on clients is foolish and too restrictive.
> While, it might be argued that this was an "internal" API, technically,
> speaking, guarding classes by putting them in an "internal" package is no
> safe-guard or guarantee that could have been properly enforced using Java
> access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only
> exposing an SPI for consumption.
> The fact remains that this API was changed in an incompatible way before an
> "alternative" solution was properly introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'create region'
[
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-4787:
--
Labels: pull-request-available (was: )
> Re-instate Management REST API endpoints for 'create index' and 'create
> region'
> ---
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: John Blum
>Priority: Blocker
> Labels: pull-request-available
> Attachments: ClusterConfigurationExampleIntegrationTests.java,
> Customer.java, CustomerRepository.java
>
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache
> Geode community refactored and [reduced the
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
> and by extension, the Web service endpoints to, mostly, a [single Web
> service
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
> which essentially just accepts a _Gfsh_ command string, such as `{{create
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as
> measured against [Richardson Maturity
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources
> (e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for
> _Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager
> via HTTP in order to transcend firewalls when a devops team wanted to manage
> a remote cluster deployed in a cloud environment, such as AWS or GCP. By
> using HTTP over JMX/RMI, a user would not need to punch additional holes in
> the firewall to expose the JMX/RMI port (1099) for instance.
> Still, the "intent" was never to stop at supporting just _Gfsh_, but to
> become a true REST API that can be consumed by any client (not just _Gfsh_):
> application, framework, tool, etc, regardless of language (e.g. Java, C++/C#,
> Ruby, Python, etc).
> However, the team that modified this API failed to recognize the benefit of
> this design and actually took a step backwards. The HTTP Verbs are not
> properly used. The Web service API endpoints are not resourceful, and
> imposing the _Gfsh_ DSL on clients is foolish and too restrictive.
> While, it might be argued that this was an "internal" API, technically,
> speaking, guarding classes by putting them in an "internal" package is no
> safe-guard or guarantee that could have been properly enforced using Java
> access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only
> exposing an SPI for consumption.
> The fact remains that this API was changed in an incompatible way before an
> "alternative" solution was properly introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4765) Cluster configuration does not respond after locator reconnects to the distributed system
[
https://issues.apache.org/jira/browse/GEODE-4765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4765:
--
Fix Version/s: 1.6.0
> Cluster configuration does not respond after locator reconnects to the
> distributed system
> -
>
> Key: GEODE-4765
> URL: https://issues.apache.org/jira/browse/GEODE-4765
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> In the case of a reconnect event, subsequent server requests for the cluster
> configuration fail with the following error:
> {noformat}
> [info 2018/02/22 11:16:15.345 IST locator
> tid=0x94] Received request for configuration : ConfigurationRequest for
> groups :
>cluster[cluster]
> [info 2018/02/22 11:16:15.346 IST locator
> tid=0x94] grantorId=null grantor=null> has been destroyed
> org.apache.geode.distributed.LockServiceDestroyedException:
> grantorId=null grantor=null> has been destroyed
> at
> org.apache.geode.distributed.internal.locks.DLockService.generateLockServiceDestroyedException(DLockService.java:205)
> at
> org.apache.geode.distributed.internal.locks.DLockService.checkDestroyed(DLockService.java:194)
> at
> org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1242)
> at
> org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1236)
> at
> org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1231)
> at
> org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1227)
> at
> org.apache.geode.distributed.internal.ClusterConfigurationService.createConfigurationResponse(ClusterConfigurationService.java:494)
> at
> org.apache.geode.management.internal.configuration.handlers.ConfigurationRequestHandler.processRequest(ConfigurationRequestHandler.java:51)
> at
> org.apache.geode.distributed.internal.InternalLocator$PrimaryHandler.processRequest(InternalLocator.java:1251)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:434)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4765) Cluster configuration does not respond after locator reconnects to the distributed system
[
https://issues.apache.org/jira/browse/GEODE-4765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-4765.
---
Resolution: Fixed
> Cluster configuration does not respond after locator reconnects to the
> distributed system
> -
>
> Key: GEODE-4765
> URL: https://issues.apache.org/jira/browse/GEODE-4765
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> In the case of a reconnect event, subsequent server requests for the cluster
> configuration fail with the following error:
> {noformat}
> [info 2018/02/22 11:16:15.345 IST locator
> tid=0x94] Received request for configuration : ConfigurationRequest for
> groups :
>cluster[cluster]
> [info 2018/02/22 11:16:15.346 IST locator
> tid=0x94] grantorId=null grantor=null> has been destroyed
> org.apache.geode.distributed.LockServiceDestroyedException:
> grantorId=null grantor=null> has been destroyed
> at
> org.apache.geode.distributed.internal.locks.DLockService.generateLockServiceDestroyedException(DLockService.java:205)
> at
> org.apache.geode.distributed.internal.locks.DLockService.checkDestroyed(DLockService.java:194)
> at
> org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1242)
> at
> org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1236)
> at
> org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1231)
> at
> org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1227)
> at
> org.apache.geode.distributed.internal.ClusterConfigurationService.createConfigurationResponse(ClusterConfigurationService.java:494)
> at
> org.apache.geode.management.internal.configuration.handlers.ConfigurationRequestHandler.processRequest(ConfigurationRequestHandler.java:51)
> at
> org.apache.geode.distributed.internal.InternalLocator$PrimaryHandler.processRequest(InternalLocator.java:1251)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:434)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4662) Protobuf: Add GetEntryCount message
[ https://issues.apache.org/jira/browse/GEODE-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dodge resolved GEODE-4662. -- Resolution: Fixed Fix Version/s: 1.6.0 > Protobuf: Add GetEntryCount message > --- > > Key: GEODE-4662 > URL: https://issues.apache.org/jira/browse/GEODE-4662 > Project: Geode > Issue Type: New Feature > Components: client/server >Reporter: Brian Baynes >Assignee: Michael Dodge >Priority: Major > Labels: pull-request-available > Fix For: 1.6.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > As a dev using the new protocol, I need to be able to retrive the entry count > for a given region. > Add GetEntryCount message, returning the count of entries for the provided > region. Return an error if the region does not exist. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4786) Reconfigure sidenav and delete existing pages
[ https://issues.apache.org/jira/browse/GEODE-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-4786: -- Assignee: Dave Barnes > Reconfigure sidenav and delete existing pages > - > > Key: GEODE-4786 > URL: https://issues.apache.org/jira/browse/GEODE-4786 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Addison >Assignee: Dave Barnes >Priority: Major > > I propose that we start refactoring the geode native docs from a blank > canvas. This story is about deleting the existing pages and sidenav > structure and building out the docs, anew, one page at a time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'create region'
[
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388363#comment-16388363
]
John Blum edited comment on GEODE-4787 at 3/6/18 7:26 PM:
--
This *bug(!)* exists because it broke _Spring Data for Apache Geode's_ [Cluster
Configuration
Push|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config-cluster]
feature, which as we know is used by a Pivotal GemFire user when creating
_Spring Boot_ with _Spring Data GemFire_, and by extension, Pivotal GemFire,
{{ClientCache}} applications in a PCF context using PCC.
The
[implementation|https://github.com/spring-projects/spring-data-geode/blob/2.0.5.RELEASE/src/main/java/org/springframework/data/gemfire/config/admin/remote/RestHttpGemfireAdminTemplate.java]
of _Cluster Configuration Push_ was well communicated (and I thought known)
since it was discussed many times at the PCC working group meeting. It
naturally followed and used the individual Management REST-like API Web service
endpoints (e.g. {{`POST
http://localhost:8080/gemfire/v1/regions?name=Example=PARTITION`}}).
It would be unreasonable to force applications, frameworks and tools to have to
conform _Gfsh_ command syntax/DSL, for reasons that I cited above.
was (Author: jblum):
This *bug(!)* exists because it broke _Spring Data for Apache Geode's_ [Cluster
Configuration
Push|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config-cluster]
feature, which as we know is used by a Pivotal GemFire user when creating
_Spring Boot_ with _Spring Data GemFire_, and by extension, Pivotal GemFire,
{{ClientCache}} applications in a PCF context using PCC.
The
[implementation|https://github.com/spring-projects/spring-data-geode/blob/2.0.5.RELEASE/src/main/java/org/springframework/data/gemfire/config/admin/remote/RestHttpGemfireAdminTemplate.java]
of _Cluster Configuration Push_ was well communicated (and I thought known)
since it was discussed many times at the PCC working group meeting.
> Re-instate Management REST API endpoints for 'create index' and 'create
> region'
> ---
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: John Blum
>Priority: Blocker
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache
> Geode community refactored and [reduced the
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
> and by extension, the Web service endpoints to, mostly, a [single Web
> service
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
> which essentially just accepts a _Gfsh_ command string, such as `{{create
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as
> measured against [Richardson Maturity
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources
> (e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for
> _Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager
> via HTTP in order to transcend firewalls when a devops team wanted to manage
> a remote cluster deployed in a cloud environment, such as AWS or GCP. By
> using HTTP over JMX/RMI, a user would not need to punch additional holes in
> the firewall to expose the JMX/RMI port (1099)
[jira] [Updated] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'create region'
[
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-4787:
-
Flags: Important
Affects Version/s: 1.3.0
1.4.0
External issue URL: https://github.com/apache/geode/pull/1563
> Re-instate Management REST API endpoints for 'create index' and 'create
> region'
> ---
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
> Issue Type: Bug
> Components: management
>Affects Versions: 1.3.0, 1.4.0
>Reporter: John Blum
>Priority: Blocker
> Labels: pull-request-available
> Attachments: ClusterConfigurationExampleIntegrationTests.java,
> Customer.java, CustomerRepository.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache
> Geode community refactored and [reduced the
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
> and by extension, the Web service endpoints to, mostly, a [single Web
> service
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
> which essentially just accepts a _Gfsh_ command string, such as `{{create
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as
> measured against [Richardson Maturity
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources
> (e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for
> _Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager
> via HTTP in order to transcend firewalls when a devops team wanted to manage
> a remote cluster deployed in a cloud environment, such as AWS or GCP. By
> using HTTP over JMX/RMI, a user would not need to punch additional holes in
> the firewall to expose the JMX/RMI port (1099) for instance.
> Still, the "intent" was never to stop at supporting just _Gfsh_, but to
> become a true REST API that can be consumed by any client (not just _Gfsh_):
> application, framework, tool, etc, regardless of language (e.g. Java, C++/C#,
> Ruby, Python, etc).
> However, the team that modified this API failed to recognize the benefit of
> this design and actually took a step backwards. The HTTP Verbs are not
> properly used. The Web service API endpoints are not resourceful, and
> imposing the _Gfsh_ DSL on clients is foolish and too restrictive.
> While, it might be argued that this was an "internal" API, technically,
> speaking, guarding classes by putting them in an "internal" package is no
> safe-guard or guarantee that could have been properly enforced using Java
> access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only
> exposing an SPI for consumption.
> The fact remains that this API was changed in an incompatible way before an
> "alternative" solution was properly introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'create region'
[
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388437#comment-16388437
]
John Blum commented on GEODE-4787:
--
I have just built Apache Geode with my [proposed
changes|https://github.com/apache/geode/pull/1563] and ran the provided test
class. All passes.
> Re-instate Management REST API endpoints for 'create index' and 'create
> region'
> ---
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: John Blum
>Priority: Blocker
> Labels: pull-request-available
> Attachments: ClusterConfigurationExampleIntegrationTests.java,
> Customer.java, CustomerRepository.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache
> Geode community refactored and [reduced the
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
> and by extension, the Web service endpoints to, mostly, a [single Web
> service
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
> which essentially just accepts a _Gfsh_ command string, such as `{{create
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as
> measured against [Richardson Maturity
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources
> (e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for
> _Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager
> via HTTP in order to transcend firewalls when a devops team wanted to manage
> a remote cluster deployed in a cloud environment, such as AWS or GCP. By
> using HTTP over JMX/RMI, a user would not need to punch additional holes in
> the firewall to expose the JMX/RMI port (1099) for instance.
> Still, the "intent" was never to stop at supporting just _Gfsh_, but to
> become a true REST API that can be consumed by any client (not just _Gfsh_):
> application, framework, tool, etc, regardless of language (e.g. Java, C++/C#,
> Ruby, Python, etc).
> However, the team that modified this API failed to recognize the benefit of
> this design and actually took a step backwards. The HTTP Verbs are not
> properly used. The Web service API endpoints are not resourceful, and
> imposing the _Gfsh_ DSL on clients is foolish and too restrictive.
> While, it might be argued that this was an "internal" API, technically,
> speaking, guarding classes by putting them in an "internal" package is no
> safe-guard or guarantee that could have been properly enforced using Java
> access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only
> exposing an SPI for consumption.
> The fact remains that this API was changed in an incompatible way before an
> "alternative" solution was properly introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4788) parReg.execute.FunctionServiceTest.getSomeKeys failed with util.TestException: Test Issue - Got the exception
[
https://issues.apache.org/jira/browse/GEODE-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388448#comment-16388448
]
xiaojian zhou commented on GEODE-4788:
--
Root cause is:
The refactoring in GEODE-2673 changed the behavior of the test code of
getSomeKeys().
The old code will catch ForceReattemptException or PRLocallyDestroyedException,
log them and continue.
But the new code will throw RuntimeException when caught these exception.
> parReg.execute.FunctionServiceTest.getSomeKeys failed with
> util.TestException: Test Issue - Got the exception
> -
>
> Key: GEODE-4788
> URL: https://issues.apache.org/jira/browse/GEODE-4788
> Project: Geode
> Issue Type: New Feature
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
>
> {noformat}
> CLIENT
> vm_12_thr_15_accessor1_rs-FullRegression-2018-03-03-05-01-17-client-8_4804
> TASK[0]
> parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions
> ERROR util.TestException: Test Issue - Got the exception
> util.TestException: Test Issue - Got the exception
> at
> parReg.execute.FunctionServiceTest.getSomeKeys(FunctionServiceTest.java:508)
> at
> parReg.execute.FunctionServiceTest.doRandomFunctionExecutions(FunctionServiceTest.java:473)
> at
> parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions(FunctionServiceTest.java:436)
> 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 hydra.MethExecutor.execute(MethExecutor.java:181)
> at hydra.MethExecutor.execute(MethExecutor.java:149)
> at hydra.TestTask.execute(TestTask.java:192)
> at hydra.RemoteTestModule$1.run(RemoteTestModule.java:212)
> Caused by: java.lang.RuntimeException:
> org.apache.geode.internal.cache.ForceReattemptException: FetchKeysResponse
> got remote CacheClosedException; forcing reattempt.
> at
> org.apache.geode.internal.cache.PartitionedRegionGetSomeKeys.getSomeKeys(PartitionedRegionGetSomeKeys.java:74)
> at
> parReg.execute.FunctionServiceTest.getSomeKeys(FunctionServiceTest.java:502)
> ... 10 more
> Caused by: org.apache.geode.internal.cache.ForceReattemptException:
> FetchKeysResponse got remote CacheClosedException; forcing reattempt.
> at
> org.apache.geode.internal.cache.partitioned.FetchKeysMessage$FetchKeysResponse.waitForKeys(FetchKeysMessage.java:546)
> at
> org.apache.geode.internal.cache.PartitionedRegionGetSomeKeys.getSomeKeys(PartitionedRegionGetSomeKeys.java:66)
> ... 11 more
> Caused by: org.apache.geode.cache.CacheClosedException: Remote cache is
> closed:
> rs-FullRegression-2018-03-03-05-01-17-client-8(dataStoregemfire5_rs-FullRegression-2018-03-03-05-01-17-client-8_4776:4776):1031
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1588)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1576)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:304)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:448)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1118)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$8$1.run(ClusterDistributionManager.java:943)
> at java.lang.Thread.run(Thread.java:748)
>
> CLIENT
> vm_15_thr_29_accessor4_rs-FullRegression-2018-03-03-05-01-17-client-8_4918
> TASK[0]
> parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions
> ERROR util.TestException: Test Issue - Got the exception
> util.TestException: Test Issue - Got the exception
> at
> parReg.execute.FunctionServiceTest.getSomeKeys(FunctionServiceTest.java:508)
> at
> parReg.execute.FunctionServiceTest.doRandomFunctionExecutions(FunctionServiceTest.java:473)
> at
> parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions(FunctionServiceTest.java:436)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
[jira] [Assigned] (GEODE-4679) pdxReadSerialized accessors must be present in some product level component like Cache
[ https://issues.apache.org/jira/browse/GEODE-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-4679: Assignee: Udo Kohlmeyer > pdxReadSerialized accessors must be present in some product level component > like Cache > -- > > Key: GEODE-4679 > URL: https://issues.apache.org/jira/browse/GEODE-4679 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > > +*Current situation:*+ > The getters/setters for pdxReadSerialized thread is present in DefaultQuery > as static calls. > * DefaultQuery # getPdxReadSerialized() > * DefaultQuery # setPdxReadSerialized() > > +*Solution:*+ > These getters/setters need to move to a more logical part of the code like > cache and not be present in DeafaultQuery > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4730) Remove DLock acquisition timeouts in ClusterConfigurationService.createConfigurationResponse
[ https://issues.apache.org/jira/browse/GEODE-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-4730: -- Fix Version/s: 1.6.0 > Remove DLock acquisition timeouts in > ClusterConfigurationService.createConfigurationResponse > > > Key: GEODE-4730 > URL: https://issues.apache.org/jira/browse/GEODE-4730 > Project: Geode > Issue Type: Improvement > Components: configuration >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.6.0 > > > Reviewing some of this code with [~upthewaterspout] it seems like it would be > worse if the lock acquisition fails and an empty response is returned vs. a > hang/deadlock happening on server startup. > At least if there's a hang we'd know it as opposed to a server starting up > without any configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4730) Remove DLock acquisition timeouts in ClusterConfigurationService.createConfigurationResponse
[ https://issues.apache.org/jira/browse/GEODE-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-4730. --- Resolution: Fixed > Remove DLock acquisition timeouts in > ClusterConfigurationService.createConfigurationResponse > > > Key: GEODE-4730 > URL: https://issues.apache.org/jira/browse/GEODE-4730 > Project: Geode > Issue Type: Improvement > Components: configuration >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.6.0 > > > Reviewing some of this code with [~upthewaterspout] it seems like it would be > worse if the lock acquisition fails and an empty response is returned vs. a > hang/deadlock happening on server startup. > At least if there's a hang we'd know it as opposed to a server starting up > without any configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4774) When starting second locator without Security Manager, displaying incorrect status message
[
https://issues.apache.org/jira/browse/GEODE-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-4774.
---
Resolution: Cannot Reproduce
Tried to reproduce on develop on 3/6/18 to update the text for clearer
description and cannot reproduce anymore. Closing for now unless it comes back
up again.
> When starting second locator without Security Manager, displaying incorrect
> status message
> --
>
> Key: GEODE-4774
> URL: https://issues.apache.org/jira/browse/GEODE-4774
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Barbara Pruijn
>Priority: Major
>
> When I start a second locator without a Security Manager (inside a gfsh
> shell), I get the following output:
> {code:java}
> Security Manager is enabled - unable to auto-connect. Please use "connect
> --locator=10.118.19.11[13489]" to connect Gfsh to the locator.{code}
> However, the output should state:
> {code:java}
> Cluster configuration service is up and running.{code}
> How to reproduce:
> {code:java}
> gfsh> start locator --name=locator1
> gfsh> start locator --name=locator2 --port=13489
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-4115) Remove nullability of InternalLocator.myDS
[
https://issues.apache.org/jira/browse/GEODE-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dodge reassigned GEODE-4115:
Assignee: (was: Michael Dodge)
> Remove nullability of InternalLocator.myDS
> --
>
> Key: GEODE-4115
> URL: https://issues.apache.org/jira/browse/GEODE-4115
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Galen O'Sullivan
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> /**
>* The distributed system owned by this locator, if any. Note that if a ds
> already exists because
>* the locator is being colocated in a normal member this field will be
> null.
>*/
> private InternalDistributedSystem myDs;
> {code}
> I don't think that this should be nullable. It makes things more complicated
> -- when we start a colocated locator, the protobuf protocol statistics
> initialization has to check {{InternalDistributedSystem.getAnyInstance()}} to
> get a DS. Can that call be null? I'm not sure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'create region'
[
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388363#comment-16388363
]
John Blum edited comment on GEODE-4787 at 3/6/18 7:22 PM:
--
This *bug(!)* exists because it broke _Spring Data for Apache Geode's_ [Cluster
Configuration
Push|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config-cluster]
feature, which as we know is used by a Pivotal GemFire user when creating
_Spring Boot_ with _Spring Data GemFire_, and by extension, Pivotal GemFire,
{{ClientCache}} applications in a PCF context using PCC.
The
[implementation|https://github.com/spring-projects/spring-data-geode/blob/2.0.5.RELEASE/src/main/java/org/springframework/data/gemfire/config/admin/remote/RestHttpGemfireAdminTemplate.java]
of _Cluster Configuration Push_ was well communicated (and I thought known)
since it was discussed many times at the PCC working group meeting.
was (Author: jblum):
This *bug(!)* exists because it broke _Spring Data for Apache Geode's_ [Cluster
Configuration
Push|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config-cluster]
feature, which as we know is used by Pivotal GemFire user when creating
_Spring Boot_ with _Spring Data GemFire_, and by extension, Pivotal GemFire,
{{ClientCache}} applications in a PCF when using PCC.
The
[implementation|https://github.com/spring-projects/spring-data-geode/blob/2.0.5.RELEASE/src/main/java/org/springframework/data/gemfire/config/admin/remote/RestHttpGemfireAdminTemplate.java]
of _Cluster Configuration Push_ was well communicated (and I thought known)
since it was discussed many times at the PCC working group meeting.
> Re-instate Management REST API endpoints for 'create index' and 'create
> region'
> ---
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: John Blum
>Priority: Blocker
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache
> Geode community refactored and [reduced the
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
> and by extension, the Web service endpoints to, mostly, a [single Web
> service
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
> which essentially just accepts a _Gfsh_ command string, such as `{{create
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as
> measured against [Richardson Maturity
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources
> (e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for
> _Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager
> via HTTP in order to transcend firewalls when a devops team wanted to manage
> a remote cluster deployed in a cloud environment, such as AWS or GCP. By
> using HTTP over JMX/RMI, a user would not need to punch additional holes in
> the firewall to expose the JMX/RMI port (1099) for instance.
> Still, the "intent" was never to stop at supporting just _Gfsh_, but to
> become a true REST API that can be consumed by any client (not just _Gfsh_):
> application, framework, tool, etc, regardless of language (e.g. Java, C++/C#,
> Ruby, Python, etc).
> However, the team that modified this API failed to recognize
[jira] [Created] (GEODE-4788) parReg.execute.FunctionServiceTest.getSomeKeys failed with util.TestException: Test Issue - Got the exception
xiaojian zhou created GEODE-4788:
Summary: parReg.execute.FunctionServiceTest.getSomeKeys failed
with util.TestException: Test Issue - Got the exception
Key: GEODE-4788
URL: https://issues.apache.org/jira/browse/GEODE-4788
Project: Geode
Issue Type: New Feature
Reporter: xiaojian zhou
{noformat}
CLIENT
vm_12_thr_15_accessor1_rs-FullRegression-2018-03-03-05-01-17-client-8_4804
TASK[0] parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions
ERROR util.TestException: Test Issue - Got the exception
util.TestException: Test Issue - Got the exception
at parReg.execute.FunctionServiceTest.getSomeKeys(FunctionServiceTest.java:508)
at
parReg.execute.FunctionServiceTest.doRandomFunctionExecutions(FunctionServiceTest.java:473)
at
parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions(FunctionServiceTest.java:436)
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 hydra.MethExecutor.execute(MethExecutor.java:181)
at hydra.MethExecutor.execute(MethExecutor.java:149)
at hydra.TestTask.execute(TestTask.java:192)
at hydra.RemoteTestModule$1.run(RemoteTestModule.java:212)
Caused by: java.lang.RuntimeException:
org.apache.geode.internal.cache.ForceReattemptException: FetchKeysResponse got
remote CacheClosedException; forcing reattempt.
at
org.apache.geode.internal.cache.PartitionedRegionGetSomeKeys.getSomeKeys(PartitionedRegionGetSomeKeys.java:74)
at parReg.execute.FunctionServiceTest.getSomeKeys(FunctionServiceTest.java:502)
... 10 more
Caused by: org.apache.geode.internal.cache.ForceReattemptException:
FetchKeysResponse got remote CacheClosedException; forcing reattempt.
at
org.apache.geode.internal.cache.partitioned.FetchKeysMessage$FetchKeysResponse.waitForKeys(FetchKeysMessage.java:546)
at
org.apache.geode.internal.cache.PartitionedRegionGetSomeKeys.getSomeKeys(PartitionedRegionGetSomeKeys.java:66)
... 11 more
Caused by: org.apache.geode.cache.CacheClosedException: Remote cache is closed:
rs-FullRegression-2018-03-03-05-01-17-client-8(dataStoregemfire5_rs-FullRegression-2018-03-03-05-01-17-client-8_4776:4776):1031
at
org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1588)
at
org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1576)
at
org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:304)
at
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
at
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:448)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1118)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
at
org.apache.geode.distributed.internal.ClusterDistributionManager$8$1.run(ClusterDistributionManager.java:943)
at java.lang.Thread.run(Thread.java:748)
CLIENT
vm_15_thr_29_accessor4_rs-FullRegression-2018-03-03-05-01-17-client-8_4918
TASK[0] parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions
ERROR util.TestException: Test Issue - Got the exception
util.TestException: Test Issue - Got the exception
at parReg.execute.FunctionServiceTest.getSomeKeys(FunctionServiceTest.java:508)
at
parReg.execute.FunctionServiceTest.doRandomFunctionExecutions(FunctionServiceTest.java:473)
at
parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions(FunctionServiceTest.java:436)
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 hydra.MethExecutor.execute(MethExecutor.java:{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'created region'.
John Blum created GEODE-4787:
Summary: Re-instate Management REST API endpoints for 'create
index' and 'created region'.
Key: GEODE-4787
URL: https://issues.apache.org/jira/browse/GEODE-4787
Project: Geode
Issue Type: Bug
Components: gfsh, management
Reporter: John Blum
As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper (REST-like)
Web service endpoints for the Geode's Management functionality.
This primarily concerns the Management (REST-like) Web service API in
{{org.apache.geode.management.internal.web.controllers}}, which in Apache Geode
1.2.1 and earlier, consisted of the following [Spring Web MVC
Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache Geode
community refactored and [reduced the
Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
and by extension, the Web service endpoints to, mostly, a [single Web service
endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
which essentially just accepts a _Gfsh_ command string, such as `{{create
region --name=Example --type=PARTITION}}`.
This is an significant *anti-pattern* to be sure nor is it consistent with
good/proper Web service/general API design, much less REST-ful design.
While this Management REST-like API was not a "complete" REST API design, as
measured against [Richardson Maturity
Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
consist of elements in both Levels 1 and 2.
For instance, it used proper URLs and URIs to identify and access resources
(e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
affect (e.g. CRUD) the resources.
Essentially, it only needed proper Resource abstractions representing the
different resources (e.g. Regions, Indexes, etc) along with Hypermedia Controls
to move beyond being a specific interface for _Gfsh_.
The intent was never to make the Management REST API a specific extension for
_Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager via
HTTP in order to transcend firewalls when a devops team wanted to manage a
remote cluster deployed in a cloud environment, such as AWS or GCP. By using
HTTP over JMX/RMI, a user would not need to punch additional holes in the
firewall to expose the JMX/RMI port (1099) for instance.
Still, the "intent" was never to stop at supporting just _Gfsh_, but to become
a true REST API that can be consumed by any client (not just _Gfsh_):
application, framework, tool, etc, regardless of language (e.g. Java, C++/C#,
Ruby, Python, etc).
However, the team that modified this API failed to recognize the benefit of
this design and actually took a step backwards. The HTTP Verbs are not
properly used. The Web service API endpoints are not resourceful, and imposing
the _Gfsh_ DSL on clients is foolish and too restrictive.
While, it might be argued that this was an "internal" API, technically,
speaking, guarding classes by putting them in an "internal" package is no
safe-guard or guarantee that could have been properly enforced using Java
access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only
exposing an SPI for consumption.
The fact remains that this API was changed in an incompatible way before an
"alternative" solution was properly introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'create region'
[
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388363#comment-16388363
]
John Blum commented on GEODE-4787:
--
This *bug(!)* exists because it broke _Spring Data for Apache Geode's_ [Cluster
Configuration
Push|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config-cluster]
feature, which as we know is used by Pivotal GemFire user when creating
_Spring Boot_ with _Spring Data GemFire_, and by extension, Pivotal GemFire,
{{ClientCache}} applications in a PCF when using PCC.
The
[implementation|https://github.com/spring-projects/spring-data-geode/blob/2.0.5.RELEASE/src/main/java/org/springframework/data/gemfire/config/admin/remote/RestHttpGemfireAdminTemplate.java]
of _Cluster Configuration Push_ was well communicated (and I thought known)
since it was discussed many times at the PCC working group meeting.
> Re-instate Management REST API endpoints for 'create index' and 'create
> region'
> ---
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: John Blum
>Priority: Blocker
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache
> Geode community refactored and [reduced the
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
> and by extension, the Web service endpoints to, mostly, a [single Web
> service
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
> which essentially just accepts a _Gfsh_ command string, such as `{{create
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as
> measured against [Richardson Maturity
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources
> (e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for
> _Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager
> via HTTP in order to transcend firewalls when a devops team wanted to manage
> a remote cluster deployed in a cloud environment, such as AWS or GCP. By
> using HTTP over JMX/RMI, a user would not need to punch additional holes in
> the firewall to expose the JMX/RMI port (1099) for instance.
> Still, the "intent" was never to stop at supporting just _Gfsh_, but to
> become a true REST API that can be consumed by any client (not just _Gfsh_):
> application, framework, tool, etc, regardless of language (e.g. Java, C++/C#,
> Ruby, Python, etc).
> However, the team that modified this API failed to recognize the benefit of
> this design and actually took a step backwards. The HTTP Verbs are not
> properly used. The Web service API endpoints are not resourceful, and
> imposing the _Gfsh_ DSL on clients is foolish and too restrictive.
> While, it might be argued that this was an "internal" API, technically,
> speaking, guarding classes by putting them in an "internal" package is no
> safe-guard or guarantee that could have been properly enforced using Java
> access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only
> exposing an SPI for consumption.
> The fact remains that this API was changed in an incompatible way before an
> "alternative" solution was properly introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4770) Destroying an unstarted GatewayReceiver throws an NPE
[
https://issues.apache.org/jira/browse/GEODE-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388609#comment-16388609
]
Kenneth Howe commented on GEODE-4770:
-
No. I found this while developing a new command that calls
GatewayReceiver.destroy(). The new command is not yet checked in.
> Destroying an unstarted GatewayReceiver throws an NPE
> -
>
> Key: GEODE-4770
> URL: https://issues.apache.org/jira/browse/GEODE-4770
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.5.0
>Reporter: Kenneth Howe
>Assignee: Jason Huynh
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Found while writing tests for a new Gfsh command to destroy a GatewayReceiver:
> Create a GatewayReceiver with manualStart = true
> {{create gateway-receiver --manual-start==true ...}}
> NPE is thrown by the {{destroy()}} in the Function that implements the new
> {{destroy gateway-receiver}} command.
> {code:java}
> if (receiver.isRunning()) {
> receiver.stop();
> }
> receiver.destroy();
> {code}
> NPE is thrown here:
> {code:java|title=GatewayReceiverImpl}
> public void destroy() {
> if (receiver.isRunning()) {
> {code}
> because {{receiver}} is not set until the the GatewayReceiver is started.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-4770) Destroying an unstarted GatewayReceiver throws an NPE
[
https://issues.apache.org/jira/browse/GEODE-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-4770:
---
Assignee: Kenneth Howe (was: Jason Huynh)
> Destroying an unstarted GatewayReceiver throws an NPE
> -
>
> Key: GEODE-4770
> URL: https://issues.apache.org/jira/browse/GEODE-4770
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.5.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Found while writing tests for a new Gfsh command to destroy a GatewayReceiver:
> Create a GatewayReceiver with manualStart = true
> {{create gateway-receiver --manual-start==true ...}}
> NPE is thrown by the {{destroy()}} in the Function that implements the new
> {{destroy gateway-receiver}} command.
> {code:java}
> if (receiver.isRunning()) {
> receiver.stop();
> }
> receiver.destroy();
> {code}
> NPE is thrown here:
> {code:java|title=GatewayReceiverImpl}
> public void destroy() {
> if (receiver.isRunning()) {
> {code}
> because {{receiver}} is not set until the the GatewayReceiver is started.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4776) Migrate to chrome driver for Pulse UI Tests
[ https://issues.apache.org/jira/browse/GEODE-4776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Boorlagadda resolved GEODE-4776. Resolution: Fixed Fix Version/s: 1.6.0 > Migrate to chrome driver for Pulse UI Tests > --- > > Key: GEODE-4776 > URL: https://issues.apache.org/jira/browse/GEODE-4776 > Project: Geode > Issue Type: Improvement > Components: pulse >Reporter: Sai Boorlagadda >Assignee: Sai Boorlagadda >Priority: Major > Labels: pull-request-available > Fix For: 1.6.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > * Migrate to use chrome web driver > * Remove unused mock implementations on Pulse UI tests > * Fix any failing tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4776) Migrate to chrome driver for Pulse UI Tests
[ https://issues.apache.org/jira/browse/GEODE-4776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Boorlagadda closed GEODE-4776. -- > Migrate to chrome driver for Pulse UI Tests > --- > > Key: GEODE-4776 > URL: https://issues.apache.org/jira/browse/GEODE-4776 > Project: Geode > Issue Type: Improvement > Components: pulse >Reporter: Sai Boorlagadda >Assignee: Sai Boorlagadda >Priority: Major > Labels: pull-request-available > Fix For: 1.6.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > * Migrate to use chrome web driver > * Remove unused mock implementations on Pulse UI tests > * Fix any failing tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4217) gfsh create jdbc-connection command allows a password to be set without a user name
[ https://issues.apache.org/jira/browse/GEODE-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Reich reassigned GEODE-4217: - Assignee: Nick Reich (was: Kirk Lund) > gfsh create jdbc-connection command allows a password to be set without a > user name > > > Key: GEODE-4217 > URL: https://issues.apache.org/jira/browse/GEODE-4217 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Darrel Schneider >Assignee: Nick Reich >Priority: Major > > The gfsh create jdbc-connection command allows a password to be set without > a user name. > If you configure a password you must also configure a user name and this > should be validated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4217) gfsh create jdbc-connection command allows a password to be set without a user name
[ https://issues.apache.org/jira/browse/GEODE-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4217: -- Labels: pull-request-available (was: ) > gfsh create jdbc-connection command allows a password to be set without a > user name > > > Key: GEODE-4217 > URL: https://issues.apache.org/jira/browse/GEODE-4217 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Darrel Schneider >Assignee: Nick Reich >Priority: Major > Labels: pull-request-available > > The gfsh create jdbc-connection command allows a password to be set without > a user name. > If you configure a password you must also configure a user name and this > should be validated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4770) Destroying an unstarted GatewayReceiver throws an NPE
[
https://issues.apache.org/jira/browse/GEODE-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388597#comment-16388597
]
Diane Hardman commented on GEODE-4770:
--
Ken,
Is this fix needed in the Geode 1.5.0 release branch?
> Destroying an unstarted GatewayReceiver throws an NPE
> -
>
> Key: GEODE-4770
> URL: https://issues.apache.org/jira/browse/GEODE-4770
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.5.0
>Reporter: Kenneth Howe
>Assignee: Jason Huynh
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Found while writing tests for a new Gfsh command to destroy a GatewayReceiver:
> Create a GatewayReceiver with manualStart = true
> {{create gateway-receiver --manual-start==true ...}}
> NPE is thrown by the {{destroy()}} in the Function that implements the new
> {{destroy gateway-receiver}} command.
> {code:java}
> if (receiver.isRunning()) {
> receiver.stop();
> }
> receiver.destroy();
> {code}
> NPE is thrown here:
> {code:java|title=GatewayReceiverImpl}
> public void destroy() {
> if (receiver.isRunning()) {
> {code}
> because {{receiver}} is not set until the the GatewayReceiver is started.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-4789) Update system-rules dependency from 1.16.1 to 1.17.1
[ https://issues.apache.org/jira/browse/GEODE-4789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-4789: Assignee: Kirk Lund > Update system-rules dependency from 1.16.1 to 1.17.1 > > > Key: GEODE-4789 > URL: https://issues.apache.org/jira/browse/GEODE-4789 > Project: Geode > Issue Type: Improvement > Components: build, tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > com.github.stefanbirkner:system-rules releases are now up to 1.17.1. We > should update our dependency from 1.16.1 to 1.17.1. > System-Rules is a library of JUnit Rules used in UnitTests, IntegrationTests > and DistributedTests for controlling System properties, stdout, stderr, etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4789) Update system-rules dependency from 1.16.1 to 1.17.1
Kirk Lund created GEODE-4789: Summary: Update system-rules dependency from 1.16.1 to 1.17.1 Key: GEODE-4789 URL: https://issues.apache.org/jira/browse/GEODE-4789 Project: Geode Issue Type: Improvement Components: build, tests Reporter: Kirk Lund com.github.stefanbirkner:system-rules releases are now up to 1.17.1. We should update our dependency from 1.16.1 to 1.17.1. System-Rules is a library of JUnit Rules used in UnitTests, IntegrationTests and DistributedTests for controlling System properties, stdout, stderr, etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4408) ChacheableKeys.hpp provides incorrect hashcode functions.
[ https://issues.apache.org/jira/browse/GEODE-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Addison resolved GEODE-4408. Resolution: Fixed > ChacheableKeys.hpp provides incorrect hashcode functions. > - > > Key: GEODE-4408 > URL: https://issues.apache.org/jira/browse/GEODE-4408 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob S. Barrett >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > ChacheableKeys.hpp provides incorrect hashcode functions returning uint32_t. > Used mostly internally. Consider removing or moving internal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4751) Add function execution to Protobuf driver
[ https://issues.apache.org/jira/browse/GEODE-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dodge reassigned GEODE-4751: Assignee: Michael Dodge > Add function execution to Protobuf driver > - > > Key: GEODE-4751 > URL: https://issues.apache.org/jira/browse/GEODE-4751 > Project: Geode > Issue Type: New Feature > Components: client/server >Reporter: Bruce Schuchardt >Assignee: Michael Dodge >Priority: Major > > The experimental protobuf driver needs to have function execution added to > its API. > executeFunctionOnServer(s) and executeFunctionOnGroup(s) > The functionality has already been implemented in the server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4792) ArgumentRedactor regex should be rewritten to be more clear.
Patrick Rhomberg created GEODE-4792: --- Summary: ArgumentRedactor regex should be rewritten to be more clear. Key: GEODE-4792 URL: https://issues.apache.org/jira/browse/GEODE-4792 Project: Geode Issue Type: Improvement Reporter: Patrick Rhomberg -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4770) Destroying an unstarted GatewayReceiver throws an NPE
[
https://issues.apache.org/jira/browse/GEODE-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-4770:
---
Assignee: Jason Huynh (was: Kenneth Howe)
> Destroying an unstarted GatewayReceiver throws an NPE
> -
>
> Key: GEODE-4770
> URL: https://issues.apache.org/jira/browse/GEODE-4770
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.5.0
>Reporter: Kenneth Howe
>Assignee: Jason Huynh
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Found while writing tests for a new Gfsh command to destroy a GatewayReceiver:
> Create a GatewayReceiver with manualStart = true
> {{create gateway-receiver --manual-start==true ...}}
> NPE is thrown by the {{destroy()}} in the Function that implements the new
> {{destroy gateway-receiver}} command.
> {code:java}
> if (receiver.isRunning()) {
> receiver.stop();
> }
> receiver.destroy();
> {code}
> NPE is thrown here:
> {code:java|title=GatewayReceiverImpl}
> public void destroy() {
> if (receiver.isRunning()) {
> {code}
> because {{receiver}} is not set until the the GatewayReceiver is started.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-4791) Increase gradle version from 3.5.1 to 4.51
[ https://issues.apache.org/jira/browse/GEODE-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-4791: Assignee: Udo Kohlmeyer > Increase gradle version from 3.5.1 to 4.51 > -- > > Key: GEODE-4791 > URL: https://issues.apache.org/jira/browse/GEODE-4791 > Project: Geode > Issue Type: Improvement > Components: build, general >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4792) ArgumentRedactor regex should be rewritten to be more clear.
[ https://issues.apache.org/jira/browse/GEODE-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-4792: --- Assignee: Patrick Rhomberg > ArgumentRedactor regex should be rewritten to be more clear. > > > Key: GEODE-4792 > URL: https://issues.apache.org/jira/browse/GEODE-4792 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4792) ArgumentRedactor regex should be rewritten to be more clear.
[ https://issues.apache.org/jira/browse/GEODE-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg updated GEODE-4792: Description: Even though I wrote it and it has a lot of comments, it's still hard to read the ArgumentRedactor's regex. It should be broken apart for better readability. > ArgumentRedactor regex should be rewritten to be more clear. > > > Key: GEODE-4792 > URL: https://issues.apache.org/jira/browse/GEODE-4792 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > > Even though I wrote it and it has a lot of comments, it's still hard to read > the ArgumentRedactor's regex. It should be broken apart for better > readability. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4750) Add finer grained security to OQL queries with protobuf
[ https://issues.apache.org/jira/browse/GEODE-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4750: -- Labels: pull-request-available (was: ) > Add finer grained security to OQL queries with protobuf > --- > > Key: GEODE-4750 > URL: https://issues.apache.org/jira/browse/GEODE-4750 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Dan Smith >Priority: Major > Labels: pull-request-available > > After GEODE-3126 and GEODE-4406 are implemented, we should update the > OqlOperationHandler to allow queries if the user has access to the individual > regions. Currently the changes for GEODE-3126 are validating that the user > has DATA:READ access for all regions in order to do a query. > The QueryCommand class has an example of how to validate the regions involved > in the query. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4384) gfsh command to destroy jndi binding
[
https://issues.apache.org/jira/browse/GEODE-4384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-4384:
--
Labels: pull-request-available (was: )
> gfsh command to destroy jndi binding
>
>
> Key: GEODE-4384
> URL: https://issues.apache.org/jira/browse/GEODE-4384
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Barbara Pruijn
>Priority: Major
> Labels: pull-request-available
>
> In cache.xml user can specify jndi binding like so:
> {code:java}
>
> jdbc-driver-class="org.postgresql.Driver" user-name="gpadmin"
> password="changeme"
> connection-url="jdbc:postgresql://localhost:5432/gemfire_db">
>
>
> {code}
> A user should be able to delete a datasource using the gfsh command {{destroy
> jndi-binding --name=jndi-binding-name}}
> Then the datasource will be deleted from the cluster and the binding will be
> deleted without the user having to restart the existing server(s).
> Please look at Geode's schema for a list of attributes that can be set:
> [https://github.com/apache/geode-site/blob/master/website/content/schema/cache/cache-1.0.xsd#L1331]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4790) Access violation exception when setting cache-xml-file on cache factory
Ryan McMahon created GEODE-4790:
---
Summary: Access violation exception when setting cache-xml-file on
cache factory
Key: GEODE-4790
URL: https://issues.apache.org/jira/browse/GEODE-4790
Project: Geode
Issue Type: Bug
Components: native client
Reporter: Ryan McMahon
When using the latest geode-native, the following code results in an access
violation exception. This appears to be a regression as the same code worked
in 9.2 and prior.
{code:java}
var cache = new CacheFactory()
.Set("cache-xml-file", somePath)
.Create();
var region = cache.GetRegion(someRegionName);
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4775) Apply ArgumentRedactor to JVM arguments.
[ https://issues.apache.org/jira/browse/GEODE-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-4775. - Resolution: Fixed > Apply ArgumentRedactor to JVM arguments. > > > Key: GEODE-4775 > URL: https://issues.apache.org/jira/browse/GEODE-4775 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4791) Increase gradle version from 3.5.1 to 4.51
Udo Kohlmeyer created GEODE-4791: Summary: Increase gradle version from 3.5.1 to 4.51 Key: GEODE-4791 URL: https://issues.apache.org/jira/browse/GEODE-4791 Project: Geode Issue Type: Improvement Components: build, general Reporter: Udo Kohlmeyer -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4791) Increase gradle version from 3.5.1 to 4.51
[ https://issues.apache.org/jira/browse/GEODE-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4791: -- Labels: pull-request-available (was: ) > Increase gradle version from 3.5.1 to 4.51 > -- > > Key: GEODE-4791 > URL: https://issues.apache.org/jira/browse/GEODE-4791 > Project: Geode > Issue Type: Improvement > Components: build, general >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4777) Add UITest job to concourse develop pipeline
[ https://issues.apache.org/jira/browse/GEODE-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Boorlagadda closed GEODE-4777. -- > Add UITest job to concourse develop pipeline > > > Key: GEODE-4777 > URL: https://issues.apache.org/jira/browse/GEODE-4777 > Project: Geode > Issue Type: Task > Components: ci, pulse >Reporter: Sai Boorlagadda >Assignee: Sai Boorlagadda >Priority: Major > Labels: pull-request-available > Fix For: 1.6.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Add a UITest job to concourse develop pipeline to run `gradlew uiTest` to run > selenium tests as part of the CI pipeline. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4685) Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal
[ https://issues.apache.org/jira/browse/GEODE-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4685: -- Labels: pull-request-available (was: ) > Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal > -- > > Key: GEODE-4685 > URL: https://issues.apache.org/jira/browse/GEODE-4685 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Replace with the solution from GEODE-4679 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4788) parReg.execute.FunctionServiceTest.getSomeKeys failed with util.TestException: Test Issue - Got the exception
[
https://issues.apache.org/jira/browse/GEODE-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16389157#comment-16389157
]
xiaojian zhou commented on GEODE-4788:
--
fixed in revision
378d97aed9f23c237b9616c78e17bdb1fea2c21f
> parReg.execute.FunctionServiceTest.getSomeKeys failed with
> util.TestException: Test Issue - Got the exception
> -
>
> Key: GEODE-4788
> URL: https://issues.apache.org/jira/browse/GEODE-4788
> Project: Geode
> Issue Type: New Feature
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> CLIENT
> vm_12_thr_15_accessor1_rs-FullRegression-2018-03-03-05-01-17-client-8_4804
> TASK[0]
> parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions
> ERROR util.TestException: Test Issue - Got the exception
> util.TestException: Test Issue - Got the exception
> at
> parReg.execute.FunctionServiceTest.getSomeKeys(FunctionServiceTest.java:508)
> at
> parReg.execute.FunctionServiceTest.doRandomFunctionExecutions(FunctionServiceTest.java:473)
> at
> parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions(FunctionServiceTest.java:436)
> 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 hydra.MethExecutor.execute(MethExecutor.java:181)
> at hydra.MethExecutor.execute(MethExecutor.java:149)
> at hydra.TestTask.execute(TestTask.java:192)
> at hydra.RemoteTestModule$1.run(RemoteTestModule.java:212)
> Caused by: java.lang.RuntimeException:
> org.apache.geode.internal.cache.ForceReattemptException: FetchKeysResponse
> got remote CacheClosedException; forcing reattempt.
> at
> org.apache.geode.internal.cache.PartitionedRegionGetSomeKeys.getSomeKeys(PartitionedRegionGetSomeKeys.java:74)
> at
> parReg.execute.FunctionServiceTest.getSomeKeys(FunctionServiceTest.java:502)
> ... 10 more
> Caused by: org.apache.geode.internal.cache.ForceReattemptException:
> FetchKeysResponse got remote CacheClosedException; forcing reattempt.
> at
> org.apache.geode.internal.cache.partitioned.FetchKeysMessage$FetchKeysResponse.waitForKeys(FetchKeysMessage.java:546)
> at
> org.apache.geode.internal.cache.PartitionedRegionGetSomeKeys.getSomeKeys(PartitionedRegionGetSomeKeys.java:66)
> ... 11 more
> Caused by: org.apache.geode.cache.CacheClosedException: Remote cache is
> closed:
> rs-FullRegression-2018-03-03-05-01-17-client-8(dataStoregemfire5_rs-FullRegression-2018-03-03-05-01-17-client-8_4776:4776):1031
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1588)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1576)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:304)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:448)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1118)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$8$1.run(ClusterDistributionManager.java:943)
> at java.lang.Thread.run(Thread.java:748)
>
> CLIENT
> vm_15_thr_29_accessor4_rs-FullRegression-2018-03-03-05-01-17-client-8_4918
> TASK[0]
> parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions
> ERROR util.TestException: Test Issue - Got the exception
> util.TestException: Test Issue - Got the exception
> at
> parReg.execute.FunctionServiceTest.getSomeKeys(FunctionServiceTest.java:508)
> at
> parReg.execute.FunctionServiceTest.doRandomFunctionExecutions(FunctionServiceTest.java:473)
> at
> parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions(FunctionServiceTest.java:436)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Assigned] (GEODE-4793) DUnit tests fail on Windows
[
https://issues.apache.org/jira/browse/GEODE-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-4793:
-
Assignee: Jens Deppe
> DUnit tests fail on Windows
> ---
>
> Key: GEODE-4793
> URL: https://issues.apache.org/jira/browse/GEODE-4793
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> Various tests will fail on Windows with errors similar to the following:
> {noformat}
> [vm0] [error 2018/03/07 04:38:13.670 UTC Connection(1)-10.32.110.121> tid=19] Error occurred while initializing
> cluster configuration
> [vm0] java.lang.RuntimeException: Error occurred while initializing cluster
> configuration
> [vm0] at
> org.apache.geode.distributed.internal.ClusterConfigurationService.getConfigurationRegion(ClusterConfigurationService.java:731)
> [vm0] at
> org.apache.geode.distributed.internal.ClusterConfigurationService.initSharedConfiguration(ClusterConfigurationService.java:459)
> [vm0] at
> org.apache.geode.distributed.internal.InternalLocator.startSharedConfigurationService(InternalLocator.java:1332)
> [vm0] at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:668)
> [vm0] at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:647)
> [vm0] at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:309)
> [vm0] at
> org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
> [vm0] at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
> [vm0] at
> org.apache.geode.test.junit.rules.LocatorStarterRule.startLocator(LocatorStarterRule.java:78)
> [vm0] at
> org.apache.geode.test.junit.rules.LocatorStarterRule.before(LocatorStarterRule.java:59)
> [vm0] at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.lambda$startLocatorVM$1c67b668$1(ClusterStartupRule.java:157)
> [vm0] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm0] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm0] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm0] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm0] at hydra.MethExecutor.executeObject(MethExecutor.java:244)
> [vm0] at
> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:70)
> [vm0] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm0] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm0] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm0] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm0] at
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:361)
> [vm0] at sun.rmi.transport.Transport$1.run(Transport.java:200)
> [vm0] at sun.rmi.transport.Transport$1.run(Transport.java:197)
> [vm0] at java.security.AccessController.doPrivileged(Native Method)
> [vm0] at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> [vm0] at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> [vm0] at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> [vm0] at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> [vm0] at java.security.AccessController.doPrivileged(Native Method)
> [vm0] at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> [vm0] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [vm0] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [vm0] at java.lang.Thread.run(Thread.java:748)
> [vm0] Caused by: java.io.IOException: Cannot create directory at
> C:\Users\Administrator\geode\geode-core\dunit\vm0\ConfigDiskDir_locator-0
> [vm0] at
> org.apache.geode.distributed.internal.ClusterConfigurationService.getConfigurationRegion(ClusterConfigurationService.java:699)
> [vm0] ... 33 more
> {noformat}
> The problem boils down to the use of `Files.list` which sometimes will hold
> open a directory and prevent its cleanup between tests.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4793) DUnit tests fail on Windows
Jens Deppe created GEODE-4793:
-
Summary: DUnit tests fail on Windows
Key: GEODE-4793
URL: https://issues.apache.org/jira/browse/GEODE-4793
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Jens Deppe
Various tests will fail on Windows with errors similar to the following:
{noformat}
[vm0] [error 2018/03/07 04:38:13.670 UTC
tid=19] Error occurred while initializing cluster configuration
[vm0] java.lang.RuntimeException: Error occurred while initializing cluster
configuration
[vm0] at
org.apache.geode.distributed.internal.ClusterConfigurationService.getConfigurationRegion(ClusterConfigurationService.java:731)
[vm0] at
org.apache.geode.distributed.internal.ClusterConfigurationService.initSharedConfiguration(ClusterConfigurationService.java:459)
[vm0] at
org.apache.geode.distributed.internal.InternalLocator.startSharedConfigurationService(InternalLocator.java:1332)
[vm0] at
org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:668)
[vm0] at
org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:647)
[vm0] at
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:309)
[vm0] at org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
[vm0] at
org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
[vm0] at
org.apache.geode.test.junit.rules.LocatorStarterRule.startLocator(LocatorStarterRule.java:78)
[vm0] at
org.apache.geode.test.junit.rules.LocatorStarterRule.before(LocatorStarterRule.java:59)
[vm0] at
org.apache.geode.test.dunit.rules.ClusterStartupRule.lambda$startLocatorVM$1c67b668$1(ClusterStartupRule.java:157)
[vm0] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[vm0] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[vm0] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[vm0] at java.lang.reflect.Method.invoke(Method.java:498)
[vm0] at hydra.MethExecutor.executeObject(MethExecutor.java:244)
[vm0] at
org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:70)
[vm0] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[vm0] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[vm0] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[vm0] at java.lang.reflect.Method.invoke(Method.java:498)
[vm0] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:361)
[vm0] at sun.rmi.transport.Transport$1.run(Transport.java:200)
[vm0] at sun.rmi.transport.Transport$1.run(Transport.java:197)
[vm0] at java.security.AccessController.doPrivileged(Native Method)
[vm0] at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
[vm0] at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
[vm0] at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
[vm0] at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
[vm0] at java.security.AccessController.doPrivileged(Native Method)
[vm0] at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
[vm0] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[vm0] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[vm0] at java.lang.Thread.run(Thread.java:748)
[vm0] Caused by: java.io.IOException: Cannot create directory at
C:\Users\Administrator\geode\geode-core\dunit\vm0\ConfigDiskDir_locator-0
[vm0] at
org.apache.geode.distributed.internal.ClusterConfigurationService.getConfigurationRegion(ClusterConfigurationService.java:699)
[vm0] ... 33 more
{noformat}
The problem boils down to the use of `Files.list` which sometimes will hold
open a directory and prevent its cleanup between tests.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4755) Jar deploy fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-4755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-4755:
--
Labels: pull-request-available (was: )
> Jar deploy fails on Windows
> ---
>
> Key: GEODE-4755
> URL: https://issues.apache.org/jira/browse/GEODE-4755
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> Fails with this exception:
> {noformat}
> java.lang.UnsupportedOperationException: 'posix:permissions' not supported as
> initial attribute
>at
> sun.nio.fs.WindowsSecurityDescriptor.fromAttribute(WindowsSecurityDescriptor.java:358)
>at
> sun.nio.fs.WindowsFileSystemProvider.createDirectory(WindowsFileSystemProvider.java:492)
>at java.nio.file.Files.createDirectory(Files.java:674)
>at java.nio.file.TempFileHelper.create(TempFileHelper.java:136)
>at
> java.nio.file.TempFileHelper.createTempDirectory(TempFileHelper.java:173)
>at java.nio.file.Files.createTempDirectory(Files.java:991)
>at
> org.apache.geode.management.internal.beans.FileUploader.uploadFile(FileUploader.java:77)
> {noformat}
> Potential classes affected:
> {noformat}
> org.apache.geode.distributed.internal.ClusterConfigurationService
> org.apache.geode.internal.cache.ClusterConfigurationLoader
> org.apache.geode.management.internal.beans.FileUploader
> org.apache.geode.management.internal.cli.functions.DeployFunction
> org.apache.geode.management.internal.web.controllers.AbstractCommandsController
> {noformat}
> Posixness can be checked with
> {{FileSystems.getDefault().supportedFileAttributeViews().contains(“posix”);}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4788) parReg.execute.FunctionServiceTest.getSomeKeys failed with util.TestException: Test Issue - Got the exception
[
https://issues.apache.org/jira/browse/GEODE-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xiaojian zhou resolved GEODE-4788.
--
Resolution: Fixed
Fix Version/s: 1.6.0
> parReg.execute.FunctionServiceTest.getSomeKeys failed with
> util.TestException: Test Issue - Got the exception
> -
>
> Key: GEODE-4788
> URL: https://issues.apache.org/jira/browse/GEODE-4788
> Project: Geode
> Issue Type: New Feature
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> CLIENT
> vm_12_thr_15_accessor1_rs-FullRegression-2018-03-03-05-01-17-client-8_4804
> TASK[0]
> parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions
> ERROR util.TestException: Test Issue - Got the exception
> util.TestException: Test Issue - Got the exception
> at
> parReg.execute.FunctionServiceTest.getSomeKeys(FunctionServiceTest.java:508)
> at
> parReg.execute.FunctionServiceTest.doRandomFunctionExecutions(FunctionServiceTest.java:473)
> at
> parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions(FunctionServiceTest.java:436)
> 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 hydra.MethExecutor.execute(MethExecutor.java:181)
> at hydra.MethExecutor.execute(MethExecutor.java:149)
> at hydra.TestTask.execute(TestTask.java:192)
> at hydra.RemoteTestModule$1.run(RemoteTestModule.java:212)
> Caused by: java.lang.RuntimeException:
> org.apache.geode.internal.cache.ForceReattemptException: FetchKeysResponse
> got remote CacheClosedException; forcing reattempt.
> at
> org.apache.geode.internal.cache.PartitionedRegionGetSomeKeys.getSomeKeys(PartitionedRegionGetSomeKeys.java:74)
> at
> parReg.execute.FunctionServiceTest.getSomeKeys(FunctionServiceTest.java:502)
> ... 10 more
> Caused by: org.apache.geode.internal.cache.ForceReattemptException:
> FetchKeysResponse got remote CacheClosedException; forcing reattempt.
> at
> org.apache.geode.internal.cache.partitioned.FetchKeysMessage$FetchKeysResponse.waitForKeys(FetchKeysMessage.java:546)
> at
> org.apache.geode.internal.cache.PartitionedRegionGetSomeKeys.getSomeKeys(PartitionedRegionGetSomeKeys.java:66)
> ... 11 more
> Caused by: org.apache.geode.cache.CacheClosedException: Remote cache is
> closed:
> rs-FullRegression-2018-03-03-05-01-17-client-8(dataStoregemfire5_rs-FullRegression-2018-03-03-05-01-17-client-8_4776:4776):1031
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1588)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1576)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:304)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:448)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1118)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$8$1.run(ClusterDistributionManager.java:943)
> at java.lang.Thread.run(Thread.java:748)
>
> CLIENT
> vm_15_thr_29_accessor4_rs-FullRegression-2018-03-03-05-01-17-client-8_4918
> TASK[0]
> parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions
> ERROR util.TestException: Test Issue - Got the exception
> util.TestException: Test Issue - Got the exception
> at
> parReg.execute.FunctionServiceTest.getSomeKeys(FunctionServiceTest.java:508)
> at
> parReg.execute.FunctionServiceTest.doRandomFunctionExecutions(FunctionServiceTest.java:473)
> at
> parReg.execute.FunctionServiceTest.HydraTask_doRandomFunctionExecutions(FunctionServiceTest.java:436)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Updated] (GEODE-4793) DUnit tests fail on Windows
[
https://issues.apache.org/jira/browse/GEODE-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-4793:
--
Labels: pull-request-available (was: )
> DUnit tests fail on Windows
> ---
>
> Key: GEODE-4793
> URL: https://issues.apache.org/jira/browse/GEODE-4793
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> Various tests will fail on Windows with errors similar to the following:
> {noformat}
> [vm0] [error 2018/03/07 04:38:13.670 UTC Connection(1)-10.32.110.121> tid=19] Error occurred while initializing
> cluster configuration
> [vm0] java.lang.RuntimeException: Error occurred while initializing cluster
> configuration
> [vm0] at
> org.apache.geode.distributed.internal.ClusterConfigurationService.getConfigurationRegion(ClusterConfigurationService.java:731)
> [vm0] at
> org.apache.geode.distributed.internal.ClusterConfigurationService.initSharedConfiguration(ClusterConfigurationService.java:459)
> [vm0] at
> org.apache.geode.distributed.internal.InternalLocator.startSharedConfigurationService(InternalLocator.java:1332)
> [vm0] at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:668)
> [vm0] at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:647)
> [vm0] at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:309)
> [vm0] at
> org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
> [vm0] at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
> [vm0] at
> org.apache.geode.test.junit.rules.LocatorStarterRule.startLocator(LocatorStarterRule.java:78)
> [vm0] at
> org.apache.geode.test.junit.rules.LocatorStarterRule.before(LocatorStarterRule.java:59)
> [vm0] at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.lambda$startLocatorVM$1c67b668$1(ClusterStartupRule.java:157)
> [vm0] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm0] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm0] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm0] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm0] at hydra.MethExecutor.executeObject(MethExecutor.java:244)
> [vm0] at
> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:70)
> [vm0] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm0] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm0] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm0] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm0] at
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:361)
> [vm0] at sun.rmi.transport.Transport$1.run(Transport.java:200)
> [vm0] at sun.rmi.transport.Transport$1.run(Transport.java:197)
> [vm0] at java.security.AccessController.doPrivileged(Native Method)
> [vm0] at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> [vm0] at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> [vm0] at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> [vm0] at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> [vm0] at java.security.AccessController.doPrivileged(Native Method)
> [vm0] at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> [vm0] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [vm0] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [vm0] at java.lang.Thread.run(Thread.java:748)
> [vm0] Caused by: java.io.IOException: Cannot create directory at
> C:\Users\Administrator\geode\geode-core\dunit\vm0\ConfigDiskDir_locator-0
> [vm0] at
> org.apache.geode.distributed.internal.ClusterConfigurationService.getConfigurationRegion(ClusterConfigurationService.java:699)
> [vm0] ... 33 more
> {noformat}
> The problem boils down to the use of `Files.list` which sometimes will hold
> open a directory and prevent its cleanup between tests.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4748) Geode put may result in inconsistent cache if network problem occurs or serialization of key or value class fails
[
https://issues.apache.org/jira/browse/GEODE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16389202#comment-16389202
]
Eugene Nedzvetsky commented on GEODE-4748:
--
Dan Smith. I couldn't reproduce this issue with drop packets emulation. I'll
create another bug with drop packets emulation(cluster hangs on
TXCommitMessage$CommitReplyProcessor.waitForCommitCompletion due to system
didn't kick out recipient member). Thanks.
> Geode put may result in inconsistent cache if network problem occurs or
> serialization of key or value class fails
> -
>
> Key: GEODE-4748
> URL: https://issues.apache.org/jira/browse/GEODE-4748
> Project: Geode
> Issue Type: Bug
> Components: membership, regions
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0
>Reporter: Vadim Lotarev
>Priority: Critical
> Attachments: clumsy.jpg, geode-4748.log
>
>
> Geode cache became inconsistent in case if networking and serialization
> problems occur at commit time. How to reproduce:
> # create any simple _replicated_ region
> # run two nodes
> # put some value in the region (within a transaction or not)
> # execute query on both nodes to check that the same value is returned (I
> used JMX for that)
> # emulate somehow temporary networking or serialization error (throw
> IOException from toData() or use [clumsy|https://jagt.github.io/clumsy/] to
> emulate network interruption)
> # repeat [#3], exception should occur
> # repeat [#4] - you should see different values on different nodes
> It looks like errors occurred after {{TXState.applyChanges}} produce
> inconsistency - it is impossible to rollback applied local changes what leads
> to the state where local cache contains changed data but other node(s) old
> data (before changes made in transaction).
> To me, consistency is a key property for the systems like Geode so I would
> consider this bug as a critical one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4782) Categorize Gfsh tests
Kenneth Howe created GEODE-4782: --- Summary: Categorize Gfsh tests Key: GEODE-4782 URL: https://issues.apache.org/jira/browse/GEODE-4782 Project: Geode Issue Type: Bug Components: gfsh Reporter: Kenneth Howe Add Category annotation for gfsh integration and distributed tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4783) Categorize Management tests
Kenneth Howe created GEODE-4783: --- Summary: Categorize Management tests Key: GEODE-4783 URL: https://issues.apache.org/jira/browse/GEODE-4783 Project: Geode Issue Type: Bug Reporter: Kenneth Howe Add Category annotation for management integration and distributed tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4783) Categorize Management tests
[ https://issues.apache.org/jira/browse/GEODE-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe updated GEODE-4783: Affects Version/s: 1.5.0 Component/s: management > Categorize Management tests > --- > > Key: GEODE-4783 > URL: https://issues.apache.org/jira/browse/GEODE-4783 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.5.0 >Reporter: Kenneth Howe >Priority: Major > > Add Category annotation for management integration and distributed tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4782) Categorize Gfsh tests
[ https://issues.apache.org/jira/browse/GEODE-4782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe updated GEODE-4782: Affects Version/s: 1.5.0 > Categorize Gfsh tests > - > > Key: GEODE-4782 > URL: https://issues.apache.org/jira/browse/GEODE-4782 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.5.0 >Reporter: Kenneth Howe >Priority: Major > > Add Category annotation for gfsh integration and distributed tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4784) Categorize Security tests
[ https://issues.apache.org/jira/browse/GEODE-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe updated GEODE-4784: Affects Version/s: 1.5.0 > Categorize Security tests > - > > Key: GEODE-4784 > URL: https://issues.apache.org/jira/browse/GEODE-4784 > Project: Geode > Issue Type: Bug > Components: security >Affects Versions: 1.5.0 >Reporter: Kenneth Howe >Priority: Major > > Add Category annotation for security integration and distributed tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4784) Categorize Security tests
Kenneth Howe created GEODE-4784: --- Summary: Categorize Security tests Key: GEODE-4784 URL: https://issues.apache.org/jira/browse/GEODE-4784 Project: Geode Issue Type: Bug Components: security Reporter: Kenneth Howe Add Category annotation for security integration and distributed tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4785) Categorize Pulse tests
[ https://issues.apache.org/jira/browse/GEODE-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe updated GEODE-4785: Affects Version/s: 1.5.0 > Categorize Pulse tests > -- > > Key: GEODE-4785 > URL: https://issues.apache.org/jira/browse/GEODE-4785 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.5.0 >Reporter: Kenneth Howe >Priority: Major > > Add Category annotation for pulse tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4785) Categorize Pulse tests
Kenneth Howe created GEODE-4785: --- Summary: Categorize Pulse tests Key: GEODE-4785 URL: https://issues.apache.org/jira/browse/GEODE-4785 Project: Geode Issue Type: Bug Components: pulse Reporter: Kenneth Howe Add Category annotation for pulse tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
