[jira] [Assigned] (CAMEL-20606) Add Camel K bind command
[ https://issues.apache.org/jira/browse/CAMEL-20606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-20606: --- Assignee: Christoph Deppisch > Add Camel K bind command > > > Key: CAMEL-20606 > URL: https://issues.apache.org/jira/browse/CAMEL-20606 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Affects Versions: 4.x >Reporter: Christoph Deppisch >Assignee: Christoph Deppisch >Priority: Major > Fix For: 4.6.0 > > > Camel JBang provides a bind command that creates a Pipe resource connecting a > source and a sink. > Camel K JBang plugin may add support for traits, annotations and service > bindings to this feature. The plugin command may reuse the arbitrary bind > command as a basis adding the Kubernetes specific options on top of that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20606) Add Camel K bind command
[ https://issues.apache.org/jira/browse/CAMEL-20606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-20606. - Resolution: Fixed > Add Camel K bind command > > > Key: CAMEL-20606 > URL: https://issues.apache.org/jira/browse/CAMEL-20606 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Affects Versions: 4.x >Reporter: Christoph Deppisch >Assignee: Christoph Deppisch >Priority: Major > Fix For: 4.6.0 > > > Camel JBang provides a bind command that creates a Pipe resource connecting a > source and a sink. > Camel K JBang plugin may add support for traits, annotations and service > bindings to this feature. The plugin command may reuse the arbitrary bind > command as a basis adding the Kubernetes specific options on top of that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20606) Add Camel K bind command
[ https://issues.apache.org/jira/browse/CAMEL-20606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20606: Fix Version/s: 4.6.0 > Add Camel K bind command > > > Key: CAMEL-20606 > URL: https://issues.apache.org/jira/browse/CAMEL-20606 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Affects Versions: 4.x >Reporter: Christoph Deppisch >Priority: Major > Fix For: 4.6.0 > > > Camel JBang provides a bind command that creates a Pipe resource connecting a > source and a sink. > Camel K JBang plugin may add support for traits, annotations and service > bindings to this feature. The plugin command may reuse the arbitrary bind > command as a basis adding the Kubernetes specific options on top of that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20606) Add Camel K bind command
Christoph Deppisch created CAMEL-20606: -- Summary: Add Camel K bind command Key: CAMEL-20606 URL: https://issues.apache.org/jira/browse/CAMEL-20606 Project: Camel Issue Type: Improvement Components: camel-jbang Affects Versions: 4.x Reporter: Christoph Deppisch Camel JBang provides a bind command that creates a Pipe resource connecting a source and a sink. Camel K JBang plugin may add support for traits, annotations and service bindings to this feature. The plugin command may reuse the arbitrary bind command as a basis adding the Kubernetes specific options on top of that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20604) camel-jbang - Remove -p for run command
[ https://issues.apache.org/jira/browse/CAMEL-20604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-20604. - Assignee: Claus Ibsen Resolution: Fixed > camel-jbang - Remove -p for run command > --- > > Key: CAMEL-20604 > URL: https://issues.apache.org/jira/browse/CAMEL-20604 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.5.0 > > > We should only have double dash args that are rememberable. No -p -o -i args > etc -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20605) camel-jbang - The camel-k run command should not have args with single char
Claus Ibsen created CAMEL-20605: --- Summary: camel-jbang - The camel-k run command should not have args with single char Key: CAMEL-20605 URL: https://issues.apache.org/jira/browse/CAMEL-20605 Project: Camel Issue Type: Improvement Components: camel-jbang Reporter: Claus Ibsen Fix For: 4.x We should avoid commands that has single char like -x, -k and whatnot. And use `--kit` and understandable names. That is what camel-jbang in general does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20604) camel-jbang - Remove -p for run command
[ https://issues.apache.org/jira/browse/CAMEL-20604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20604: Fix Version/s: 4.5.0 (was: 4.x) > camel-jbang - Remove -p for run command > --- > > Key: CAMEL-20604 > URL: https://issues.apache.org/jira/browse/CAMEL-20604 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Reporter: Claus Ibsen >Priority: Minor > Fix For: 4.5.0 > > > We should only have double dash args that are rememberable. No -p -o -i args > etc -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20601) Support error handler in Camel JBang bind command
[ https://issues.apache.org/jira/browse/CAMEL-20601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-20601. - Resolution: Fixed > Support error handler in Camel JBang bind command > - > > Key: CAMEL-20601 > URL: https://issues.apache.org/jira/browse/CAMEL-20601 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Affects Versions: 4.x >Reporter: Christoph Deppisch >Assignee: Christoph Deppisch >Priority: Major > Fix For: 4.5.0 > > > A Pipe resource is able to specify an error handler in addition to a source > and a sink. The bind command in Camel JBang should be able to also specify an > error handler. > The error handler specification in the Pipe can be a sink (e.g. a Kamelet > reference), endpoint URI, log error handler or noErrorHandler. > The bind command should provide a new option (--error-handler) that receives > the error handler in the same way as source and sink are specified on the > command. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20604) camel-jbang - Remove -p for run command
Claus Ibsen created CAMEL-20604: --- Summary: camel-jbang - Remove -p for run command Key: CAMEL-20604 URL: https://issues.apache.org/jira/browse/CAMEL-20604 Project: Camel Issue Type: Improvement Components: camel-jbang Reporter: Claus Ibsen Fix For: 4.x We should only have double dash args that are rememberable. No -p -o -i args etc -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20602) Support user properties in Camel JBang bind command
[ https://issues.apache.org/jira/browse/CAMEL-20602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-20602. - Resolution: Fixed > Support user properties in Camel JBang bind command > --- > > Key: CAMEL-20602 > URL: https://issues.apache.org/jira/browse/CAMEL-20602 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Affects Versions: 4.x >Reporter: Christoph Deppisch >Assignee: Christoph Deppisch >Priority: Major > Fix For: 4.5.0 > > > The bind command in Camel JBang is used to create a Pipe with a source and a > sink. The source and sink can have properties that the user needs to specify > (e.g. required Kamelet properties). > The user should be able to specify these properties for source and sink as > command options (e.g. --property source.key=value). The property keys use a > prefix of type source, sink or error-handler that determines where the > property should be set (on source, sink or error handler). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20601) Support error handler in Camel JBang bind command
[ https://issues.apache.org/jira/browse/CAMEL-20601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-20601: --- Assignee: Christoph Deppisch > Support error handler in Camel JBang bind command > - > > Key: CAMEL-20601 > URL: https://issues.apache.org/jira/browse/CAMEL-20601 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Affects Versions: 4.x >Reporter: Christoph Deppisch >Assignee: Christoph Deppisch >Priority: Major > Fix For: 4.6.0 > > > A Pipe resource is able to specify an error handler in addition to a source > and a sink. The bind command in Camel JBang should be able to also specify an > error handler. > The error handler specification in the Pipe can be a sink (e.g. a Kamelet > reference), endpoint URI, log error handler or noErrorHandler. > The bind command should provide a new option (--error-handler) that receives > the error handler in the same way as source and sink are specified on the > command. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20601) Support error handler in Camel JBang bind command
[ https://issues.apache.org/jira/browse/CAMEL-20601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20601: Fix Version/s: 4.5.0 (was: 4.6.0) > Support error handler in Camel JBang bind command > - > > Key: CAMEL-20601 > URL: https://issues.apache.org/jira/browse/CAMEL-20601 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Affects Versions: 4.x >Reporter: Christoph Deppisch >Assignee: Christoph Deppisch >Priority: Major > Fix For: 4.5.0 > > > A Pipe resource is able to specify an error handler in addition to a source > and a sink. The bind command in Camel JBang should be able to also specify an > error handler. > The error handler specification in the Pipe can be a sink (e.g. a Kamelet > reference), endpoint URI, log error handler or noErrorHandler. > The bind command should provide a new option (--error-handler) that receives > the error handler in the same way as source and sink are specified on the > command. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20594) Camel-Milvus: Add a datatype for transforming langchain embeddings in Milvus objects
[ https://issues.apache.org/jira/browse/CAMEL-20594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino updated CAMEL-20594: - Fix Version/s: 4.5.0 (was: 4.6.0) > Camel-Milvus: Add a datatype for transforming langchain embeddings in Milvus > objects > > > Key: CAMEL-20594 > URL: https://issues.apache.org/jira/browse/CAMEL-20594 > Project: Camel > Issue Type: New Feature >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.5.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20594) Camel-Milvus: Add a datatype for transforming langchain embeddings in Milvus objects
[ https://issues.apache.org/jira/browse/CAMEL-20594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-20594. -- Resolution: Fixed > Camel-Milvus: Add a datatype for transforming langchain embeddings in Milvus > objects > > > Key: CAMEL-20594 > URL: https://issues.apache.org/jira/browse/CAMEL-20594 > Project: Camel > Issue Type: New Feature >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.5.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20602) Support user properties in Camel JBang bind command
[ https://issues.apache.org/jira/browse/CAMEL-20602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-20602: --- Assignee: Christoph Deppisch > Support user properties in Camel JBang bind command > --- > > Key: CAMEL-20602 > URL: https://issues.apache.org/jira/browse/CAMEL-20602 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Affects Versions: 4.x >Reporter: Christoph Deppisch >Assignee: Christoph Deppisch >Priority: Major > Fix For: 4.5.0 > > > The bind command in Camel JBang is used to create a Pipe with a source and a > sink. The source and sink can have properties that the user needs to specify > (e.g. required Kamelet properties). > The user should be able to specify these properties for source and sink as > command options (e.g. --property source.key=value). The property keys use a > prefix of type source, sink or error-handler that determines where the > property should be set (on source, sink or error handler). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20602) Support user properties in Camel JBang bind command
[ https://issues.apache.org/jira/browse/CAMEL-20602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829926#comment-17829926 ] Claus Ibsen commented on CAMEL-20602: - I think we can make this for 4.5 > Support user properties in Camel JBang bind command > --- > > Key: CAMEL-20602 > URL: https://issues.apache.org/jira/browse/CAMEL-20602 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Affects Versions: 4.x >Reporter: Christoph Deppisch >Priority: Major > Fix For: 4.5.0 > > > The bind command in Camel JBang is used to create a Pipe with a source and a > sink. The source and sink can have properties that the user needs to specify > (e.g. required Kamelet properties). > The user should be able to specify these properties for source and sink as > command options (e.g. --property source.key=value). The property keys use a > prefix of type source, sink or error-handler that determines where the > property should be set (on source, sink or error handler). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20602) Support user properties in Camel JBang bind command
[ https://issues.apache.org/jira/browse/CAMEL-20602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20602: Fix Version/s: 4.5.0 (was: 4.6.0) > Support user properties in Camel JBang bind command > --- > > Key: CAMEL-20602 > URL: https://issues.apache.org/jira/browse/CAMEL-20602 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Affects Versions: 4.x >Reporter: Christoph Deppisch >Priority: Major > Fix For: 4.5.0 > > > The bind command in Camel JBang is used to create a Pipe with a source and a > sink. The source and sink can have properties that the user needs to specify > (e.g. required Kamelet properties). > The user should be able to specify these properties for source and sink as > command options (e.g. --property source.key=value). The property keys use a > prefix of type source, sink or error-handler that determines where the > property should be set (on source, sink or error handler). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20601) Support error handler in Camel JBang bind command
[ https://issues.apache.org/jira/browse/CAMEL-20601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20601: Fix Version/s: 4.6.0 > Support error handler in Camel JBang bind command > - > > Key: CAMEL-20601 > URL: https://issues.apache.org/jira/browse/CAMEL-20601 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Affects Versions: 4.x >Reporter: Christoph Deppisch >Priority: Major > Fix For: 4.6.0 > > > A Pipe resource is able to specify an error handler in addition to a source > and a sink. The bind command in Camel JBang should be able to also specify an > error handler. > The error handler specification in the Pipe can be a sink (e.g. a Kamelet > reference), endpoint URI, log error handler or noErrorHandler. > The bind command should provide a new option (--error-handler) that receives > the error handler in the same way as source and sink are specified on the > command. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20602) Support user properties in Camel JBang bind command
[ https://issues.apache.org/jira/browse/CAMEL-20602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20602: Fix Version/s: 4.6.0 > Support user properties in Camel JBang bind command > --- > > Key: CAMEL-20602 > URL: https://issues.apache.org/jira/browse/CAMEL-20602 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Affects Versions: 4.x >Reporter: Christoph Deppisch >Priority: Major > Fix For: 4.6.0 > > > The bind command in Camel JBang is used to create a Pipe with a source and a > sink. The source and sink can have properties that the user needs to specify > (e.g. required Kamelet properties). > The user should be able to specify these properties for source and sink as > command options (e.g. --property source.key=value). The property keys use a > prefix of type source, sink or error-handler that determines where the > property should be set (on source, sink or error handler). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20596) Propagate Azure Service Bus message headers (properties) to Camel Message
[
https://issues.apache.org/jira/browse/CAMEL-20596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-20596.
-
Resolution: Fixed
> Propagate Azure Service Bus message headers (properties) to Camel Message
> -
>
> Key: CAMEL-20596
> URL: https://issues.apache.org/jira/browse/CAMEL-20596
> Project: Camel
> Issue Type: Improvement
> Components: camel-azure
>Affects Versions: 4.4.1
>Reporter: Dylan Piergies
>Priority: Major
> Fix For: 4.4.2, 4.5.0
>
>
> Message headers (_properties_, in Service Bus parlance) are not currently
> propagated to/from Camel Message headers aside from within the
> {{CamelAzureServiceBusApplicationProperties}} header.
> Crucially, the lack of header propagation means that *trace context
> propagation does not work* when using Azure Service Bus.
> I have implemented and tested the necessary header propagation and created a
> PR. Please let me know if I need to target a later version, or if we need to
> make the new behaviour switchable in order to make it suitable for a patch
> release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20603) camel-micrometer - Micrometer observation component losses spans during tracing
[
https://issues.apache.org/jira/browse/CAMEL-20603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829902#comment-17829902
]
Claus Ibsen commented on CAMEL-20603:
-
Thanks for reporting and with the details and screenshots. I liked to a
potential related JIRA.
> camel-micrometer - Micrometer observation component losses spans during
> tracing
> ---
>
> Key: CAMEL-20603
> URL: https://issues.apache.org/jira/browse/CAMEL-20603
> Project: Camel
> Issue Type: Bug
> Components: camel-micrometer
>Affects Versions: 4.4.0
>Reporter: Kutorkin Artyom
>Priority: Minor
> Attachments: image-2024-03-22-16-34-11-487.png,
> image-2024-03-22-16-34-54-659.png, image-2024-03-22-16-46-21-015.png,
> image-2024-03-22-16-51-48-525.png
>
>
> I've got an issue in my project related with Camel Observation within routes.
> Most of the time, during request processing previous spans are losing, so
> multiple traces can be created for one request. Also, for unknown reasons
> some of the spans that were created in current request, can join previous
> trace where spans were missed.
> {*}Workflow{*}:
> {code:java}
> // 1. Spring controller producing the event to SEDA dictSync
> producerTemplate.send(SEDA_DICT_SYNC_START.getUri(), exchange ->
> exchange.getIn().setBody(objectMapper.writeValueAsString(entities)));
> // 2. Event-driven consumer consumes the event from SEDA dictSync and
> processes it in dictSyncStartProcessor
> from(SEDA_DICT_SYNC_START)
> .routeId("DictSyncStart")
> .unmarshal().json(JsonLibrary.Jackson)
> .onException(Exception.class).handled(true)
> .process(exchange -> handleException((String)
> exchange.getIn().getBody(ArrayList.class).get(0), exchange))
> .end()
> .process(dictSyncStartProcessor);
> // 3. dictSyncStartProcessor processes the event and send another to SEDA
> dictSyncSplit
> producerTemplate.send(SEDA_DICT_SYNC_SPLIT.getUri(), exchange -> {
> Message message = exchange.getIn();
> entitySync.setUpdateDatetime(updateDatetime);
> message.setHeader("destination", destination.name());
> message.setHeader("entity", objectMapper.writeValueAsString(entitySync));
> message.setHeader("messageId", messageId);
> message.setBody(data);
> });
> // 4. dictSyncSplit consumes event, split its body, aggregate splitted
> records and send aggregated record to kafka
> from(SEDA_DICT_SYNC_SPLIT)
> .routeId("DictSyncSplit")
> .onException(Exception.class).handled(true).useOriginalMessage()
> .process(exchange -> {
> var entitySync =
> objectMapper.readValue(exchange.getIn().getHeader("entity", String.class),
> EntitySync.class);
> handleException(entitySync.getEntity(), exchange);
> })
> .end()
> .split(body())
> .aggregate(header("messageId"), aggregationStrategy)
> .completionSize(20)
> .completionTimeout(1000L)
> .marshal().json(JsonLibrary.Jackson)
> .to(kafka(DICTIONARY_SYNC_TOPIC));
> // 5. dictionarySync route consumes event from kafka and send another to
> proccesedEntitySync
> producerTemplate.send(kafka(PROCESSED_ENTITY_SYNC_TOPIC).getUri(), ex ->
> ex.getIn().setBody(objectMapper.writeValueAsString(entitySync)));{code}
>
> *First case*
> Actual unexpected results:
> * dictSyncSplit route observations are missing (but will be associated
> during next request)
> * processedEntitySync is separated into another trace
> !image-2024-03-22-16-34-11-487.png|width=460,height=166!!image-2024-03-22-16-34-54-659.png|width=422,height=198!
> After invoking this request once again, new spans were associated with first
> request:
> !image-2024-03-22-16-46-21-015.png|width=490,height=245!
>
> *Second case*
> Actual unexpected results:
> * dictSyncSplit is separated into another trace
> * processedEntitySync is separated into another trace
> *!image-2024-03-22-16-51-48-525.png|width=549,height=112!*
>
> *Observation dependencies:*
> {code:java}
> implementation 'org.springframework.boot:spring-boot-starter-aop'
> implementation 'io.micrometer:micrometer-tracing-bridge-otel'
> implementation 'io.opentelemetry:opentelemetry-exporter-zipkin'
> implementation
> 'org.apache.camel.springboot:camel-observation-starter:4.4.0'{code}
> Spring boot version: 3.2.2
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20603) camel-micrometer - Micrometer observation component losses spans during tracing
[
https://issues.apache.org/jira/browse/CAMEL-20603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20603:
Summary: camel-micrometer - Micrometer observation component losses spans
during tracing (was: Micrometer observation component losses spans during
tracing)
> camel-micrometer - Micrometer observation component losses spans during
> tracing
> ---
>
> Key: CAMEL-20603
> URL: https://issues.apache.org/jira/browse/CAMEL-20603
> Project: Camel
> Issue Type: Bug
> Components: camel-micrometer
>Affects Versions: 4.4.0
>Reporter: Kutorkin Artyom
>Priority: Minor
> Attachments: image-2024-03-22-16-34-11-487.png,
> image-2024-03-22-16-34-54-659.png, image-2024-03-22-16-46-21-015.png,
> image-2024-03-22-16-51-48-525.png
>
>
> I've got an issue in my project related with Camel Observation within routes.
> Most of the time, during request processing previous spans are losing, so
> multiple traces can be created for one request. Also, for unknown reasons
> some of the spans that were created in current request, can join previous
> trace where spans were missed.
> {*}Workflow{*}:
> {code:java}
> // 1. Spring controller producing the event to SEDA dictSync
> producerTemplate.send(SEDA_DICT_SYNC_START.getUri(), exchange ->
> exchange.getIn().setBody(objectMapper.writeValueAsString(entities)));
> // 2. Event-driven consumer consumes the event from SEDA dictSync and
> processes it in dictSyncStartProcessor
> from(SEDA_DICT_SYNC_START)
> .routeId("DictSyncStart")
> .unmarshal().json(JsonLibrary.Jackson)
> .onException(Exception.class).handled(true)
> .process(exchange -> handleException((String)
> exchange.getIn().getBody(ArrayList.class).get(0), exchange))
> .end()
> .process(dictSyncStartProcessor);
> // 3. dictSyncStartProcessor processes the event and send another to SEDA
> dictSyncSplit
> producerTemplate.send(SEDA_DICT_SYNC_SPLIT.getUri(), exchange -> {
> Message message = exchange.getIn();
> entitySync.setUpdateDatetime(updateDatetime);
> message.setHeader("destination", destination.name());
> message.setHeader("entity", objectMapper.writeValueAsString(entitySync));
> message.setHeader("messageId", messageId);
> message.setBody(data);
> });
> // 4. dictSyncSplit consumes event, split its body, aggregate splitted
> records and send aggregated record to kafka
> from(SEDA_DICT_SYNC_SPLIT)
> .routeId("DictSyncSplit")
> .onException(Exception.class).handled(true).useOriginalMessage()
> .process(exchange -> {
> var entitySync =
> objectMapper.readValue(exchange.getIn().getHeader("entity", String.class),
> EntitySync.class);
> handleException(entitySync.getEntity(), exchange);
> })
> .end()
> .split(body())
> .aggregate(header("messageId"), aggregationStrategy)
> .completionSize(20)
> .completionTimeout(1000L)
> .marshal().json(JsonLibrary.Jackson)
> .to(kafka(DICTIONARY_SYNC_TOPIC));
> // 5. dictionarySync route consumes event from kafka and send another to
> proccesedEntitySync
> producerTemplate.send(kafka(PROCESSED_ENTITY_SYNC_TOPIC).getUri(), ex ->
> ex.getIn().setBody(objectMapper.writeValueAsString(entitySync)));{code}
>
> *First case*
> Actual unexpected results:
> * dictSyncSplit route observations are missing (but will be associated
> during next request)
> * processedEntitySync is separated into another trace
> !image-2024-03-22-16-34-11-487.png|width=460,height=166!!image-2024-03-22-16-34-54-659.png|width=422,height=198!
> After invoking this request once again, new spans were associated with first
> request:
> !image-2024-03-22-16-46-21-015.png|width=490,height=245!
>
> *Second case*
> Actual unexpected results:
> * dictSyncSplit is separated into another trace
> * processedEntitySync is separated into another trace
> *!image-2024-03-22-16-51-48-525.png|width=549,height=112!*
>
> *Observation dependencies:*
> {code:java}
> implementation 'org.springframework.boot:spring-boot-starter-aop'
> implementation 'io.micrometer:micrometer-tracing-bridge-otel'
> implementation 'io.opentelemetry:opentelemetry-exporter-zipkin'
> implementation
> 'org.apache.camel.springboot:camel-observation-starter:4.4.0'{code}
> Spring boot version: 3.2.2
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20603) Micrometer observation component losses spans during tracing
[
https://issues.apache.org/jira/browse/CAMEL-20603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20603:
Component/s: camel-micrometer
(was: camel-spring-boot)
> Micrometer observation component losses spans during tracing
>
>
> Key: CAMEL-20603
> URL: https://issues.apache.org/jira/browse/CAMEL-20603
> Project: Camel
> Issue Type: Bug
> Components: camel-micrometer
>Affects Versions: 4.4.0
>Reporter: Kutorkin Artyom
>Priority: Minor
> Attachments: image-2024-03-22-16-34-11-487.png,
> image-2024-03-22-16-34-54-659.png, image-2024-03-22-16-46-21-015.png,
> image-2024-03-22-16-51-48-525.png
>
>
> I've got an issue in my project related with Camel Observation within routes.
> Most of the time, during request processing previous spans are losing, so
> multiple traces can be created for one request. Also, for unknown reasons
> some of the spans that were created in current request, can join previous
> trace where spans were missed.
> {*}Workflow{*}:
> {code:java}
> // 1. Spring controller producing the event to SEDA dictSync
> producerTemplate.send(SEDA_DICT_SYNC_START.getUri(), exchange ->
> exchange.getIn().setBody(objectMapper.writeValueAsString(entities)));
> // 2. Event-driven consumer consumes the event from SEDA dictSync and
> processes it in dictSyncStartProcessor
> from(SEDA_DICT_SYNC_START)
> .routeId("DictSyncStart")
> .unmarshal().json(JsonLibrary.Jackson)
> .onException(Exception.class).handled(true)
> .process(exchange -> handleException((String)
> exchange.getIn().getBody(ArrayList.class).get(0), exchange))
> .end()
> .process(dictSyncStartProcessor);
> // 3. dictSyncStartProcessor processes the event and send another to SEDA
> dictSyncSplit
> producerTemplate.send(SEDA_DICT_SYNC_SPLIT.getUri(), exchange -> {
> Message message = exchange.getIn();
> entitySync.setUpdateDatetime(updateDatetime);
> message.setHeader("destination", destination.name());
> message.setHeader("entity", objectMapper.writeValueAsString(entitySync));
> message.setHeader("messageId", messageId);
> message.setBody(data);
> });
> // 4. dictSyncSplit consumes event, split its body, aggregate splitted
> records and send aggregated record to kafka
> from(SEDA_DICT_SYNC_SPLIT)
> .routeId("DictSyncSplit")
> .onException(Exception.class).handled(true).useOriginalMessage()
> .process(exchange -> {
> var entitySync =
> objectMapper.readValue(exchange.getIn().getHeader("entity", String.class),
> EntitySync.class);
> handleException(entitySync.getEntity(), exchange);
> })
> .end()
> .split(body())
> .aggregate(header("messageId"), aggregationStrategy)
> .completionSize(20)
> .completionTimeout(1000L)
> .marshal().json(JsonLibrary.Jackson)
> .to(kafka(DICTIONARY_SYNC_TOPIC));
> // 5. dictionarySync route consumes event from kafka and send another to
> proccesedEntitySync
> producerTemplate.send(kafka(PROCESSED_ENTITY_SYNC_TOPIC).getUri(), ex ->
> ex.getIn().setBody(objectMapper.writeValueAsString(entitySync)));{code}
>
> *First case*
> Actual unexpected results:
> * dictSyncSplit route observations are missing (but will be associated
> during next request)
> * processedEntitySync is separated into another trace
> !image-2024-03-22-16-34-11-487.png|width=460,height=166!!image-2024-03-22-16-34-54-659.png|width=422,height=198!
> After invoking this request once again, new spans were associated with first
> request:
> !image-2024-03-22-16-46-21-015.png|width=490,height=245!
>
> *Second case*
> Actual unexpected results:
> * dictSyncSplit is separated into another trace
> * processedEntitySync is separated into another trace
> *!image-2024-03-22-16-51-48-525.png|width=549,height=112!*
>
> *Observation dependencies:*
> {code:java}
> implementation 'org.springframework.boot:spring-boot-starter-aop'
> implementation 'io.micrometer:micrometer-tracing-bridge-otel'
> implementation 'io.opentelemetry:opentelemetry-exporter-zipkin'
> implementation
> 'org.apache.camel.springboot:camel-observation-starter:4.4.0'{code}
> Spring boot version: 3.2.2
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20603) Micrometer observation component losses spans during tracing
[
https://issues.apache.org/jira/browse/CAMEL-20603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20603:
Priority: Minor (was: Major)
> Micrometer observation component losses spans during tracing
>
>
> Key: CAMEL-20603
> URL: https://issues.apache.org/jira/browse/CAMEL-20603
> Project: Camel
> Issue Type: Bug
> Components: camel-spring-boot
>Affects Versions: 4.4.0
>Reporter: Kutorkin Artyom
>Priority: Minor
> Attachments: image-2024-03-22-16-34-11-487.png,
> image-2024-03-22-16-34-54-659.png, image-2024-03-22-16-46-21-015.png,
> image-2024-03-22-16-51-48-525.png
>
>
> I've got an issue in my project related with Camel Observation within routes.
> Most of the time, during request processing previous spans are losing, so
> multiple traces can be created for one request. Also, for unknown reasons
> some of the spans that were created in current request, can join previous
> trace where spans were missed.
> {*}Workflow{*}:
> {code:java}
> // 1. Spring controller producing the event to SEDA dictSync
> producerTemplate.send(SEDA_DICT_SYNC_START.getUri(), exchange ->
> exchange.getIn().setBody(objectMapper.writeValueAsString(entities)));
> // 2. Event-driven consumer consumes the event from SEDA dictSync and
> processes it in dictSyncStartProcessor
> from(SEDA_DICT_SYNC_START)
> .routeId("DictSyncStart")
> .unmarshal().json(JsonLibrary.Jackson)
> .onException(Exception.class).handled(true)
> .process(exchange -> handleException((String)
> exchange.getIn().getBody(ArrayList.class).get(0), exchange))
> .end()
> .process(dictSyncStartProcessor);
> // 3. dictSyncStartProcessor processes the event and send another to SEDA
> dictSyncSplit
> producerTemplate.send(SEDA_DICT_SYNC_SPLIT.getUri(), exchange -> {
> Message message = exchange.getIn();
> entitySync.setUpdateDatetime(updateDatetime);
> message.setHeader("destination", destination.name());
> message.setHeader("entity", objectMapper.writeValueAsString(entitySync));
> message.setHeader("messageId", messageId);
> message.setBody(data);
> });
> // 4. dictSyncSplit consumes event, split its body, aggregate splitted
> records and send aggregated record to kafka
> from(SEDA_DICT_SYNC_SPLIT)
> .routeId("DictSyncSplit")
> .onException(Exception.class).handled(true).useOriginalMessage()
> .process(exchange -> {
> var entitySync =
> objectMapper.readValue(exchange.getIn().getHeader("entity", String.class),
> EntitySync.class);
> handleException(entitySync.getEntity(), exchange);
> })
> .end()
> .split(body())
> .aggregate(header("messageId"), aggregationStrategy)
> .completionSize(20)
> .completionTimeout(1000L)
> .marshal().json(JsonLibrary.Jackson)
> .to(kafka(DICTIONARY_SYNC_TOPIC));
> // 5. dictionarySync route consumes event from kafka and send another to
> proccesedEntitySync
> producerTemplate.send(kafka(PROCESSED_ENTITY_SYNC_TOPIC).getUri(), ex ->
> ex.getIn().setBody(objectMapper.writeValueAsString(entitySync)));{code}
>
> *First case*
> Actual unexpected results:
> * dictSyncSplit route observations are missing (but will be associated
> during next request)
> * processedEntitySync is separated into another trace
> !image-2024-03-22-16-34-11-487.png|width=460,height=166!!image-2024-03-22-16-34-54-659.png|width=422,height=198!
> After invoking this request once again, new spans were associated with first
> request:
> !image-2024-03-22-16-46-21-015.png|width=490,height=245!
>
> *Second case*
> Actual unexpected results:
> * dictSyncSplit is separated into another trace
> * processedEntitySync is separated into another trace
> *!image-2024-03-22-16-51-48-525.png|width=549,height=112!*
>
> *Observation dependencies:*
> {code:java}
> implementation 'org.springframework.boot:spring-boot-starter-aop'
> implementation 'io.micrometer:micrometer-tracing-bridge-otel'
> implementation 'io.opentelemetry:opentelemetry-exporter-zipkin'
> implementation
> 'org.apache.camel.springboot:camel-observation-starter:4.4.0'{code}
> Spring boot version: 3.2.2
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20603) Micrometer observation component losses spans during tracing
Kutorkin Artyom created CAMEL-20603:
---
Summary: Micrometer observation component losses spans during
tracing
Key: CAMEL-20603
URL: https://issues.apache.org/jira/browse/CAMEL-20603
Project: Camel
Issue Type: Bug
Components: camel-spring-boot
Affects Versions: 4.4.0
Reporter: Kutorkin Artyom
Attachments: image-2024-03-22-16-34-11-487.png,
image-2024-03-22-16-34-54-659.png, image-2024-03-22-16-46-21-015.png,
image-2024-03-22-16-51-48-525.png
I've got an issue in my project related with Camel Observation within routes.
Most of the time, during request processing previous spans are losing, so
multiple traces can be created for one request. Also, for unknown reasons some
of the spans that were created in current request, can join previous trace
where spans were missed.
{*}Workflow{*}:
{code:java}
// 1. Spring controller producing the event to SEDA dictSync
producerTemplate.send(SEDA_DICT_SYNC_START.getUri(), exchange ->
exchange.getIn().setBody(objectMapper.writeValueAsString(entities)));
// 2. Event-driven consumer consumes the event from SEDA dictSync and processes
it in dictSyncStartProcessor
from(SEDA_DICT_SYNC_START)
.routeId("DictSyncStart")
.unmarshal().json(JsonLibrary.Jackson)
.onException(Exception.class).handled(true)
.process(exchange -> handleException((String)
exchange.getIn().getBody(ArrayList.class).get(0), exchange))
.end()
.process(dictSyncStartProcessor);
// 3. dictSyncStartProcessor processes the event and send another to SEDA
dictSyncSplit
producerTemplate.send(SEDA_DICT_SYNC_SPLIT.getUri(), exchange -> {
Message message = exchange.getIn();
entitySync.setUpdateDatetime(updateDatetime);
message.setHeader("destination", destination.name());
message.setHeader("entity", objectMapper.writeValueAsString(entitySync));
message.setHeader("messageId", messageId);
message.setBody(data);
});
// 4. dictSyncSplit consumes event, split its body, aggregate splitted records
and send aggregated record to kafka
from(SEDA_DICT_SYNC_SPLIT)
.routeId("DictSyncSplit")
.onException(Exception.class).handled(true).useOriginalMessage()
.process(exchange -> {
var entitySync =
objectMapper.readValue(exchange.getIn().getHeader("entity", String.class),
EntitySync.class);
handleException(entitySync.getEntity(), exchange);
})
.end()
.split(body())
.aggregate(header("messageId"), aggregationStrategy)
.completionSize(20)
.completionTimeout(1000L)
.marshal().json(JsonLibrary.Jackson)
.to(kafka(DICTIONARY_SYNC_TOPIC));
// 5. dictionarySync route consumes event from kafka and send another to
proccesedEntitySync
producerTemplate.send(kafka(PROCESSED_ENTITY_SYNC_TOPIC).getUri(), ex ->
ex.getIn().setBody(objectMapper.writeValueAsString(entitySync)));{code}
*First case*
Actual unexpected results:
* dictSyncSplit route observations are missing (but will be associated during
next request)
* processedEntitySync is separated into another trace
!image-2024-03-22-16-34-11-487.png|width=460,height=166!!image-2024-03-22-16-34-54-659.png|width=422,height=198!
After invoking this request once again, new spans were associated with first
request:
!image-2024-03-22-16-46-21-015.png|width=490,height=245!
*Second case*
Actual unexpected results:
* dictSyncSplit is separated into another trace
* processedEntitySync is separated into another trace
*!image-2024-03-22-16-51-48-525.png|width=549,height=112!*
*Observation dependencies:*
{code:java}
implementation 'org.springframework.boot:spring-boot-starter-aop'
implementation 'io.micrometer:micrometer-tracing-bridge-otel'
implementation 'io.opentelemetry:opentelemetry-exporter-zipkin'
implementation
'org.apache.camel.springboot:camel-observation-starter:4.4.0'{code}
Spring boot version: 3.2.2
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20602) Support user properties in Camel JBang bind command
Christoph Deppisch created CAMEL-20602: -- Summary: Support user properties in Camel JBang bind command Key: CAMEL-20602 URL: https://issues.apache.org/jira/browse/CAMEL-20602 Project: Camel Issue Type: Improvement Components: camel-jbang Affects Versions: 4.x Reporter: Christoph Deppisch The bind command in Camel JBang is used to create a Pipe with a source and a sink. The source and sink can have properties that the user needs to specify (e.g. required Kamelet properties). The user should be able to specify these properties for source and sink as command options (e.g. --property source.key=value). The property keys use a prefix of type source, sink or error-handler that determines where the property should be set (on source, sink or error handler). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20601) Support error handler in Camel JBang bind command
Christoph Deppisch created CAMEL-20601: -- Summary: Support error handler in Camel JBang bind command Key: CAMEL-20601 URL: https://issues.apache.org/jira/browse/CAMEL-20601 Project: Camel Issue Type: Improvement Components: camel-jbang Affects Versions: 4.x Reporter: Christoph Deppisch A Pipe resource is able to specify an error handler in addition to a source and a sink. The bind command in Camel JBang should be able to also specify an error handler. The error handler specification in the Pipe can be a sink (e.g. a Kamelet reference), endpoint URI, log error handler or noErrorHandler. The bind command should provide a new option (--error-handler) that receives the error handler in the same way as source and sink are specified on the command. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20596) Propagate Azure Service Bus message headers (properties) to Camel Message
[
https://issues.apache.org/jira/browse/CAMEL-20596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829870#comment-17829870
]
Dylan Piergies commented on CAMEL-20596:
Created #13592.
> Propagate Azure Service Bus message headers (properties) to Camel Message
> -
>
> Key: CAMEL-20596
> URL: https://issues.apache.org/jira/browse/CAMEL-20596
> Project: Camel
> Issue Type: Improvement
> Components: camel-azure
>Affects Versions: 4.4.1
>Reporter: Dylan Piergies
>Priority: Major
> Fix For: 4.4.2, 4.5.0
>
>
> Message headers (_properties_, in Service Bus parlance) are not currently
> propagated to/from Camel Message headers aside from within the
> {{CamelAzureServiceBusApplicationProperties}} header.
> Crucially, the lack of header propagation means that *trace context
> propagation does not work* when using Azure Service Bus.
> I have implemented and tested the necessary header propagation and created a
> PR. Please let me know if I need to target a later version, or if we need to
> make the new behaviour switchable in order to make it suitable for a patch
> release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20521) camel-amqp - AMQP publisher application is losing messages with local JMS transaction enabled
[
https://issues.apache.org/jira/browse/CAMEL-20521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20521:
Fix Version/s: 4.x
(was: 4.5.0)
(was: 4.4.2)
> camel-amqp - AMQP publisher application is losing messages with local JMS
> transaction enabled
> -
>
> Key: CAMEL-20521
> URL: https://issues.apache.org/jira/browse/CAMEL-20521
> Project: Camel
> Issue Type: Bug
> Components: camel-amqp
>Affects Versions: 4.4.0
>Reporter: Luigi De Masi
>Assignee: Luigi De Masi
>Priority: Major
> Fix For: 4.x
>
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> camel-amqp with local transaction enabled loses messages because to invoke
> the commit, it uses a spring-jms routine that catch and ignore a couple of
> exceptions that occurs and should not be ignored:
> In {{org.apache.camel.component.jms.JmsConfiguration.CamelJmsTemplate}} :
> !screenshot-1.png!
> that calls {{org.springframework.jms.support.JmsUtils}}
> !screenshot-2.png!
> In the comment it says that {{jakarta.jms.TransactionInProgressException}}
> and {{jakarta.jms.IllegalStateException}} can only happen in case of a JTA
> transaction but it can happens
> also in case of connection problems:
> {code:java}
> javax.jms.IllegalStateException: The Session is closed
> at org.apache.qpid.jms.JmsSession.checkClosed(JmsSession.java:1113)
> at org.apache.qpid.jms.JmsSession.getTransacted(JmsSession.java:213)
> at
> org.messaginghub.pooled.jms.JmsPoolSession.getTransacted(JmsPoolSession.java:256)
> at
> nl.ns.hip.cci.jms.CamelJmsTemplate.doSendToDestination(CamelJmsTemplate.java:94)
> at
> nl.ns.hip.cci.jms.CamelJmsTemplate.lambda$send$0(CamelJmsTemplate.java:33)
> at
> org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:504)
> at nl.ns.hip.cci.jms.CamelJmsTemplate.send(CamelJmsTemplate.java:31)
> at
> org.apache.camel.component.jms.JmsProducer.doSend(JmsProducer.java:425)
> at
> org.apache.camel.component.jms.JmsProducer.processInOnly(JmsProducer.java:392)
> at
> org.apache.camel.component.jms.JmsProducer.process(JmsProducer.java:159)
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:172)
> at
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.doRun(RedeliveryErrorHandler.java:818)
> at
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.run(RedeliveryErrorHandler.java:726)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:181)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:59)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:165)
> at
> org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:392)
> at
> org.apache.camel.component.seda.SedaConsumer.sendToConsumers(SedaConsumer.java:269)
> at
> org.apache.camel.component.seda.SedaConsumer.doRun(SedaConsumer.java:187)
> at
> org.apache.camel.component.seda.SedaConsumer.run(SedaConsumer.java:130)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20575) Camel-Milvus: Improve documentation
[ https://issues.apache.org/jira/browse/CAMEL-20575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20575: Fix Version/s: 4.6.0 (was: 4.5.0) > Camel-Milvus: Improve documentation > --- > > Key: CAMEL-20575 > URL: https://issues.apache.org/jira/browse/CAMEL-20575 > Project: Camel > Issue Type: Task >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20506) Google Mail Stream CloudEvent transformer
[ https://issues.apache.org/jira/browse/CAMEL-20506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20506: Fix Version/s: 4.6.0 (was: 4.5.0) > Google Mail Stream CloudEvent transformer > - > > Key: CAMEL-20506 > URL: https://issues.apache.org/jira/browse/CAMEL-20506 > Project: Camel > Issue Type: Sub-task >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20513) Camel-AWS-Bedrock: Support Amazon Titan Multimodal Embeddings G1 Model
[ https://issues.apache.org/jira/browse/CAMEL-20513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20513: Fix Version/s: 4.6.0 (was: 4.5.0) > Camel-AWS-Bedrock: Support Amazon Titan Multimodal Embeddings G1 Model > -- > > Key: CAMEL-20513 > URL: https://issues.apache.org/jira/browse/CAMEL-20513 > Project: Camel > Issue Type: Sub-task >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20521) camel-amqp - AMQP publisher application is losing messages with local JMS transaction enabled
[
https://issues.apache.org/jira/browse/CAMEL-20521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829849#comment-17829849
]
Claus Ibsen commented on CAMEL-20521:
-
This will be fixed by spring-jms, so we are awaiting they will do releases
> camel-amqp - AMQP publisher application is losing messages with local JMS
> transaction enabled
> -
>
> Key: CAMEL-20521
> URL: https://issues.apache.org/jira/browse/CAMEL-20521
> Project: Camel
> Issue Type: Bug
> Components: camel-amqp
>Affects Versions: 4.4.0
>Reporter: Luigi De Masi
>Assignee: Luigi De Masi
>Priority: Major
> Fix For: 4.x
>
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> camel-amqp with local transaction enabled loses messages because to invoke
> the commit, it uses a spring-jms routine that catch and ignore a couple of
> exceptions that occurs and should not be ignored:
> In {{org.apache.camel.component.jms.JmsConfiguration.CamelJmsTemplate}} :
> !screenshot-1.png!
> that calls {{org.springframework.jms.support.JmsUtils}}
> !screenshot-2.png!
> In the comment it says that {{jakarta.jms.TransactionInProgressException}}
> and {{jakarta.jms.IllegalStateException}} can only happen in case of a JTA
> transaction but it can happens
> also in case of connection problems:
> {code:java}
> javax.jms.IllegalStateException: The Session is closed
> at org.apache.qpid.jms.JmsSession.checkClosed(JmsSession.java:1113)
> at org.apache.qpid.jms.JmsSession.getTransacted(JmsSession.java:213)
> at
> org.messaginghub.pooled.jms.JmsPoolSession.getTransacted(JmsPoolSession.java:256)
> at
> nl.ns.hip.cci.jms.CamelJmsTemplate.doSendToDestination(CamelJmsTemplate.java:94)
> at
> nl.ns.hip.cci.jms.CamelJmsTemplate.lambda$send$0(CamelJmsTemplate.java:33)
> at
> org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:504)
> at nl.ns.hip.cci.jms.CamelJmsTemplate.send(CamelJmsTemplate.java:31)
> at
> org.apache.camel.component.jms.JmsProducer.doSend(JmsProducer.java:425)
> at
> org.apache.camel.component.jms.JmsProducer.processInOnly(JmsProducer.java:392)
> at
> org.apache.camel.component.jms.JmsProducer.process(JmsProducer.java:159)
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:172)
> at
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.doRun(RedeliveryErrorHandler.java:818)
> at
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.run(RedeliveryErrorHandler.java:726)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:181)
> at
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:59)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:165)
> at
> org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:392)
> at
> org.apache.camel.component.seda.SedaConsumer.sendToConsumers(SedaConsumer.java:269)
> at
> org.apache.camel.component.seda.SedaConsumer.doRun(SedaConsumer.java:187)
> at
> org.apache.camel.component.seda.SedaConsumer.run(SedaConsumer.java:130)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20505) Google Calendar Streams CloudEvent Transformer
[ https://issues.apache.org/jira/browse/CAMEL-20505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20505: Fix Version/s: 4.6.0 (was: 4.5.0) > Google Calendar Streams CloudEvent Transformer > -- > > Key: CAMEL-20505 > URL: https://issues.apache.org/jira/browse/CAMEL-20505 > Project: Camel > Issue Type: Sub-task >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20573) Camel-Milvus: Evaluating if creating a converter like qdrant component makes sense
[ https://issues.apache.org/jira/browse/CAMEL-20573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20573: Fix Version/s: 4.6.0 (was: 4.5.0) > Camel-Milvus: Evaluating if creating a converter like qdrant component makes > sense > -- > > Key: CAMEL-20573 > URL: https://issues.apache.org/jira/browse/CAMEL-20573 > Project: Camel > Issue Type: New Feature >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20574) Camel-Milvus: Add more producer operation
[ https://issues.apache.org/jira/browse/CAMEL-20574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20574: Fix Version/s: 4.6.0 (was: 4.5.0) > Camel-Milvus: Add more producer operation > - > > Key: CAMEL-20574 > URL: https://issues.apache.org/jira/browse/CAMEL-20574 > Project: Camel > Issue Type: New Feature >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20562) Camel-AWS-Bedrock: Support Mistral AI models
[ https://issues.apache.org/jira/browse/CAMEL-20562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20562: Fix Version/s: 4.6.0 (was: 4.5.0) > Camel-AWS-Bedrock: Support Mistral AI models > > > Key: CAMEL-20562 > URL: https://issues.apache.org/jira/browse/CAMEL-20562 > Project: Camel > Issue Type: Sub-task >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20594) Camel-Milvus: Add a datatype for transforming langchain embeddings in Milvus objects
[ https://issues.apache.org/jira/browse/CAMEL-20594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20594: Fix Version/s: 4.6.0 (was: 4.5.0) > Camel-Milvus: Add a datatype for transforming langchain embeddings in Milvus > objects > > > Key: CAMEL-20594 > URL: https://issues.apache.org/jira/browse/CAMEL-20594 > Project: Camel > Issue Type: New Feature >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20599) camel-ai - pom.xml should be clean
[ https://issues.apache.org/jira/browse/CAMEL-20599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-20599. - Resolution: Fixed > camel-ai - pom.xml should be clean > -- > > Key: CAMEL-20599 > URL: https://issues.apache.org/jira/browse/CAMEL-20599 > Project: Camel > Issue Type: Task > Components: build system >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 4.5.0 > > > camel-ai/pom.xml has dependency which it should not. They should be in the > component itself instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19469) camel-opentelemetry: Context not propagated correctly when tracing bean or processor invocations with @WithSpan
[
https://issues.apache.org/jira/browse/CAMEL-19469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829804#comment-17829804
]
James Netherton commented on CAMEL-19469:
-
{quote}The OpenTelemetryTracingStrategy already creates a Span for
Processors{quote}
True, but that wasn't the case when this issue was created. So this issue
probably needs a retest / reassessment.
> camel-opentelemetry: Context not propagated correctly when tracing bean or
> processor invocations with @WithSpan
> ---
>
> Key: CAMEL-19469
> URL: https://issues.apache.org/jira/browse/CAMEL-19469
> Project: Camel
> Issue Type: Improvement
> Components: camel-opentelemetry
>Affects Versions: 3.20.5, 4.0-M3
>Reporter: James Netherton
>Priority: Minor
>
> OpenTelemetry enables you to trace arbitrary method invocations by tagging
> them with the @WithSpan annotation:
> https://opentelemetry.io/docs/instrumentation/java/automatic/annotations/#creating-spans-around-methods-with-withspan
> For some scenarios, the tracing context does not seem to get propagated and
> the resulting spans end up being disassociated. For example:
> {code}
> from("timer:tick?period=5s)
> .process("myProcessor");
> {code}
> {code}
> public class MyProcessor implements Processor {
> @WithSpan
> @Override
> public void process(Exchange exchange) {
> // Useful work here...
> }
> }
> {code}
> This results in 2 spans. One for timer:tick & another for MyProcessor. The
> problem is that the parent span for MyProcessor is not set, so they appear as
> 2 distinct traces.
> There is a workaround where you can configure the route like this and the
> span hierarchy ends up being correct:
> {code}
> from("timer:tick?period=5s")
> .to("direct:start");
> from("direct:start")
> .process("myProcessor");
> {code}
> There's some more background in the original issue reported on Camel Quarkus:
> https://github.com/apache/camel-quarkus/issues/4981
> There's also a reproducer project here:
> https://github.com/jamesnetherton/camel-opentelemetry-demo
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20600) camel-activemq - Upgrade to ActiveMQ classic 6.x or create camel-activemq6
Claus Ibsen created CAMEL-20600: --- Summary: camel-activemq - Upgrade to ActiveMQ classic 6.x or create camel-activemq6 Key: CAMEL-20600 URL: https://issues.apache.org/jira/browse/CAMEL-20600 Project: Camel Issue Type: Dependency upgrade Components: camel-activemq Reporter: Claus Ibsen Fix For: 4.x We test with 5.18.x which is widely in use. The newer 6.x is JDK17 and jakarta ee compatible. We may consider having camel-activemq6 as a component for the newer client/broker. So we can keep the older around for the many 5.x users. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20599) camel-ai - pom.xml should be clean
[ https://issues.apache.org/jira/browse/CAMEL-20599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-20599: --- Assignee: Claus Ibsen > camel-ai - pom.xml should be clean > -- > > Key: CAMEL-20599 > URL: https://issues.apache.org/jira/browse/CAMEL-20599 > Project: Camel > Issue Type: Task > Components: build system >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 4.5.0 > > > camel-ai/pom.xml has dependency which it should not. They should be in the > component itself instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20595) camel-dlj - Move into camel-ai
[ https://issues.apache.org/jira/browse/CAMEL-20595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20595: Fix Version/s: 4.5.0 (was: 4.x) > camel-dlj - Move into camel-ai > -- > > Key: CAMEL-20595 > URL: https://issues.apache.org/jira/browse/CAMEL-20595 > Project: Camel > Issue Type: Task > Components: camel-ai >Reporter: Claus Ibsen >Priority: Minor > Fix For: 4.5.0 > > > We can move camel-dlj into the camel-ai folder as its for llm/ai stuff -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20595) camel-dlj - Move into camel-ai
[ https://issues.apache.org/jira/browse/CAMEL-20595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-20595. - Resolution: Fixed > camel-dlj - Move into camel-ai > -- > > Key: CAMEL-20595 > URL: https://issues.apache.org/jira/browse/CAMEL-20595 > Project: Camel > Issue Type: Task > Components: camel-ai >Reporter: Claus Ibsen >Priority: Minor > Fix For: 4.5.0 > > > We can move camel-dlj into the camel-ai folder as its for llm/ai stuff -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20599) camel-ai - pom.xml should be clean
Claus Ibsen created CAMEL-20599: --- Summary: camel-ai - pom.xml should be clean Key: CAMEL-20599 URL: https://issues.apache.org/jira/browse/CAMEL-20599 Project: Camel Issue Type: Task Components: build system Reporter: Claus Ibsen Fix For: 4.5.0 camel-ai/pom.xml has dependency which it should not. They should be in the component itself instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20598) camel-jbang - Cannot use hawtio v4
[ https://issues.apache.org/jira/browse/CAMEL-20598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20598: Priority: Minor (was: Major) > camel-jbang - Cannot use hawtio v4 > -- > > Key: CAMEL-20598 > URL: https://issues.apache.org/jira/browse/CAMEL-20598 > Project: Camel > Issue Type: Task > Components: camel-jbang >Reporter: Claus Ibsen >Priority: Minor > Fix For: 4.x > > > When using > camel run foo.java > camel hawtio foo > then it works with 3.0.x > but if you want to try with 4.0.x > camel hawtio foo --version=4.0.0-RC1 > you get a classloading issue -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20598) camel-jbang - Cannot use hawtio v4
Claus Ibsen created CAMEL-20598: --- Summary: camel-jbang - Cannot use hawtio v4 Key: CAMEL-20598 URL: https://issues.apache.org/jira/browse/CAMEL-20598 Project: Camel Issue Type: Task Components: camel-jbang Reporter: Claus Ibsen Fix For: 4.x When using camel run foo.java camel hawtio foo then it works with 3.0.x but if you want to try with 4.0.x camel hawtio foo --version=4.0.0-RC1 you get a classloading issue -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20598) camel-jbang - Cannot use hawtio v4
[ https://issues.apache.org/jira/browse/CAMEL-20598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829765#comment-17829765 ] Claus Ibsen commented on CAMEL-20598: - [~tsato] just a heads up > camel-jbang - Cannot use hawtio v4 > -- > > Key: CAMEL-20598 > URL: https://issues.apache.org/jira/browse/CAMEL-20598 > Project: Camel > Issue Type: Task > Components: camel-jbang >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > When using > camel run foo.java > camel hawtio foo > then it works with 3.0.x > but if you want to try with 4.0.x > camel hawtio foo --version=4.0.0-RC1 > you get a classloading issue -- This message was sent by Atlassian Jira (v8.20.10#820010)
