Here are Red Hat JBoss Fuse ESB interview questions and answers for fresher as well as experienced candidates to get the dream job.
The following are the components of Red Hat Jboss Fuse.
It’s because we believe developers should be able to choose what best suits them, for example:
We can go with following deployment options:
JBoss Fuse consists of the following directories.
JBoss Fuse provides more than 200 connectors that are ready to use for supporting Integration everywhere. It supports integration for the extended enterprise, including applications and services on-premise, or in the cloud, or on mobile devices. Users can connect from legacy systems to Software-as-a-Service (SaaS) applications, and application programing interfaces (APIs) to Internet of Things (IoT) devices.
SwitchYard is a lightweight service delivery framework on top of JBoss Fuse. It provides full lifecycle support to develop, deploy, and manage Service-Oriented Applications. It works with Apache Camel along with comprehensive connectivity and transports to provide a fast, simple, flexible integration runtime.
Apache Karaf is a powerful OSGi-based runtime container to deploy and manage bundles. JBoss Fuse uses Apache Karaf as the runtime. It is where the application bundles run. Apache Karaf is built on top of OSGi Frameworks like Felix and equinox. While Docker is an open platform that enables developers and system administrators to create distributed applications.
The main advantages / disadvantages for these styles are the same as monolith vs. microservice architecture. I’ve used both extensively and they solve different problems. In short: OSGi Apache Karaf can help you build an application which is modular but in the end (no matter how many or little modules used) still runs in a single JVM process. Docker can help you to manage the deployment of an application which often helps if your solution is architected as a microservices (a whole bunch of separate processes) and run into multiple JVMs.
OSGi (Open Service Gateway Initiative) is a Java framework for developing and deploying modular software programs and libraries.
OSGi has two parts. The first part is a specification for modular components called bundles, which are commonly referred to as plug-ins. The specification defines an infrastructure for a bundle’s life cycle and determines how bundles will interact. The second part of OSGi is a Java Virtual Machine (JVM)-level service registry that bundles can use to publish, discover and bind to services in a service-oriented architecture (SOA).
In simple words the OSGi technology is a set of specifications that define a dynamic component system for java. These specifications allow a development model where applications are (dynamically) composed of many different (reusable) components.
The JVM Problem: JVM or Java virtual Machine does not act as an actual virtual machine. A machine which will allow you to stop, start or restart components running inside it on the fly. It may sometimes allow hot deployments at class level but there is no way you could deploy or undeploy a component of your application in your virtual machine without restarting it. To solve this problem and allow modularity in Java application, Fuse uses an OSGi based runtime known as Apache Karaf.
Apache Karaf is an OSGi based runtime, it is where our Application bundles run. Fuse uses Apache Karaf as its runtime in which bundles run and collaborate to provide business functionality.
Karaf is built on Felix and equinox which are OSGi Frameworks.
Apache Karaf adds the following additional functionalities to basic OSGi runtime.
Karaf supports hot deployment. It contains a hot deploy directory. Anything that is placed in this directory is automatically deployed and installed in Karaf as a bundle.
Karaf provides centralized logging by generating logs for all bundles in $Fuse_home/data/log. We can edit logger configuration in org.ops4j.pax.logging.cfg in $Fuse_home/etc directory.
Karaf provides a sophisticated and lucid Admin console to interact with running instance of fuse. It also provides a pre-installed set of commands which can be used to manage and monitor components (Bundle) at runtime. This console is extensible so it allows us to add new commands to the console by adding new bundles to console.
Karaf allows remote access to this Admin console with SSH. Anyone with valid credentials can connect to karaf admin console over SSH terminal.
This is achieved by using the Apache Felix Plugin. For step by step guide: Red Hat JBoss Fuse ESB + Apache Camel + ActiveMQ + OSGI Blueprint DSL + Example
Applications in an OSGi environment are subject to the lifecycle of its bundles.
Bundles have six lifecycle states:
We will discuss about the basic configuration of JBoss Fuse and for that we have to start with the following command Edit $FUSE_INSTALLATION_DIR/etc/
There are three types of deployment models in JBoss Fuse.
Manifest-Version: 1.0 Built-By: cruise Bundle-Activator: org.apache.camel.osgi.Activator Created-By: Apache Maven Bundle Plugin Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt Import-Package: javax.xml.bind,javax.xml.bind.annotation,org.apache.camel Bnd-LastModified: 1233952200932 Export-Package: org.apache.camel.osgi;version="1.6.0.fuse" Bundle-Version: 1.5.4.fuse Bundle-Name: camel-osgi Bundle-Description: Camel OSGi support Build-Jdk: 1.5.0_12 Private-Package: !* Bundle-DocURL: http://open.iona.com Bundle-ManifestVersion: 2 Bundle-Vendor: IONA Open Source Community Bundle-SymbolicName: org.apache.camel.camel-osgi Implementation-Title: Apache Camel Tool: Bnd-0.0.255 Implementation-Version: 1.5.4.0-fuse
JBossFuse:karaf@root> osgi:install -s mvn:com.the.basic.tech.info/apache-camel-cxfrs-webservice/1.0.0-SNAPSHOT Bundle ID: 296
CamelContext may contain one or more routes. Routes are the integration logic which defines how data will flow in camel context from one endpoint to another.
Endpoint is end of channel through which system can send or receive messages. This is what we call as destination or source in communication language.
Components are point of extension in Camel. Components can be an interface to technology, data format, transformers, etc. They may also act as a factory for endpoints.
Component | Artifact | Since | Description |
---|---|---|---|
Bean | camel-bean | 1.0 | Invoke methods of Java beans stored in Camel registry. |
Browse | camel-browse | 1.3 | Inspect the messages received on endpoints supporting BrowsableEndpoint. |
Class | camel-bean | 2.4 | Invoke methods of Java beans specified by class name. |
Control Bus | camel-controlbus | 2.11 | Manage and monitor Camel routes. |
Data Format | camel-dataformat | 2.12 | Use a Camel Data Format as a regular Camel Component. |
Dataset | camel-dataset | 1.3 | Provide data for load and soak testing of your Camel application. |
DataSet Test | camel-dataset | 1.3 | Extends the mock component by pulling messages from another endpoint on startup to set the expected message bodies. |
Direct | camel-direct | 1.0 | Call another endpoint from the same Camel Context synchronously. |
Direct VM | camel-directvm | 2.10 | Call another endpoint from any Camel Context in the same JVM synchronously. |
File | camel-file | 1.0 | Read and write files. |
Kamelet | camel-kamelet | 3.8 | To call Kamelets |
Kamelet Reify | camel-kamelet-reify | 3.6 | To call Kamelets (indirectly) |
Language | camel-language | 2.5 | Execute scripts in any of the languages supported by Camel. |
Log | camel-log | 1.1 | Log messages to the underlying logging mechanism. |
Mock | camel-mock | 1.0 | Test routes and mediation rules using mocks. |
Ref | camel-ref | 1.2 | Route messages to an endpoint looked up dynamically by name in the Camel Registry. |
REST | camel-rest | 2.14 | Expose REST services or call external REST services. |
REST API | camel-rest | 2.16 | Expose OpenAPI Specification of the REST services defined using Camel REST DSL. |
Saga | camel-saga | 2.21 | Execute custom actions within a route using the Saga EIP. |
Scheduler | camel-scheduler | 2.15 | Generate messages in specified intervals using java.util.concurrent.ScheduledExecutorService. |
SEDA | camel-seda | 1.1 | Asynchronously call another endpoint from any Camel Context in the same JVM. |
Stub | camel-stub | 2.10 | Stub out any physical endpoints while in development or testing. |
Timer | camel-timer | 1.0 | Generate messages in specified intervals using java.util.Timer. |
Validator | camel-validator | 1.1 | Validate the payload using XML Schema and JAXP Validation. |
VM | camel-vm | 1.1 | Call another endpoint in the same CamelContext asynchronously. |
XSLT | camel-xslt | 1.3 | Transforms XML payload using an XSLT template. |
XSLT Saxon | camel-xslt-saxon | 3.0 | Transform XML payloads using an XSLT template using Saxon. |
ActiveMQ | camel-activemq | 1.0 | Send messages to (or consume from) Apache ActiveMQ. This component extends the Camel JMS component. |
AMQP | camel-amqp | 1.2 | Messaging with AMQP protocol using Apache QPid Client. |
Enterprise Integration Pattern: Camel supports most of the Enterprise Integration Patterns s.t.
It is main purpose of WireTap. As example for logging or auditing outside of main thread to do not slow main thread for non-functional operations.
Main Difference is :
In relation to “what to use when” :
Digital transmission is a procedure of sharing information digitally.
First of all we need to create a bundle using Maven, just in the same way that we might create a JAR file. To do this, we need to add the Maven Bundle Plugin to our Maven POM, and set your packaging type to bundle. An OSGi bundle is just a certain type of Java application. It looks pretty much like a .jar file, but it also has some metadata inside, which describes the application’s dependencies and configuration.
Once we have created a bundle, and we want to deploy it into JBoss Fuse – known as installing a bundle – we should use the following command from the Fuse console:
osgi:install <mvn: artifact>
The mvn: prefix means that JBoss Fuse will use Maven to look for the bundle. It look for bundle in the local Maven repository, and it also searches a number of public repositories, such as Maven Central.
<?xml version="1.0" encoding="UTF-8"?> <features name="CustomRepository"> </features>
Now, we can add a feature to the custom feature repository like as below:
<?xml version="1.0" encoding="UTF-8"?> <features name="CustomRepository"> <feature name="example-camel-bundle"> <feature>camel-core</feature> <feature>camel-spring-osgi</feature> <feature>servicemix-camel</feature> <bundle>file:C:/Projects/camel-bundle/target/camel-bundle-1.0-SNAPSHOT.jar</bundle> </feature> </features>
To check whether the features service successfully parses the new feature entry, enter the following pair of console commands:
karaf@root> features:addUrl file:C:/Projects/features.xml karaf@root> features:refreshUrl karaf@root> features:list ... [uninstalled] [0.0.0 ] example-camel-bundle CustomRepository ...
By adding a configfile element to a feature, you can ensure that an OSGi configuration file gets added to the InstallDir/etc directory at the same time that the feature is installed. This means that you can conveniently install a feature and its associated configuration at the same time.For example, given that the org.fusesource.fuseesb.example.cfg configuration file is archived in a Maven repository at mvn:org.fusesource.fuseesb.example/configadmin/1.0/cfg, you could deploy the configuration file by adding the following element to the feature:
<configfile finalname="etc/org.fusesource.fuseesb.example.cfg"> mvn:org.fusesource.fuseesb.example/configadmin/1.0/cfg </configfile>
Red Hat JBoss Fuse uses the OPS4j Pax Logging system. Pax Logging is an open source OSGi logging service that extends the standard OSGi logging service to make it more appropriate for use in enterprise applications. It uses Apache Log4j as the back-end logging service. Pax Logging has its own API, but it also supports the following APIs:
JBossFuse:karaf@root> config:edit org.ops4j.pax.logging JBossFuse:karaf@root> config:propappend log4j.appender.stdout.append true JBossFuse:karaf@root> config:update
The most useful logger to change when trying to debug an issue with Red Hat JBoss Fuse is the root logger. Suppose You want to set the logging level to generate more fine grained messages. To do so you change the value of the org.ops4j.pax.logging PID’s log4j.rootLogger property so that the logging level is one of the following:
JBossFuse:karaf@root> config:edit org.ops4j.pax.logging JBossFuse:karaf@root> config:propset log4j.rootLogger "DEBUG, out, osgi:VmLogAppender" JBossFuse:karaf@root> config:update
The Red Hat JBoss Fuse console provides the following commands for managing logging output:
log:display
Displays the most recent log entries. By default, the number of entries returned and the pattern of the output depends on the size and pattern properties in the org.apache.karaf.log.cfg file. You can override these using the -p and -d arguments.
log:display-exception
Displays the most recently logged exception.
log:get
Displays the current log level.
log:set
Sets the log level.
log:tail
Continuously display log entries.
log:clear
Clear log entries.
Red Hat Fuse component details for each product release are listed below. As part of the release process, multiple open-source community components may be added or removed for dependency or compatibility purposes; other components may be included as technology previews.
The following community components have been integrated into Red Hat Fuse 7.10.
Component | Version |
---|---|
Spring Boot | 2.3.12.RELEASE |
Apache Karaf | 4.2.12 |
Karaf Maven Plugin | 4.2.12 |
Apache Camel | 2.23.2 |
Wildfly Camel | 5.8.0 |
Apache CXF (on Apache Karaf and Spring Boot) | 3.3.6 |
Apache CXF (on JBoss EAP) | 3.3.12 |
Hawtio | 2.0.0 |
Hibernate core | 5.3.23 |
OpenShift Maven Plugin | 1.3.0 |
Narayana | 5.11.3 |
Undertow | 2.2.12 |
RH SSO | 7.4.9 |
The following community components have been integrated into Red Hat Fuse 7.9.
Component | Version |
---|---|
Spring Boot | 2.3.9.RELEASE |
Apache Karaf | 4.2.11 |
Karaf Maven Plugin | 4.2.11 |
Apache Camel | 2.23.2 |
Wildfly Camel | 5.7.0 |
Apache CXF (on Apache Karaf and Spring Boot) | 3.3.6 |
Apache CXF (on JBoss EAP) | 3.3.9 |
Hawtio | 2.0.0 |
Hibernate core | 5.3.20 |
Fabric8 Maven Plugin | 4.3.0 |
Narayana | 5.11.3 |
Undertow | 2.2.5 |
RH SSO | 7.4.6 |
The following community components have been integrated into Red Hat Fuse 7.8.
Component | Version |
---|---|
Spring Boot | 2.3.4.RELEASE |
Apache Karaf | 4.2.9 |
Karaf Maven Plugin | 4.2.9 |
Apache Camel | 2.23.2 |
Wildfly Camel | 5.6.0 |
Apache CXF (on Apache Karaf and Spring Boot) | 3.3.6 |
Apache CXF (on JBoss EAP) | 3.3.5 |
Hawtio | 2.0.0 |
Hibernate core | 5.3.17 |
Fabric8 | 3.0.11 |
Fabric8 Maven Plugin | 3.5.42 |
Narayana | 5.9.8 |
Undertow | 2.0.30 |
RH SSO | 7.4.2 |
The following community components have been integrated into Red Hat Fuse 7.7.
Component | Version |
---|---|
Spring Boot | 1.5.22.RELEASE 2.1.6.RELEASE |
Apache Karaf | 4.2.6 |
Karaf Maven Plugin | 4.2.6 |
Apache Camel (on Apache Karaf, JBoss EAP and Spring Boot 1.5) | 2.21.0 |
Apache Camel (on Spring Boot 2.1.3) | 2.23.2 |
Wildfly Camel | 5.5.0 |
Apache CXF (on Apache Karaf and Spring Boot) | 3.2.7 |
Apache CXF (on JBoss EAP) | 3.2.11 |
Hawtio | 2.0.0 |
Hibernate core | 5.3.15 |
Fabric8 | 3.0.11 |
Fabric8 Maven Plugin (in Karaf and Spring Boot 1) | 3.5.33 |
Fabric8 Maven Plugin (in Spring Boot 2) | 3.5.42 |
Narayana (on Apache Karaf and Spring Boot) | 5.9.8 |
Narayana (on JBoss EAP) | 5.9.6 |
Undertow (on Apache Karaf and Spring Boot) | 2.0.30 |
Undertow (on JBoss EAP) | 2.0.28 |
RH SSO | 7.3.7 |
The following community components have been integrated into Red Hat Fuse 7.6.
Component | Version |
---|---|
Spring Boot | 1.5.22.RELEASE 2.1.6.RELEASE |
Apache Karaf | 4.2.6 |
Karaf Maven Plugin | 4.2.6 |
Apache Camel (on Apache Karaf, JBoss EAP and Spring Boot 1.5) | 2.21.0 |
Apache Camel (on Spring Boot 2.1.3) | 2.23.2 |
Wildfly Camel | 5.4.0 |
Apache CXF (on Apache Karaf and Spring Boot) | 3.2.7 |
Apache CXF (on JBoss EAP 7.2.5) | 3.2.5 |
Hawtio | 2.0.0 |
Hibernate | 5.3.13 |
Fabric8 | 3.0.11 |
Fabric8 Maven Plugin (in Karaf and Spring Boot 1) | 3.5.33 |
Fabric8 Maven Plugin (in Spring Boot 2) | 3.5.42 |
Narayana | 5.9.6 |
Undertow | 2.0.26 |
RH SSO | 7.3.5 |
The following community components have been integrated into Red Hat Fuse 7.5.
Component | Version |
---|---|
Spring Boot | 1.5.19.RELEASE 2.1.6.RELEASE |
Apache Karaf | 4.2.6 |
Karaf Maven Plugin | 4.2.6 |
Apache Camel (on Apache Karaf, JBoss EAP and Spring Boot 1.5) | 2.21.0 |
Apache Camel (on Spring Boot 2.1.3) | 2.23.2 |
Wildfly Camel | 5.3.0 |
Apache CXF (on Apache Karaf and Spring Boot) | 3.2.7 |
Apache CXF (on JBoss EAP 7.2.3) | 3.2.5 |
Hawtio | 2.0.0 |
Hibernate | 5.3.10 |
Fabric8 | 3.0.11 |
Fabric8 Maven Plugin | 3.5.33 |
Narayana | 5.9.3 |
Undertow | 2.0.22 |
RH SSO | 7.3.3 |
The following community components have been integrated into Red Hat Fuse 7.4.
Component | Version |
---|---|
Spring Boot | 1.5.19.RELEASE 2.1.3.RELEASE |
Apache Karaf | 4.2.0 |
Karaf Maven Plugin | 4.2.0 |
Apache Camel (on Apache Karaf, JBoss EAP and Spring Boot 1.5) | 2.21.0 |
Apache Camel (on Spring Boot 2.1.3) | 2.23.0 |
Wildfly Camel | 5.3.0 |
Apache CXF (on Apache Karaf and Spring Boot) | 3.2.7 |
Apache CXF (on JBoss EAP 7.2.1) | 3.2.7 |
Hawtio | 2.0.0 |
Hibernate | 5.3.10 |
Fabric8 | 3.0.11 |
Fabric8 Maven Plugin | 3.5.33 |
Narayana | 5.9.1 |
Undertow | 2.0.20 |
The following community components have been integrated into Red Hat Fuse 7.3.
Component | Version |
---|---|
Spring Boot | 1.5.17.RELEASE |
Apache Karaf | 4.2.0 |
Karaf Maven Plugin | 4.2.0 |
Apache Camel | 2.21.0 |
Wildfly Camel | 5.3.0 |
Apache CXF (on Apache Karaf and Spring Boot) | 3.2.7 |
Apache CXF (on JBoss EAP) | 3.2.5 |
Hawtio | 2.0.0 |
Hibernate | 5.3.7 |
Fabric8 | 3.0.11 |
Fabric8 Maven Plugin | 3.5.33 |
Narayana | 5.9.0 |
Undertow | 2.0.15 |
The following community components have been integrated into Red Hat Fuse 7.2.
Component | Version |
---|---|
Spring Boot | 1.5.16.RELEASE |
Apache Karaf | 4.2.0 |
Karaf Maven Plugin | 4.2.0 |
Apache Camel | 2.21.0 |
Wildfly Camel | 5.2.0 |
Apache CXF | 3.1.11 |
Hawtio | 2.0.0 |
Hibernate | 5.1.16 |
Fabric8 | 3.0.11 |
Fabric8 Maven Plugin | 3.5.33 |
Narayana | 5.5.31 |
Undertow | 1.4.18 |
The following community components have been integrated into Red Hat Fuse 7.1.
Component | Version |
---|---|
Spring Boot | 1.5.13.RELEASE |
Apache Karaf | 4.2.0 |
Karaf Maven Plugin | 4.2.0 |
Apache Camel | 2.21.0 |
Wildfly Camel | 5.2.0 |
Apache CXF | 3.1.11 |
Hawtio | 2.0.0 |
Hibernate | 5.1.13 |
Fabric8 | 3.0.11 |
Fabric8 Maven Plugin | 3.5.33 |
Narayana | 5.5.31 |
The following community components have been integrated into Red Hat Fuse 7.0.
Component | Version |
---|---|
Spring Boot | 1.5.12.RELEASE |
Apache Karaf | 4.2.0 |
Karaf Maven Plugin | 4.2.0 |
Apache Camel | 2.21.0 |
Wildfly Camel | 5.1.0 |
Apache CXF | 3.1.11 |
Hawtio | 2.0.0 |
Hibernate | 5.1.10 |
Fabric8 | 3.0.11 |
Fabric8 Maven Plugin | 3.5.33 |
Narayana | 5.5.31 |
The following community components have been integrated into JBoss Fuse 6.3.
Component | Version |
---|---|
Apache ActiveMQ | 5.11.0 |
Apache Camel | 2.17.0 |
Apache CXF | 3.1.5 |
Apache Karaf | 2.4 |
Fabric8 | 1.2 |
SwitchYard | 2.1.0 |
Hibernate | 4.2.22 |
The following community components have been integrated into Fuse Integration Services 2.0 for OpenShift.
Component | Version |
---|---|
Spring Boot | 1.4.1.RELEASE |
Apache Camel | 2.18.1 (Java image) 2.17.0 (Karaf image) |
Apache CXF | 3.1.5 |
Apache Karaf | 2.4 |
Karaf Maven Plugin | 4.0.8 |
Fabric8 | 2.2.170 |
Fabric8 Maven Plugin | 3.1.80 |
The following community components have been integrated into JBoss Fuse 6.2.1.
Component | Version |
---|---|
Apache ActiveMQ | 5.11.0 |
Apache Camel | 2.15.1 |
Apache CXF | 3.0.4 |
Apache Karaf | 2.4 |
Fuse Fabric | 7.2.0 (Fabric8 1.2) |
SwitchYard | 2.0.1 |
The following community components have been integrated into JBoss Fuse 6.2.
Component | Version |
---|---|
Apache ActiveMQ | 5.11.0 |
Apache Camel | 2.15.1 |
Apache CXF | 3.0.4 |
Apache Karaf | 2.4 |
Fuse Fabric | 7.2.0 (Fabric8 1.2) |
SwitchYard | 2.0.1 |
The following community components have been integrated into JBoss Fuse 6.1.
Component | Version |
---|---|
Apache ActiveMQ | 5.9.0 |
Apache Camel | 2.12.0 |
Apache CXF | 2.7.0 |
Apache Karaf | 2.3 |
Fuse Fabric | 7.2.0 (Fabric8 1.2) |
The following community components have been integrated into JBoss Fuse 6.0.
Component | Version |
---|---|
Apache ActiveMQ | 5.8.0 |
Apache Camel | 2.10.0 |
Apache CXF | 2.6.0 |
Apache Karaf | 2.3 |
Fuse Fabric | 7.2.0 |
We can use jdbc component or sql component to integrate with Database. In our application the SQL component with databases being used.
We need to add the following dependency to their pom.xml for this component:
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-jdbc</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency>
Note: This component can only be used to define producer endpoints, which means that you cannot use the JDBC component in a from() statement. E.g. First we need to register our datasource in the Camel registry as testdb: then we can use it in our camel route as below. In this component we have to pass the query in camel body.
from("timer://MoveNewCustomersEveryHour?period=3600000") .setBody(constant("select * from customer where create_time > (sysdate-1/24)")) .to("jdbc:testdb") .split(body()) .process(new MyCustomerProcessor()) //filter/transform results as needed .setBody(simple("insert into processed_customer values('${body[ID]}','${body[NAME]}')")) .to("jdbc:testdb");
We can use camel-sql Component in our application in Camel route as below. First we need to add maven artifact in pom.xml.
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-sql</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency>
from("direct:query") .to("sql:select * from projects where project in (:#in:names) order by id") .to("log:query") .to("mock:query");
Under Splitter EIP “Splitting big messages”, it briefly discusses using streaming with the splitter in context of the tokenizer, which only processes strings. It states that tokenizer uses java.util.Scanner to read chunks of data into memory. So the Scanner reads a “stream” of data, based on a token. The Scanner object is then passed back to Camel as an Expression, which Camel then uses to iterate over and deliver as parts. Is this correct? Hence we have to handle this in Customized Iterator I mean we have to split big binary file into smaller chunks in MyCustomFileChunkIterator() processor e.g.
public void configure() throws Exception{ from( "file://file-item-list/general?initialDelay=1000&delay=5000&delete=true" ) .transacted( "PROPAGATION_REQUIRED" ) .split(ExpressionBuilder.beanExpression(new MyCustomFileChunkIterator(), "iterator")) // split big file of items into smaller chunks .streaming() .to("activemq:queue:file-item-sublist-request"); }
Apache Camel offers various components and enterprise integration patterns (EIPs) to achieve concurrency.
When using Multicast EIP for parallel processing, Camel uses a default thread pool which has a maximum pool size of 20, limiting the number of parallel threads that can be spanned to 20:
<threadPoolProfile id=”defaultThreadPoolProfile” defaultProfile=”true” poolSize=”10” maxPoolSize=”20” maxQueueSize=”1000” allowCoreThreadTimeOut=”false” rejectedPolicy=”CallerRuns”/>
With these pool size settings, multicast invocation becomes a major performance bottleneck when processing higher transactions per second (TPS).
It’s recommended to use a custom thread pool tuned for the performance needs of each use case rather than using default thread pool settings as below.
<threadPool id=”customThreadPool” threadName=”customThread” poolSize=”300” maxPoolSize=”300”/> from (“mainRoute”) .multicast() .aggregationStrategy (new ResponseAggregator()) .parallelProcessing() .executorServiceRef(customThreadPool) .to (“subRoute1”, “subRoute2”, "subroute3”)
Note: Streaming should be applied only if the AggregationStrategy does not depend on the order of responses from the sub-routes. An example is:
from (“mainRoute”) .multicast() .aggregationStrategy (new ResponseAggregator()) .parallelProcessing() .streaming() .executorService(executorService) .to (“subRoute1”, “subRoute2”, "subroute3”)
Note: Enabling parallel aggregation would require the AggregationStrategy to be implemented as thread safe. An example is:
from (“mainRoute”) .multicast() .aggregationStrategy(new ResponseAggregator() .parallelAggregate() .parallelProcessing() .streamlining() .executorService (executorService) .to (“subRoute1, “subRoute2”, "subroute3”)
Error Handler | Description |
DefaultErrorHandler | This is the default error handler that’s automatically enabled, in case no other has been configured. |
DeadLetterChannel | This error handler implements the Dead Letter Channel EIP. |
TransactionErrorHandler | This is a transaction-aware error handler extending the default error handler. |
NoErrorHandler | This handler is used to disable error handling altogether. |
LoggingErrorHandler | This error handler just logs the exception. This error handler is deprecated, in favor of using the DeadLetterChannel error handler, using a log endpoint as the destination. |
By default Apache Camel will perform any redelivery (retry) attempts from the point of failure. So if we want to retry from a point before this, we would need to split up our route for implementing redeliveryPolicy.
<!-- this is the processor that will fail the first 2 attempts --> <bean id="myProcessor" class="org.apache.camel.processor.RedeliverToSubRouteTest.MyProcessor"/> <camelContext xmlns="http://camel.apache.org/schema/spring"> <!-- setup no error handler with an id, we refer to from the 2nd route --> <errorHandler id="noErrorHandler" type="NoErrorHandler"/> <!-- configure on exception to redelivery at most 2 times when an IOException was thrown do not use redelivery delay to run unit test faster --> <onException> <exception>java.io.IOException</exception> <redeliveryPolicy maximumRedeliveries="2" redeliveryDelay="0"/> </onException> <!-- 1st route, no need to setup error handler, as it will use the default error handler --> <route> <from uri="direct:start"/> <to uri="mock:a"/> <to uri="direct:sub"/> <to uri="mock:c"/> </route> <!-- disable error handler on this route, so the entire route can be redelivered when called from the 1st route --> <route errorHandlerRef="noErrorHandler"> <from uri="direct:sub"/> <to uri="mock:b"/> <process ref="myProcessor"/> </route> </camelContext>
Adding a custom Processor (MyProcessor.java) for throwing exception for the testing.
package org.apache.camel.processor.RedeliverToSubRouteTest public static class MyProcessor implements Processor { private int counter; @Override public void process(Exchange exchange) throws Exception { // use a processor to simulate error in the first 2 calls if (counter++ < 2) { throw new IOException("Exception Occured. Retry !!!"); } exchange.getIn().setBody("No Exception - Relax."); } }
<camelContext trace="true" xmlns="http://activemq.apache.org/camel/schema/spring"> ... </camelContext>
Some third party tools offer Apache Camel route debugging.
Thank you for reading. Will be adding more Q&A, keep visiting 🙂