[jira] [Commented] (CAMEL-12109) camel-zipkin - Generate tracing identifiers on exchange begin if they do not exist
[ https://issues.apache.org/jira/browse/CAMEL-12109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16593941#comment-16593941 ] ASF GitHub Bot commented on CAMEL-12109: GitHub user ramu11 opened a pull request: https://github.com/apache/camel/pull/2494 camel-zipkin - Generate tracing identifiers on exchange begin if they… CAMEL-12109:camel-zipkin - Generate tracing identifiers on exchange begin if they do not exist You can merge this pull request into a Git repository by running: $ git pull https://github.com/ramu11/camel master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/2494.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2494 commit 3805a555f934b5abd421ccb358ece56e869f0aa6 Author: Ramu Date: 2018-08-27T16:52:36Z camel-zipkin - Generate tracing identifiers on exchange begin if they do not exist > camel-zipkin - Generate tracing identifiers on exchange begin if they do not > exist > -- > > Key: CAMEL-12109 > URL: https://issues.apache.org/jira/browse/CAMEL-12109 > Project: Camel > Issue Type: New Feature > Components: camel-zipkin >Reporter: Chris Snyder >Assignee: Ramu >Priority: Minor > > The current Zipkin instrumentation generates tracing IDs during client > requests (in com.github.kristofa.brave.ClientTracer.startNewSpan()). However, > it does not do so for server requests (see > [ZipkinTracer.ZipkinRoutePolicy.onExchangeBegin()|https://github.com/apache/camel/blob/c6c02ff92a536e78f7ed1b9dd550d6531e852cee/components/camel-zipkin/src/main/java/org/apache/camel/zipkin/ZipkinTracer.java#L753]). > This means that if the client does not supply its own tracing headers, > nothing will be traced until a client request is made from within Camel. > This can be demonstrated using the camel-example-zipkin modules by removing > the Zipkin instrumentation from the client module. When this is done, the > service1 module will not report any spans. > The [Zipkin documentation|https://zipkin.io/pages/instrumenting.html] > indicates that tracing information should be generated when none is present: > "When an incoming request has no trace information attached, we generate a > random trace ID and span ID." -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CAMEL-12109) camel-zipkin - Generate tracing identifiers on exchange begin if they do not exist
[ https://issues.apache.org/jira/browse/CAMEL-12109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramu reassigned CAMEL-12109: Assignee: Ramu > camel-zipkin - Generate tracing identifiers on exchange begin if they do not > exist > -- > > Key: CAMEL-12109 > URL: https://issues.apache.org/jira/browse/CAMEL-12109 > Project: Camel > Issue Type: New Feature > Components: camel-zipkin >Reporter: Chris Snyder >Assignee: Ramu >Priority: Minor > > The current Zipkin instrumentation generates tracing IDs during client > requests (in com.github.kristofa.brave.ClientTracer.startNewSpan()). However, > it does not do so for server requests (see > [ZipkinTracer.ZipkinRoutePolicy.onExchangeBegin()|https://github.com/apache/camel/blob/c6c02ff92a536e78f7ed1b9dd550d6531e852cee/components/camel-zipkin/src/main/java/org/apache/camel/zipkin/ZipkinTracer.java#L753]). > This means that if the client does not supply its own tracing headers, > nothing will be traced until a client request is made from within Camel. > This can be demonstrated using the camel-example-zipkin modules by removing > the Zipkin instrumentation from the client module. When this is done, the > service1 module will not report any spans. > The [Zipkin documentation|https://zipkin.io/pages/instrumenting.html] > indicates that tracing information should be generated when none is present: > "When an incoming request has no trace information attached, we generate a > random trace ID and span ID." -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12753) OPTIONS Http request on REST resource returns incorrect content of Allow header
[ https://issues.apache.org/jira/browse/CAMEL-12753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-12753. - Resolution: Fixed > OPTIONS Http request on REST resource returns incorrect content of Allow > header > --- > > Key: CAMEL-12753 > URL: https://issues.apache.org/jira/browse/CAMEL-12753 > Project: Camel > Issue Type: Bug > Components: camel-undertow >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.23.0 > > > I have a REST resource which consumes multiple Http methods (for example GET, > POST and PUT). If I send OPTIONS request to resource and I expect to receive > Allow Http header with this content: > Allow: GET,POST,PUT,OPTIONS > That does not happen because I receive header which contains only two methods > one of them is OPTIONS. > Allow: GET,OPTIONS > I have try multiple implementations and only camel-restlet works as I expect. > These components contain bug: > camel-undertow > camel-servlet > camel-jetty > camel-netty4-http -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12753) OPTIONS Http request on REST resource returns incorrect content of Allow header
[ https://issues.apache.org/jira/browse/CAMEL-12753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16593615#comment-16593615 ] Claus Ibsen commented on CAMEL-12753: - Okay have a fix for camel-undertow. This requires a bit of component specific fix > OPTIONS Http request on REST resource returns incorrect content of Allow > header > --- > > Key: CAMEL-12753 > URL: https://issues.apache.org/jira/browse/CAMEL-12753 > Project: Camel > Issue Type: Bug > Components: camel-undertow >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.23.0 > > > I have a REST resource which consumes multiple Http methods (for example GET, > POST and PUT). If I send OPTIONS request to resource and I expect to receive > Allow Http header with this content: > Allow: GET,POST,PUT,OPTIONS > That does not happen because I receive header which contains only two methods > one of them is OPTIONS. > Allow: GET,OPTIONS > I have try multiple implementations and only camel-restlet works as I expect. > These components contain bug: > camel-undertow > camel-servlet > camel-jetty > camel-netty4-http -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12753) OPTIONS Http request on REST resource returns incorrect content of Allow header
Claus Ibsen created CAMEL-12753: --- Summary: OPTIONS Http request on REST resource returns incorrect content of Allow header Key: CAMEL-12753 URL: https://issues.apache.org/jira/browse/CAMEL-12753 Project: Camel Issue Type: Bug Components: camel-undertow Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.23.0 I have a REST resource which consumes multiple Http methods (for example GET, POST and PUT). If I send OPTIONS request to resource and I expect to receive Allow Http header with this content: Allow: GET,POST,PUT,OPTIONS That does not happen because I receive header which contains only two methods one of them is OPTIONS. Allow: GET,OPTIONS I have try multiple implementations and only camel-restlet works as I expect. These components contain bug: camel-undertow camel-servlet camel-jetty camel-netty4-http -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12109) camel-zipkin - Generate tracing identifiers on exchange begin if they do not exist
[ https://issues.apache.org/jira/browse/CAMEL-12109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16593582#comment-16593582 ] Ramu commented on CAMEL-12109: -- I will look into this > camel-zipkin - Generate tracing identifiers on exchange begin if they do not > exist > -- > > Key: CAMEL-12109 > URL: https://issues.apache.org/jira/browse/CAMEL-12109 > Project: Camel > Issue Type: New Feature > Components: camel-zipkin >Reporter: Chris Snyder >Priority: Minor > > The current Zipkin instrumentation generates tracing IDs during client > requests (in com.github.kristofa.brave.ClientTracer.startNewSpan()). However, > it does not do so for server requests (see > [ZipkinTracer.ZipkinRoutePolicy.onExchangeBegin()|https://github.com/apache/camel/blob/c6c02ff92a536e78f7ed1b9dd550d6531e852cee/components/camel-zipkin/src/main/java/org/apache/camel/zipkin/ZipkinTracer.java#L753]). > This means that if the client does not supply its own tracing headers, > nothing will be traced until a client request is made from within Camel. > This can be demonstrated using the camel-example-zipkin modules by removing > the Zipkin instrumentation from the client module. When this is done, the > service1 module will not report any spans. > The [Zipkin documentation|https://zipkin.io/pages/instrumenting.html] > indicates that tracing information should be generated when none is present: > "When an incoming request has no trace information attached, we generate a > random trace ID and span ID." -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12752) Upgrade jetty to 9.4.11
[ https://issues.apache.org/jira/browse/CAMEL-12752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-12752. - Resolution: Fixed Upgraded Jetty. Lets keep an eye on CI server if something weird happens as jetty is used in several components during testing, and in the past it may have causes some problems when upgrading. > Upgrade jetty to 9.4.11 > --- > > Key: CAMEL-12752 > URL: https://issues.apache.org/jira/browse/CAMEL-12752 > Project: Camel > Issue Type: Task > Components: camel-jetty >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 2.23.0 > > > We are using 9.4.6 but there is a 9.4.11 version -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12752) Upgrade jetty to 9.4.11
Claus Ibsen created CAMEL-12752: --- Summary: Upgrade jetty to 9.4.11 Key: CAMEL-12752 URL: https://issues.apache.org/jira/browse/CAMEL-12752 Project: Camel Issue Type: Task Components: camel-jetty Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.23.0 We are using 9.4.6 but there is a 9.4.11 version -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12727) java.util.ConcurrentModificationException at org.apache.camel.impl.DefaultExchange.createProperties(DefaultExchange.java:550) in 2.20.1
[ https://issues.apache.org/jira/browse/CAMEL-12727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-12727. - Resolution: Fixed Assignee: Claus Ibsen Okay going back to ConcurrentMap so its safe as it was in Camel 2.19.x and older. > java.util.ConcurrentModificationException at > org.apache.camel.impl.DefaultExchange.createProperties(DefaultExchange.java:550) > in 2.20.1 > --- > > Key: CAMEL-12727 > URL: https://issues.apache.org/jira/browse/CAMEL-12727 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.20.0 > Environment: Camel 2.20.1. > The exception occurs within a aggregation processor using a custom > aggregation strategy and optimistic locking. >Reporter: Philippe Bouteleux >Assignee: Claus Ibsen >Priority: Major > Fix For: 2.23.0 > > Attachments: dih-error.queue_2 (1).txt > > > A concurrent access exception occurs during our load tests while consuming > messages from a rabbitmq queue. > The call stack embedded below shows that the issue is related to an > "optimization" which was introduced in > https://issues.apache.org/jira/browse/CAMEL-11330 to replace a > ConcurrentHashMap with a regular one from version 2.19.5 to 2.20.0 onward. > The faulty code is still present in latest 2.22.0. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-12727) java.util.ConcurrentModificationException at org.apache.camel.impl.DefaultExchange.createProperties(DefaultExchange.java:550) in 2.20.1
[ https://issues.apache.org/jira/browse/CAMEL-12727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16593359#comment-16593359 ] Claus Ibsen edited comment on CAMEL-12727 at 8/27/18 9:10 AM: -- Yeah the hack would be needed as the locking is optimistick and therefore concurrent access on the copy method. But as you say the concurrent hash map smells like the better option and it was also what was used in the past. was (Author: davsclaus): Yeah the hack would be needed as the locking is optimistick and therefore concurrent access on the copy method. > java.util.ConcurrentModificationException at > org.apache.camel.impl.DefaultExchange.createProperties(DefaultExchange.java:550) > in 2.20.1 > --- > > Key: CAMEL-12727 > URL: https://issues.apache.org/jira/browse/CAMEL-12727 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.20.0 > Environment: Camel 2.20.1. > The exception occurs within a aggregation processor using a custom > aggregation strategy and optimistic locking. >Reporter: Philippe Bouteleux >Priority: Major > Fix For: 2.23.0 > > Attachments: dih-error.queue_2 (1).txt > > > A concurrent access exception occurs during our load tests while consuming > messages from a rabbitmq queue. > The call stack embedded below shows that the issue is related to an > "optimization" which was introduced in > https://issues.apache.org/jira/browse/CAMEL-11330 to replace a > ConcurrentHashMap with a regular one from version 2.19.5 to 2.20.0 onward. > The faulty code is still present in latest 2.22.0. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12727) java.util.ConcurrentModificationException at org.apache.camel.impl.DefaultExchange.createProperties(DefaultExchange.java:550) in 2.20.1
[ https://issues.apache.org/jira/browse/CAMEL-12727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16593359#comment-16593359 ] Claus Ibsen commented on CAMEL-12727: - Yeah the hack would be needed as the locking is optimistick and therefore concurrent access on the copy method. > java.util.ConcurrentModificationException at > org.apache.camel.impl.DefaultExchange.createProperties(DefaultExchange.java:550) > in 2.20.1 > --- > > Key: CAMEL-12727 > URL: https://issues.apache.org/jira/browse/CAMEL-12727 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.20.0 > Environment: Camel 2.20.1. > The exception occurs within a aggregation processor using a custom > aggregation strategy and optimistic locking. >Reporter: Philippe Bouteleux >Priority: Major > Fix For: 2.23.0 > > Attachments: dih-error.queue_2 (1).txt > > > A concurrent access exception occurs during our load tests while consuming > messages from a rabbitmq queue. > The call stack embedded below shows that the issue is related to an > "optimization" which was introduced in > https://issues.apache.org/jira/browse/CAMEL-11330 to replace a > ConcurrentHashMap with a regular one from version 2.19.5 to 2.20.0 onward. > The faulty code is still present in latest 2.22.0. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12751) http producer - Ignore content length header
Claus Ibsen created CAMEL-12751: --- Summary: http producer - Ignore content length header Key: CAMEL-12751 URL: https://issues.apache.org/jira/browse/CAMEL-12751 Project: Camel Issue Type: Improvement Components: camel-http, camel-http4 Reporter: Claus Ibsen When doing eg REST -> HTTP etc then the REST consumer may populate the message with Content-Length header, which gets propagated to the http producer. We should by default ignore those existing headers and calculate the length in the producer based on the message body, eg if string, byte[] etc which AFAIR does today. See nabble http://camel.465427.n5.nabble.com/Content-Length-Header-being-used-previous-HTTP-Response-td5813376.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
