Develop Camel Quarkus Applications With XML DSL
Let's show you how to develop Camel Quarkus application from scratch using XML DSL and breakdown the advantages of Camel Quarkus.
Join the DZone community and get the full member experience.Join For Free
This article is about developing Camel Quarkus Application from scratch using XML DSL. Also one can migrate his blueprint or spring or springboot based Camel routes to Camel Quarkus Application using XML DSL. Hence migration path for such applications to Quarkus would be much more easier and faster than converting Camel XML routes to Java DSL routes.
Here we will find that what advantage Camel Quarkus brings to the table. We will see that application boot time/warm-up time is so quick that even if pod restarts (due to some runtime unforeseen error) our live traffic wouldn't be impacted for more than a second. While with other framework pod may take 5 or more seconds to be in ready state so that it can start serving the requests. Thus there would be a downtime(where application wouldn't be able to server requests) of at least 5 to 10 second for each restart with non-quarkus pods. For some enterprise with real time traffic and transaction 5 to 10 or more seconds can be a big loss of revenue.
Also we will find that if we run native build than actual memory utilization(RSS) is also reduced. Here we are going to check Camel Quarkus apps in both JVM and native builds and both of these builds have clear advantage on memory footprint and boot-time over other build like blueprint(Karaf), spring, wildfly, standalone and springboot.
So let's check it straight away.
2. The example downloaded uses Java DSL. However this article is specifically about XML DSL. So you can modify this downloaded example with example here.
3. Following are the important modifications which we should be aware of.
- This example is tested in minikube thus following dependencies are required. More details are deploying-to-kubernetes and deploying-to-minikube.
- Our routes are defined in camel-route.xml and with classpath resolver this xml is loaded at runtime.
4. Now let us run with JAVA build powered by Quarkus with underlying GraalVM. We will see that the Memory utilization(RSS) in RAM(physical memory) is 163 MB.
5. Now let us deploy it in minikube with Java build powered by Quarkus.
6. If we note it took around 1.6 second to start application which is quite less when compared to other non quarkus based application. However next we will find native builds are even more quick to start.
quarkus-camel-xml 1.0.0-SNAPSHOT on JVM (powered by Quarkus 1.7.2.Final) started in 1.643s.
7. We will run this app in native mode first and than check the memory utilization. We find that only 39 MB is the memory utilization(RSS).
8. Now let us start deployment in minikube with native build powered by Quarkus.
9. In step 8, we find that native build only took 0.017 to start. This is one feature(quick boot/loading time of application) which makes Quarkus so amazing. Have you seen that quick application boot/warm-up time anywhere else ?
quarkus-camel-xml 1.0.0-SNAPSHOT native (powered by Quarkus 1.7.2.Final) started in 0.017s.
That's it guys. In this article we find that how we can write camel quarkus app in XML DSL and also deploy in Kubernetes in both JVM and native build. We find that memory utilization is quite less with Quarkus native build and boot time is also reduced a lot.
Opinions expressed by DZone contributors are their own.