Merge branch 'main' into 5.4/mongo-doc-changes

# Conflicts:
#	docs/modules/sql/pages/mapping-to-mongo.adoc

.gitignore

@@ -5,3 +5,6 @@
 package-lock.json
 .idea/
 *.iml
+# Eclipse IDE
+.project
+.settings/

README.adoc

@@ -147,7 +147,7 @@ For example, if you are releasing version 5.1, create a new release branch named
 +
 IMPORTANT: If you are creating a branch for a beta release, do not remove this field.
 
-. When you are ready to release, create a maintentance branch from the release branch.
+. When you are ready to release, create a maintenance branch from the release branch.
 +
 NOTE: As soon as you push the maintenance branch to the repository, GitHub will trigger a new build of the site, which will include your new content.
 

antora-playbook-local.yml

@@ -30,7 +30,7 @@ asciidoc:
     idseparator: '-'
     # Variables used in the docs
     page-survey: https://www.surveymonkey.co.uk/r/NYGJNF9
-    hazelcast-cloud: Viridian
+    hazelcast-cloud: Viridian Cloud
   extensions:
     - ./docs-tabs-library/tabs-block.js
     - asciidoctor-kroki

antora-playbook.yml

@@ -27,7 +27,7 @@ asciidoc:
     idseparator: '-'
     # Variables used in the docs
     page-survey: https://www.surveymonkey.co.uk/r/NYGJNF9
-    hazelcast-cloud: Viridian
+    hazelcast-cloud: Viridian Cloud
   extensions:
     - ./docs-tabs-library/tabs-block.js
     - asciidoctor-kroki

check-links-playbook.yml

@@ -80,9 +80,6 @@ content:
   - url: https://github.com/hazelcast-guides/ecs-embedded
     branches: master
     start_path: docs
-  - url: https://github.com/hazelcast-guides/striim-cdc
-    branches: master
-    start_path: docs
   - url: https://github.com/hazelcast-guides/springboot-tomcat-session-replication
     branches: master
     start_path: docs

docs/antora.yml

@@ -10,6 +10,8 @@ asciidoc:
   attributes:
     # The full major.minor.patch version, which is used as a variable in the docs for things like download links
     full-version: '5.4.0-SNAPSHOT'
+    # The minor.patch version, which is used as a variable in the docs for things like file versions
+    minor-version: '5.3'
     # The snapshot version for installing with brew
     version-brew: '5.4.0.SNAPSHOT'
     # Allows us to use UI macros. See https://docs.asciidoctor.org/asciidoc/latest/macros/ui-macros/
@@ -19,13 +21,13 @@ asciidoc:
     # All page-latest attributes are used as a variable in the docs for things like download links and search results
     page-latest-cli: '5.2021.09'
     # Must be lowercase because this is how the version appears in the docs
-    page-latest-supported-mc: '5.3.1-snapshot'
+    page-latest-supported-mc: '5.4-snapshot'
     page-latest-supported-java-client: '5.4.0-SNAPSHOT'
-    page-latest-supported-go-client: '1.3.0'
-    page-latest-supported-cplusplus-client: '5.0.0'
-    page-latest-supported-csharp-client: '5.1.0'
-    page-latest-supported-python-client: '5.1'
-    page-latest-supported-nodejs-client: '5.1.0'
-    page-latest-supported-clc: '5.2.0-BETA-3'
+    page-latest-supported-go-client: '1.4.0'
+    page-latest-supported-cplusplus-client: '5.3.0'
+    page-latest-supported-csharp-client: '5.3.0'
+    page-latest-supported-python-client: '5.3.0'
+    page-latest-supported-nodejs-client: '5.3.0'
+    page-latest-supported-clc: '5.3.1'
 nav:
   - modules/ROOT/nav.adoc

docs/modules/ROOT/examples/storage/SampleHotRestartConfiguration.java

@@ -30,6 +30,8 @@ public static void main(String[] args) throws Exception{
         cacheConfig.getMerkleTreeConfig().setDepth(12);
         config.addCacheConfig(cacheConfig);
 
+        config.getSqlConfig().setCatalogPersistenceEnabled(true);
+
         config.getJetConfig().setLosslessRestartEnabled(true);
         //end::hrconf[]
     }

