This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit 4a348b38506c3b6b0f6db4f6aa466f8b7ef4c825
Author: Otavio R. Piske <angusyo...@gmail.com>
AuthorDate: Sat Feb 24 11:50:25 2024 +0100
CAMEL-20459: documentation fixes for the competing consumers EIP.
Signed-off-by: Otavio R. Piske <angusyo...@gmail.com>
---
.../modules/eips/pages/competing-consumers.adoc | 48 +++++++++++-----------
1 file changed, 25 insertions(+), 23 deletions(-)
diff --git
a/core/camel-core-engine/src/main/docs/modules/eips/pages/competing-consumers.adoc
b/core/camel-core-engine/src/main/docs/modules/eips/pages/competing-consumers.adoc
index 1b0b49a354b..65e0a8f2de2 100644
---
a/core/camel-core-engine/src/main/docs/modules/eips/pages/competing-consumers.adoc
+++
b/core/camel-core-engine/src/main/docs/modules/eips/pages/competing-consumers.adoc
@@ -11,15 +11,15 @@ For example from SEDA, JMS, Kafka, and various AWS
components.
image::eip/CompetingConsumers.gif[image]
- xref:ROOT:seda-component.adoc[SEDA] for SEDA based concurrent processing
using a thread pool
-- xref:ROOT:jms-component.adoc[JMS] for distributed SEDA based concurrent
processing with queues which support reliable load balancing, failover and
clustering.
+- xref:ROOT:jms-component.adoc[JMS] for distributed SEDA-based concurrent
processing with queues which support reliable load balancing, fail over, and
clustering.
-For components which does not allow concurrent consumers, then Camel allows
routeing from the consumer
+For components that do not allow concurrent consumers, then Camel allows
routing from the consumer
to a thread-pool which can then further process the message concurrently,
which then simulates a _quasi like_ competing consumers.
== Competing Consumers with JMS
-To enable Competing Consumers you just need to set the `concurrentConsumers`
property on the JMS endpoint.
+To enable Competing Consumers, you need to set the `concurrentConsumers`
property on the JMS endpoint.
For example
@@ -60,11 +60,12 @@ YAML::
== Competing Consumers with Thread Pool
You can simulate competing consumers by using a thread pool which then
continue processing the messages concurrently.
-Then the single thread consumer can quickly continue and pickup new messages
to process and offload them to the thread-pool
+Then the single thread consumer can quickly continue
+and pick up new messages to process and offload them to the thread-pool
(and its task queue).
-Suppose we have this simple route where we poll a folder for new files,
-process the files and afterwards move the files to a backup folder when
complete.
+Suppose we have this route where we poll a folder for new files,
+process the files and afterward move the files to a backup folder when
complete.
[tabs]
====
@@ -98,23 +99,24 @@ YAML::
----
====
-The route is synchronous and there is only a single consumer running at any
given time.
+The route is synchronous, and there is only a single consumer running at any
given time.
This scenario is well known, and it doesn't affect thread safety as we only
have one active thread
involved at any given time.
Now imagine that the inbox folder is filled with filers quicker than we can
process.
So we want to speed up this process. How can we do this?
-Well we could try adding a 2nd route with the same route path.
-Well that doesn't work so well as we have competing consumers for the same
files.
-That requires however that we use file locking, so we won't have two consumers
compete for the same file.
-By default, Camel support this with its file locking option on the file
component.
+Well, we could try adding a second route with the same route path.
+That doesn't work so well as we have competing consumers for the same files.
+That requires, however, that we use file locking, so we won't have two
consumers compete for the same file.
+By default, Camel supports this with its file locking option on the file
component.
-What if the component doesn't support this, or it's not possible to add a 2nd
consumer
-for the same endpoint? And yes it's _a bit of a hack_, and the route logic
code is duplicated.
-And what if we need more, then we need to add a 3rd, a 4th and so on.
+What if the component doesn't support this, or it's not possible to add a
second consumer
+for the same endpoint?
+And yes, it's _a bit of a hack_, and the route logic code is duplicated.
+And what if we need more, then we need to add a third, a fourth and so on.
-What if the processing of the file itself is the bottleneck, i.e. the
`calculateBean` is slow?
+What if the processing of the file itself is the bottleneck, i.e., the
`calculateBean` is slow?
So how can we process messages with this bean concurrently?
We can use the xref:threads-eip.adoc[Threads EIP], so if we insert it in the
route we get:
@@ -160,19 +162,19 @@ it should use a thread pool with up till 10 concurrent
threads.
So when the file consumer delivers a message to the threads, then the threads
take it from there,
and the file consumer can return and continue to poll the next file.
-By leveraging this fact we can still use a single file consumer to poll new
files.
+By leveraging this fact, we can still use a single file consumer to poll new
files.
And polling a directory to just grab the file handle is very fast.
-And we won't have problem with file locking, sorting, filtering and whatnot.
+And we won't have a problem with file locking, sorting, filtering, and whatnot.
And at the same time we can leverage the fact that we can process the file
messages concurrently
by the `calculateBean` bean.
-Here at the end lets take a closer look what happens with the synchronous
thread and the
+Here at the end, let's take a closer look at what happens with the synchronous
thread and the
asynchronous thread. The synchronous thread hands over the exchange to the new
asynchronous thread and as
-such the synchronous thread completes. The asynchronous thread is then routing
and processing the message.
-And when this thread finishes it will take care of the file completion
strategy to move the file
-into the backup folder. This is an important note, that the on completion is
done by the asynchronous thread.
+ such, the synchronous thread completes. The asynchronous thread is then
routing and processing the message.
+And when this thread finishes, it will take care of the file completion
strategy to move the file
+into the backup folder. This is an important note that the on completion is
done by the asynchronous thread.
This ensures the file is not moved before the file is processed successfully.
Suppose the `calculateBean` bean
-could not process one of the files. If it was the asynchronous thread that
should do the on completion strategy
+could not process one of the files. If it was the asynchronous thread that
should do the on completion strategy,
then the file would have been moved to early into the backup folder. By
handing over this to the asynchronous
-thread we do it after we have processed the message completely
+ thread, we do it after we have processed the message completely
