[jira] [Comment Edited] (CAMEL-11650) Use Hibernate Validator 6.x where possible
[ https://issues.apache.org/jira/browse/CAMEL-11650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16561868#comment-16561868 ] Yves De Moor edited comment on CAMEL-11650 at 7/30/18 12:46 PM: A notice is missing on the release note of version 2.22.0 about this upgrade to validator 2.0 api. Especially because JSR 380 (Bean Validation 2.0) is part of JEE 8, and as therefore camel 2.22.0 may not be running on Java EE 7 server. was (Author: yvesdm): A notice is missing on the release note of version 2.22.0 about this upgrade to validator 2.0 api. Especially because JSR 380 (Bean Validation 2.0) is part of JEE 8, and as therefore camel 2.22.0 may not be running on Java EE 7 server. 2.6.0.0 > Use Hibernate Validator 6.x where possible > -- > > Key: CAMEL-11650 > URL: https://issues.apache.org/jira/browse/CAMEL-11650 > Project: Camel > Issue Type: Task > Components: camel-bean-validator, camel-cm-sms >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 2.22.0 > > > We have to try to upgrade wherever possible, but we may have problem with > validation-api and el-api in OSGi. It will be a bit of pain to use the same > version for all the component and have all working in OSGi. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-11650) Use Hibernate Validator 6.x where possible
[ https://issues.apache.org/jira/browse/CAMEL-11650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16561868#comment-16561868 ] Yves De Moor edited comment on CAMEL-11650 at 7/30/18 12:43 PM: A notice is missing on the release note of version 2.22.0 about this upgrade to validator 2.0 api. Especially because JSR 380 (Bean Validation 2.0) is part of JEE 8, and as therefore camel 2.22.0 may not be running on Java EE 7 server. 2.6.0.0 was (Author: yvesdm): A notice is missing on the release note of version 2.22.0 about this upgrade to validator 2.0 api. Especially because JSR 380 (Bean Validation 2.0) is part of JEE 8, and as therefore camel 2.22.0 may not be running on Java EE 7 server. 2.6.0.0 > Use Hibernate Validator 6.x where possible > -- > > Key: CAMEL-11650 > URL: https://issues.apache.org/jira/browse/CAMEL-11650 > Project: Camel > Issue Type: Task > Components: camel-bean-validator, camel-cm-sms >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 2.22.0 > > > We have to try to upgrade wherever possible, but we may have problem with > validation-api and el-api in OSGi. It will be a bit of pain to use the same > version for all the component and have all working in OSGi. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-11650) Use Hibernate Validator 6.x where possible
[ https://issues.apache.org/jira/browse/CAMEL-11650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16561868#comment-16561868 ] Yves De Moor commented on CAMEL-11650: -- A notice is missing on the release note of version 2.22.0 about this upgrade to validator 2.0 api. Especially because JSR 380 (Bean Validation 2.0) is part of JEE 8, and as therefore camel 2.22.0 may not be running on Java EE 7 server. 2.6.0.0 > Use Hibernate Validator 6.x where possible > -- > > Key: CAMEL-11650 > URL: https://issues.apache.org/jira/browse/CAMEL-11650 > Project: Camel > Issue Type: Task > Components: camel-bean-validator, camel-cm-sms >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 2.22.0 > > > We have to try to upgrade wherever possible, but we may have problem with > validation-api and el-api in OSGi. It will be a bit of pain to use the same > version for all the component and have all working in OSGi. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-5539) Circuit Breaker EIP
[ https://issues.apache.org/jira/browse/CAMEL-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14185021#comment-14185021 ] Yves De Moor commented on CAMEL-5539: - I would suggest two changes in the current implementation : 1. Ability to call a route when the the circuit is open and not only when it is closed (to allow for instance to go further with a degraded mode, or to return a functional error, ...). The source code currently add a RejectedExecutionException to the exchange. I don't know if this is a camel expected behaviour as it is usually thrown to reject the execution when camel is shutting down. 2. If change 1 is accepted, we could set the number of failure in the exchange so we could for instance react the first time the circuit is open (write to the log, send an alert, or whatever else) What are your opinion ? Circuit Breaker EIP --- Key: CAMEL-5539 URL: https://issues.apache.org/jira/browse/CAMEL-5539 Project: Camel Issue Type: New Feature Components: camel-core, eip Reporter: Claus Ibsen Assignee: Raúl Kripalani Fix For: Future Attachments: CAMEL-5539-output-82ef800.txt, CAMEL-5539-output.txt Look at add the circuit breaker EIP to the Camel DSL. http://davybrion.com/blog/2008/05/the-circuit-breaker/ Would need some thoughts for that though. Either as an explicit in the DSL. Or as a interceptor for sending to an endpoint. As explicit its a kind to the load balancer (in fact it may be extended upon that). Either the LB selects the intended target, or it select the breaker, which rejects executing the message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-5539) Circuit Breaker EIP
[ https://issues.apache.org/jira/browse/CAMEL-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14185200#comment-14185200 ] Yves De Moor commented on CAMEL-5539: - Simple, quick and most flexible solution could be : Put the number of failure in an exchange property. Put circuit state in an exchange property (2 status : Open / closed, as halfOpen do the same as closed in term of business) use a Content Based Router to perform something like from(direct:a) .loadBalance()// .circuitBreaker(3, 3000L, MyCustomException.class) .choice() .when(property(Exchange.CircuitBreaker_state).isEqualTo(closed)) .to(direct:normalMode) .when(property(Exchange.CircuitBreaker_state).isEqualTo(opened)) .to(direct:degradedMode) .end() from(direct:degradedMode) .choice() .when(property(Exchange.CircuitBreaker_errorCount).isEqualTo(1)) //First error encountered, send an alert to monitoring .to(direct:monitorging_alert_degradedMode) .end() I also see the current solution is not enough robust. when halfOpen is reached, (System.currentTimeMillis() - lastFailure halfOpenAfter) there is no restriction on the number of calls (threads) that will perform a retry. When retry timeout is reached, we should let only 1 thread go in halfOpen mode, all other should be kept in open state until an halfOpen succeed. (will create new issue for this) Yves. Circuit Breaker EIP --- Key: CAMEL-5539 URL: https://issues.apache.org/jira/browse/CAMEL-5539 Project: Camel Issue Type: New Feature Components: camel-core, eip Reporter: Claus Ibsen Assignee: Raúl Kripalani Fix For: Future Attachments: CAMEL-5539-output-82ef800.txt, CAMEL-5539-output.txt Look at add the circuit breaker EIP to the Camel DSL. http://davybrion.com/blog/2008/05/the-circuit-breaker/ Would need some thoughts for that though. Either as an explicit in the DSL. Or as a interceptor for sending to an endpoint. As explicit its a kind to the load balancer (in fact it may be extended upon that). Either the LB selects the intended target, or it select the breaker, which rejects executing the message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7972) Make the Circuit Breaker EIP more robust - in state halfOpen let only one thread to perform a try
Yves De Moor created CAMEL-7972: --- Summary: Make the Circuit Breaker EIP more robust - in state halfOpen let only one thread to perform a try Key: CAMEL-7972 URL: https://issues.apache.org/jira/browse/CAMEL-7972 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.14.0 Reporter: Yves De Moor when halfOpen is reached, (System.currentTimeMillis() - lastFailure halfOpenAfter) there is no restriction on the number of calls (threads) that will perform a retry. When retry timeout is reached, we should let only 1 thread go in halfOpen mode, all other should be kept in open state until an halfOpen succeed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7974) Provide CircuitBreaker state in an exchange property
Yves De Moor created CAMEL-7974: --- Summary: Provide CircuitBreaker state in an exchange property Key: CAMEL-7974 URL: https://issues.apache.org/jira/browse/CAMEL-7974 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.14.0 Reporter: Yves De Moor To be more flexible, the idea is to create some exchange properties Put circuit state in an exchange property (2 status : Open / closed, as halfOpen do the same as closed in term of business) use a Content Based Router to perform something like from(direct:a) .loadBalance()// .circuitBreaker(3, 3000L, MyCustomException.class) .choice() .when(property(Exchange.CircuitBreaker_state).isEqualTo(closed)) .to(direct:normalMode) .when(property(Exchange.CircuitBreaker_state).isEqualTo(opened)) .to(direct:degradedMode) .end() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7167) AbstractListAggregationStrategy : at the end of the split, the body is not replaced by the agregated list
Yves De Moor created CAMEL-7167:
---
Summary: AbstractListAggregationStrategy : at the end of the
split, the body is not replaced by the agregated list
Key: CAMEL-7167
URL: https://issues.apache.org/jira/browse/CAMEL-7167
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.12.1
Reporter: Yves De Moor
Priority: Minor
Using a class that extends AbstractListAggregationStrategy to rebuild a List
after the completion of the split cause the body not to be replaced by the
agregated list at the end of the split.
In other words (AbstractListAggregationStrategy.onCompletion(Exchange exchange)
is never called.
Here is what I do :
from(HANDLE_A_LIST)//
.split(body(), new ListAggregationStrategy())// body is an
arrayList of String
.to(log:foo)//
.end()// end split
// the body is a string instead of a List
.end()// end route
class ListAggregationStrategy extends AbstractListAggregationStrategyString
{
@Override
public String getValue(Exchange exchange)
{
return exchange.getIn().getBody();
}
}
As workaround, I use .setBody(property(Exchange.GROUPED_EXCHANGE)) after the
end of the split.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
