[jira] [Resolved] (CAMEL-20597) camel-salesforce - NullPointerException when query header is missing
[ https://issues.apache.org/jira/browse/CAMEL-20597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-20597. - Resolution: Fixed > camel-salesforce - NullPointerException when query header is missing > > > Key: CAMEL-20597 > URL: https://issues.apache.org/jira/browse/CAMEL-20597 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 4.4.1 >Reporter: Vishal Bihani >Priority: Minor > Fix For: 4.0.5, 4.4.2, 4.5.0 > > > [https://github.com/apache/camel/blob/3aa3c12f9a60df466bbafff660d5e4009263ba78/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/RawProcessor.java#L80|https://github.com/apache/camel/blob/3aa3c12f9a60df466bbafff660d5e4009263ba78/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/RawProcessor.java#L80] > When query header is not set it throws NullPointerException. Ideally it > should set checked exception. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20597) camel-salesforce - NullPointerException when query header is missing
[ https://issues.apache.org/jira/browse/CAMEL-20597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20597: Summary: camel-salesforce - NullPointerException when query header is missing (was: NullPointerException when query header is missing) > camel-salesforce - NullPointerException when query header is missing > > > Key: CAMEL-20597 > URL: https://issues.apache.org/jira/browse/CAMEL-20597 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 4.4.1 >Reporter: Vishal Bihani >Priority: Minor > > [https://github.com/apache/camel/blob/3aa3c12f9a60df466bbafff660d5e4009263ba78/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/RawProcessor.java#L80|https://github.com/apache/camel/blob/3aa3c12f9a60df466bbafff660d5e4009263ba78/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/RawProcessor.java#L80] > When query header is not set it throws NullPointerException. Ideally it > should set checked exception. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20597) camel-salesforce - NullPointerException when query header is missing
[ https://issues.apache.org/jira/browse/CAMEL-20597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20597: Fix Version/s: 4.5.0 > camel-salesforce - NullPointerException when query header is missing > > > Key: CAMEL-20597 > URL: https://issues.apache.org/jira/browse/CAMEL-20597 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 4.4.1 >Reporter: Vishal Bihani >Priority: Minor > Fix For: 4.0.5, 4.4.2, 4.5.0 > > > [https://github.com/apache/camel/blob/3aa3c12f9a60df466bbafff660d5e4009263ba78/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/RawProcessor.java#L80|https://github.com/apache/camel/blob/3aa3c12f9a60df466bbafff660d5e4009263ba78/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/RawProcessor.java#L80] > When query header is not set it throws NullPointerException. Ideally it > should set checked exception. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20597) camel-salesforce - NullPointerException when query header is missing
[ https://issues.apache.org/jira/browse/CAMEL-20597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20597: Fix Version/s: 4.0.5 4.4.2 > camel-salesforce - NullPointerException when query header is missing > > > Key: CAMEL-20597 > URL: https://issues.apache.org/jira/browse/CAMEL-20597 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 4.4.1 >Reporter: Vishal Bihani >Priority: Minor > Fix For: 4.0.5, 4.4.2 > > > [https://github.com/apache/camel/blob/3aa3c12f9a60df466bbafff660d5e4009263ba78/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/RawProcessor.java#L80|https://github.com/apache/camel/blob/3aa3c12f9a60df466bbafff660d5e4009263ba78/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/RawProcessor.java#L80] > When query header is not set it throws NullPointerException. Ideally it > should set checked exception. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20590) Delay to execute timeout to Camel RabbitMQ (InOut)
[
https://issues.apache.org/jira/browse/CAMEL-20590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20590:
Fix Version/s: 4.5.0
> Delay to execute timeout to Camel RabbitMQ (InOut)
> --
>
> Key: CAMEL-20590
> URL: https://issues.apache.org/jira/browse/CAMEL-20590
> Project: Camel
> Issue Type: Improvement
> Components: camel-rabbitmq
>Affects Versions: 3.20.0, 3.21.0
>Reporter: Rhuan Rocha
>Assignee: Rhuan Rocha
>Priority: Minor
> Fix For: 3.21.5, 3.22.2, 4.0.5, 4.4.2, 4.5.0
>
>
> I'm utilizing the camel-rabbitmq component to send messages to RabbitMQ with
> a specified timeout. However, I've observed that the timeout response is
> delayed. Upon debugging the Camel code
> ([https://github.com/apache/camel/blob/camel-3.21.x/components/camel-rabbitmq/src/main/java/org/apache/camel/component/rabbitmq/reply/ReplyManagerSupport.java#L217]),
> I discovered that this delay is caused by a specific line of code that
> performs a {{get}} operation on a map. This map internally uses a
> {{{}ReentrantLock{}}}, which is contributing to the delay. I think it is not
> a bug, but I think it can be improved. I propose developing a 'contains'
> method that operates without the need for locking. I'm trying to reproduce it
> outside my application and inside a simple POC.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20590) Delay to execute timeout to Camel RabbitMQ (InOut)
[
https://issues.apache.org/jira/browse/CAMEL-20590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20590:
Fix Version/s: 3.22.2
4.0.5
4.4.2
> Delay to execute timeout to Camel RabbitMQ (InOut)
> --
>
> Key: CAMEL-20590
> URL: https://issues.apache.org/jira/browse/CAMEL-20590
> Project: Camel
> Issue Type: Improvement
> Components: camel-rabbitmq
>Affects Versions: 3.20.0, 3.21.0
>Reporter: Rhuan Rocha
>Assignee: Rhuan Rocha
>Priority: Minor
> Fix For: 3.21.5, 3.22.2, 4.0.5, 4.4.2
>
>
> I'm utilizing the camel-rabbitmq component to send messages to RabbitMQ with
> a specified timeout. However, I've observed that the timeout response is
> delayed. Upon debugging the Camel code
> ([https://github.com/apache/camel/blob/camel-3.21.x/components/camel-rabbitmq/src/main/java/org/apache/camel/component/rabbitmq/reply/ReplyManagerSupport.java#L217]),
> I discovered that this delay is caused by a specific line of code that
> performs a {{get}} operation on a map. This map internally uses a
> {{{}ReentrantLock{}}}, which is contributing to the delay. I think it is not
> a bug, but I think it can be improved. I propose developing a 'contains'
> method that operates without the need for locking. I'm trying to reproduce it
> outside my application and inside a simple POC.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (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 updated CAMEL-20596:
Fix Version/s: 4.5.0
> 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.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-20590) Delay to execute timeout to Camel RabbitMQ (InOut)
[
https://issues.apache.org/jira/browse/CAMEL-20590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20590:
Fix Version/s: 3.21.5
> Delay to execute timeout to Camel RabbitMQ (InOut)
> --
>
> Key: CAMEL-20590
> URL: https://issues.apache.org/jira/browse/CAMEL-20590
> Project: Camel
> Issue Type: Improvement
> Components: camel-rabbitmq
>Affects Versions: 3.20.0, 3.21.0
>Reporter: Rhuan Rocha
>Assignee: Rhuan Rocha
>Priority: Minor
> Fix For: 3.21.5
>
>
> I'm utilizing the camel-rabbitmq component to send messages to RabbitMQ with
> a specified timeout. However, I've observed that the timeout response is
> delayed. Upon debugging the Camel code
> ([https://github.com/apache/camel/blob/camel-3.21.x/components/camel-rabbitmq/src/main/java/org/apache/camel/component/rabbitmq/reply/ReplyManagerSupport.java#L217]),
> I discovered that this delay is caused by a specific line of code that
> performs a {{get}} operation on a map. This map internally uses a
> {{{}ReentrantLock{}}}, which is contributing to the delay. I think it is not
> a bug, but I think it can be improved. I propose developing a 'contains'
> method that operates without the need for locking. I'm trying to reproduce it
> outside my application and inside a simple POC.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-20590) Delay to execute timeout to Camel RabbitMQ (InOut)
[
https://issues.apache.org/jira/browse/CAMEL-20590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-20590.
-
Resolution: Fixed
> Delay to execute timeout to Camel RabbitMQ (InOut)
> --
>
> Key: CAMEL-20590
> URL: https://issues.apache.org/jira/browse/CAMEL-20590
> Project: Camel
> Issue Type: Improvement
> Components: camel-rabbitmq
>Affects Versions: 3.20.0, 3.21.0
>Reporter: Rhuan Rocha
>Assignee: Rhuan Rocha
>Priority: Minor
> Fix For: 3.21.5, 3.22.2, 4.0.5, 4.4.2, 4.5.0
>
>
> I'm utilizing the camel-rabbitmq component to send messages to RabbitMQ with
> a specified timeout. However, I've observed that the timeout response is
> delayed. Upon debugging the Camel code
> ([https://github.com/apache/camel/blob/camel-3.21.x/components/camel-rabbitmq/src/main/java/org/apache/camel/component/rabbitmq/reply/ReplyManagerSupport.java#L217]),
> I discovered that this delay is caused by a specific line of code that
> performs a {{get}} operation on a map. This map internally uses a
> {{{}ReentrantLock{}}}, which is contributing to the delay. I think it is not
> a bug, but I think it can be improved. I propose developing a 'contains'
> method that operates without the need for locking. I'm trying to reproduce it
> outside my application and inside a simple POC.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20597) NullPointerException when query header is missing
[ https://issues.apache.org/jira/browse/CAMEL-20597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829710#comment-17829710 ] Vishal Bihani commented on CAMEL-20597: --- PR: [https://github.com/apache/camel/pull/13575|https://github.com/apache/camel/pull/13575] > NullPointerException when query header is missing > - > > Key: CAMEL-20597 > URL: https://issues.apache.org/jira/browse/CAMEL-20597 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 4.4.1 >Reporter: Vishal Bihani >Priority: Minor > > [https://github.com/apache/camel/blob/3aa3c12f9a60df466bbafff660d5e4009263ba78/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/RawProcessor.java#L80|https://github.com/apache/camel/blob/3aa3c12f9a60df466bbafff660d5e4009263ba78/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/RawProcessor.java#L80] > When query header is not set it throws NullPointerException. Ideally it > should set checked exception. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20597) NullPointerException when query header is missing
Vishal Bihani created CAMEL-20597: - Summary: NullPointerException when query header is missing Key: CAMEL-20597 URL: https://issues.apache.org/jira/browse/CAMEL-20597 Project: Camel Issue Type: Bug Components: camel-salesforce Affects Versions: 4.4.1 Reporter: Vishal Bihani [https://github.com/apache/camel/blob/3aa3c12f9a60df466bbafff660d5e4009263ba78/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/RawProcessor.java#L80|https://github.com/apache/camel/blob/3aa3c12f9a60df466bbafff660d5e4009263ba78/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/RawProcessor.java#L80] When query header is not set it throws NullPointerException. Ideally it should set checked exception. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (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
]
Dylan Piergies updated CAMEL-20596:
---
Description:
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.
was:
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:
https://github.com/apache/camel/pull/13574
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 acceptable for a patch release.
> 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
>
> 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-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
]
Dylan Piergies updated CAMEL-20596:
---
Description:
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:
https://github.com/apache/camel/pull/13574
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 acceptable for a patch release.
was:
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:
https://github.com/apache/camel/pull/13574
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 acceptable for a patch release.
> 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
>
> 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:
> https://github.com/apache/camel/pull/13574
> 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 acceptable for a patch
> release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (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
]
Dylan Piergies updated CAMEL-20596:
---
Description:
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:
https://github.com/apache/camel/pull/13574
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 acceptable for a patch release.
was:
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. Will create a
PR once I have the JIRA number.
> 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
>
> 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:
> https://github.com/apache/camel/pull/13574
> 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 acceptable for a patch
> release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20596) Propagate Azure Service Bus message headers (properties) to Camel Message
Dylan Piergies created CAMEL-20596:
--
Summary: 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
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. Will create a
PR once I have the JIRA number.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19667) camel-tracing: Context is not propagated from exchange header to OpenTelemetry Context
[
https://issues.apache.org/jira/browse/CAMEL-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829640#comment-17829640
]
John Poth commented on CAMEL-19667:
---
Unfortunately, naively putting,
{code:java}
from("timer:tick?period=5s)
.process("myProcessor");
public class MyProcessor implements Processor {
@Override
public void process(Exchange exchange) {
// OpenTelemetry Context is here
}
}
{code}
In a Unit Test does not reproduce the issue and the Context is correctly
propagated. We also have an OpenTelemetry example using Kafka [1] which
correctly propagates the Context.
[1]
[https://github.com/apache/camel-spring-boot-examples/tree/main/opentelemetry]
> camel-tracing: Context is not propagated from exchange header to
> OpenTelemetry Context
> --
>
> Key: CAMEL-19667
> URL: https://issues.apache.org/jira/browse/CAMEL-19667
> Project: Camel
> Issue Type: Improvement
> Components: camel-opentelemetry, camel-tracing
>Affects Versions: 3.20.5, 3.20.6, 3.21.0, 4.0-M3
>Reporter: Roman Kvasnytskyi
>Priority: Major
> Labels: bug, opentelemetry, tracing
> Fix For: 4.x
>
> Attachments: screenshot-1.png
>
>
> I am using OpenTelemetry Agent for tracing along with
> camel-opentelemetry-starter that configures OpenTelemetryTracer for Camel
> aligned with camel-tracing.
> I see my spans for Camel inside a single trace, but after control is passed
> to the Processor process method next spans are disassociated from the trace
> and are created in the separate trace.
> The tracing context does not seem to get propagated, and the resulting spans
> end up being disassociated. For example:
> {code:java}
> from("timer:tick?period=5s)
> .process("myProcessor");
> {code}
> {code:java}
> public class MyProcessor implements Processor {
> private final HttpClient someClient = new HttpClient();
> @Override
> public void process(Exchange exchange) {
> // http client is instrumented and also produces spans
> someClient.get('/example');
> }
> }
> {code}
> This results in 2 spans. One for timer:tick & another for a client call. The
> problem is that the parent span for client calls is not set, so they appear
> as 2 distinct traces.
> My exchange headers contain traceparent header with all data which should be
> put inside the OpenTelemetry context, but they do not.
> I have come up with a workaround. The idea is trivial - get traceparent
> header if it is present in exchange, parse trace metadata from it, create a
> SpanContext object, and put it as a parent for the current OpenTelemetry
> context.
> It looks like this:
> {code:java}
> public class TraceEnrichingProcessor implements Processor {
> private final Processor delegate;
> public TraceEnrichingProcessor(Processor delegate) {
> this.delegate = delegate;
> }
> @Override
> public void process(Exchange exchange) throws Exception {
> // Get the existing traceparent header from the Exchange
> String traceparent = exchange.getIn().getHeader("traceparent",
> String.class);
> if (traceparent != null && !traceparent.isEmpty()) {
> // Extract the traceId, parentSpanId and sampleFlag
> String[] parts = traceparent.split("-");
> String traceId = parts[1];
> String parentSpanId = parts[2];
> boolean isSampled = parts[3].equals("01");
> // Create the parent SpanContext
> SpanContext parentContext = SpanContext.create(
> traceId,
> parentSpanId,
> isSampled ? TraceFlags.getSampled() : TraceFlags.getDefault(),
> TraceState.getDefault()
> );
> // Attach the parent SpanContext to the current Context
> try (Scope scope =
> Context.current().with(Span.wrap(parentContext)).makeCurrent()) {
> // Now, the current Context has the parent SpanContext
> attached,
> // and any new spans created within this scope will use it as
> their parent
>
> // Pass control to the delegate processor
> delegate.process(exchange);
> }
> } else {
> // If no traceparent header is found, just delegate without
> modifying the Context
> delegate.process(exchange);
> }
> }
> } {code}
> Inside OpenTelemetry Agent, they dropped support of Camel 3.x+, because Camel
> provides its module for tracing, and they will not help with it.
> [Link|https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/4052]
> I wonder if that can be done inside Camel to propagate context from the
[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=17829634#comment-17829634
]
John Poth commented on CAMEL-19469:
---
I'm also curious about the use case. The
[OpenTelemetryTracingStrategy|https://github.com/apache/camel/blob/main/components/camel-opentelemetry/src/main/java/org/apache/camel/opentelemetry/OpenTelemetryTracingStrategy.java#L64]
already creates a Span for Processors. It seems adding @WithSpan would just
create another identical Span.
Unfortunately, naively putting,
{code:java}
// Some comments here
from("timer:tick?period=5s)
.process("myProcessor");
public class MyProcessor implements Processor {
@WithSpan
@Override
public void process(Exchange exchange) {
// Useful work here...
}
}
{code}
In a Unit test does not reproduce the issue and the Context is correctly
propagated.
> 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] [Comment Edited] (CAMEL-19667) camel-tracing: Context is not propagated from exchange header to OpenTelemetry Context
[
https://issues.apache.org/jira/browse/CAMEL-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829595#comment-17829595
]
Davin Taddeo edited comment on CAMEL-19667 at 3/21/24 2:59 PM:
---
Another workaround, in v4.4.0. Going against the recommended operations was
really the only way we were able to get things working. You can use the
`ActiveSpanManager` from the `camel-tracing` component to get the current span
context and make it current. Looking at this [branch of my example
app|https://github.com/tdarwin/camel-kafka-demo-tracing/tree/restore-exchange-span-context],
we've got a couple examples of doing this
You can use ActiveSpanManager the way the camel-opentelemetry component does,
to cast the processor's span as a camelSpan, then you can use that span with
the makeCurrent function to get an AutoCloseable for your functions.
{code:java}
from("kafka:pageviews?brokers=localhost:9092")
.process(exchange -> {
// We're not supposed to use ActiveSpanManager directly, but
// camel-opentelemetry doesn't seem to provide a way to get the current
span.
OpenTelemetrySpanAdapter camelSpan = (OpenTelemetrySpanAdapter)
ActiveSpanManager.getSpan(exchange);
try (AutoCloseable scope = camelSpan.makeCurrent()) {
// Custom processing logic
modifyBody(exchange);
}
})
.to("kafka:viewedpages?brokers=localhost:9092")
.to("log:partone-done");
{code}
You could also just skip the OpenTelemetrySpanAdapter bit and just grab the
AutoCloseable from the ActiveSpanManager class in camel-tracing. We were trying
to do this without going to the option, since it says don't do it... But
there's no way to get the context working an not do it that we can see, aside
from the workaround from the OP to manually break down the kafka header to get
the traceparent header and link into the trace that way.
{code:java}
from("kafka:viewedpages?brokers=localhost:9092")
.process(exchange -> {
try (AutoCloseable scope =
ActiveSpanManager.getSpan(exchange).makeCurrent()) {
modifyBody(exchange);
}
})
.to("kafka:processedviews?brokers=localhost:9092")
.to("log:processedviews");{code}
[~davsclaus], If something could be added to camel-opentelemetry's
OpenTelemetryTracer class, that would work like the getSpan method, that would
at least make this easier, without having to dip into classes from the
camel-tracing compoent. Assuming the camel-opentelemetry component itself can't
be updated to just play nice with OTEL's @WithSpan decorators nicely on its
own... This will at least get people a simpler method to get into current
context where they _can_ then use the @WithSpan decorator later on.
was (Author: JIRAUSER304603):
Another workaround, in v4.4.0. Going against the recommended operations was
really the only way we were able to get things working. You can use the
`ActiveSpanManager` from the `camel-tracing` component to get the current span
context and make it current. Looking at this [branch of my example
app|https://github.com/tdarwin/camel-kafka-demo-tracing/tree/restore-exchange-span-context],
we've got a couple examples of doing this
You can use ActiveSpanManager the way the camel-opentelemetry component does,
to cast the processor's span as a camelSpan, then you can use that span with
the makeCurrent function to get an AutoCloseable for your functions.
```java
from("kafka:pageviews?brokers=localhost:9092")
.process(exchange -> {
// We're not supposed to use ActiveSpanManager directly, but
// camel-opentelemetry doesn't seem to provide a way to get the current
span.
OpenTelemetrySpanAdapter camelSpan = (OpenTelemetrySpanAdapter)
ActiveSpanManager.getSpan(exchange);
try (AutoCloseable scope = camelSpan.makeCurrent()) {
// Custom processing logic
modifyBody(exchange);
}
})
.to("kafka:viewedpages?brokers=localhost:9092")
```
You could also just skip the OpenTelemetrySpanAdapter bit and just grab the
AutoCloseable from the ActiveSpanManager class in camel-tracing. We were trying
to do this without going to the option, since it says don't do it... But
there's no way to get the context working an not do it that we can see, aside
from the workaround from the OP to manually break down the kafka header to get
the traceparent header and link into the trace that way.
```java
from("kafka:viewedpages?brokers=localhost:9092")
.process(exchange -> {
try (AutoCloseable scope =
ActiveSpanManager.getSpan(exchange).makeCurrent()) {
modifyBody(exchange);
}
})
.to("kafka:processedviews?brokers=localhost:9092")
.to("log:processedviews");
```
[~davsclaus], If something could be added to camel-opentelemetry's
OpenTelemetryTracer class, that would
[jira] [Commented] (CAMEL-19667) camel-tracing: Context is not propagated from exchange header to OpenTelemetry Context
[
https://issues.apache.org/jira/browse/CAMEL-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829595#comment-17829595
]
Davin Taddeo commented on CAMEL-19667:
--
Another workaround, in v4.4.0. Going against the recommended operations was
really the only way we were able to get things working. You can use the
`ActiveSpanManager` from the `camel-tracing` component to get the current span
context and make it current. Looking at this [branch of my example
app|https://github.com/tdarwin/camel-kafka-demo-tracing/tree/restore-exchange-span-context],
we've got a couple examples of doing this
You can use ActiveSpanManager the way the camel-opentelemetry component does,
to cast the processor's span as a camelSpan, then you can use that span with
the makeCurrent function to get an AutoCloseable for your functions.
```java
from("kafka:pageviews?brokers=localhost:9092")
.process(exchange -> {
// We're not supposed to use ActiveSpanManager directly, but
// camel-opentelemetry doesn't seem to provide a way to get the current
span.
OpenTelemetrySpanAdapter camelSpan = (OpenTelemetrySpanAdapter)
ActiveSpanManager.getSpan(exchange);
try (AutoCloseable scope = camelSpan.makeCurrent()) {
// Custom processing logic
modifyBody(exchange);
}
})
.to("kafka:viewedpages?brokers=localhost:9092")
```
You could also just skip the OpenTelemetrySpanAdapter bit and just grab the
AutoCloseable from the ActiveSpanManager class in camel-tracing. We were trying
to do this without going to the option, since it says don't do it... But
there's no way to get the context working an not do it that we can see, aside
from the workaround from the OP to manually break down the kafka header to get
the traceparent header and link into the trace that way.
```java
from("kafka:viewedpages?brokers=localhost:9092")
.process(exchange -> {
try (AutoCloseable scope =
ActiveSpanManager.getSpan(exchange).makeCurrent()) {
modifyBody(exchange);
}
})
.to("kafka:processedviews?brokers=localhost:9092")
.to("log:processedviews");
```
[~davsclaus], If something could be added to camel-opentelemetry's
OpenTelemetryTracer class, that would work like the getSpan method, that would
at least make this easier, without having to dip into classes from the
camel-tracing compoent. Assuming the camel-opentelemetry component itself
can't be updated to just play nice with OTEL's @WithSpan decorators nicely on
its own... This will at least get people a simpler method to get into current
context where they _can_ then use the @WithSpan decorator later on.
> camel-tracing: Context is not propagated from exchange header to
> OpenTelemetry Context
> --
>
> Key: CAMEL-19667
> URL: https://issues.apache.org/jira/browse/CAMEL-19667
> Project: Camel
> Issue Type: Improvement
> Components: camel-opentelemetry, camel-tracing
>Affects Versions: 3.20.5, 3.20.6, 3.21.0, 4.0-M3
>Reporter: Roman Kvasnytskyi
>Priority: Major
> Labels: bug, opentelemetry, tracing
> Fix For: 4.x
>
> Attachments: screenshot-1.png
>
>
> I am using OpenTelemetry Agent for tracing along with
> camel-opentelemetry-starter that configures OpenTelemetryTracer for Camel
> aligned with camel-tracing.
> I see my spans for Camel inside a single trace, but after control is passed
> to the Processor process method next spans are disassociated from the trace
> and are created in the separate trace.
> The tracing context does not seem to get propagated, and the resulting spans
> end up being disassociated. For example:
> {code:java}
> from("timer:tick?period=5s)
> .process("myProcessor");
> {code}
> {code:java}
> public class MyProcessor implements Processor {
> private final HttpClient someClient = new HttpClient();
> @Override
> public void process(Exchange exchange) {
> // http client is instrumented and also produces spans
> someClient.get('/example');
> }
> }
> {code}
> This results in 2 spans. One for timer:tick & another for a client call. The
> problem is that the parent span for client calls is not set, so they appear
> as 2 distinct traces.
> My exchange headers contain traceparent header with all data which should be
> put inside the OpenTelemetry context, but they do not.
> I have come up with a workaround. The idea is trivial - get traceparent
> header if it is present in exchange, parse trace metadata from it, create a
> SpanContext object, and put it as a parent for the current OpenTelemetry
> context.
> It looks like this:
> {code:java}
> public class TraceEnrichingProcessor implements Processor {
> private final
[jira] [Resolved] (CAMEL-20589) camel-jbang - Make it easy to run activemq with vm transport
[
https://issues.apache.org/jira/browse/CAMEL-20589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-20589.
-
Resolution: Fixed
> camel-jbang - Make it easy to run activemq with vm transport
>
>
> Key: CAMEL-20589
> URL: https://issues.apache.org/jira/browse/CAMEL-20589
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 4.5.0
>
>
> camel-activemq uses tcp:localhost:61616 by default, but we should make it
> possible to run via vm embedded instead
> camel run
> https://github.com/apache/camel/blob/camel-1.0.0/examples/camel-example-spring/src/main/java/org/apache/camel/example/spring/MyRouteBuilder.java
> --prop=camel.component.activemq.brokerUrl=vm://localhost
> However I get an error
> 2024-03-20 22:20:33.743 ERROR 11245 --- [r[test.MyQueue]]
> .DefaultJmsMessageListenerContainer : Could not refresh JMS Connection for
> destination 'test.MyQueue' - retrying using FixedBackOff{interval=5000,
> currentAttempts=1, maxAttempts=unlimited}. Cause: Could not create Transport.
> Reason: java.io.IOException: Transport scheme NOT recognized: [vm]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20589) camel-jbang - Make it easy to run activemq with vm transport
[
https://issues.apache.org/jira/browse/CAMEL-20589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829589#comment-17829589
]
Claus Ibsen commented on CAMEL-20589:
-
You can now set embedded=true on activemq component
> camel-jbang - Make it easy to run activemq with vm transport
>
>
> Key: CAMEL-20589
> URL: https://issues.apache.org/jira/browse/CAMEL-20589
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 4.5.0
>
>
> camel-activemq uses tcp:localhost:61616 by default, but we should make it
> possible to run via vm embedded instead
> camel run
> https://github.com/apache/camel/blob/camel-1.0.0/examples/camel-example-spring/src/main/java/org/apache/camel/example/spring/MyRouteBuilder.java
> --prop=camel.component.activemq.brokerUrl=vm://localhost
> However I get an error
> 2024-03-20 22:20:33.743 ERROR 11245 --- [r[test.MyQueue]]
> .DefaultJmsMessageListenerContainer : Could not refresh JMS Connection for
> destination 'test.MyQueue' - retrying using FixedBackOff{interval=5000,
> currentAttempts=1, maxAttempts=unlimited}. Cause: Could not create Transport.
> Reason: java.io.IOException: Transport scheme NOT recognized: [vm]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-20589) camel-jbang - Make it easy to run activemq with vm transport
[
https://issues.apache.org/jira/browse/CAMEL-20589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-20589:
---
Assignee: Claus Ibsen
> camel-jbang - Make it easy to run activemq with vm transport
>
>
> Key: CAMEL-20589
> URL: https://issues.apache.org/jira/browse/CAMEL-20589
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 4.x
>
>
> camel-activemq uses tcp:localhost:61616 by default, but we should make it
> possible to run via vm embedded instead
> camel run
> https://github.com/apache/camel/blob/camel-1.0.0/examples/camel-example-spring/src/main/java/org/apache/camel/example/spring/MyRouteBuilder.java
> --prop=camel.component.activemq.brokerUrl=vm://localhost
> However I get an error
> 2024-03-20 22:20:33.743 ERROR 11245 --- [r[test.MyQueue]]
> .DefaultJmsMessageListenerContainer : Could not refresh JMS Connection for
> destination 'test.MyQueue' - retrying using FixedBackOff{interval=5000,
> currentAttempts=1, maxAttempts=unlimited}. Cause: Could not create Transport.
> Reason: java.io.IOException: Transport scheme NOT recognized: [vm]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20589) camel-jbang - Make it easy to run activemq with vm transport
[
https://issues.apache.org/jira/browse/CAMEL-20589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20589:
Fix Version/s: 4.5.0
(was: 4.x)
> camel-jbang - Make it easy to run activemq with vm transport
>
>
> Key: CAMEL-20589
> URL: https://issues.apache.org/jira/browse/CAMEL-20589
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 4.5.0
>
>
> camel-activemq uses tcp:localhost:61616 by default, but we should make it
> possible to run via vm embedded instead
> camel run
> https://github.com/apache/camel/blob/camel-1.0.0/examples/camel-example-spring/src/main/java/org/apache/camel/example/spring/MyRouteBuilder.java
> --prop=camel.component.activemq.brokerUrl=vm://localhost
> However I get an error
> 2024-03-20 22:20:33.743 ERROR 11245 --- [r[test.MyQueue]]
> .DefaultJmsMessageListenerContainer : Could not refresh JMS Connection for
> destination 'test.MyQueue' - retrying using FixedBackOff{interval=5000,
> currentAttempts=1, maxAttempts=unlimited}. Cause: Could not create Transport.
> Reason: java.io.IOException: Transport scheme NOT recognized: [vm]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20595) camel-dlj - Move into camel-ai
Claus Ibsen created CAMEL-20595: --- Summary: 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 Fix For: 4.x 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] [Updated] (CAMEL-20590) Delay to execute timeout to Camel RabbitMQ (InOut)
[
https://issues.apache.org/jira/browse/CAMEL-20590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20590:
Priority: Minor (was: Major)
> Delay to execute timeout to Camel RabbitMQ (InOut)
> --
>
> Key: CAMEL-20590
> URL: https://issues.apache.org/jira/browse/CAMEL-20590
> Project: Camel
> Issue Type: Improvement
> Components: camel-rabbitmq
>Affects Versions: 3.20.0, 3.21.0
>Reporter: Rhuan Rocha
>Assignee: Rhuan Rocha
>Priority: Minor
>
> I'm utilizing the camel-rabbitmq component to send messages to RabbitMQ with
> a specified timeout. However, I've observed that the timeout response is
> delayed. Upon debugging the Camel code
> ([https://github.com/apache/camel/blob/camel-3.21.x/components/camel-rabbitmq/src/main/java/org/apache/camel/component/rabbitmq/reply/ReplyManagerSupport.java#L217]),
> I discovered that this delay is caused by a specific line of code that
> performs a {{get}} operation on a map. This map internally uses a
> {{{}ReentrantLock{}}}, which is contributing to the delay. I think it is not
> a bug, but I think it can be improved. I propose developing a 'contains'
> method that operates without the need for locking. I'm trying to reproduce it
> outside my application and inside a simple POC.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18855) camel-tests: Investigate using in-memory filesystems
[ https://issues.apache.org/jira/browse/CAMEL-18855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske updated CAMEL-18855: - Affects Version/s: 4.4.0 4.5.0 > camel-tests: Investigate using in-memory filesystems > > > Key: CAMEL-18855 > URL: https://issues.apache.org/jira/browse/CAMEL-18855 > Project: Camel > Issue Type: Improvement > Components: tests >Affects Versions: 3.20.0, 4.4.0, 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Minor > Labels: easy, help-wanted > > Our tests are very slow to run. We need to investigate if using an in-memory > filesystem can help them run faster: > > * [https://github.com/marschall/memoryfilesystem] > * [https://github.com/google/jimfs] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-18855) camel-tests: Investigate using in-memory filesystems
[ https://issues.apache.org/jira/browse/CAMEL-18855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske reassigned CAMEL-18855: Assignee: (was: Otavio Rodolfo Piske) > camel-tests: Investigate using in-memory filesystems > > > Key: CAMEL-18855 > URL: https://issues.apache.org/jira/browse/CAMEL-18855 > Project: Camel > Issue Type: Improvement > Components: tests >Affects Versions: 3.20.0, 4.4.0, 4.5.0 >Reporter: Otavio Rodolfo Piske >Priority: Minor > Labels: easy, help-wanted > > Our tests are very slow to run. We need to investigate if using an in-memory > filesystem can help them run faster: > > * [https://github.com/marschall/memoryfilesystem] > * [https://github.com/google/jimfs] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19781) camel-core: excessive occurrence of type misses may be hurting performance
[ https://issues.apache.org/jira/browse/CAMEL-19781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske resolved CAMEL-19781. -- Resolution: Won't Fix A lot of the work for this was done on the linked issues. With the prospect of this issue being fixed directly on the JVM, I think it's pointless to rework the code for this. > camel-core: excessive occurrence of type misses may be hurting performance > -- > > Key: CAMEL-19781 > URL: https://issues.apache.org/jira/browse/CAMEL-19781 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 4.1.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Fix For: 4.x > > Attachments: type-misses.txt > > > Our code has an excessive amount of type misses that may be hurting > performance due to [JDK-8180450|https://bugs.openjdk.org/browse/JDK-8180450] > and how the underlying implementation of type checks work in the JVM. > Using the type pollution agent, we can see that there is a significant number > of type misses in a sample execution of a Routing Slip using a bean to > resolve the endpoints (see the attachment for details). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20015) camel-core: cleanup cyclic dependencies in the AbstractExchange
[ https://issues.apache.org/jira/browse/CAMEL-20015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske updated CAMEL-20015: - Priority: Minor (was: Major) > camel-core: cleanup cyclic dependencies in the AbstractExchange > --- > > Key: CAMEL-20015 > URL: https://issues.apache.org/jira/browse/CAMEL-20015 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Minor > > As part of CAMEL-15105 we decoupled the ExtendedExchange from the > AbstractExchange. This helped us reduce the incidence of type polution > problems, cleanup and simplify the code. > However, there's still many cases of cyclic dependencies between these two > types. We should move the handling of the internal APIs fully to the > extension class. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20477) camel-jms: test flakiness
[ https://issues.apache.org/jira/browse/CAMEL-20477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske resolved CAMEL-20477. -- Resolution: Fixed It looks like the recent set of fixes resolved our problems with JMS flakies. Closing it. > camel-jms: test flakiness > - > > Key: CAMEL-20477 > URL: https://issues.apache.org/jira/browse/CAMEL-20477 > Project: Camel > Issue Type: Test > Components: camel-jms >Affects Versions: 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Fix For: 4.5.0 > > > There's seems to be a higher incidence of test flakiness on JMS lately. We > should investigate and Fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20477) camel-jms: test flakiness
[ https://issues.apache.org/jira/browse/CAMEL-20477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829533#comment-17829533 ] Otavio Rodolfo Piske commented on CAMEL-20477: -- Yeah, I think we can close this one. I haven't seen JMS flakies for a while. > camel-jms: test flakiness > - > > Key: CAMEL-20477 > URL: https://issues.apache.org/jira/browse/CAMEL-20477 > Project: Camel > Issue Type: Test > Components: camel-jms >Affects Versions: 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Fix For: 4.5.0 > > > There's seems to be a higher incidence of test flakiness on JMS lately. We > should investigate and Fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20477) camel-jms: test flakiness
[ https://issues.apache.org/jira/browse/CAMEL-20477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829532#comment-17829532 ] Claus Ibsen commented on CAMEL-20477: - Is the flakes fixed > camel-jms: test flakiness > - > > Key: CAMEL-20477 > URL: https://issues.apache.org/jira/browse/CAMEL-20477 > Project: Camel > Issue Type: Test > Components: camel-jms >Affects Versions: 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Fix For: 4.5.0 > > > There's seems to be a higher incidence of test flakiness on JMS lately. We > should investigate and Fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20499) tests: consolidate failsafe configuration
[ https://issues.apache.org/jira/browse/CAMEL-20499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20499: Component/s: build system tests > tests: consolidate failsafe configuration > - > > Key: CAMEL-20499 > URL: https://issues.apache.org/jira/browse/CAMEL-20499 > Project: Camel > Issue Type: Task > Components: build system, tests >Affects Versions: 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Fix For: 4.6.0 > > > We are starting to have multiple failsafe configurations in pom files. Let's > consolidate those. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20499) tests: consolidate failsafe configuration
[ https://issues.apache.org/jira/browse/CAMEL-20499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20499: Fix Version/s: 4.6.0 (was: 4.5.0) > tests: consolidate failsafe configuration > - > > Key: CAMEL-20499 > URL: https://issues.apache.org/jira/browse/CAMEL-20499 > Project: Camel > Issue Type: Task >Affects Versions: 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Fix For: 4.6.0 > > > We are starting to have multiple failsafe configurations in pom files. Let's > consolidate those. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20592) camel-kafka - Upgrade to 3.7
[ https://issues.apache.org/jira/browse/CAMEL-20592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-20592. - Resolution: Fixed > camel-kafka - Upgrade to 3.7 > > > Key: CAMEL-20592 > URL: https://issues.apache.org/jira/browse/CAMEL-20592 > Project: Camel > Issue Type: Dependency upgrade > Components: camel-kafka >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 4.5.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20594) Camel-Milvus: Add a datatype for transforming langchain embeddings in Milvus objects
Andrea Cosentino created CAMEL-20594: Summary: 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 Fix For: 4.5.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20593) camel-kafka - Use official ASF docker images instead of confluent
Claus Ibsen created CAMEL-20593: --- Summary: camel-kafka - Use official ASF docker images instead of confluent Key: CAMEL-20593 URL: https://issues.apache.org/jira/browse/CAMEL-20593 Project: Camel Issue Type: Dependency upgrade Components: camel-kafka Reporter: Claus Ibsen Fix For: 4.x There are ASF images now we should favour using https://hub.docker.com/r/apache/kafka/tags -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20592) camel-kafka - Upgrade to 3.7
[ https://issues.apache.org/jira/browse/CAMEL-20592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-20592: --- Assignee: Claus Ibsen > camel-kafka - Upgrade to 3.7 > > > Key: CAMEL-20592 > URL: https://issues.apache.org/jira/browse/CAMEL-20592 > Project: Camel > Issue Type: Dependency upgrade > Components: camel-kafka >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 4.5.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20591) Add a method to set muteException/logException option in restConfiguration
[
https://issues.apache.org/jira/browse/CAMEL-20591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-20591.
-
Resolution: Information Provided
> Add a method to set muteException/logException option in restConfiguration
> --
>
> Key: CAMEL-20591
> URL: https://issues.apache.org/jira/browse/CAMEL-20591
> Project: Camel
> Issue Type: New Feature
> Components: camel-atmosphere-websocket, camel-http-common,
> camel-jetty, camel-servlet
>Reporter: Branislav Smolicek
>Priority: Major
> Attachments: bean-validator.zip
>
>
> Since Camel 4.1.0, by default, stack traces are not included in HTTP
> responses and exceptions are muted.
> [https://camel.apache.org/manual/camel-4x-upgrade-guide-4_1.html#_camel_jetty_camel_servlet_camel_atmosphere_websocket_camel_http_common]
>
> It would be nice to have a way to set *muteException* and *logException* like
> this:
> {code:java}
> restConfiguration().component("servlet").muteException(false);{code}
> So that users don't have to set application properties.
> In the attached reproducer [^bean-validator.zip] it's not possible to set
> with route option as the documentation suggests. Only by setting application
> property:
> {code:java}
> camel.component.servlet.mute-exception=false {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20591) Add a method to set muteException/logException option in restConfiguration
[
https://issues.apache.org/jira/browse/CAMEL-20591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829465#comment-17829465
]
Claus Ibsen commented on CAMEL-20591:
-
the servlet component is likely already created at that point in time so the
option may not affect it.
> Add a method to set muteException/logException option in restConfiguration
> --
>
> Key: CAMEL-20591
> URL: https://issues.apache.org/jira/browse/CAMEL-20591
> Project: Camel
> Issue Type: New Feature
> Components: camel-atmosphere-websocket, camel-http-common,
> camel-jetty, camel-servlet
>Reporter: Branislav Smolicek
>Priority: Major
> Attachments: bean-validator.zip
>
>
> Since Camel 4.1.0, by default, stack traces are not included in HTTP
> responses and exceptions are muted.
> [https://camel.apache.org/manual/camel-4x-upgrade-guide-4_1.html#_camel_jetty_camel_servlet_camel_atmosphere_websocket_camel_http_common]
>
> It would be nice to have a way to set *muteException* and *logException* like
> this:
> {code:java}
> restConfiguration().component("servlet").muteException(false);{code}
> So that users don't have to set application properties.
> In the attached reproducer [^bean-validator.zip] it's not possible to set
> with route option as the documentation suggests. Only by setting application
> property:
> {code:java}
> camel.component.servlet.mute-exception=false {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20591) Add a method to set muteException/logException option in restConfiguration
[
https://issues.apache.org/jira/browse/CAMEL-20591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829464#comment-17829464
]
Federico Mariani commented on CAMEL-20591:
--
Actually, componentProperty is not working as expected (though, it should from
the documentation), but endpointProperty is working
_restConfiguration().component("servlet").endpointProperty("muteException",
"false"); (/)_
> Add a method to set muteException/logException option in restConfiguration
> --
>
> Key: CAMEL-20591
> URL: https://issues.apache.org/jira/browse/CAMEL-20591
> Project: Camel
> Issue Type: New Feature
> Components: camel-atmosphere-websocket, camel-http-common,
> camel-jetty, camel-servlet
>Reporter: Branislav Smolicek
>Priority: Major
> Attachments: bean-validator.zip
>
>
> Since Camel 4.1.0, by default, stack traces are not included in HTTP
> responses and exceptions are muted.
> [https://camel.apache.org/manual/camel-4x-upgrade-guide-4_1.html#_camel_jetty_camel_servlet_camel_atmosphere_websocket_camel_http_common]
>
> It would be nice to have a way to set *muteException* and *logException* like
> this:
> {code:java}
> restConfiguration().component("servlet").muteException(false);{code}
> So that users don't have to set application properties.
> In the attached reproducer [^bean-validator.zip] it's not possible to set
> with route option as the documentation suggests. Only by setting application
> property:
> {code:java}
> camel.component.servlet.mute-exception=false {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20591) Add a method to set muteException/logException option in restConfiguration
[
https://issues.apache.org/jira/browse/CAMEL-20591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829435#comment-17829435
]
Claus Ibsen commented on CAMEL-20591:
-
You can do this with rest-dsl, see the componentProperty in the docs
https://camel.apache.org/manual/rest-dsl.html
> Add a method to set muteException/logException option in restConfiguration
> --
>
> Key: CAMEL-20591
> URL: https://issues.apache.org/jira/browse/CAMEL-20591
> Project: Camel
> Issue Type: New Feature
> Components: camel-atmosphere-websocket, camel-http-common,
> camel-jetty, camel-servlet
>Reporter: Branislav Smolicek
>Priority: Major
> Attachments: bean-validator.zip
>
>
> Since Camel 4.1.0, by default, stack traces are not included in HTTP
> responses and exceptions are muted.
> [https://camel.apache.org/manual/camel-4x-upgrade-guide-4_1.html#_camel_jetty_camel_servlet_camel_atmosphere_websocket_camel_http_common]
>
> It would be nice to have a way to set *muteException* and *logException* like
> this:
> {code:java}
> restConfiguration().component("servlet").muteException(false);{code}
> So that users don't have to set application properties.
> In the attached reproducer [^bean-validator.zip] it's not possible to set
> with route option as the documentation suggests. Only by setting application
> property:
> {code:java}
> camel.component.servlet.mute-exception=false {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20592) camel-kafka - Upgrade to 3.7
[ https://issues.apache.org/jira/browse/CAMEL-20592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829431#comment-17829431 ] Claus Ibsen commented on CAMEL-20592: - The 3.7.0 should be backwards compatible, but there may be some new options we may want to expose in camel-kafka https://cwiki.apache.org/confluence/display/KAFKA/KIP-580%3A+Exponential+Backoff+for+Kafka+Clients > camel-kafka - Upgrade to 3.7 > > > Key: CAMEL-20592 > URL: https://issues.apache.org/jira/browse/CAMEL-20592 > Project: Camel > Issue Type: Dependency upgrade > Components: camel-kafka >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.5.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20592) camel-kafka - Upgrade to 3.7
Claus Ibsen created CAMEL-20592: --- Summary: camel-kafka - Upgrade to 3.7 Key: CAMEL-20592 URL: https://issues.apache.org/jira/browse/CAMEL-20592 Project: Camel Issue Type: Dependency upgrade Components: camel-kafka Reporter: Claus Ibsen Fix For: 4.5.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20592) camel-kafka - Upgrade to 3.7
[ https://issues.apache.org/jira/browse/CAMEL-20592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829430#comment-17829430 ] Claus Ibsen commented on CAMEL-20592: - https://github.com/apache/camel/pull/13526 > camel-kafka - Upgrade to 3.7 > > > Key: CAMEL-20592 > URL: https://issues.apache.org/jira/browse/CAMEL-20592 > Project: Camel > Issue Type: Dependency upgrade > Components: camel-kafka >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.5.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20591) Add a method to set muteException/logException option in restConfiguration
Branislav Smolicek created CAMEL-20591:
--
Summary: Add a method to set muteException/logException option in
restConfiguration
Key: CAMEL-20591
URL: https://issues.apache.org/jira/browse/CAMEL-20591
Project: Camel
Issue Type: New Feature
Components: camel-atmosphere-websocket, camel-http-common,
camel-jetty, camel-servlet
Reporter: Branislav Smolicek
Attachments: bean-validator.zip
Since Camel 4.1.0, by default, stack traces are not included in HTTP responses
and exceptions are muted.
[https://camel.apache.org/manual/camel-4x-upgrade-guide-4_1.html#_camel_jetty_camel_servlet_camel_atmosphere_websocket_camel_http_common]
It would be nice to have a way to set *muteException* and *logException* like
this:
{code:java}
restConfiguration().component("servlet").muteException(false);{code}
So that users don't have to set application properties.
In the attached reproducer [^bean-validator.zip] it's not possible to set with
route option as the documentation suggests. Only by setting application
property:
{code:java}
camel.component.servlet.mute-exception=false {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