docs/modules/ROOT/nav.adoc

@@ -16,17 +16,17 @@ include::mapstore:partial$nav.adoc[]
 --
 include::pipelines:partial$nav.adoc[]
 include::query:partial$nav.adoc[]
-* SQL
-+
---
-include::sql:partial$nav.adoc[]
---
 * Improving Query Performance
 ** xref:query:indexing-maps.adoc[]
 ** xref:performance:data-affinity.adoc[]
 ** xref:performance:caching-deserialized-values.adoc[]
 ** xref:performance:near-cache.adoc[]
 ** xref:data-structures:preventing-out-of-memory.adoc[]
+* SQL
++
+--
+include::sql:partial$nav.adoc[]
+--
 include::integrate:partial$nav.adoc[]
 include::spring:partial$nav.adoc[]
 include::computing:partial$nav.adoc[]

docs/modules/ROOT/pages/capacity-planning.adoc

@@ -16,7 +16,7 @@ Hazelcast's architecture and concepts. Here, we introduce some basic guidelines
 that help to properly size a cluster.
 
 We recommend always benchmarking your setup before deploying it to
-production. We also recommend that bechmarking systems resemble the
+production. We also recommend that benchmarking systems resemble the
 production system as much as possible to avoid unexpected results.
 We provide a <<benchmarking-and-sizing-example, bechmarking example>>
 that you can use as a starting point.
@@ -134,7 +134,7 @@ Memory consumption is affected by:
 files such as models for ML inference pipelines can consume significant resources.
 * **State of the running jobs:** This varies, as it's affected by the shape of
 your pipeline and by the data being processed. Most of the memory is
-consumed by operations that aggregate and buffer data. Typically the
+consumed by operations that aggregate and buffer data. Typically, the
 state also scales with the number of distinct keys seen within the
 time window. Learn how the operations in the pipeline store its state.
 Operators coming with Jet provide this information in the javadoc.
@@ -166,7 +166,7 @@ for information about lite members.
 Hazelcast's default partition count is 271. This is a good choice for clusters of
 up to 50 members and ~25–30 GB of data. Up to this threshold,
 partitions are small enough that any rebalancing of the partition map
-when members join or leave the cluster doesn’t disturb the smooth operation of the cluster.
+when members join or leave the cluster doesn't disturb the smooth operation of the cluster.
 With larger clusters and/or bigger data sets, a larger partition count helps to
 maintain an efficient rebalancing of data across members.
 
@@ -181,7 +181,7 @@ is under 100MB. Remember to factor in headroom for projected data growth.
 To change the partition count, use the system property `hazelcast.partition.count`.
 
 NOTE: If you change the partition count from the default of 271,
-be sure to use a prime number of partitions. This helps minimizing
+be sure to use a prime number of partitions. This helps minimize
 the collision of keys across partitions, ensuring more consistent lookup
 times.
 
@@ -595,11 +595,8 @@ of your Hazelcast data pipeline.
 
 === Upgrade Your JDK
 
-If you are still on JDK 8, seriously consider upgrading. We found that
-none of its garbage collectors are a match for the offerings of JDK 11,
-which is the current version with Oracle's Long-Term Support (LTS). The
-JVM has been undergoing a phase of rapid development lately, which means
-you can expect numerous improvements with each JDK version.
+Hazelcast does not support JDK 8, so if you are still on JDK 8, please upgrade it.
+The garbage collectors of JDK 11+ have been improved to achieve much higher throughputs. 
 
 === The G1 Collector is Great for Most Workloads
 

docs/modules/ROOT/pages/faq.adoc

@@ -39,7 +39,7 @@ maintain linearizability and prefer consistency over availability during netwo
 
 The partition count of 271, being a prime number, is a good choice because
 it is distributed to the members almost evenly.
