Easier, more transparent config for crash-proof routes
------------------------------------------------------
Key: CAMEL-4761
URL: https://issues.apache.org/jira/browse/CAMEL-4761
Project: Camel
Issue Type: New Feature
Components: camel-core
Affects Versions: 2.8.3, 2.9.0
Reporter: Raul Kripalani
Only applicable to InOnly exchanges.
Using the right combination of Camel route + ActiveMQ or other JMS provider for
internal routing, it is straight forward to achieve crash-proof routing. That
is, if the container crashes in the middle of routing, when it comes back up it
can resume processing from where it cut off. For this, we use the JMS broker as
our persistent medium. This allows Camel to be lightweight and to not depend on
a DB (like other middleware offerings do).
However, this entails splitting the route in several routes, chained together
via JMS queues. For example:
{code}
from("cxf:bean:...")
.to("xslt:...")
.to("cxf:bean:...")
.to("activemq:queue:route.block2");
from("activemq:queue:route.block2")
.to("xslt:...")
.to("cxf:bean:...")
.to("activemq:queue:route.block3");
from("activemq:queue:route.block3")
...;
{code}
Even though the goal is achieved, the syntax is quite verbose and creates queue
proliferation in the broker. It complicates the routing logic and is intrusive,
since it forces the developer to "pollute" their code with concerns that could
be handled by the middleware itself.
*Ideas/paths to explore:*
* Provide a quick and easy way for folks to signal "checkpoints" or
"savepoints" and have Camel take care of diverting out to the broker behind the
curtains. Create a new DSL to mark checkpoints and have Camel automatically use
the context id, route id and a checkpoint name to create JMS queues and
transparently weave the to() and from() from the two sections separated by a
checkpoint. For example, the route above turns into:
{code}
from("cxf:bean:...")
.to("xslt:...")
.to("cxf:bean:...")
.checkpoint("block2")
.to("xslt:...")
.to("cxf:bean:...")
.checkpoint("block3)"
...;
{code}
* Create a "reliable:" component wrapper to wrap endpoints and provide
idempotence and store replies. Upon a second execution of the route after a
failed first attempt, the entire route would be replayed from the beginning and
when the reliable endpoints are hit, they would skip invoking the real endpoint
and return the response received in the first iteration (thanks James
Strachan). Would this require a DB?
* Create an attribute on the <route> element (e.g. "recoverable"), which
automatically applies an InterceptionStrategy to divert in and out of the JMS
broker before endpoints.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
