This is an automated email from the ASF dual-hosted git repository.
davsclaus pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit b5ad091669bab6f7bb09a1c8e81205cd5a5b947c
Author: Claus Ibsen <claus.ib...@gmail.com>
AuthorDate: Sun Mar 12 10:08:16 2023 +0100
CAMEL-19132: Deprecate vm and direct-vm and remove in v4
---
.../camel-direct/src/main/docs/direct-component.adoc | 8 --------
.../src/main/docs/disruptor-component.adoc | 15 +++++++--------
.../src/main/docs/disruptor-vm-component.adoc | 17 ++++++++---------
components/camel-seda/src/main/docs/seda-component.adoc | 11 ++++-------
.../modules/ROOT/pages/browsable-endpoint.adoc | 3 +--
...-the-direct-event-seda-and-vm-endpoints-compare.adoc | 4 ++--
.../faq/pages/why-use-multiple-camelcontext.adoc | 2 +-
7 files changed, 23 insertions(+), 37 deletions(-)
diff --git a/components/camel-direct/src/main/docs/direct-component.adoc
b/components/camel-direct/src/main/docs/direct-component.adoc
index f4b27210d4d..8aabe95f57c 100644
--- a/components/camel-direct/src/main/docs/direct-component.adoc
+++ b/components/camel-direct/src/main/docs/direct-component.adoc
@@ -27,14 +27,6 @@ The xref:seda-component.adoc[SEDA] component provides
asynchronous invocation of
any consumers when a producer sends a message exchange.
====
-[TIP]
-====
-*Connection to other camel contexts*
-
-The xref:vm-component.adoc[VM] component provides connections between Camel
-contexts as long they run in the same *JVM*.
-====
-
== URI format
[source]
diff --git a/components/camel-disruptor/src/main/docs/disruptor-component.adoc
b/components/camel-disruptor/src/main/docs/disruptor-component.adoc
index fe755425ba2..15c9e6304a8 100644
--- a/components/camel-disruptor/src/main/docs/disruptor-component.adoc
+++ b/components/camel-disruptor/src/main/docs/disruptor-component.adoc
@@ -15,21 +15,20 @@
The Disruptor component provides asynchronous
https://en.wikipedia.org/wiki/Staged_event-driven_architecture[SEDA] behavior
much as the
-standard SEDA Component, but utilizes a
+standard SEDA component, but utilizes a
https://github.com/LMAX-Exchange/disruptor[Disruptor] instead of a
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html[BlockingQueue]
-utilized by the standard xref:seda-component.adoc[SEDA]. Alternatively, a
*disruptor-vm:* endpoint is supported by this component, providing an
-alternative to the standard xref:vm-component.adoc[VM].
+utilized by the standard xref:seda-component.adoc[SEDA]. Alternatively, a
*disruptor-vm:* endpoint is supported by this component.
-The main advantage of choosing to use the Disruptor Component over the
-SEDA or the VM Component is performance in use cases where there is high
+The main advantage of choosing to use the Disruptor component over the
+SEDA is performance in use cases where there is high
contention between producer(s) and/or multicasted or concurrent
Consumers. In those cases, significant increases of throughput and
reduction of latency has been observed. Performance in scenarios without
-contention is comparable to the SEDA and VM Components.
+contention is comparable to the SEDA component.
The Disruptor is implemented with the intention of mimicing the
-behaviour and options of the SEDA and VM Components as much as possible.
+behaviour and options of the SEDA component as much as possible.
The main differences with the them are the following:
* The buffer used is always bounded in size (default 1024 exchanges).
@@ -46,7 +45,7 @@ complete flushing of all pending exchanges in the Disruptor.
* As a result of the reconfiguration: Data sent over a Disruptor is
directly processed and 'gone' if there is at least one consumer, late
joiners only get new exchanges published after they've joined.
-* The *pollTimeout* option is not supported by the Disruptor Component.
+* The *pollTimeout* option is not supported by the Disruptor component.
* When a producer blocks on a full Disruptor, it does not respond to
thread interrupts.
diff --git
a/components/camel-disruptor/src/main/docs/disruptor-vm-component.adoc
b/components/camel-disruptor/src/main/docs/disruptor-vm-component.adoc
index 50a6dc7c4a5..980424b4a81 100644
--- a/components/camel-disruptor/src/main/docs/disruptor-vm-component.adoc
+++ b/components/camel-disruptor/src/main/docs/disruptor-vm-component.adoc
@@ -15,11 +15,10 @@
The Disruptor component provides asynchronous
https://en.wikipedia.org/wiki/Staged_event-driven_architecture[SEDA] behavior
much as the
-standard SEDA Component, but utilizes a
+standard SEDA component, but utilizes a
https://github.com/LMAX-Exchange/disruptor[Disruptor] instead of a
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html[BlockingQueue]
-utilized by the standard xref:seda-component.adoc[SEDA]. Alternatively, a
*disruptor-vm:* endpoint is supported by this component, providing an
-alternative to the standard xref:vm-component.adoc[VM]. As with the SEDA
+utilized by the standard xref:seda-component.adoc[SEDA]. Alternatively, a
*disruptor-vm:* endpoint is supported by this component. As with the SEDA
component, buffers of the *disruptor:* endpoints are only visible within
a *single* CamelContext and no support is
provided for persistence or recovery. The buffers of the
@@ -28,15 +27,15 @@ across CamelContexts instances so you can use this
mechanism to
communicate across web applications (provided that *camel-disruptor.jar*
is on the *system/boot* classpath).
-The main advantage of choosing to use the Disruptor Component over the
-SEDA or the VM Component is performance in use cases where there is high
+The main advantage of choosing to use the Disruptor component over the
+SEDA is performance in use cases where there is high
contention between producer(s) and/or multicasted or concurrent
-Consumers. In those cases, significant increases of throughput and
+consumers. In those cases, significant increases of throughput and
reduction of latency has been observed. Performance in scenarios without
-contention is comparable to the SEDA and VM Components.
+contention is comparable to the SEDA component.
The Disruptor is implemented with the intention of mimicing the
-behaviour and options of the SEDA and VM Components as much as possible.
+behaviour and options of the SEDA component as much as possible.
The main differences with the them are the following:
* The buffer used is always bounded in size (default 1024 exchanges).
@@ -53,7 +52,7 @@ complete flushing of all pending exchanges in the Disruptor.
* As a result of the reconfiguration: Data sent over a Disruptor is
directly processed and 'gone' if there is at least one consumer, late
joiners only get new exchanges published after they've joined.
-* The *pollTimeout* option is not supported by the Disruptor Component.
+* The *pollTimeout* option is not supported by the Disruptor component.
* When a producer blocks on a full Disruptor, it does not respond to
thread interrupts.
diff --git a/components/camel-seda/src/main/docs/seda-component.adoc
b/components/camel-seda/src/main/docs/seda-component.adoc
index 0125f7d2df1..89460696e27 100644
--- a/components/camel-seda/src/main/docs/seda-component.adoc
+++ b/components/camel-seda/src/main/docs/seda-component.adoc
@@ -20,15 +20,12 @@ messages are exchanged on a
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html[BlockingQueue]
and consumers are invoked in a separate thread from the producer.
-Note that queues are only visible within a _single_
-CamelContext. If you want to communicate across
-`CamelContext` instances (for example, communicating between Web
-applications), see the xref:vm-component.adoc[VM] component.
+Note that queues are only visible within the same CamelContext.
This component does not implement any kind of persistence or recovery,
-if the VM terminates while messages are yet to be processed. If you need
-persistence, reliability or distributed SEDA, try using either
-xref:jms-component.adoc[JMS] or xref:jms-component.adoc[ActiveMQ].
+if the JVM terminates while messages are yet to be processed. If you need
+persistence, reliability or distributed SEDA, try using
+xref:jms-component.adoc[JMS].
[TIP]
====
diff --git a/docs/user-manual/modules/ROOT/pages/browsable-endpoint.adoc
b/docs/user-manual/modules/ROOT/pages/browsable-endpoint.adoc
index c66ab05a9b3..b691cb1a0ca 100644
--- a/docs/user-manual/modules/ROOT/pages/browsable-endpoint.adoc
+++ b/docs/user-manual/modules/ROOT/pages/browsable-endpoint.adoc
@@ -8,6 +8,5 @@ Some implementations include:
* xref:components::jms-component.adoc[JMS] for queues only
* xref:components::mock-component.adoc[Mock]
-* xref:components::seda-component.adoc[Seda]
-* xref:components::vm-component.adoc[VM]
+* xref:components::seda-component.adoc[SEDA]
diff --git
a/docs/user-manual/modules/faq/pages/how-do-the-direct-event-seda-and-vm-endpoints-compare.adoc
b/docs/user-manual/modules/faq/pages/how-do-the-direct-event-seda-and-vm-endpoints-compare.adoc
index 98eacddfe07..c7d799a6795 100644
---
a/docs/user-manual/modules/faq/pages/how-do-the-direct-event-seda-and-vm-endpoints-compare.adoc
+++
b/docs/user-manual/modules/faq/pages/how-do-the-direct-event-seda-and-vm-endpoints-compare.adoc
@@ -1,6 +1,6 @@
= How do the `direct`, `event`, `seda`, and `vm` endpoints compare?
-* xref:components::vm-component.adoc[VM] and
xref:components::seda-component.adoc[SEDA] endpoints are basically the
+* VM and xref:components::seda-component.adoc[SEDA] endpoints are basically the
same; they both offer asychronous in memory SEDA queues; they differ in
visibility -- endpoints are visible inside the same JVM or within the same
CamelContext respectively.
@@ -10,6 +10,6 @@ consumer when sending.
application events; so the consumer is invoked the same thread as Spring
notifies events. Event differs in that the payload should be a Spring
`ApplicationEvent` object whereas
xref:components::direct-component.adoc[Direct],
-xref:components::seda-component.adoc[SEDA] and
xref:components::vm-component.adoc[VM] can use any payload.
+xref:components::seda-component.adoc[SEDA] can use any payload.
More information about when to use which component can be found in this
https://tomd.xyz/camel-direct-vm-seda/[guide].
diff --git
a/docs/user-manual/modules/faq/pages/why-use-multiple-camelcontext.adoc
b/docs/user-manual/modules/faq/pages/why-use-multiple-camelcontext.adoc
index 7d981750a86..9f2adaab8cb 100644
--- a/docs/user-manual/modules/faq/pages/why-use-multiple-camelcontext.adoc
+++ b/docs/user-manual/modules/faq/pages/why-use-multiple-camelcontext.adoc
@@ -11,4 +11,4 @@ other Camel applications.
If you want the endpoints or producers in different camel contexts to
communicate with another, there are a number of solutions. You can use
-xref:components::jms-component.adoc[JMS], or you can use Camel's
xref:components::vm-component.adoc[VM] transport.
+xref:components::jms-component.adoc[JMS].
