[jira] [Commented] (CAMEL-17620) Document data type in body from the endpoints of each component
[ https://issues.apache.org/jira/browse/CAMEL-17620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489272#comment-17489272 ] Tadayoshi Sato commented on CAMEL-17620: Yes, agreed. We should start from Kamelets docs. > Document data type in body from the endpoints of each component > --- > > Key: CAMEL-17620 > URL: https://issues.apache.org/jira/browse/CAMEL-17620 > Project: Camel > Issue Type: Task > Components: documentation >Affects Versions: 3.15.0 >Reporter: Tadayoshi Sato >Priority: Major > > I sometimes see users complaining that it is not clear about what data type > they can expect from an endpoint for further processing in the route. > The endpoint parameters are well documented already but the data type each > endpoint should return is rarely documented, for example: > https://camel.apache.org/components/3.15.x/twitter-search-component.html > It would be great if we can find some way to automate the documentation of > the data type an endpoint returns, or at least document them manually. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-17620) Document data type in body from the endpoints of each component
[ https://issues.apache.org/jira/browse/CAMEL-17620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489269#comment-17489269 ] Claus Ibsen commented on CAMEL-17620: - Its more important to document the kamelets, they are the higher level building blocks. > Document data type in body from the endpoints of each component > --- > > Key: CAMEL-17620 > URL: https://issues.apache.org/jira/browse/CAMEL-17620 > Project: Camel > Issue Type: Task > Components: documentation >Affects Versions: 3.15.0 >Reporter: Tadayoshi Sato >Priority: Major > > I sometimes see users complaining that it is not clear about what data type > they can expect from an endpoint for further processing in the route. > The endpoint parameters are well documented already but the data type each > endpoint should return is rarely documented, for example: > https://camel.apache.org/components/3.15.x/twitter-search-component.html > It would be great if we can find some way to automate the documentation of > the data type an endpoint returns, or at least document them manually. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (CAMEL-12823) Create a LINE component
[ https://issues.apache.org/jira/browse/CAMEL-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tadayoshi Sato closed CAMEL-12823. -- Resolution: Won't Do > Create a LINE component > --- > > Key: CAMEL-12823 > URL: https://issues.apache.org/jira/browse/CAMEL-12823 > Project: Camel > Issue Type: New Feature >Reporter: Tadayoshi Sato >Assignee: Tadayoshi Sato >Priority: Minor > Fix For: Future > > > [LINE|https://developers.line.me/en/] is the most popular mobile messaging > service in Japan. I will try to create a component for handling the SDKs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-12823) Create a LINE component
[ https://issues.apache.org/jira/browse/CAMEL-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489247#comment-17489247 ] Tadayoshi Sato commented on CAMEL-12823: At this moment I lost interest in developing a component for that service. Let me close it. > Create a LINE component > --- > > Key: CAMEL-12823 > URL: https://issues.apache.org/jira/browse/CAMEL-12823 > Project: Camel > Issue Type: New Feature >Reporter: Tadayoshi Sato >Assignee: Tadayoshi Sato >Priority: Minor > Fix For: Future > > > [LINE|https://developers.line.me/en/] is the most popular mobile messaging > service in Japan. I will try to create a component for handling the SDKs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17620) Document data type in body from the endpoints of each component
Tadayoshi Sato created CAMEL-17620: -- Summary: Document data type in body from the endpoints of each component Key: CAMEL-17620 URL: https://issues.apache.org/jira/browse/CAMEL-17620 Project: Camel Issue Type: Task Components: documentation Affects Versions: 3.15.0 Reporter: Tadayoshi Sato I sometimes see users complaining that it is not clear about what data type they can expect from an endpoint for further processing in the route. The endpoint parameters are well documented already but the data type each endpoint should return is rarely documented, for example: https://camel.apache.org/components/3.15.x/twitter-search-component.html It would be great if we can find some way to automate the documentation of the data type an endpoint returns, or at least document them manually. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17619) Remove the superfluous json-simple dependency from the Slack component
Peter Palaga created CAMEL-17619: Summary: Remove the superfluous json-simple dependency from the Slack component Key: CAMEL-17619 URL: https://issues.apache.org/jira/browse/CAMEL-17619 Project: Camel Issue Type: Task Reporter: Peter Palaga Assignee: Peter Palaga There is no trace of org.json.simple in the Slack component anymore. It used to be utilized for json parsing in the past. Here the last occurrence was removed: https://github.com/apache/camel/commit/cfd9ea1e726151922e0c5f93c2b42128cb0c59d2#diff-ade5607d95deef18f4077538b733120e3e1c038c211c4ead4fe720f37acec322 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17618) camel-ref: only add the endpoint into camelContext when not exist
Freeman Yue Fang created CAMEL-17618:
Summary: camel-ref: only add the endpoint into camelContext when
not exist
Key: CAMEL-17618
URL: https://issues.apache.org/jira/browse/CAMEL-17618
Project: Camel
Issue Type: Bug
Reporter: Freeman Yue Fang
Currently camel-ref endpoint always adds the underlying endpoint like
getCamelContext().addEndpoint(getEndpoint().getEndpointUri(), endpoint);
We should check if it exists or not firstly like
if (getCamelContext().getEndpoint(getEndpoint().getEndpointUri()) ==
null) {
getCamelContext().addEndpoint(getEndpoint().getEndpointUri(),
endpoint);
}
Because if we re-add the same endpoint, this endpoint actually will be stopped
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (CAMEL-17618) camel-ref: only add the endpoint into camelContext when not exist
[
https://issues.apache.org/jira/browse/CAMEL-17618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang reassigned CAMEL-17618:
Assignee: Freeman Yue Fang
> camel-ref: only add the endpoint into camelContext when not exist
> -
>
> Key: CAMEL-17618
> URL: https://issues.apache.org/jira/browse/CAMEL-17618
> Project: Camel
> Issue Type: Bug
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
>
> Currently camel-ref endpoint always adds the underlying endpoint like
> getCamelContext().addEndpoint(getEndpoint().getEndpointUri(), endpoint);
> We should check if it exists or not firstly like
> if (getCamelContext().getEndpoint(getEndpoint().getEndpointUri()) ==
> null) {
>getCamelContext().addEndpoint(getEndpoint().getEndpointUri(),
> endpoint);
>}
> Because if we re-add the same endpoint, this endpoint actually will be stopped
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CAMEL-17618) camel-ref: only add the endpoint into camelContext when not exist
[
https://issues.apache.org/jira/browse/CAMEL-17618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang updated CAMEL-17618:
-
Fix Version/s: 3.16.0
Affects Version/s: 3.15.0
> camel-ref: only add the endpoint into camelContext when not exist
> -
>
> Key: CAMEL-17618
> URL: https://issues.apache.org/jira/browse/CAMEL-17618
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.15.0
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.16.0
>
>
> Currently camel-ref endpoint always adds the underlying endpoint like
> getCamelContext().addEndpoint(getEndpoint().getEndpointUri(), endpoint);
> We should check if it exists or not firstly like
> if (getCamelContext().getEndpoint(getEndpoint().getEndpointUri()) ==
> null) {
>getCamelContext().addEndpoint(getEndpoint().getEndpointUri(),
> endpoint);
>}
> Because if we re-add the same endpoint, this endpoint actually will be stopped
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CAMEL-17598) camel-bindy: Handle parse failures
[
https://issues.apache.org/jira/browse/CAMEL-17598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488980#comment-17488980
]
Jeremy Ross commented on CAMEL-17598:
-
I think that solution probably provides the best flexibility. But I suspect the
use of options I described would cover the vast majority of uses cases and is
obviously much simpler.
I'm kinda liking the idea of having both of these solutions. The ability to set
options to define simpler parse failure behavior, and ParseErrorHandler for
ultimate flexibility.
> camel-bindy: Handle parse failures
> --
>
> Key: CAMEL-17598
> URL: https://issues.apache.org/jira/browse/CAMEL-17598
> Project: Camel
> Issue Type: New Feature
> Components: camel-bindy
>Affects Versions: 3.14.1
>Reporter: Jeremy Ross
>Priority: Minor
> Fix For: 3.x
>
>
> If bindy fails to parse a value, say a date, an exception is thrown and the
> entire unmarshal operation is aborted. It would be nice if the exception
> could be handled and processing could resume. We'd probably also want a way
> to specify a default value in the case of a parse failure.
> Here are some choices that need to be made:
> * A way to indicate unmarshaling should resume in the event of a parse
> failure. Where would this live? Options are at the component option level,
> {{@CsvRecord}} level, and {{@DataField}} level. Maybe all of these with each
> one successively overriding the higher level setting. But maybe that's too
> complex. What would this be called? {{continueOnParseFailure}}? Is this even
> the right concept?
> * A way to specify a default value to use when a parse fails. {{@DataField}}
> already has a {{defaultValue}} element, so maybe we use this value in the
> event of a failure. If {{defaultValue}} is not set, it could default to null
> or the default value for a primitive type.
> Zulip chat:
> https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Bindy.20continue.20on.20parse.20exception
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CAMEL-17611) Allow to create a Route from a route template in XML and YAML
[
https://issues.apache.org/jira/browse/CAMEL-17611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488963#comment-17488963
]
Nicolas Filotto commented on CAMEL-17611:
-
The related PR https://github.com/apache/camel/pull/6903
> Allow to create a Route from a route template in XML and YAML
> -
>
> Key: CAMEL-17611
> URL: https://issues.apache.org/jira/browse/CAMEL-17611
> Project: Camel
> Issue Type: Improvement
> Components: came-core
>Reporter: Nicolas Filotto
>Assignee: Nicolas Filotto
>Priority: Major
> Fix For: 3.16.0
>
>
> With the existing code it is possible to create a route from a route template
> thanks to TemplatedRouteBuilder with a pure Java code or simply with a
> Kamelet. However in some particular cases it could be interesting to be able
> to create routes from a route template from a pure XML or YAML file
> especially for camel users that don't want to use Kamelets and write Java
> code.
>
> So for example, following XML snippet would allow to instantiate a route
> whose id is "my-route" from the route template "myTemplate" with the 2
> parameters "for" and "bar" and the bean "myBean".
> {code:java}
>
>
>
> type="#class:org.apache.camel.spring.routebuilder.MySpecialBean">
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CAMEL-17617) Specify minimal Java version in Jbang script
Aurélien Pupier created CAMEL-17617:
---
Summary: Specify minimal Java version in Jbang script
Key: CAMEL-17617
URL: https://issues.apache.org/jira/browse/CAMEL-17617
Project: Camel
Issue Type: Improvement
Components: camel-jbang
Affects Versions: 3.15.0
Reporter: Aurélien Pupier
jbang is using the defautl jvm that it finds. it can result to this kind of
error:
{noformat}
jbang -Dcamel.jbang.version=3.15.0 camel@apache/camel run test.yaml
--max-messages=10 --logging-level=info --reload
[jcordes@jcordes ~]$ jbang -Dcamel.jbang.version=3.15.0 camel@apache/camel run
test.yaml --max-messages=10 --logging-level=info --reload
[jbang] Building jar...
/home/jcordes/.jbang/cache/urls/f20491f9ebc0e16d2fca028eb3d4f03aafdf8cd62b8af1a9d1730bfe382d8165/CamelJBang.java:28:
error: cannot access CamelJBangMain
import org.apache.camel.dsl.jbang.core.commands.CamelJBangMain;
^
bad class file:
/home/jcordes/.m2/repository/org/apache/camel/camel-jbang-core/3.15.0/camel-jbang-core-3.15.0.jar(org/apache/camel/dsl/jbang/core/commands/CamelJBangMain.class)
class file has wrong version 55.0, should be 52.0
Please remove or make sure it appears in the correct subdirectory of the
classpath.
[jbang] [ERROR] Error during compile
[jbang] Run with --verbose for more details
{noformat}
the minimal java version can be specified
https://www.jbang.dev/documentation/guide/latest/javaversions.html#managing-jdks
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CAMEL-17615) camel-kafka: cleanup Kafka client warnings
[
https://issues.apache.org/jira/browse/CAMEL-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488738#comment-17488738
]
Otavio Rodolfo Piske commented on CAMEL-17615:
--
For Camel Kafka no, we have in the code:
[https://github.com/apache/camel/blob/main/components/camel-kafka/src/main/java/org/apache/camel/component/kafka/KafkaConfiguration.java#L360-L488.]
I think the auto-generated might be for vertx-kafka (but I haven't checked).
> camel-kafka: cleanup Kafka client warnings
> --
>
> Key: CAMEL-17615
> URL: https://issues.apache.org/jira/browse/CAMEL-17615
> Project: Camel
> Issue Type: Improvement
> Components: camel-kafka
>Affects Versions: 3.11.5, 3.14.0
>Reporter: Otavio Rodolfo Piske
>Priority: Minor
> Fix For: 3.16.0
>
>
> There are several warnings about unrecognized configurations when the Kafka
> client starts. We should clean them up.
> For example:
>
> {code:java}
> 2022-01-17 06:37:49.634 WARN 28548 --- [r-transactions]]
> o.a.k.clients.consumer.ConsumerConfig : The configuration
> 'specific.avro.reader' was supplied but isn't a known config.
> 2022-01-17 06:37:49.634 WARN 28548 --- [r-transactions]]
> o.a.k.clients.consumer.ConsumerConfig : The configuration
> 'specific.avro.reader' was supplied but isn't a known config.
> 2022-01-17 06:37:49.635 WARN 28548 --- [r-transactions]]
> o.a.k.clients.consumer.ConsumerConfig : The configuration
> 'sasl.kerberos.principal.to.local.rules' was supplied but isn't a known
> config.
> 2022-01-17 06:37:49.635 WARN 28548 --- [r-transactions]]
> o.a.k.clients.consumer.ConsumerConfig : The configuration
> 'sasl.kerberos.principal.to.local.rules' was supplied but isn't a known
> config.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CAMEL-11834) provide automated tests for Camel examples
[ https://issues.apache.org/jira/browse/CAMEL-11834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488724#comment-17488724 ] Claus Ibsen commented on CAMEL-11834: - Its a mix of different thing - some are community contributed - others are a way to demonstrate a feature in Camel or to have quick demo of running Camel with main / or something. > provide automated tests for Camel examples > -- > > Key: CAMEL-11834 > URL: https://issues.apache.org/jira/browse/CAMEL-11834 > Project: Camel > Issue Type: Task > Components: examples >Affects Versions: 2.19.3 >Reporter: Aurélien Pupier >Priority: Minor > Fix For: 3.x > > Time Spent: 20m > Remaining Estimate: 0h > > currently someone need to check manually that everything is fine. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CAMEL-17614) Be able to run infinispan spring-boot example out of the box
[ https://issues.apache.org/jira/browse/CAMEL-17614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17614: Fix Version/s: 3.16.0 > Be able to run infinispan spring-boot example out of the box > > > Key: CAMEL-17614 > URL: https://issues.apache.org/jira/browse/CAMEL-17614 > Project: Camel > Issue Type: Task > Components: camel-spring-boot, examples >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > Fix For: 3.16.0 > > > currently the camel-spring-boot infinispan exmaple requires a separate > running Infinispan server. > I think it's better to be able to run this example OOTB, like start a docker > Infinispan server image and create the "default" cacheName if required(since > the default cache doesn't exist in latest Infinispan server ) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-17615) camel-kafka: cleanup Kafka client warnings
[
https://issues.apache.org/jira/browse/CAMEL-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488723#comment-17488723
]
Claus Ibsen commented on CAMEL-17615:
-
Dont we use a maven plugin that generates the kafka configuration options, or
was this only done for the vert-kafka component?
> camel-kafka: cleanup Kafka client warnings
> --
>
> Key: CAMEL-17615
> URL: https://issues.apache.org/jira/browse/CAMEL-17615
> Project: Camel
> Issue Type: Improvement
> Components: camel-kafka
>Affects Versions: 3.11.5, 3.14.0
>Reporter: Otavio Rodolfo Piske
>Priority: Minor
> Fix For: 3.16.0
>
>
> There are several warnings about unrecognized configurations when the Kafka
> client starts. We should clean them up.
> For example:
>
> {code:java}
> 2022-01-17 06:37:49.634 WARN 28548 --- [r-transactions]]
> o.a.k.clients.consumer.ConsumerConfig : The configuration
> 'specific.avro.reader' was supplied but isn't a known config.
> 2022-01-17 06:37:49.634 WARN 28548 --- [r-transactions]]
> o.a.k.clients.consumer.ConsumerConfig : The configuration
> 'specific.avro.reader' was supplied but isn't a known config.
> 2022-01-17 06:37:49.635 WARN 28548 --- [r-transactions]]
> o.a.k.clients.consumer.ConsumerConfig : The configuration
> 'sasl.kerberos.principal.to.local.rules' was supplied but isn't a known
> config.
> 2022-01-17 06:37:49.635 WARN 28548 --- [r-transactions]]
> o.a.k.clients.consumer.ConsumerConfig : The configuration
> 'sasl.kerberos.principal.to.local.rules' was supplied but isn't a known
> config.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CAMEL-17615) camel-kafka: cleanup Kafka client warnings
[
https://issues.apache.org/jira/browse/CAMEL-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-17615:
Fix Version/s: 3.16.0
> camel-kafka: cleanup Kafka client warnings
> --
>
> Key: CAMEL-17615
> URL: https://issues.apache.org/jira/browse/CAMEL-17615
> Project: Camel
> Issue Type: Improvement
> Components: camel-kafka
>Affects Versions: 3.11.5, 3.14.0
>Reporter: Otavio Rodolfo Piske
>Priority: Minor
> Fix For: 3.16.0
>
>
> There are several warnings about unrecognized configurations when the Kafka
> client starts. We should clean them up.
> For example:
>
> {code:java}
> 2022-01-17 06:37:49.634 WARN 28548 --- [r-transactions]]
> o.a.k.clients.consumer.ConsumerConfig : The configuration
> 'specific.avro.reader' was supplied but isn't a known config.
> 2022-01-17 06:37:49.634 WARN 28548 --- [r-transactions]]
> o.a.k.clients.consumer.ConsumerConfig : The configuration
> 'specific.avro.reader' was supplied but isn't a known config.
> 2022-01-17 06:37:49.635 WARN 28548 --- [r-transactions]]
> o.a.k.clients.consumer.ConsumerConfig : The configuration
> 'sasl.kerberos.principal.to.local.rules' was supplied but isn't a known
> config.
> 2022-01-17 06:37:49.635 WARN 28548 --- [r-transactions]]
> o.a.k.clients.consumer.ConsumerConfig : The configuration
> 'sasl.kerberos.principal.to.local.rules' was supplied but isn't a known
> config.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CAMEL-17616) JdbcAggregationRepository will not start if it contains too many exchanges
[ https://issues.apache.org/jira/browse/CAMEL-17616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17616: Fix Version/s: 3.16.0 > JdbcAggregationRepository will not start if it contains too many exchanges > --- > > Key: CAMEL-17616 > URL: https://issues.apache.org/jira/browse/CAMEL-17616 > Project: Camel > Issue Type: Improvement > Components: camel-sql >Affects Versions: 3.11.2 >Reporter: Benjamin BONNET >Priority: Minor > Fix For: 3.16.0 > > > Hi, > We are using a JdbcAggregationRepository with a transactional Datasource. > When JdbcAggregationRepository is started, if its table contains lots of > rows, a transaction timeout may occur and make it fail to start. > Actually, when repo starts, doStart method is invoked, that method calls > getKeys() and iterates over every row in order to count them, which may be > quite long if repo contains millions of rows. > In order to avoid that issue, count could be implemented directly in the SQL > query. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CAMEL-17612) camel google functions documentation shows consumer example instead of producer
[
https://issues.apache.org/jira/browse/CAMEL-17612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-17612:
Component/s: documentation
> camel google functions documentation shows consumer example instead of
> producer
>
>
> Key: CAMEL-17612
> URL: https://issues.apache.org/jira/browse/CAMEL-17612
> Project: Camel
> Issue Type: Task
> Components: documentation
>Affects Versions: 3.14.1
>Reporter: Zineb Bendhiba
>Priority: Minor
> Fix For: 3.16.0
>
>
> The official documentation of Camel Google Cloud Functions component says
> that the component is supported for Producer only.
> However, this is a consumer example shown in the documentation
> {code:java}
> from("google-functions://myCamelFunction?project=myProject&location=us-central1&operation=callFunction&serviceAccountKey=/home/user/Downloads/my-key.json")
>
> .to("direct:test");{code}
> There's something wrong with the doc.
> [https://camel.apache.org/components/3.14.x/google-functions-component.html]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CAMEL-17612) camel google functions documentation shows consumer example instead of producer
[
https://issues.apache.org/jira/browse/CAMEL-17612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-17612:
Priority: Minor (was: Major)
> camel google functions documentation shows consumer example instead of
> producer
>
>
> Key: CAMEL-17612
> URL: https://issues.apache.org/jira/browse/CAMEL-17612
> Project: Camel
> Issue Type: Task
>Affects Versions: 3.14.1
>Reporter: Zineb Bendhiba
>Priority: Minor
>
> The official documentation of Camel Google Cloud Functions component says
> that the component is supported for Producer only.
> However, this is a consumer example shown in the documentation
> {code:java}
> from("google-functions://myCamelFunction?project=myProject&location=us-central1&operation=callFunction&serviceAccountKey=/home/user/Downloads/my-key.json")
>
> .to("direct:test");{code}
> There's something wrong with the doc.
> [https://camel.apache.org/components/3.14.x/google-functions-component.html]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CAMEL-17612) camel google functions documentation shows consumer example instead of producer
[
https://issues.apache.org/jira/browse/CAMEL-17612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-17612:
Issue Type: Task (was: Bug)
> camel google functions documentation shows consumer example instead of
> producer
>
>
> Key: CAMEL-17612
> URL: https://issues.apache.org/jira/browse/CAMEL-17612
> Project: Camel
> Issue Type: Task
>Affects Versions: 3.14.1
>Reporter: Zineb Bendhiba
>Priority: Major
>
> The official documentation of Camel Google Cloud Functions component says
> that the component is supported for Producer only.
> However, this is a consumer example shown in the documentation
> {code:java}
> from("google-functions://myCamelFunction?project=myProject&location=us-central1&operation=callFunction&serviceAccountKey=/home/user/Downloads/my-key.json")
>
> .to("direct:test");{code}
> There's something wrong with the doc.
> [https://camel.apache.org/components/3.14.x/google-functions-component.html]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CAMEL-17612) camel google functions documentation shows consumer example instead of producer
[
https://issues.apache.org/jira/browse/CAMEL-17612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-17612:
Fix Version/s: 3.16.0
> camel google functions documentation shows consumer example instead of
> producer
>
>
> Key: CAMEL-17612
> URL: https://issues.apache.org/jira/browse/CAMEL-17612
> Project: Camel
> Issue Type: Task
>Affects Versions: 3.14.1
>Reporter: Zineb Bendhiba
>Priority: Minor
> Fix For: 3.16.0
>
>
> The official documentation of Camel Google Cloud Functions component says
> that the component is supported for Producer only.
> However, this is a consumer example shown in the documentation
> {code:java}
> from("google-functions://myCamelFunction?project=myProject&location=us-central1&operation=callFunction&serviceAccountKey=/home/user/Downloads/my-key.json")
>
> .to("direct:test");{code}
> There's something wrong with the doc.
> [https://camel.apache.org/components/3.14.x/google-functions-component.html]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CAMEL-17613) Race condition in AggregateProcessor with Jdbc Repository
[ https://issues.apache.org/jira/browse/CAMEL-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488721#comment-17488721 ] Claus Ibsen commented on CAMEL-17613: - Oh that is a great analysis. > Race condition in AggregateProcessor with Jdbc Repository > - > > Key: CAMEL-17613 > URL: https://issues.apache.org/jira/browse/CAMEL-17613 > Project: Camel > Issue Type: Bug > Components: camel-core, camel-sql >Affects Versions: 3.11.2 >Reporter: Benjamin BONNET >Priority: Major > > Hi, > using aggregate with a JdbcAggregationRepository, we are encountering a race > condition that may leave a completed exchange in completed table even after > that completed exchange has been sent. Unfortunately, that leads to > duplicates since recovery task will eventually try and recover it. > Normally, when the exchange completes, it is deleted from repo exchange table > and inserted into repo completed exchange table. Then exchange is sent and > deleted from repo completed exchange table. > But, due to the fact those two actions are run by different threads (and in > different transactions) that order may vary. > > Here is a normal sequence : > AggregateProcessor.doProcess > doAggregation > doAggregationComplete > onCompletion > JdbcAggregationRepository.remove : => INSERT ... INTO _completed > onSubmitCompletion > AggregateOnCompletion.onComplete (via executorService) > JdbcAggregationRepository.confirm : => DELETE FROM _completed > With the use of executorService, confirm is run by another thread and may > commit before remove commits. Eventually, when that occurs, one can check > that DELETE statement returns 0 (number of deleted rows) instead of 1. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-17616) JdbcAggregationRepository will not start if it contains too many exchanges
[ https://issues.apache.org/jira/browse/CAMEL-17616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488708#comment-17488708 ] Claus Ibsen commented on CAMEL-17616: - You are welcome to send a PR to count the keys in a faster way > JdbcAggregationRepository will not start if it contains too many exchanges > --- > > Key: CAMEL-17616 > URL: https://issues.apache.org/jira/browse/CAMEL-17616 > Project: Camel > Issue Type: Bug > Components: camel-sql >Affects Versions: 3.11.2 >Reporter: Benjamin BONNET >Priority: Major > > Hi, > We are using a JdbcAggregationRepository with a transactional Datasource. > When JdbcAggregationRepository is started, if its table contains lots of > rows, a transaction timeout may occur and make it fail to start. > Actually, when repo starts, doStart method is invoked, that method calls > getKeys() and iterates over every row in order to count them, which may be > quite long if repo contains millions of rows. > In order to avoid that issue, count could be implemented directly in the SQL > query. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CAMEL-17616) JdbcAggregationRepository will not start if it contains too many exchanges
[ https://issues.apache.org/jira/browse/CAMEL-17616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17616: Priority: Minor (was: Major) > JdbcAggregationRepository will not start if it contains too many exchanges > --- > > Key: CAMEL-17616 > URL: https://issues.apache.org/jira/browse/CAMEL-17616 > Project: Camel > Issue Type: Improvement > Components: camel-sql >Affects Versions: 3.11.2 >Reporter: Benjamin BONNET >Priority: Minor > > Hi, > We are using a JdbcAggregationRepository with a transactional Datasource. > When JdbcAggregationRepository is started, if its table contains lots of > rows, a transaction timeout may occur and make it fail to start. > Actually, when repo starts, doStart method is invoked, that method calls > getKeys() and iterates over every row in order to count them, which may be > quite long if repo contains millions of rows. > In order to avoid that issue, count could be implemented directly in the SQL > query. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CAMEL-17616) JdbcAggregationRepository will not start if it contains too many exchanges
[ https://issues.apache.org/jira/browse/CAMEL-17616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17616: Issue Type: Improvement (was: Bug) > JdbcAggregationRepository will not start if it contains too many exchanges > --- > > Key: CAMEL-17616 > URL: https://issues.apache.org/jira/browse/CAMEL-17616 > Project: Camel > Issue Type: Improvement > Components: camel-sql >Affects Versions: 3.11.2 >Reporter: Benjamin BONNET >Priority: Major > > Hi, > We are using a JdbcAggregationRepository with a transactional Datasource. > When JdbcAggregationRepository is started, if its table contains lots of > rows, a transaction timeout may occur and make it fail to start. > Actually, when repo starts, doStart method is invoked, that method calls > getKeys() and iterates over every row in order to count them, which may be > quite long if repo contains millions of rows. > In order to avoid that issue, count could be implemented directly in the SQL > query. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17616) JdbcAggregationRepository will not start if it contains too many exchanges
Benjamin BONNET created CAMEL-17616: --- Summary: JdbcAggregationRepository will not start if it contains too many exchanges Key: CAMEL-17616 URL: https://issues.apache.org/jira/browse/CAMEL-17616 Project: Camel Issue Type: Bug Components: camel-sql Affects Versions: 3.11.2 Reporter: Benjamin BONNET Hi, We are using a JdbcAggregationRepository with a transactional Datasource. When JdbcAggregationRepository is started, if its table contains lots of rows, a transaction timeout may occur and make it fail to start. Actually, when repo starts, doStart method is invoked, that method calls getKeys() and iterates over every row in order to count them, which may be quite long if repo contains millions of rows. In order to avoid that issue, count could be implemented directly in the SQL query. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CAMEL-17615) camel-kafka: cleanup Kafka client warnings
[
https://issues.apache.org/jira/browse/CAMEL-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otavio Rodolfo Piske updated CAMEL-17615:
-
Priority: Minor (was: Major)
> camel-kafka: cleanup Kafka client warnings
> --
>
> Key: CAMEL-17615
> URL: https://issues.apache.org/jira/browse/CAMEL-17615
> Project: Camel
> Issue Type: Improvement
> Components: camel-kafka
>Affects Versions: 3.11.5, 3.14.0
>Reporter: Otavio Rodolfo Piske
>Priority: Minor
>
> There are several warnings about unrecognized configurations when the Kafka
> client starts. We should clean them up.
> For example:
>
> {code:java}
> 2022-01-17 06:37:49.634 WARN 28548 --- [r-transactions]]
> o.a.k.clients.consumer.ConsumerConfig : The configuration
> 'specific.avro.reader' was supplied but isn't a known config.
> 2022-01-17 06:37:49.634 WARN 28548 --- [r-transactions]]
> o.a.k.clients.consumer.ConsumerConfig : The configuration
> 'specific.avro.reader' was supplied but isn't a known config.
> 2022-01-17 06:37:49.635 WARN 28548 --- [r-transactions]]
> o.a.k.clients.consumer.ConsumerConfig : The configuration
> 'sasl.kerberos.principal.to.local.rules' was supplied but isn't a known
> config.
> 2022-01-17 06:37:49.635 WARN 28548 --- [r-transactions]]
> o.a.k.clients.consumer.ConsumerConfig : The configuration
> 'sasl.kerberos.principal.to.local.rules' was supplied but isn't a known
> config.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CAMEL-17615) camel-kafka: cleanup Kafka client warnings
Otavio Rodolfo Piske created CAMEL-17615:
Summary: camel-kafka: cleanup Kafka client warnings
Key: CAMEL-17615
URL: https://issues.apache.org/jira/browse/CAMEL-17615
Project: Camel
Issue Type: Improvement
Components: camel-kafka
Affects Versions: 3.14.0, 3.11.5
Reporter: Otavio Rodolfo Piske
There are several warnings about unrecognized configurations when the Kafka
client starts. We should clean them up.
For example:
{code:java}
2022-01-17 06:37:49.634 WARN 28548 --- [r-transactions]]
o.a.k.clients.consumer.ConsumerConfig : The configuration
'specific.avro.reader' was supplied but isn't a known config.
2022-01-17 06:37:49.634 WARN 28548 --- [r-transactions]]
o.a.k.clients.consumer.ConsumerConfig : The configuration
'specific.avro.reader' was supplied but isn't a known config.
2022-01-17 06:37:49.635 WARN 28548 --- [r-transactions]]
o.a.k.clients.consumer.ConsumerConfig : The configuration
'sasl.kerberos.principal.to.local.rules' was supplied but isn't a known config.
2022-01-17 06:37:49.635 WARN 28548 --- [r-transactions]]
o.a.k.clients.consumer.ConsumerConfig : The configuration
'sasl.kerberos.principal.to.local.rules' was supplied but isn't a known
config.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
