Thanks for sharing and it was a great demo. I am a big fan of Apache Camel and it has been working for me extremely well in production for many years. I do understand your demo is just to depict the Throttle. Just want to add up here, Although, Throttle save our application to consume as expected request as we assumed, it move the pressure to incoming component part, in this case to RabbitMQ, which it has limitation to queue up the incoming requests as well based on the resources in MQ. In this case we can also add up the SEDA (Staged Event-Driven Architecture) component to stage incoming messages and process them asynchronously, which can help to handle bursts of traffic and maximize the use of our resources.
Thanks for sharing your input. I do agree this approach can create back-pressure. There are several ways to overcome this problem, and SEDA is one such approach. I like SEDA but it has it's own pros & cons. One issue could be that you might endup over consuming messages and then lose all in JVM crash.
Good video. Will be nice to know how to configure properly message broker with throttler and queue size not to loose data. I guess it's also possible to persist data if it exceed queue size.
This method is used when you want to construct the URI using a formatted string (similar to String.format() in Java). Example: fromF("file:%s?fileName=%s", "inputFolder", "test.txt") .to("log:received");
70 / 5.000
The best explained tutorials I've seen / read of apache camel. Thanks
Sir , you are too good. Hats off to you.
Thanks for sharing and it was a great demo. I am a big fan of Apache Camel and it has been working for me extremely well in production for many years. I do understand your demo is just to depict the Throttle. Just want to add up here, Although, Throttle save our application to consume as expected request as we assumed, it move the pressure to incoming component part, in this case to RabbitMQ, which it has limitation to queue up the incoming requests as well based on the resources in MQ. In this case we can also add up the SEDA (Staged Event-Driven Architecture) component to stage incoming messages and process them asynchronously, which can help to handle bursts of traffic and maximize the use of our resources.
Thanks for sharing your input. I do agree this approach can create back-pressure. There are several ways to overcome this problem, and SEDA is one such approach. I like SEDA but it has it's own pros & cons. One issue could be that you might endup over consuming messages and then lose all in JVM crash.
Thanks, it's clever to put the throttle directly after a queue, so the memory stay low.
Good video. Will be nice to know how to configure properly message broker with throttler and queue size not to loose data.
I guess it's also possible to persist data if it exceed queue size.
Brilliant. Can you also explain how you managed to print the number increments on the same line on the console?
You can use
Hi could you explain what is the difference between from and fromF?
This method is used when you want to construct the URI using a formatted string (similar to String.format() in Java).
Example: fromF("file:%s?fileName=%s", "inputFolder", "test.txt")
.to("log:received");