camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CAMEL-11665) Define a saga DSL and implementation for long running actions
Date Wed, 10 Jan 2018 17:29:00 GMT


ASF GitHub Bot commented on CAMEL-11665:

nicolaferraro commented on a change in pull request #2173: CAMEL-11665: Saga EIP

 File path: camel-core/src/main/java/org/apache/camel/
 @@ -170,6 +170,9 @@
     String LOOP_INDEX               = "CamelLoopIndex";
     String LOOP_SIZE                = "CamelLoopSize";
+    // Long running action (saga)
+    String SAGA_LONG_RUNNING_ACTION = "Long-Running-Action";
 Review comment:
   It could, but setting it to "Long-Running-Action" simplifies things a lot, since that is
the same header used in the Microprofile implementation, so Camel routes would be able to
interoperate naturally with them. So I prefer to stick with that if not an issue.

This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

> Define a saga DSL and implementation for long running actions
> -------------------------------------------------------------
>                 Key: CAMEL-11665
>                 URL:
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-core
>            Reporter: Nicola Ferraro
>            Assignee: Nicola Ferraro
>            Priority: Minor
> I'm trying to define a saga interface and DSL for Camel in order to support long running
> I've done some experiments here:
> The experiment works with a in memory saga manager.
> It should be possible to switch to a proper "long running action coordinator" (e.g. the
one proposed here
once an implementation is ready.
> We can also think to provide our own implementation based on a shared transaction log,
but it will be a "hard" task and it would not be compatible with other languages/frameworks,
so the "spec" way should be preferable.

This message was sent by Atlassian JIRA

View raw message