Hi Camel riders
As you know we are working on Camel 2.0 and we decided to do a 2nd
milestone release.
This gives us more time to start on some of the ideas and internal
refactorings I wanted
to do for Camel 2.1.
After having dived really deed in the camel core codebase for the
last
6+ months or longer, I
feel that we need to cease the moment and do a more extensive house
cleaning before the Camel 2.0
release. The house cleaning is only internal and will not affect
end
users of Camel.
Here are 2 issues I would like to address in the foreseeable
future.
1) Channel
==========
To introduce a Channel between each node in the route path. The
channel is a composite processor
that is responsible for routing the exchange to the next node in
the path.
We already do this but there is no visible notion of a Channel. The
"Channel" exists today as
a series of interceptors and an error handler. Today this is
wrapped
at route build time
and then we have a static list of processors the exchanges is
routed
through a runtime.
So what I am working on is to composite this series of interceptors
and error handler into a
DefaultChannel class that has the logic to do needed work before an
Exchange is routed to the next
node.
I have already discussed this a bit with Gert and James. James
agreed
that it a was time for introducing
the Channel into Camel.
So I have started experimenting with this and got it working
locally.
The Channel is in this first
stage just wrapping the existing series of interceptors and error
handler and thus the route logic
is not affect.
In the future the Channel will benefit in many ways as we can at
runtime add routing logic for instance
- enabling/disabling tracing (and other interceptors) at runtime
without reloading routes
- adding or removing interceptors at runtime without reloading
routes
- adding or removing JMX performance metrics at runtime without
reloading routes
- we could use it to blocking routing
- enhanced tooling support
- potential you could persist exchanges at the channel
- later add true async processing with the help of the channel
- easier to traverse the runtime route graph as we can traverse the
Channel, where we can have next/prev or the like methods
- and much more we can imagine
2) AsyncProcessor
=================
I propose to remove the AsyncProcessor all together. I had a chat
with
James about it and it was an experiment by Hiram back in early
2007.
Basically he had not worked on the code since, and its not really
put
into good use. But sadly over time the AsyncProcessor have spread
itself into other core parts of Camel.
The basic idea was to attach a callback to a route so you could do
some "commit" work after the exchange is finished.
This idea is actually superseded by the UnitOfWork (introduced by
James) that is better for this kind of work. And we have schduled
an
overhaul for UnitOfWork
in Camel 2.1 to allow more of our components to take advantage of
this
and also expose DSLs for end users to attach their custom
processors
or route.
The code in Camel core that is affected by the AsyncProcessor is
much
more complex than regular Processor. In fact there are some areas
where its not
used correctly and causes unforseen side effects that only
surfaces in
some complex or rare unit tests. This issues is more apparent
lately
as more
and more camel processors supports the async processor directly.
The original code by Hiram only leverages the async callback in the
file component as it was part of his initial code. No other areas
benefits from this.
The code is basically making it bloat and complex inside Camel
itself.
End users do not use this. I do not recall a single question on
it in
the user forum.
So I am in a big +1 to get it out of the codebase.
And before you say well how do we do async routing then? Well the
seda
component is still there to truely spawn a new thread to route an
exchange.
And we have the UnitOfWork where you are supposed to register your
callback. We might make the UnitOfWork a bit easier to register
callbacks for
only commit or failure depending on what you want. If its a single
methods its also easier for dynamic languages to have nice DSL
support
for it.
Well that is just me rambling now..... And the UnitOfWork was James
envision for doing async work after the exchange is ended.
Summary
=======
1) Channel
The first cut of this is already done on my local laptop and it
will
just work as is today. But its bases the foundation for more exotic
and advanced
stuff in Camel 2.x series.
Already in progress.
Any thoughts?
2) AsyncProcessor
To reduce the complexity for maintaining the Camel codebase. Just
as
Gert if he was a bit puzzled how to do his StreamCache that uses
the
Async stuff.
When we get it out of there the codebase is much easier to maintain
and we have a greater chance to attract potential new committers.
I vote +1 for this.
Any thoughts?