[jira] [Resolved] (CAMEL-20722) camel-kafka: reduce KafkaBreakOnFirstError tests are too unreliable for CIs
[ https://issues.apache.org/jira/browse/CAMEL-20722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] JV Singh resolved CAMEL-20722. -- Resolution: Fixed local builds have been quite stable for a while, and last CI tests were clean after this: [https://github.com/apache/camel/pull/14060] I suggest we observe this for a few more rounds on CI > camel-kafka: reduce KafkaBreakOnFirstError tests are too unreliable for CIs > --- > > Key: CAMEL-20722 > URL: https://issues.apache.org/jira/browse/CAMEL-20722 > Project: Camel > Issue Type: Task > Components: camel-kafka >Affects Versions: 4.4.1, 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: JV Singh >Priority: Major > Labels: help-wanted > Fix For: 4.x > > Attachments: build-log.txt > > > All the tests named KafkaBreakOnFirst.*IT are unreliable when running on the > CI. They fail often, sometimes in multiple archs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (CAMEL-20722) camel-kafka: reduce KafkaBreakOnFirstError tests are too unreliable for CIs
[ https://issues.apache.org/jira/browse/CAMEL-20722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-20722 started by JV Singh. > camel-kafka: reduce KafkaBreakOnFirstError tests are too unreliable for CIs > --- > > Key: CAMEL-20722 > URL: https://issues.apache.org/jira/browse/CAMEL-20722 > Project: Camel > Issue Type: Task > Components: camel-kafka >Affects Versions: 4.4.1, 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: JV Singh >Priority: Major > Labels: help-wanted > Fix For: 4.x > > Attachments: build-log.txt > > > All the tests named KafkaBreakOnFirst.*IT are unreliable when running on the > CI. They fail often, sometimes in multiple archs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20722) camel-kafka: reduce KafkaBreakOnFirstError tests are too unreliable for CIs
[ https://issues.apache.org/jira/browse/CAMEL-20722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844544#comment-17844544 ] JV Singh commented on CAMEL-20722: -- Since local builds have been quite stable for a while, and last CI tests were clean after this: [https://github.com/apache/camel/pull/14060] I suggest we observe this for a few more rounds on CI, just in case we find another random failure [~orpiske] , you can take a call when it's ok to mark this as closed > camel-kafka: reduce KafkaBreakOnFirstError tests are too unreliable for CIs > --- > > Key: CAMEL-20722 > URL: https://issues.apache.org/jira/browse/CAMEL-20722 > Project: Camel > Issue Type: Task > Components: camel-kafka >Affects Versions: 4.4.1, 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: JV Singh >Priority: Major > Labels: help-wanted > Fix For: 4.x > > Attachments: build-log.txt > > > All the tests named KafkaBreakOnFirst.*IT are unreliable when running on the > CI. They fail often, sometimes in multiple archs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work stopped] (CAMEL-20722) camel-kafka: reduce KafkaBreakOnFirstError tests are too unreliable for CIs
[ https://issues.apache.org/jira/browse/CAMEL-20722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-20722 stopped by JV Singh. > camel-kafka: reduce KafkaBreakOnFirstError tests are too unreliable for CIs > --- > > Key: CAMEL-20722 > URL: https://issues.apache.org/jira/browse/CAMEL-20722 > Project: Camel > Issue Type: Task > Components: camel-kafka >Affects Versions: 4.4.1, 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: JV Singh >Priority: Major > Labels: help-wanted > Fix For: 4.x > > Attachments: build-log.txt > > > All the tests named KafkaBreakOnFirst.*IT are unreliable when running on the > CI. They fail often, sometimes in multiple archs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (CAMEL-20722) camel-kafka: reduce KafkaBreakOnFirstError tests are too unreliable for CIs
[ https://issues.apache.org/jira/browse/CAMEL-20722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-20722 started by JV Singh. > camel-kafka: reduce KafkaBreakOnFirstError tests are too unreliable for CIs > --- > > Key: CAMEL-20722 > URL: https://issues.apache.org/jira/browse/CAMEL-20722 > Project: Camel > Issue Type: Task > Components: camel-kafka >Affects Versions: 4.4.1, 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: JV Singh >Priority: Major > Labels: help-wanted > Fix For: 4.x > > Attachments: build-log.txt > > > All the tests named KafkaBreakOnFirst.*IT are unreliable when running on the > CI. They fail often, sometimes in multiple archs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20680) camel-kafka: reduce KafkaBreakOnFirstErrorSeekIssueIT test duration
[ https://issues.apache.org/jira/browse/CAMEL-20680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844541#comment-17844541 ] JV Singh commented on CAMEL-20680: -- Assigning back to [~orpiske] who created this , to review and close. > camel-kafka: reduce KafkaBreakOnFirstErrorSeekIssueIT test duration > --- > > Key: CAMEL-20680 > URL: https://issues.apache.org/jira/browse/CAMEL-20680 > Project: Camel > Issue Type: Task > Components: camel-kafka >Affects Versions: 4.4.1, 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Labels: help-wanted > Fix For: 4.x > > Attachments: image-2024-05-01-08-13-28-056.png > > > The test KafkaBreakOnFirstErrorSeekIssueIT takes a very long time to run. > This consumes unnecessary resources from ASF CI. We should investigate how to > improve it to it runs quickly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20680) camel-kafka: reduce KafkaBreakOnFirstErrorSeekIssueIT test duration
[ https://issues.apache.org/jira/browse/CAMEL-20680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] JV Singh resolved CAMEL-20680. -- Resolution: Fixed This specific test was fixed via pull request: [https://github.com/apache/camel/pull/14008] There a drastic reduction in test execution time. Subsequent pull request re-enabled this and related set of tests: https://github.com/apache/camel/pull/14060/commits > camel-kafka: reduce KafkaBreakOnFirstErrorSeekIssueIT test duration > --- > > Key: CAMEL-20680 > URL: https://issues.apache.org/jira/browse/CAMEL-20680 > Project: Camel > Issue Type: Task > Components: camel-kafka >Affects Versions: 4.4.1, 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: JV Singh >Priority: Major > Labels: help-wanted > Fix For: 4.x > > Attachments: image-2024-05-01-08-13-28-056.png > > > The test KafkaBreakOnFirstErrorSeekIssueIT takes a very long time to run. > This consumes unnecessary resources from ASF CI. We should investigate how to > improve it to it runs quickly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20680) camel-kafka: reduce KafkaBreakOnFirstErrorSeekIssueIT test duration
[ https://issues.apache.org/jira/browse/CAMEL-20680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] JV Singh reassigned CAMEL-20680: Assignee: Otavio Rodolfo Piske (was: JV Singh) > camel-kafka: reduce KafkaBreakOnFirstErrorSeekIssueIT test duration > --- > > Key: CAMEL-20680 > URL: https://issues.apache.org/jira/browse/CAMEL-20680 > Project: Camel > Issue Type: Task > Components: camel-kafka >Affects Versions: 4.4.1, 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Labels: help-wanted > Fix For: 4.x > > Attachments: image-2024-05-01-08-13-28-056.png > > > The test KafkaBreakOnFirstErrorSeekIssueIT takes a very long time to run. > This consumes unnecessary resources from ASF CI. We should investigate how to > improve it to it runs quickly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (CAMEL-20680) camel-kafka: reduce KafkaBreakOnFirstErrorSeekIssueIT test duration
[ https://issues.apache.org/jira/browse/CAMEL-20680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-20680 started by JV Singh. > camel-kafka: reduce KafkaBreakOnFirstErrorSeekIssueIT test duration > --- > > Key: CAMEL-20680 > URL: https://issues.apache.org/jira/browse/CAMEL-20680 > Project: Camel > Issue Type: Task > Components: camel-kafka >Affects Versions: 4.4.1, 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: JV Singh >Priority: Major > Labels: help-wanted > Fix For: 4.x > > Attachments: image-2024-05-01-08-13-28-056.png > > > The test KafkaBreakOnFirstErrorSeekIssueIT takes a very long time to run. > This consumes unnecessary resources from ASF CI. We should investigate how to > improve it to it runs quickly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20745) camel-core-dsl - Add support for constructors to lookup beans
[ https://issues.apache.org/jira/browse/CAMEL-20745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-20745. - Resolution: Fixed > camel-core-dsl - Add support for constructors to lookup beans > - > > Key: CAMEL-20745 > URL: https://issues.apache.org/jira/browse/CAMEL-20745 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 4.5.0, 4.6.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 4.7.0 > > > https://github.com/apache/camel-karavan/discussions/1251 > We should support looking up beans if constructor has #bean:xxx to find the > correct constructor method so it match by type and not take it as a String > parameter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20745) camel-core-dsl - Add support for constructors to lookup beans
[ https://issues.apache.org/jira/browse/CAMEL-20745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-20745: --- Assignee: Claus Ibsen > camel-core-dsl - Add support for constructors to lookup beans > - > > Key: CAMEL-20745 > URL: https://issues.apache.org/jira/browse/CAMEL-20745 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 4.5.0, 4.6.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 4.7.0 > > > https://github.com/apache/camel-karavan/discussions/1251 > We should support looking up beans if constructor has #bean:xxx to find the > correct constructor method so it match by type and not take it as a String > parameter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20745) camel-core-dsl - Add support for constructors to lookup beans
Claus Ibsen created CAMEL-20745: --- Summary: camel-core-dsl - Add support for constructors to lookup beans Key: CAMEL-20745 URL: https://issues.apache.org/jira/browse/CAMEL-20745 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 4.5.0, 4.6.0 Reporter: Claus Ibsen Fix For: 4.7.0 https://github.com/apache/camel-karavan/discussions/1251 We should support looking up beans if constructor has #bean:xxx to find the correct constructor method so it match by type and not take it as a String parameter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20744) camel-core - Error handler redelivery to support option to break out if stopping
Claus Ibsen created CAMEL-20744: --- Summary: camel-core - Error handler redelivery to support option to break out if stopping Key: CAMEL-20744 URL: https://issues.apache.org/jira/browse/CAMEL-20744 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Fix For: 4.x We can maybe add an option to error handler / onException retryWhileStopping = true|false This means that Camel will stop doing retries/redeliveries when CamelContext is stopping / or that the current route is being stopped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20743) camel-model - Load Balancer EIPs to be named with LoadBalancer to be consistent in naming style
Claus Ibsen created CAMEL-20743: --- Summary: camel-model - Load Balancer EIPs to be named with LoadBalancer to be consistent in naming style Key: CAMEL-20743 URL: https://issues.apache.org/jira/browse/CAMEL-20743 Project: Camel Issue Type: Improvement Components: camel-core, dsl Reporter: Claus Ibsen Fix For: 4.x failover -> failoverLoadBalancer random -> randomLoadBalancer ... and so on. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-17829) camel-as2 - issue in MDN response condition
[
https://issues.apache.org/jira/browse/CAMEL-17829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-17829.
-
Resolution: Fixed
> camel-as2 - issue in MDN response condition
> ---
>
> Key: CAMEL-17829
> URL: https://issues.apache.org/jira/browse/CAMEL-17829
> Project: Camel
> Issue Type: Bug
> Components: camel-as2
>Reporter: João Miranda
>Assignee: Jono Morris
>Priority: Minor
> Fix For: 4.7.0
>
>
> The MDN implementation has a field status that can be used to tell the
> requester if the message was processed with success or if any error occurred.
> The default template has that field in {*}$dispositionType{*}.
>
> {noformat}
> private static final String DEFAULT_MDN_MESSAGE_TEMPLATE = "MDN for -\n"
>+ " Message ID:
> $requestHeaders[\"Message-Id\"]\n"
>+ " Subject:
> $requestHeaders[\"Subject\"]\n"
>+ " Date:
> $requestHeaders[\"Date\"]\n"
>+ " From:
> $requestHeaders[\"AS2-From\"]\n"
>+ " To:
> $requestHeaders[\"AS2-To\"]\n"
>+ " Received on:
> $responseHeaders[\"Date\"]\n"
>+ " Status:
> $dispositionType \n";{noformat}
>
>
> The issue is in the condition that determines if the MDN should be returned
> with success status or error status:
>
> {noformat}
> ResponseMDN.java
> if (AS2DispositionType.FAILED.getType()
> .equals(HttpMessageUtils.getHeaderValue(request,
> AS2Header.DISPOSITION_TYPE))) {...}{noformat}
> This condition is looking at the *request header* Disposition-Type which is
> not correct. If the requester sends this header with *failed* the MDN will be
> returned with failed status regardless of the execution status of the
> receiver.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-17829) camel-as2 - issue in MDN response condition
[
https://issues.apache.org/jira/browse/CAMEL-17829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-17829:
Fix Version/s: 4.7.0
(was: Future)
> camel-as2 - issue in MDN response condition
> ---
>
> Key: CAMEL-17829
> URL: https://issues.apache.org/jira/browse/CAMEL-17829
> Project: Camel
> Issue Type: Bug
> Components: camel-as2
>Reporter: João Miranda
>Assignee: Jono Morris
>Priority: Minor
> Fix For: 4.7.0
>
>
> The MDN implementation has a field status that can be used to tell the
> requester if the message was processed with success or if any error occurred.
> The default template has that field in {*}$dispositionType{*}.
>
> {noformat}
> private static final String DEFAULT_MDN_MESSAGE_TEMPLATE = "MDN for -\n"
>+ " Message ID:
> $requestHeaders[\"Message-Id\"]\n"
>+ " Subject:
> $requestHeaders[\"Subject\"]\n"
>+ " Date:
> $requestHeaders[\"Date\"]\n"
>+ " From:
> $requestHeaders[\"AS2-From\"]\n"
>+ " To:
> $requestHeaders[\"AS2-To\"]\n"
>+ " Received on:
> $responseHeaders[\"Date\"]\n"
>+ " Status:
> $dispositionType \n";{noformat}
>
>
> The issue is in the condition that determines if the MDN should be returned
> with success status or error status:
>
> {noformat}
> ResponseMDN.java
> if (AS2DispositionType.FAILED.getType()
> .equals(HttpMessageUtils.getHeaderValue(request,
> AS2Header.DISPOSITION_TYPE))) {...}{noformat}
> This condition is looking at the *request header* Disposition-Type which is
> not correct. If the requester sends this header with *failed* the MDN will be
> returned with failed status regardless of the execution status of the
> receiver.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20742) Support Vespa Vector Database
Andrea Cosentino created CAMEL-20742: Summary: Support Vespa Vector Database Key: CAMEL-20742 URL: https://issues.apache.org/jira/browse/CAMEL-20742 Project: Camel Issue Type: New Feature Reporter: Andrea Cosentino Fix For: 4.7.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20742) Support Vespa Vector Database
[ https://issues.apache.org/jira/browse/CAMEL-20742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino updated CAMEL-20742: - Fix Version/s: 4.x (was: 4.7.0) > Support Vespa Vector Database > - > > Key: CAMEL-20742 > URL: https://issues.apache.org/jira/browse/CAMEL-20742 > Project: Camel > Issue Type: New Feature >Reporter: Andrea Cosentino >Priority: Major > Fix For: 4.x > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20741) Support Chroma DB Vector database
Andrea Cosentino created CAMEL-20741: Summary: Support Chroma DB Vector database Key: CAMEL-20741 URL: https://issues.apache.org/jira/browse/CAMEL-20741 Project: Camel Issue Type: New Feature Reporter: Andrea Cosentino Assignee: Andrea Cosentino Fix For: 4.7.0 https://www.trychroma.com/ https://github.com/amikos-tech/chromadb-java-client -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-17829) camel-as2 - issue in MDN response condition
[
https://issues.apache.org/jira/browse/CAMEL-17829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jono Morris reassigned CAMEL-17829:
---
Assignee: Jono Morris
> camel-as2 - issue in MDN response condition
> ---
>
> Key: CAMEL-17829
> URL: https://issues.apache.org/jira/browse/CAMEL-17829
> Project: Camel
> Issue Type: Bug
> Components: camel-as2
>Reporter: João Miranda
>Assignee: Jono Morris
>Priority: Minor
> Fix For: Future
>
>
> The MDN implementation has a field status that can be used to tell the
> requester if the message was processed with success or if any error occurred.
> The default template has that field in {*}$dispositionType{*}.
>
> {noformat}
> private static final String DEFAULT_MDN_MESSAGE_TEMPLATE = "MDN for -\n"
>+ " Message ID:
> $requestHeaders[\"Message-Id\"]\n"
>+ " Subject:
> $requestHeaders[\"Subject\"]\n"
>+ " Date:
> $requestHeaders[\"Date\"]\n"
>+ " From:
> $requestHeaders[\"AS2-From\"]\n"
>+ " To:
> $requestHeaders[\"AS2-To\"]\n"
>+ " Received on:
> $responseHeaders[\"Date\"]\n"
>+ " Status:
> $dispositionType \n";{noformat}
>
>
> The issue is in the condition that determines if the MDN should be returned
> with success status or error status:
>
> {noformat}
> ResponseMDN.java
> if (AS2DispositionType.FAILED.getType()
> .equals(HttpMessageUtils.getHeaderValue(request,
> AS2Header.DISPOSITION_TYPE))) {...}{noformat}
> This condition is looking at the *request header* Disposition-Type which is
> not correct. If the requester sends this header with *failed* the MDN will be
> returned with failed status regardless of the execution status of the
> receiver.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-17829) camel-as2 - issue in MDN response condition
[
https://issues.apache.org/jira/browse/CAMEL-17829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844260#comment-17844260
]
Jono Morris commented on CAMEL-17829:
-
I think reading the disposition type from the HttpContext is the best way
forward so that Camel-as2 can continue to be improved.
> camel-as2 - issue in MDN response condition
> ---
>
> Key: CAMEL-17829
> URL: https://issues.apache.org/jira/browse/CAMEL-17829
> Project: Camel
> Issue Type: Bug
> Components: camel-as2
>Reporter: João Miranda
>Priority: Minor
> Fix For: Future
>
>
> The MDN implementation has a field status that can be used to tell the
> requester if the message was processed with success or if any error occurred.
> The default template has that field in {*}$dispositionType{*}.
>
> {noformat}
> private static final String DEFAULT_MDN_MESSAGE_TEMPLATE = "MDN for -\n"
>+ " Message ID:
> $requestHeaders[\"Message-Id\"]\n"
>+ " Subject:
> $requestHeaders[\"Subject\"]\n"
>+ " Date:
> $requestHeaders[\"Date\"]\n"
>+ " From:
> $requestHeaders[\"AS2-From\"]\n"
>+ " To:
> $requestHeaders[\"AS2-To\"]\n"
>+ " Received on:
> $responseHeaders[\"Date\"]\n"
>+ " Status:
> $dispositionType \n";{noformat}
>
>
> The issue is in the condition that determines if the MDN should be returned
> with success status or error status:
>
> {noformat}
> ResponseMDN.java
> if (AS2DispositionType.FAILED.getType()
> .equals(HttpMessageUtils.getHeaderValue(request,
> AS2Header.DISPOSITION_TYPE))) {...}{noformat}
> This condition is looking at the *request header* Disposition-Type which is
> not correct. If the requester sends this header with *failed* the MDN will be
> returned with failed status regardless of the execution status of the
> receiver.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-19358) camel-kafka - Kafka consumer is still able to consume message with keepOpen as true in ThrottlingExceptionRoutePolicy
[ https://issues.apache.org/jira/browse/CAMEL-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-19358: --- Assignee: Claus Ibsen > camel-kafka - Kafka consumer is still able to consume message with keepOpen > as true in ThrottlingExceptionRoutePolicy > - > > Key: CAMEL-19358 > URL: https://issues.apache.org/jira/browse/CAMEL-19358 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.18.3, 3.20.0 >Reporter: Jianbo Ma >Assignee: Claus Ibsen >Priority: Minor > > We have circuit breaker implementation in routes, and it is using > ThrottlingExceptionRoutePolicy. Previously we were using version 3.18.0, the > Kakfa consumer is not able to consume messages when keepOpen is true. However > there was an issue with version 3.18.0, which was that the consumer couldn't > be resumed after we changed the keepOpen to false, could be an issue related > to https://issues.apache.org/jira/browse/CAMEL-18688 . We tried version > 3.18.3 and 3.20.0, both versions have the same issue, Kafka consumer is able > to consume message even with keepOpen as true, while for the route with JMS > consumer, there is no such issue. > Thanks, > Jianbo -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19358) camel-kafka - Kafka consumer is still able to consume message with keepOpen as true in ThrottlingExceptionRoutePolicy
[ https://issues.apache.org/jira/browse/CAMEL-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844254#comment-17844254 ] Claus Ibsen commented on CAMEL-19358: - Yeah the code looks suspisius where suspend will exit the startPolling loop and resume will not get back into that loop. > camel-kafka - Kafka consumer is still able to consume message with keepOpen > as true in ThrottlingExceptionRoutePolicy > - > > Key: CAMEL-19358 > URL: https://issues.apache.org/jira/browse/CAMEL-19358 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.18.3, 3.20.0 >Reporter: Jianbo Ma >Priority: Minor > > We have circuit breaker implementation in routes, and it is using > ThrottlingExceptionRoutePolicy. Previously we were using version 3.18.0, the > Kakfa consumer is not able to consume messages when keepOpen is true. However > there was an issue with version 3.18.0, which was that the consumer couldn't > be resumed after we changed the keepOpen to false, could be an issue related > to https://issues.apache.org/jira/browse/CAMEL-18688 . We tried version > 3.18.3 and 3.20.0, both versions have the same issue, Kafka consumer is able > to consume message even with keepOpen as true, while for the route with JMS > consumer, there is no such issue. > Thanks, > Jianbo -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19972) camel-kafka manual commit configuration inconsistency
[
https://issues.apache.org/jira/browse/CAMEL-19972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844253#comment-17844253
]
Claus Ibsen commented on CAMEL-19972:
-
Can you try with latest 4.4.x or newer releases as we have improved kafka since
this was reported
> camel-kafka manual commit configuration inconsistency
> -
>
> Key: CAMEL-19972
> URL: https://issues.apache.org/jira/browse/CAMEL-19972
> Project: Camel
> Issue Type: Bug
> Components: camel-kafka
>Affects Versions: 3.18.5, 3.21.1
>Reporter: Sami Peltola
>Priority: Minor
> Labels: help-wanted
>
> h2. Expected behavior
> * Should not matter if manual commits are enabled component level or
> endpoint level, consumer should not commit automatically when
> autoCommitEnable is set to false
> h2. Actual behavior
> The behavior for manual commits is inconsistent at the moment (Test on Camel
> versions 3.18.5 and 3.21.1), depending on whether the KafkaComponent is
> configured on component or endpoint level
> * If configured on component level, will still automatically commit offsets
> back to broker (after records from a partition have been processed)
> * If configured on endpoint level, will never automatically commit offsets
> * autoCommitEnable is
> h3. Configuration of manual commit for Kafka client during startup
> During startup for Kafka component, Camel context will go through the
> following classes and methods while setting up manual commit configuration.
> h4. KafkaComponent
> [https://github.com/apache/camel/blob/camel-3.18.5/components/camel-kafka/src/main/java/org/apache/camel/component/kafka/KafkaComponent.java#L222]
> *Class:* org.apache.camel.component.kafka.KafkaComponent
> *Method:* doInit
>
> * When the component is being initialized, will check if
> configuration.isAllowManualCommit() is true AND kafkaManualCommitFactory is
> null
> ** If they are, will initialize kafkaManualCommitFactory as
> DefaultKafkaManualCommitFactory
> ** If not, will leave kafkaManualCommitFactory as null
>
> h4. CommitManagers
> [https://github.com/apache/camel/blob/camel-3.18.5/components/camel-kafka/src/main/java/org/apache/camel/component/kafka/consumer/CommitManagers.java#L32]
> *Class:* org.apache.camel.component.kafka.consumer.CommitManagers
> *Method:* createCommitManager
> * Called when initializing Consumer
> ** For clarity's sake, omitting Async-related logic
> ** If configuration.isAllowManualCommit() is true AND manualCommitFactory is
> instance of DefaultKafkaManualCommitFactory
> *** Will initialize SyncCommitManager
> *** Otherwise, will initialize NoopCommitManager
> h4. Summary
> * Configuring manual commits on component level still results in automatic
> commits when the changing partitions (or all records processed) since
> *SyncCommitManager* is configured
> ** allowManualCommit is true when calling *doInit* -> initializes
> kafkaManualCommitFactory as DefaultKafkaManualCommitFactory -> initilize
> commitManager as SyncCommitManager
> * If allowManualCommit is only configured on endpoint level, it will be
> false when invoking {*}doInit{*}, therefore leaving kafkaManualCommitFactory
> as null, resulting in NoopCommitManager in *createCommitManager*
>
> h2. Workaround
> * Configure manual commits on endpoint level
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20645) camel-jbang-plugin-k run command telemetry trait parameters ignored
[
https://issues.apache.org/jira/browse/CAMEL-20645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20645:
Fix Version/s: 4.x
> camel-jbang-plugin-k run command telemetry trait parameters ignored
> ---
>
> Key: CAMEL-20645
> URL: https://issues.apache.org/jira/browse/CAMEL-20645
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
>Affects Versions: 4.5.0
> Environment: Jbang version : 0.115.0
> Camel version: 4.5.0
> Camel k: 2.3.0-SNAPSHOT
>Reporter: Gaëlle Fournier
>Priority: Minor
> Fix For: 4.x
>
>
> When running the telemetry test from Camel K with jbang camel k plugin, the
> telemetry trait parameters are ignored in the generated Integration CRD.
> The jbang camel k command:
> {code}
> jbang run --deps=org.apache.camel:camel-jbang-plugin-k:4.5.0
> --deps=org.apache.camel.k:camel-k-crds:2.3.0-SNAPSHOT camel@apache/camel k
> run e2e/telemetry/files/rest-consumer.yaml --name rest-consumer -t
> telemetry.enabled=true -t
> telemetry.endpoint=http://opentelemetrycollector.otlp.svc.cluster.local:4317{code}
> will result in the following integration CRD configuration:
> {code:java}
> spec:
> flows:
> - rest:
> get:
> - path: /customers/{name}
> to: direct:start
> - from:
> steps:
> - log:
> message: get ${header.name}
> - setBody:
> simple: ${header.name} Doe
> uri: direct:start
> traits: {}
> status:
> dependencies:
> - camel:core
> - camel:direct
> - mvn:org.apache.camel.k:camel-k-runtime
> - mvn:org.apache.camel.quarkus:camel-quarkus-platform-http
> - mvn:org.apache.camel.quarkus:camel-quarkus-rest
> - mvn:org.apache.camel.quarkus:camel-quarkus-yaml-dsl{code}
>
> In comparaison the kamel command:
> {code:java}
> kamel run e2e/telemetry/files/rest-consumer.yaml --name rest-consumer -t
> telemetry.enabled=true -t
> telemetry.endpoint=http://opentelemetrycollector.otlp.svc.cluster.local:4317{code}
> will result in the following integration CRD configuration:
> {code:java}
> spec:
> flows:
> - rest:
> get:
> - path: /customers/{name}
> to: direct:start
> - from:
> steps:
> - log:
> message: get ${header.name}
> - setBody:
> simple: ${header.name} Doe
> uri: direct:start
> traits:
> addons:
> telemetry:
> enabled: true
> endpoint: http://opentelemetrycollector.otlp.svc.cluster.local:4317
> status:
> dependencies:
> - camel:core
> - camel:direct
> - mvn:org.apache.camel.k:camel-k-runtime
> - mvn:org.apache.camel.quarkus:camel-quarkus-opentelemetry
> - mvn:org.apache.camel.quarkus:camel-quarkus-platform-http
> - mvn:org.apache.camel.quarkus:camel-quarkus-rest
> - mvn:org.apache.camel.quarkus:camel-quarkus-yaml-dsl{code}
>
> Note: I did not test it but I suspect 4.4.x might be affected as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20645) camel-jbang-plugin-k run command telemetry trait parameters ignored
[
https://issues.apache.org/jira/browse/CAMEL-20645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844252#comment-17844252
]
Claus Ibsen commented on CAMEL-20645:
-
[~christophd] does the ck sub command need to be improved to generate metadata
for some of the traits, and if so would you work on that?
> camel-jbang-plugin-k run command telemetry trait parameters ignored
> ---
>
> Key: CAMEL-20645
> URL: https://issues.apache.org/jira/browse/CAMEL-20645
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
>Affects Versions: 4.5.0
> Environment: Jbang version : 0.115.0
> Camel version: 4.5.0
> Camel k: 2.3.0-SNAPSHOT
>Reporter: Gaëlle Fournier
>Priority: Minor
>
> When running the telemetry test from Camel K with jbang camel k plugin, the
> telemetry trait parameters are ignored in the generated Integration CRD.
> The jbang camel k command:
> {code}
> jbang run --deps=org.apache.camel:camel-jbang-plugin-k:4.5.0
> --deps=org.apache.camel.k:camel-k-crds:2.3.0-SNAPSHOT camel@apache/camel k
> run e2e/telemetry/files/rest-consumer.yaml --name rest-consumer -t
> telemetry.enabled=true -t
> telemetry.endpoint=http://opentelemetrycollector.otlp.svc.cluster.local:4317{code}
> will result in the following integration CRD configuration:
> {code:java}
> spec:
> flows:
> - rest:
> get:
> - path: /customers/{name}
> to: direct:start
> - from:
> steps:
> - log:
> message: get ${header.name}
> - setBody:
> simple: ${header.name} Doe
> uri: direct:start
> traits: {}
> status:
> dependencies:
> - camel:core
> - camel:direct
> - mvn:org.apache.camel.k:camel-k-runtime
> - mvn:org.apache.camel.quarkus:camel-quarkus-platform-http
> - mvn:org.apache.camel.quarkus:camel-quarkus-rest
> - mvn:org.apache.camel.quarkus:camel-quarkus-yaml-dsl{code}
>
> In comparaison the kamel command:
> {code:java}
> kamel run e2e/telemetry/files/rest-consumer.yaml --name rest-consumer -t
> telemetry.enabled=true -t
> telemetry.endpoint=http://opentelemetrycollector.otlp.svc.cluster.local:4317{code}
> will result in the following integration CRD configuration:
> {code:java}
> spec:
> flows:
> - rest:
> get:
> - path: /customers/{name}
> to: direct:start
> - from:
> steps:
> - log:
> message: get ${header.name}
> - setBody:
> simple: ${header.name} Doe
> uri: direct:start
> traits:
> addons:
> telemetry:
> enabled: true
> endpoint: http://opentelemetrycollector.otlp.svc.cluster.local:4317
> status:
> dependencies:
> - camel:core
> - camel:direct
> - mvn:org.apache.camel.k:camel-k-runtime
> - mvn:org.apache.camel.quarkus:camel-quarkus-opentelemetry
> - mvn:org.apache.camel.quarkus:camel-quarkus-platform-http
> - mvn:org.apache.camel.quarkus:camel-quarkus-rest
> - mvn:org.apache.camel.quarkus:camel-quarkus-yaml-dsl{code}
>
> Note: I did not test it but I suspect 4.4.x might be affected as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-17829) camel-as2 - issue in MDN response condition
[
https://issues.apache.org/jira/browse/CAMEL-17829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844247#comment-17844247
]
Claus Ibsen commented on CAMEL-17829:
-
Okay Jono, what do you recommend to do?
> camel-as2 - issue in MDN response condition
> ---
>
> Key: CAMEL-17829
> URL: https://issues.apache.org/jira/browse/CAMEL-17829
> Project: Camel
> Issue Type: Bug
> Components: camel-as2
>Reporter: João Miranda
>Priority: Minor
> Fix For: Future
>
>
> The MDN implementation has a field status that can be used to tell the
> requester if the message was processed with success or if any error occurred.
> The default template has that field in {*}$dispositionType{*}.
>
> {noformat}
> private static final String DEFAULT_MDN_MESSAGE_TEMPLATE = "MDN for -\n"
>+ " Message ID:
> $requestHeaders[\"Message-Id\"]\n"
>+ " Subject:
> $requestHeaders[\"Subject\"]\n"
>+ " Date:
> $requestHeaders[\"Date\"]\n"
>+ " From:
> $requestHeaders[\"AS2-From\"]\n"
>+ " To:
> $requestHeaders[\"AS2-To\"]\n"
>+ " Received on:
> $responseHeaders[\"Date\"]\n"
>+ " Status:
> $dispositionType \n";{noformat}
>
>
> The issue is in the condition that determines if the MDN should be returned
> with success status or error status:
>
> {noformat}
> ResponseMDN.java
> if (AS2DispositionType.FAILED.getType()
> .equals(HttpMessageUtils.getHeaderValue(request,
> AS2Header.DISPOSITION_TYPE))) {...}{noformat}
> This condition is looking at the *request header* Disposition-Type which is
> not correct. If the requester sends this header with *failed* the MDN will be
> returned with failed status regardless of the execution status of the
> receiver.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-17829) camel-as2 - issue in MDN response condition
[
https://issues.apache.org/jira/browse/CAMEL-17829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844237#comment-17844237
]
Jono Morris edited comment on CAMEL-17829 at 5/7/24 10:51 AM:
--
[~davsclaus] From the spec it seems the only thing that would cause a 'failure'
disposition is a client requesting a signed receipt with non-standard
Disposition-notification-options, e.g. something other than:
Disposition-notification-options:
signed-receipt-protocol=required,pkcs7-signature;
signed-receipt-micalg=required,sha1,md5
Camel-as2 doesn't seem to validate these options at all, e.g. assumes
pkcs7-signature and defaults to sha1, so such a failure will never occur.
So the failure MDN block could be removed as it's never used, or we can read
the attribute from HttpContext instead of the request in case disposition
handling is improved in future e.g.
if (AS2DispositionType.FAILED.getType()
.equals(coreContext.getAttribute(DISPOSITION_TYPE))) {
was (Author: jono):
[~davsclaus] From the spec it seems the only thing that would cause a 'failure'
disposition is a client requesting a signed receipt with non-standard
Disposition-notification-options, e.g. something other than:
Disposition-notification-options:
signed-receipt-protocol=required,pkcs7-signature;
signed-receipt-micalg=required,sha1,md5
Camel-as2 doesn't seem to validate these options at all, e.g. assumes
pkcs7-signature and defaults to sha1, so such a failure will never occur.
So the failure MDN block could probably be removed as it's never used.
> camel-as2 - issue in MDN response condition
> ---
>
> Key: CAMEL-17829
> URL: https://issues.apache.org/jira/browse/CAMEL-17829
> Project: Camel
> Issue Type: Bug
> Components: camel-as2
>Reporter: João Miranda
>Priority: Minor
> Fix For: Future
>
>
> The MDN implementation has a field status that can be used to tell the
> requester if the message was processed with success or if any error occurred.
> The default template has that field in {*}$dispositionType{*}.
>
> {noformat}
> private static final String DEFAULT_MDN_MESSAGE_TEMPLATE = "MDN for -\n"
>+ " Message ID:
> $requestHeaders[\"Message-Id\"]\n"
>+ " Subject:
> $requestHeaders[\"Subject\"]\n"
>+ " Date:
> $requestHeaders[\"Date\"]\n"
>+ " From:
> $requestHeaders[\"AS2-From\"]\n"
>+ " To:
> $requestHeaders[\"AS2-To\"]\n"
>+ " Received on:
> $responseHeaders[\"Date\"]\n"
>+ " Status:
> $dispositionType \n";{noformat}
>
>
> The issue is in the condition that determines if the MDN should be returned
> with success status or error status:
>
> {noformat}
> ResponseMDN.java
> if (AS2DispositionType.FAILED.getType()
> .equals(HttpMessageUtils.getHeaderValue(request,
> AS2Header.DISPOSITION_TYPE))) {...}{noformat}
> This condition is looking at the *request header* Disposition-Type which is
> not correct. If the requester sends this header with *failed* the MDN will be
> returned with failed status regardless of the execution status of the
> receiver.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-17829) camel-as2 - issue in MDN response condition
[
https://issues.apache.org/jira/browse/CAMEL-17829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844237#comment-17844237
]
Jono Morris commented on CAMEL-17829:
-
[~davsclaus] From the spec it seems the only thing that would cause a 'failure'
disposition is a client requesting a signed receipt with non-standard
Disposition-notification-options, e.g. something other than:
Disposition-notification-options:
signed-receipt-protocol=required,pkcs7-signature;
signed-receipt-micalg=required,sha1,md5
Camel-as2 doesn't seem to validate these options at all, e.g. assumes
pkcs7-signature and defaults to sha1, so such a failure will never occur.
So the failure MDN block could probably be removed as it's never used.
> camel-as2 - issue in MDN response condition
> ---
>
> Key: CAMEL-17829
> URL: https://issues.apache.org/jira/browse/CAMEL-17829
> Project: Camel
> Issue Type: Bug
> Components: camel-as2
>Reporter: João Miranda
>Priority: Minor
> Fix For: Future
>
>
> The MDN implementation has a field status that can be used to tell the
> requester if the message was processed with success or if any error occurred.
> The default template has that field in {*}$dispositionType{*}.
>
> {noformat}
> private static final String DEFAULT_MDN_MESSAGE_TEMPLATE = "MDN for -\n"
>+ " Message ID:
> $requestHeaders[\"Message-Id\"]\n"
>+ " Subject:
> $requestHeaders[\"Subject\"]\n"
>+ " Date:
> $requestHeaders[\"Date\"]\n"
>+ " From:
> $requestHeaders[\"AS2-From\"]\n"
>+ " To:
> $requestHeaders[\"AS2-To\"]\n"
>+ " Received on:
> $responseHeaders[\"Date\"]\n"
>+ " Status:
> $dispositionType \n";{noformat}
>
>
> The issue is in the condition that determines if the MDN should be returned
> with success status or error status:
>
> {noformat}
> ResponseMDN.java
> if (AS2DispositionType.FAILED.getType()
> .equals(HttpMessageUtils.getHeaderValue(request,
> AS2Header.DISPOSITION_TYPE))) {...}{noformat}
> This condition is looking at the *request header* Disposition-Type which is
> not correct. If the requester sends this header with *failed* the MDN will be
> returned with failed status regardless of the execution status of the
> receiver.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20740) Allow to configure multiple components of same type in application.properties
[ https://issues.apache.org/jira/browse/CAMEL-20740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844208#comment-17844208 ] Claus Ibsen commented on CAMEL-20740: - Yeah SB auto-configuration is a bit of challenge, where we would need to adjust all the starter to support this, or come up with some other way. > Allow to configure multiple components of same type in application.properties > - > > Key: CAMEL-20740 > URL: https://issues.apache.org/jira/browse/CAMEL-20740 > Project: Camel > Issue Type: New Feature > Components: camel-main >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > See if we can make it easier to define 2 JMS or 2+ SQL components with their > own configuration and do all of this via application.properties. > The default camel.component.sql is for the default component only. > So something > camel.component.mysql.alias=sql > camel.component.mysql.batch=123 > camel.component.oracle-db.alias=sql > camel.component.oracle-db.batch=444 > So the name of the component needs to use a non OOTB component name and have > an alias option that refers to the actual component. > This does impact tooling as they dont understand these "fake components" so > maybe we need to put this into another prefix to avoid confusion. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20728) camel-aws2s3 Stream Producer should support multipart loading
[ https://issues.apache.org/jira/browse/CAMEL-20728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-20728. - Resolution: Fixed Thanks for the PR > camel-aws2s3 Stream Producer should support multipart loading > - > > Key: CAMEL-20728 > URL: https://issues.apache.org/jira/browse/CAMEL-20728 > Project: Camel > Issue Type: New Feature > Components: camel-aws >Affects Versions: 4.5.0 >Reporter: Benjamin BONNET >Priority: Major > Fix For: 4.7.0 > > > AWS2S3 Producer comes in two flavours: AWS2S3Producer and > AWS2S3StreamUploadProducer. > * AWS2S3Producer supports S3 multipart upload: exchange data will be > chunked into parts, parts will be sent separately to S3 and will be > aggregated into one file. > * AWS2S3StreamUploadProducer supports message streaming: incoming messages > are aggregated into a buffer that will be sent as one file to S3, as soon as > some condition is true (number of messages / size /timeout). > Unfortunately, AWS2S3StreamUploadProducer, although it is able to break a > huge flow of messages into parts (which is great for some use cases), is not > able to manage S3 multipart upload. So if you need to aggregate lots of > messages into one big file on S3 side, that means the producer will have to > send that message batch in one request (actually, a single part multipart > request if you look at implementation). If the volume is huge, that will blow > up jvm heap. > So we propose to add multi-part support to AWS2S3StreamUploadProducer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20680) camel-kafka: reduce KafkaBreakOnFirstErrorSeekIssueIT test duration
[ https://issues.apache.org/jira/browse/CAMEL-20680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-20680: --- Assignee: JV Singh > camel-kafka: reduce KafkaBreakOnFirstErrorSeekIssueIT test duration > --- > > Key: CAMEL-20680 > URL: https://issues.apache.org/jira/browse/CAMEL-20680 > Project: Camel > Issue Type: Task > Components: camel-kafka >Affects Versions: 4.4.1, 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: JV Singh >Priority: Major > Labels: help-wanted > Fix For: 4.x > > Attachments: image-2024-05-01-08-13-28-056.png > > > The test KafkaBreakOnFirstErrorSeekIssueIT takes a very long time to run. > This consumes unnecessary resources from ASF CI. We should investigate how to > improve it to it runs quickly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20722) camel-kafka: reduce KafkaBreakOnFirstError tests are too unreliable for CIs
[ https://issues.apache.org/jira/browse/CAMEL-20722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-20722: --- Assignee: JV Singh > camel-kafka: reduce KafkaBreakOnFirstError tests are too unreliable for CIs > --- > > Key: CAMEL-20722 > URL: https://issues.apache.org/jira/browse/CAMEL-20722 > Project: Camel > Issue Type: Task > Components: camel-kafka >Affects Versions: 4.4.1, 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: JV Singh >Priority: Major > Labels: help-wanted > Fix For: 4.x > > Attachments: build-log.txt > > > All the tests named KafkaBreakOnFirst.*IT are unreliable when running on the > CI. They fail often, sometimes in multiple archs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20728) camel-aws2s3 Stream Producer should support multipart loading
[ https://issues.apache.org/jira/browse/CAMEL-20728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20728: Fix Version/s: 4.7.0 > camel-aws2s3 Stream Producer should support multipart loading > - > > Key: CAMEL-20728 > URL: https://issues.apache.org/jira/browse/CAMEL-20728 > Project: Camel > Issue Type: New Feature > Components: camel-aws >Affects Versions: 4.5.0 >Reporter: Benjamin BONNET >Priority: Major > Fix For: 4.7.0 > > > AWS2S3 Producer comes in two flavours: AWS2S3Producer and > AWS2S3StreamUploadProducer. > * AWS2S3Producer supports S3 multipart upload: exchange data will be > chunked into parts, parts will be sent separately to S3 and will be > aggregated into one file. > * AWS2S3StreamUploadProducer supports message streaming: incoming messages > are aggregated into a buffer that will be sent as one file to S3, as soon as > some condition is true (number of messages / size /timeout). > Unfortunately, AWS2S3StreamUploadProducer, although it is able to break a > huge flow of messages into parts (which is great for some use cases), is not > able to manage S3 multipart upload. So if you need to aggregate lots of > messages into one big file on S3 side, that means the producer will have to > send that message batch in one request (actually, a single part multipart > request if you look at implementation). If the volume is huge, that will blow > up jvm heap. > So we propose to add multi-part support to AWS2S3StreamUploadProducer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
