Merge pull request hazelcast#46 from Serdaro/main

Replacing ???s with content or removing them.

docs/modules/ROOT/pages/index.adoc

@@ -142,8 +142,6 @@ ones listed above:
 * WAN Replication (syncing data between two geo-replicated clusters)
 * Blue/Green Deployments
 
-(??? links will be provided for above when the relevant sections are settled down???)
-
 NOTE: All preexisting Hazelcast licenses (former Pro/Enterprise/Enterprise HD licenses)
 work with Hazelcast 5.0. 
 
@@ -223,11 +221,7 @@ Lastly be prompt in your communication with Hazelcast support - helps to ensure
 
 == Architecture Overview
 
-Here is the architecture diagram of Hazelcast.
-
-??? Architecture Diagram ???
-
-Let's first mention the fundamental key components of Hazelcast:
+The fundamental key components of Hazelcast are as follows:
 
 * A *member* is the computational and data storage unit in Hazelcast. Typically
 it is a JVM.

docs/modules/cluster-performance/pages/performance-tuning.adoc

@@ -176,14 +176,13 @@ For queries on fields with ranges, you can use an ordered index.
 Hazelcast, by default, caches the deserialized form of the object under
 query in the memory when inserted into an index. This removes the overhead
 of object deserialization per query, at the cost of increased heap usage.
-??? Provide a link ???
+See the xref:query:indexing-maps.adoc#indexing-ranged-queries[Indexing Ranged Queries section].
 
 === Composite Indexes
 
 Composite indexes are built on top of multiple map entry
 attributes; thus, increase the performance of complex queries significantly
-when used correctly.
-??? Provide a link ???
+when used correctly. See the xref:query:indexing-maps.adoc#composite-indexes[Composite Indexes section]
 
 === Parallel Query Evaluation & Query Thread Pool
 
@@ -192,21 +191,20 @@ to `true` can speed up queries when using slow predicates or when there are huge
 amount of entries per member.
 
 If you're using queries heavily, you can benefit from increasing query thread pools.
-??? Provide link to the query thread pool content ???
+See the xref:query:querying-maps-predicates.adoc#configuring-the-query-thread-pool[Configuring the Query Thread Pool section].
 
 === In-Memory Format for Queries
 
 Setting the queried entries' in-memory format to `OBJECT` forces the objects
 to be always kept in object format, resulting in faster access for queries, but also in
-higher heap usage. It will also incur an object serialization step on every remote get operation.
-??? Provide links to in-memory format content ???
+higher heap usage. It will also incur an object serialization step on every remote get operation. See the xref:data-structures:map.adoc#setting-in-memory-format[Setting In-Memory Format section].
 
 === Portable Interface on Queried Objects
 
 The Portable interface allows individual fields to be accessed without
 the overhead of deserialization or reflection and supports query and
 indexing support without full-object deserialization.
-??? Provide links to https://hazelcast.com/blog/for-faster-hazelcast-queries/[Hazelcast Blog] and Portable serialization content ???
+See the related https://hazelcast.com/blog/for-faster-hazelcast-queries/[Hazelcast Blog] and the xref:serialization:implementing-portable-serialization.adoc[Portable Serialization  section].
 
 == Serialization Tuning
 
@@ -321,7 +319,8 @@ reduce binary object size by an order of magnitude.
 back-reference an object pointing to a previously serialized instance.
 If set to `false`, every instance is considered unique and copied separately
 even if they point to the same instance. The default configuration is false.
-??? Provide link to the serialization conf wrap-up content ???
+
+See also the xref:serialization:serialization-configuration.adoc[Serialization Configuration Wrap-Up section] for details.
 
 [[exec-svc-opt]]
 == Compute Tuning
@@ -338,7 +337,7 @@ threads (`pool-size` property in the executor service configuration)
 appropriate to the number of cores available for execution.
 Too few threads will reduce parallelism, leaving cores idle, while too
 many threads will cause context switching overhead.
-??? Provide link to the executor service conf content ???
+See the xref:computing:executor-service.adoc#configuring-executor-service[Configuring Executor Service section].
 
 === Bounded Execution Queue
 
@@ -350,7 +349,7 @@ an exception when the queue is full. This will avoid the overhead
 of enqueuing a task only for it to be canceled because its execution
 takes too long. It will also allow enqueuing clients to take corrective
 action rather than blindly filling up work queues with tasks faster than they can be executed.
