Removed some topics due to streamlining miniTOC, reviewed WebUI chang…

…e, reviewed custom caching addition to MemoryXtend
Gigaspaces · Dec 10, 2017 · f9a3369 · f9a3369
1 parent ed3b8d8
commit f9a3369
Show file tree

Hide file tree

Showing 8 changed files with 699 additions and 795 deletions.
diff --git a/site/content/attachment_files/web-console/login-12.3.png b/site/content/attachment_files/web-console/login-12.3.png
diff --git a/site/content/xap/12.3/admin/memoryxtend-rocksdb-ssd.markdown b/site/content/xap/12.3/admin/memoryxtend-rocksdb-ssd.markdown
diff --git a/site/content/xap/12.3/dev-java/event-processing.markdown b/site/content/xap/12.3/dev-java/event-processing.markdown
@@ -7,36 +7,13 @@ weight: 1500
 ---
 
 
-This section will guide you through the event processing APIs and configuration on top of the Space.
+This section describes the event processing APIs and how to configure them on top of the Space. The relevant APIs include the [Notify Container](./notify-container-overview.html), which wraps the space data event session API with event container abstraction, and the Polling Container](./polling-container-overview.html), which allows you to perform polling receive operations against the Space.
 
+Events that are received by the polling and notify containers are handled by the [Event Listener](./data-event-listener.html), which is a Space Data Event Listener and the [Event Exception Listener](./event-exception-handler.html).
 
-<br>
+Regarding [FIFO Ordering](./fifo-overview.html), XAP supports both non-ordered Entries and FIFO ordered Entries when performing Space operations. XAP also includes [JMS message support](./messaging-support.html) that is built on top of the core spaces architecture.
 
-
-{{% fpanel%}}
-[Notify Container](./notify-container-overview.html){{<wbr>}}
-The notify event container wraps the space data event session API with event container abstraction.
-
-[Polling Container](./polling-container-overview.html){{<wbr>}}
-Allows you to perform polling receive operations against the space.
-
-[Event Listener](./data-event-listener.html){{<wbr>}}
-Describe the common Space Data Event Listener and its different adapters.
-
-[Event Exception Listener](./event-exception-handler.html){{<wbr>}}
-Describe the common Exception Event Listener and its different adapters.
-
-[FIFO Ordering](./fifo-overview.html){{<wbr>}}
-XAP supports both non-ordered Entries and FIFO ordered Entries when performing space operations.
-
-[JMS Integration](./messaging-support.html){{<wbr>}}
-XAP provide a JMS implementation, built on top of the core spaces architecture.
-{{%/fpanel%}}
-
-
-<br>
-
-#### Additional Resources
+# Additional Resources
 
 {{%youtube "GwLfDYgl6f8"  "Event Processing"%}}
 

diff --git a/site/content/xap/12.3/dev-java/mule-esb.markdown b/site/content/xap/12.3/dev-java/mule-esb.markdown
@@ -6,28 +6,12 @@ parent: none
 weight: 1700
 ---
 
-XAP comes with comprehensive support for Mule v3.7. It allows you to use the Space as a Mule external transport, enabling receiving and dispatching of POJO messages over the Space.
+XAP comes with comprehensive support for Mule v3.7. This allows you to use the Space as a Mule external transport, enabling receiving and dispatching of POJO messages over the Space using an [Event Container](./mule-event-container-transport.html).
 An additional transport called os-queue allows you to replace the Mule VM transport with highly available inter VM transport over the Space.
-A Mule application can be packaged and run as a Processing Unit within one of the SLA-driven Processing Unit containers.
 
-<br>
+A Mule application can be packaged and run as a [Processing Unit](./mule-processing-unit.html) within one of the SLA-driven Processing Unit containers.
 
-{{%fpanel%}}
-
-[Event Container](./mule-event-container-transport.html){{<wbr>}}
-XAP's event container transport uses event components that allow you to send and receive POJO messages over the Space using Mule.
-
-[Processing Unit](./mule-processing-unit.html){{<wbr>}}
-The Mule Processing Unit allows you to run Mule within a Processing Unit, thus leveraging all of the Processing Unit and SLA-driven container capabilities.
-
-[Queue Provider](./mule-queue-provider.html){{<wbr>}}
-The XAP queue provider is used for internal space-based communication between services managed by Mule.
-
-{{%/fpanel%}}
-
-<br>
-
-## Additional Resources
+# Additional Resources
 
 {{%exurl "Mule Site" "http://www.mulesoft.org"%}}
 

diff --git a/site/content/xap/12.3/dev-java/space-based-remoting-overview.markdown b/site/content/xap/12.3/dev-java/space-based-remoting-overview.markdown
@@ -8,26 +8,33 @@ weight: 1600
 
 
 
