[jira] [Resolved] (CAMEL-4761) Easier, more transparent config for crash-proof routes

["Claus Ibsen (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen resolved CAMEL-4761.
--------------------------------
    Resolution: Abandoned

Closing old tickets

> 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: Raúl Kripalani
>            Priority: Major
>         Attachments: test-crashProofProcessing.xml
>
>
> 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 was sent by Atlassian JIRA
(v7.6.14#76016)