[jira] [Commented] (CAMEL-13086) Java DSL: Rename "endChoice" to "endWhen"
[
https://issues.apache.org/jira/browse/CAMEL-13086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004145#comment-17004145
]
Peter Keller commented on CAMEL-13086:
--
In order not to break existing routes, an alternative {{RouteBuilder}} could be
introduced with the apdapted DSL, see also CAMEL-13085.
> Java DSL: Rename "endChoice" to "endWhen"
> -
>
> Key: CAMEL-13086
> URL: https://issues.apache.org/jira/browse/CAMEL-13086
> Project: Camel
> Issue Type: Wish
> Components: camel-core
>Reporter: Peter Keller
>Priority: Major
> Fix For: 3.0.0
>
>
> Java DSL: Rename {{endChoice}} to {{endWhen}} as {{endChoice}} actually ends
> a {{when}} condition.
> I am aware that this will break current routes. Nevertheless I wanted to
> bring this issue to discussion as {{endChoice}} isn't obvious for beginners
> that learn the framework.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-13085) Java DSL: Add explicit endings such as “endSplit”, “endMulticast”, "endException"
[
https://issues.apache.org/jira/browse/CAMEL-13085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004144#comment-17004144
]
Peter Keller commented on CAMEL-13085:
--
In order not to break existing routes, an alternative {{RouteBuilder}} could be
introduced with the apdapted DSL.
> Java DSL: Add explicit endings such as “endSplit”, “endMulticast”,
> "endException"
> -
>
> Key: CAMEL-13085
> URL: https://issues.apache.org/jira/browse/CAMEL-13085
> Project: Camel
> Issue Type: Wish
> Components: camel-core
>Reporter: Peter Keller
>Priority: Major
> Fix For: Future
>
>
> For non-trivial complex routes it isn't obvious where structurel elements
> such as {{split}}, {{multicast}} or {{exception}} are ending. This is even
> true for non-novice user of the framework.
> Suggestion: Add explicit endings such as {{endSplit}}, {{endMulticast}},
> {{endException}} to the Java DSL. These ending may be optional so that no
> migration is needed from Camel 2 to Camel 3.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-13086) Java DSL: Rename "endChoice" to "endWhen"
[
https://issues.apache.org/jira/browse/CAMEL-13086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776323#comment-16776323
]
Peter Keller commented on CAMEL-13086:
--
When migrating to 3.0.0, you won't do it without migration the old setup
anyway, see https://github.com/apache/camel/blob/master/MIGRATION.md
> Java DSL: Rename "endChoice" to "endWhen"
> -
>
> Key: CAMEL-13086
> URL: https://issues.apache.org/jira/browse/CAMEL-13086
> Project: Camel
> Issue Type: Wish
> Components: camel-core
>Reporter: Peter Keller
>Priority: Major
> Fix For: 3.0.0
>
>
> Java DSL: Rename {{endChoice}} to {{endWhen}} as {{endChoice}} actually ends
> a {{when}} condition.
> I am aware that this will break current routes. Nevertheless I wanted to
> bring this issue to discussion as {{endChoice}} isn't obvious for beginners
> that learn the framework.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-13086) Java DSL: Rename "endChoice" to "endWhen"
[
https://issues.apache.org/jira/browse/CAMEL-13086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749052#comment-16749052
]
Peter Keller edited comment on CAMEL-13086 at 1/22/19 8:05 PM:
---
The actual behaviour is not obvious as in other programming languages a
different behaviour is found, see
[Wikipedia|https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(syntax)]:
* Ada, Visual Basic, Seed7: {{if}} ... {{end If}}
* Bash, sh, ksh: {{if}} ... {{fi}}, {{case}} ... {{esac}}
* ALGOL 68: {{if}} ... {{fi}}, {{do}} ... {{od}}
* COBOL: {{IF}} ... {{ENDIF}}, {{PERFORM}} ... {{END-PERFORM}}
* Visual Basic .Net: {{If}} ... {{End If}}
* Small Basic: {{If}} ... {{Endif}}, {{For}} ... {{EndFor}}, {{While}} ...
{{EndWhile}}
was (Author: peter keller):
The actual behaviour is not obvious as in other programming languages a
different behaviour is found, see
[Wikipedia|https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(syntax)]:
* Ada, Visual Basic, Seed7: {{if}} ... {{end If}}
* Bash, sh, ksh: {{if}} ... {{fi}}, {{case}} ... {{esac}}
* ALGOL 68: {{if}} ... {{fi}}, {{do}} ... {{od}}
* COBOL: {{IF}} ... {{ENDIF-IF}}, {{PERFORM}} ... {{END-PERFORM}}
* Visual Basic .Net: {{If}} ... {{End If}}
* Small Basic: {{If}} ... {{Endif}}, {{For}} ... {{EndFor}}, {{While}} ...
{{EndWhile}}
> Java DSL: Rename "endChoice" to "endWhen"
> -
>
> Key: CAMEL-13086
> URL: https://issues.apache.org/jira/browse/CAMEL-13086
> Project: Camel
> Issue Type: Wish
> Components: camel-core
>Reporter: Peter Keller
>Priority: Major
> Fix For: 3.0.0
>
>
> Java DSL: Rename {{endChoice}} to {{endWhen}} as {{endChoice}} actually ends
> a {{when}} condition.
> I am aware that this will break current routes. Nevertheless I wanted to
> bring this issue to discussion as {{endChoice}} isn't obvious for beginners
> that learn the framework.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13086) Java DSL: Rename "endChoice" to "endWhen"
[
https://issues.apache.org/jira/browse/CAMEL-13086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749052#comment-16749052
]
Peter Keller commented on CAMEL-13086:
--
The actual behaviour is not obvious as in other programming languages a
different behaviour is found, see
[Wikipedia|https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(syntax)]:
* Ada, Visual Basic, Seed7: {{if}} ... {{end If}}
* Bash, sh, ksh: {{if}} ... {{fi}}, {{case}} ... {{esac}}
* ALGOL 68: {{if}} ... \{fi}}, {{do}} ... {{od}}
* COBOL: {{IF}} ... {{ENDIF-IF}}, {{PERFORM}} ... {{END-PERFORM}}
* Visual Basic .Net: {{If}} ... {{End If}}
* Small Basic: {{If}} ... {{Endif}}, {{For}} ... {{EndFor}}, {{While}} ...
{{EndWhile}}
> Java DSL: Rename "endChoice" to "endWhen"
> -
>
> Key: CAMEL-13086
> URL: https://issues.apache.org/jira/browse/CAMEL-13086
> Project: Camel
> Issue Type: Wish
> Components: camel-core
>Reporter: Peter Keller
>Priority: Major
> Fix For: 3.0.0
>
>
> Java DSL: Rename {{endChoice}} to {{endWhen}} as {{endChoice}} actually ends
> a {{when}} condition.
> I am aware that this will break current routes. Nevertheless I wanted to
> bring this issue to discussion as {{endChoice}} isn't obvious for beginners
> that learn the framework.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-13086) Java DSL: Rename "endChoice" to "endWhen"
[
https://issues.apache.org/jira/browse/CAMEL-13086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749052#comment-16749052
]
Peter Keller edited comment on CAMEL-13086 at 1/22/19 7:32 PM:
---
The actual behaviour is not obvious as in other programming languages a
different behaviour is found, see
[Wikipedia|https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(syntax)]:
* Ada, Visual Basic, Seed7: {{if}} ... {{end If}}
* Bash, sh, ksh: {{if}} ... {{fi}}, {{case}} ... {{esac}}
* ALGOL 68: {{if}} ... {{fi}}, {{do}} ... {{od}}
* COBOL: {{IF}} ... {{ENDIF-IF}}, {{PERFORM}} ... {{END-PERFORM}}
* Visual Basic .Net: {{If}} ... {{End If}}
* Small Basic: {{If}} ... {{Endif}}, {{For}} ... {{EndFor}}, {{While}} ...
{{EndWhile}}
was (Author: peter keller):
The actual behaviour is not obvious as in other programming languages a
different behaviour is found, see
[Wikipedia|https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(syntax)]:
* Ada, Visual Basic, Seed7: {{if}} ... {{end If}}
* Bash, sh, ksh: {{if}} ... {{fi}}, {{case}} ... {{esac}}
* ALGOL 68: {{if}} ... \{fi}}, {{do}} ... {{od}}
* COBOL: {{IF}} ... {{ENDIF-IF}}, {{PERFORM}} ... {{END-PERFORM}}
* Visual Basic .Net: {{If}} ... {{End If}}
* Small Basic: {{If}} ... {{Endif}}, {{For}} ... {{EndFor}}, {{While}} ...
{{EndWhile}}
> Java DSL: Rename "endChoice" to "endWhen"
> -
>
> Key: CAMEL-13086
> URL: https://issues.apache.org/jira/browse/CAMEL-13086
> Project: Camel
> Issue Type: Wish
> Components: camel-core
>Reporter: Peter Keller
>Priority: Major
> Fix For: 3.0.0
>
>
> Java DSL: Rename {{endChoice}} to {{endWhen}} as {{endChoice}} actually ends
> a {{when}} condition.
> I am aware that this will break current routes. Nevertheless I wanted to
> bring this issue to discussion as {{endChoice}} isn't obvious for beginners
> that learn the framework.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13086) Java DSL: Rename "endChoice" to "endWhen"
[
https://issues.apache.org/jira/browse/CAMEL-13086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16747489#comment-16747489
]
Peter Keller commented on CAMEL-13086:
--
Yes, you are right. But {{choice}} is ended by {{end}}, and {{when}} by
{{endChoice}}. My suggestion is to end {{choice}} by {{endChoice}} and {{when}}
by {{endWhen}}.
> Java DSL: Rename "endChoice" to "endWhen"
> -
>
> Key: CAMEL-13086
> URL: https://issues.apache.org/jira/browse/CAMEL-13086
> Project: Camel
> Issue Type: Wish
> Components: camel-core
>Reporter: Peter Keller
>Priority: Major
> Fix For: 3.0.0
>
>
> Java DSL: Rename {{endChoice}} to {{endWhen}} as {{endChoice}} actually ends
> a {{when}} condition.
> I am aware that this will break current routes. Nevertheless I wanted to
> bring this issue to discussion as {{endChoice}} isn't obvious for beginners
> that learn the framework.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-11807) Upgrade to JUnit 5
[
https://issues.apache.org/jira/browse/CAMEL-11807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16747485#comment-16747485
]
Peter Keller commented on CAMEL-11807:
--
Wouldn't it be sensible to have two separate issues:
1) Upgrade Camel unit tests to JUnit 5
2) Provide base test classes for consumers of the framework using JUnit 5 (e.g.
{{CamelSpringRunner}} and {{CamelSpringBootRunner}}).
> Upgrade to JUnit 5
> --
>
> Key: CAMEL-11807
> URL: https://issues.apache.org/jira/browse/CAMEL-11807
> Project: Camel
> Issue Type: Improvement
>Reporter: Luca Burgazzoli
>Priority: Minor
> Fix For: 3.0.0, Future
>
>
> See http://junit.org/junit5/
> Note: it provides a junit-vintage module so we should be able to migrate
> stuffs easily (!)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13087) Add more obvious exception handling for "multicast"
Peter Keller created CAMEL-13087:
Summary: Add more obvious exception handling for "multicast"
Key: CAMEL-13087
URL: https://issues.apache.org/jira/browse/CAMEL-13087
Project: Camel
Issue Type: Wish
Reporter: Peter Keller
Fix For: 3.0.0
Add more obvious exception handling for {{multicast}}.
E.g. see
*
https://stackoverflow.com/questions/35896325/camel-multicast-exception-propagation
*
https://stackoverflow.com/questions/51156635/apache-camel-how-to-catch-exception-with-multicast
*
https://stackoverflow.com/questions/40281605/camel-isnt-propagating-exceptions-when-they-are-thrown-inside-of-a-multicast-wh
*
https://stackoverflow.com/questions/7317776/apache-camel-multicast-exception-and-aggregation-strategy
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13086) Java DSL: Rename "endChoice" to "endWhen"
Peter Keller created CAMEL-13086:
Summary: Java DSL: Rename "endChoice" to "endWhen"
Key: CAMEL-13086
URL: https://issues.apache.org/jira/browse/CAMEL-13086
Project: Camel
Issue Type: Wish
Components: camel-core
Reporter: Peter Keller
Fix For: 3.0.0
Java DSL: Rename {{endChoice}} to {{endWhen}} as {{endChoice}} actually ends a
{{when}} condition.
I am aware that this will break current routes. Nevertheless I wanted to bring
this issue to discussion as {{endChoice}} isn't obvious for beginners that
learn the framework.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-13085) Java DSL: Add explicit endings such as “endSplit”, “endMulticast”, "endException"
[
https://issues.apache.org/jira/browse/CAMEL-13085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keller updated CAMEL-13085:
-
Issue Type: Wish (was: Improvement)
> Java DSL: Add explicit endings such as “endSplit”, “endMulticast”,
> "endException"
> -
>
> Key: CAMEL-13085
> URL: https://issues.apache.org/jira/browse/CAMEL-13085
> Project: Camel
> Issue Type: Wish
> Components: camel-core
>Reporter: Peter Keller
>Priority: Major
> Fix For: 3.0.0
>
>
> For non-trivial complex routes it isn't obvious where structurel elements
> such as {{split}}, {{multicast}} or {{exception}} are ending. This is even
> true for non-novice user of the framework.
> Suggestion: Add explicit endings such as {{endSplit}}, {{endMulticast}},
> {{endException}} to the Java DSL. These ending may be optional so that no
> migration is needed from Camel 2 to Camel 3.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13085) Java DSL: Add explicit endings such as “endSplit”, “endMulticast”, "endException"
Peter Keller created CAMEL-13085:
Summary: Java DSL: Add explicit endings such as “endSplit”,
“endMulticast”, "endException"
Key: CAMEL-13085
URL: https://issues.apache.org/jira/browse/CAMEL-13085
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Peter Keller
Fix For: 3.0.0
For non-trivial complex routes it isn't obvious where structurel elements such
as {{split}}, {{multicast}} or {{exception}} are ending. This is even true for
non-novice user of the framework.
Suggestion: Add explicit endings such as {{endSplit}}, {{endMulticast}},
{{endException}} to the Java DSL. These ending may be optional so that no
migration is needed from Camel 2 to Camel 3.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13036) Add the possibility to disable the invocation of ModelHelper.dumpModelAsXml()
Peter Keller created CAMEL-13036:
Summary: Add the possibility to disable the invocation of
ModelHelper.dumpModelAsXml()
Key: CAMEL-13036
URL: https://issues.apache.org/jira/browse/CAMEL-13036
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.23.0
Reporter: Peter Keller
Add the possibility to disable the invocation of
{{ModelHelper.dumpModelAsXml()}}. This is particularly disturbing for Camel
contexts with a lot of route definitions as this uses a lot of processing time
and the information is only used for log output.
Actual use in 2.x in {{RouteDefinition.java}}:
{code:java|title=RouteDefinition.java}
String beforeAsXml = ModelHelper.dumpModelAsXml(camelContext, this);
...
String afterAsXml = ModelHelper.dumpModelAsXml(camelContext, merged);
log.info("Adviced route before/after as XML:\n{}\n{}", beforeAsXml, afterAsXml);
{code}
In 2.X this should be optimized in {{RouteDefinition.java}}, in 3.X in
{{RouteReifier.java}}.
Possible solution: Add {{log.isInfoEnabled{}}} guard.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-11370) Problem with MTOM in Camel-CXF
[ https://issues.apache.org/jira/browse/CAMEL-11370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16358539#comment-16358539 ] Peter Keller commented on CAMEL-11370: -- I tried v2.20.2 with the same effect. I implemented a small sample project which can be found on https://github.com/peterkeller/camel-cxf-memory.git > Problem with MTOM in Camel-CXF > -- > > Key: CAMEL-11370 > URL: https://issues.apache.org/jira/browse/CAMEL-11370 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Reporter: Joerg Kessler >Priority: Minor > Attachments: MTOM-conversion.patch, > accept-also-sub-classes-of-orgapachecxfjaxbJAXBDataB.patch, mtom.test.zip > > > I originally opened the issue on CXF: > https://issues.apache.org/jira/browse/CXF-7388 > but ther CXF guys think the problem is in camel-cxf. Please have a look at > this ticket. Basically the MTOM conversion seems not to work anymore when > using CXF in Camel. I provided a unit test that demonstrates the observed > behaviour. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-11370) Problem with MTOM in Camel-CXF
[ https://issues.apache.org/jira/browse/CAMEL-11370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16346464#comment-16346464 ] Peter Keller commented on CAMEL-11370: -- Requesting a SOAP response of about 50 MB with JAXB/MTOM results in an excessive memory heap usage (> 500 MB) which is not acceptable (Camel v2.19.2). It would be highly appreciated if anyone could fix this. > Problem with MTOM in Camel-CXF > -- > > Key: CAMEL-11370 > URL: https://issues.apache.org/jira/browse/CAMEL-11370 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Reporter: Joerg Kessler >Priority: Minor > Attachments: MTOM-conversion.patch, > accept-also-sub-classes-of-orgapachecxfjaxbJAXBDataB.patch, mtom.test.zip > > > I originally opened the issue on CXF: > https://issues.apache.org/jira/browse/CXF-7388 > but ther CXF guys think the problem is in camel-cxf. Please have a look at > this ticket. Basically the MTOM conversion seems not to work anymore when > using CXF in Camel. I provided a unit test that demonstrates the observed > behaviour. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-10272) Unexpected behaviour in aggregator if recipient list is processed in parallel
[
https://issues.apache.org/jira/browse/CAMEL-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15717708#comment-15717708
]
Peter Keller edited comment on CAMEL-10272 at 12/3/16 6:38 PM:
---
Alex thank you for the patch.
I updated the summary and the description of the issue so that it better suits
to the actual problem. I hope that everybody is fine with this.
The analysis of our problem showed that a
{{java.util.ConcurrentModificationException}} was thrown in the aggregator. A
non thread safe collection was accessed concurrently in every route of the
recipient list as well as in the aggregator. This explains properly the
unpredictable behaviour.
Thinking about the solution I think the correct way is to pass the exception to
the error handler of the main route, even if this brakes the old behaviour.
Perhaps this could be controlled by a new option?
was (Author: peter keller):
Alex thank you for the patch.
I updated the title and the description of the issue so that it better suits to
the actual problem. I hope that everybody is fine with this.
The analysis of our problem showed that a
{{java.util.ConcurrentModificationException}} was thrown in the aggregator. A
non thread safe collection was accessed concurrently in every route of the
recipient list as well as in the aggregator. This explains properly the
unpredictable behaviour.
Thinking about the solution I think the correct way is to pass the exception to
the error handler of the main route, even if this brakes the old behaviour.
Perhaps this could be controlled by a new option?
> Unexpected behaviour in aggregator if recipient list is processed in parallel
> -
>
> Key: CAMEL-10272
> URL: https://issues.apache.org/jira/browse/CAMEL-10272
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.16.3, 2.17.3
> Environment: MacOS 10.11.6, JRE 1.7.0_79
>Reporter: Peter Keller
>
> h3. Problem
> The {{oldExchange}} is {{null}} more than once in the aggregator if a
> recipient list is processed in parallel.
> h3. Camel route
> In my Camel route, a recipient list is worked of in parallel:
> {code}
> from("direct:start")
> .to("direct:pre")
> .recipientList().method(new MyRecipientListBuilder())
> .stopOnException()
> .aggregationStrategy(new MyAggregationStrategy())
> .parallelProcessing()
> .end()
> .bean(new MyPostProcessor());
> {code}
> Snippet of {{MyAggregationStrategy}}:
> {code}
> @Override
> @SuppressWarnings("unchecked")
> public Exchange aggregate(final Exchange oldExchange, final Exchange
> newExchange) {
> if (oldExchange == null) {
> // this is the case more than once which is not expected!
> }
> // ...
> {code}
> {{oldExchange}} is null more than once which is not expected and which
> contradicts the contract with Camel.
> h3. Analysis
> Unfortunately, I am not able to provide a (simple) unit test for
> comprehending the problem. Furthermore our (complex) unit tests are not
> deterministic due to the root cause of the problem.
> During the processing, Camel invokes
> {{ParallelAggregateTask.doAggregateInternal()}}. If aggregation is not done
> in parallel (as it is the case in our route), this is supposed to be done
> synchronously:
> {code}
> protected void doAggregateInternal(AggregationStrategy strategy,
> AtomicExchange result, Exchange exchange) {
> if (strategy != null) {
> // prepare the exchanges for aggregation
> Exchange oldExchange = result.get();
> ExchangeHelper.prepareAggregation(oldExchange, exchange);
> result.set(strategy.aggregate(oldExchange, exchange));
> }
> }
> {code}
> However, is it possible that we face a race condition in
> {{doAggregateInternal}} even if this method is supposed to be invoked
> synchronously?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (CAMEL-10272) Unexpected behaviour in aggregator if recipient list is processed in parallel
[
https://issues.apache.org/jira/browse/CAMEL-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keller updated CAMEL-10272:
-
Comment: was deleted
(was: I updated the analysis: There is only one instance of
{{AggregateOnTheFlyTask}}.)
> Unexpected behaviour in aggregator if recipient list is processed in parallel
> -
>
> Key: CAMEL-10272
> URL: https://issues.apache.org/jira/browse/CAMEL-10272
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.16.3, 2.17.3
> Environment: MacOS 10.11.6, JRE 1.7.0_79
>Reporter: Peter Keller
>
> h3. Problem
> The {{oldExchange}} is {{null}} more than once in the aggregator if a
> recipient list is processed in parallel.
> h3. Camel route
> In my Camel route, a recipient list is worked of in parallel:
> {code}
> from("direct:start")
> .to("direct:pre")
> .recipientList().method(new MyRecipientListBuilder())
> .stopOnException()
> .aggregationStrategy(new MyAggregationStrategy())
> .parallelProcessing()
> .end()
> .bean(new MyPostProcessor());
> {code}
> Snippet of {{MyAggregationStrategy}}:
> {code}
> @Override
> @SuppressWarnings("unchecked")
> public Exchange aggregate(final Exchange oldExchange, final Exchange
> newExchange) {
> if (oldExchange == null) {
> // this is the case more than once which is not expected!
> }
> // ...
> {code}
> {{oldExchange}} is null more than once which is not expected and which
> contradicts the contract with Camel.
> h3. Analysis
> Unfortunately, I am not able to provide a (simple) unit test for
> comprehending the problem. Furthermore our (complex) unit tests are not
> deterministic due to the root cause of the problem.
> During the processing, Camel invokes
> {{ParallelAggregateTask.doAggregateInternal()}}. If aggregation is not done
> in parallel (as it is the case in our route), this is supposed to be done
> synchronously:
> {code}
> protected void doAggregateInternal(AggregationStrategy strategy,
> AtomicExchange result, Exchange exchange) {
> if (strategy != null) {
> // prepare the exchanges for aggregation
> Exchange oldExchange = result.get();
> ExchangeHelper.prepareAggregation(oldExchange, exchange);
> result.set(strategy.aggregate(oldExchange, exchange));
> }
> }
> {code}
> However, is it possible that we face a race condition in
> {{doAggregateInternal}} even if this method is supposed to be invoked
> synchronously?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-10272) Unexpected behaviour in aggregator if recipient list is processed in parallel
[
https://issues.apache.org/jira/browse/CAMEL-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15717708#comment-15717708
]
Peter Keller commented on CAMEL-10272:
--
Alex thank you for the patch.
I updated the title and the description of the issue so that it better suits to
the actual problem. I hope that everybody is fine with this.
The analysis of our problem showed that a
{{java.util.ConcurrentModificationException}} was thrown in the aggregator. A
non thread safe collection was accessed concurrently in every route of the
recipient list as well as in the aggregator. This explains properly the
unpredictable behaviour.
Thinking about the solution I think the correct way is to pass the exception to
the error handler of the main route, even if this brakes the old behaviour.
Perhaps this could be controlled by a new option?
> Unexpected behaviour in aggregator if recipient list is processed in parallel
> -
>
> Key: CAMEL-10272
> URL: https://issues.apache.org/jira/browse/CAMEL-10272
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.16.3, 2.17.3
> Environment: MacOS 10.11.6, JRE 1.7.0_79
>Reporter: Peter Keller
>
> h3. Problem
> The {{oldExchange}} is {{null}} more than once in the aggregator if a
> recipient list is processed in parallel.
> h3. Camel route
> In my Camel route, a recipient list is worked of in parallel:
> {code}
> from("direct:start")
> .to("direct:pre")
> .recipientList().method(new MyRecipientListBuilder())
> .stopOnException()
> .aggregationStrategy(new MyAggregationStrategy())
> .parallelProcessing()
> .end()
> .bean(new MyPostProcessor());
> {code}
> Snippet of {{MyAggregationStrategy}}:
> {code}
> @Override
> @SuppressWarnings("unchecked")
> public Exchange aggregate(final Exchange oldExchange, final Exchange
> newExchange) {
> if (oldExchange == null) {
> // this is the case more than once which is not expected!
> }
> // ...
> {code}
> {{oldExchange}} is null more than once which is not expected and which
> contradicts the contract with Camel.
> h3. Analysis
> Unfortunately, I am not able to provide a (simple) unit test for
> comprehending the problem. Furthermore our (complex) unit tests are not
> deterministic due to the root cause of the problem.
> During the processing, Camel invokes
> {{ParallelAggregateTask.doAggregateInternal()}}. If aggregation is not done
> in parallel (as it is the case in our route), this is supposed to be done
> synchronously:
> {code}
> protected void doAggregateInternal(AggregationStrategy strategy,
> AtomicExchange result, Exchange exchange) {
> if (strategy != null) {
> // prepare the exchanges for aggregation
> Exchange oldExchange = result.get();
> ExchangeHelper.prepareAggregation(oldExchange, exchange);
> result.set(strategy.aggregate(oldExchange, exchange));
> }
> }
> {code}
> However, is it possible that we face a race condition in
> {{doAggregateInternal}} even if this method is supposed to be invoked
> synchronously?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-10272) Unexpected behaviour in aggregator if recipient list is processed in parallel
[
https://issues.apache.org/jira/browse/CAMEL-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keller updated CAMEL-10272:
-
Description:
h3. Problem
The {{oldExchange}} is {{null}} more than once in the aggregator if a recipient
list is processed in parallel.
h3. Camel route
In my Camel route, a recipient list is worked of in parallel:
{code}
from("direct:start")
.to("direct:pre")
.recipientList().method(new MyRecipientListBuilder())
.stopOnException()
.aggregationStrategy(new MyAggregationStrategy())
.parallelProcessing()
.end()
.bean(new MyPostProcessor());
{code}
Snippet of {{MyAggregationStrategy}}:
{code}
@Override
@SuppressWarnings("unchecked")
public Exchange aggregate(final Exchange oldExchange, final Exchange
newExchange) {
if (oldExchange == null) {
// this is the case more than once which is not expected!
}
// ...
{code}
{{oldExchange}} is null more than once which is not expected and which
contradicts the contract with Camel.
h3. Analysis
Unfortunately, I am not able to provide a (simple) unit test for comprehending
the problem. Furthermore our (complex) unit tests are not deterministic due to
the root cause of the problem.
During the processing, Camel invokes
{{ParallelAggregateTask.doAggregateInternal()}}. If aggregation is not done in
parallel (as it is the case in our route), this is supposed to be done
synchronously:
{code}
protected void doAggregateInternal(AggregationStrategy strategy, AtomicExchange
result, Exchange exchange) {
if (strategy != null) {
// prepare the exchanges for aggregation
Exchange oldExchange = result.get();
ExchangeHelper.prepareAggregation(oldExchange, exchange);
result.set(strategy.aggregate(oldExchange, exchange));
}
}
{code}
However, is it possible that we face a race condition in
{{doAggregateInternal}} even if this method is supposed to be invoked
synchronously?
was:
Unfortunately, I am not able to provide a (simple) unit test for comprehending
the problem. Furthermore our (complex) unit tests are not deterministic due to
the root cause of the problem.
However I tried to analyze the Camel Java code, to work out the problem. Please
find below my findings.
h3. Problem
The {{oldExchange}} is {{null}} more than once in the aggregator if a recipient
list is processed in parallel.
h3. Camel route
In my Camel route, a recipient list is worked of in parallel:
{code}
from("direct:start")
.to("direct:pre")
.recipientList().method(new MyRecipientListBuilder())
.stopOnException()
.aggregationStrategy(new MyAggregationStrategy())
.parallelProcessing()
.end()
.bean(new MyPostProcessor());
{code}
Snippet of {{MyAggregationStrategy}}:
{code}
@Override
@SuppressWarnings("unchecked")
public Exchange aggregate(final Exchange oldExchange, final Exchange
newExchange) {
if (oldExchange == null) {
// this is the case more than once which is not expected!
}
// ...
{code}
{{oldExchange}} is null more than once which is not expected and which
contradicts the contract with Camel.
h3. Analysis
During the processing, Camel invokes {{MulticastProcessor.process()}}. Here the
result object {{AtomicExchange}} is created which is shared during the whole
processing.
If the processing should be done in parallel (as it is the case for our route)
then {{MulticastProcessor.doProcessParallel()}} is invoked. Here one instance
of {{AggregateOnTheFlyTask}} is initialized and {{aggregateOnTheFly()}} is
invoked -*asynchronously* via {{run()}} for *every* target in the recipient
list-. via {{aggregateExecutorService.submit}} ({{aggregationTaskSubmitted}}
guarantees that this is only be done once)
In {{aggregateOnTheFly()}}, a new instance of {{ParallelAggregateTask}} is
generated, and if aggregation is not done in parallel (as it is the case in our
route), {{ParallelAggregateTask.run()}},
{{ParallelAggregateTask.doAggregate()}} (this method is synchronized), and
{{ParallelAggregateTask.doAggregateInternal()}} is invoked synchronously:
{code}
protected void doAggregateInternal(AggregationStrategy strategy, AtomicExchange
result, Exchange exchange) {
if (strategy != null) {
// prepare the exchanges for aggregation
Exchange oldExchange = result.get();
ExchangeHelper.prepareAggregation(oldExchange, exchange);
result.set(strategy.aggregate(oldExchange, exchange));
}
}
{code}
However, in {{ParallelAggregateTask.doAggregateInternal()}} there may occur a
race condition as {{result}} is shared -by every instance of
{{AggregateOnTheFlyTask}}- such that {{oldExchange = result.get()}} may be
{{null}} more than once!
Note: As a new instance of {{ParallelAggregateTask}} for every target in
recipient list is created, the {{synchronized}} method
[jira] [Updated] (CAMEL-10272) Unexpected behaviour in aggregator if recipient list is processed in parallel
[
https://issues.apache.org/jira/browse/CAMEL-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keller updated CAMEL-10272:
-
Summary: Unexpected behaviour in aggregator if recipient list is processed
in parallel (was: Aggregation is broken due to race condition in
ParallelAggregateTask.doAggregateInternal())
> Unexpected behaviour in aggregator if recipient list is processed in parallel
> -
>
> Key: CAMEL-10272
> URL: https://issues.apache.org/jira/browse/CAMEL-10272
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.16.3, 2.17.3
> Environment: MacOS 10.11.6, JRE 1.7.0_79
>Reporter: Peter Keller
>
> Unfortunately, I am not able to provide a (simple) unit test for
> comprehending the problem. Furthermore our (complex) unit tests are not
> deterministic due to the root cause of the problem.
> However I tried to analyze the Camel Java code, to work out the problem.
> Please find below my findings.
> h3. Problem
> The {{oldExchange}} is {{null}} more than once in the aggregator if a
> recipient list is processed in parallel.
> h3. Camel route
> In my Camel route, a recipient list is worked of in parallel:
> {code}
> from("direct:start")
> .to("direct:pre")
> .recipientList().method(new MyRecipientListBuilder())
> .stopOnException()
> .aggregationStrategy(new MyAggregationStrategy())
> .parallelProcessing()
> .end()
> .bean(new MyPostProcessor());
> {code}
> Snippet of {{MyAggregationStrategy}}:
> {code}
> @Override
> @SuppressWarnings("unchecked")
> public Exchange aggregate(final Exchange oldExchange, final Exchange
> newExchange) {
> if (oldExchange == null) {
> // this is the case more than once which is not expected!
> }
> // ...
> {code}
> {{oldExchange}} is null more than once which is not expected and which
> contradicts the contract with Camel.
> h3. Analysis
> During the processing, Camel invokes {{MulticastProcessor.process()}}. Here
> the result object {{AtomicExchange}} is created which is shared during the
> whole processing.
> If the processing should be done in parallel (as it is the case for our
> route) then {{MulticastProcessor.doProcessParallel()}} is invoked. Here one
> instance of {{AggregateOnTheFlyTask}} is initialized and
> {{aggregateOnTheFly()}} is invoked -*asynchronously* via {{run()}} for
> *every* target in the recipient list-. via
> {{aggregateExecutorService.submit}} ({{aggregationTaskSubmitted}} guarantees
> that this is only be done once)
> In {{aggregateOnTheFly()}}, a new instance of {{ParallelAggregateTask}} is
> generated, and if aggregation is not done in parallel (as it is the case in
> our route), {{ParallelAggregateTask.run()}},
> {{ParallelAggregateTask.doAggregate()}} (this method is synchronized), and
> {{ParallelAggregateTask.doAggregateInternal()}} is invoked synchronously:
> {code}
> protected void doAggregateInternal(AggregationStrategy strategy,
> AtomicExchange result, Exchange exchange) {
> if (strategy != null) {
> // prepare the exchanges for aggregation
> Exchange oldExchange = result.get();
> ExchangeHelper.prepareAggregation(oldExchange, exchange);
> result.set(strategy.aggregate(oldExchange, exchange));
> }
> }
> {code}
> However, in {{ParallelAggregateTask.doAggregateInternal()}} there may occur a
> race condition as {{result}} is shared -by every instance of
> {{AggregateOnTheFlyTask}}- such that {{oldExchange = result.get()}} may be
> {{null}} more than once!
> Note: As a new instance of {{ParallelAggregateTask}} for every target in
> recipient list is created, the {{synchronized}} method
> {{ParallelAggregateTask.doAggregate()}} does not prevent the race condition!
> Does this sounds reasonably?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-10272) Aggregation is broken due to race condition in ParallelAggregateTask.doAggregateInternal()
[
https://issues.apache.org/jira/browse/CAMEL-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15709764#comment-15709764
]
Peter Keller commented on CAMEL-10272:
--
Alex, thank you very much for the analysis.
You are right: if an exception is thrown then {{oldExchange}} may be {{null}}.
As this may be the case in our route, it is mysterious why the exception is
thrown in a non-deterministic way (of course the root cause may be another
multi-threading issue not directly correlated to Camel).
Note, if {{parallelAggregate()}} is used (as mentioned above we don't use this
setup), then {{oldExchange}} may also be null. This can be shown using a
debugger with setting a breakpoint in {{doAggregateInternal}} on the line with
{{ExchangeHelper.prepareAggregation}}. Shouldn't Camel prevent {{oldExchange}}
to be {{null}} in this case?
The logging of the (possible) exception caused by the aggregation strategy
could help to trace down the cause. Of course this could be done in the
implementation of the aggregation strategy itself with a try/catch clause
without changing the Camel framework.
Unwinding the exception to the default error handler may break existing routes
which is not desirable. That said, I personally would prefer this possibility.
> Aggregation is broken due to race condition in
> ParallelAggregateTask.doAggregateInternal()
> --
>
> Key: CAMEL-10272
> URL: https://issues.apache.org/jira/browse/CAMEL-10272
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.16.3, 2.17.3
> Environment: MacOS 10.11.6, JRE 1.7.0_79
>Reporter: Peter Keller
>
> Unfortunately, I am not able to provide a (simple) unit test for
> comprehending the problem. Furthermore our (complex) unit tests are not
> deterministic due to the root cause of the problem.
> However I tried to analyze the Camel Java code, to work out the problem.
> Please find below my findings.
> h3. Problem
> The {{oldExchange}} is {{null}} more than once in the aggregator if a
> recipient list is processed in parallel.
> h3. Camel route
> In my Camel route, a recipient list is worked of in parallel:
> {code}
> from("direct:start")
> .to("direct:pre")
> .recipientList().method(new MyRecipientListBuilder())
> .stopOnException()
> .aggregationStrategy(new MyAggregationStrategy())
> .parallelProcessing()
> .end()
> .bean(new MyPostProcessor());
> {code}
> Snippet of {{MyAggregationStrategy}}:
> {code}
> @Override
> @SuppressWarnings("unchecked")
> public Exchange aggregate(final Exchange oldExchange, final Exchange
> newExchange) {
> if (oldExchange == null) {
> // this is the case more than once which is not expected!
> }
> // ...
> {code}
> {{oldExchange}} is null more than once which is not expected and which
> contradicts the contract with Camel.
> h3. Analysis
> During the processing, Camel invokes {{MulticastProcessor.process()}}. Here
> the result object {{AtomicExchange}} is created which is shared during the
> whole processing.
> If the processing should be done in parallel (as it is the case for our
> route) then {{MulticastProcessor.doProcessParallel()}} is invoked. Here one
> instance of {{AggregateOnTheFlyTask}} is initialized and
> {{aggregateOnTheFly()}} is invoked -*asynchronously* via {{run()}} for
> *every* target in the recipient list-. via
> {{aggregateExecutorService.submit}} ({{aggregationTaskSubmitted}} guarantees
> that this is only be done once)
> In {{aggregateOnTheFly()}}, a new instance of {{ParallelAggregateTask}} is
> generated, and if aggregation is not done in parallel (as it is the case in
> our route), {{ParallelAggregateTask.run()}},
> {{ParallelAggregateTask.doAggregate()}} (this method is synchronized), and
> {{ParallelAggregateTask.doAggregateInternal()}} is invoked synchronously:
> {code}
> protected void doAggregateInternal(AggregationStrategy strategy,
> AtomicExchange result, Exchange exchange) {
> if (strategy != null) {
> // prepare the exchanges for aggregation
> Exchange oldExchange = result.get();
> ExchangeHelper.prepareAggregation(oldExchange, exchange);
> result.set(strategy.aggregate(oldExchange, exchange));
> }
> }
> {code}
> However, in {{ParallelAggregateTask.doAggregateInternal()}} there may occur a
> race condition as {{result}} is shared -by every instance of
> {{AggregateOnTheFlyTask}}- such that {{oldExchange = result.get()}} may be
> {{null}} more than once!
> Note: As a new instance of {{ParallelAggregateTask}} for every target in
> recipient list is created, the {{synchronized}} method
> {{ParallelAggregateTask.doAggregate()}} does not prevent the race condition!
> Does this sounds
[jira] [Commented] (CAMEL-10272) Aggregation is broken due to race condition in ParallelAggregateTask.doAggregateInternal()
[
https://issues.apache.org/jira/browse/CAMEL-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15455190#comment-15455190
]
Peter Keller commented on CAMEL-10272:
--
I updated the analysis: There is only one instance of {{AggregateOnTheFlyTask}}.
> Aggregation is broken due to race condition in
> ParallelAggregateTask.doAggregateInternal()
> --
>
> Key: CAMEL-10272
> URL: https://issues.apache.org/jira/browse/CAMEL-10272
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.16.3, 2.17.3
> Environment: MacOS 10.11.6, JRE 1.7.0_79
>Reporter: Peter Keller
>Priority: Critical
>
> Unfortunately, I am not able to provide a (simple) unit test for
> comprehending the problem. Furthermore our (complex) unit tests are not
> deterministic due to the root cause of the problem.
> However I tried to analyze the Camel Java code, to work out the problem.
> Please find below my findings.
> h3. Problem
> The {{oldExchange}} is {{null}} more than once in the aggregator if a
> recipient list is processed in parallel.
> h3. Camel route
> In my Camel route, a recipient list is worked of in parallel:
> {code}
> from("direct:start")
> .to("direct:pre")
> .recipientList().method(new MyRecipientListBuilder())
> .stopOnException()
> .aggregationStrategy(new MyAggregationStrategy())
> .parallelProcessing()
> .end()
> .bean(new MyPostProcessor());
> {code}
> Snippet of {{MyAggregationStrategy}}:
> {code}
> @Override
> @SuppressWarnings("unchecked")
> public Exchange aggregate(final Exchange oldExchange, final Exchange
> newExchange) {
> if (oldExchange == null) {
> // this is the case more than once which is not expected!
> }
> // ...
> {code}
> {{oldExchange}} is null more than once which is not expected and which
> contradicts the contract with Camel.
> h3. Analysis
> During the processing, Camel invokes {{MulticastProcessor.process()}}. Here
> the result object {{AtomicExchange}} is created which is shared during the
> whole processing.
> If the processing should be done in parallel (as it is the case for our
> route) then {{MulticastProcessor.doProcessParallel()}} is invoked. Here one
> instance of {{AggregateOnTheFlyTask}} is initialized and
> {{aggregateOnTheFly()}} is invoked -*asynchronously* via {{run()}} for
> *every* target in the recipient list-. via
> {{aggregateExecutorService.submit}} ({{aggregationTaskSubmitted}} guarantees
> that this is only be done once)
> In {{aggregateOnTheFly()}}, a new instance of {{ParallelAggregateTask}} is
> generated, and if aggregation is not done in parallel (as it is the case in
> our route), {{ParallelAggregateTask.run()}},
> {{ParallelAggregateTask.doAggregate()}} (this method is synchronized), and
> {{ParallelAggregateTask.doAggregateInternal()}} is invoked synchronously:
> {code}
> protected void doAggregateInternal(AggregationStrategy strategy,
> AtomicExchange result, Exchange exchange) {
> if (strategy != null) {
> // prepare the exchanges for aggregation
> Exchange oldExchange = result.get();
> ExchangeHelper.prepareAggregation(oldExchange, exchange);
> result.set(strategy.aggregate(oldExchange, exchange));
> }
> }
> {code}
> However, in {{ParallelAggregateTask.doAggregateInternal()}} there may occur a
> race condition as {{result}} is shared -by every instance of
> {{AggregateOnTheFlyTask}}- such that {{oldExchange = result.get()}} may be
> {{null}} more than once!
> Note: As a new instance of {{ParallelAggregateTask}} for every target in
> recipient list is created, the {{synchronized}} method
> {{ParallelAggregateTask.doAggregate()}} does not prevent the race condition!
> Does this sounds reasonably?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-10272) Aggregation is broken due to race condition in ParallelAggregateTask.doAggregateInternal()
[
https://issues.apache.org/jira/browse/CAMEL-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keller updated CAMEL-10272:
-
Description:
Unfortunately, I am not able to provide a (simple) unit test for comprehending
the problem. Furthermore our (complex) unit tests are not deterministic due to
the root cause of the problem.
However I tried to analyze the Camel Java code, to work out the problem. Please
find below my findings.
h3. Problem
The {{oldExchange}} is {{null}} more than once in the aggregator if a recipient
list is processed in parallel.
h3. Camel route
In my Camel route, a recipient list is worked of in parallel:
{code}
from("direct:start")
.to("direct:pre")
.recipientList().method(new MyRecipientListBuilder())
.stopOnException()
.aggregationStrategy(new MyAggregationStrategy())
.parallelProcessing()
.end()
.bean(new MyPostProcessor());
{code}
Snippet of {{MyAggregationStrategy}}:
{code}
@Override
@SuppressWarnings("unchecked")
public Exchange aggregate(final Exchange oldExchange, final Exchange
newExchange) {
if (oldExchange == null) {
// this is the case more than once which is not expected!
}
// ...
{code}
{{oldExchange}} is null more than once which is not expected and which
contradicts the contract with Camel.
h3. Analysis
During the processing, Camel invokes {{MulticastProcessor.process()}}. Here the
result object {{AtomicExchange}} is created which is shared during the whole
processing.
If the processing should be done in parallel (as it is the case for our route)
then {{MulticastProcessor.doProcessParallel()}} is invoked. Here one instance
of {{AggregateOnTheFlyTask}} is initialized and {{aggregateOnTheFly()}} is
invoked -*asynchronously* via {{run()}} for *every* target in the recipient
list-. via {{aggregateExecutorService.submit}} ({{aggregationTaskSubmitted}}
guarantees that this is only be done once)
In {{aggregateOnTheFly()}}, a new instance of {{ParallelAggregateTask}} is
generated, and if aggregation is not done in parallel (as it is the case in our
route), {{ParallelAggregateTask.run()}},
{{ParallelAggregateTask.doAggregate()}} (this method is synchronized), and
{{ParallelAggregateTask.doAggregateInternal()}} is invoked synchronously:
{code}
protected void doAggregateInternal(AggregationStrategy strategy, AtomicExchange
result, Exchange exchange) {
if (strategy != null) {
// prepare the exchanges for aggregation
Exchange oldExchange = result.get();
ExchangeHelper.prepareAggregation(oldExchange, exchange);
result.set(strategy.aggregate(oldExchange, exchange));
}
}
{code}
However, in {{ParallelAggregateTask.doAggregateInternal()}} there may occur a
race condition as {{result}} is shared -by every instance of
{{AggregateOnTheFlyTask}}- such that {{oldExchange = result.get()}} may be
{{null}} more than once!
Note: As a new instance of {{ParallelAggregateTask}} for every target in
recipient list is created, the {{synchronized}} method
{{ParallelAggregateTask.doAggregate()}} does not prevent the race condition!
Does this sounds reasonably?
was:
Unfortunately, I am not able to provide a (simple) unit test for comprehending
the problem. Furthermore our (complex) unit tests are not determinist due to
the root cause of the problem.
However I tried to analyze the Camel Java code, to work out the problem. Please
find below my findings.
h3. Problem
The {{oldExchange}} is {{null}} more than once in the aggregator if a recipient
list is processed in parallel.
h3. Camel route
In my Camel route, a recipient list is worked of in parallel:
{code}
from("direct:start")
.to("direct:pre")
.recipientList().method(new MyRecipientListBuilder())
.stopOnException()
.aggregationStrategy(new MyAggregationStrategy())
.parallelProcessing()
.end()
.bean(new MyPostProcessor());
{code}
Snippet of {{MyAggregationStrategy}}:
{code}
@Override
@SuppressWarnings("unchecked")
public Exchange aggregate(final Exchange oldExchange, final Exchange
newExchange) {
if (oldExchange == null) {
// this is the case more than once which is not expected!
}
// ...
{code}
{{oldExchange}} is null more than once which is not expected and which
contradicts the contract with Camel.
h3. Analysis
During the processing, Camel invokes {{MulticastProcessor.process()}}. Here the
result object {{AtomicExchange}} is created which is shared during the whole
processing.
If the processing should be done in parallel (as it is the case for our route)
then {{MulticastProcessor.doProcessParallel()}} is invoked. Here one instance
of {{AggregateOnTheFlyTask}} is initialized and {{aggregateOnTheFly()}} is
invoked *asynchronously* via {{run()}} for *every* target in the recipient
list.
In {{aggregateOnTheFly()}}, a new instance of
[jira] [Updated] (CAMEL-10272) Aggregation is broken due to race condition in ParallelAggregateTask.doAggregateInternal()
[
https://issues.apache.org/jira/browse/CAMEL-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keller updated CAMEL-10272:
-
Environment: MacOS 10.11.6, JRE 1.7.0_79
> Aggregation is broken due to race condition in
> ParallelAggregateTask.doAggregateInternal()
> --
>
> Key: CAMEL-10272
> URL: https://issues.apache.org/jira/browse/CAMEL-10272
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.16.3, 2.17.3
> Environment: MacOS 10.11.6, JRE 1.7.0_79
>Reporter: Peter Keller
>Priority: Critical
>
> Unfortunately, I am not able to provide a (simple) unit test for
> comprehending the problem. Furthermore our (complex) unit tests are not
> determinist due to the root cause of the problem.
> However I tried to analyze the Camel Java code, to work out the problem.
> Please find below my findings.
> h3. Problem
> The {{oldExchange}} is {{null}} more than once in the aggregator if a
> recipient list is processed in parallel.
> h3. Camel route
> In my Camel route, a recipient list is worked of in parallel:
> {code}
> from("direct:start")
> .to("direct:pre")
> .recipientList().method(new MyRecipientListBuilder())
> .stopOnException()
> .aggregationStrategy(new MyAggregationStrategy())
> .parallelProcessing()
> .end()
> .bean(new MyPostProcessor());
> {code}
> Snippet of {{MyAggregationStrategy}}:
> {code}
> @Override
> @SuppressWarnings("unchecked")
> public Exchange aggregate(final Exchange oldExchange, final Exchange
> newExchange) {
> if (oldExchange == null) {
> // this is the case more than once which is not expected!
> }
> // ...
> {code}
> {{oldExchange}} is null more than once which is not expected and which
> contradicts the contract with Camel.
> h3. Analysis
> During the processing, Camel invokes {{MulticastProcessor.process()}}. Here
> the result object {{AtomicExchange}} is created which is shared during the
> whole processing.
> If the processing should be done in parallel (as it is the case for our
> route) then {{MulticastProcessor.doProcessParallel()}} is invoked. Here one
> instance of {{AggregateOnTheFlyTask}} is initialized and
> {{aggregateOnTheFly()}} is invoked *asynchronously* via {{run()}} for
> *every* target in the recipient list.
> In {{aggregateOnTheFly()}}, a new instance of {{ParallelAggregateTask}} is
> generated, and if aggregation is not done in parallel (as it is the case in
> our route), {{ParallelAggregateTask.run()}},
> {{ParallelAggregateTask.doAggregate()}} (this method is synchronized), and
> {{ParallelAggregateTask.doAggregateInternal()}} is invoked:
> {code}
> protected void doAggregateInternal(AggregationStrategy strategy,
> AtomicExchange result, Exchange exchange) {
> if (strategy != null) {
> // prepare the exchanges for aggregation
> Exchange oldExchange = result.get();
> ExchangeHelper.prepareAggregation(oldExchange, exchange);
> result.set(strategy.aggregate(oldExchange, exchange));
> }
> }
> {code}
> However, in {{ParallelAggregateTask.doAggregateInternal()}} there may occur a
> race condition as {{result}} is shared by every instance of
> {{AggregateOnTheFlyTask}} such that {{oldExchange = result.get()}}
> may be {{null}} more than once!
> Note: As a new instance of {{ParallelAggregateTask}} for every target in
> recipient list is created, the {{synchronized}} method
> {{ParallelAggregateTask.doAggregate()}} does not prevent the race condition!
> Does this sounds reasonably?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-10272) Aggregation is broken due to race condition in ParallelAggregateTask.doAggregateInternal()
Peter Keller created CAMEL-10272:
Summary: Aggregation is broken due to race condition in
ParallelAggregateTask.doAggregateInternal()
Key: CAMEL-10272
URL: https://issues.apache.org/jira/browse/CAMEL-10272
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.17.3, 2.16.3
Reporter: Peter Keller
Priority: Critical
Unfortunately, I am not able to provide a (simple) unit test for comprehending
the problem. Furthermore our (complex) unit tests are not determinist due to
the root cause of the problem.
However I tried to analyze the Camel Java code, to work out the problem. Please
find below my findings.
h3. Problem
The {{oldExchange}} is {{null}} more than once in the aggregator if a recipient
list is processed in parallel.
h3. Camel route
In my Camel route, a recipient list is worked of in parallel:
{code}
from("direct:start")
.to("direct:pre")
.recipientList().method(new MyRecipientListBuilder())
.stopOnException()
.aggregationStrategy(new MyAggregationStrategy())
.parallelProcessing()
.end()
.bean(new MyPostProcessor());
{code}
Snippet of {{MyAggregationStrategy}}:
{code}
@Override
@SuppressWarnings("unchecked")
public Exchange aggregate(final Exchange oldExchange, final Exchange
newExchange) {
if (oldExchange == null) {
// this is the case more than once which is not expected!
}
// ...
{code}
{{oldExchange}} is null more than once which is not expected and which
contradicts the contract with Camel.
h3. Analysis
During the processing, Camel invokes {{MulticastProcessor.process()}}. Here the
result object {{AtomicExchange}} is created which is shared during the whole
processing.
If the processing should be done in parallel (as it is the case for our route)
then {{MulticastProcessor.doProcessParallel()}} is invoked. Here one instance
of {{AggregateOnTheFlyTask}} is initialized and {{aggregateOnTheFly()}} is
invoked *asynchronously* via {{run()}} for *every* target in the recipient
list.
In {{aggregateOnTheFly()}}, a new instance of {{ParallelAggregateTask}} is
generated, and if aggregation is not done in parallel (as it is the case in our
route), {{ParallelAggregateTask.run()}},
{{ParallelAggregateTask.doAggregate()}} (this method is synchronized), and
{{ParallelAggregateTask.doAggregateInternal()}} is invoked:
{code}
protected void doAggregateInternal(AggregationStrategy strategy, AtomicExchange
result, Exchange exchange) {
if (strategy != null) {
// prepare the exchanges for aggregation
Exchange oldExchange = result.get();
ExchangeHelper.prepareAggregation(oldExchange, exchange);
result.set(strategy.aggregate(oldExchange, exchange));
}
}
{code}
However, in {{ParallelAggregateTask.doAggregateInternal()}} there may occur a
race condition as {{result}} is shared by every instance of
{{AggregateOnTheFlyTask}} such that {{oldExchange = result.get()}}
may be {{null}} more than once!
Note: As a new instance of {{ParallelAggregateTask}} for every target in
recipient list is created, the {{synchronized}} method
{{ParallelAggregateTask.doAggregate()}} does not prevent the race condition!
Does this sounds reasonably?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9671) camel-docker fails to consume events (Docker API version 1.22)
[
https://issues.apache.org/jira/browse/CAMEL-9671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15182285#comment-15182285
]
Peter Keller commented on CAMEL-9671:
-
camel-docker depends on docker-java v1.4.0.
docker-java support matrix according to
https://github.com/docker-java/docker-java:
- docker-java v2.2.3 -> Docker Remote API v1.19
- docker-java v3.0.0-RC3 -> Docker Remote API v1.22
> camel-docker fails to consume events (Docker API version 1.22)
> --
>
> Key: CAMEL-9671
> URL: https://issues.apache.org/jira/browse/CAMEL-9671
> Project: Camel
> Issue Type: Improvement
> Components: camel-docker
>Affects Versions: 2.16.2
> Environment: MacOS: 10.11.3
> Docker Machine: 0.6.0
> Docker: Version 1.10.2, API version 1.22
>Reporter: Peter Keller
>Priority: Minor
>
> Camel complains that different fields are "not marked as ignorable" and fails
> properly handling the event. Fields:
> - Type
> - Action
> - ID
> - Attributes
> - image
> - name
> Camel route:
> {code}
> from("docker://events?host=192.168.99.100=2376=true=/path/to/.docker/machine/machines/default")
> .process(new Processor() {
> @Override
> public void process(Exchange exchange) throws Exception {
> LOG.info("body = {}", exchange.getIn().getBody());
> }
> });
> {code}
> Error messages:
> {code}
> [ pool-1-thread-1] DockerEventsConsumer ERROR Error
> Consuming from Docker Events: Unrecognized field "Type" (class
> com.github.dockerjava.api.model.Event), not marked as ignorable (4 known
> properties: "status", "id", "time", "from"])
> at [Source:
> com.github.dockerjava.jaxrs.util.WrappedResponseInputStream@7d534017; line:
> 1, column: 134] (through reference chain:
> com.github.dockerjava.api.model.Event["Type"])
> [ pool-1-thread-1] DockerEventsConsumer ERROR Error
> Consuming from Docker Events: Unrecognized field "Action" (class
> com.github.dockerjava.api.model.Event), not marked as ignorable (4 known
> properties: "status", "id", "time", "from"])
> at [Source:
> com.github.dockerjava.jaxrs.util.WrappedResponseInputStream@7d534017; line:
> 1, column: 155] (through reference chain:
> com.github.dockerjava.api.model.Event["Action"])
> [ pool-1-thread-1] DockerEventsConsumer ERROR Error
> Consuming from Docker Events: Unrecognized field "Actor" (class
> com.github.dockerjava.api.model.Event), not marked as ignorable (4 known
> properties: "status", "id", "time", "from"])
> at [Source:
> com.github.dockerjava.jaxrs.util.WrappedResponseInputStream@7d534017; line:
> 1, column: 173] (through reference chain:
> com.github.dockerjava.api.model.Event["Actor"])
> [ pool-1-thread-1] DockerEventsConsumer ERROR Error
> Consuming from Docker Events: Unrecognized field "ID" (class
> com.github.dockerjava.api.model.Event), not marked as ignorable (4 known
> properties: "status", "id", "time", "from"])
> at [Source:
> com.github.dockerjava.jaxrs.util.WrappedResponseInputStream@7d534017; line:
> 1, column: 179] (through reference chain:
> com.github.dockerjava.api.model.Event["ID"])
> [ pool-1-thread-1] DockerEventsConsumer ERROR Error
> Consuming from Docker Events: Unrecognized field "Attributes" (class
> com.github.dockerjava.api.model.Event), not marked as ignorable (4 known
> properties: "status", "id", "time", "from"])
> at [Source:
> com.github.dockerjava.jaxrs.util.WrappedResponseInputStream@7d534017; line:
> 1, column: 259] (through reference chain:
> com.github.dockerjava.api.model.Event["Attributes"])
> [ pool-1-thread-1] DockerEventsConsumer ERROR Error
> Consuming from Docker Events: Unrecognized field "image" (class
> com.github.dockerjava.api.model.Event), not marked as ignorable (4 known
> properties: "status", "id", "time", "from"])
> at [Source:
> com.github.dockerjava.jaxrs.util.WrappedResponseInputStream@7d534017; line:
> 1, column: 268] (through reference chain:
> com.github.dockerjava.api.model.Event["image"])
> [ pool-1-thread-1] DockerEventsConsumer ERROR Error
> Consuming from Docker Events: Unrecognized field "name" (class
> com.github.dockerjava.api.model.Event), not marked as ignorable (4 known
> properties: "status", "id", "time", "from"])
> at [Source:
> com.github.dockerjava.jaxrs.util.WrappedResponseInputStream@7d534017; line:
> 1, column: 301] (through reference chain:
> com.github.dockerjava.api.model.Event["name"])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9671) camel-docker fails to consume events (Docker API version 1.22)
Peter Keller created CAMEL-9671:
---
Summary: camel-docker fails to consume events (Docker API version
1.22)
Key: CAMEL-9671
URL: https://issues.apache.org/jira/browse/CAMEL-9671
Project: Camel
Issue Type: Bug
Components: camel-docker
Affects Versions: 2.16.2
Environment: MacOS: 10.11.3
Docker Machine: 0.6.0
Docker: Version 1.10.2, API version 1.22
Reporter: Peter Keller
Camel complains that different fields are "not marked as ignorable" and fails
properly handling the event. Fields:
- Type
- Action
- ID
- Attributes
- image
- name
Camel route:
{code}
from("docker://events?host=192.168.99.100=2376=true=/path/to/.docker/machine/machines/default")
.process(new Processor() {
@Override
public void process(Exchange exchange) throws Exception {
LOG.info("body = {}", exchange.getIn().getBody());
}
});
{code}
Error messages:
{code}
[ pool-1-thread-1] DockerEventsConsumer ERROR Error
Consuming from Docker Events: Unrecognized field "Type" (class
com.github.dockerjava.api.model.Event), not marked as ignorable (4 known
properties: "status", "id", "time", "from"])
at [Source:
com.github.dockerjava.jaxrs.util.WrappedResponseInputStream@7d534017; line: 1,
column: 134] (through reference chain:
com.github.dockerjava.api.model.Event["Type"])
[ pool-1-thread-1] DockerEventsConsumer ERROR Error
Consuming from Docker Events: Unrecognized field "Action" (class
com.github.dockerjava.api.model.Event), not marked as ignorable (4 known
properties: "status", "id", "time", "from"])
at [Source:
com.github.dockerjava.jaxrs.util.WrappedResponseInputStream@7d534017; line: 1,
column: 155] (through reference chain:
com.github.dockerjava.api.model.Event["Action"])
[ pool-1-thread-1] DockerEventsConsumer ERROR Error
Consuming from Docker Events: Unrecognized field "Actor" (class
com.github.dockerjava.api.model.Event), not marked as ignorable (4 known
properties: "status", "id", "time", "from"])
at [Source:
com.github.dockerjava.jaxrs.util.WrappedResponseInputStream@7d534017; line: 1,
column: 173] (through reference chain:
com.github.dockerjava.api.model.Event["Actor"])
[ pool-1-thread-1] DockerEventsConsumer ERROR Error
Consuming from Docker Events: Unrecognized field "ID" (class
com.github.dockerjava.api.model.Event), not marked as ignorable (4 known
properties: "status", "id", "time", "from"])
at [Source:
com.github.dockerjava.jaxrs.util.WrappedResponseInputStream@7d534017; line: 1,
column: 179] (through reference chain:
com.github.dockerjava.api.model.Event["ID"])
[ pool-1-thread-1] DockerEventsConsumer ERROR Error
Consuming from Docker Events: Unrecognized field "Attributes" (class
com.github.dockerjava.api.model.Event), not marked as ignorable (4 known
properties: "status", "id", "time", "from"])
at [Source:
com.github.dockerjava.jaxrs.util.WrappedResponseInputStream@7d534017; line: 1,
column: 259] (through reference chain:
com.github.dockerjava.api.model.Event["Attributes"])
[ pool-1-thread-1] DockerEventsConsumer ERROR Error
Consuming from Docker Events: Unrecognized field "image" (class
com.github.dockerjava.api.model.Event), not marked as ignorable (4 known
properties: "status", "id", "time", "from"])
at [Source:
com.github.dockerjava.jaxrs.util.WrappedResponseInputStream@7d534017; line: 1,
column: 268] (through reference chain:
com.github.dockerjava.api.model.Event["image"])
[ pool-1-thread-1] DockerEventsConsumer ERROR Error
Consuming from Docker Events: Unrecognized field "name" (class
com.github.dockerjava.api.model.Event), not marked as ignorable (4 known
properties: "status", "id", "time", "from"])
at [Source:
com.github.dockerjava.jaxrs.util.WrappedResponseInputStream@7d534017; line: 1,
column: 301] (through reference chain:
com.github.dockerjava.api.model.Event["name"])
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-7986) Route disappears if named route1
Peter Keller created CAMEL-7986:
---
Summary: Route disappears if named route1
Key: CAMEL-7986
URL: https://issues.apache.org/jira/browse/CAMEL-7986
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.14.0
Reporter: Peter Keller
With below route configuration with {{routeId}} defined as {{route1}},
{{route2}} and intentionally omitted {{routeId}} for the 3rd route, Camel will
auto-generate a {{routeId}} with format as {{route}} + count for you if you
didn't define it. This seems to cause some routes to be missed.
Route definitions:
{code}
from(direct:start1)
.routeId(route1)
.log(route1: ${body});
from(direct:start2)
.routeId(route2)
.log(route2: ${body});
from(direct:start3) // no route id!
.log(route3: ${body});
{code}
Testing:
{code}
ProducerTemplate template = context.createProducerTemplate();
template.sendBody(direct:start1, World!);
template.sendBody(direct:start2, World!);
{code}
This leads to following exception:
{quote}
Caused by:
org.apache.camel.component.direct.DirectConsumerNotAvailableException: No
consumers available on endpoint: Endpoint[direct://start1]
{quote}
If the {{direct:start3}} route is deleted or {{direct:start}} is renamed, then
everything works as expected.
See
http://stackoverflow.com/questions/26646881/route-is-not-detected-when-route-id-is-not-assigned-does-camelcontext-loses-the/26673144#26673144
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7986) Route disappears if named route1
[
https://issues.apache.org/jira/browse/CAMEL-7986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keller updated CAMEL-7986:
Description:
With below route configuration with {{routeId}} defined as {{route1}},
{{route2}} and intentionally omitted {{routeId}} for the 3rd route, Camel will
auto-generate a {{routeId}} with format as {{route}} + count for you if you
didn't define it. This seems to cause some routes to be missed.
Route definitions:
{code}
from(direct:start1)
.routeId(route1)
.log(route1: ${body});
from(direct:start2)
.routeId(route2)
.log(route2: ${body});
from(direct:start3) // no route id!
.log(route3: ${body});
{code}
Testing:
{code}
ProducerTemplate template = context.createProducerTemplate();
template.sendBody(direct:start1, World!);
template.sendBody(direct:start2, World!);
{code}
This leads to following exception:
{quote}
Caused by:
org.apache.camel.component.direct.DirectConsumerNotAvailableException: No
consumers available on endpoint: Endpoint[direct://start1]
{quote}
If the {{direct:start3}} route is deleted or {{direct:start1}} is renamed, then
everything works as expected.
See
http://stackoverflow.com/questions/26646881/route-is-not-detected-when-route-id-is-not-assigned-does-camelcontext-loses-the/26673144#26673144
was:
With below route configuration with {{routeId}} defined as {{route1}},
{{route2}} and intentionally omitted {{routeId}} for the 3rd route, Camel will
auto-generate a {{routeId}} with format as {{route}} + count for you if you
didn't define it. This seems to cause some routes to be missed.
Route definitions:
{code}
from(direct:start1)
.routeId(route1)
.log(route1: ${body});
from(direct:start2)
.routeId(route2)
.log(route2: ${body});
from(direct:start3) // no route id!
.log(route3: ${body});
{code}
Testing:
{code}
ProducerTemplate template = context.createProducerTemplate();
template.sendBody(direct:start1, World!);
template.sendBody(direct:start2, World!);
{code}
This leads to following exception:
{quote}
Caused by:
org.apache.camel.component.direct.DirectConsumerNotAvailableException: No
consumers available on endpoint: Endpoint[direct://start1]
{quote}
If the {{direct:start3}} route is deleted or {{direct:start}} is renamed, then
everything works as expected.
See
http://stackoverflow.com/questions/26646881/route-is-not-detected-when-route-id-is-not-assigned-does-camelcontext-loses-the/26673144#26673144
Route disappears if named route1
--
Key: CAMEL-7986
URL: https://issues.apache.org/jira/browse/CAMEL-7986
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.14.0
Reporter: Peter Keller
With below route configuration with {{routeId}} defined as {{route1}},
{{route2}} and intentionally omitted {{routeId}} for the 3rd route, Camel
will auto-generate a {{routeId}} with format as {{route}} + count for you if
you didn't define it. This seems to cause some routes to be missed.
Route definitions:
{code}
from(direct:start1)
.routeId(route1)
.log(route1: ${body});
from(direct:start2)
.routeId(route2)
.log(route2: ${body});
from(direct:start3) // no route id!
.log(route3: ${body});
{code}
Testing:
{code}
ProducerTemplate template = context.createProducerTemplate();
template.sendBody(direct:start1, World!);
template.sendBody(direct:start2, World!);
{code}
This leads to following exception:
{quote}
Caused by:
org.apache.camel.component.direct.DirectConsumerNotAvailableException: No
consumers available on endpoint: Endpoint[direct://start1]
{quote}
If the {{direct:start3}} route is deleted or {{direct:start1}} is renamed,
then everything works as expected.
See
http://stackoverflow.com/questions/26646881/route-is-not-detected-when-route-id-is-not-assigned-does-camelcontext-loses-the/26673144#26673144
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7986) Route disappears if named route1
[
https://issues.apache.org/jira/browse/CAMEL-7986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keller updated CAMEL-7986:
Description:
With below route configuration with {{routeId}} defined as {{route1}},
{{route2}} and intentionally omitted {{routeId}} for the 3rd route, Camel will
auto-generate a {{routeId}} with format as {{route}} + count for you if you
didn't define it. This seems to cause some routes to be missed.
Route definitions:
{code}
from(direct:start1)
.routeId(route1)
.log(route1: ${body});
from(direct:start2)
.routeId(route2)
.log(route2: ${body});
from(direct:start3) // no route id!
.log(route3: ${body});
{code}
Testing:
{code}
ProducerTemplate template = context.createProducerTemplate();
template.sendBody(direct:start1, World!);
template.sendBody(direct:start2, World!);
{code}
This leads to following exception:
{quote}
Caused by:
org.apache.camel.component.direct.DirectConsumerNotAvailableException: No
consumers available on endpoint: Endpoint[direct://start1]
{quote}
If the {{direct:start3}} route is deleted or the ID {{route1}} is renamed,
then everything works as expected.
See
http://stackoverflow.com/questions/26646881/route-is-not-detected-when-route-id-is-not-assigned-does-camelcontext-loses-the/26673144#26673144
was:
With below route configuration with {{routeId}} defined as {{route1}},
{{route2}} and intentionally omitted {{routeId}} for the 3rd route, Camel will
auto-generate a {{routeId}} with format as {{route}} + count for you if you
didn't define it. This seems to cause some routes to be missed.
Route definitions:
{code}
from(direct:start1)
.routeId(route1)
.log(route1: ${body});
from(direct:start2)
.routeId(route2)
.log(route2: ${body});
from(direct:start3) // no route id!
.log(route3: ${body});
{code}
Testing:
{code}
ProducerTemplate template = context.createProducerTemplate();
template.sendBody(direct:start1, World!);
template.sendBody(direct:start2, World!);
{code}
This leads to following exception:
{quote}
Caused by:
org.apache.camel.component.direct.DirectConsumerNotAvailableException: No
consumers available on endpoint: Endpoint[direct://start1]
{quote}
If the {{direct:start3}} route is deleted or {{direct:start1}} is renamed, then
everything works as expected.
See
http://stackoverflow.com/questions/26646881/route-is-not-detected-when-route-id-is-not-assigned-does-camelcontext-loses-the/26673144#26673144
Route disappears if named route1
--
Key: CAMEL-7986
URL: https://issues.apache.org/jira/browse/CAMEL-7986
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.14.0
Reporter: Peter Keller
With below route configuration with {{routeId}} defined as {{route1}},
{{route2}} and intentionally omitted {{routeId}} for the 3rd route, Camel
will auto-generate a {{routeId}} with format as {{route}} + count for you if
you didn't define it. This seems to cause some routes to be missed.
Route definitions:
{code}
from(direct:start1)
.routeId(route1)
.log(route1: ${body});
from(direct:start2)
.routeId(route2)
.log(route2: ${body});
from(direct:start3) // no route id!
.log(route3: ${body});
{code}
Testing:
{code}
ProducerTemplate template = context.createProducerTemplate();
template.sendBody(direct:start1, World!);
template.sendBody(direct:start2, World!);
{code}
This leads to following exception:
{quote}
Caused by:
org.apache.camel.component.direct.DirectConsumerNotAvailableException: No
consumers available on endpoint: Endpoint[direct://start1]
{quote}
If the {{direct:start3}} route is deleted or the ID {{route1}} is renamed,
then everything works as expected.
See
http://stackoverflow.com/questions/26646881/route-is-not-detected-when-route-id-is-not-assigned-does-camelcontext-loses-the/26673144#26673144
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7986) Route disappears with ID set to route1
[
https://issues.apache.org/jira/browse/CAMEL-7986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keller updated CAMEL-7986:
Summary: Route disappears with ID set to route1 (was: Route disappears
if named route1)
Route disappears with ID set to route1
Key: CAMEL-7986
URL: https://issues.apache.org/jira/browse/CAMEL-7986
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.14.0
Reporter: Peter Keller
With below route configuration with {{routeId}} defined as {{route1}},
{{route2}} and intentionally omitted {{routeId}} for the 3rd route, Camel
will auto-generate a {{routeId}} with format as {{route}} + count for you if
you didn't define it. This seems to cause some routes to be missed.
Route definitions:
{code}
from(direct:start1)
.routeId(route1)
.log(route1: ${body});
from(direct:start2)
.routeId(route2)
.log(route2: ${body});
from(direct:start3) // no route id!
.log(route3: ${body});
{code}
Testing:
{code}
ProducerTemplate template = context.createProducerTemplate();
template.sendBody(direct:start1, World!);
template.sendBody(direct:start2, World!);
{code}
This leads to following exception:
{quote}
Caused by:
org.apache.camel.component.direct.DirectConsumerNotAvailableException: No
consumers available on endpoint: Endpoint[direct://start1]
{quote}
If the {{direct:start3}} route is deleted or the ID {{route1}} is renamed,
then everything works as expected.
See
http://stackoverflow.com/questions/26646881/route-is-not-detected-when-route-id-is-not-assigned-does-camelcontext-loses-the/26673144#26673144
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7986) Route disappears with routeId set to route1
[
https://issues.apache.org/jira/browse/CAMEL-7986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keller updated CAMEL-7986:
Summary: Route disappears with routeId set to route1 (was: Route
disappears with ID set to route1)
Route disappears with routeId set to route1
-
Key: CAMEL-7986
URL: https://issues.apache.org/jira/browse/CAMEL-7986
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.14.0
Reporter: Peter Keller
With below route configuration with {{routeId}} defined as {{route1}},
{{route2}} and intentionally omitted {{routeId}} for the 3rd route, Camel
will auto-generate a {{routeId}} with format as {{route}} + count for you if
you didn't define it. This seems to cause some routes to be missed.
Route definitions:
{code}
from(direct:start1)
.routeId(route1)
.log(route1: ${body});
from(direct:start2)
.routeId(route2)
.log(route2: ${body});
from(direct:start3) // no route id!
.log(route3: ${body});
{code}
Testing:
{code}
ProducerTemplate template = context.createProducerTemplate();
template.sendBody(direct:start1, World!);
template.sendBody(direct:start2, World!);
{code}
This leads to following exception:
{quote}
Caused by:
org.apache.camel.component.direct.DirectConsumerNotAvailableException: No
consumers available on endpoint: Endpoint[direct://start1]
{quote}
If the {{direct:start3}} route is deleted or the ID {{route1}} is renamed,
then everything works as expected.
See
http://stackoverflow.com/questions/26646881/route-is-not-detected-when-route-id-is-not-assigned-does-camelcontext-loses-the/26673144#26673144
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7578) camel-bindy - pattern attribute should not be ignored if locale is not set
[
https://issues.apache.org/jira/browse/CAMEL-7578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14053099#comment-14053099
]
Peter Keller commented on CAMEL-7578:
-
Thanks a lot for the quick fix!
camel-bindy - pattern attribute should not be ignored if locale is not set
--
Key: CAMEL-7578
URL: https://issues.apache.org/jira/browse/CAMEL-7578
Project: Camel
Issue Type: Bug
Components: camel-bindy
Affects Versions: 2.13.1
Reporter: Peter Keller
Assignee: Claus Ibsen
Fix For: 2.12.5, 2.13.3, 2.14.0
This code doesn't pad field {{mandant}} with 0 if locale is not set:
{code}
@CsvRecord(separator = ,)
public class Unity {
@DataField(pos = 1, pattern = 000)
public float mandant;
{code}
Route:
{code}
final BindyCsvDataFormat bindy = new BindyCsvDataFormat(Unity.class);
from(direct:start)
.marshal(bindy)
.log(${body});
{code}
Testing with:
{code}
final Unity unity = new Unity();
unity.mandant = 50f;
final ProducerTemplate template = context.createProducerTemplate();
{code}
This prints:
{quote}
50.0
{quote}
Only when setting the locale, {{pattern}} is not ignored:
{code}
bindy.setLocale(Locale.US.getISO3Country());
{code}
This prints:
{quote}
050
{quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CAMEL-7578) camel-bindy - pattern attribute should not be ignored if locale is not set
Peter Keller created CAMEL-7578:
---
Summary: camel-bindy - pattern attribute should not be ignored if
locale is not set
Key: CAMEL-7578
URL: https://issues.apache.org/jira/browse/CAMEL-7578
Project: Camel
Issue Type: Bug
Components: camel-bindy
Affects Versions: 2.13.1
Reporter: Peter Keller
This code doesn't pad field mandant with 0 if locale is not set:
{code}
@CsvRecord(separator = ,)
public class Unity {
@DataField(pos = 1, pattern = 000)
public float mandant;
{code}
Route:
{code}
final BindyCsvDataFormat bindy = new BindyCsvDataFormat(Unity.class);
from(direct:start)
.marshal(bindy)
.log(${body});
{code}
Testing with:
{code}
final Unity unity = new Unity();
unity.mandant = 50f;
final ProducerTemplate template = context.createProducerTemplate();
{code}
This prints:
{quote}
50.0
{quote}
Only when setting the locale, {{pattern}} is not ignored:
{code}
bindy.setLocale(Locale.US.toString());
{code}
This prints:
{quote}
050
{quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7578) camel-bindy - pattern attribute should not be ignored if locale is not set
[
https://issues.apache.org/jira/browse/CAMEL-7578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14052417#comment-14052417
]
Peter Keller commented on CAMEL-7578:
-
See
{{org.apache.camel.dataformat.bindy.format.NumberPatternFormat#getNumberFormat()}}:
{code}
if (locale == null) {
return null;
}
{code}
This should be:
{code}
if (locale == null) {
locale = Locale.getDefault();
}
{code}
camel-bindy - pattern attribute should not be ignored if locale is not set
--
Key: CAMEL-7578
URL: https://issues.apache.org/jira/browse/CAMEL-7578
Project: Camel
Issue Type: Bug
Components: camel-bindy
Affects Versions: 2.13.1
Reporter: Peter Keller
This code doesn't pad field mandant with 0 if locale is not set:
{code}
@CsvRecord(separator = ,)
public class Unity {
@DataField(pos = 1, pattern = 000)
public float mandant;
{code}
Route:
{code}
final BindyCsvDataFormat bindy = new BindyCsvDataFormat(Unity.class);
from(direct:start)
.marshal(bindy)
.log(${body});
{code}
Testing with:
{code}
final Unity unity = new Unity();
unity.mandant = 50f;
final ProducerTemplate template = context.createProducerTemplate();
{code}
This prints:
{quote}
50.0
{quote}
Only when setting the locale, {{pattern}} is not ignored:
{code}
bindy.setLocale(Locale.US.toString());
{code}
This prints:
{quote}
050
{quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7555) ZipAggregationStrategy does not preserve properties
[
https://issues.apache.org/jira/browse/CAMEL-7555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14052424#comment-14052424
]
Peter Keller commented on CAMEL-7555:
-
It's expected that properties are accessible during the *entire* lifetime of
the {{Exchange}} object. From the JavaDoc of
[Exchange|http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/Exchange.html]:
{quote}
The Exchange also holds meta-data during its *entire* lifetime stored as
properties accessible using the various getProperty(String) methods.
{quote}
Why not copy just all properties as this is be done everywhere else?
ZipAggregationStrategy does not preserve properties
---
Key: CAMEL-7555
URL: https://issues.apache.org/jira/browse/CAMEL-7555
Project: Camel
Issue Type: Bug
Affects Versions: 2.13.1
Reporter: Peter Keller
Assignee: Willem Jiang
{{ZipAggregationStrategy}} does not preserve properties:
{code}
public class MyRouteBuilder extends RouteBuilder {
@Override
public void configure() {
from(file:zipper/in?include=.*.xmlnoop=true)
.process(new Processor() {
@Override
public void process(final Exchange exchange) throws Exception
{
exchange.setProperty(myProperty, myValue);
}
})
.aggregate(new ZipAggregationStrategy())
.constant(true)
.completionFromBatchConsumer()
.eagerCheckCompletion()
.log(myProperty = ${property.myProperty})
.to(file:zipper/out);
}
}
{code}
This logs:
{quote}
myProperty =
{quote}
Instead it should log:
{quote}
myProperty = myValue
{quote}
See
http://stackoverflow.com/questions/24473035/how-to-access-calling-exchange-with-camels-zipaggregationstrategy
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CAMEL-7578) camel-bindy - pattern attribute should not be ignored if locale is not set
[
https://issues.apache.org/jira/browse/CAMEL-7578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keller updated CAMEL-7578:
Description:
This code doesn't pad field mandant with 0 if locale is not set:
{code}
@CsvRecord(separator = ,)
public class Unity {
@DataField(pos = 1, pattern = 000)
public float mandant;
{code}
Route:
{code}
final BindyCsvDataFormat bindy = new BindyCsvDataFormat(Unity.class);
from(direct:start)
.marshal(bindy)
.log(${body});
{code}
Testing with:
{code}
final Unity unity = new Unity();
unity.mandant = 50f;
final ProducerTemplate template = context.createProducerTemplate();
{code}
This prints:
{quote}
50.0
{quote}
Only when setting the locale, {{pattern}} is not ignored:
{code}
bindy.setLocale(Locale.US.getISO3Country());
{code}
This prints:
{quote}
050
{quote}
was:
This code doesn't pad field mandant with 0 if locale is not set:
{code}
@CsvRecord(separator = ,)
public class Unity {
@DataField(pos = 1, pattern = 000)
public float mandant;
{code}
Route:
{code}
final BindyCsvDataFormat bindy = new BindyCsvDataFormat(Unity.class);
from(direct:start)
.marshal(bindy)
.log(${body});
{code}
Testing with:
{code}
final Unity unity = new Unity();
unity.mandant = 50f;
final ProducerTemplate template = context.createProducerTemplate();
{code}
This prints:
{quote}
50.0
{quote}
Only when setting the locale, {{pattern}} is not ignored:
{code}
bindy.setLocale(Locale.US.toString());
{code}
This prints:
{quote}
050
{quote}
camel-bindy - pattern attribute should not be ignored if locale is not set
--
Key: CAMEL-7578
URL: https://issues.apache.org/jira/browse/CAMEL-7578
Project: Camel
Issue Type: Bug
Components: camel-bindy
Affects Versions: 2.13.1
Reporter: Peter Keller
This code doesn't pad field mandant with 0 if locale is not set:
{code}
@CsvRecord(separator = ,)
public class Unity {
@DataField(pos = 1, pattern = 000)
public float mandant;
{code}
Route:
{code}
final BindyCsvDataFormat bindy = new BindyCsvDataFormat(Unity.class);
from(direct:start)
.marshal(bindy)
.log(${body});
{code}
Testing with:
{code}
final Unity unity = new Unity();
unity.mandant = 50f;
final ProducerTemplate template = context.createProducerTemplate();
{code}
This prints:
{quote}
50.0
{quote}
Only when setting the locale, {{pattern}} is not ignored:
{code}
bindy.setLocale(Locale.US.getISO3Country());
{code}
This prints:
{quote}
050
{quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CAMEL-7578) camel-bindy - pattern attribute should not be ignored if locale is not set
[
https://issues.apache.org/jira/browse/CAMEL-7578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keller updated CAMEL-7578:
Description:
This code doesn't pad field {{mandant}} with 0 if locale is not set:
{code}
@CsvRecord(separator = ,)
public class Unity {
@DataField(pos = 1, pattern = 000)
public float mandant;
{code}
Route:
{code}
final BindyCsvDataFormat bindy = new BindyCsvDataFormat(Unity.class);
from(direct:start)
.marshal(bindy)
.log(${body});
{code}
Testing with:
{code}
final Unity unity = new Unity();
unity.mandant = 50f;
final ProducerTemplate template = context.createProducerTemplate();
{code}
This prints:
{quote}
50.0
{quote}
Only when setting the locale, {{pattern}} is not ignored:
{code}
bindy.setLocale(Locale.US.getISO3Country());
{code}
This prints:
{quote}
050
{quote}
was:
This code doesn't pad field mandant with 0 if locale is not set:
{code}
@CsvRecord(separator = ,)
public class Unity {
@DataField(pos = 1, pattern = 000)
public float mandant;
{code}
Route:
{code}
final BindyCsvDataFormat bindy = new BindyCsvDataFormat(Unity.class);
from(direct:start)
.marshal(bindy)
.log(${body});
{code}
Testing with:
{code}
final Unity unity = new Unity();
unity.mandant = 50f;
final ProducerTemplate template = context.createProducerTemplate();
{code}
This prints:
{quote}
50.0
{quote}
Only when setting the locale, {{pattern}} is not ignored:
{code}
bindy.setLocale(Locale.US.getISO3Country());
{code}
This prints:
{quote}
050
{quote}
camel-bindy - pattern attribute should not be ignored if locale is not set
--
Key: CAMEL-7578
URL: https://issues.apache.org/jira/browse/CAMEL-7578
Project: Camel
Issue Type: Bug
Components: camel-bindy
Affects Versions: 2.13.1
Reporter: Peter Keller
This code doesn't pad field {{mandant}} with 0 if locale is not set:
{code}
@CsvRecord(separator = ,)
public class Unity {
@DataField(pos = 1, pattern = 000)
public float mandant;
{code}
Route:
{code}
final BindyCsvDataFormat bindy = new BindyCsvDataFormat(Unity.class);
from(direct:start)
.marshal(bindy)
.log(${body});
{code}
Testing with:
{code}
final Unity unity = new Unity();
unity.mandant = 50f;
final ProducerTemplate template = context.createProducerTemplate();
{code}
This prints:
{quote}
50.0
{quote}
Only when setting the locale, {{pattern}} is not ignored:
{code}
bindy.setLocale(Locale.US.getISO3Country());
{code}
This prints:
{quote}
050
{quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CAMEL-7555) ZipAggregationStrategy does not preserve properties
Peter Keller created CAMEL-7555:
---
Summary: ZipAggregationStrategy does not preserve properties
Key: CAMEL-7555
URL: https://issues.apache.org/jira/browse/CAMEL-7555
Project: Camel
Issue Type: Bug
Affects Versions: 2.13.1
Reporter: Peter Keller
{{ZipAggregationStrategy}} does not preserve properties:
{code}
public class MyRouteBuilder extends RouteBuilder {
@Override
public void configure() {
from(file:zipper/in?include=.*.xmlnoop=true)
.process(new Processor() {
@Override
public void process(final Exchange exchange) throws Exception {
exchange.setProperty(myProperty, myValue);
}
})
.aggregate(new ZipAggregationStrategy())
.constant(true)
.completionFromBatchConsumer()
.eagerCheckCompletion()
.log(myProperty = ${property.myProperty})
.to(file:zipper/out);
}
}
{code}
This logs:
{quote}
myProperty =
{quote}
Instead it should log:
{quote}
myProperty = myValue
{quote}
See
http://stackoverflow.com/questions/24473035/how-to-access-calling-exchange-with-camels-zipaggregationstrategy
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7478) Simple Language - Length of array properties is not correctly evaluated
[
https://issues.apache.org/jira/browse/CAMEL-7478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14019612#comment-14019612
]
Peter Keller commented on CAMEL-7478:
-
Thanks a lot.
Simple Language - Length of array properties is not correctly evaluated
---
Key: CAMEL-7478
URL: https://issues.apache.org/jira/browse/CAMEL-7478
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.13.1
Reporter: Peter Keller
Assignee: Willem Jiang
Fix For: 2.12.4, 2.13.2, 2.14.0
If the exchange body is an array, then {{body.length}} returns correctly the
length of the array. However, if the array is a property of an object, then
not the correct value is returned:
{code:title=MyClass.java}
public class MyClass {
public Object[] getMyArray() {
return new Object[]{Hallo, World, !};
}
}
{code}
Accessing the property {{myArray}} with Simple:
{code}
setHeader headerName=mySimpleHeader
simplebody.myArray.length/simple
/setHeader
log message=mySimpleHeader = ${header.mySimpleHeader} /
{code}
Java:
{code}
final ProducerTemplate template = main.getCamelTemplate();
template.sendBody(direct:start, new MyClass());
{code}
Log:
{noformat}
[main] route1 INFO mySimpleHeader = 1
{noformat}
The return value should be {{3}} instead of {{1}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Issue Comment Deleted] (CAMEL-7428) Simple Language - Operators are not evaluated for setting body or headers
[
https://issues.apache.org/jira/browse/CAMEL-7428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keller updated CAMEL-7428:
Comment: was deleted
(was: I was not able to install 2.13.1. I downloaded
http://repository.apache.org/content/repositories/orgapachecamel-1008/org/apache/camel/apache-camel/2.13.1/apache-camel-2.13.1-src.zip,
executed {{mvn install}} and got following error:
{noformat}
Running org.apache.camel.view.XmlGraphTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.092 sec - in
org.apache.camel.view.XmlGraphTest
Results :
Failed tests:
FileProducerRenameUsingCopyTestTestSupport.runBare:58-testMove:41-ContextTestSupport.assertMockEndpointsSatisfied:343
mock://result Content of file: target/file/done/hello.txt. Expected: Hello
Camel but was:
Tests run: 4902, Failures: 1, Errors: 0, Skipped: 3
{noformat}
I use MacOS with java version 1.7.0_40.
I tried to subscribe to dev-subscr...@camel.apache.org but without success
(yet), so I post the error here.)
Simple Language - Operators are not evaluated for setting body or headers
-
Key: CAMEL-7428
URL: https://issues.apache.org/jira/browse/CAMEL-7428
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.12.3, 2.13.0
Reporter: Peter Keller
Assignee: Claus Ibsen
Fix For: 2.12.4, 2.13.1, 2.14.0
Operators are not evaluated if using {{simple}} for setting bodies or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
Also, see
http://stackoverflow.com/questions/23523409/camel-how-to-set-boolean-header-parameter-using-simple-comparison/23560989#23560989
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CAMEL-7478) Simple Language - Length of array properties is not correctly evaluated
Peter Keller created CAMEL-7478:
---
Summary: Simple Language - Length of array properties is not
correctly evaluated
Key: CAMEL-7478
URL: https://issues.apache.org/jira/browse/CAMEL-7478
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.13.1
Reporter: Peter Keller
If the exchange body is an array, then {{body.length}} returns correctly the
length of the array. However, if the array is a property of an object, then not
the correct value is returned:
{code:title=MyClass.java}
public class MyClass {
public Object[] getMyArray() {
return new Object[]{Hallo, World, !};
}
}
{code}
Accessing the property {{myArray}} with Simple:
{code}
setHeader headerName=mySimpleHeader
simplebody.myArray.length/simple
/setHeader
log message=mySimpleHeader = ${header.mySimpleHeader} /
{code}
Java:
{code}
final ProducerTemplate template = main.getCamelTemplate();
template.sendBody(direct:start, new MyClass());
{code}
Log:
{noformat}
[main] route1 INFO mySimpleHeader = 1
{noformat}
The return value should be {{3}} instead of {{1}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CAMEL-7479) Test fails in non-English environments
Peter Keller created CAMEL-7479:
---
Summary: Test fails in non-English environments
Key: CAMEL-7479
URL: https://issues.apache.org/jira/browse/CAMEL-7479
Project: Camel
Issue Type: Bug
Components: camel-jaxb, camel-test
Environment: MacOS, Java 1.7.0_40, German language
Reporter: Peter Keller
Some Java exception messages are language specific and JUnit tests evaluating
theses messages fail in a non-English environment.
Such assertions are done in {{JaxbDataFormatSchemaValidationSpringTest}} and
{{JaxbDataFormatSchemaValidationTest}}:
* The assertion Invalid content was found fails for the German message
Ungültiger Content wurde beginnend mit Element age gefunden
({{#testMarshallWithValidationException}})
* The assertion The content of element 'person' is not complete fails for the
German message Content des Elements person ist nicht vollständig
(#testUnmarshallWithValidationException()}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CAMEL-7479) Test fails in non-English environments
[
https://issues.apache.org/jira/browse/CAMEL-7479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keller updated CAMEL-7479:
Description:
Some Java exception messages are language specific and JUnit tests evaluating
theses messages fail in a non-English environment.
Such assertions are done in {{JaxbDataFormatSchemaValidationSpringTest}} and
{{JaxbDataFormatSchemaValidationTest}}:
* The assertion Invalid content was found fails for the German message
Ungültiger Content wurde beginnend mit Element age gefunden
({{#testMarshallWithValidationException}})
* The assertion The content of element 'person' is not complete fails for the
German message Content des Elements person ist nicht vollständig
({{#testUnmarshallWithValidationException()}}.
was:
Some Java exception messages are language specific and JUnit tests evaluating
theses messages fail in a non-English environment.
Such assertions are done in {{JaxbDataFormatSchemaValidationSpringTest}} and
{{JaxbDataFormatSchemaValidationTest}}:
* The assertion Invalid content was found fails for the German message
Ungültiger Content wurde beginnend mit Element age gefunden
({{#testMarshallWithValidationException}})
* The assertion The content of element 'person' is not complete fails for the
German message Content des Elements person ist nicht vollständig
(#testUnmarshallWithValidationException()}}.
Test fails in non-English environments
--
Key: CAMEL-7479
URL: https://issues.apache.org/jira/browse/CAMEL-7479
Project: Camel
Issue Type: Bug
Components: camel-jaxb, camel-test
Environment: MacOS, Java 1.7.0_40, German language
Reporter: Peter Keller
Some Java exception messages are language specific and JUnit tests evaluating
theses messages fail in a non-English environment.
Such assertions are done in {{JaxbDataFormatSchemaValidationSpringTest}} and
{{JaxbDataFormatSchemaValidationTest}}:
* The assertion Invalid content was found fails for the German message
Ungültiger Content wurde beginnend mit Element age gefunden
({{#testMarshallWithValidationException}})
* The assertion The content of element 'person' is not complete fails for
the German message Content des Elements person ist nicht vollständig
({{#testUnmarshallWithValidationException()}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7428) Simple Language - Operators are not evaluated for setting body or headers
[
https://issues.apache.org/jira/browse/CAMEL-7428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13994469#comment-13994469
]
Peter Keller commented on CAMEL-7428:
-
I tested with 2.13.0, 2.13-SNAPSHOT and 2.12-SNAPSHOT and none of them handled
the operators correctly.
Simple Language - Operators are not evaluated for setting body or headers
-
Key: CAMEL-7428
URL: https://issues.apache.org/jira/browse/CAMEL-7428
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.12.3, 2.13.0
Reporter: Peter Keller
Operators are not evaluated if using 'simple' for setting bodies or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
Also, see
http://stackoverflow.com/questions/23523409/camel-how-to-set-boolean-header-parameter-using-simple-comparison/23560989#23560989
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7428) Simple Language - Operators are not evaluated for setting body or headers
[
https://issues.apache.org/jira/browse/CAMEL-7428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13994479#comment-13994479
]
Peter Keller commented on CAMEL-7428:
-
Using
{code}
${true}
{code}
fails with {{Unknown function: true}}?
I tested with {{'hello' == 'hello'}} and {{'hello' contains 'hello'}} and both
return {{false}} instead of {{true}}. The following more complete and realistic
scenario fails too:
{code}
from(direct:simple)
.setHeader(param1, constant(hello))
.log(param1 = ${header.param1})
.setHeader(param2).simple(${header.param1} == 'hello, Boolean.class)
.log(param2 = ${header.param2});
{code}
This logs:
{noformat}
INFO param1 = hello
INFO param2 = false
{noformat}
Simple Language - Operators are not evaluated for setting body or headers
-
Key: CAMEL-7428
URL: https://issues.apache.org/jira/browse/CAMEL-7428
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.12.3, 2.13.0
Reporter: Peter Keller
Operators are not evaluated if using {{simple}} for setting bodies or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
Also, see
http://stackoverflow.com/questions/23523409/camel-how-to-set-boolean-header-parameter-using-simple-comparison/23560989#23560989
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (CAMEL-7428) Simple Language - Operators are not evaluated for setting body or headers
[
https://issues.apache.org/jira/browse/CAMEL-7428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13994479#comment-13994479
]
Peter Keller edited comment on CAMEL-7428 at 5/11/14 9:05 AM:
--
Using
{code}
${true}
{code}
fails with {{Unknown function: true}}?
I tested with {{'hello' == 'hello'}} and {{'hello' contains 'hello'}} and both
return {{false}} instead of {{true}}. The following more complete and realistic
scenario fails too:
{code}
from(direct:simple)
.setHeader(param1, constant(hello))
.log(param1 = ${header.param1})
.setHeader(param2).simple(${header.param1} == 'hello', Boolean.class)
.log(param2 = ${header.param2});
{code}
This logs:
{noformat}
INFO param1 = hello
INFO param2 = false
{noformat}
was (Author: peter keller):
Using
{code}
${true}
{code}
fails with {{Unknown function: true}}?
I tested with {{'hello' == 'hello'}} and {{'hello' contains 'hello'}} and both
return {{false}} instead of {{true}}. The following more complete and realistic
scenario fails too:
{code}
from(direct:simple)
.setHeader(param1, constant(hello))
.log(param1 = ${header.param1})
.setHeader(param2).simple(${header.param1} == 'hello, Boolean.class)
.log(param2 = ${header.param2});
{code}
This logs:
{noformat}
INFO param1 = hello
INFO param2 = false
{noformat}
Simple Language - Operators are not evaluated for setting body or headers
-
Key: CAMEL-7428
URL: https://issues.apache.org/jira/browse/CAMEL-7428
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.12.3, 2.13.0
Reporter: Peter Keller
Operators are not evaluated if using {{simple}} for setting bodies or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
Also, see
http://stackoverflow.com/questions/23523409/camel-how-to-set-boolean-header-parameter-using-simple-comparison/23560989#23560989
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CAMEL-7428) Simple Language - Operators are not evaluated for setting body or headers
[
https://issues.apache.org/jira/browse/CAMEL-7428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keller updated CAMEL-7428:
Description:
Operators are not evaluated if using {{simple}} for setting bodies or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
Also, see
http://stackoverflow.com/questions/23523409/camel-how-to-set-boolean-header-parameter-using-simple-comparison/23560989#23560989
was:
Operators are not evaluated if using 'simple' for setting bodies or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
Also, see
http://stackoverflow.com/questions/23523409/camel-how-to-set-boolean-header-parameter-using-simple-comparison/23560989#23560989
Affects Version/s: 2.13.0
Issue Type: Bug (was: Improvement)
Simple Language - Operators are not evaluated for setting body or headers
-
Key: CAMEL-7428
URL: https://issues.apache.org/jira/browse/CAMEL-7428
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.12.3, 2.13.0
Reporter: Peter Keller
Operators are not evaluated if using {{simple}} for setting bodies or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
Also, see
http://stackoverflow.com/questions/23523409/camel-how-to-set-boolean-header-parameter-using-simple-comparison/23560989#23560989
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7428) Simple Language - Operators are not evaluated for setting body or headers
[
https://issues.apache.org/jira/browse/CAMEL-7428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13994489#comment-13994489
]
Peter Keller commented on CAMEL-7428:
-
I guess fix version 2.13.0 is wrong as I tested with this version and it does
not work properly. It would be helpful to ink to the original issue, however I
didn't find it.
Simple Language - Operators are not evaluated for setting body or headers
-
Key: CAMEL-7428
URL: https://issues.apache.org/jira/browse/CAMEL-7428
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.12.3, 2.13.0
Reporter: Peter Keller
Assignee: Claus Ibsen
Fix For: 2.12.4, 2.13.1, 2.14.0
Operators are not evaluated if using {{simple}} for setting bodies or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
Also, see
http://stackoverflow.com/questions/23523409/camel-how-to-set-boolean-header-parameter-using-simple-comparison/23560989#23560989
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (CAMEL-7428) Simple Language - Operators are not evaluated for setting body or headers
[
https://issues.apache.org/jira/browse/CAMEL-7428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13994489#comment-13994489
]
Peter Keller edited comment on CAMEL-7428 at 5/11/14 9:34 AM:
--
I guess fix version 2.13.0 is wrong as I tested with this version and it does
not work properly. It would be helpful to link to the original issue, however I
didn't find it.
was (Author: peter keller):
I guess fix version 2.13.0 is wrong as I tested with this version and it does
not work properly. It would be helpful to ink to the original issue, however I
didn't find it.
Simple Language - Operators are not evaluated for setting body or headers
-
Key: CAMEL-7428
URL: https://issues.apache.org/jira/browse/CAMEL-7428
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.12.3, 2.13.0
Reporter: Peter Keller
Assignee: Claus Ibsen
Fix For: 2.12.4, 2.13.1, 2.14.0
Operators are not evaluated if using {{simple}} for setting bodies or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
Also, see
http://stackoverflow.com/questions/23523409/camel-how-to-set-boolean-header-parameter-using-simple-comparison/23560989#23560989
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7428) Simple Language - Operators are not evaluated for setting body or headers
[
https://issues.apache.org/jira/browse/CAMEL-7428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13994495#comment-13994495
]
Peter Keller commented on CAMEL-7428:
-
Thanks for updating the fix versions and the link.
Simple Language - Operators are not evaluated for setting body or headers
-
Key: CAMEL-7428
URL: https://issues.apache.org/jira/browse/CAMEL-7428
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.12.3, 2.13.0
Reporter: Peter Keller
Assignee: Claus Ibsen
Fix For: 2.12.4, 2.13.1, 2.14.0
Operators are not evaluated if using {{simple}} for setting bodies or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
Also, see
http://stackoverflow.com/questions/23523409/camel-how-to-set-boolean-header-parameter-using-simple-comparison/23560989#23560989
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7428) Simple Language - Operators are not evaluated for setting body or headers
[
https://issues.apache.org/jira/browse/CAMEL-7428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13994545#comment-13994545
]
Peter Keller commented on CAMEL-7428:
-
I was not able to install 2.13.1. I downloaded
http://repository.apache.org/content/repositories/orgapachecamel-1008/org/apache/camel/apache-camel/2.13.1/apache-camel-2.13.1-src.zip,
executed {{mvn install}} and got following error:
{noformat}
Running org.apache.camel.view.XmlGraphTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.092 sec - in
org.apache.camel.view.XmlGraphTest
Results :
Failed tests:
FileProducerRenameUsingCopyTestTestSupport.runBare:58-testMove:41-ContextTestSupport.assertMockEndpointsSatisfied:343
mock://result Content of file: target/file/done/hello.txt. Expected: Hello
Camel but was:
Tests run: 4902, Failures: 1, Errors: 0, Skipped: 3
{noformat}
I use MacOS with java version 1.7.0_40.
I tried to subscribe to dev-subscr...@camel.apache.org but without success
(yet), so I post the error here.
Simple Language - Operators are not evaluated for setting body or headers
-
Key: CAMEL-7428
URL: https://issues.apache.org/jira/browse/CAMEL-7428
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.12.3, 2.13.0
Reporter: Peter Keller
Assignee: Claus Ibsen
Fix For: 2.12.4, 2.13.1, 2.14.0
Operators are not evaluated if using {{simple}} for setting bodies or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
Also, see
http://stackoverflow.com/questions/23523409/camel-how-to-set-boolean-header-parameter-using-simple-comparison/23560989#23560989
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CAMEL-7428) Simple Language - Operators are not evaluated for setting body or headers
[
https://issues.apache.org/jira/browse/CAMEL-7428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keller updated CAMEL-7428:
Description:
Operators are not evaluated if using 'simple' for setting body or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
Also, see
http://stackoverflow.com/questions/23523409/camel-how-to-set-boolean-header-parameter-using-simple-comparison/23560989#23560989
was:
Operators are not evaluated if using 'simple' for setting body or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
Simple Language - Operators are not evaluated for setting body or headers
-
Key: CAMEL-7428
URL: https://issues.apache.org/jira/browse/CAMEL-7428
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.12.3
Reporter: Peter Keller
Operators are not evaluated if using 'simple' for setting body or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
Also, see
http://stackoverflow.com/questions/23523409/camel-how-to-set-boolean-header-parameter-using-simple-comparison/23560989#23560989
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CAMEL-7428) Simple Language - Operators are not evaluated for setting body or headers
[
https://issues.apache.org/jira/browse/CAMEL-7428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keller updated CAMEL-7428:
Description:
Operators are not evaluated if using 'simple' for setting bodies or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
Also, see
http://stackoverflow.com/questions/23523409/camel-how-to-set-boolean-header-parameter-using-simple-comparison/23560989#23560989
was:
Operators are not evaluated if using 'simple' for setting body or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
Also, see
http://stackoverflow.com/questions/23523409/camel-how-to-set-boolean-header-parameter-using-simple-comparison/23560989#23560989
Simple Language - Operators are not evaluated for setting body or headers
-
Key: CAMEL-7428
URL: https://issues.apache.org/jira/browse/CAMEL-7428
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.12.3
Reporter: Peter Keller
Operators are not evaluated if using 'simple' for setting bodies or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
Also, see
http://stackoverflow.com/questions/23523409/camel-how-to-set-boolean-header-parameter-using-simple-comparison/23560989#23560989
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CAMEL-7428) Simple Language - Operators are not evaluated for setting body or headers
Peter Keller created CAMEL-7428:
---
Summary: Simple Language - Operators are not evaluated for setting
body or headers
Key: CAMEL-7428
URL: https://issues.apache.org/jira/browse/CAMEL-7428
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.12.3
Reporter: Peter Keller
Operators are not evaluated if using 'simple' for setting body or headers:
{code}
from(direct:simple)
.setHeader(myHeader).simple(true == true, Boolean.class)
.log(header = [${header.myHeader}])
.setBody(simple(true == true, Boolean.class))
.log(body = [${body}]);
{code}
Output is as follows:
{code}
INFO header = [false]
INFO body = [false]
{code}
The outcome should be {{true}} in both cases.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