-For a small to medium sized cluster, the count of 271 gives an almost even partition distribution and optimal-sized partitions.
+For a small to medium-sized cluster, the count of 271 gives an almost even partition distribution and optimal-sized partitions.
 As your cluster becomes bigger, you should make this count bigger to have evenly distributed partitions.
 
 
@@ -166,7 +166,7 @@ public void testTwoMemberMapSizes() {
 ----
 
 In the test above, everything happens in the same thread.
-When developing a multi-threaded test, you need to carefully handle coordination of the thread executions.
+When developing a multithreaded test, you need to carefully handle coordination of the thread executions.
 It is highly recommended that you use `CountDownLatch` for thread coordination (you can certainly use other ways).
 Here is an example where we need to listen for messages and make sure that we got these messages.
 

docs/modules/ROOT/pages/glossary.adoc

@@ -1,7 +1,7 @@
 = Glossary
 
 [glossary]
-2-phase commit:: An atomic commitment protocol for distributed systems. It consists of two phases: commit-request and commit. In commit-request phase, transaction manager coordinates all the transaction resources to commit or abort. In commit-phase, transaction manager decides to finalize operation by committing or aborting according to the votes of the each transaction resource.
+2-phase commit:: An atomic commitment protocol for distributed systems. It consists of two phases: commit-request and commit. In commit-request phase, transaction manager coordinates all the transaction resources to commit or abort. In commit-phase, transaction manager decides to finalize operation by committing or aborting according to the votes of each transaction resource.
 ACID:: A set of properties (Atomicity, Consistency, Isolation, Durability) guaranteeing that transactions are processed reliably. Atomicity requires that each transaction be all or nothing, i.e., if one part of the transaction fails, the entire transaction fails). Consistency ensures that only valid data following all rules and constraints is written. Isolation ensures that transactions are securely and independently processed at the same time without interference (and without transaction ordering). Durability means that once a transaction has been committed, it will remain so, no matter if there is a power loss, crash, or error.
 Cache:: A high-speed access area that can be either a reserved section of main memory or a storage device.
 Change data capture (CDC):: A <<data-pipeline, data pipeline>> pattern for observing changes made to a database and extracting them in a form usable by other systems, for the purposes of replication, analysis and more.
@@ -24,7 +24,7 @@ Lite member:: A member that does not store data and has no partitions. These mem
 Member:: A Hazelcast instance. Depending on your Hazelcast topology, it can refer to a server or a Java virtual machine (JVM). Members belong to a Hazelcast cluster. Members may also be referred as member nodes, cluster members, Hazelcast members, or data members.
 Multicast:: A type of communication where data is addressed to a group of destination members simultaneously.
 Near cache:: A caching model where an object retrieved from a remote member is put into the local cache and the future requests made to this object will be handled by this local member.
-NoSQL:: "Not Only SQL". A database model that provides a mechanism for storage and retrieval of data that is tailored in means other than the tabular relations used in relational databases. It is a type of database which does not adhering to the traditional relational database management system (RDMS) structure. It is not built on tables and does not employ SQL to manipulate data. It also may not provide full ACID guarantees, but still has a distributed and fault tolerant architecture.
+NoSQL:: "Not Only SQL". A database model that provides a mechanism for storage and retrieval of data that is tailored in means other than the tabular relations used in relational databases. It is a type of database which does not adhering to the traditional relational database management system (RDMS) structure. It is not built on tables and does not employ SQL to manipulate data. It also may not provide full ACID guarantees, but still has a distributed and fault-tolerant architecture.
 OSGI:: Formerly known as the Open Services Gateway initiative, it describes a modular system and a service platform for the Java programming language that implements a complete and dynamic component model.
 Partition table:: Table containing all members in the cluster, mappings of partitions to members and further metadata.
 Race condition:: This condition occurs when two or more threads can access shared data and they try to change it at the same time.

docs/modules/ROOT/pages/list-of-metrics.adoc

@@ -192,7 +192,7 @@ with the master member.
 
 |`cp.session.endpoint`
 |
-|Address of the endpoint which the CP session session belongs to
+|Address of the endpoint which the CP session belongs to
 
 |`cp.session.endpointType`
 |
