[jira] [Commented] (CAMEL-16757) camel-core - Allow to define global error handling in all DSL the same way
[ https://issues.apache.org/jira/browse/CAMEL-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376278#comment-17376278 ] Claus Ibsen commented on CAMEL-16757: - TODO: - Collect routes vs build routes: Use 2 pass so we collect all resources first, and then use 1st pass to load only routes configuration. And 2nd pass to load the rest - RouteBuilder Java DSL should we have routesConfiguration() in its own class? - RoutesConfiguration: Add interceptor, on completion, and error handler - Documentation - Examples (main, spring boot, quarkus) > camel-core - Allow to define global error handling in all DSL the same way > -- > > Key: CAMEL-16757 > URL: https://issues.apache.org/jira/browse/CAMEL-16757 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.12.0 > > > In the legacy camel-spring-xml and camel-blueprint you have > where you can setup global error handlers, interceptors etc > In the microservice world we may want to look at allowing to have a > or some other name, where you can drop that as a file > into the routes loader to setup global error handling, and so on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-16790) camel-pulsar is prone to uneven message distribution with large backlog
[ https://issues.apache.org/jira/browse/CAMEL-16790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376266#comment-17376266 ] Claus Ibsen commented on CAMEL-16790: - This appear to be mostly a pulsar issue so lets see what they say > camel-pulsar is prone to uneven message distribution with large backlog > --- > > Key: CAMEL-16790 > URL: https://issues.apache.org/jira/browse/CAMEL-16790 > Project: Camel > Issue Type: Improvement > Components: camel-pulsar > Environment: camel 3.5.0, pulsar 2.7.1, unix >Reporter: Kai Levy >Priority: Minor > > I have filed a bug in the pulsar project about uneven distribution of > messages using the Java client: > [https://github.com/apache/pulsar/issues/11008] - there are some reproduction > instructions in this ticket. This means that for large backlogs, only the > instances that were connected when the messages were produced will be able to > process the messages. > The issue occurs when you use a consumer with `messageListener` and set > `receiverQueueSize > 0`. It appears that the camel-pulsar component uses that > message listener: > [https://github.com/apache/camel/blob/main/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/consumers/CommonCreationStrategyImpl.java#L54] > > We observed the issue in our camel application using camel 3.5.0, but I > believe it occurs on more versions. If the issue is not fixed in the java > client, a convenient workaround could be to use a threadpool calling > `consumer.receive()` in a loop instead of `messageListener`. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-16790) camel-pulsar is prone to uneven message distribution with large backlog
[ https://issues.apache.org/jira/browse/CAMEL-16790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16790: Priority: Minor (was: Major) > camel-pulsar is prone to uneven message distribution with large backlog > --- > > Key: CAMEL-16790 > URL: https://issues.apache.org/jira/browse/CAMEL-16790 > Project: Camel > Issue Type: Improvement > Components: camel-pulsar > Environment: camel 3.5.0, pulsar 2.7.1, unix >Reporter: Kai Levy >Priority: Minor > > I have filed a bug in the pulsar project about uneven distribution of > messages using the Java client: > [https://github.com/apache/pulsar/issues/11008] - there are some reproduction > instructions in this ticket. This means that for large backlogs, only the > instances that were connected when the messages were produced will be able to > process the messages. > The issue occurs when you use a consumer with `messageListener` and set > `receiverQueueSize > 0`. It appears that the camel-pulsar component uses that > message listener: > [https://github.com/apache/camel/blob/main/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/consumers/CommonCreationStrategyImpl.java#L54] > > We observed the issue in our camel application using camel 3.5.0, but I > believe it occurs on more versions. If the issue is not fixed in the java > client, a convenient workaround could be to use a threadpool calling > `consumer.receive()` in a loop instead of `messageListener`. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-16790) camel-pulsar is prone to uneven message distribution with large backlog
[ https://issues.apache.org/jira/browse/CAMEL-16790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16790: Issue Type: Improvement (was: Bug) > camel-pulsar is prone to uneven message distribution with large backlog > --- > > Key: CAMEL-16790 > URL: https://issues.apache.org/jira/browse/CAMEL-16790 > Project: Camel > Issue Type: Improvement > Components: camel-pulsar > Environment: camel 3.5.0, pulsar 2.7.1, unix >Reporter: Kai Levy >Priority: Major > > I have filed a bug in the pulsar project about uneven distribution of > messages using the Java client: > [https://github.com/apache/pulsar/issues/11008] - there are some reproduction > instructions in this ticket. This means that for large backlogs, only the > instances that were connected when the messages were produced will be able to > process the messages. > The issue occurs when you use a consumer with `messageListener` and set > `receiverQueueSize > 0`. It appears that the camel-pulsar component uses that > message listener: > [https://github.com/apache/camel/blob/main/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/consumers/CommonCreationStrategyImpl.java#L54] > > We observed the issue in our camel application using camel 3.5.0, but I > believe it occurs on more versions. If the issue is not fixed in the java > client, a convenient workaround could be to use a threadpool calling > `consumer.receive()` in a loop instead of `messageListener`. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-16790) camel-pulsar is prone to uneven message distribution with large backlog
Kai Levy created CAMEL-16790: Summary: camel-pulsar is prone to uneven message distribution with large backlog Key: CAMEL-16790 URL: https://issues.apache.org/jira/browse/CAMEL-16790 Project: Camel Issue Type: Bug Components: camel-pulsar Environment: camel 3.5.0, pulsar 2.7.1, unix Reporter: Kai Levy I have filed a bug in the pulsar project about uneven distribution of messages using the Java client: [https://github.com/apache/pulsar/issues/11008] - there are some reproduction instructions in this ticket. This means that for large backlogs, only the instances that were connected when the messages were produced will be able to process the messages. The issue occurs when you use a consumer with `messageListener` and set `receiverQueueSize > 0`. It appears that the camel-pulsar component uses that message listener: [https://github.com/apache/camel/blob/main/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/consumers/CommonCreationStrategyImpl.java#L54] We observed the issue in our camel application using camel 3.5.0, but I believe it occurs on more versions. If the issue is not fixed in the java client, a convenient workaround could be to use a threadpool calling `consumer.receive()` in a loop instead of `messageListener`. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-16789) faulttolerance: timeoutScheduledExecutorServiceRef and bulkHead* to be deprecated ?
Alex Dettinger created CAMEL-16789: -- Summary: faulttolerance: timeoutScheduledExecutorServiceRef and bulkHead* to be deprecated ? Key: CAMEL-16789 URL: https://issues.apache.org/jira/browse/CAMEL-16789 Project: Camel Issue Type: Task Reporter: Alex Dettinger It looks like faulttolerance *timeoutScheduledExecutorServiceRef* and *bulkHead** have no effect. [FaultToleranceConfiguration.getTimeoutScheduledExecutorServiceRef()|https://github.com/apache/camel/blob/main/components/camel-microprofile/camel-microprofile-fault-tolerance/src/main/java/org/apache/camel/component/microprofile/faulttolerance/FaultToleranceConfiguration.java#L89..L91] is never called from camel code, so the configured value is never reified into an actual processor as far as I get it. Concerning bulkHead*, the [FaultToleranceReifier does not propagate|https://github.com/apache/camel/blob/main/components/camel-microprofile/camel-microprofile-fault-tolerance/src/main/java/org/apache/camel/component/microprofile/faulttolerance/FaultToleranceReifier.java#L103..L108] the bulkHeadEnabled boolean by calling something like *target.setBulkheadEnabled(true);* As such, the FaultToleranceProcessor never actually executes the [doStart()|https://github.com/apache/camel/blob/main/components/camel-microprofile/camel-microprofile-fault-tolerance/src/main/java/org/apache/camel/component/microprofile/faulttolerance/FaultToleranceProcessor.java#L348..L352] and [process()|https://github.com/apache/camel/blob/main/components/camel-microprofile/camel-microprofile-fault-tolerance/src/main/java/org/apache/camel/component/microprofile/faulttolerance/FaultToleranceProcessor.java#L239..L243] code related to bulkhead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CAMEL-16589) [camel-azure-servicebus] Create Azure ServiceBus component
[ https://issues.apache.org/jira/browse/CAMEL-16589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Omar Al-Safi closed CAMEL-16589. Resolution: Fixed > [camel-azure-servicebus] Create Azure ServiceBus component > -- > > Key: CAMEL-16589 > URL: https://issues.apache.org/jira/browse/CAMEL-16589 > Project: Camel > Issue Type: New Feature > Components: camel-azure >Reporter: Omar Al-Safi >Assignee: Omar Al-Safi >Priority: Minor > Fix For: 3.12.0 > > > Per title, some references: > * > https://github.com/Azure/azure-sdk-for-java/tree/master/sdk/servicebus/azure-messaging-servicebus > * > https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted > * https://azure.microsoft.com/en-us/services/service-bus/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-16788) Local parameters get overridden by environment variable
Nicola Ferraro created CAMEL-16788: -- Summary: Local parameters get overridden by environment variable Key: CAMEL-16788 URL: https://issues.apache.org/jira/browse/CAMEL-16788 Project: Camel Issue Type: Bug Components: camel-kamelet Reporter: Nicola Ferraro Fix For: 3.12.0 When a Kamelet declares a parameter like "namespace" or "port", then the value assigned to that parameter via properties is ignored if there's a "NAMESPACE" or "PORT" environment variable set on the host. That strategy may work well for global parameters, but scoped parameters should prioritize the local configuration if present. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-16787) 3rd party dependency or pom.xml refers to bintray
[ https://issues.apache.org/jira/browse/CAMEL-16787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17375362#comment-17375362 ] Claus Ibsen commented on CAMEL-16787: - It would be good to know which one to see if we can fix it or something > 3rd party dependency or pom.xml refers to bintray > - > > Key: CAMEL-16787 > URL: https://issues.apache.org/jira/browse/CAMEL-16787 > Project: Camel > Issue Type: Task > Components: build system >Reporter: Claus Ibsen >Priority: Major > > You can see this when building endpoint-dsl > [INFO] -< org.apache.camel:camel-endpointdsl > >- > [INFO] Building Camel :: Endpoint DSL 3.12.0-SNAPSHOT > [26/27] > [INFO] [ jar > ]- > [WARNING] Failure to transfer > com.google.code.findbugs:jsr305/maven-metadata.xml from > http://allenai.bintray.com/maven was cached in the local repository, > resolution will not be reattempted until the update interval of > bintray-allenai-maven has elapsed or updates are forced. Original error: > Could not transfer metadata > com.google.code.findbugs:jsr305/maven-metadata.xml from/to > bintray-allenai-maven (http://allenai.bintray.com/maven): Authorization > failed for > http://allenai.bintray.com/maven/com/google/code/findbugs/jsr305/maven-metadata.xml > 403 Forbidden -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-16787) 3rd party dependency or pom.xml refers to bintray
[ https://issues.apache.org/jira/browse/CAMEL-16787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16787: Component/s: build system > 3rd party dependency or pom.xml refers to bintray > - > > Key: CAMEL-16787 > URL: https://issues.apache.org/jira/browse/CAMEL-16787 > Project: Camel > Issue Type: Task > Components: build system >Reporter: Claus Ibsen >Priority: Major > > You can see this when building endpoint-dsl > [INFO] -< org.apache.camel:camel-endpointdsl > >- > [INFO] Building Camel :: Endpoint DSL 3.12.0-SNAPSHOT > [26/27] > [INFO] [ jar > ]- > [WARNING] Failure to transfer > com.google.code.findbugs:jsr305/maven-metadata.xml from > http://allenai.bintray.com/maven was cached in the local repository, > resolution will not be reattempted until the update interval of > bintray-allenai-maven has elapsed or updates are forced. Original error: > Could not transfer metadata > com.google.code.findbugs:jsr305/maven-metadata.xml from/to > bintray-allenai-maven (http://allenai.bintray.com/maven): Authorization > failed for > http://allenai.bintray.com/maven/com/google/code/findbugs/jsr305/maven-metadata.xml > 403 Forbidden -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-16787) 3rd party dependency or pom.xml refers to bintray
Claus Ibsen created CAMEL-16787: --- Summary: 3rd party dependency or pom.xml refers to bintray Key: CAMEL-16787 URL: https://issues.apache.org/jira/browse/CAMEL-16787 Project: Camel Issue Type: Task Reporter: Claus Ibsen You can see this when building endpoint-dsl [INFO] -< org.apache.camel:camel-endpointdsl >- [INFO] Building Camel :: Endpoint DSL 3.12.0-SNAPSHOT [26/27] [INFO] [ jar ]- [WARNING] Failure to transfer com.google.code.findbugs:jsr305/maven-metadata.xml from http://allenai.bintray.com/maven was cached in the local repository, resolution will not be reattempted until the update interval of bintray-allenai-maven has elapsed or updates are forced. Original error: Could not transfer metadata com.google.code.findbugs:jsr305/maven-metadata.xml from/to bintray-allenai-maven (http://allenai.bintray.com/maven): Authorization failed for http://allenai.bintray.com/maven/com/google/code/findbugs/jsr305/maven-metadata.xml 403 Forbidden -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-16757) camel-core - Allow to define global error handling in all DSL the same way
[ https://issues.apache.org/jira/browse/CAMEL-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16757: Summary: camel-core - Allow to define global error handling in all DSL the same way (was: camel-core - yaml and xml dsl - Allow to define global error handling) > camel-core - Allow to define global error handling in all DSL the same way > -- > > Key: CAMEL-16757 > URL: https://issues.apache.org/jira/browse/CAMEL-16757 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.12.0 > > > In the legacy camel-spring-xml and camel-blueprint you have > where you can setup global error handlers, interceptors etc > In the microservice world we may want to look at allowing to have a > or some other name, where you can drop that as a file > into the routes loader to setup global error handling, and so on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-16757) camel-core - yaml and xml dsl - Allow to define global error handling
[ https://issues.apache.org/jira/browse/CAMEL-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17375360#comment-17375360 ] Claus Ibsen commented on CAMEL-16757: - Working on this. This will be generic for the DSL (also Java) so we can configure this the same way in all DSLs. Currently you could only in Java DSL have a base class with global error handling. And in XML it was only the old spring and blueprint xml that has this specially. The idea is that you can have a RouteBuilder (or some new class) for this kind of global configuration, that Camel then discover like any other routes (via route collector). This also allows to define global error handler and whatnot in Java code, and then users can use XML to define routes, eg as some users may not be savy Java coders. Also you can have global error handling etc in a JAR that you just add as a dependency. > camel-core - yaml and xml dsl - Allow to define global error handling > - > > Key: CAMEL-16757 > URL: https://issues.apache.org/jira/browse/CAMEL-16757 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.12.0 > > > In the legacy camel-spring-xml and camel-blueprint you have > where you can setup global error handlers, interceptors etc > In the microservice world we may want to look at allowing to have a > or some other name, where you can drop that as a file > into the routes loader to setup global error handling, and so on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CAMEL-15953) [camel-vertx-kafka] Upgrade Vertx kafka client to 4.0.0
[ https://issues.apache.org/jira/browse/CAMEL-15953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Omar Al-Safi closed CAMEL-15953. Resolution: Duplicate It has been already done > [camel-vertx-kafka] Upgrade Vertx kafka client to 4.0.0 > --- > > Key: CAMEL-15953 > URL: https://issues.apache.org/jira/browse/CAMEL-15953 > Project: Camel > Issue Type: Task > Components: camel-vertx >Affects Versions: 3.7.0 >Reporter: Omar Al-Safi >Assignee: Omar Al-Safi >Priority: Minor > Fix For: 3.x > > > Upgrade Vertx kafka client to 4.0.0. However this is *not just only version > pump up* this requires work to migrate the APIs that were being used in > camel-vertx-kafka 3.9.5 to to be 4.0.0, for example from callback based to > Future based APIs -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-16774) camel-debezium - Upgrade to 1.6
[ https://issues.apache.org/jira/browse/CAMEL-16774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16774. - Resolution: Fixed > camel-debezium - Upgrade to 1.6 > --- > > Key: CAMEL-16774 > URL: https://issues.apache.org/jira/browse/CAMEL-16774 > Project: Camel > Issue Type: Dependency upgrade >Reporter: Claus Ibsen >Assignee: Ramu >Priority: Major > Fix For: 3.12.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
