[jira] [Commented] (GEODE-7201) Useless and unhelpful Exception inappropriately logged at ERROR
[
https://issues.apache.org/jira/browse/GEODE-7201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561627#comment-17561627
]
John Blum commented on GEODE-7201:
--
This does not only affect Spring! This is easy enough to reproduce without
Spring, by simply using the Apache Geode API.
> Useless and unhelpful Exception inappropriately logged at ERROR
> ---
>
> Key: GEODE-7201
> URL: https://issues.apache.org/jira/browse/GEODE-7201
> Project: Geode
> Issue Type: Bug
>Reporter: John Blum
>Priority: Major
> Labels: affects-spring
>
> For testing, it is valid that I might register interests on a client Region
> where the server-side Region is a PARTITION Region, yet I am not using either
> mcast-port or Locators since I only need a single server for my tests!
> Therefore this Exception is not helpful in anyway and only adds confusion to
> the user...
> {code}
> 08:59:51 Caused by: java.lang.IllegalStateException: Should not register
> interest for a partitioned region when mcast-port is 0 and no locator is
> present
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.command.RegisterInterest61.cmdExecute(RegisterInterest61.java:257)
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> 08:59:51 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 08:59:51 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> 08:59:51 at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> 08:59:51 ... 1 more
> {code}
> So, I "should" not...
> > "_Should not register interest for a partitioned region when mcast-port is
> > 0 and no locator is present_"
> Why not?
> And, why does this message need to be logged at ERROR? WARN would suffice,
> especially since "_should_" implies a "_recommendation_" and not a strict,
> hard rule or requirement, which would rather be appropriately stated as
> "_Must not register interest..._".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-8254) JSONFormatter cannot parse JSON Arrays
[ https://issues.apache.org/jira/browse/GEODE-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-8254: - Description: The Apache Geode [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html] class is not capable of parsing/processing JSON Arrays, making it less than adequate to process JSON documents and content. This leaves the responsibility and burden on the user, which requires the user to inspect the individual array elements. A test case reproducing this issue can be found [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L518-L543]. The matching JSON document is [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/resources/data-example-doefamily.json]. JSON Arrays are a very common JSON data type, as [specified|https://www.json.org/json-en.html]. was: The Apache Geode [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html] class is not capable of parsing/processing JSON Arrays, making it less than adequate to process JSON documents and content. This leaves the responsibility and burden on the user, which requires the user to inspect the individual array elements. A test case reproducing this issue can be found [here|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]. The matching JSON document is [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/resources/data-example-doefamily.json]. JSON Arrays are a very common JSON data type, as [specified|https://www.json.org/json-en.html]. > JSONFormatter cannot parse JSON Arrays > -- > > Key: GEODE-8254 > URL: https://issues.apache.org/jira/browse/GEODE-8254 > Project: Geode > Issue Type: Bug > Components: serialization >Affects Versions: 1.9.2, 1.10.0, 1.11.0, 1.12.0 >Reporter: John Blum >Priority: Major > Labels: JSON-PDX > > The Apache Geode > [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html] > class is not capable of parsing/processing JSON Arrays, making it less than > adequate to process JSON documents and content. > This leaves the responsibility and burden on the user, which requires the > user to inspect the individual array elements. > A test case reproducing this issue can be found > [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L518-L543]. > The matching JSON document is > [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/resources/data-example-doefamily.json]. > JSON Arrays are a very common JSON data type, as > [specified|https://www.json.org/json-en.html]. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. A proper SPI affords any application, framework, tool or product a
degree of extensibility and flexibility, applied by users without intervention
by being able to "provide" a custom implementation or extension as needed by
the application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (specification)
compliant implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
Undertow) used by Geode to bootstrap the embedded HTTP service hosting the
Geode provided Web apps (e.g. Pulse, Management/Admin REST API, Developer REST
API) when external hosting is not an option. Of course, these Apache Geode
provided, internal Web apps need to be updated as well (to use the new Jakarta
EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) itself, is highly useful and
valuable in certain configuration arrangements.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. A proper SPI affords any application, framework, tool or product a
degree of extensibility and flexibility, applied by users without intervention
by being able to "provide" a custom implementation or extension as needed by
the application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (specification)
compliant implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
Undertow) used by Geode to bootstrap the embedded HTTP service hosting the
Geode provided Web apps (e.g. Pulse, Management/Admin REST API, Developer REST
API) when external hosting is not an option. Of course, these Apache Geode
provided, internal Web apps need to be updated as well (to use the new Jakarta
EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Sub-task
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
> {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. A proper SPI affords any application, framework, tool or product a
> degree of extensibility and flexibility, applied by users without
> intervention by being able to "provide" a custom implementation or extension
> as needed by the application, framework, tool or product.
> 1 such example would be
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. A proper SPI affords any application, framework, tool or product a
degree of extensibility and flexibility, applied by users without intervention
by being able to "provide" a custom implementation or extension as needed by
the application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (specification)
compliant implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
Undertow) used by Geode to bootstrap the embedded HTTP service hosting the
Geode provided Web apps (e.g. Pulse, Management/Admin REST API, Developer REST
API) when external hosting is not an option. Of course, these Apache Geode
provided, internal Web apps need to be updated as well (to use the new Jakarta
EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. A proper SPI affords any application, framework, tool or product a
degree of extensibility and flexibility, applied by users without intervention
by being able to "provide" a custom implementation or extension as needed by
the application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (specification)
compliant implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
Undertow) used by Geode to bootstrap the embedded HTTP service hosting the
Geode provided Web apps (e.g. Pulse, Management/Admin REST API, Developer REST
API) when external hosting is not an option. Of course, these Web apps need to
be updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Sub-task
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
> {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. A proper SPI affords any application, framework, tool or product a
> degree of extensibility and flexibility, applied by users without
> intervention by being able to "provide" a custom implementation or extension
> as needed by the application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (specification)
> compliant implementation of an embedded HTTP
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. A proper SPI affords any application, framework, tool or product a
degree of extensibility and flexibility, applied by users without intervention
by being able to "provide" a custom implementation or extension as needed by
the application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (specification)
compliant implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
Undertow) used by Geode to bootstrap the embedded HTTP service hosting the
Geode provided Web apps (e.g. Pulse, Management/Admin REST API, Developer REST
API) when external hosting is not an option. Of course, these Web apps need to
be updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. A proper SPI affords any application, framework, tool or product a
degree of extensibility and flexibility, applied by users without intervention
by being able to "provide" a custom implementation or extension as needed by
the application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Sub-task
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
> {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. A proper SPI affords any application, framework, tool or product a
> degree of extensibility and flexibility, applied by users without
> intervention by being able to "provide" a custom implementation or extension
> as needed by the application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (specification)
> compliant implementation of an embedded HTTP server (e.g. Jetty, Tomcat or
> even
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. A proper SPI affords any application, framework, tool or product a
degree of extensibility and flexibility, applied by users without intervention
by being able to "provide" a custom implementation or extension as needed by
the application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention, by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Sub-task
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
> {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. A proper SPI affords any application, framework, tool or product a
> degree of extensibility and flexibility, applied by users without
> intervention by being able to "provide" a custom implementation or extension
> as needed by the application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention, by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such using the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention, by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Sub-task
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
> {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. This allows any application, framework, tool or product a degree of
> extensibility and flexibility, afforded to users without intervention, by
> being able to "provide" a custom implementation or extension as needed by the
> application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to bootstrap the
[jira] [Updated] (GEODE-8258) Cannot implement PdxInstance and store in a Region
[
https://issues.apache.org/jira/browse/GEODE-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8258:
-
Priority: Major (was: Minor)
> Cannot implement PdxInstance and store in a Region
> --
>
> Key: GEODE-8258
> URL: https://issues.apache.org/jira/browse/GEODE-8258
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.9.2, 1.10.0, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Major
> Labels: JSON-PDX
>
> Given the type coupling in Geode between a {{PdxInstance}} and the PDX type
> registry, it is not currently possible to implement the
> [{{PdxInstance}}|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/PdxInstance.html]
> interface and store this {{PdxInstance}} object in a Region.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-9397) Gfsh `deploy jar` should introspect, identify, and invoke/initialize all Declarable objects
[ https://issues.apache.org/jira/browse/GEODE-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-9397: - Priority: Major (was: Minor) > Gfsh `deploy jar` should introspect, identify, and invoke/initialize all > Declarable objects > --- > > Key: GEODE-9397 > URL: https://issues.apache.org/jira/browse/GEODE-9397 > Project: Geode > Issue Type: New Feature > Components: core >Affects Versions: 1.13.2 >Reporter: John Blum >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524610#comment-17524610
]
John Blum edited comment on GEODE-10005 at 4/19/22 10:21 PM:
-
I am downgrading this Issue from "_Blocker_" to "_Major_" as I have provided a
[workaround|https://github.com/spring-projects/spring-boot-data-geode/issues/116]
in _*Spring Boot for Apache Geode*_ (SBDG) {{2.0}}, which successfully rebases
*Apache Geode* {{1.14.4}} on *Jetty* {{11}}, as declared and managed by _Spring
Boot_ {{3.0}}, upon which SBDG {{2.0}} is based.
was (Author: jblum):
I am downgrading this Issue from "_Blocker_" to "_Major_" as I have provided a
[workaround|https://github.com/spring-projects/spring-boot-data-geode/issues/116]
in _*Spring Boot for Apache Geode*_ (SBDG) `2.0`, which successfully rebases
*Apache Geode* `1.14.4` on *Jetty* `11`, as declared and managed by _Spring
Boot_ `3.0`, upon which SBDG `2.0` is based.
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Major
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524610#comment-17524610
]
John Blum commented on GEODE-10005:
---
I am downgrading this Issue from "_Blocker_" to "_Major_" as I have provided a
[workaround|https://github.com/spring-projects/spring-boot-data-geode/issues/116]
in _*Spring Boot for Apache Geode*_ (SBDG) `2.0`, which successfully rebases
*Apache Geode* `1.14.4` on *Jetty* `11`, as declared and managed by _Spring
Boot_ `3.0`, upon which SBDG `2.0` is based.
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Major
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10005:
--
Priority: Major (was: Blocker)
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Major
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum resolved GEODE-10045.
---
Resolution: Invalid
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.4
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Metrics and Monitoring, with Tracing, and so
> on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum closed GEODE-10045.
-
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.4
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Metrics and Monitoring, with Tracing, and so
> on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum reassigned GEODE-10045:
-
Assignee: John Blum
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.4
>Reporter: John Blum
>Assignee: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Metrics and Monitoring, with Tracing, and so
> on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum reassigned GEODE-10045:
-
Assignee: (was: John Blum)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.4
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Metrics and Monitoring, with Tracing, and so
> on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Affects Version/s: 1.14.4
(was: 1.14.3)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.4
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Metrics and Monitoring, with Tracing, and so
> on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524607#comment-17524607
]
John Blum commented on GEODE-10045:
---
No longer applicable now that Micrometer `2.0` is being reverted back to
Micrometer `1.10`.
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Metrics and Monitoring, with Tracing, and so
> on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Priority: Major (was: Blocker)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Metrics and Monitoring, with Tracing, and so
> on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Description:
As part of the ongoing story and themes in Spring Framework 6, Spring Data 3.0,
Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and major
topics is Observability (Metrics and Monitoring, with Tracing, and so on).
As part of that effort, Micrometer is undergoing a major revision change from
1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode no
longer runs (or even will build) with Micrometer 2.0.
Either Micrometer should be upgraded to 2.0 (most likely in the next major
version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
perhaps only enabled when Micrometer is on the classpath.
Still a cleaner separation is needed if [Spring] Apache Geode users require and
use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
Micrometer 1.x (currently
[1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
in Apache Geode {{1.14.3}}).
was:
As part of the ongoing story and themes in Spring Framework 6, Spring Data 3.0,
Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and major
topics is Observability (Monitoring with Metrics, Tracing, and so on).
As part of that effort, Micrometer is undergoing a major revision change from
1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode no
longer runs (or even will build) with Micrometer 2.0.
Either Micrometer should be upgraded to 2.0 (most likely in the next major
version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
perhaps only enabled when Micrometer is on the classpath.
Still a cleaner separation is needed if [Spring] Apache Geode users require and
use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
Micrometer 1.x (currently
[1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
in Apache Geode {{1.14.3}}).
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Blocker
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Metrics and Monitoring, with Tracing, and so
> on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Priority: Blocker (was: Major)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Blocker
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Priority: Major (was: Blocker)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer, blocks-1.15.0
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Description:
As part of the ongoing story and themes in Spring Framework 6, Spring Data 3.0,
Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and major
topics is Observability (Monitoring with Metrics, Tracing, and so on).
As part of that effort, Micrometer is undergoing a major revision change from
1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode no
longer runs (or even will build) with Micrometer 2.0.
Either Micrometer should be upgraded to 2.0 (most likely in the next major
version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
perhaps only enabled when Micrometer is on the classpath.
Still a cleaner separation is needed if [Spring] Apache Geode users require and
use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
Micrometer 1.x (currently
[1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
in Apache Geode {{1.14.3}}).
was:
As part of the ongoing story and themes in Spring Framework 6, Spring Data 3.0
and the rest of the Spring portfolio, 1 of the new and major topics is
Observability (Monitoring with Metrics, Tracing, and so on).
As part of that effort, Micrometer is undergoing a major revision change from
1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode no
longer runs (or even will build) with Micrometer 2.0.
Either Micrometer should be upgraded to 2.0 (most likely in the next major
version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
perhaps only enabled when Micrometer is on the classpath.
Still a cleaner separation is needed if [Spring] Apache Geode users require and
use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
Micrometer 1.x (currently
[1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
in Apache Geode {{1.14.3}}).
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Blocker
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503205#comment-17503205
]
John Blum commented on GEODE-10045:
---
Upgrading this ticket to a "*Blocker*" now that core Spring APIs and components
are relying on the core Micrometer libraries and APIs to implement
_Observability_ across the Spring portfolio.
For instance, Spring Boot is integrating essential Micrometer functionality to
implement key metrics (e.g. Startup Time) provided by Spring Boot Actuator. As
a result, Spring Boot for Apache Geode will no longer build/run with Micrometer
1.x (i.e. Micrometer 1.6.3 on which Apache Geode 1.14.3 is currently
[based|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]),
which causes the following Exception to be thrown:
{code:java}
java.lang.NoSuchMethodError: 'io.micrometer.core.instrument.TimeGauge$Builder
io.micrometer.core.instrument.TimeGauge.builder(java.lang.String,
java.util.function.Supplier, java.util.concurrent.TimeUnit)'
at
org.springframework.boot.actuate.metrics.startup.StartupTimeMetricsListener.registerGauge(StartupTimeMetricsListener.java:119)
at
org.springframework.boot.actuate.metrics.startup.StartupTimeMetricsListener.onApplicationStarted(StartupTimeMetricsListener.java:106)
at
org.springframework.boot.actuate.metrics.startup.StartupTimeMetricsListener.onApplicationEvent(StartupTimeMetricsListener.java:98)
...
{code}
Conversely, Apache Geode will not build/run with the new Spring Boot,
Micrometer 2.0
[baseline|https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-dependencies/build.gradle#L954-L965],
leading to the following Exception, which is thrown from Apache Geode:
{code:java}
...
Caused by: java.lang.NoClassDefFoundError:
io/micrometer/core/instrument/binder/system/FileDescriptorMetrics
at
org.apache.geode.metrics.internal.StandardMeterBinder.(StandardMeterBinder.java:40)
at
org.apache.geode.metrics.internal.InternalDistributedSystemMetricsService$Builder.build(InternalDistributedSystemMetricsService.java:250)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:804)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
at
org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:208)
at
org.apache.geode.cache.client.ClientCacheFactory.connectInternalDistributedSystem(ClientCacheFactory.java:282)
at
org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:252)
at
org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:218)
at
org.springframework.data.gemfire.client.ClientCacheFactoryBean.createCache(ClientCacheFactoryBean.java:411)
at
org.springframework.data.gemfire.AbstractResolvableCacheFactoryBean.resolveCache(AbstractResolvableCacheFactoryBean.java:153)
at
org.springframework.data.gemfire.AbstractResolvableCacheFactoryBean.init(AbstractResolvableCacheFactoryBean.java:72)
at
org.springframework.data.gemfire.AbstractResolvableCacheFactoryBean.doGetObject(AbstractResolvableCacheFactoryBean.java:52)
at
org.springframework.data.gemfire.AbstractBasicCacheFactoryBean.getObject(AbstractBasicCacheFactoryBean.java:351)
at
org.springframework.data.gemfire.AbstractBasicCacheFactoryBean.getObject(AbstractBasicCacheFactoryBean.java:113)
at
org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:148)
... 84 more
Caused by: java.lang.ClassNotFoundException:
io.micrometer.core.instrument.binder.system.FileDescriptorMetrics
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
... 101 more
{code}
This leaves Spring and Apache Geode at an impasse as of SBDG 2.0 / Spring Boot
3.0.
This problem is only going to grow as more and more core Spring functionality
is augmented with metrics using Micrometer 2.0.
Spring Data (Commons) is also using Micrometer in the core Repository
infrastructure to gather runtime metrics.
This Micrometer incompatibility will effectively render Apache Geode inoperable
on Spring 6 / Spring Boot/Data 3 and
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Priority: Blocker (was: Minor)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Blocker
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0 and the rest of the Spring portfolio, 1 of the new and major topics is
> Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Priority: Minor (was: Blocker)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Minor
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0 and the rest of the Spring portfolio, 1 of the new and major topics is
> Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Priority: Blocker (was: Major)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Blocker
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0 and the rest of the Spring portfolio, 1 of the new and major topics is
> Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491075#comment-17491075
]
John Blum commented on GEODE-10035:
---
The workaround is to simply and only use the {{p2p.nodirectBuffers}} (set to
{{true}}) GemFire property.
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Minor
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> Alternatively:
> {code:java}
> public static final boolean useDirectBuffers =
> !Boolean.getBoolean("p2p.nodirectBuffers")
> &&
> !Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then
> DO NOT USE direct ByteBuffers.
> The term "{{useHeapBuffers}}" implies that the buffer should be created on
> the JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
> "{{true}}" would result in a direct ByteBuffer allocation as can be seen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
>
> rather than what should happen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> As the condition currently stands, if the "{{p2p.nodirectBuffers}}" System
> property is not set at all (which results in {{Boolean.getBoolean(..)}}
> returning {{false}}), which negated results in the OR'd condition not even
> being evaluated!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Component/s: core
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0 and the rest of the Spring portfolio, 1 of the new and major topics is
> Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Labels: Micrometer (was: )
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0 and the rest of the Spring portfolio, 1 of the new and major topics is
> Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491074#comment-17491074
]
John Blum edited comment on GEODE-10045 at 2/11/22, 5:52 PM:
-
Related: https://github.com/spring-projects/spring-data-geode/issues/572
And: https://github.com/spring-projects/spring-data-geode/issues/571
was (Author: jblum):
Related: https://github.com/spring-projects/spring-data-geode/issues/572
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0 and the rest of the Spring portfolio, 1 of the new and major topics is
> Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491074#comment-17491074
]
John Blum commented on GEODE-10045:
---
Related: https://github.com/spring-projects/spring-data-geode/issues/572
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0 and the rest of the Spring portfolio, 1 of the new and major topics is
> Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Summary: Upgrade to Micrometer 2.0 (was: Upgrade Apache Geode to
Micrometer 2.0)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0 and the rest of the Spring portfolio, 1 of the new and major topics is
> Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10045) Upgrade Apache Geode to Micrometer 2.0
John Blum created GEODE-10045:
-
Summary: Upgrade Apache Geode to Micrometer 2.0
Key: GEODE-10045
URL: https://issues.apache.org/jira/browse/GEODE-10045
Project: Geode
Issue Type: Improvement
Affects Versions: 1.14.3
Reporter: John Blum
As part of the ongoing story and themes in Spring Framework 6, Spring Data 3.0
and the rest of the Spring portfolio, 1 of the new and major topics is
Observability (Monitoring with Metrics, Tracing, and so on).
As part of that effort, Micrometer is undergoing a major revision change from
1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode no
longer runs (or even will build) with Micrometer 2.0.
Either Micrometer should be upgraded to 2.0 (most likely in the next major
version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
perhaps only enabled when Micrometer is on the classpath.
Still a cleaner separation is needed if [Spring] Apache Geode users require and
use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
Micrometer 1.x (currently
[1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GEODE-8286) The Geode JVM Shutdown Hook should not be enabled by default
[ https://issues.apache.org/jira/browse/GEODE-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140754#comment-17140754 ] John Blum edited comment on GEODE-8286 at 2/11/22, 1:24 AM: Of course, changing the registration of the Geode, JVM Shutdown Hook to "opt-in" rather than the currently positioned "opt-out" would constitute a change in behavior that could adversely affect users. This would be an acceptable change in a major version. The only other alternative is if Geode provided an SPI that made it context aware. was (Author: jblum): Of course, changing the registration of the Geode, JVM Shutdown Hook to "opt-in" rather than the currently positioned, "opt-out", is a change in behavior could adversely affect users. This would be an acceptable change in a major version. The only other alternative is if Geode provided an SPI that made it context aware. > The Geode JVM Shutdown Hook should not be enabled by default > > > Key: GEODE-8286 > URL: https://issues.apache.org/jira/browse/GEODE-8286 > Project: Geode > Issue Type: Bug > Components: configuration, general, management >Reporter: John Blum >Priority: Critical > Labels: JSON-PDX > > Apache Geode registers a JVM Shutdown Hook in > [InternalDistributedSystem|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2190-L] > that ensures the Apache Geode Cache and associated DistributedSystem are > shutdown properly when the JVM exits. > However, this JVM Shutdown Hook and interfere with Frameworks and Tooling > that have their own Lifecycle Management capabilities. The Spring Framework > and Container is one such example. > Any managed environment, be that Micronaut, Quarkus, Pivotal Platform > (PCF/TAS), Kubernetes, AWS, Azure, GCP, etc, etc, are going to have lifecycle > management capabilities. > It is very important that the environment manage the lifecycle of all actors > in the fully "integrated" system. > In Spring's case, it must coordinate the lifecycle of application components > along with integrated systems, like Geode, in an effort to shut all > components down in a coordinated, correct fashion. > If Geode's JVM Shutdown Hook is permitted to do as it pleases, then this can > circumvent the Framework/Container, Tool, or other's lifecycle management > capabilities, leaving the system or application in an inconsistent/incorrect > state. > To make matters worse, the [JVM System > Property|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2191] > (and specifically, > [this|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L391-L392]) > controlling the enablement of the JVM Shutdown Hook, is non-public and [not > documented|https://geode.apache.org/docs/guide/112/reference/topics/gemfire_properties.html]. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9393) Apache Geode does not build/run on Java 16/17
[
https://issues.apache.org/jira/browse/GEODE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490604#comment-17490604
]
John Blum commented on GEODE-9393:
--
See recent occurrence of this problem in GEODE-10036 when trying to start a
cluster with multiple _Locators_.
> Apache Geode does not build/run on Java 16/17
> -
>
> Key: GEODE-9393
> URL: https://issues.apache.org/jira/browse/GEODE-9393
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.13.2
>Reporter: John Blum
>Priority: Blocker
> Labels: Java16
>
> Due to Java 16 tightened restrictions, Apache Geode fails to run on a Java 16
> Runtime (JRE).
> Exceptions like the following are thrown:
> {code}
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> - at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> - at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> - at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
> - at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2050)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> - at
> org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
> - at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> - at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
> - at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> - at java.base/java.lang.Thread.run(Thread.java:831)
> - Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @40f9161a
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> - at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> - at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> - ... 22 common frames omitted
> - 2021-04-30 14:57:13,638 INFO ributed.internal.membership.gms.Services: 606
> - received leave request from
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> - 2021-04-30 14:57:13,640 INFO ributed.internal.membership.gms.Services: 617
> - JoinLeave.processMessage(LeaveRequestMessage) invoked. isCoordinator=true;
> isStopping=false; cancelInProgress=false
> - 2021-04-30 14:57:13,647 ERROR xecutors.LoggingUncaughtExceptionHandler: 92
> - Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> shared unordered uid=1 local port=53039 remote port=64063,10,main]
> - org.apache.geode.InternalGemFireException: unable to retrieve
[jira] [Commented] (GEODE-9393) Apache Geode does not build/run on Java 16/17
[
https://issues.apache.org/jira/browse/GEODE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490603#comment-17490603
]
John Blum commented on GEODE-9393:
--
Setting either JVM option would be unacceptable in the long-term for most
users. Users may not necessarily have control over their deployment and
runtime environment.
Regarding my comment above about using the {{Runtime}} API to fork Java
processes (e.g. GemFire/Geode server processes), which I mainly due for
testing/examples purposes, I meant passing {{--add-opens}} JVM options in the
({{java}}) command passed to {{Runtime.exec(:String[])}}
([Javadoc|https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#exec-java.lang.String:A-])
did not seem to work correctly.
I figured out that the individual elements of the command array just be present
as:
{code:java}
String[] javaCommand = new String[..];
javaCommand[0] = "java"
javaCommand[1] = "--add-opens"
javaCommadn[2] = "java.base/java.lang=ALL_UNNAMED"
javaCommand[3] = ...
{code}
The command cannot be expressed as:
{code:java}
String[] javaCommand = new String[..];
javaCommand[0] = "java"
javaCommand[1] = "--add-opens ava.base/java.lang=ALL_UNNAMED"
{code}
The Java {{Runtime}} API will throw an Exception. I don't recall what
Exception was thrown now, I just know the second example does not work! The
first {{java}} command array configuration arrangement does, however.
> Apache Geode does not build/run on Java 16/17
> -
>
> Key: GEODE-9393
> URL: https://issues.apache.org/jira/browse/GEODE-9393
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.13.2
>Reporter: John Blum
>Priority: Blocker
> Labels: Java16
>
> Due to Java 16 tightened restrictions, Apache Geode fails to run on a Java 16
> Runtime (JRE).
> Exceptions like the following are thrown:
> {code}
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> - at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> - at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> - at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
> - at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2050)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> - at
> org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
> - at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> - at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
> - at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> - at java.base/java.lang.Thread.run(Thread.java:831)
> - Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @40f9161a
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> - at
>
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such using the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention, by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used inn Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such using the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used inn Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such using the _Java_
> {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. This allows any application, framework, tool or product a degree of
> extensibility and flexibility, afforded to users without intervention, by
> being able to "provide" a custom implementation or extension as needed by the
> application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such using the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention, by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such using the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention, by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used inn Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such using the _Java_
> {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. This allows any application, framework, tool or product a degree of
> extensibility and flexibility, afforded to users without intervention, by
> being able to "provide" a custom implementation or extension as needed by the
> application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such using the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used inn Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such by via the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used inn Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such using the _Java_
> {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. This allows any application, framework, tool or product a degree of
> extensibility and flexibility, afforded to users without intervention by
> being able to "provide" a custom implementation or extension as needed by the
> application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to
[jira] [Comment Edited] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489898#comment-17489898
]
John Blum edited comment on GEODE-10036 at 2/11/22, 1:03 AM:
-
While it should be technically possible to still run and join Locators in a
cluster by setting the appropriate JVM options (e.g. {{--add-opens
java.base/java.nio=ALL_UNNAMED}}), I was unsuccessful in doing so. I am not
sure why in this case as I was not able to successfully open options while
running other Apache Geode processes based on my use cases and scenarios.
It should be noted that requiring users to use {{--add-opens}} JVM options is
not an acceptable alternative to proper Java module configuration, anyway.
was (Author: jblum):
While it should be technically possible to still run and join Locators in a
cluster by setting the appropriate JVM options (e.g. {{--add-opens
java.base/java.nio=ALL_UNNAMED}}), I was unsuccessful in doing so. I am not
sure why in this case as I was not able to successfully open options while
running other Apache Geode processes based on my use cases and scenarios.
It should be noted that the use of {{--add-opens}} JVM options are not an
acceptable alternative to proper Java module configuration, anyway.
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
> Labels: needsTriage
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object
[jira] [Comment Edited] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489898#comment-17489898
]
John Blum edited comment on GEODE-10036 at 2/11/22, 1:02 AM:
-
While it should be technically possible to still run and join Locators in a
cluster by setting the appropriate JVM options (e.g. {{--add-opens
java.base/java.nio=ALL_UNNAMED}}), I was unsuccessful in doing so. I am not
sure why in this case as I was not able to successfully open options while
running other Apache Geode processes based on my use cases and scenarios.
It should be noted that the use of {{--add-opens}} JVM options are not an
acceptable alternative to proper Java module configuration, anyway.
was (Author: jblum):
While it should be technically possible to still run and join Locators in a
cluster by setting the appropriate JVM options (e.g. {{--add-opens
java.base/java.nio=ALL_UNNAMED}}), I was unsuccessful in doing so. I am not
sure why in this case as I was successfully adding open options while running
other Apache Geode processes based on my use cases and scenarios.
It should be noted that the use of {{--add-opens}} JVM options are not an
acceptable alternative to proper Java module configuration.
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
> Labels: needsTriage
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object
[jira] [Updated] (GEODE-10037) Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API
[ https://issues.apache.org/jira/browse/GEODE-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-10037: -- Description: For the same reasons that were stated in GEODE-10007. (was: See GEODE-10007.) > Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the > non-internal, public API > - > > Key: GEODE-10037 > URL: https://issues.apache.org/jira/browse/GEODE-10037 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.14.3 >Reporter: John Blum >Priority: Minor > Labels: needsTriage > > For the same reasons that were stated in GEODE-10007. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10037) Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API
[ https://issues.apache.org/jira/browse/GEODE-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-10037: -- Priority: Minor (was: Major) > Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the > non-internal, public API > - > > Key: GEODE-10037 > URL: https://issues.apache.org/jira/browse/GEODE-10037 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.14.3 >Reporter: John Blum >Priority: Minor > Labels: needsTriage > > See GEODE-10007. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10037) Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API
[ https://issues.apache.org/jira/browse/GEODE-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-10037: -- Issue Type: Improvement (was: Bug) > Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the > non-internal, public API > - > > Key: GEODE-10037 > URL: https://issues.apache.org/jira/browse/GEODE-10037 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.14.3 >Reporter: John Blum >Priority: Major > Labels: needsTriage > > See GEODE-10007. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10037) Make o.a.g.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API
[ https://issues.apache.org/jira/browse/GEODE-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-10037: -- Summary: Make o.a.g.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API (was: Make org.apache.geode.internal.cache.wan.spi.WANFactory SPI interface part of the non-internal, public API) > Make o.a.g.internal.cache.wan.spi.WANFactory SPI part of the non-internal, > public API > - > > Key: GEODE-10037 > URL: https://issues.apache.org/jira/browse/GEODE-10037 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.3 >Reporter: John Blum >Priority: Major > Labels: needsTriage > > See GEODE- -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10037) Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API
[ https://issues.apache.org/jira/browse/GEODE-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-10037: -- Description: See GEODE-10007. (was: See GEODE-) > Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the > non-internal, public API > - > > Key: GEODE-10037 > URL: https://issues.apache.org/jira/browse/GEODE-10037 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.3 >Reporter: John Blum >Priority: Major > Labels: needsTriage > > See GEODE-10007. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10037) Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API
[ https://issues.apache.org/jira/browse/GEODE-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-10037: -- Summary: Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API (was: Make o.a.g.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API) > Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the > non-internal, public API > - > > Key: GEODE-10037 > URL: https://issues.apache.org/jira/browse/GEODE-10037 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.3 >Reporter: John Blum >Priority: Major > Labels: needsTriage > > See GEODE- -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10037) Make org.apache.geode.internal.cache.wan.spi.WANFactory SPI interface part of the non-internal, public API
John Blum created GEODE-10037: - Summary: Make org.apache.geode.internal.cache.wan.spi.WANFactory SPI interface part of the non-internal, public API Key: GEODE-10037 URL: https://issues.apache.org/jira/browse/GEODE-10037 Project: Geode Issue Type: Bug Affects Versions: 1.14.3 Reporter: John Blum See GEODE- -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489898#comment-17489898
]
John Blum edited comment on GEODE-10036 at 2/10/22, 1:23 AM:
-
While it should be technically possible to still run and join Locators in a
cluster by setting the appropriate JVM options (e.g. {{--add-opens
java.base/java.nio=ALL_UNNAMED}}), I was unsuccessful in doing so. I am not
sure why in this case as I was successfully adding open options while running
other Apache Geode processes based on my use cases and scenarios.
It should be noted that the use of {{--add-opens}} JVM options are not an
acceptable alternative to proper Java module configuration.
was (Author: jblum):
While it should be technically possible to still run and join Locators in a
cluster by setting the appropriate JVM options (e.g. {{--add-opens
java.base/java.nio=ALL_UNNAMED}}), I was unsuccessful in doing so. I am not
sure why in this case as I was successfully adding open options while running
other Apache Geode processes based on my use cases and scenarios.
It should be noted that the use of the JVM {{--add-opens}} option is not an
acceptable alternative to proper Java module configuration.
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
> Labels: needsTriage
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object
[jira] [Updated] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10035:
--
Priority: Minor (was: Critical)
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Minor
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> Alternatively:
> {code:java}
> public static final boolean useDirectBuffers =
> !Boolean.getBoolean("p2p.nodirectBuffers")
> &&
> !Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then
> DO NOT USE direct ByteBuffers.
> The term "{{useHeapBuffers}}" implies that the buffer should be created on
> the JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
> "{{true}}" would result in a direct ByteBuffer allocation as can be seen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
>
> rather than what should happen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> As the condition currently stands, if the "{{p2p.nodirectBuffers}}" System
> property is not set at all (which results in {{Boolean.getBoolean(..)}}
> returning {{false}}), which negated results in the OR'd condition not even
> being evaluated!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489898#comment-17489898
]
John Blum edited comment on GEODE-10036 at 2/10/22, 1:22 AM:
-
While it should be technically possible to still run and join Locators in a
cluster by setting the appropriate JVM options (e.g. {{--add-opens
java.base/java.nio=ALL_UNNAMED}}), I was unsuccessful in doing so. I am not
sure why in this case as I was successfully adding open options while running
other Apache Geode processes based on my use cases and scenarios.
It should be noted that the use of the JVM {{--add-opens}} option is not an
acceptable alternative to proper Java module configuration.
was (Author: jblum):
While it should be technically possible to still run and join Locators in a
cluster by setting the appropriate JVM options (e.g. {{--add-opens
java.base/java.nio=ALL_UNNAMED}}), I was unsuccessful in doing so. I am not
sure why in this case as I was successfully adding open options while running
other Apache Geode processes based on my use cases and scenarios.
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
> Labels: needsTriage
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @2e0fa5d3
> at
>
[jira] [Commented] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489900#comment-17489900
]
John Blum commented on GEODE-10035:
---
You may wonder why I needed to set this System property at all; GEODE-10036 is
the reason.
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> Alternatively:
> {code:java}
> public static final boolean useDirectBuffers =
> !Boolean.getBoolean("p2p.nodirectBuffers")
> &&
> !Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then
> DO NOT USE direct ByteBuffers.
> The term "{{useHeapBuffers}}" implies that the buffer should be created on
> the JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
> "{{true}}" would result in a direct ByteBuffer allocation as can be seen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
>
> rather than what should happen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> As the condition currently stands, if the "{{p2p.nodirectBuffers}}" System
> property is not set at all (which results in {{Boolean.getBoolean(..)}}
> returning {{false}}), which negated results in the OR'd condition not even
> being evaluated!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489899#comment-17489899
]
John Blum commented on GEODE-10036:
---
This was related to GEODE-10035.
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
> Labels: needsTriage
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @2e0fa5d3
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> ... 69 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10036:
--
Priority: Critical (was: Major)
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
> Labels: needsTriage
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @2e0fa5d3
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> ... 69 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489898#comment-17489898
]
John Blum commented on GEODE-10036:
---
While it should be technically possible to still run and join Locators in a
cluster by setting the appropriate JVM options (e.g. {{--add-opens
java.base/java.nio=ALL_UNNAMED}}), I was unsuccessful in doing so. I am not
sure why in this case as I was successfully adding open options while running
other Apache Geode processes based on my use cases and scenarios.
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: needsTriage
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @2e0fa5d3
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> ... 69 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
John Blum created GEODE-10036:
-
Summary: Joining Locators in a cluster is not possible on Java 17
Key: GEODE-10036
URL: https://issues.apache.org/jira/browse/GEODE-10036
Project: Geode
Issue Type: Bug
Affects Versions: 1.14.3
Reporter: John Blum
When trying to add multiple _Locators_ to the same cluster, particularly when
"_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
{code:java}
Caused by: org.apache.geode.SystemConnectException: One or more peers generated
exceptions during connection attempt
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
at
org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
at
org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
at
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
at
org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
at
org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
... 44 more
Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
underlying byte buffer
at
org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
at
org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
at
org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
at
org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
at
org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
at
org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
at
org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
at
org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
at
org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
... 56 more
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make public
java.lang.Object java.nio.DirectByteBuffer.attachment() accessible: module
java.base does not "opens java.nio" to unnamed module @2e0fa5d3
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at
java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
at
org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
... 69 more
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10035:
--
Issue Type: Bug (was: Improvement)
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> Alternatively:
> {code:java}
> public static final boolean useDirectBuffers =
> !Boolean.getBoolean("p2p.nodirectBuffers")
> &&
> !Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then
> DO NOT USE direct ByteBuffers.
> The term "{{useHeapBuffers}}" implies that the buffer should be created on
> the JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
> "{{true}}" would result in a direct ByteBuffer allocation as can be seen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
>
> rather than what should happen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> As the condition currently stands, if the "{{p2p.nodirectBuffers}}" System
> property is not set at all (which results in {{Boolean.getBoolean(..)}}
> returning {{false}}), which negated results in the OR'd condition not even
> being evaluated!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10035:
--
Description:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
Alternatively:
{code:java}
public static final boolean useDirectBuffers =
!Boolean.getBoolean("p2p.nodirectBuffers")
&&
!Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
{code}
That is, if either the "{{p2p.nodirectBuffers}}" OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then DO
NOT USE direct ByteBuffers.
The term "{{useHeapBuffers}}" implies that the buffer should be created on the
JVM Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
As the condition currently stands, if the "{{p2p.nodirectBuffers}}" System
property is not set at all (which results in {{Boolean.getBoolean(..)}}
returning {{false}}), which negated results in the OR'd condition not even
being evaluated!
was:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
Alternatively:
{code:java}
public static final boolean useDirectBuffers =
!Boolean.getBoolean("p2p.nodirectBuffers")
&&
!Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
{code}
That is, if either the "{{p2p.nodirectBuffers}}" OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then DO
NOT USE direct ByteBuffers.
The term "{{useHeapBuffers}}" implies that the buffer should be created on the
JVM Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> Alternatively:
> {code:java}
> public static final boolean useDirectBuffers =
> !Boolean.getBoolean("p2p.nodirectBuffers")
>
[jira] [Updated] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10035:
--
Priority: Critical (was: Major)
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> Alternatively:
> {code:java}
> public static final boolean useDirectBuffers =
> !Boolean.getBoolean("p2p.nodirectBuffers")
> &&
> !Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then
> DO NOT USE direct ByteBuffers.
> The term "{{useHeapBuffers}}" implies that the buffer should be created on
> the JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
> "{{true}}" would result in a direct ByteBuffer allocation as can be seen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
>
> rather than what should happen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> As the condition currently stands, if the "{{p2p.nodirectBuffers}}" System
> property is not set at all (which results in {{Boolean.getBoolean(..)}}
> returning {{false}}), which negated results in the OR'd condition not even
> being evaluated!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10035:
--
Description:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
Alternatively:
{code:java}
public static final boolean useDirectBuffers =
!Boolean.getBoolean("p2p.nodirectBuffers")
&&
!Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
{code}
That is, if either the "{{p2p.nodirectBuffers}}" OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then DO
NOT USE direct ByteBuffers.
The term "{{useHeapBuffers}}" implies that the buffer should be created on the
JVM Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
was:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
Alternatively:
{code:java}
public static final boolean useDirectBuffers =
!Boolean.getBoolean("p2p.nodirectBuffers")
&&
!Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
{code}
That is, if either the "{{p2p.nodirectBuffers}}" OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then DO
NOT USE direct ByteBuffers.
The term "{{useHeapBuffers}}" implies that the buffer should created on the JVM
Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> Alternatively:
> {code:java}
> public static final boolean useDirectBuffers =
> !Boolean.getBoolean("p2p.nodirectBuffers")
> &&
> !Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then
> DO
[jira] [Updated] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10035:
--
Description:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
Alternatively:
{code:java}
public static final boolean useDirectBuffers =
!Boolean.getBoolean("p2p.nodirectBuffers")
&&
!Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
{code}
That is, if either the "{{p2p.nodirectBuffers}}" OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then DO
NOT USE direct ByteBuffers.
The term "{{useHeapBuffers}}" implies that the buffer should created on the JVM
Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
was:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
That is, if either the "{{p2p.nodirectBuffers}}" OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then DO
NOT USE direct ByteBuffers.
The term "{{useHeapBuffers}}" implies that the buffer should created on the JVM
Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> Alternatively:
> {code:java}
> public static final boolean useDirectBuffers =
> !Boolean.getBoolean("p2p.nodirectBuffers")
> &&
> !Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then
> DO NOT USE direct ByteBuffers.
> The term "{{useHeapBuffers}}" implies that the buffer should created on the
> JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property
[jira] [Updated] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10035:
--
Description:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
That is, if either the "{{p2p.nodirectBuffers}}" OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then DO
NOT USE direct ByteBuffers.
The term "{{useHeapBuffers}}" implies that the buffer should created on the JVM
Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
was:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
The term "{{useHeapBuffers}}" implies that the buffer should created on the JVM
Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then
> DO NOT USE direct ByteBuffers.
> The term "{{useHeapBuffers}}" implies that the buffer should created on the
> JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
> "{{true}}" would result in a direct ByteBuffer allocation as can be seen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
>
> rather than what should happen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10035:
--
Description:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
The term "{{useHeapBuffers}}" implies that the buffer should created on the JVM
Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
was:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read:
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
The term "{{useHeapBuffers}}" implies that the buffer should created on the JVM
Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> The term "{{useHeapBuffers}}" implies that the buffer should created on the
> JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
> "{{true}}" would result in a direct ByteBuffer allocation as can be seen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
>
> rather than what should happen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
John Blum created GEODE-10035:
-
Summary: The System property condition to use "direct" ByteBuffers
in P2P is wrong
Key: GEODE-10035
URL: https://issues.apache.org/jira/browse/GEODE-10035
Project: Geode
Issue Type: Improvement
Affects Versions: 1.14.3
Reporter: John Blum
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read:
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
The term "{{useHeapBuffers}}" implies that the buffer should created on the JVM
Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GEODE-7891) User Guide refers to non-valid GemFire Properties
[
https://issues.apache.org/jira/browse/GEODE-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485450#comment-17485450
]
John Blum edited comment on GEODE-7891 at 2/1/22, 10:08 PM:
Given the lack of action / comments on this ticket, I am not sure we are
understanding the gravity of the situation here.
By declaring these properties in {{gemfire.properties}}, Apache Geode will fail
to start (!) as they are considered invalid properties.
For example, given the following test application code using the Apache Geode
API:
{code:java}
public class ApacheGeodePeerCacheApplication {
public static void main(String[] args) {
Cache peerCache = new CacheFactory()
.set("name", "PeerCacheApplicationTest")
.set("tombstone-gc-threshold", "100")
.create();
assertThat(peerCache).isNotNull();
assertThat(peerCache.getName()).isEqualTo("PeerCacheApplicationTest");
}
}
{code}
Running this test application results in the following error:
{code}
Exception in thread "main" java.lang.IllegalArgumentException: Unknown
configuration attribute name tombstone-gc-threshold. Valid attribute names are:
ack-severe-alert-threshold ack-wait-threshold archive-disk-space-limit
archive-file-size-limit async-distribution-timeout async-max-queue-size
async-queue-timeout bind-address cache-xml-file cluster-configuration-dir
cluster-ssl-ciphers cluster-ssl-enabled cluster-ssl-keystore
cluster-ssl-keystore-password cluster-ssl-keystore-type cluster-ssl-protocols
cluster-ssl-require-authentication cluster-ssl-truststore
cluster-ssl-truststore-password compatible-with-redis-bind-address
compatible-with-redis-enabled compatible-with-redis-password
compatible-with-redis-port conflate-events conserve-sockets delta-propagation
deploy-working-dir disable-auto-reconnect disable-jmx disable-tcp
distributed-system-id distributed-transactions durable-client-id
durable-client-timeout enable-cluster-configuration
enable-management-rest-service enable-network-partition-detection
enable-time-statistics enforce-unique-host gateway-ssl-ciphers
gateway-ssl-enabled gateway-ssl-keystore gateway-ssl-keystore-password
gateway-ssl-keystore-type gateway-ssl-protocols
gateway-ssl-require-authentication gateway-ssl-truststore
gateway-ssl-truststore-password groups http-service-bind-address
http-service-port http-service-ssl-ciphers http-service-ssl-enabled
http-service-ssl-keystore http-service-ssl-keystore-password
http-service-ssl-keystore-type http-service-ssl-protocols
http-service-ssl-require-authentication http-service-ssl-truststore
http-service-ssl-truststore-password jmx-manager jmx-manager-access-file
jmx-manager-bind-address jmx-manager-hostname-for-clients jmx-manager-http-port
jmx-manager-password-file jmx-manager-port jmx-manager-ssl-ciphers
jmx-manager-ssl-enabled jmx-manager-ssl-keystore
jmx-manager-ssl-keystore-password jmx-manager-ssl-keystore-type
jmx-manager-ssl-protocols jmx-manager-ssl-require-authentication
jmx-manager-ssl-truststore jmx-manager-ssl-truststore-password
jmx-manager-start jmx-manager-update-rate load-cluster-configuration-from-dir
locator-wait-time locators lock-memory log-disk-space-limit log-file
log-file-size-limit log-level max-num-reconnect-tries max-wait-time-reconnect
mcast-address mcast-flow-control mcast-port mcast-recv-buffer-size
mcast-send-buffer-size mcast-ttl member-timeout membership-port-range
memcached-bind-address memcached-port memcached-protocol name
off-heap-memory-size redundancy-zone remote-locators remove-unresponsive-client
roles security-auth-token-enabled-components security-client-accessor
security-client-accessor-pp security-client-auth-init
security-client-authenticator security-client-dhalgo security-log-file
security-log-level security-manager security-peer-auth-init
security-peer-authenticator security-peer-verifymember-timeout
security-post-processor security-shiro-init security-udp-dhalgo
serializable-object-filter server-bind-address server-ssl-ciphers
server-ssl-enabled server-ssl-keystore server-ssl-keystore-password
server-ssl-keystore-type server-ssl-protocols server-ssl-require-authentication
server-ssl-truststore server-ssl-truststore-password socket-buffer-size
socket-lease-time ssl-ciphers ssl-cluster-alias ssl-default-alias
ssl-enabled-components ssl-endpoint-identification-enabled ssl-gateway-alias
ssl-jmx-alias ssl-keystore ssl-keystore-password ssl-keystore-type
ssl-locator-alias ssl-parameter-extension ssl-protocols
ssl-require-authentication ssl-server-alias ssl-truststore
ssl-truststore-password ssl-truststore-type ssl-use-default-context
ssl-web-alias ssl-web-require-authentication start-dev-rest-api start-locator
statistic-archive-file statistic-sample-rate statistic-sampling-enabled
[jira] [Commented] (GEODE-7891) User Guide refers to non-valid GemFire Properties
[
https://issues.apache.org/jira/browse/GEODE-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485497#comment-17485497
]
John Blum commented on GEODE-7891:
--
Additionally...
{code:java}
Exception in thread "main" java.lang.IllegalArgumentException: Unknown
configuration attribute name
geode.disallow-internal-messages-without-credentials. Valid attribute names
are: ack-severe-alert-threshold ack-wait-threshold archive-disk-space-limit
archive-file-size-limit async-distribution-timeout async-max-queue-size
async-queue-timeout bind-address cache-xml-file cluster-configuration-dir
cluster-ssl-ciphers cluster-ssl-enabled cluster-ssl-keystore
cluster-ssl-keystore-password cluster-ssl-keystore-type cluster-ssl-protocols
cluster-ssl-require-authentication cluster-ssl-truststore
cluster-ssl-truststore-password compatible-with-redis-bind-address
compatible-with-redis-enabled compatible-with-redis-password
compatible-with-redis-port conflate-events conserve-sockets delta-propagation
deploy-working-dir disable-auto-reconnect disable-jmx disable-tcp
distributed-system-id distributed-transactions durable-client-id
durable-client-timeout enable-cluster-configuration
enable-management-rest-service enable-network-partition-detection
enable-time-statistics enforce-unique-host gateway-ssl-ciphers
gateway-ssl-enabled gateway-ssl-keystore gateway-ssl-keystore-password
gateway-ssl-keystore-type gateway-ssl-protocols
gateway-ssl-require-authentication gateway-ssl-truststore
gateway-ssl-truststore-password groups http-service-bind-address
http-service-port http-service-ssl-ciphers http-service-ssl-enabled
http-service-ssl-keystore http-service-ssl-keystore-password
http-service-ssl-keystore-type http-service-ssl-protocols
http-service-ssl-require-authentication http-service-ssl-truststore
http-service-ssl-truststore-password jmx-manager jmx-manager-access-file
jmx-manager-bind-address jmx-manager-hostname-for-clients jmx-manager-http-port
jmx-manager-password-file jmx-manager-port jmx-manager-ssl-ciphers
jmx-manager-ssl-enabled jmx-manager-ssl-keystore
jmx-manager-ssl-keystore-password jmx-manager-ssl-keystore-type
jmx-manager-ssl-protocols jmx-manager-ssl-require-authentication
jmx-manager-ssl-truststore jmx-manager-ssl-truststore-password
jmx-manager-start jmx-manager-update-rate load-cluster-configuration-from-dir
locator-wait-time locators lock-memory log-disk-space-limit log-file
log-file-size-limit log-level max-num-reconnect-tries max-wait-time-reconnect
mcast-address mcast-flow-control mcast-port mcast-recv-buffer-size
mcast-send-buffer-size mcast-ttl member-timeout membership-port-range
memcached-bind-address memcached-port memcached-protocol name
off-heap-memory-size redundancy-zone remote-locators remove-unresponsive-client
roles security-auth-token-enabled-components security-client-accessor
security-client-accessor-pp security-client-auth-init
security-client-authenticator security-client-dhalgo security-log-file
security-log-level security-manager security-peer-auth-init
security-peer-authenticator security-peer-verifymember-timeout
security-post-processor security-shiro-init security-udp-dhalgo
serializable-object-filter server-bind-address server-ssl-ciphers
server-ssl-enabled server-ssl-keystore server-ssl-keystore-password
server-ssl-keystore-type server-ssl-protocols server-ssl-require-authentication
server-ssl-truststore server-ssl-truststore-password socket-buffer-size
socket-lease-time ssl-ciphers ssl-cluster-alias ssl-default-alias
ssl-enabled-components ssl-endpoint-identification-enabled ssl-gateway-alias
ssl-jmx-alias ssl-keystore ssl-keystore-password ssl-keystore-type
ssl-locator-alias ssl-parameter-extension ssl-protocols
ssl-require-authentication ssl-server-alias ssl-truststore
ssl-truststore-password ssl-truststore-type ssl-use-default-context
ssl-web-alias ssl-web-require-authentication start-dev-rest-api start-locator
statistic-archive-file statistic-sample-rate statistic-sampling-enabled
tcp-port thread-monitor-enabled thread-monitor-interval-ms
thread-monitor-time-limit-ms udp-fragment-size udp-recv-buffer-size
udp-send-buffer-size use-cluster-configuration user-command-packages
validate-serializable-objects .
at
org.apache.geode.internal.AbstractConfig.checkAttributeName(AbstractConfig.java:333)
at
org.apache.geode.distributed.internal.AbstractDistributionConfig.checkAttributeName(AbstractDistributionConfig.java:728)
at
org.apache.geode.distributed.internal.AbstractDistributionConfig.getAttributeType(AbstractDistributionConfig.java:890)
at
org.apache.geode.internal.AbstractConfig.setAttribute(AbstractConfig.java:222)
at
org.apache.geode.distributed.internal.DistributionConfigImpl.initialize(DistributionConfigImpl.java:1688)
at
[jira] [Commented] (GEODE-7891) User Guide refers to non-valid GemFire Properties
[
https://issues.apache.org/jira/browse/GEODE-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485450#comment-17485450
]
John Blum commented on GEODE-7891:
--
Given the lack of action / comments on this ticket, I am not sure we are
understanding the gravity of the situation here.
By declaring these properties in {{gemfire.properties}}, Apache Geode will fail
to start (!) as they are considered invalid properties.
For example, given the following test application code using the Apache Geode
API:
{code:java}
public class ApacheGeodePeerCacheApplication {
public static void main(String[] args) {
Cache peerCache = new CacheFactory()
.set("name", "PeerCacheApplicationTest")
.set("tombstone-gc-threshold", "100")
.create();
assertThat(peerCache).isNotNull();
assertThat(peerCache.getName()).isEqualTo("PeerCacheApplicationTest");
}
}
{code}
Running this test application results in the following error:
{code}
Exception in thread "main" java.lang.IllegalArgumentException: Unknown
configuration attribute name tombstone-gc-threshold. Valid attribute names are:
ack-severe-alert-threshold ack-wait-threshold archive-disk-space-limit
archive-file-size-limit async-distribution-timeout async-max-queue-size
async-queue-timeout bind-address cache-xml-file cluster-configuration-dir
cluster-ssl-ciphers cluster-ssl-enabled cluster-ssl-keystore
cluster-ssl-keystore-password cluster-ssl-keystore-type cluster-ssl-protocols
cluster-ssl-require-authentication cluster-ssl-truststore
cluster-ssl-truststore-password compatible-with-redis-bind-address
compatible-with-redis-enabled compatible-with-redis-password
compatible-with-redis-port conflate-events conserve-sockets delta-propagation
deploy-working-dir disable-auto-reconnect disable-jmx disable-tcp
distributed-system-id distributed-transactions durable-client-id
durable-client-timeout enable-cluster-configuration
enable-management-rest-service enable-network-partition-detection
enable-time-statistics enforce-unique-host gateway-ssl-ciphers
gateway-ssl-enabled gateway-ssl-keystore gateway-ssl-keystore-password
gateway-ssl-keystore-type gateway-ssl-protocols
gateway-ssl-require-authentication gateway-ssl-truststore
gateway-ssl-truststore-password groups http-service-bind-address
http-service-port http-service-ssl-ciphers http-service-ssl-enabled
http-service-ssl-keystore http-service-ssl-keystore-password
http-service-ssl-keystore-type http-service-ssl-protocols
http-service-ssl-require-authentication http-service-ssl-truststore
http-service-ssl-truststore-password jmx-manager jmx-manager-access-file
jmx-manager-bind-address jmx-manager-hostname-for-clients jmx-manager-http-port
jmx-manager-password-file jmx-manager-port jmx-manager-ssl-ciphers
jmx-manager-ssl-enabled jmx-manager-ssl-keystore
jmx-manager-ssl-keystore-password jmx-manager-ssl-keystore-type
jmx-manager-ssl-protocols jmx-manager-ssl-require-authentication
jmx-manager-ssl-truststore jmx-manager-ssl-truststore-password
jmx-manager-start jmx-manager-update-rate load-cluster-configuration-from-dir
locator-wait-time locators lock-memory log-disk-space-limit log-file
log-file-size-limit log-level max-num-reconnect-tries max-wait-time-reconnect
mcast-address mcast-flow-control mcast-port mcast-recv-buffer-size
mcast-send-buffer-size mcast-ttl member-timeout membership-port-range
memcached-bind-address memcached-port memcached-protocol name
off-heap-memory-size redundancy-zone remote-locators remove-unresponsive-client
roles security-auth-token-enabled-components security-client-accessor
security-client-accessor-pp security-client-auth-init
security-client-authenticator security-client-dhalgo security-log-file
security-log-level security-manager security-peer-auth-init
security-peer-authenticator security-peer-verifymember-timeout
security-post-processor security-shiro-init security-udp-dhalgo
serializable-object-filter server-bind-address server-ssl-ciphers
server-ssl-enabled server-ssl-keystore server-ssl-keystore-password
server-ssl-keystore-type server-ssl-protocols server-ssl-require-authentication
server-ssl-truststore server-ssl-truststore-password socket-buffer-size
socket-lease-time ssl-ciphers ssl-cluster-alias ssl-default-alias
ssl-enabled-components ssl-endpoint-identification-enabled ssl-gateway-alias
ssl-jmx-alias ssl-keystore ssl-keystore-password ssl-keystore-type
ssl-locator-alias ssl-parameter-extension ssl-protocols
ssl-require-authentication ssl-server-alias ssl-truststore
ssl-truststore-password ssl-truststore-type ssl-use-default-context
ssl-web-alias ssl-web-require-authentication start-dev-rest-api start-locator
statistic-archive-file statistic-sample-rate statistic-sampling-enabled
tcp-port thread-monitor-enabled
[jira] [Updated] (GEODE-7891) User Guide refers to non-valid GemFire Properties
[
https://issues.apache.org/jira/browse/GEODE-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-7891:
-
Description:
The following properties in [GemFire
Properties|https://geode.apache.org/docs/guide/114/reference/topics/gemfire_properties.html]
are *NOT* valid (distributed system/config properties) according to the
[ConfigurationProperties|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java]
and
[DistributionConfig|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java]
classes!
Properties include:
{code:java}
"geode.disallow-internal-messages-without-credentials"
"tombstone-gc-threshold"
{code}
was:
The following properties in [GemFire
Properties|https://geode.apache.org/docs/guide/111/reference/topics/gemfire_properties.html]
are *NOT* valid (distributed system/config properties) according to the
[ConfigurationProperties|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java]
and
[DistributionConfig|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java]
classes!
Properties include:
{code:java}
"geode.disallow-internal-messages-without-credentials"
"tombstone-gc-threshold"
{code}
> User Guide refers to non-valid GemFire Properties
> -
>
> Key: GEODE-7891
> URL: https://issues.apache.org/jira/browse/GEODE-7891
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: John Blum
>Priority: Major
>
> The following properties in [GemFire
> Properties|https://geode.apache.org/docs/guide/114/reference/topics/gemfire_properties.html]
> are *NOT* valid (distributed system/config properties) according to the
> [ConfigurationProperties|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java]
> and
> [DistributionConfig|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java]
> classes!
> Properties include:
> {code:java}
> "geode.disallow-internal-messages-without-credentials"
> "tombstone-gc-threshold"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GEODE-7394) Gfsh `configure pdx` command is non-intuitive and currently has a bad user experience
[
https://issues.apache.org/jira/browse/GEODE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485434#comment-17485434
]
John Blum edited comment on GEODE-7394 at 2/1/22, 7:54 PM:
---
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always supply a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given its foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
simple typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is problematic. Of course, SDG's {{MappingPdxSerializer}}
does not prevent users from using REGEX if they prefer; they can do so inside a
Java {{Predicate}}, and they can compose multiple (chained) {{Predicates}}
together, which effectively simplifies (separates) expressions and/or matching
criteria, making it easier to test.
All {{PdxSerialization}} aside, it is not apparent "how Geode will behave" when
the _Gfsh_ {{configure pdx}} command is used. It is less than obvious what
effect the command has in most cases. Having said this, I have not had to
issue the command in sometime, maybe not since I filed this ticket, so I am not
sure if anything has been updated in this regard.
was (Author: jblum):
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always supply a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given its foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
simple typo in the pattern can compile but
[jira] [Comment Edited] (GEODE-7394) Gfsh `configure pdx` command is non-intuitive and currently has a bad user experience
[
https://issues.apache.org/jira/browse/GEODE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485434#comment-17485434
]
John Blum edited comment on GEODE-7394 at 2/1/22, 7:53 PM:
---
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always supply a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given its foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
simple typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is problematic. Of course, SDG's {{MappingPdxSerializer}}
does not prevent users from using REGEX if they prefer; they can do so inside a
Java {{Predicate}}, and they can use multiple (chained) {{Predicates}}, which
effectively simplifies expressions or matching criteria.
All {{PdxSerialization}} aside, it is not apparent "how Geode will behave" when
the _Gfsh_ {{configure pdx}} command is used. It is less than obvious what
effect the command has in most cases. Having said this, I have not had to
issue the command in sometime, maybe not since I filed this ticket, so I am not
sure if anything has been updated in this regard.
was (Author: jblum):
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always supply a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given its foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is
[jira] [Comment Edited] (GEODE-7394) Gfsh `configure pdx` command is non-intuitive and currently has a bad user experience
[
https://issues.apache.org/jira/browse/GEODE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485434#comment-17485434
]
John Blum edited comment on GEODE-7394 at 2/1/22, 7:53 PM:
---
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always supply a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given its foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is problematic. Of course, SDG's {{MappingPdxSerializer}}
does not prevent users from using REGEX if they prefer; they can do so inside a
Java {{Predicate}}, and they can use multiple (chained) {{Predicates}}, which
effectively simplifies expressions or matching criteria.
All {{PdxSerialization}} aside, it is not apparent "how Geode will behave" when
the _Gfsh_ {{configure pdx}} command is used. It is less than obvious what
effect the command has in most cases. Having said this, I have not had to
issue the command in sometime, maybe not since I filed this ticket, so I am not
sure if anything has been updated in this regard.
was (Author: jblum):
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always supply a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given is foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is
[jira] [Comment Edited] (GEODE-7394) Gfsh `configure pdx` command is non-intuitive and currently has a bad user experience
[
https://issues.apache.org/jira/browse/GEODE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485434#comment-17485434
]
John Blum edited comment on GEODE-7394 at 2/1/22, 7:52 PM:
---
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always supply a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given is foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is problematic. Of course, SDG's {{MappingPdxSerializer}}
does not prevent users from using REGEX if they prefer; they can do so inside a
Java {{Predicate}}, and they can use multiple (chained) {{Predicates}}, which
effectively simplifies expressions or matching criteria.
All {{PdxSerialization}} aside, it is not apparent "how Geode will behave" when
the _Gfsh_ {{configure pdx}} command is used. It is less than obvious what
effect the command has in most cases. Having said this, I have not had to
issue the command in sometime, maybe not since I filed this ticket, so I am not
sure if anything has been updated in this regard.
was (Author: jblum):
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always provided a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given is foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is
[jira] [Comment Edited] (GEODE-7394) Gfsh `configure pdx` command is non-intuitive and currently has a bad user experience
[
https://issues.apache.org/jira/browse/GEODE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485434#comment-17485434
]
John Blum edited comment on GEODE-7394 at 2/1/22, 7:51 PM:
---
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always provided a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given is foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is problematic. Of course, SDG's {{MappingPdxSerializer}}
does not prevent users from using REGEX if they prefer; they can do so inside a
Java {{Predicate}}, and they can use multiple (chained) {{Predicates}}, which
effectively simplifies expressions or matching criteria.
All {{PdxSerialization}} aside, it is not apparent "how Geode will behave" when
the _Gfsh_ {{configure pdx}} command is used. It is less than obvious what
effect the command has in most cases. Having said this, I have not had to
issue the command in sometime, maybe not since I filed this ticket, so I am not
sure if anything has been updated in this regard.
was (Author: jblum):
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users. For one, it
unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always provided a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given is foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is
[jira] [Commented] (GEODE-7394) Gfsh `configure pdx` command is non-intuitive and currently has a bad user experience
[
https://issues.apache.org/jira/browse/GEODE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485434#comment-17485434
]
John Blum commented on GEODE-7394:
--
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users. For one, it
unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always provided a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given is foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is problematic. Of course, SDG's {{MappingPdxSerializer}}
does not prevent users from using REGEX if they prefer; they can do so inside a
Java {{Predicate}}, and they can use multiple (chained) {{Predicates}}, which
effectively simplifies expressions or matching criteria.
All {{PdxSerialization}} aside, it is not apparent "how Geode will behave" when
the _Gfsh_ {{configure pdx}} command is used. It is less than obvious what
effect the command has in most cases. Having said this, I have not had to
issue the command in sometime, maybe not since I filed this ticket, so I am not
sure if anything has been updated in this regard.
> Gfsh `configure pdx` command is non-intuitive and currently has a bad user
> experience
> -
>
> Key: GEODE-7394
> URL: https://issues.apache.org/jira/browse/GEODE-7394
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: John Blum
>Priority: Major
>
> The _Gfsh_ {{configure pdx}} command does *not* register a {{PdxSerializer}}
> (e.g. {{ReflectionBasedAutoSerializer}}, or otherwise) unless the
> {{--auto-serializable-classes}} option is explicitly specified. Without a
> {{PdxSerializer}} the command essentially serves no purpose nor has any
> effect. Effectively, the command is useless.
> For example, doing something like `gfsh> configure pdx
> --read-serialized=false` or `gfsh> configure pdx --ignore-unread-fields` by
> itself is *pointless* since ultimately there would be no `PdxSerializer`
> registered in this case.
> _Gfsh_ should minimally register a `PdxSerializer` anytime the `configure
> pdx` command is used regardless of the options provided, especially if it
> returns successfully without incident. For instance, it could register the
> `ReflectionBaseAutoSerializer` with the REGEX {{.*}} (de/serializing all
> types, regardless of whether that is optimal or not).
> Alternatively, if we decide not to register the
> {{ReflectionBasedAutoSerialier}} with a generic REGEX (e.g. {{.*}}), then we
> should _fail-fast_ and the command should report that
> {{--[portable-]-auto-serializable-classes}} is required!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GEODE-7381) PDX Serialization throws an Exception with an incorrect error message when a domain type does not have a public, no-arg constructor
[
https://issues.apache.org/jira/browse/GEODE-7381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964234#comment-16964234
]
John Blum edited comment on GEODE-7381 at 2/1/22, 7:29 PM:
---
Technically, there is no logical reason why the constructor needs to be public
in the first place. Java Introspection & Reflection facilities allow all
members of a class type to be inspected *and* invoked.
Also there is no reason why the constructor needs to be no-arg either. See
[GEODE-7382].
was (Author: jblum):
Technically, there is not logical reason why the constructor needs to be public
in the first place. Java Introspection & Reflection facilities allow all
members of a class type to be inspected *and* invoked.
Also there is no reason why the constructor needs to be no-arg either. See
[GEODE-7382].
> PDX Serialization throws an Exception with an incorrect error message when a
> domain type does not have a public, no-arg constructor
> ---
>
> Key: GEODE-7381
> URL: https://issues.apache.org/jira/browse/GEODE-7381
> Project: Geode
> Issue Type: Bug
>Reporter: John Blum
>Priority: Major
>
> Apache Geode throws an incorrect {{PdxSerializationException}} with message
> "_Could not deserialize pdx because the pdx serializer's fromData returned
> false for a pdx of class com.springone.austin.vursys.battle.model.Vote_",
> instead.
> The Stack Trace is:
> {code:java}
> Caused by: org.apache.geode.pdx.PdxSerializationException: Could not
> deserialize pdx because the pdx serializer's fromData returned false for a
> pdx of class com.springone.austin.vursys.battle.model.Vote
> at
> org.apache.geode.pdx.internal.PdxReaderImpl.basicGetObject(PdxReaderImpl.java:823)
> at
> org.apache.geode.pdx.internal.PdxReaderImpl.getObject(PdxReaderImpl.java:753)
> at
> org.apache.geode.internal.InternalDataSerializer.readPdxSerializable(InternalDataSerializer.java:3153)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2916)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:90)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2013)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2006)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getDeserializedValue(VMCachedDeserializable.java:132)
> at
> org.apache.geode.internal.cache.LocalRegion.getDeserialized(LocalRegion.java:1336)
> at
> org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:91)
> at
> org.apache.geode.internal.cache.LocalDataSet$LocalEntriesSet$LocalEntriesSetIterator.moveNext(LocalDataSet.java:781)
> at
> org.apache.geode.internal.cache.LocalDataSet$LocalEntriesSet$LocalEntriesSetIterator.(LocalDataSet.java:735)
> at
> org.apache.geode.internal.cache.LocalDataSet$LocalEntriesSet.iterator(LocalDataSet.java:722)
> at
> org.apache.geode.cache.query.internal.ResultsCollectionWrapper.iterator(ResultsCollectionWrapper.java:199)
> at
> org.apache.geode.cache.query.internal.QRegion.iterator(QRegion.java:282)
> at
> org.apache.geode.cache.query.internal.CompiledSelect.doNestedIterations(CompiledSelect.java:834)
> at
> org.apache.geode.cache.query.internal.CompiledSelect.doIterationEvaluate(CompiledSelect.java:701)
> at
> org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:545)
> at
> org.apache.geode.cache.query.internal.CompiledGroupBySelect.evaluate(CompiledGroupBySelect.java:157)
> at
> org.apache.geode.cache.query.internal.CompiledGroupBySelect.evaluate(CompiledGroupBySelect.java:42)
> at
> org.apache.geode.cache.query.internal.DefaultQuery.executeUsingContext(DefaultQuery.java:430)
> at
> org.apache.geode.internal.cache.PRQueryProcessor.executeQueryOnBuckets(PRQueryProcessor.java:246)
> at
> org.apache.geode.internal.cache.PRQueryProcessor.executeSequentially(PRQueryProcessor.java:204)
> at
> org.apache.geode.internal.cache.PRQueryProcessor.executeQuery(PRQueryProcessor.java:122)
> at
> org.apache.geode.internal.cache.PartitionedRegionQueryEvaluator.executeQueryOnLocalNode(PartitionedRegionQueryEvaluator.java:962)
> at
> org.apache.geode.internal.cache.PartitionedRegionQueryEvaluator.executeQueryOnRemoteAndLocalNodes(PartitionedRegionQueryEvaluator.java:378)
> at
> org.apache.geode.internal.cache.PartitionedRegionQueryEvaluator.queryBuckets(PartitionedRegionQueryEvaluator.java:495)
> at
>
[jira] [Comment Edited] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485002#comment-17485002
]
John Blum edited comment on GEODE-10005 at 2/1/22, 7:25 PM:
Part of the requirement to upgrade *Eclipse Jetty* in Apache Geode in order to
release SBDG {{2.0}} stems from *Eclipse Jetty's* support of *Jakarta EE 9*,
replacing the old _Java EE 8_ specifications (see
[here|https://eclipse-foundation.blog/2021/03/24/eclipse-jetty-11-supports-the-big-bang/]
and
[here|https://containerjournal.com/features/jetty-project-embraces-jakarta-ee-9-specification/]).
was (Author: jblum):
Part of the requirement to upgrade *Eclipse Jetty* in Apache Geode in order to
release SBDG {{2.0}} stems from *Eclipse Jetty's* support of *Jakarta EE 9*,
replacing the old _Java EE 8_ (see
[here|https://eclipse-foundation.blog/2021/03/24/eclipse-jetty-11-supports-the-big-bang/]
and
[here|https://containerjournal.com/features/jetty-project-embraces-jakarta-ee-9-specification/]).
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Blocker
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10006) Do not configure Geode JTA transaction management by default
[ https://issues.apache.org/jira/browse/GEODE-10006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-10006: -- Priority: Critical (was: Major) > Do not configure Geode JTA transaction management by default > > > Key: GEODE-10006 > URL: https://issues.apache.org/jira/browse/GEODE-10006 > Project: Geode > Issue Type: Improvement >Reporter: John Blum >Priority: Critical > > Geode's built-in JTA transaction management and JNDI context registrations > are unnecessary unless Apache Geode is being used in the context of JTA > transactions (along with other JTA transactional compliant resources that > must all be associated with the same logical transaction) in the first place. > JTA is an overly complex application architectural design, is error prone to > use correctly at best, and with the advent of Microservices, has become > increasingly unpopular for managing consistency across 2 or more > transactional resources. > Additionally, Apache Geode's transaction manager should never be used as the > JTA transaction manager implementation. > The logic to initiate JTA transactional logic in Apache Geode resides in the > [JNDIInvoker|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/jndi/JNDIInvoker.java] > class and > [initiated|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L875](specifically, > > [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L964]) > during cache creation and initialization. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such by via the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used inn Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such by via the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of the SPI used on Apache Geode, which are part of the
non-internal, public API, for example the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such by via the
> _Java_ {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. This allows any application, framework, tool or product a degree of
> extensibility and flexibility, afforded to users without intervention by
> being able to "provide" a custom implementation or extension as needed by the
> application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such by via the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of the SPI used on Apache Geode, which are part of the
non-internal, public API, for example the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such by via the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the HTTP service hosting the Geode provided Web apps
(e.g. Pulse, Management/Admin REST API, Developer REST API). Of course, these
Web apps need to be updated as well (to use the new Jakarta EE 9 specs).
There are other examples of the SPI used on Apache Geode, which are part of the
non-internal, public API, for example the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such by via the
> _Java_ {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. This allows any application, framework, tool or product a degree of
> extensibility and flexibility, afforded to users without intervention by
> being able to "provide" a custom implementation or extension as needed by the
> application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to bootstrap the embedded HTTP service hosting the
> Geode
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such by via the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the HTTP service hosting the Geode provided Web apps
(e.g. Pulse, Management/Admin REST API, Developer REST API). Of course, these
Web apps need to be updated as well (to use the new Jakarta EE 9 specs).
There are other examples of the SPI used on Apache Geode, which are part of the
non-internal, public API, for example the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such by via the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the HTTP service hosting the Geode provided Web apps
(e.g. Pulse, Management/Admin REST API, Developer REST API). Of course, these
Web apps need to be updated as well (to use the new Jakarta EE 9 specs).
There are other examples of the SPI used on Apache Geode, which are part of the
non-internal, public API, for example the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such by via the
> _Java_ {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. This allows any application, framework, tool or product a degree of
> extensibility and flexibility, afforded to users without intervention by
> being able to "provide" a custom implementation or extension as needed by the
> application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to bootstrap the HTTP service hosting the Geode
> provided Web apps (e.g. Pulse, Management/Admin REST API, Developer REST
> API). Of course, these Web apps need to be updated as well (to use the new
> Jakarta EE 9 specs).
>
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such by via the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the HTTP service hosting the Geode provided Web apps
(e.g. Pulse, Management/Admin REST API, Developer REST API). Of course, these
Web apps need to be updated as well (to use the new Jakarta EE 9 specs).
There are other examples of the SPI used on Apache Geode, which are part of the
non-internal, public API, for example the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) and even loaded as such by via the _Java_ {{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the HTTP service hosting the Geode provided Web apps
(e.g. Pulse, Management/Admin REST API, Developer REST API). Of course, these
Web apps need to be updated as well (to use the new Jakarta EE 9 specs).
There are other examples of the SPI used on Apache Geode, which are part of the
non-internal, public API, for example the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such by via the
> _Java_ {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. This allows any application, framework, tool or product a degree of
> extensibility and flexibility, afforded to users without intervention.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to bootstrap the HTTP service hosting the Geode
> provided Web apps (e.g. Pulse, Management/Admin REST API, Developer REST
> API). Of course, these Web apps need to be updated as well (to use the new
> Jakarta EE 9 specs).
> There are other examples of the SPI used on Apache Geode, which are part of
> the non-internal, public API, for example the
> [ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
>
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Summary: Make o.a.geode.cache.internal.HttpService SPI part of the
non-internal, public API (was: o.a.geode.cache.internal.HttpService should be
part of the API)
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) and even loaded as such by via the _Java_ {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. This allows any application, framework, tool or product a degree of
> extensibility and flexibility, afforded to users without intervention.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to bootstrap the HTTP service hosting the Geode
> provided Web apps (e.g. Pulse, Management/Admin REST API, Developer REST
> API). Of course, these Web apps need to be updated as well (to use the new
> Jakarta EE 9 specs).
> There are other examples of the SPI used on Apache Geode, which are part of
> the non-internal, public API, for example the
> [ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
> interface, with 1 such
> [implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
> provided by _Spring Data for Apache Geode_ (SDG) even.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10007) o.a.geode.cache.internal.HttpService should be part of the API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Priority: Minor (was: Major)
> o.a.geode.cache.internal.HttpService should be part of the API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) and even loaded as such by via the _Java_ {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. This allows any application, framework, tool or product a degree of
> extensibility and flexibility, afforded to users without intervention.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to bootstrap the HTTP service hosting the Geode
> provided Web apps (e.g. Pulse, Management/Admin REST API, Developer REST
> API). Of course, these Web apps need to be updated as well (to use the new
> Jakarta EE 9 specs).
> There are other examples of the SPI used on Apache Geode, which are part of
> the non-internal, public API, for example the
> [ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
> interface, with 1 such
> [implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
> provided by _Spring Data for Apache Geode_ (SDG) even.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10007) o.a.geode.cache.internal.HttpService should be part of the API
John Blum created GEODE-10007:
-
Summary: o.a.geode.cache.internal.HttpService should be part of
the API
Key: GEODE-10007
URL: https://issues.apache.org/jira/browse/GEODE-10007
Project: Geode
Issue Type: Improvement
Reporter: John Blum
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) and even loaded as such by via the _Java_ {{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the HTTP service hosting the Geode provided Web apps
(e.g. Pulse, Management/Admin REST API, Developer REST API). Of course, these
Web apps need to be updated as well (to use the new Jakarta EE 9 specs).
There are other examples of the SPI used on Apache Geode, which are part of the
non-internal, public API, for example the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10005:
--
Priority: Blocker (was: Major)
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Blocker
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485002#comment-17485002
]
John Blum commented on GEODE-10005:
---
Part of the requirement to upgrade *Eclipse Jetty* in Apache Geode in order to
release SBDG {{2.0}} stems from *Eclipse Jetty's* support of *Jakarta EE 9*,
replacing the old _Java EE 8_ (see
[here|https://eclipse-foundation.blog/2021/03/24/eclipse-jetty-11-supports-the-big-bang/]
and
[here|https://containerjournal.com/features/jetty-project-embraces-jakarta-ee-9-specification/]).
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Major
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485001#comment-17485001
]
John Blum commented on GEODE-10005:
---
Apache Geode 1.14.3 (current release at this time) is currently based on
*Eclipse Jetty* {{9.4.39.v20210325}} (see
[here|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L425-L429]).
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Major
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10006) Do not configure Geode JTA transaction management by default
[ https://issues.apache.org/jira/browse/GEODE-10006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-10006: -- Summary: Do not configure Geode JTA transaction management by default (was: Remove default configuration of Geode JTA transaction management) > Do not configure Geode JTA transaction management by default > > > Key: GEODE-10006 > URL: https://issues.apache.org/jira/browse/GEODE-10006 > Project: Geode > Issue Type: Improvement >Reporter: John Blum >Priority: Major > > Geode's built-in JTA transaction management and JNDI context registrations > are unnecessary unless Apache Geode is being used in the context of JTA > transactions (along with other JTA transactional compliant resources that > must all be associated with the same logical transaction) in the first place. > JTA is an overly complex application architectural design, is error prone to > use correctly at best, and with the advent of Microservices, has become > increasingly unpopular for managing consistency across 2 or more > transactional resources. > Additionally, Apache Geode's transaction manager should never be used as the > JTA transaction manager implementation. > The logic to initiate JTA transactional logic in Apache Geode resides in the > [JNDIInvoker|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/jndi/JNDIInvoker.java] > class and > [initiated|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L875](specifically, > > [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L964]) > during cache creation and initialization. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10006) Remove default configuration of Geode JTA transaction management
John Blum created GEODE-10006: - Summary: Remove default configuration of Geode JTA transaction management Key: GEODE-10006 URL: https://issues.apache.org/jira/browse/GEODE-10006 Project: Geode Issue Type: Improvement Reporter: John Blum Geode's built-in JTA transaction management and JNDI context registrations are unnecessary unless Apache Geode is being used in the context of JTA transactions (along with other JTA transactional compliant resources that must all be associated with the same logical transaction) in the first place. JTA is an overly complex application architectural design, is error prone to use correctly at best, and with the advent of Microservices, has become increasingly unpopular for managing consistency across 2 or more transactional resources. Additionally, Apache Geode's transaction manager should never be used as the JTA transaction manager implementation. The logic to initiate JTA transactional logic in Apache Geode resides in the [JNDIInvoker|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/jndi/JNDIInvoker.java] class and [initiated|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L875](specifically, [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L964]) during cache creation and initialization. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
John Blum created GEODE-10005:
-
Summary: Upgrade to Eclipse Jetty 11.0.x
Key: GEODE-10005
URL: https://issues.apache.org/jira/browse/GEODE-10005
Project: Geode
Issue Type: Improvement
Reporter: John Blum
In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
_Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
Boot's_ minimum [(major.mionr)
version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9657) Javadoc errors occur on Java 17 due to split packages in Geode
[
https://issues.apache.org/jira/browse/GEODE-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-9657:
-
Priority: Blocker (was: Major)
> Javadoc errors occur on Java 17 due to split packages in Geode
> --
>
> Key: GEODE-9657
> URL: https://issues.apache.org/jira/browse/GEODE-9657
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.13.4, 1.14.0
>Reporter: John Blum
>Priority: Blocker
> Labels: needsTriage
>
> When trying to build any library, framework (e.g. _Spring Data for Apache
> Geode_ (SDG)) or application with Apache Geode on Java 17, Javadoc errors
> occur.
> For example:
> {code}
> 22:36:52 [ERROR]
> /opt/jenkins/data/workspace/spring-data-geode_3.0.x/spring-data-geode/src/main/java/org/springframework/data/gemfire/function/PojoFunctionWrapper.java:53:
> error: cannot access Identifiable
> 22:36:52 [ERROR] public class PojoFunctionWrapper implements Function {
> 22:36:52 [ERROR]^
> 22:36:52 [ERROR] class file for org.apache.geode.lang.Identifiable not
> found
> {code}
> As it turns out, in Java 17, the _Javadoc_ tool now uses _Java_ modules.
> _Javadoc_ is started with:
> {code}
> javadoc … --add-modules ALL-MODULE-PATH --module-path --patch-module …
> {code}
> {{geode-core-1.14.0.jar}} ships
> {{org.apache.geode.lang.AttachAPINotFoundException}} and
> {{geode-common-1.14.0.jar}} ships {{org.apache.geode.lang.Identifiable}}. Due
> to this split-package arrangement, _Javadoc_ isn’t discovering
> {{Identifiable}} because it has found the package {{org.apache.geode.lang}}
> in {{geode-core-1.14.0.jar}}.
> The best course of action is to make sure all {{org.apache.geode.lang}}
> sub-packages and class are in 1 JAR (e.g. {{geode-common}}) or the other
> (i.e. {{geode-core}}).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9657) Javadoc errors occur on Java 17 due to split packages in Geode
John Blum created GEODE-9657:
Summary: Javadoc errors occur on Java 17 due to split packages in
Geode
Key: GEODE-9657
URL: https://issues.apache.org/jira/browse/GEODE-9657
Project: Geode
Issue Type: Bug
Components: core
Affects Versions: 1.14.0, 1.13.4
Reporter: John Blum
When trying to build any library, framework (e.g. _Spring Data for Apache
Geode_ (SDG)) or application with Apache Geode on Java 17, Javadoc errors occur.
For example:
{code}
22:36:52 [ERROR]
/opt/jenkins/data/workspace/spring-data-geode_3.0.x/spring-data-geode/src/main/java/org/springframework/data/gemfire/function/PojoFunctionWrapper.java:53:
error: cannot access Identifiable
22:36:52 [ERROR] public class PojoFunctionWrapper implements Function {
22:36:52 [ERROR]^
22:36:52 [ERROR] class file for org.apache.geode.lang.Identifiable not found
{code}
As it turns out, in Java 17, the _Javadoc_ tool now uses _Java_ modules.
_Javadoc_ is started with:
{code}
javadoc … --add-modules ALL-MODULE-PATH --module-path --patch-module …
{code}
{{geode-core-1.14.0.jar}} ships
{{org.apache.geode.lang.AttachAPINotFoundException}} and
{{geode-common-1.14.0.jar}} ships {{org.apache.geode.lang.Identifiable}}. Due
to this split-package arrangement, _Javadoc_ isn’t discovering {{Identifiable}}
because it has found the package {{org.apache.geode.lang}} in
{{geode-core-1.14.0.jar}}.
The best course of action is to make sure all {{org.apache.geode.lang}}
sub-packages and class are in 1 JAR (e.g. {{geode-common}}) or the other (i.e.
{{geode-core}}).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9657) Javadoc errors occur on Java 17 due to split packages in Geode
[
https://issues.apache.org/jira/browse/GEODE-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-9657:
-
Priority: Major (was: Blocker)
> Javadoc errors occur on Java 17 due to split packages in Geode
> --
>
> Key: GEODE-9657
> URL: https://issues.apache.org/jira/browse/GEODE-9657
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.13.4, 1.14.0
>Reporter: John Blum
>Priority: Major
> Labels: needsTriage
>
> When trying to build any library, framework (e.g. _Spring Data for Apache
> Geode_ (SDG)) or application with Apache Geode on Java 17, Javadoc errors
> occur.
> For example:
> {code}
> 22:36:52 [ERROR]
> /opt/jenkins/data/workspace/spring-data-geode_3.0.x/spring-data-geode/src/main/java/org/springframework/data/gemfire/function/PojoFunctionWrapper.java:53:
> error: cannot access Identifiable
> 22:36:52 [ERROR] public class PojoFunctionWrapper implements Function {
> 22:36:52 [ERROR]^
> 22:36:52 [ERROR] class file for org.apache.geode.lang.Identifiable not
> found
> {code}
> As it turns out, in Java 17, the _Javadoc_ tool now uses _Java_ modules.
> _Javadoc_ is started with:
> {code}
> javadoc … --add-modules ALL-MODULE-PATH --module-path --patch-module …
> {code}
> {{geode-core-1.14.0.jar}} ships
> {{org.apache.geode.lang.AttachAPINotFoundException}} and
> {{geode-common-1.14.0.jar}} ships {{org.apache.geode.lang.Identifiable}}. Due
> to this split-package arrangement, _Javadoc_ isn’t discovering
> {{Identifiable}} because it has found the package {{org.apache.geode.lang}}
> in {{geode-core-1.14.0.jar}}.
> The best course of action is to make sure all {{org.apache.geode.lang}}
> sub-packages and class are in 1 JAR (e.g. {{geode-common}}) or the other
> (i.e. {{geode-core}}).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9393) Apache Geode does not build/run on Java 16/17
[
https://issues.apache.org/jira/browse/GEODE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-9393:
-
Summary: Apache Geode does not build/run on Java 16/17 (was: Apache Geode
does not run on Java 16)
> Apache Geode does not build/run on Java 16/17
> -
>
> Key: GEODE-9393
> URL: https://issues.apache.org/jira/browse/GEODE-9393
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.13.2
>Reporter: John Blum
>Priority: Blocker
> Labels: Java16
>
> Due to Java 16 tightened restrictions, Apache Geode fails to run on a Java 16
> Runtime (JRE).
> Exceptions like the following are thrown:
> {code}
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> - at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> - at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> - at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
> - at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2050)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> - at
> org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
> - at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> - at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
> - at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> - at java.base/java.lang.Thread.run(Thread.java:831)
> - Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @40f9161a
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> - at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> - at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> - ... 22 common frames omitted
> - 2021-04-30 14:57:13,638 INFO ributed.internal.membership.gms.Services: 606
> - received leave request from
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> - 2021-04-30 14:57:13,640 INFO ributed.internal.membership.gms.Services: 617
> - JoinLeave.processMessage(LeaveRequestMessage) invoked. isCoordinator=true;
> isStopping=false; cancelInProgress=false
> - 2021-04-30 14:57:13,647 ERROR xecutors.LoggingUncaughtExceptionHandler: 92
> - Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> shared unordered uid=1 local port=53039 remote port=64063,10,main]
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
>
[jira] [Updated] (GEODE-7891) User Guide refers to non-valid GemFire Properties
[
https://issues.apache.org/jira/browse/GEODE-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-7891:
-
Priority: Major (was: Minor)
> User Guide refers to non-valid GemFire Properties
> -
>
> Key: GEODE-7891
> URL: https://issues.apache.org/jira/browse/GEODE-7891
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: John Blum
>Priority: Major
>
> The following properties in [GemFire
> Properties|https://geode.apache.org/docs/guide/111/reference/topics/gemfire_properties.html]
> are *NOT* valid (distributed system/config properties) according to the
> [ConfigurationProperties|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java]
> and
> [DistributionConfig|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java]
> classes!
> Properties include:
> {code:java}
> "geode.disallow-internal-messages-without-credentials"
> "tombstone-gc-threshold"
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7891) User Guide refers to non-valid GemFire Properties
[
https://issues.apache.org/jira/browse/GEODE-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-7891:
-
Priority: Minor (was: Major)
> User Guide refers to non-valid GemFire Properties
> -
>
> Key: GEODE-7891
> URL: https://issues.apache.org/jira/browse/GEODE-7891
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: John Blum
>Priority: Minor
>
> The following properties in [GemFire
> Properties|https://geode.apache.org/docs/guide/111/reference/topics/gemfire_properties.html]
> are *NOT* valid (distributed system/config properties) according to the
> [ConfigurationProperties|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java]
> and
> [DistributionConfig|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java]
> classes!
> Properties include:
> {code:java}
> "geode.disallow-internal-messages-without-credentials"
> "tombstone-gc-threshold"
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8256) The Jackson ObjectMapper used by a PdxInstance does not properly handle Java 8 Types
[
https://issues.apache.org/jira/browse/GEODE-8256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8256:
-
Priority: Blocker (was: Critical)
> The Jackson ObjectMapper used by a PdxInstance does not properly handle Java
> 8 Types
>
>
> Key: GEODE-8256
> URL: https://issues.apache.org/jira/browse/GEODE-8256
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.9.2, 1.10.0, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Blocker
> Labels: JSON-PDX
>
> The Jackson {{ObjectMapper}} in the {{PdxInstanceImpl}} class (see
> [here|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/pdx/internal/PdxInstanceImpl.java#L68-L75])is
> not properly configured.
> Specifically, it cannot handle *Java 8* types since these types are not
> included in Jackson 2, by default, primarily because Jackson 2 is based on
> Java 6 (not Java 8). However, that does not mean Jackson 2 cannot handle
> Java 8 types, when configured properly with extension modules.
> To make matters worse, the {{ObjectMapper}} used by PDX, and specifically the
> {{PdxInstance}} implementation, violates the _Open/Closed_ software design
> principle, so there is literally no way to modify (i.e. override/extend) the
> configuration of the {{ObjectMapper}} as required by the application.
> See
> [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L583-L618]
> for a test case demonstrating the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9393) Apache Geode does not run on Java 16
[
https://issues.apache.org/jira/browse/GEODE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370932#comment-17370932
]
John Blum commented on GEODE-9393:
--
Encountered another Exception:
{code}
Caused by: org.apache.geode.cache.client.ServerOperationException: remote
server on
10.99.199.28(ClientCacheApplication:98687:loner):62805:d511d954:ClientCacheApplication:
Region /Users removeAll at server applied partial keys due to exception.
at
org.apache.geode.internal.cache.LocalRegion.basicRemoveAll(LocalRegion.java:9207)
at
org.apache.geode.internal.cache.LocalRegion.removeAll(LocalRegion.java:8917)
at
org.apache.geode.internal.cache.LocalRegion.removeAll(LocalRegion.java:8908)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
... 55 more
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
static final char[] java.lang.Integer.digits accessible: module java.base does
not "opens java.lang" to unnamed module @12e61fe6
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at
java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:177)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:171)
at
org.apache.geode.internal.size.ObjectTraverser.buildFieldSet(ObjectTraverser.java:117)
at
org.apache.geode.internal.size.ObjectTraverser.cacheFieldSet(ObjectTraverser.java:92)
at
org.apache.geode.internal.size.ObjectTraverser.doSearch(ObjectTraverser.java:65)
at
org.apache.geode.internal.size.ObjectTraverser.breadthFirstSearch(ObjectTraverser.java:54)
at
org.apache.geode.internal.size.ObjectGraphSizer.size(ObjectGraphSizer.java:101)
at
org.apache.geode.internal.size.ReflectionObjectSizer.sizeof(ReflectionObjectSizer.java:76)
at
org.apache.geode.internal.size.SizeClassOnceObjectSizer.sizeof(SizeClassOnceObjectSizer.java:63)
at
org.apache.geode.internal.cache.TombstoneService$Tombstone.getSize(TombstoneService.java:398)
at
org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.scheduleTombstone(TombstoneService.java:982)
at
org.apache.geode.internal.cache.TombstoneService.scheduleTombstone(TombstoneService.java:196)
at
org.apache.geode.internal.cache.LocalRegion.scheduleTombstone(LocalRegion.java:3298)
at
org.apache.geode.internal.cache.entries.AbstractRegionEntry.makeTombstone(AbstractRegionEntry.java:265)
at
org.apache.geode.internal.cache.entries.AbstractRegionEntry.destroy(AbstractRegionEntry.java:879)
at
org.apache.geode.internal.cache.map.RegionMapDestroy.destroyEntry(RegionMapDestroy.java:734)
at
org.apache.geode.internal.cache.map.RegionMapDestroy.destroyExistingEntry(RegionMapDestroy.java:392)
at
org.apache.geode.internal.cache.map.RegionMapDestroy.handleExistingRegionEntry(RegionMapDestroy.java:244)
at
org.apache.geode.internal.cache.map.RegionMapDestroy.destroy(RegionMapDestroy.java:152)
at
org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:968)
at
org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6500)
at
org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6474)
at
org.apache.geode.internal.cache.BucketRegion.basicDestroy(BucketRegion.java:1194)
at
org.apache.geode.internal.cache.PartitionedRegionDataStore.destroyLocally(PartitionedRegionDataStore.java:1345)
at
org.apache.geode.internal.cache.PartitionedRegionDataView.destroyOnRemote(PartitionedRegionDataView.java:104)
at
org.apache.geode.internal.cache.partitioned.RemoveAllPRMessage.doLocalRemoveAll(RemoveAllPRMessage.java:462)
at
org.apache.geode.internal.cache.PartitionedRegion.tryToSendOneRemoveAllMessage(PartitionedRegion.java:2853)
at
org.apache.geode.internal.cache.PartitionedRegion.sendMsgByBucket(PartitionedRegion.java:2732)
at
org.apache.geode.internal.cache.PartitionedRegion.postRemoveAllSend(PartitionedRegion.java:2453)
at
org.apache.geode.internal.cache.LocalRegionDataView.postRemoveAll(LocalRegionDataView.java:380)
at
org.apache.geode.internal.cache.LocalRegion.basicRemoveAll(LocalRegion.java:9364)
at
org.apache.geode.internal.cache.LocalRegion.basicBridgeRemoveAll(LocalRegion.java:8851)
at
[jira] [Updated] (GEODE-9394) Apache Geode does not properly cleanup its SSL context between runs
[
https://issues.apache.org/jira/browse/GEODE-9394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-9394:
-
Summary: Apache Geode does not properly cleanup its SSL context between
runs (was: Apache Geode does not properly cleanup it's SSL context between
runs)
> Apache Geode does not properly cleanup its SSL context between runs
> ---
>
> Key: GEODE-9394
> URL: https://issues.apache.org/jira/browse/GEODE-9394
> Project: Geode
> Issue Type: Bug
> Components: security
>Reporter: John Blum
>Priority: Critical
>
> Because Geode internally uses may statics to maintain state and to pass
> configuration between components in a non-Object Oriented fashion, I believe
> stale SSL configuration is being retained between Geode instance runs,
> leading to Exceptions thrown of the following nature:
> {code}
> Caused by: org.apache.geode.GemFireConfigException: Error configuring GemFire
> ssl
> at
> org.apache.geode.internal.net.SocketCreator.initialize(SocketCreator.java:249)
> at
> org.apache.geode.internal.net.SocketCreator.(SocketCreator.java:180)
> at
> org.apache.geode.internal.net.SocketCreatorFactory.createSSLSocketCreator(SocketCreatorFactory.java:114)
> at
> org.apache.geode.internal.net.SocketCreatorFactory.getSSLSocketCreator(SocketCreatorFactory.java:88)
> at
> org.apache.geode.internal.net.SocketCreatorFactory.getOrCreateSocketCreatorForSSLEnabledComponent(SocketCreatorFactory.java:104)
> at
> org.apache.geode.internal.net.SocketCreatorFactory.getSocketCreatorForComponent(SocketCreatorFactory.java:74)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.(ConnectionFactoryImpl.java:84)
> at
> org.apache.geode.cache.client.internal.PoolImpl.(PoolImpl.java:261)
> at
> org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:161)
> at
> org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:374)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.determineDefaultPool(GemFireCacheImpl.java:2835)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getDefaultPool(GemFireCacheImpl.java:1321)
> at
> org.apache.geode.cache.client.internal.ClientRegionFactoryImpl.getDefaultPool(ClientRegionFactoryImpl.java:101)
> at
> org.apache.geode.cache.client.internal.ClientRegionFactoryImpl.createRegionAttributes(ClientRegionFactoryImpl.java:249)
> at
> org.apache.geode.cache.client.internal.ClientRegionFactoryImpl.create(ClientRegionFactoryImpl.java:232)
> at
> org.springframework.data.gemfire.client.ClientRegionFactoryBean.newRegion(ClientRegionFactoryBean.java:193)
> at
> org.springframework.data.gemfire.client.ClientRegionFactoryBean.createRegion(ClientRegionFactoryBean.java:164)
> at
> org.springframework.data.gemfire.ResolvableRegionFactoryBean.afterPropertiesSet(ResolvableRegionFactoryBean.java:96)
> at
> org.springframework.data.gemfire.config.annotation.support.CacheTypeAwareRegionFactoryBean.newClientRegion(CacheTypeAwareRegionFactoryBean.java:181)
> at
> org.springframework.data.gemfire.config.annotation.support.CacheTypeAwareRegionFactoryBean.createRegion(CacheTypeAwareRegionFactoryBean.java:141)
> at
> org.springframework.data.gemfire.ResolvableRegionFactoryBean.afterPropertiesSet(ResolvableRegionFactoryBean.java:96)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1858)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1795)
> ... 69 more
> Caused by: java.security.UnrecoverableKeyException: Password must not be null
> at
> sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:134)
> at
> sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:57)
> at
> sun.security.provider.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:96)
> at
> sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetKey(JavaKeyStore.java:71)
> at java.security.KeyStore.getKey(KeyStore.java:1023)
> at
> sun.security.ssl.SunX509KeyManagerImpl.(SunX509KeyManagerImpl.java:145)
> at
> sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:70)
> at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
> at
> org.apache.geode.internal.net.SocketCreator.getKeyManagers(SocketCreator.java:422)
> at
> org.apache.geode.internal.net.SocketCreator.createAndConfigureSSLContext(SocketCreator.java:292)
> at
>