@@ -753,7 +753,7 @@ with the master member.
 
 |`nearcache.persistenceCount`
 |count
-|Number of Near Cache key persistences (when the pre-load feature is enabled)
+|Number of Near Cache key persistences (when the preload feature is enabled)
 
 |`operation.adhoc.executedOperationsCount`
 |count
@@ -1061,7 +1061,7 @@ with the master member.
 
 |`persistence.liveTombstones`
 |count
-|Number of live tombstones in the xref:storage:persistence.adoc[persistent store]; this and the below Persistence metrics have the following format when output: `hz_persistence_<INSTANCE_NAME>_<CHUNK_MANAGER_ID>_<metric>`
+|Number of live tombstones in the xref:storage:persistence.adoc[persistent store]
 
 |`persistence.liveValues`
 |count
@@ -1975,8 +1975,8 @@ vertex.
 Each Hazelcast member will have an instance of these metrics for each
 ordinal of each vertex of each job execution.
 
-Note: These metrics are only present for distributed edges (ie.
-edges producing network traffic).
+Note: These metrics are only present for distributed edges, i.e., 
+edges producing network traffic.
 
 |distributedBytesOut
 |Total number of bytes sent to remote members.

docs/modules/ROOT/pages/production-checklist.adoc

@@ -32,7 +32,7 @@ However, the following modules are not supported for the Solaris operating syste
 === VMWare ESX
 
 Hazelcast is certified on VMWare VSphere 5.5/ESXi 6.0.
-Generally speaking, Hazelcast can use all of the resources on a full machine.
+Generally speaking, Hazelcast can use all the resources on a full machine.
 Splitting a single physical machine into multiple virtual machines and
 thereby dividing resources are not required.
 
@@ -70,19 +70,11 @@ General recommendations:
 * GC logs should be enabled
 * Minimum and maximum heap size should be equal
 
-For Java 9+:
+For Java 11+:
 
 * G1GC is the default recommended GC policy
 * No tuning is recommended unless needed
 
-For Java 8:
-
-* Recommended GC policies are CMS and ParNewGC:
-** `-XX:CMSInitiatingOccupancyFraction=65`
-** `-XX:+UseParNewGC`
-** `-XX:+UseConcMarkSweepGC`
-* For large heaps G1GC is recommended as above
-
 == Data Size Calculation Recommendations
 
 Total data size should be calculated based on the combination of primary data and backup data. For example, if you have configured your cluster with a backup count of 2, then total memory consumed is actually 3x larger than the primary data size (primary + backup + backup). Partition sizes of 50MB or less are recommended.

docs/modules/ROOT/pages/system-properties.adoc

@@ -1162,7 +1162,17 @@ master starts forming the cluster.
 |50000
 |int
 |Defines the pending invocation threshold for the WAN replication implementation. Exceeding this threshold on a WAN consumer member makes the member to delay the WAN acknowledgment,
-thus slowing down the WAN publishers on the source side that send WAN events to the given WAN consumer. Setting this value to negative disables the acknowledgement delaying feature.
+thus slowing down the WAN publishers on the source side that send WAN events to the given WAN consumer. Setting this value to negative disables the acknowledgment delaying feature.
+
+|`hazelcast.wan.replicate.imap.evictions`
+|false
+|bool
+|Specifies whether `IMap` objects replicate entry evictions over WAN to target clusters. Use this property with caution. When enabled, _ALL_ evictions, including size or expiration-driven evictions and manual invocations are replicated to target clusters. Setting this property to `true` does not guarantee data consistency between clusters.
+
+|`hazelcast.wan.replicate.icache.evictions`
+|false
+|bool
+|Specifies whether `ICache` objects replicate entry evictions over WAN to target clusters. Use this property with caution. When enabled, _ALL_ evictions, including size or expiration-driven evictions and manual invocations are replicated to target clusters. Setting this property to `true` does not guarantee data consistency between clusters.
 
 |`tcp.channels.per.connection`
 | 1

docs/modules/architecture/pages/architecture.adoc

