[jira] [Commented] (CAMEL-21472) Opentelemetry is using the same traceId when exchange is fired from file or timer component
[
https://issues.apache.org/jira/browse/CAMEL-21472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901212#comment-17901212
]
Pasquale Congiusti commented on CAMEL-21472:
Thanks [~ganteth], no, feel free to add any further findings and possible
fixes. As you've said, we must find the root cause and solve it at the root to
avoid introducing any regression in other paths we're not testing out of the
box. It may take a bit more time to have a final fix, but the idea is to have
something stable for all the different scenarios.
> Opentelemetry is using the same traceId when exchange is fired from file or
> timer component
> ---
>
> Key: CAMEL-21472
> URL: https://issues.apache.org/jira/browse/CAMEL-21472
> Project: Camel
> Issue Type: Bug
> Components: camel-opentelemetry
>Affects Versions: 4.8.1
>Reporter: Thomas Gantenbein
>Assignee: Pasquale Congiusti
>Priority: Major
> Fix For: 4.8.2, 4.9.0
>
> Attachments: image-2024-11-26-09-59-35-555.png
>
>
> *Problem*
> When using a consumer like {{timer}} or {{{}file{}}}, the traceId remains the
> same for all messages. When using a consumer like netty (or, I assume, any
> other http/tcp-based consumer), every call gets its own traceId as expected.
> See also
> https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Same.20OTEL.20trace.20for.20all.20messages.20into.20IBM.20MQ
> *Reproducer*
> [https://github.com/thomas-gantenbein-tga/camel-opentelemetry/tree/main]
> [~pcongiusti], thanks for your answer on Zulip Chat. Let me know if I should
> further explain or minimize that reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-21399) Kubernetes plugin regression. Fails on OCP deployments
[
https://issues.apache.org/jira/browse/CAMEL-21399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901215#comment-17901215
]
Christoph Deppisch commented on CAMEL-21399:
I think this is a duplicated to
https://issues.apache.org/jira/browse/CAMEL-21361 which is to be fixed in 4.8.2
> Kubernetes plugin regression. Fails on OCP deployments
> --
>
> Key: CAMEL-21399
> URL: https://issues.apache.org/jira/browse/CAMEL-21399
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
>Affects Versions: 4.8.1
>Reporter: Bruno Meseguer
>Priority: Minor
> Fix For: 4.8.2, 4.9.0
>
>
> All seems to work well in 4.8.0
> Operating the same commands using 4.8.1 fails.
>
> Create a Camel route, for example, with:
> {code:java}
> camel init myroute.camel.yaml{code}
>
> Then using the commands below to deploy on OpenShift (tested in Developer
> Sandbox) run
>
> {code:java}
> camel version
> JBang version: 0.119.0
> Camel JBang version: 4.8.1
> camel kubernetes run * --cluster-type=openshift --dev
> {code}
>
>
> The execution fails with:
> {code:java}
> Run: kubectl get pod -l app.kubernetes.io/name=test
> Exception in thread "main" java.util.ServiceConfigurationError:
> io.fabric8.kubernetes.api.model.KubernetesResource:
> io.fabric8.kubernetes.api.model.LimitRange not a subtype{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-21472) Opentelemetry is using the same traceId when exchange is fired from file or timer component
[
https://issues.apache.org/jira/browse/CAMEL-21472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901260#comment-17901260
]
Thomas Gantenbein commented on CAMEL-21472:
---
[~jpoth], thanks for the suggestion. No, the option synchronous=true doesn't
resolve this.
[~squakez], I've made a draft PR: [https://github.com/apache/camel/pull/16386.]
Actually, with my reproducer it works better than expected: I tried `curl -H
"traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01"
localhost:12345` and observed that traceId 4bf92f3577b34da6a3ce929d0e0e4736 was
actually assigned to the trace and a new span was created. When not sending
such a header, a new traceId would be generated. Same for the timer-route.
I don't like the fact that my "fix" is checking whether a new traceId should be
assigned when a new exchange comes in – instead of just doing whatever is
necessary when the exchange is done and no parent span exists. But this is what
seems to work for me for the moment, without me having to touch more stuff that
I don't _really_ understand.
> Opentelemetry is using the same traceId when exchange is fired from file or
> timer component
> ---
>
> Key: CAMEL-21472
> URL: https://issues.apache.org/jira/browse/CAMEL-21472
> Project: Camel
> Issue Type: Bug
> Components: camel-opentelemetry
>Affects Versions: 4.8.1
>Reporter: Thomas Gantenbein
>Assignee: Pasquale Congiusti
>Priority: Major
> Fix For: 4.8.2, 4.9.0
>
> Attachments: image-2024-11-26-09-59-35-555.png
>
>
> *Problem*
> When using a consumer like {{timer}} or {{{}file{}}}, the traceId remains the
> same for all messages. When using a consumer like netty (or, I assume, any
> other http/tcp-based consumer), every call gets its own traceId as expected.
> See also
> https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Same.20OTEL.20trace.20for.20all.20messages.20into.20IBM.20MQ
> *Reproducer*
> [https://github.com/thomas-gantenbein-tga/camel-opentelemetry/tree/main]
> [~pcongiusti], thanks for your answer on Zulip Chat. Let me know if I should
> further explain or minimize that reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-21472) Opentelemetry is using the same traceId when exchange is fired from file or timer component
[
https://issues.apache.org/jira/browse/CAMEL-21472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901206#comment-17901206
]
John Poth commented on CAMEL-21472:
---
Hi [~ganteth]! By any chance, does adding the option `synchronous=true` to the
timer and file uri fix the issue ? so "file:.&synchronous=true" and
"timer:...&synchronous=true" resolve the issue ? This reminds me of
https://issues.apache.org/jira/browse/CAMEL-21302 ... thanks !
> Opentelemetry is using the same traceId when exchange is fired from file or
> timer component
> ---
>
> Key: CAMEL-21472
> URL: https://issues.apache.org/jira/browse/CAMEL-21472
> Project: Camel
> Issue Type: Bug
> Components: camel-opentelemetry
>Affects Versions: 4.8.1
>Reporter: Thomas Gantenbein
>Assignee: Pasquale Congiusti
>Priority: Major
> Fix For: 4.8.2, 4.9.0
>
> Attachments: image-2024-11-26-09-59-35-555.png
>
>
> *Problem*
> When using a consumer like {{timer}} or {{{}file{}}}, the traceId remains the
> same for all messages. When using a consumer like netty (or, I assume, any
> other http/tcp-based consumer), every call gets its own traceId as expected.
> See also
> https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Same.20OTEL.20trace.20for.20all.20messages.20into.20IBM.20MQ
> *Reproducer*
> [https://github.com/thomas-gantenbein-tga/camel-opentelemetry/tree/main]
> [~pcongiusti], thanks for your answer on Zulip Chat. Let me know if I should
> further explain or minimize that reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-21472) Opentelemetry is using the same traceId when exchange is fired from file or timer component
[
https://issues.apache.org/jira/browse/CAMEL-21472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901213#comment-17901213
]
Pasquale Congiusti commented on CAMEL-21472:
If the actual work you've done is patching this problem, you can submit a draft
PR in the while, so, we can test any possible regression and have a first
feedback.
> Opentelemetry is using the same traceId when exchange is fired from file or
> timer component
> ---
>
> Key: CAMEL-21472
> URL: https://issues.apache.org/jira/browse/CAMEL-21472
> Project: Camel
> Issue Type: Bug
> Components: camel-opentelemetry
>Affects Versions: 4.8.1
>Reporter: Thomas Gantenbein
>Assignee: Pasquale Congiusti
>Priority: Major
> Fix For: 4.8.2, 4.9.0
>
> Attachments: image-2024-11-26-09-59-35-555.png
>
>
> *Problem*
> When using a consumer like {{timer}} or {{{}file{}}}, the traceId remains the
> same for all messages. When using a consumer like netty (or, I assume, any
> other http/tcp-based consumer), every call gets its own traceId as expected.
> See also
> https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Same.20OTEL.20trace.20for.20all.20messages.20into.20IBM.20MQ
> *Reproducer*
> [https://github.com/thomas-gantenbein-tga/camel-opentelemetry/tree/main]
> [~pcongiusti], thanks for your answer on Zulip Chat. Let me know if I should
> further explain or minimize that reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-21476) SQL Stored Procedure compont don't use definied RowMapperFactory from SQL compont
John Zander created CAMEL-21476:
---
Summary: SQL Stored Procedure compont don't use definied
RowMapperFactory from SQL compont
Key: CAMEL-21476
URL: https://issues.apache.org/jira/browse/CAMEL-21476
Project: Camel
Issue Type: Bug
Components: camel-sql
Affects Versions: 4.8.0
Reporter: John Zander
Fix For: 4.x
{color:#268bd2}Hi devs,{color}
{color:#268bd2}we are using camel to call stored-procedures which return a
non-standard datatype which is not handled by the framework. For this use case,
it is possible to define a custom RowMapperFactory which can handle that
datatype. {color}
{color:#268bd2}[https://camel.apache.org/components/4.8.x/sql-stored-component.html]{color}
{color:#268bd2}states
{color}{color:#268bd2}"camel.component.{color}{color:#268bd2}sql.{color}{color:#268bd2}row-mapper-factory"
as property to set.{color}
Unfortunately, this property doesn't become active on "sqlstored" only on plain
"sql". Please fix or change the documentation with the correct property. Thank
you!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-21476) SQL Stored Procedure compont don't use definied RowMapperFactory from SQL compont
[
https://issues.apache.org/jira/browse/CAMEL-21476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-21476:
Priority: Minor (was: Major)
> SQL Stored Procedure compont don't use definied RowMapperFactory from SQL
> compont
> --
>
> Key: CAMEL-21476
> URL: https://issues.apache.org/jira/browse/CAMEL-21476
> Project: Camel
> Issue Type: Improvement
> Components: camel-sql
>Affects Versions: 4.8.0
>Reporter: John Zander
>Priority: Minor
> Fix For: 4.x
>
>
> {color:#268bd2}Hi devs,{color}
>
> {color:#268bd2}we are using camel to call stored-procedures which return a
> non-standard datatype which is not handled by the framework. For this use
> case, it is possible to define a custom RowMapperFactory which can handle
> that datatype. {color}
>
> {color:#268bd2}[https://camel.apache.org/components/4.8.x/sql-stored-component.html]{color}
>
> {color:#268bd2}states
> {color}{color:#268bd2}"camel.component.{color}{color:#268bd2}sql.{color}{color:#268bd2}row-mapper-factory"
> as property to set.{color}
>
> Unfortunately, this property doesn't become active on "sqlstored" only on
> plain "sql". Please fix or change the documentation with the correct
> property. Thank you!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-21467) Simple expressions execute forever. Thread is RUNNABLE for ever. Issue appears with bean expressions inside simple expressions on SimpleLRUCache
[ https://issues.apache.org/jira/browse/CAMEL-21467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto reassigned CAMEL-21467: --- Assignee: Nicolas Filotto > Simple expressions execute forever. Thread is RUNNABLE for ever. Issue > appears with bean expressions inside simple expressions on SimpleLRUCache > > > Key: CAMEL-21467 > URL: https://issues.apache.org/jira/browse/CAMEL-21467 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 4.8.1 >Reporter: Jannik Schmeier >Assignee: Nicolas Filotto >Priority: Major > Fix For: 4.8.2, 4.9.0 > > > Similar to CAMEL-21432, occasionally my camel route gets stuck on > SimpleLRUCache. > The thread dump suggests, that this has to do with simple and bean > expressions. I've had two encounters with this issue in two different > applications: > *First encounter:* > "Camel (camel-1) thread #2 - JmsConsumer[]" - Thread t@58 > java.lang.Thread.State: RUNNABLE > at > org.apache.camel.support.cache.SimpleLRUCache$OperationContext.close(SimpleLRUCache.java:318) > at > org.apache.camel.support.cache.SimpleLRUCache.put(SimpleLRUCache.java:106) > at > org.apache.camel.support.cache.SimpleSoftCache.put(SimpleSoftCache.java:114) > at > org.apache.camel.component.bean.BeanComponent.addBeanInfoToCache(BeanComponent.java:96) > at org.apache.camel.component.bean.BeanInfo.(BeanInfo.java:169) > at > org.apache.camel.component.bean.ConstantBeanHolder.(ConstantBeanHolder.java:50) > at > org.apache.camel.language.bean.BeanExpression.invokeOgnlMethod(BeanExpression.java:435) > at > org.apache.camel.language.bean.BeanExpression.evaluate(BeanExpression.java:218) > at > org.apache.camel.language.bean.BeanExpression.evaluate(BeanExpression.java:232) > at > org.apache.camel.language.simple.SimpleExpressionBuilder$KeyedOgnlExpressionAdapter.evaluate(SimpleExpressionBuilder.java:1253) > at > org.apache.camel.support.ExpressionAdapter.evaluate(ExpressionAdapter.java:45) > at > org.apache.camel.model.language.ExpressionDefinition.evaluate(ExpressionDefinition.java:252) > at > org.apache.camel.support.builder.ValueBuilder.evaluate(ValueBuilder.java:55) > at > org.apache.camel.support.builder.BinaryPredicateSupport.matchesReturningFailureMessage(BinaryPredicateSupport.java:67) > at > org.apache.camel.support.builder.BinaryPredicateSupport.matches(BinaryPredicateSupport.java:56) > at > org.apache.camel.processor.FilterProcessor.matches(FilterProcessor.java:89) > at > org.apache.camel.processor.FilterProcessor.process(FilterProcessor.java:72) > at > org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.doRun(RedeliveryErrorHandler.java:808) > at > org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.run(RedeliveryErrorHandler.java:714) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.executeFromQueue(DefaultReactiveExecutor.java:240) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor.executeFromQueue(DefaultReactiveExecutor.java:77) > at > org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.await(DefaultAsyncProcessorAwaitManager.java:95) > at > org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:84) > at > org.apache.camel.processor.errorhandler.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:178) > at > org.apache.camel.impl.engine.CamelInternalProcessor.processTransacted(CamelInternalProcessor.java:390) > at > org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:320) > at org.apache.camel.processor.Pipeline$PipelineTask.run(Pipeline.java:102) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.executeFromQueue(DefaultReactiveExecutor.java:240) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor.executeFromQueue(DefaultReactiveExecutor.java:77) > at > org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.await(DefaultAsyncProcessorAwaitManager.java:95) > at > org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:84) > at > org.apache.camel.spring.spi.TransactionErrorHandler.processByErrorHandler(TransactionErrorHandler.java:244) > at > org.apache.camel.spring.spi.TransactionErrorHandler.process(TransactionErrorHandler.java:119) > at > org.apache.camel.spring.spi.TransactionErrorHandler.process(TransactionErrorHandler.java:132) > at > org.apache.camel.processor.errorhandler.RedeliveryErrorHan
[jira] [Commented] (CAMEL-21472) Opentelemetry is using the same traceId when exchange is fired from file or timer component
[
https://issues.apache.org/jira/browse/CAMEL-21472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901203#comment-17901203
]
Thomas Gantenbein commented on CAMEL-21472:
---
Actually, forget about those lines regarding the MDC context: They are not
necessary. I think I included them when I had not yet set
`builder.setNoParent()` and was surprised to still find the same traceId in the
logs. But it wasn't about the MDC context, it was about that
`builder.setNoParent()`. Removing traceId from MDC seems to be done as expected
(at least: expected by {_}me{_}) in ActiveSpanManager.
And I agree that this "fix" is counterintuitive. Also, it will work, I guess,
for cases were messages originate from Camel, but it will not work if another
service calls Camel, for example, with an existing traceId in a HTTP header:
we'd start a new traceId, which is certainly not what's expected.
The span seems to be ended in
[https://github.com/apache/camel/blob/main/components/camel-tracing/src/main/java/org/apache/camel/tracing/Tracer.java#L328,]
but maybe we'd have to check there if there is no parent span and, if so,
clear the context – no idea how that is done exactly. It seems to me that the
"context" of a trace is stored in ThreadLocalStorage and by calling
Span.fromContext(ctx), that information is restored when a new exchange is
started – including the traceId from a previous trace processed on the same
thread.
Anyway, [~squakez], if you prefer to work on this by yourself I'll let you do
your work and not disturb. If you appreciate comments like these and
suggestions, I'll continue to try out things if I find time.
> Opentelemetry is using the same traceId when exchange is fired from file or
> timer component
> ---
>
> Key: CAMEL-21472
> URL: https://issues.apache.org/jira/browse/CAMEL-21472
> Project: Camel
> Issue Type: Bug
> Components: camel-opentelemetry
>Affects Versions: 4.8.1
>Reporter: Thomas Gantenbein
>Assignee: Pasquale Congiusti
>Priority: Major
> Fix For: 4.8.2, 4.9.0
>
> Attachments: image-2024-11-26-09-59-35-555.png
>
>
> *Problem*
> When using a consumer like {{timer}} or {{{}file{}}}, the traceId remains the
> same for all messages. When using a consumer like netty (or, I assume, any
> other http/tcp-based consumer), every call gets its own traceId as expected.
> See also
> https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Same.20OTEL.20trace.20for.20all.20messages.20into.20IBM.20MQ
> *Reproducer*
> [https://github.com/thomas-gantenbein-tga/camel-opentelemetry/tree/main]
> [~pcongiusti], thanks for your answer on Zulip Chat. Let me know if I should
> further explain or minimize that reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-21399) Kubernetes plugin regression. Fails on OCP deployments
[
https://issues.apache.org/jira/browse/CAMEL-21399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-21399.
-
Resolution: Duplicate
> Kubernetes plugin regression. Fails on OCP deployments
> --
>
> Key: CAMEL-21399
> URL: https://issues.apache.org/jira/browse/CAMEL-21399
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
>Affects Versions: 4.8.1
>Reporter: Bruno Meseguer
>Priority: Minor
> Fix For: 4.8.2, 4.9.0
>
>
> All seems to work well in 4.8.0
> Operating the same commands using 4.8.1 fails.
>
> Create a Camel route, for example, with:
> {code:java}
> camel init myroute.camel.yaml{code}
>
> Then using the commands below to deploy on OpenShift (tested in Developer
> Sandbox) run
>
> {code:java}
> camel version
> JBang version: 0.119.0
> Camel JBang version: 4.8.1
> camel kubernetes run * --cluster-type=openshift --dev
> {code}
>
>
> The execution fails with:
> {code:java}
> Run: kubectl get pod -l app.kubernetes.io/name=test
> Exception in thread "main" java.util.ServiceConfigurationError:
> io.fabric8.kubernetes.api.model.KubernetesResource:
> io.fabric8.kubernetes.api.model.LimitRange not a subtype{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-21476) SQL Stored Procedure compont don't use definied RowMapperFactory from SQL compont
[
https://issues.apache.org/jira/browse/CAMEL-21476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-21476:
Issue Type: Improvement (was: Bug)
> SQL Stored Procedure compont don't use definied RowMapperFactory from SQL
> compont
> --
>
> Key: CAMEL-21476
> URL: https://issues.apache.org/jira/browse/CAMEL-21476
> Project: Camel
> Issue Type: Improvement
> Components: camel-sql
>Affects Versions: 4.8.0
>Reporter: John Zander
>Priority: Major
> Fix For: 4.x
>
>
> {color:#268bd2}Hi devs,{color}
>
> {color:#268bd2}we are using camel to call stored-procedures which return a
> non-standard datatype which is not handled by the framework. For this use
> case, it is possible to define a custom RowMapperFactory which can handle
> that datatype. {color}
>
> {color:#268bd2}[https://camel.apache.org/components/4.8.x/sql-stored-component.html]{color}
>
> {color:#268bd2}states
> {color}{color:#268bd2}"camel.component.{color}{color:#268bd2}sql.{color}{color:#268bd2}row-mapper-factory"
> as property to set.{color}
>
> Unfortunately, this property doesn't become active on "sqlstored" only on
> plain "sql". Please fix or change the documentation with the correct
> property. Thank you!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-21467) Simple expressions execute forever. Thread is RUNNABLE for ever. Issue appears with bean expressions inside simple expressions on SimpleLRUCache
[ https://issues.apache.org/jira/browse/CAMEL-21467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901400#comment-17901400 ] Nicolas Filotto commented on CAMEL-21467: - [~shmyer] I published new snapshots 4.9-SNAPSHOT at https://repository.apache.org/snapshots/ with a potential fix, could you please test it with it? If you reproduce it again, I would need clear steps to reproduce, thx in advance > Simple expressions execute forever. Thread is RUNNABLE for ever. Issue > appears with bean expressions inside simple expressions on SimpleLRUCache > > > Key: CAMEL-21467 > URL: https://issues.apache.org/jira/browse/CAMEL-21467 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 4.8.1 >Reporter: Jannik Schmeier >Assignee: Nicolas Filotto >Priority: Major > Fix For: 4.8.2, 4.9.0 > > > Similar to CAMEL-21432, occasionally my camel route gets stuck on > SimpleLRUCache. > The thread dump suggests, that this has to do with simple and bean > expressions. I've had two encounters with this issue in two different > applications: > *First encounter:* > "Camel (camel-1) thread #2 - JmsConsumer[]" - Thread t@58 > java.lang.Thread.State: RUNNABLE > at > org.apache.camel.support.cache.SimpleLRUCache$OperationContext.close(SimpleLRUCache.java:318) > at > org.apache.camel.support.cache.SimpleLRUCache.put(SimpleLRUCache.java:106) > at > org.apache.camel.support.cache.SimpleSoftCache.put(SimpleSoftCache.java:114) > at > org.apache.camel.component.bean.BeanComponent.addBeanInfoToCache(BeanComponent.java:96) > at org.apache.camel.component.bean.BeanInfo.(BeanInfo.java:169) > at > org.apache.camel.component.bean.ConstantBeanHolder.(ConstantBeanHolder.java:50) > at > org.apache.camel.language.bean.BeanExpression.invokeOgnlMethod(BeanExpression.java:435) > at > org.apache.camel.language.bean.BeanExpression.evaluate(BeanExpression.java:218) > at > org.apache.camel.language.bean.BeanExpression.evaluate(BeanExpression.java:232) > at > org.apache.camel.language.simple.SimpleExpressionBuilder$KeyedOgnlExpressionAdapter.evaluate(SimpleExpressionBuilder.java:1253) > at > org.apache.camel.support.ExpressionAdapter.evaluate(ExpressionAdapter.java:45) > at > org.apache.camel.model.language.ExpressionDefinition.evaluate(ExpressionDefinition.java:252) > at > org.apache.camel.support.builder.ValueBuilder.evaluate(ValueBuilder.java:55) > at > org.apache.camel.support.builder.BinaryPredicateSupport.matchesReturningFailureMessage(BinaryPredicateSupport.java:67) > at > org.apache.camel.support.builder.BinaryPredicateSupport.matches(BinaryPredicateSupport.java:56) > at > org.apache.camel.processor.FilterProcessor.matches(FilterProcessor.java:89) > at > org.apache.camel.processor.FilterProcessor.process(FilterProcessor.java:72) > at > org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.doRun(RedeliveryErrorHandler.java:808) > at > org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.run(RedeliveryErrorHandler.java:714) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.executeFromQueue(DefaultReactiveExecutor.java:240) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor.executeFromQueue(DefaultReactiveExecutor.java:77) > at > org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.await(DefaultAsyncProcessorAwaitManager.java:95) > at > org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:84) > at > org.apache.camel.processor.errorhandler.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:178) > at > org.apache.camel.impl.engine.CamelInternalProcessor.processTransacted(CamelInternalProcessor.java:390) > at > org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:320) > at org.apache.camel.processor.Pipeline$PipelineTask.run(Pipeline.java:102) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.executeFromQueue(DefaultReactiveExecutor.java:240) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor.executeFromQueue(DefaultReactiveExecutor.java:77) > at > org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.await(DefaultAsyncProcessorAwaitManager.java:95) > at > org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:84) > at > org.apache.camel.spring.spi.TransactionErrorHandler.processByErrorHandler(TransactionErrorHandler.java:244) > at > org.apache.camel
[jira] [Commented] (CAMEL-21467) Simple expressions execute forever. Thread is RUNNABLE for ever. Issue appears with bean expressions inside simple expressions on SimpleLRUCache
[ https://issues.apache.org/jira/browse/CAMEL-21467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901119#comment-17901119 ] Nicolas Filotto commented on CAMEL-21467: - Hi, I will try to have a look this afternoon, I need to finish a task first > Simple expressions execute forever. Thread is RUNNABLE for ever. Issue > appears with bean expressions inside simple expressions on SimpleLRUCache > > > Key: CAMEL-21467 > URL: https://issues.apache.org/jira/browse/CAMEL-21467 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 4.8.1 >Reporter: Jannik Schmeier >Priority: Major > Fix For: 4.8.2, 4.9.0 > > > Similar to CAMEL-21432, occasionally my camel route gets stuck on > SimpleLRUCache. > The thread dump suggests, that this has to do with simple and bean > expressions. I've had two encounters with this issue in two different > applications: > *First encounter:* > "Camel (camel-1) thread #2 - JmsConsumer[]" - Thread t@58 > java.lang.Thread.State: RUNNABLE > at > org.apache.camel.support.cache.SimpleLRUCache$OperationContext.close(SimpleLRUCache.java:318) > at > org.apache.camel.support.cache.SimpleLRUCache.put(SimpleLRUCache.java:106) > at > org.apache.camel.support.cache.SimpleSoftCache.put(SimpleSoftCache.java:114) > at > org.apache.camel.component.bean.BeanComponent.addBeanInfoToCache(BeanComponent.java:96) > at org.apache.camel.component.bean.BeanInfo.(BeanInfo.java:169) > at > org.apache.camel.component.bean.ConstantBeanHolder.(ConstantBeanHolder.java:50) > at > org.apache.camel.language.bean.BeanExpression.invokeOgnlMethod(BeanExpression.java:435) > at > org.apache.camel.language.bean.BeanExpression.evaluate(BeanExpression.java:218) > at > org.apache.camel.language.bean.BeanExpression.evaluate(BeanExpression.java:232) > at > org.apache.camel.language.simple.SimpleExpressionBuilder$KeyedOgnlExpressionAdapter.evaluate(SimpleExpressionBuilder.java:1253) > at > org.apache.camel.support.ExpressionAdapter.evaluate(ExpressionAdapter.java:45) > at > org.apache.camel.model.language.ExpressionDefinition.evaluate(ExpressionDefinition.java:252) > at > org.apache.camel.support.builder.ValueBuilder.evaluate(ValueBuilder.java:55) > at > org.apache.camel.support.builder.BinaryPredicateSupport.matchesReturningFailureMessage(BinaryPredicateSupport.java:67) > at > org.apache.camel.support.builder.BinaryPredicateSupport.matches(BinaryPredicateSupport.java:56) > at > org.apache.camel.processor.FilterProcessor.matches(FilterProcessor.java:89) > at > org.apache.camel.processor.FilterProcessor.process(FilterProcessor.java:72) > at > org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.doRun(RedeliveryErrorHandler.java:808) > at > org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.run(RedeliveryErrorHandler.java:714) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.executeFromQueue(DefaultReactiveExecutor.java:240) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor.executeFromQueue(DefaultReactiveExecutor.java:77) > at > org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.await(DefaultAsyncProcessorAwaitManager.java:95) > at > org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:84) > at > org.apache.camel.processor.errorhandler.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:178) > at > org.apache.camel.impl.engine.CamelInternalProcessor.processTransacted(CamelInternalProcessor.java:390) > at > org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:320) > at org.apache.camel.processor.Pipeline$PipelineTask.run(Pipeline.java:102) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.executeFromQueue(DefaultReactiveExecutor.java:240) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor.executeFromQueue(DefaultReactiveExecutor.java:77) > at > org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.await(DefaultAsyncProcessorAwaitManager.java:95) > at > org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:84) > at > org.apache.camel.spring.spi.TransactionErrorHandler.processByErrorHandler(TransactionErrorHandler.java:244) > at > org.apache.camel.spring.spi.TransactionErrorHandler.process(TransactionErrorHandler.java:119) > at > org.apache.camel.spring.spi.TransactionErrorHandler.process(TransactionErrorHandler.java:132) > at >
[jira] [Assigned] (CAMEL-21472) Opentelemetry is using the same traceId when exchange is fired from file or timer component
[
https://issues.apache.org/jira/browse/CAMEL-21472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pasquale Congiusti reassigned CAMEL-21472:
--
Assignee: Pasquale Congiusti
> Opentelemetry is using the same traceId when exchange is fired from file or
> timer component
> ---
>
> Key: CAMEL-21472
> URL: https://issues.apache.org/jira/browse/CAMEL-21472
> Project: Camel
> Issue Type: Bug
> Components: camel-opentelemetry
>Affects Versions: 4.8.1
>Reporter: Thomas Gantenbein
>Assignee: Pasquale Congiusti
>Priority: Major
> Fix For: 4.8.2, 4.9.0
>
>
> *Problem*
> When using a consumer like {{timer}} or {{{}file{}}}, the traceId remains the
> same for all messages. When using a consumer like netty (or, I assume, any
> other http/tcp-based consumer), every call gets its own traceId as expected.
> See also
> https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Same.20OTEL.20trace.20for.20all.20messages.20into.20IBM.20MQ
> *Reproducer*
> [https://github.com/thomas-gantenbein-tga/camel-opentelemetry/tree/main]
> [~pcongiusti], thanks for your answer on Zulip Chat. Let me know if I should
> further explain or minimize that reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-21472) Opentelemetry is using the same traceId when exchange is fired from file or timer component
[
https://issues.apache.org/jira/browse/CAMEL-21472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901118#comment-17901118
]
Pasquale Congiusti commented on CAMEL-21472:
Thanks for the insights. I am going to have a look and I'll ask your support
for further troubleshooting if required.
> Opentelemetry is using the same traceId when exchange is fired from file or
> timer component
> ---
>
> Key: CAMEL-21472
> URL: https://issues.apache.org/jira/browse/CAMEL-21472
> Project: Camel
> Issue Type: Bug
> Components: camel-opentelemetry
>Affects Versions: 4.8.1
>Reporter: Thomas Gantenbein
>Assignee: Pasquale Congiusti
>Priority: Major
> Fix For: 4.8.2, 4.9.0
>
>
> *Problem*
> When using a consumer like {{timer}} or {{{}file{}}}, the traceId remains the
> same for all messages. When using a consumer like netty (or, I assume, any
> other http/tcp-based consumer), every call gets its own traceId as expected.
> See also
> https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Same.20OTEL.20trace.20for.20all.20messages.20into.20IBM.20MQ
> *Reproducer*
> [https://github.com/thomas-gantenbein-tga/camel-opentelemetry/tree/main]
> [~pcongiusti], thanks for your answer on Zulip Chat. Let me know if I should
> further explain or minimize that reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work started] (CAMEL-21472) Opentelemetry is using the same traceId when exchange is fired from file or timer component
[
https://issues.apache.org/jira/browse/CAMEL-21472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-21472 started by Pasquale Congiusti.
--
> Opentelemetry is using the same traceId when exchange is fired from file or
> timer component
> ---
>
> Key: CAMEL-21472
> URL: https://issues.apache.org/jira/browse/CAMEL-21472
> Project: Camel
> Issue Type: Bug
> Components: camel-opentelemetry
>Affects Versions: 4.8.1
>Reporter: Thomas Gantenbein
>Assignee: Pasquale Congiusti
>Priority: Major
> Fix For: 4.8.2, 4.9.0
>
>
> *Problem*
> When using a consumer like {{timer}} or {{{}file{}}}, the traceId remains the
> same for all messages. When using a consumer like netty (or, I assume, any
> other http/tcp-based consumer), every call gets its own traceId as expected.
> See also
> https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Same.20OTEL.20trace.20for.20all.20messages.20into.20IBM.20MQ
> *Reproducer*
> [https://github.com/thomas-gantenbein-tga/camel-opentelemetry/tree/main]
> [~pcongiusti], thanks for your answer on Zulip Chat. Let me know if I should
> further explain or minimize that reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-21472) Opentelemetry is using the same traceId when exchange is fired from file or timer component
[
https://issues.apache.org/jira/browse/CAMEL-21472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Gantenbein updated CAMEL-21472:
--
Attachment: image-2024-11-26-09-59-35-555.png
> Opentelemetry is using the same traceId when exchange is fired from file or
> timer component
> ---
>
> Key: CAMEL-21472
> URL: https://issues.apache.org/jira/browse/CAMEL-21472
> Project: Camel
> Issue Type: Bug
> Components: camel-opentelemetry
>Affects Versions: 4.8.1
>Reporter: Thomas Gantenbein
>Assignee: Pasquale Congiusti
>Priority: Major
> Fix For: 4.8.2, 4.9.0
>
> Attachments: image-2024-11-26-09-59-35-555.png
>
>
> *Problem*
> When using a consumer like {{timer}} or {{{}file{}}}, the traceId remains the
> same for all messages. When using a consumer like netty (or, I assume, any
> other http/tcp-based consumer), every call gets its own traceId as expected.
> See also
> https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Same.20OTEL.20trace.20for.20all.20messages.20into.20IBM.20MQ
> *Reproducer*
> [https://github.com/thomas-gantenbein-tga/camel-opentelemetry/tree/main]
> [~pcongiusti], thanks for your answer on Zulip Chat. Let me know if I should
> further explain or minimize that reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-21369) camel-jbang - Kubernetes plugin - Use quarkus extensions for Route trait
[ https://issues.apache.org/jira/browse/CAMEL-21369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901129#comment-17901129 ] Claus Ibsen commented on CAMEL-21369: - Okay so this ticket can be closed ? > camel-jbang - Kubernetes plugin - Use quarkus extensions for Route trait > > > Key: CAMEL-21369 > URL: https://issues.apache.org/jira/browse/CAMEL-21369 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Affects Versions: 4.x >Reporter: Gaelle Fournier >Assignee: Gaelle Fournier >Priority: Major > Fix For: 4.8.2, 4.9.0 > > > In Kubernetes plugin, Route trait (service exposure) are only available > through the generated openshift manifest. > To leverage quarkus cloud readyness we should add for quarkus runtime cases > the use of openshift: > [https://quarkus.io/guides/deploying-to-openshift#exposing_routes] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-21399) Kubernetes plugin regression. Fails on OCP deployments
[
https://issues.apache.org/jira/browse/CAMEL-21399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901130#comment-17901130
]
Claus Ibsen commented on CAMEL-21399:
-
[~tdiesler] I assume this has been fixed or do we wait for a new fabric8 client
release ?
> Kubernetes plugin regression. Fails on OCP deployments
> --
>
> Key: CAMEL-21399
> URL: https://issues.apache.org/jira/browse/CAMEL-21399
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
>Affects Versions: 4.8.1
>Reporter: Bruno Meseguer
>Priority: Minor
> Fix For: 4.8.2, 4.9.0
>
>
> All seems to work well in 4.8.0
> Operating the same commands using 4.8.1 fails.
>
> Create a Camel route, for example, with:
> {code:java}
> camel init myroute.camel.yaml{code}
>
> Then using the commands below to deploy on OpenShift (tested in Developer
> Sandbox) run
>
> {code:java}
> camel version
> JBang version: 0.119.0
> Camel JBang version: 4.8.1
> camel kubernetes run * --cluster-type=openshift --dev
> {code}
>
>
> The execution fails with:
> {code:java}
> Run: kubectl get pod -l app.kubernetes.io/name=test
> Exception in thread "main" java.util.ServiceConfigurationError:
> io.fabric8.kubernetes.api.model.KubernetesResource:
> io.fabric8.kubernetes.api.model.LimitRange not a subtype{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-21368) Regression in Camel JBang fails when generating REST routes from OpenAPI spec
[
https://issues.apache.org/jira/browse/CAMEL-21368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901131#comment-17901131
]
Claus Ibsen commented on CAMEL-21368:
-
Okay can we see if we can make swagger not resolve external schemas or find a
way to hook into this. Or if not then report this to swagger to see if they can
improve this in a future release.
> Regression in Camel JBang fails when generating REST routes from OpenAPI spec
> -
>
> Key: CAMEL-21368
> URL: https://issues.apache.org/jira/browse/CAMEL-21368
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
>Affects Versions: 4.8.0
>Reporter: Claude Mamo
>Priority: Minor
> Fix For: 4.8.2, 4.9.0
>
> Attachments: us-core-server.openapi.json
>
>
> When generating REST routes from the *attached* OpenAPI spec using Camel
> JBang, I get the following error:
> {code:java}
> java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException
> at
> org.apache.camel.generator.openapi.RestDefinitionEmitter.emit(RestDefinitionEmitter.java:50)
> at
> org.apache.camel.generator.openapi.OperationVisitor.emit(OperationVisitor.java:118)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
> at
> org.apache.camel.generator.openapi.OperationVisitor.visit(OperationVisitor.java:166)
> at
> org.apache.camel.generator.openapi.PathVisitor.lambda$visit$0(PathVisitor.java:46)
> at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:721)
> at
> org.apache.camel.generator.openapi.PathVisitor.visit(PathVisitor.java:46)
> at
> org.apache.camel.generator.openapi.RestDslYamlGenerator.generate(RestDslYamlGenerator.java:83)
> at
> org.apache.camel.dsl.jbang.core.commands.generate.CodeRestGenerator.doCall(CodeRestGenerator.java:122)
> at
> org.apache.camel.dsl.jbang.core.commands.CamelCommand.call(CamelCommand.java:71)
> at
> org.apache.camel.dsl.jbang.core.commands.CamelCommand.call(CamelCommand.java:37)
> at picocli.CommandLine.executeUserObject(CommandLine.java:2045)
> at picocli.CommandLine.access$1500(CommandLine.java:148)
> at
> picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2465)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2457)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2419)
> at
> picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2277)
> at picocli.CommandLine$RunLast.execute(CommandLine.java:2421)
> at picocli.CommandLine.execute(CommandLine.java:2174)
> at
> org.apache.camel.dsl.jbang.core.commands.CamelJBangMain.run(CamelJBangMain.java:173)
> at
> org.apache.camel.dsl.jbang.core.commands.CamelJBangMain.run(CamelJBangMain.java:62)
> at main.CamelJBang.main(CamelJBang.java:36)
> Caused by: java.lang.reflect.InvocationTargetException
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:569)
> at
> org.apache.camel.generator.openapi.RestDefinitionEmitter.emit(RestDefinitionEmitter.java:48)
> ... 21 more
> Caused by: java.lang.IllegalArgumentException: name must be specified and not
> empty
> at org.apache.camel.util.StringHelper.notEmpty(StringHelper.java:356)
> at
> org.apache.camel.model.rest.ParamDefinition.endParam(ParamDefinition.java:344)
> ... 26 more
> {code}
> {{In version 4.5.0, I was able to generate the routes but something broke in
> 4.8.0. The command I'm running is: jbang "-Dcamel.jbang.version=4.8.0"
> camel@apache/camel generate rest --input us-core-server.openapi.json --output
> api.yaml . I've observed that the command works when there's a single _path_
> in the spec.}}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-21472) Opentelemetry is using the same traceId when exchange is fired from file or timer component
[
https://issues.apache.org/jira/browse/CAMEL-21472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901133#comment-17901133
]
Thomas Gantenbein commented on CAMEL-21472:
---
Couldn't leave this alone, so in case it helps, here's what I've tried:
!image-2024-11-26-09-59-35-555.png|width=813,height=357!
This solves the issue for my tiny little example – not sure though that this is
the right way. The lines about mdc logging are just a quick fix for me to test.
> Opentelemetry is using the same traceId when exchange is fired from file or
> timer component
> ---
>
> Key: CAMEL-21472
> URL: https://issues.apache.org/jira/browse/CAMEL-21472
> Project: Camel
> Issue Type: Bug
> Components: camel-opentelemetry
>Affects Versions: 4.8.1
>Reporter: Thomas Gantenbein
>Assignee: Pasquale Congiusti
>Priority: Major
> Fix For: 4.8.2, 4.9.0
>
> Attachments: image-2024-11-26-09-59-35-555.png
>
>
> *Problem*
> When using a consumer like {{timer}} or {{{}file{}}}, the traceId remains the
> same for all messages. When using a consumer like netty (or, I assume, any
> other http/tcp-based consumer), every call gets its own traceId as expected.
> See also
> https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Same.20OTEL.20trace.20for.20all.20messages.20into.20IBM.20MQ
> *Reproducer*
> [https://github.com/thomas-gantenbein-tga/camel-opentelemetry/tree/main]
> [~pcongiusti], thanks for your answer on Zulip Chat. Let me know if I should
> further explain or minimize that reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-21369) camel-jbang - Kubernetes plugin - Use quarkus extensions for Route trait
[ https://issues.apache.org/jira/browse/CAMEL-21369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901153#comment-17901153 ] Claus Ibsen commented on CAMEL-21369: - okay you can close the ticket as "wont do" > camel-jbang - Kubernetes plugin - Use quarkus extensions for Route trait > > > Key: CAMEL-21369 > URL: https://issues.apache.org/jira/browse/CAMEL-21369 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Affects Versions: 4.x >Reporter: Gaelle Fournier >Assignee: Gaelle Fournier >Priority: Major > Fix For: 4.8.2, 4.9.0 > > > In Kubernetes plugin, Route trait (service exposure) are only available > through the generated openshift manifest. > To leverage quarkus cloud readyness we should add for quarkus runtime cases > the use of openshift: > [https://quarkus.io/guides/deploying-to-openshift#exposing_routes] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-21369) camel-jbang - Kubernetes plugin - Use quarkus extensions for Route trait
[ https://issues.apache.org/jira/browse/CAMEL-21369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901152#comment-17901152 ] Gaelle Fournier commented on CAMEL-21369: - Yes. Also it has been added then removed with the decision to be full jkube. Not sure what it means in terms of ticket status. > camel-jbang - Kubernetes plugin - Use quarkus extensions for Route trait > > > Key: CAMEL-21369 > URL: https://issues.apache.org/jira/browse/CAMEL-21369 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Affects Versions: 4.x >Reporter: Gaelle Fournier >Assignee: Gaelle Fournier >Priority: Major > Fix For: 4.8.2, 4.9.0 > > > In Kubernetes plugin, Route trait (service exposure) are only available > through the generated openshift manifest. > To leverage quarkus cloud readyness we should add for quarkus runtime cases > the use of openshift: > [https://quarkus.io/guides/deploying-to-openshift#exposing_routes] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-21472) Opentelemetry is using the same traceId when exchange is fired from file or timer component
[
https://issues.apache.org/jira/browse/CAMEL-21472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901148#comment-17901148
]
Pasquale Congiusti commented on CAMEL-21472:
Hello. I think that part was kind of introduced on purpose: [1] and [2]. We
need to understand a bit more on the root cause and which is the expected
behavior of the component, how we can tune based on the requirement we have and
if there is any bug we need to fix. I will try to work on all those points. I
had a quick look to understand if the MDC behavior is something we can skip by
configuration, but it seems it does not.
[1]
https://camel.apache.org/components/next/others/opentelemetry.html#_mdc_logging
[2]
https://github.com/apache/camel/commit/04916f4e601d1c1cdb9c22cff9ff40e0a1070ffe
> Opentelemetry is using the same traceId when exchange is fired from file or
> timer component
> ---
>
> Key: CAMEL-21472
> URL: https://issues.apache.org/jira/browse/CAMEL-21472
> Project: Camel
> Issue Type: Bug
> Components: camel-opentelemetry
>Affects Versions: 4.8.1
>Reporter: Thomas Gantenbein
>Assignee: Pasquale Congiusti
>Priority: Major
> Fix For: 4.8.2, 4.9.0
>
> Attachments: image-2024-11-26-09-59-35-555.png
>
>
> *Problem*
> When using a consumer like {{timer}} or {{{}file{}}}, the traceId remains the
> same for all messages. When using a consumer like netty (or, I assume, any
> other http/tcp-based consumer), every call gets its own traceId as expected.
> See also
> https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Same.20OTEL.20trace.20for.20all.20messages.20into.20IBM.20MQ
> *Reproducer*
> [https://github.com/thomas-gantenbein-tga/camel-opentelemetry/tree/main]
> [~pcongiusti], thanks for your answer on Zulip Chat. Let me know if I should
> further explain or minimize that reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-21475) camel-yaml-dsl - Using route templates with hardcoded ids problem
Claus Ibsen created CAMEL-21475: --- Summary: camel-yaml-dsl - Using route templates with hardcoded ids problem Key: CAMEL-21475 URL: https://issues.apache.org/jira/browse/CAMEL-21475 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 4.9.0 See this example [https://github.com/apache/camel-kamelets-examples/tree/main/jbang/route-template] When using hardcoded ids, (user or via tooling) then the template should self-assign unique nodeIdPrefix to avoid clashes. org.apache.camel.FailedToCreateRouteFromTemplateException: Failed to create route two from template myTemplate because of duplicate id detected: setBody-e9c1. Please correct ids to be unique among all your routes. at org.apache.camel.impl.DefaultModel.addRouteFromTemplate(DefaultModel.java:539) at org.apache.camel.impl.DefaultModel.addRouteFromTemplate(DefaultModel.java:406) at org.apache.camel.impl.DefaultCamelContext.addRouteFromTemplate(DefaultCamelContext.java:355) at org.apache.camel.impl.engine.AbstractCamelContext.doInit(AbstractCamelContext.java:2450) at org.apache.camel.support.service.BaseService.init(BaseService.java:85) at org.apache.camel.impl.engine.AbstractCamelContext.init(AbstractCamelContext.java:2087) at org.apache.camel.support.service.BaseService.start(BaseService.java:115) at org.apache.camel.impl.engine.AbstractCamelContext.start(AbstractCamelContext.java:2106) at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:211) at org.apache.camel.main.KameletMain.doStart(KameletMain.java:385) at org.apache.camel.support.service.BaseService.start(BaseService.java:123) at org.apache.camel.dsl.jbang.core.commands.Run.runKameletMain(Run.java:1374) at org.apache.camel.dsl.jbang.core.commands.Run.run(Run.java:888) at org.apache.camel.dsl.jbang.core.commands.Run.doCall(Run.java:324) at org.apache.camel.dsl.jbang.core.commands.CamelCommand.call(CamelCommand.java:71) at org.apache.camel.dsl.jbang.core.commands.CamelCommand.call(CamelCommand.java:37) at picocli.CommandLine.executeUserObject(CommandLine.java:2045) at picocli.CommandLine.access$1500(CommandLine.java:148) at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2465) at picocli.CommandLine$RunLast.handle(CommandLine.java:2457) at picocli.CommandLine$RunLast.handle(CommandLine.java:2419) at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2277) at picocli.CommandLine$RunLast.execute(CommandLine.java:2421) at picocli.CommandLine.execute(CommandLine.java:2174) at org.apache.camel.dsl.jbang.core.commands.CamelJBangMain.run(CamelJBangMain.java:175) at org.apache.camel.dsl.jbang.core.commands.CamelJBangMain.run(CamelJBangMain.java:62) at main.CamelJBang.main(CamelJBang.java:36) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-21428) NullPointerException in createTempFileName due to tempName being null in Camel 4.8.0
[
https://issues.apache.org/jira/browse/CAMEL-21428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901162#comment-17901162
]
Oystein Follo commented on CAMEL-21428:
---
After some more digging in our own systems we've figured that we based our own
logic on the old behavior (-> 4.7.0) where this returned the string "null" in
the scenario mentioned above. Won't consider this as a bug, and we have fixed
the issue on our end now. Sorry for the noise.
> NullPointerException in createTempFileName due to tempName being null in
> Camel 4.8.0
>
>
> Key: CAMEL-21428
> URL: https://issues.apache.org/jira/browse/CAMEL-21428
> Project: Camel
> Issue Type: Bug
> Components: camel-file
>Affects Versions: 4.8.1
>Reporter: Oystein Follo
>Priority: Minor
>
> We are experiencing a {{NullPointerException}} within the
> {{createTempFileName}} method. This error occurs when {{tempName}} is
> evaluated as {{{}null{}}}, and later in the code, a call to
> {{tempName.length()}} or {{tempName.lastIndexOf()}} results in an exception.
> This issue can disrupt the file processing flow.
> *Relevant Code Segment:*
> *File: camel-file/components/file/GenericFileProducer.java*
> {code:java}
> public String createTempFileName(Exchange exchange, String fileName) {
> String answer = fileName; String tempName;
> if (exchange.getIn().getHeader(FileConstants.FILE_NAME) == null)
> { exchange.getIn().setHeader(FileConstants.FILE_NAME,
> FileUtil.stripPath(fileName)); tempName =
> endpoint.getTempFileName().evaluate(exchange, String.class);
> exchange.getIn().removeHeader(FileConstants.FILE_NAME); }
> else {
> tempName = endpoint.getTempFileName().evaluate(exchange,
> String.class);
> } int pos = Math.max(answer.lastIndexOf('/'), answer.lastIndexOf("
> "));
> if (pos == -1) {
> answer = tempName;
> } else {
> final String prefix = answer.substring(0, pos + 1);
> StringBuilder sb = new StringBuilder(tempName.length() +
> prefix.length() + 1);
> sb.append(prefix);
> sb.append(tempName);
> answer = sb.toString();
> } if (endpoint.getConfiguration().needToNormalize()) {
> answer = normalizePath(answer);
> } answer = FileUtil.compactPath(answer, getFileSeparator()); return
> answer;
> }
> {code}
> *Issue Location:*
> The issue occurs in the line:
> {code:java}
> StringBuilder sb = new StringBuilder(tempName.length() + prefix.length() + 1);
> {code}
> If {{tempName}} is {{{}null{}}}, calling {{tempName.length()}} or
> {{tempName.lastIndexOf()}} will result in a {{{}NullPointerException{}}}.
> *Steps to Reproduce:*
> # Call {{createTempFileName}} with an {{Exchange}} object where
> {{endpoint.getTempFileName().evaluate(exchange, String.class)}} may return
> {{{}null{}}}.
> # Observe that if {{tempName}} is {{{}null{}}}, a {{NullPointerException}}
> occurs.
> *Expected Behavior:*
> The method should handle the case where {{tempName}} may be {{{}null{}}}. If
> {{tempName}} is {{{}null{}}}, a default value should be used or a check
> should be added to avoid invoking methods on a {{null}} object.
> *Actual Behavior:*
> A {{NullPointerException}} is thrown when {{tempName}} is {{{}null{}}}, which
> may interrupt the file creation or processing flow.
> *Suggested Solution:*
> Add a null check for {{tempName}} after it is assigned. For example:
> {code:java}
> if (tempName == null) {
> tempName = "defaultTempName"; // or handle appropriately for your use case
> }
> {code}
>
> Alternatively, consider handling {{null}} scenarios with a fallback or
> error-handling mechanism to avoid this exception.
> *Impact:*
> This issue disrupts file processing, potentially causing failures in
> downstream applications depending on file operations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-21472) Opentelemetry is using the same traceId when exchange is fired from file or timer component
[
https://issues.apache.org/jira/browse/CAMEL-21472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901151#comment-17901151
]
Claus Ibsen commented on CAMEL-21472:
-
It smells like the span needs to be ended when the UoW of the Exchange is done
(this happens when the timer or file, or even netty) is done with the exchange.
The "fix" above seems to fix this on the start. But its a great help to find
the best solution. And if possible if we can add some unit test / mock test for
this.
> Opentelemetry is using the same traceId when exchange is fired from file or
> timer component
> ---
>
> Key: CAMEL-21472
> URL: https://issues.apache.org/jira/browse/CAMEL-21472
> Project: Camel
> Issue Type: Bug
> Components: camel-opentelemetry
>Affects Versions: 4.8.1
>Reporter: Thomas Gantenbein
>Assignee: Pasquale Congiusti
>Priority: Major
> Fix For: 4.8.2, 4.9.0
>
> Attachments: image-2024-11-26-09-59-35-555.png
>
>
> *Problem*
> When using a consumer like {{timer}} or {{{}file{}}}, the traceId remains the
> same for all messages. When using a consumer like netty (or, I assume, any
> other http/tcp-based consumer), every call gets its own traceId as expected.
> See also
> https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Same.20OTEL.20trace.20for.20all.20messages.20into.20IBM.20MQ
> *Reproducer*
> [https://github.com/thomas-gantenbein-tga/camel-opentelemetry/tree/main]
> [~pcongiusti], thanks for your answer on Zulip Chat. Let me know if I should
> further explain or minimize that reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
