Correct documentation edits and documentation polish merge conflicts.
Resolves gh-109.
This commit is contained in:
John Blum
@@ -1,24 +1,24 @@
|
||||
[[actuator]]
|
||||
== Spring Boot Actuator
|
||||
:geode-name: {apache-geode-name}
|
||||
|
||||
Spring Boot for {geode-name} (SBDG) adds {spring-boot-docs-html}/production-ready.html[Spring Boot Actuator] support
|
||||
and dedicated `HealthIndicators` for {geode-name}. Equally, the provided `HealthIndicators` even work with Tanzu Cache
|
||||
(which is backed by {pivotal-gemfire-name}) when you push your Spring Boot applications using {geode-name}
|
||||
to {VMware Tanzu Application Service (TAS)} platform.
|
||||
|
||||
Spring Boot for {apache-geode-name} (SBDG) adds {spring-boot-docs-html}/production-ready.html[Spring Boot Actuator]
|
||||
support and dedicated `HealthIndicators` for {apache-geode-name}. Equally, the provided `HealthIndicators` even work
|
||||
with Tanzu Cache (which is backed by {pivotal-gemfire-name}) when you push your Spring Boot applications
|
||||
using {apache-geode-name} to {VMware Tanzu Application Service (TAS)} platform.
|
||||
|
||||
Spring Boot `HealthIndicators` provide details about the runtime operation and behavior of your {apache-geode-name}-based
|
||||
Spring Boot `HealthIndicators` provide details about the runtime operation and behavior of your {geode-name}-based
|
||||
Spring Boot applications. For instance, by querying the right `HealthIndicator` endpoint, you can get the current
|
||||
hit/miss count for your `Region.get(key)` data access operations.
|
||||
|
||||
In addition to vital health information, SBDG provides basic, pre-runtime configuration metadata about the
|
||||
{apache-geode-name} components that are monitored by Spring Boot Actuator. This makes it easier to see how
|
||||
{geode-name} components that are monitored by Spring Boot Actuator. This makes it easier to see how
|
||||
the application was configured all in one place, rather than in properties files, Spring configuration, XML,
|
||||
and so on.
|
||||
|
||||
The provided Spring Boot `HealthIndicators` fall into three categories:
|
||||
|
||||
* Base `HealthIndicators` that apply to all {apache-geode-name}, Spring Boot applications, regardless of cache type,
|
||||
* Base `HealthIndicators` that apply to all {geode-name}, Spring Boot applications, regardless of cache type,
|
||||
such as `Regions`, `Indexes`, and `DiskStores`.
|
||||
* Peer `Cache`-based `HealthIndicators` that apply only to peer `Cache` applications, such as `AsyncEventQueues`,
|
||||
`CacheServers`, `GatewayReceivers`, and `GatewaySenders`.
|
||||
@@ -26,19 +26,19 @@ such as `Regions`, `Indexes`, and `DiskStores`.
|
||||
and connection `Pools`.
|
||||
|
||||
The following sections give a brief overview of all the available Spring Boot `HealthIndicators` provided for
|
||||
{apache-geode-name}.
|
||||
{geode-name}.
|
||||
|
||||
TIP: See the corresponding sample link:guides/boot-actuator.html[guide] and {github-samples-url}/boot/actuator[code]
|
||||
to see Spring Boot Actuator for {apache-geode-name} in action.
|
||||
to see Spring Boot Actuator for {geode-name} in action.
|
||||
|
||||
[[actuator-base-healthindicators]]
|
||||
=== Base HealthIndicators
|
||||
|
||||
This section covers Spring Boot `HealthIndicators` that apply to both {apache-geode-name} peer `Cache` and `ClientCache`,
|
||||
This section covers Spring Boot `HealthIndicators` that apply to both {geode-name} peer `Cache` and `ClientCache`,
|
||||
Spring Boot applications. That is, these `HealthIndicators` are not specific to the cache type.
|
||||
|
||||
In {apache-geode-name}, the cache instance is either a peer `Cache` instance (which makes your Spring Boot application
|
||||
part of a {apache-geode-name} cluster) or, more commonly, a `ClientCache` instance (which talks to an existing cluster).
|
||||
In {geode-name}, the cache instance is either a peer `Cache` instance (which makes your Spring Boot application
|
||||
part of a {geode-name} cluster) or, more commonly, a `ClientCache` instance (which talks to an existing cluster).
|
||||
Your Spring Boot application can only be one cache type or the other and can only have a single instance of
|
||||
that cache type.
|
||||
|
||||
@@ -327,7 +327,7 @@ In addition, the following CQ query and statistical data is covered:
|
||||
|
||||
|=====================================================================================================================
|
||||
|
||||
The {apache-geode-name} Continuous Query system is also tracked with the following additional details on the client:
|
||||
The {geode-name} Continuous Query system is also tracked with the following additional details on the client:
|
||||
|
||||
.Continuous Query (CQ), Additional Statistic Details
|
||||
[width="90%",cols="^3,<10",options="header"]
|
||||
@@ -403,7 +403,7 @@ The peer `Cache`-based `HealthIndicators` provide additional details specificall
|
||||
applications. These `HealthIndicators` are available only when the Spring Boot application creates a peer `Cache`
|
||||
instance.
|
||||
|
||||
NOTE: The default cache instance created by Spring Boot for {apache-geode-name} is a `ClientCache` instance.
|
||||
NOTE: The default cache instance created by Spring Boot for {geode-name} is a `ClientCache` instance.
|
||||
|
||||
TIP: To control what type of cache instance is created, such as a "`peer`", you can explicitly declare either the
|
||||
`@PeerCacheApplication` or, alternatively, the `@CacheServerApplication` annotation on your
|
||||
@@ -412,7 +412,7 @@ TIP: To control what type of cache instance is created, such as a "`peer`", you
|
||||
[[actuator-peercache-healthindicators-cacheservers]]
|
||||
==== GeodeCacheServersHealthIndicator
|
||||
|
||||
The `GeodeCacheServersHealthIndicator` provides details about the configured {apache-geode-name} `CacheServer` instances.
|
||||
The `GeodeCacheServersHealthIndicator` provides details about the configured {geode-name} `CacheServer` instances.
|
||||
`CacheServer` instances are required to enable clients to connect to the servers in the cluster.
|
||||
|
||||
This `HealthIndicator` captures basic configuration metadata and the runtime behavior and characteristics of
|
||||
@@ -508,7 +508,7 @@ or serial.
|
||||
==== GeodeGatewayReceiversHealthIndicator
|
||||
|
||||
`GeodeGatewayReceiversHealthIndicator` provides details about the configured (WAN) `GatewayReceivers`,
|
||||
which are capable of receiving events from remote clusters when using {apache-geode-name}'s
|
||||
which are capable of receiving events from remote clusters when using {geode-name}'s
|
||||
{apache-geode-docs}/topologies_and_comm/multi_site_configuration/chapter_overview.html[multi-site, WAN topology].
|
||||
|
||||
This `HealthIndicator` captures configuration metadata along with the running state for each `GatewayReceiver`:
|
||||
@@ -541,8 +541,8 @@ the `GatewayReceiver` is chosen.
|
||||
==== GeodeGatewaySendersHealthIndicator
|
||||
|
||||
The `GeodeGatewaySendersHealthIndicator` provides details about the configured `GatewaySenders`. `GatewaySender`
|
||||
instances are attached to Regions in order to send Region events to remote clusters in {apache-geode-name}'s
|
||||
{apache-geode-docs}/topologies_and_comm/multi_site_configuration/chapter_overview.html[multi-site, WAN topology].
|
||||
instances are attached to Regions in order to send Region events to remote clusters in {geode-name}'s
|
||||
{apache-geode-docs}/topologies_and_comm/multi_site_configuration/chapter_overview.html[multi-site, WAN topology].
|
||||
|
||||
This `HealthIndicator` captures essential configuration metadata and runtime characteristics for each `GatewaySender`:
|
||||
|
||||
|
||||
@@ -10,12 +10,13 @@ in {spring-framework-docs}/integration.html#cache[Spring's Cache Abstraction]. S
|
||||
{spring-framework-docs}/integration.html#cache-store-configuration-gemfire[enables]
|
||||
{geode-name} to function as a caching provider in Spring's Cache Abstraction.
|
||||
|
||||
TIP: See the _Spring Data for {geode-name} Reference Guide_ for more details on the
|
||||
{spring-data-geode-docs-html}/#apis:spring-cache-abstraction[support] and {spring-data-geode-docs-html}/#bootstrap-annotation-config-caching[configuration]
|
||||
TIP: See the _Spring Data for {geode-name} Reference Guide_ for more details on
|
||||
the {spring-data-geode-docs-html}/#apis:spring-cache-abstraction[support]
|
||||
and {spring-data-geode-docs-html}/#bootstrap-annotation-config-caching[configuration]
|
||||
of {geode-name} as a caching provider in Spring's Cache Abstraction.
|
||||
|
||||
TIP: Make sure you thoroughly understand the {spring-framework-docs}/integration.html#cache-strategies[concepts]
|
||||
behind Spring's cache abstraction before you continue.
|
||||
behind Spring's Cache Abstraction before you continue.
|
||||
|
||||
TIP: See also the relevant section on {spring-boot-docs-html}/#boot-features-caching[caching]
|
||||
in Spring Boot's reference documentation. Spring Boot even provides auto-configuration support for a few of the simple
|
||||
@@ -36,8 +37,8 @@ Spring's {spring-framework-docs}/integration.html#cache-annotations[declarative,
|
||||
simple to get started with caching, which is as easy as annotating your application components with the appropriate
|
||||
Spring cache annotations.
|
||||
|
||||
TIP: Spring's declarative, annotation-based caching also {spring-framework-docs}/integration.html#cache-jsr-107[supports]
|
||||
JCache (JSR-107) annotations.
|
||||
TIP: Spring's declarative, annotation-based caching also
|
||||
{spring-framework-docs}/integration.html#cache-jsr-107[supports] JSR-107 JCache annotations.
|
||||
|
||||
For example, suppose you want to cache the results of determining a person's eligibility when applying for a loan. A
|
||||
person's financial status is unlikely to change in the time that the computer runs the algorithms to compute a person's
|
||||
@@ -141,8 +142,8 @@ will be presented in a later release.
|
||||
[[geode-caching-provider-look-aside-caching]]
|
||||
==== Look-Aside Caching
|
||||
|
||||
TIP: See the corresponding sample link:guides/caching-look-aside.html[guide] and {github-samples-url}/caching/look-aside[code]
|
||||
to see Look-aside caching with {apache-geode-name} in action.
|
||||
TIP: See the corresponding sample link:guides/caching-look-aside.html[guide]
|
||||
and {github-samples-url}/caching/look-aside[code] to see Look-aside caching with {apache-geode-name} in action.
|
||||
|
||||
The caching pattern demonstrated in the preceding example is a form of
|
||||
https://content.pivotal.io/blog/an-introduction-to-look-aside-vs-inline-caching-patterns[Look-aside caching]
|
||||
@@ -199,7 +200,7 @@ to see Near caching with {apache-geode-name} in action.
|
||||
Near caching is another pattern of caching where the cache is collocated with the application. This is useful when
|
||||
the caching technology is configured in a client/server arrangement.
|
||||
|
||||
We already mentioned that Spring Boot for {geode-name} <<clientcache-applications.adoc#geode-clientcache-applications, provides>>
|
||||
We already mentioned that Spring Boot for {geode-name} <<clientcache-applications.adoc#geode-clientcache-applications,provides>>
|
||||
an auto-configured `ClientCache` instance by default. A `ClientCache` instance is most effective when the data access
|
||||
operations, including cache access, are distributed to the servers in a cluster that is accessible to the client and,
|
||||
in most cases, multiple clients. This lets other cache client applications access the same data. However, this also
|
||||
@@ -624,7 +625,8 @@ class GeodeConfiguration {
|
||||
While this approach affords you a lot of control over the low-level configuration, in addition to
|
||||
your `AsyncEventListener` implementation, this is a lot of boilerplate code.
|
||||
|
||||
TIP: See the Javadoc for SDG's {spring-data-geode-javadoc}/org/springframework/data/gemfire/wan/AsyncEventQueueFactoryBean.html[`AsyncEventQueueFactoryBean`]
|
||||
TIP: See the Javadoc for SDG's
|
||||
{spring-data-geode-javadoc}/org/springframework/data/gemfire/wan/AsyncEventQueueFactoryBean.html[`AsyncEventQueueFactoryBean`]
|
||||
for more detail on the configuration of the AEQ.
|
||||
|
||||
TIP: See {geode-name}'s {apache-geode-docs}/developing/events/implementing_write_behind_event_handler.html[User Guide]
|
||||
@@ -912,7 +914,8 @@ Programming (AOP) and the https://en.wikipedia.org/wiki/Decorator_pattern[Decora
|
||||
The `apply*` methods and the supplied `Function` let you decorate, enhance, post-process, or otherwise modify
|
||||
the {geode-name} objects created by the configurer.
|
||||
|
||||
The `AsyncInlineCachingRegionConfigurer` strictly adheres to the https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle[open/close principle]
|
||||
The `AsyncInlineCachingRegionConfigurer` strictly adheres to
|
||||
the https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle[open/close principle]
|
||||
and is, therefore, flexibly extensible.
|
||||
|
||||
[[geode-caching-provider-multi-site-caching]]
|
||||
|
||||
@@ -27,7 +27,7 @@ For example, you can begin building a Spring Boot {geode-name} `ClientCache` app
|
||||
----
|
||||
====
|
||||
|
||||
Then you configure and bootstrap your Spring Boot {geode-name} `ClientCache` application with the following
|
||||
Then you configure and bootstrap your Spring Boot, {geode-name} `ClientCache` application with the following
|
||||
main application class:
|
||||
|
||||
.Spring Boot, {geode-name} `ClientCache` Application
|
||||
@@ -689,7 +689,7 @@ class CacheServerManagerApplication {
|
||||
@SpringBootApplication
|
||||
@PeerCacheApplication(name = "PeerCacheManagerApplication")
|
||||
@EnableManager(start = "true")
|
||||
class SpringBootPeerCacheManagerApplication {
|
||||
class PeerCacheManagerApplication {
|
||||
// ...
|
||||
}
|
||||
----
|
||||
@@ -739,11 +739,11 @@ runtime "org.springframework.boot:spring-boot-starter-jetty"
|
||||
====
|
||||
|
||||
The embedded HTTP service (implemented with the Eclipse Jetty Servlet Container), runs the Management (Admin) REST API,
|
||||
which is used by {geode-name} tooling, such as Gfsh, to connect to the cluster over HTTP. In addition, it also enables
|
||||
the {geode-name} {apache-geode-docs}/tools_modules/pulse/pulse-overview.html[Pulse] Monitoring Tool
|
||||
which is used by {geode-name} tooling, such as Gfsh, to connect to an {geode-name} cluster over HTTP. In addition, it
|
||||
also enables the {geode-name} {apache-geode-docs}/tools_modules/pulse/pulse-overview.html[Pulse] Monitoring Tool
|
||||
(and Web application) to run.
|
||||
|
||||
Even if you do not start the embedded HTTP service, a _Manager_ still requires the `geode-http-service`, `geode-web`
|
||||
Even if you do not start the embedded HTTP service, a Manager still requires the `geode-http-service`, `geode-web`
|
||||
and `spring-boot-starter-jetty` dependencies.
|
||||
|
||||
Optionally, you may also include the `geode-pulse` dependency, as follows:
|
||||
@@ -756,6 +756,6 @@ runtime "org.apache.geode:geode-pulse"
|
||||
----
|
||||
====
|
||||
|
||||
The `geode-pulse` dependency is only required if you want the _Manager_ to automatically start
|
||||
the {geode-name} {apache-geode-docs}/tools_modules/pulse/pulse-overview.html[Pulse] Monitoring Tool. _Pulse_ enables
|
||||
you to view the nodes of your {geode-name} cluster and monitor them in realtime.
|
||||
The `geode-pulse` dependency is only required if you want the Manager to automatically start
|
||||
the {geode-name} {apache-geode-docs}/tools_modules/pulse/pulse-overview.html[Pulse] Monitoring Tool. Pulse enables you
|
||||
to view the nodes of your {geode-name} cluster and monitor them in realtime.
|
||||
|
||||
@@ -5,6 +5,7 @@
|
||||
:pcc-name: Pivotal Cloud Cache
|
||||
:pcf-name: Pivotal CloudFoundry
|
||||
|
||||
|
||||
NOTE: As of the VMware, Inc. acquisition of Pivotal Software, Inc., {pcf-name} (PCF) is now known as VMware Tanzu
|
||||
Application Service (TAS) for VMs. Also, {pcc-name} (PCC) has been rebranded as VMware Tanzu GemFire for VMS.
|
||||
This documentation will eventually be updated to reflect the rebranding.
|
||||
@@ -505,7 +506,7 @@ ServerOne | 10.99.199.24(ServerOne:14401)<v1>:1025
|
||||
----
|
||||
====
|
||||
|
||||
Currently, we have not defined any regions in which to store our application's data:
|
||||
Currently, we have not defined any Regions in which to store our application's data:
|
||||
|
||||
.No Application Regions
|
||||
====
|
||||
|
||||
@@ -47,7 +47,7 @@ To learn more about the motivation behind SDG's annotation-based configuration m
|
||||
Currently, SBDG provides auto-configuration for the following features:
|
||||
|
||||
* `ClientCache`
|
||||
* Caching with Spring's cache abstraction
|
||||
* Caching with Spring's Cache Abstraction
|
||||
* Continuous Query
|
||||
* Function Execution and Implementation
|
||||
* Logging
|
||||
|
||||
@@ -375,7 +375,7 @@ interface MyCustomerApplicationFunctions {
|
||||
----
|
||||
====
|
||||
|
||||
Then you can inject the function execution into any application component and use it:
|
||||
Then you can inject the Function execution into any application component and use it:
|
||||
|
||||
.Use the Function
|
||||
====
|
||||
|
||||
@@ -544,7 +544,6 @@ NOTE: Lucene Indexes can only be created on `PARTITION` Regions, and `PARTITION`
|
||||
the server side.
|
||||
|
||||
You may have noticed that the `Customer` entity class's `name` field was annotated with `@Indexed`.
|
||||
Consider the following listing:
|
||||
|
||||
Consider the following listing:
|
||||
|
||||
|
||||
@@ -2,15 +2,13 @@
|
||||
== Configuration Metadata Reference
|
||||
:geode-name: {apache-geode-name}
|
||||
|
||||
|
||||
The following reference sections cover documented and well-known properties recognized and processed by
|
||||
Spring Data for {geode-name} (SDG) and Spring Session for {geode-name} (SSDG).
|
||||
|
||||
The following reference sections cover documented and well-known properties recognized and processed by Spring Data
|
||||
for {geode-name} (SDG) and Spring Session for {geode-name} (SSDG).
|
||||
|
||||
These properties may be used in Spring Boot `application.properties` or as JVM System properties, to configure different
|
||||
aspects of or enable individual features of {geode-name} in a Spring application. When combined with the power of
|
||||
Spring Boot, they give you the ability to quickly create an application that uses {geode_name}.
|
||||
Spring Boot, they give you the ability to quickly create an application that uses {geode-name}.
|
||||
|
||||
[[geode-configuration-metadata-springdata]]
|
||||
=== Spring Data Based Properties
|
||||
|
||||
@@ -2,8 +2,6 @@
|
||||
== Data Serialization with PDX
|
||||
:geode-name: {apache-geode-name}
|
||||
|
||||
Anytime data is overflowed or persisted to disk, transferred between clients and servers, transferred between peers in a cluster or between
|
||||
different clusters in a multi-site topology, all data stored in {geode-name} must be serializable.
|
||||
|
||||
Anytime data is overflowed or persisted to disk, transferred between clients and servers, transferred between peers
|
||||
in a cluster or between different clusters in a multi-site WAN topology, all data stored in {geode-name} must be
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
[[geode-data-using]]
|
||||
== Using Data
|
||||
:geode-name: Apache Geode
|
||||
:geode-name: {apache-geode-name}
|
||||
|
||||
|
||||
One of the most important tasks during development is ensuring your Spring Boot application handles data correctly.
|
||||
To verify the accuracy, integrity, and availability of your data, your application needs data with which to work.
|
||||
|
||||
@@ -2,12 +2,9 @@
|
||||
== Docker
|
||||
:docker-docs-url: https://docs.docker.com
|
||||
:docker-site-url: https://www.docker.com/
|
||||
:geode-name: Apache Geode
|
||||
:geode-name: {apache-geode-name}
|
||||
:testcontainers-url: https://www.testcontainers.org
|
||||
|
||||
The state of modern software application development is moving towards https://www.docker.com/resources/what-container[containerization].
|
||||
Containers offer a controlled environment to predictably build (configure and package), run, and manage your applications
|
||||
in a reliable and repeatable manner, regardless of context. In many situations, the intrinsic benefit of using containers is obvious.
|
||||
|
||||
The state of modern software application development is moving towards https://www.docker.com/resources/what-container[containerization].
|
||||
Containers offer a controlled environment to predictably build (compile, configure and package), run, and manage your
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
[[geode-configuration-gemfire-properties]]
|
||||
== Using Geode Properties
|
||||
:geode-name: Apache Geode
|
||||
:geode-name: {apache-geode-name}
|
||||
|
||||
|
||||
As of Spring Boot for {geode-name} (SBDG) 1.3, you can declare {geode-name} properties from `gemfire.properties`
|
||||
@@ -72,7 +72,7 @@ Valid attribute names are: ack-severe-alert-threshold ack-wait-threshold archive
|
||||
----
|
||||
====
|
||||
|
||||
It is inconvenient to have to separate {geode-name} properties from other application properties,or to have to declare
|
||||
It is inconvenient to have to separate {geode-name} properties from other application properties, or to have to declare
|
||||
only {geode-name} properties in a `gemfire.properties` file and application properties in a separate properties file,
|
||||
such as Spring Boot `application.properties`.
|
||||
|
||||
@@ -116,7 +116,8 @@ from SDG for a complete list of {geode-name} properties with no corresponding SD
|
||||
Furthermore, many of the SDG properties also correspond to API calls.
|
||||
|
||||
For example, {spring-data-geode-javadoc}/org/springframework/data/gemfire/config/annotation/ClientCacheApplication.html#keepAlive[`spring.data.gemfire.cache.client.keep-alive`]
|
||||
translates to the {apache-geode-javadoc}/org/apache/geode/cache/client/ClientCache.html#close-boolean[`ClientCache.close(boolean keepAlive)`] API call.
|
||||
translates to the {apache-geode-javadoc}/org/apache/geode/cache/client/ClientCache.html#close-boolean[`ClientCache.close(boolean keepAlive)`]
|
||||
API call.
|
||||
|
||||
Still, it would be convenient to be able to declare application and {geode-name} properties together, in a single
|
||||
properties file, such as Spring Boot `application.properties`. After all, it is not uncommon to declare JDBC Connection
|
||||
|
||||
@@ -1,8 +1,9 @@
|
||||
[[geode-api-extensions]]
|
||||
== Apache Geode API Extensions
|
||||
:geode-name: Apache Geode
|
||||
:geode-name: {apache-geode-name}
|
||||
:images-dir: ./images
|
||||
|
||||
|
||||
When using the Spring programming model and abstractions, it should not be necessary to use {geode-name}
|
||||
{apache-geode-javadoc}[APIs] at all -- for example, when using the Spring Cache Abstraction for caching
|
||||
or the Spring Data Repository abstraction for DAO development. There are many more examples.
|
||||
@@ -255,8 +256,6 @@ type.
|
||||
|
||||
The following example wraps an existing `PdxInstance`:
|
||||
|
||||
The following example wraps an existing `PdxInstance`:
|
||||
|
||||
.Wrapping an existing `PdxInstance`
|
||||
====
|
||||
[source,java]
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
[[geode-logging]]
|
||||
== Logging
|
||||
:geode-name: Apache Geode
|
||||
:geode-name: {apache-geode-name}
|
||||
|
||||
|
||||
{geode-name} `1.9.2` was modularized to separate its use of the Apache Log4j API to log output in {geode-name} code
|
||||
@@ -140,7 +140,7 @@ compatibility. By default, it logs output at `INFO`. This Logger's use should be
|
||||
The `org.apache.geode` Logger is the primary Logger used to control log output from all {geode-name} components
|
||||
during the runtime operation of {geode-name}. By default, it logs output at `INFO`.
|
||||
|
||||
The `org.jgroups` logger is used to log output from {geode-name}'s message distribution and membership system.
|
||||
The `org.jgroups` Logger is used to log output from {geode-name}'s message distribution and membership system.
|
||||
{geode-name} uses JGroups for membership and message distribution between peer members (nodes) in the cluster
|
||||
(distributed system). By default, JGroups logs output at `ERROR`.
|
||||
|
||||
|
||||
@@ -2,8 +2,6 @@
|
||||
== Spring Data Repositories
|
||||
:geode-name: {apache-geode-name}
|
||||
|
||||
Using Spring Data Repositories with {geode-name} makes short work of data access operations when you use {geode-name}
|
||||
as your System of Record (SoR) to persist your application's state.
|
||||
|
||||
Using Spring Data Repositories with {geode-name} makes short work of data access operations when you use {geode-name}
|
||||
as your System of Record (SoR) to persist your application's state.
|
||||
|
||||
@@ -2,8 +2,6 @@
|
||||
== Security
|
||||
:geode-name: {apache-geode-name}
|
||||
|
||||
This sections covers security configuration for {geode-name}, which includes both authentication and authorization
|
||||
(collectively, auth) as well as Transport Layer Security (TLS) using SSL.
|
||||
|
||||
This chapter covers security configuration for {geode-name}, which includes both authentication and authorization
|
||||
(collectively, auth) as well as Transport Layer Security (TLS) using SSL.
|
||||
|
||||
@@ -113,7 +113,7 @@ For instance, by default, SBDG sets the session expiration timeout to 30 minutes
|
||||
session state when the Spring Boot application is using a `ClientCache`, which it does
|
||||
by <<geode-clientcache-applications,default>>.
|
||||
|
||||
However, what if the defaults are not sufficient for your application requirements? In that case, see the next section.
|
||||
However, what if the defaults are not sufficient for your application requirements?
|
||||
|
||||
In that case, see the next section.
|
||||
|
||||
@@ -258,7 +258,7 @@ gfsh> create region --name=MySessions --type=PARTITION --entry-idle-time-expirat
|
||||
----
|
||||
====
|
||||
|
||||
You must create the cache region with the appropriate name and an expiration policy.
|
||||
You must create the cache Region with the appropriate name and an expiration policy.
|
||||
|
||||
In this case, we created an idle expiration policy with a timeout of `1800` seconds (30 minutes), after which the entry
|
||||
(session object) is `invalidated`.
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
[[geode-data-access-region-templates]]
|
||||
== Data Access with GemfireTemplate
|
||||
:geode-name: Apache Geode
|
||||
:geode-name: {apache-geode-name}
|
||||
|
||||
|
||||
There are several ways to access data stored in {geode-name}.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user