@@ -5,7 +5,7 @@
 {description}
 
 In Hazelcast, data is load-balanced in-memory across a cluster.
-This cluster is a network of members each of which runs Hazelcast. A cluster of Hazelcast members share both the data storage and computational
+This cluster is a network of members, each of which runs Hazelcast. A cluster of Hazelcast members share both the data storage and computational
 load which can dynamically scale up and down. When you add new members to the cluster, both the data and computations are automatically rebalanced across the cluster.
 
 image:ROOT:HighLevelArch.png[Hazelcast High-Level Architecture]

docs/modules/architecture/pages/data-partitioning.adoc

@@ -135,7 +135,7 @@ a stale partition table information about a backup replica member,
 network interruption, or a member crash. That's why sync backup acks require
 a timeout to give up. Regardless of being a sync or async backup, if a backup update is missed,
 the periodically running anti-entropy mechanism detects the inconsistency and
-synchronizes backup replicas with the primary. Also the graceful shutdown procedure ensures
+synchronizes backup replicas with the primary. Also, the graceful shutdown procedure ensures
 that all backup replicas for partitions whose primary replicas are assigned to
 the shutting down member will be consistent.
 

docs/modules/architecture/pages/distributed-computing.adoc

@@ -219,7 +219,7 @@ digraph DAG {
 === Tasks Concurrency is Cooperative
 
 Hazelcast avoids starting a heavyweight system thread for each
-concurrent task of the DAG. Instead it uses a xref:execution-engine.adoc[cooperative multithreading model]. This has high-level implications as well: all the
+concurrent task of the DAG. Instead, it uses a xref:execution-engine.adoc[cooperative multithreading model]. This has high-level implications as well: all the
 lambdas you write in the Jet API must cooperate by not calling
 blocking methods that may take unpredictably long to complete. If that
 happens, all the tasklets scheduled on the same thread will be blocked
@@ -238,7 +238,7 @@ asynchronous calls and use `mapUsingServiceAsync`.
 When you split the stream by, for example, user ID and aggregate every
 user's events independently, you should send all the events with the
 same user ID to the same task, the one holding that user's state.
-Otherwise all the tasks will end up with storage for all the IDs and no
+Otherwise, all the tasks will end up with storage for all the IDs and no
 task will have the full picture. The technique to achieve this
 separation is *data partitioning*: Hazelcast uses a function that maps any
 user ID to an integer from a predefined range and then assigns the

docs/modules/cache/pages/overview.adoc

@@ -132,7 +132,7 @@ To use Hazelcast for web session replication, see the following resources:
 
 == Caching with JDBC Data Stores
 
-To configure a cache with a connection to to JDBC data store, see xref:mapstore:configuring-a-generic-mapstore.adoc[].
+To configure a cache with a connection to JDBC data store, see xref:mapstore:configuring-a-generic-mapstore.adoc[].
 
 == Building a Custom Database Cache
 

docs/modules/clients/pages/clc.adoc

@@ -1,6 +1,5 @@
 = Hazelcast Command-Line Client
 :page-api-reference: https://github.com/hazelcast/hazelcast-commandline-client
 :page-toclevels: 3
-:page-beta: true
 
-The Hazelcast Command-Line Client (CLC) is a command-line tool to connect to and operate on Hazelcast Platform and xref:cloud:ROOT:overview.adoc[Hazelcast {hazelcast-cloud} Managed Services]. You can use the CLC to execute commands through a terminal. See its xref:clc:ROOT:overview.adoc[documentation] on how to use it depending on your use cases.
+The Hazelcast Command-Line Client (CLC) is a command-line tool that allows you to connect to and interact with clusters on Hazelcast Platform and xref:cloud:ROOT:overview.adoc[Hazelcast {hazelcast-cloud}]. You can use the CLC to execute commands through a terminal. See its documentation for xref:clc:ROOT:overview.adoc#use-cases[example use cases], xref:clc:ROOT:get-started.adoc[tutorials], and xref:clc:ROOT:clc-commands.adoc[supported commands].