-??? Provide link to the executor service conf content ???
+See the xref:computing:executor-service.adoc#configuring-executor-service[Configuring Executor Service section].
 
 === Avoid Blocking Operations in Tasks
 
@@ -399,7 +398,7 @@ Hazelcast also offers durable and scheduled executor services.
 Note that when a member failure occurs, durable and scheduled executor
 services come with "at least once execution of a task" guarantee,
 while the regular distributed executor service has none.
-??? Provide links to those executor services ???
+See the xref:computing:durable-executor-service.adoc[Durable] and xref:computing:scheduled-executor-service.adoc[Scheduled] executor services.
 
 === Work Queue Is Not Partitioned
 
@@ -465,8 +464,6 @@ is configured to be the number of cores on the client machine times five; e.g.,
 client machine, the internal executor service will have 20 threads.
 In some cases, increasing that thread pool size may increase performance.
 
-??? Provide link to executor pool size content ???
-
 [[ep]]
 === Entry Processors Performance Tuning
 
@@ -500,7 +497,7 @@ These optimizations apply to the following map methods only:
 * `submitToKey(Object, EntryProcessor)`
 * `submitToKey(Object, EntryProcessor, ExecutionCallback)`
 
-??? Provide link to processing map entries ???
+See the xref:computing:entry-processor.adoc[Entry Processors section].
 
 [[tls-ssl-perf]]
 == TLS/SSL Tuning
@@ -581,7 +578,7 @@ When running large numbers of clients, network stability is still a significant
 in overall stability. If you are running in Amazon EC2, hosting clients
 and members in the same zone is beneficial. Using Near Cache on read-mostly
 data sets reduces server load and network overhead. You may also try increasing
-the number of threads in the client executor pool (??? link ????.
+the number of threads in the client executor pool.
 
 [[int-response-queue]]
 == Setting Internal Response Queue Idle Strategies

docs/modules/maintain-cluster/pages/monitoring.adoc

@@ -717,15 +717,13 @@ Hazelcast exposes all its metrics using the JVM’s standard JMX interface.
 You can use tools such as **Java Mission Control** or **JConsole** to
 display them. 
 
-??????
-All Jet-related beans are stored under
-`com.hazelcast.jet/Metrics/<instanceName>/` node and the various tags
-they have form further sub-nodes in the resulting tree structure.
-
-The IMDG metrics are exposed under `com.hazelcast/$INSTANCE_NAME/Metrics` where
+The Hazelcast metrics are exposed under `com.hazelcast/$INSTANCE_NAME/Metrics` where
 `$INSTANCE_NAME` is the name of the member or client instance to which the JMX client
 is connected.
-???????
+
+And the Jet engine related beans are stored under
+`com.hazelcast.jet/Metrics/<instanceName>/` node and the various tags
+they have form further sub-nodes in the resulting tree structure.
 
 ==== Prometheus
 

docs/modules/migrate/pages/migration-tool-imdg.adoc

@@ -205,18 +205,9 @@ same contents. On the other hand, a "consistency check" might always report that
 the two IMaps are out-of-sync while in fact the contents of the IMaps are identical.
 Some examples of classes that exhibit this behavior when used as keys or values are as follows:
 
-???
-
-**Cannot use custom merge policies based on 3.x/4.x API:**
-
-???
-
-
 [#client-migration]
 === Client Migration
 
-??? TBD for 5.0 ???
-
 With Hazelcast 4.0, in addition to all the serialization changes done on the member side,
 there have been many changes in how the client connects and interacts with the cluster.
 On top of this, Hazelcast 4.0 introduced new features not available in 3.x and
@@ -236,8 +227,6 @@ the 3.12 cluster and the 3.x clients can be shut down.
 
 The same suggestion applies when migrating back from 5.0 to 3.12, only with the versions reversed.
 
-???
-
 == Using Rolling Upgrades
 
 For migrating between IMDG 4.x and Platform 5.0 releases, you can also use the

docs/modules/migrate/pages/upgrade.adoc

@@ -189,10 +189,6 @@ See the following table for the before/after script distributions:
 |===
 
 
-???
-Provide descriptions for the entries in the above table
-???
-
 === Configurations
 
 With the merge of former IMDG and Jet products, there have been changes made to the
@@ -280,10 +276,6 @@ See the following table for the before/after configuration distributions:
 |===
 
 
-???
-Provide descriptions for the entries in the above table
-???
-
 === Merge of Declarative Configurations
 
 The former Hazelcast and Jet declarative configuration