-Remoting allows you to use remote invocations of POJO services, with the space as the transport layer.
+Remoting allows you to use remote invocations of POJO services, with the Space as the transport layer. Spring provides support for [various remoting technologies](http://static.springframework.org/spring/docs/2.0.x/reference/remoting.html). XAP uses the same concepts to provide remoting, using the Space as the underlying protocol.
 
-<br>
+Some benefits of using the Space as the transport layer include:
 
-{{%fpanel%}}
+- **High availability** -- the Space by its nature (based on the cluster topology) is highly available, so remote invocations get this feature automatically when using the Space as the transport layer.
+- **Load-balancing** -- when using a Space with a partitioned cluster topology, each remote invocation is automatically directed to the appropriate partition (based on its routing handler), providing automatic load balancing.
+- **Performance** -- remote invocations are represented in fast internal OpenSpaces objects, providing fast serialization and transport over the net.
+- **Asynchronous execution** -- by its nature, remoting support is asynchronous, allowing for much higher throughput of remote invocations. OpenSpaces allows you to use asynchronous execution using Futures, and also provides synchronous support (built on top of it).
 
-[Overview](./space-based-remoting.html){{<wbr>}}
-Remoting services overview.
+The OpenSpaces API supports two types of remoting, distinguished by the underlying implementation used to send the remote call. The first is called [Executor-Based Remoting](./executor-based-remoting.html), and the second is called [Event-Driven Remoting](./event-driven-remoting.html).
 
-[Executor based remoting](./executor-based-remoting.html){{<wbr>}}
-Executor Remoting allows you to use remote invocations of POJO services, with the space as the transport layer using OpenSpaces Executors.
+# Choosing the Correct Remoting Mechanism
 
+This section explains when you should choose to use each of the remoting implementations. As far as the calling code is concerned, the choice between the implementations is transparent and requires only configuration changes.
 
-[Event driven remoting](./event-driven-remoting.html){{<wbr>}}
-Event Driven Remoting allows you to use remote invocations of POJO services, with the space as the transport layer using a polling container on the space side to process the invocations.
-{{%/fpanel%}}
+In most cases, you should choose [Executor-Based Remoting](./executor-based-remoting.html). It is based on the XAP [Task Executors](./task-execution-over-the-space.html) feature, and executes the method invocation by submitting a special kind of task that executes on the Space side by calling the invoked service. This option allows for synchronous and asynchronous invocation, map/reduce style invocations, and transparent invocation failover.
 
+[Event-Driven Remoting](./event-driven-remoting.html) supports most of the above capabilities, but does not support map/reduce style invocations. In terms of implementation, it's based on the [Polling Container](./polling-container-overview.html) feature, which means that it writes an invocation entry to the space which is later consumed by a polling container. Once taking the invocation entry from the space, the polling container's event handler delegates the call to the space-side service.
 
-<br>
+The [Event-Driven Remoting](./event-driven-remoting.html) implementation is slower than [Executor-Based Remoting](./executor-based-remoting.html) because it requires 4 Space operations to complete a single remote call: write invocation entry by client --> take invocation entry by polling container --> write invocation result by polling container --> take invocation result by client. In contrast, [Executor-Based Remoting](./executor-based-remoting.html) only requires a single `execute()` call.
+
+However, there are two main scenarios where you should opt for [Event-Driven Remoting](./event-driven-remoting.html) over [Executor-Based Remoting](./executor-based-remoting.html):
+
+- When you would like the actual service not to be co-located with the Space. With [Executor-Based Remoting](./executor-based-remoting.html), the remote service implementation can only be located within the Space's JVM(s). With [Event-Driven Remoting](./event-driven-remoting.html), you can put the client on a remote machine and use the classic **Master/Worker pattern** for processing the invocation. This offloads the processing from the Space (at the expense of moving your service away from the data it might need to process).
+- When unexpected bursts of invocations are a probable scenario, using [Event-Driven Remoting](./event-driven-remoting.html) may prove worthwhile, because invocations are not processed as they occur; they are "queued" in the Space and are processed by the polling container when resources are available. By limiting the number of threads of the polling container, you can ensure that the invocations don't monopolize the CPU of the Space. (The [Alerts](./administrative-alerts.html) API can help monitor this situation.)
+
+# Additional Resources
 
-#### Additional Resources
 {{%youtube "-07-0PXUoeM"  "Space based remoting"%}}
 
diff --git a/site/content/xap/12.3/dev-java/space-based-remoting.markdown b/site/content/xap/12.3/dev-java/space-based-remoting.markdown