[jira] [Created] (CAMEL-18310) Global SSL Context Params Force SSL for All HTTP Connections
Ralf Steppacher created CAMEL-18310:
---
Summary: Global SSL Context Params Force SSL for All HTTP
Connections
Key: CAMEL-18310
URL: https://issues.apache.org/jira/browse/CAMEL-18310
Project: Camel
Issue Type: Bug
Components: camel-http
Affects Versions: 3.18.0
Reporter: Ralf Steppacher
When setting the property
{{camel.component.http.use-global-ssl-context-parameters=true}} all plaintext
http connection attempts fail because a {{SSLConnectionSocketFactory}} is used.
E.g. this will fail:
{code:java}
to(http("localhost:9090/test"))
{code}
with the following stacktrace:
{noformat}
javax.net.ssl.SSLException: Unsupported or unrecognized SSL message
at
java.base/sun.security.ssl.SSLSocketInputRecord.handleUnknownRecord(SSLSocketInputRecord.java:451)
~[na:na]
at
java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:175)
~[na:na]
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:110)
~[na:na]
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1369)
~[na:na]
at
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1278)
~[na:na]
at
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:401)
~[na:na]
at
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:373)
~[na:na]
at
org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:436)
~[httpclient-4.5.13.jar:4.5.13]
at
org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:384)
~[httpclient-4.5.13.jar:4.5.13]
at
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
~[httpclient-4.5.13.jar:4.5.13]
at
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:376)
~[httpclient-4.5.13.jar:4.5.13]
at
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
~[httpclient-4.5.13.jar:4.5.13]
at
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
~[httpclient-4.5.13.jar:4.5.13]
at
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
~[httpclient-4.5.13.jar:4.5.13]
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
~[httpclient-4.5.13.jar:4.5.13]
at
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
~[httpclient-4.5.13.jar:4.5.13]
at
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
~[httpclient-4.5.13.jar:4.5.13]
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:72)
~[httpclient-4.5.13.jar:4.5.13]
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
~[httpclient-4.5.13.jar:4.5.13]
at
org.apache.camel.component.http.HttpProducer.executeMethod(HttpProducer.java:445)
~[camel-http-3.18.0.jar:3.18.0]
at
org.apache.camel.component.http.HttpProducer.process(HttpProducer.java:273)
~[camel-http-3.18.0.jar:3.18.0]
at
org.apache.camel.support.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:66)
~[camel-support-3.18.0.jar:3.18.0]
at
org.apache.camel.processor.SendDynamicProcessor.lambda$process$0(SendDynamicProcessor.java:197)
~[camel-core-processor-3.18.0.jar:3.18.0]
at
org.apache.camel.support.cache.DefaultProducerCache.doInAsyncProducer(DefaultProducerCache.java:327)
~[camel-support-3.18.0.jar:3.18.0]
at
org.apache.camel.processor.SendDynamicProcessor.process(SendDynamicProcessor.java:182)
~[camel-core-processor-3.18.0.jar:3.18.0]
at
org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.doRun(RedeliveryErrorHandler.java:812)
~[camel-core-processor-3.18.0.jar:3.18.0]
at
org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.run(RedeliveryErrorHandler.java:720)
~[camel-core-processor-3.18.0.jar:3.18.0]
at
org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:189)
~[camel-base-engine-3.18.0.jar:3.18.0]
at
org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:61)
~[camel-base-engine-3.18.0.jar:3.18.0]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:184)
~[camel-core-processor-3.18.0.jar:3.18.0]
at
org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:399)
~[camel-base-engine-3.18.0.jar:3.18.0]
{noformat}
SSL settings should only apply to endpoints using the {{https}} protocol
scheme, not to endpoints using the {{http}} protocol scheme.
--
This message was sent by Atlassian Jira
[jira] [Commented] (CAMEL-17295) REST DSL (With Servlet Component) Fails to Resolve Endpoint if Query Parameter Is Part of URI Parameter
[
https://issues.apache.org/jira/browse/CAMEL-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17456726#comment-17456726
]
Ralf Steppacher commented on CAMEL-17295:
-
[~davsclaus], thank you for the addtl. info on the param DSL method!
> REST DSL (With Servlet Component) Fails to Resolve Endpoint if Query
> Parameter Is Part of URI Parameter
> ---
>
> Key: CAMEL-17295
> URL: https://issues.apache.org/jira/browse/CAMEL-17295
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.11.4
>Reporter: Ralf Steppacher
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.14.0, 3.11.5
>
>
> The following works with Camel versions {{3.11.3}} and {{3.13.0}} but fails
> with version {{3.11.4}}:
> {code:java}
> rest("/Assertion?authTokenSourceUri={" + HEADER_AUTH_TOKEN_SOURCE_URI +
> "}").id(ROUTE_REST_GET_ASSERTION)
> .get()
> .produces(MediaType.TEXT_XML_VALUE)
> .route()
> // route definition omitted
> {code}
> With version {{3.11.4}} this yields an
> {{org.apache.camel.ResolveEndpointFailedException}}:
> {noformat}
> Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve
> endpoint: servlet:///Assertion?httpMethodRestrict=GET due to: There are 1
> parameters that couldn't be set on the endpoint. Check the uri if the
> parameters are spelt correctly and that they are properties of the endpoint.
> Unknown
> parameters=[{authTokenSourceUri={authTokenSourceUri}?consumerComponentName=servlet}]
> {noformat}
> Specifying the query parameter via DSL works with all three versions:
> {code:java}
> rest("/Assertion").id(ROUTE_REST_GET_ASSERTION)
> .get()
> .param()
> .name(HEADER_AUTH_TOKEN_SOURCE_URI)
> .type(RestParamType.query)
> .endParam()
> // rest is same as above
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CAMEL-17295) REST DSL (With Servlet Component) Fails to Resolve Endpoint if Query Parameter Is Part of URI Parameter
[
https://issues.apache.org/jira/browse/CAMEL-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17455190#comment-17455190
]
Ralf Steppacher commented on CAMEL-17295:
-
[~davsclaus], version {{3.14.0-SNAPSHOT}} gives me the same error about the
unresolvable endpoint due to the unknown parameter.
> REST DSL (With Servlet Component) Fails to Resolve Endpoint if Query
> Parameter Is Part of URI Parameter
> ---
>
> Key: CAMEL-17295
> URL: https://issues.apache.org/jira/browse/CAMEL-17295
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.11.4
>Reporter: Ralf Steppacher
>Priority: Minor
> Fix For: 3.11.5
>
>
> The following works with Camel versions {{3.11.3}} and {{3.13.0}} but fails
> with version {{3.11.4}}:
> {code:java}
> rest("/Assertion?authTokenSourceUri={" + HEADER_AUTH_TOKEN_SOURCE_URI +
> "}").id(ROUTE_REST_GET_ASSERTION)
> .get()
> .produces(MediaType.TEXT_XML_VALUE)
> .route()
> // route definition omitted
> {code}
> With version {{3.11.4}} this yields an
> {{org.apache.camel.ResolveEndpointFailedException}}:
> {noformat}
> Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve
> endpoint: servlet:///Assertion?httpMethodRestrict=GET due to: There are 1
> parameters that couldn't be set on the endpoint. Check the uri if the
> parameters are spelt correctly and that they are properties of the endpoint.
> Unknown
> parameters=[{authTokenSourceUri={authTokenSourceUri}?consumerComponentName=servlet}]
> {noformat}
> Specifying the query parameter via DSL works with all three versions:
> {code:java}
> rest("/Assertion").id(ROUTE_REST_GET_ASSERTION)
> .get()
> .param()
> .name(HEADER_AUTH_TOKEN_SOURCE_URI)
> .type(RestParamType.query)
> .endParam()
> // rest is same as above
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CAMEL-17295) REST DSL (With Servlet Component) Fails to Resolve Endpoint if Query Parameter Is Part of URI Parameter
[
https://issues.apache.org/jira/browse/CAMEL-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17455088#comment-17455088
]
Ralf Steppacher commented on CAMEL-17295:
-
[~davsclaus], it is already in the description. It works with Camel
* 3.11.3
* 3.13.0
It does not work with Camel
* 3.11.4
> REST DSL (With Servlet Component) Fails to Resolve Endpoint if Query
> Parameter Is Part of URI Parameter
> ---
>
> Key: CAMEL-17295
> URL: https://issues.apache.org/jira/browse/CAMEL-17295
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.11.4
>Reporter: Ralf Steppacher
>Priority: Minor
> Fix For: 3.11.5
>
>
> The following works with Camel versions {{3.11.3}} and {{3.13.0}} but fails
> with version {{3.11.4}}:
> {code:java}
> rest("/Assertion?authTokenSourceUri={" + HEADER_AUTH_TOKEN_SOURCE_URI +
> "}").id(ROUTE_REST_GET_ASSERTION)
> .get()
> .produces(MediaType.TEXT_XML_VALUE)
> .route()
> // route definition omitted
> {code}
> With version {{3.11.4}} this yields an
> {{org.apache.camel.ResolveEndpointFailedException}}:
> {noformat}
> Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve
> endpoint: servlet:///Assertion?httpMethodRestrict=GET due to: There are 1
> parameters that couldn't be set on the endpoint. Check the uri if the
> parameters are spelt correctly and that they are properties of the endpoint.
> Unknown
> parameters=[{authTokenSourceUri={authTokenSourceUri}?consumerComponentName=servlet}]
> {noformat}
> Specifying the query parameter via DSL works with all three versions:
> {code:java}
> rest("/Assertion").id(ROUTE_REST_GET_ASSERTION)
> .get()
> .param()
> .name(HEADER_AUTH_TOKEN_SOURCE_URI)
> .type(RestParamType.query)
> .endParam()
> // rest is same as above
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CAMEL-17295) REST DSL (With Servlet Component) Fails to Resolve Endpoint if Query Parameter Is Part of URI Parameter
[
https://issues.apache.org/jira/browse/CAMEL-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-17295:
Description:
The following works with Camel versions {{3.11.3}} and {{3.13.0}} but fails
with version {{3.11.4}}:
{code:java}
rest("/Assertion?authTokenSourceUri={" + HEADER_AUTH_TOKEN_SOURCE_URI +
"}").id(ROUTE_REST_GET_ASSERTION)
.get()
.produces(MediaType.TEXT_XML_VALUE)
.route()
// route definition omitted
{code}
With version {{3.11.4}} this yields an
{{org.apache.camel.ResolveEndpointFailedException}}:
{noformat}
Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve
endpoint: servlet:///Assertion?httpMethodRestrict=GET due to: There are 1
parameters that couldn't be set on the endpoint. Check the uri if the
parameters are spelt correctly and that they are properties of the endpoint.
Unknown
parameters=[{authTokenSourceUri={authTokenSourceUri}?consumerComponentName=servlet}]
{noformat}
Specifying the query parameter via DSL works with all three versions:
{code:java}
rest("/Assertion").id(ROUTE_REST_GET_ASSERTION)
.get()
.param()
.name(HEADER_AUTH_TOKEN_SOURCE_URI)
.type(RestParamType.query)
.endParam()
// rest is same as above
{code}
was:
The following works with Camel versions {{3.11.3}} and {{3.13.0}} but fails
with version {{3.11.4}}:
{code:java}
rest("/Assertion?authTokenSourceUri={" + HEADER_AUTH_TOKEN_SOURCE_URI +
"}").id(ROUTE_REST_GET_ASSERTION)
.get()
.produces(MediaType.TEXT_XML_VALUE)
.route()
// route definition omitted
{code}
With version {{3.11.4}} this yields an
{{org.apache.camel.ResolveEndpointFailedException}}:
{noformat}
Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve
endpoint: servlet:///Assertion?httpMethodRestrict=GET due to: There are 1
parameters that couldn't be set on the endpoint. Check the uri if the
parameters are spelt correctly and that they are properties of the endpoint.
Unknown
parameters=[{authTokenSourceUri={authTokenSourceUri}?consumerComponentName=servlet}]
{noformat}
Specifying the query parameter via DSL works in all three versions:
{code:java}
rest("/Assertion").id(ROUTE_REST_GET_ASSERTION)
.get()
.param()
.name(HEADER_AUTH_TOKEN_SOURCE_URI)
.type(RestParamType.query)
.endParam()
// rest is same as above
{code}
> REST DSL (With Servlet Component) Fails to Resolve Endpoint if Query
> Parameter Is Part of URI Parameter
> ---
>
> Key: CAMEL-17295
> URL: https://issues.apache.org/jira/browse/CAMEL-17295
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.11.4
>Reporter: Ralf Steppacher
>Priority: Major
>
> The following works with Camel versions {{3.11.3}} and {{3.13.0}} but fails
> with version {{3.11.4}}:
> {code:java}
> rest("/Assertion?authTokenSourceUri={" + HEADER_AUTH_TOKEN_SOURCE_URI +
> "}").id(ROUTE_REST_GET_ASSERTION)
> .get()
> .produces(MediaType.TEXT_XML_VALUE)
> .route()
> // route definition omitted
> {code}
> With version {{3.11.4}} this yields an
> {{org.apache.camel.ResolveEndpointFailedException}}:
> {noformat}
> Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve
> endpoint: servlet:///Assertion?httpMethodRestrict=GET due to: There are 1
> parameters that couldn't be set on the endpoint. Check the uri if the
> parameters are spelt correctly and that they are properties of the endpoint.
> Unknown
> parameters=[{authTokenSourceUri={authTokenSourceUri}?consumerComponentName=servlet}]
> {noformat}
> Specifying the query parameter via DSL works with all three versions:
> {code:java}
> rest("/Assertion").id(ROUTE_REST_GET_ASSERTION)
> .get()
> .param()
> .name(HEADER_AUTH_TOKEN_SOURCE_URI)
> .type(RestParamType.query)
> .endParam()
> // rest is same as above
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CAMEL-17295) REST DSL (With Servlet Component) Fails to Resolve Endpoint if Query Parameter Is Part of URI Parameter
Ralf Steppacher created CAMEL-17295:
---
Summary: REST DSL (With Servlet Component) Fails to Resolve
Endpoint if Query Parameter Is Part of URI Parameter
Key: CAMEL-17295
URL: https://issues.apache.org/jira/browse/CAMEL-17295
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 3.11.4
Reporter: Ralf Steppacher
The following works with Camel versions {{3.11.3}} and {{3.13.0}} but fails
with version {{3.11.4}}:
{code:java}
rest("/Assertion?authTokenSourceUri={" + HEADER_AUTH_TOKEN_SOURCE_URI +
"}").id(ROUTE_REST_GET_ASSERTION)
.get()
.produces(MediaType.TEXT_XML_VALUE)
.route()
// route definition omitted
{code}
With version {{3.11.4}} this yields an
{{org.apache.camel.ResolveEndpointFailedException}}:
{noformat}
Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve
endpoint: servlet:///Assertion?httpMethodRestrict=GET due to: There are 1
parameters that couldn't be set on the endpoint. Check the uri if the
parameters are spelt correctly and that they are properties of the endpoint.
Unknown
parameters=[{authTokenSourceUri={authTokenSourceUri}?consumerComponentName=servlet}]
{noformat}
Specifying the query parameter via DSL works in all three versions:
{code:java}
rest("/Assertion").id(ROUTE_REST_GET_ASSERTION)
.get()
.param()
.name(HEADER_AUTH_TOKEN_SOURCE_URI)
.type(RestParamType.query)
.endParam()
// rest is same as above
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CAMEL-15012) Camel-Http: Endpoint parameters proxyHost and proxyPort are ignored
Ralf Steppacher created CAMEL-15012:
---
Summary: Camel-Http: Endpoint parameters proxyHost and proxyPort
are ignored
Key: CAMEL-15012
URL: https://issues.apache.org/jira/browse/CAMEL-15012
Project: Camel
Issue Type: Bug
Components: camel-http
Affects Versions: 3.1.0
Reporter: Ralf Steppacher
The {{proxyHost}} and {{proxyPort}} query parameters are ignored by the
camel-http compoment. They probably should be handled in
{{org.apache.camel.component.http.HttpComponent#configureHttpProxy}}. Right now
that method only handles {{proxyAuthHost}} and {{proxyAuthPort}}.
Using those query parameters seems to be the workaround, too, as
{{org.apache.camel.component.http.ProxyHttpClientConfigurer}} makes no
distinction between authentication and non-authenticating proxies.
Relates to CAMEL-10216.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-10879) Add option for thread safe Exchange implementation
[
https://issues.apache.org/jira/browse/CAMEL-10879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15878222#comment-15878222
]
Ralf Steppacher edited comment on CAMEL-10879 at 2/22/17 1:40 PM:
--
So what about the first suggestion? Camel core comes with a thread-safe
implementation built in, and the integrator can choose between thread safe or
not by means of a route attribute? Or something alike?
was (Author: ralfsteppacher):
So what about the first suggestion. Camel core comes with a thread-safe
implementation built in, and the integrator can choose between thread safe or
not by means of a route attribute? Or something alike?
> Add option for thread safe Exchange implementation
> --
>
> Key: CAMEL-10879
> URL: https://issues.apache.org/jira/browse/CAMEL-10879
> Project: Camel
> Issue Type: Wish
> Components: camel-core
>Affects Versions: 2.18.2
>Reporter: Ralf Steppacher
>
> The current implementation of the {{org.apache.camel.Exchange}} is not thread
> safe. For routes that employ custom, multi-threaded processors with
> concurrent access to the exchange, it would be beneficial to be able to
> request a thread-safe exchange implementation.
> OR
> A factory mechanism that would allow 3rd parties to contribute an
> implementation of the exchange interface that suits their specific needs.
> Thread safety or other. (For this, the current implementation of
> {{DefaultExchange}} should be reviewed and optimized for sub-classing.)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CAMEL-10879) Add option for thread safe Exchange implementation
[
https://issues.apache.org/jira/browse/CAMEL-10879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15878222#comment-15878222
]
Ralf Steppacher commented on CAMEL-10879:
-
So what about the first suggestion. Camel core comes with a thread-safe
implementation built in, and the integrator can choose between thread safe or
not by means of a route attribute? Or something alike?
> Add option for thread safe Exchange implementation
> --
>
> Key: CAMEL-10879
> URL: https://issues.apache.org/jira/browse/CAMEL-10879
> Project: Camel
> Issue Type: Wish
> Components: camel-core
>Affects Versions: 2.18.2
>Reporter: Ralf Steppacher
>
> The current implementation of the {{org.apache.camel.Exchange}} is not thread
> safe. For routes that employ custom, multi-threaded processors with
> concurrent access to the exchange, it would be beneficial to be able to
> request a thread-safe exchange implementation.
> OR
> A factory mechanism that would allow 3rd parties to contribute an
> implementation of the exchange interface that suits their specific needs.
> Thread safety or other. (For this, the current implementation of
> {{DefaultExchange}} should be reviewed and optimized for sub-classing.)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CAMEL-10879) Add option for thread safe Exchange implementation
Ralf Steppacher created CAMEL-10879:
---
Summary: Add option for thread safe Exchange implementation
Key: CAMEL-10879
URL: https://issues.apache.org/jira/browse/CAMEL-10879
Project: Camel
Issue Type: Wish
Components: camel-core
Affects Versions: 2.18.2
Reporter: Ralf Steppacher
The current implementation of the {{org.apache.camel.Exchange}} is not thread
safe. For routes that employ custom, multi-threaded processors with concurrent
access to the exchange, it would be beneficial to be able to request a
thread-safe exchange implementation.
OR
A factory mechanism that would allow 3rd parties to contribute an
implementation of the exchange interface that suits their specific needs.
Thread safety or other. (For this, the current implementation of
{{DefaultExchange}} should be reviewed and optimized for sub-classing.)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CAMEL-10664) SimpleIllegalSyntaxException in nested expression
[
https://issues.apache.org/jira/browse/CAMEL-10664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-10664:
Description:
The following nested simple expression works in Camel 2.16.3:
{code:xml}
{code}
but fails with a SimpleIllegalSyntaxException in Camel 2.18.1:
{noformat}
Exception: org.apache.camel.language.simple.types.SimpleIllegalSyntaxException:
expected symbol functionEnd but was eol at location 8
${type:ch
*
{noformat}
Both simple expressions work when invoked in a non-nested fashion.
was:
The following nested simple expression works in Camel 2.16.3:
{code:xml}
{code}
but fails with a SimpleIllegalSyntaxException in Camel 2.18.1:
{noformat}
Exception: org.apache.camel.language.simple.types.SimpleIllegalSyntaxException:
expected symbol functionEnd but was eol at location 8
${type:ch
*
{noformat}
> SimpleIllegalSyntaxException in nested expression
> -
>
> Key: CAMEL-10664
> URL: https://issues.apache.org/jira/browse/CAMEL-10664
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.18.1
>Reporter: Ralf Steppacher
>
> The following nested simple expression works in Camel 2.16.3:
> {code:xml}
> loggingLevel="INFO" logName="pep-xds_b-registry_oncompletion_common" />
> {code}
> but fails with a SimpleIllegalSyntaxException in Camel 2.18.1:
> {noformat}
> Exception:
> org.apache.camel.language.simple.types.SimpleIllegalSyntaxException: expected
> symbol functionEnd but was eol at location 8
> ${type:ch
> *
> {noformat}
> Both simple expressions work when invoked in a non-nested fashion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-10664) SimpleIllegalSyntaxException in nested expression
Ralf Steppacher created CAMEL-10664:
---
Summary: SimpleIllegalSyntaxException in nested expression
Key: CAMEL-10664
URL: https://issues.apache.org/jira/browse/CAMEL-10664
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.18.1
Reporter: Ralf Steppacher
The following nested simple expression works in Camel 2.16.3:
{code:xml}
{code}
but fails with a SimpleIllegalSyntaxException in Camel 2.18.1:
{noformat}
Exception: org.apache.camel.language.simple.types.SimpleIllegalSyntaxException:
expected symbol functionEnd but was eol at location 8
${type:ch
*
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-10660) InterruptedException not handled by RedeliveryErrorHandler
Ralf Steppacher created CAMEL-10660:
---
Summary: InterruptedException not handled by RedeliveryErrorHandler
Key: CAMEL-10660
URL: https://issues.apache.org/jira/browse/CAMEL-10660
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.16.3
Reporter: Ralf Steppacher
It appears that if the exception on an {{Exchange}} is of type
{{InterruptedException}} or if any exception in the cause-chain is of that
type, then that exception is completely ignored by the
{{RedeliveryErrorHandler}}. Possibly because it is assumed that any
{{InterruptedException}} would have been raised is due to a Camel context
shutdown?
See {{RedeliveryErrorHandler::isDone(Exchange exchange}}.
It would be great if {{InterruptedException}} not associated with the Camel
context life-cycle could be treated like any other exception (logging,
re-delivery, etc.). As it is now they are neither logged nor handled, which
might obscure problems in application code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9856) RestSwaggerProcessor fails with "Provider org.apache.xalan.processor.TransformerFactoryImpl not found"
[
https://issues.apache.org/jira/browse/CAMEL-9856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238893#comment-15238893
]
Ralf Steppacher commented on CAMEL-9856:
Hi [~davsclaus], I cannot see a commit on the ticket. Is the "fix" the addition
of a working example? In other workds, does this mean I must have screwed up my
context setup somewhere to end up with the error? Or was it actually broken for
OSGi environments and I have to wait for 2.18.0 to be released? Thanks!
> RestSwaggerProcessor fails with "Provider
> org.apache.xalan.processor.TransformerFactoryImpl not found"
> --
>
> Key: CAMEL-9856
> URL: https://issues.apache.org/jira/browse/CAMEL-9856
> Project: Camel
> Issue Type: Bug
> Components: camel-core, karaf
>Affects Versions: 2.16.3
> Environment: Karaf 4.0.3, Java 8
>Reporter: Ralf Steppacher
>Assignee: Claus Ibsen
> Fix For: 2.18.0
>
>
> When I try to query the Swagger API output for my REST routes, which are
> defined in a Blueprint context with the XML DSL, any request to a path that I
> think should return API information yields an empty response body (status
> 200) on the client and this error on the server. The error is raised by
> {{RestSwaggerSupport::getRestDefinitions(String)}} (line 147).
> {noformat}
> 2016-04-11 16:45:29,136 | WARN | qtp215489304-167 | RestSwaggerProcessor
> | 78 - org.apache.camel.camel-swagger-java - 2.16.3 | | Error
> rendering Swagger API due RuntimeException thrown in RequiredModelMBean while
> trying to invoke operation dumpRestsAsXml
> javax.management.MBeanException: RuntimeException thrown in
> RequiredModelMBean while trying to invoke operation dumpRestsAsXml
> at
> javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1285)[:1.8.0_77]
> at
> javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:1085)[:1.8.0_77]
> at
> org.apache.camel.management.MixinRequiredModelMBean.invoke(MixinRequiredModelMBean.java:70)[71:org.apache.camel.camel-core:2.16.3]
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)[:1.8.0_77]
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)[:1.8.0_77]
> at
> org.apache.camel.swagger.RestSwaggerSupport.getRestDefinitions(RestSwaggerSupport.java:147)[78:org.apache.camel.camel-swagger-java:2.16.3]
> at
> org.apache.camel.swagger.RestSwaggerSupport.renderResourceListing(RestSwaggerSupport.java:198)[78:org.apache.camel.camel-swagger-java:2.16.3]
> at
> org.apache.camel.swagger.RestSwaggerProcessor.process(RestSwaggerProcessor.java:95)[78:org.apache.camel.camel-swagger-java:2.16.3]
> at
> org.apache.camel.component.rest.RestApiProducer.process(RestApiProducer.java:36)[71:org.apache.camel.camel-core:2.16.3]
> at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)[71:org.apache.camel.camel-core:2.16.3]
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:145)[71:org.apache.camel.camel-core:2.16.3]
> at
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:77)[71:org.apache.camel.camel-core:2.16.3]
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:460)[71:org.apache.camel.camel-core:2.16.3]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:190)[71:org.apache.camel.camel-core:2.16.3]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:190)[71:org.apache.camel.camel-core:2.16.3]
> at
> org.apache.camel.component.jetty.CamelContinuationServlet.service(CamelContinuationServlet.java:191)[74:org.apache.camel.camel-jetty-common:2.16.3]
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)[63:javax.servlet-api:3.1.0]
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:808)[122:org.eclipse.jetty.servlet:9.2.10.v20150310]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1669)[122:org.eclipse.jetty.servlet:9.2.10.v20150310]
> at
> org.eclipse.jetty.servlets.MultiPartFilter.doFilter(MultiPartFilter.java:146)[123:org.eclipse.jetty.servlets:9.2.10.v20150310]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:43)[74:org.apache.camel.camel-jetty-common:2.16.3]
> at
>
[jira] [Comment Edited] (CAMEL-9857) Installing camel-core in Karaf prevents activemq-camel from deploying successfully
[
https://issues.apache.org/jira/browse/CAMEL-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235295#comment-15235295
]
Ralf Steppacher edited comment on CAMEL-9857 at 4/11/16 3:39 PM:
-
Will do... raised as AMQ-6241.
was (Author: ralfsteppacher):
Will do.
> Installing camel-core in Karaf prevents activemq-camel from deploying
> successfully
> --
>
> Key: CAMEL-9857
> URL: https://issues.apache.org/jira/browse/CAMEL-9857
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.17.0
> Environment: Karaf 4.0.3, Java 8
>Reporter: Ralf Steppacher
>Assignee: Claus Ibsen
>Priority: Critical
>
> Installing {{activemq-camel}} into a virgin Karaf 4.0.3 instance works. If
> {{camel-core}} gets installed before one attempts to install
> {{activemq-camel}}, the latter fails:
> {noformat}
> $ ./karaf
> __ __
>/ //_/ __ _/ __/
> / ,< / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / / / /_/ / __/
> /_/ |_|\__,_/_/ \__,_/_/
> Apache Karaf (4.0.3)
> Hit '' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
> karaf@root()> feature:repo-add activemq 5.13.2
> Adding feature url mvn:org.apache.activemq/activemq-karaf/5.13.2/xml/features
> karaf@root()> feature:repo-add camel 2.17.0
> Adding feature url mvn:org.apache.camel.karaf/apache-camel/2.17.0/xml/features
> karaf@root()> feature:install camel-core
> karaf@root()> feature:install activemq
> activemqactivemq-blueprint activemq-broker
> activemq-broker-noweb
> activemq-camel activemq-client activemq-web-console
> karaf@root()> feature:install activemq-camel
> karaf@root()> bundle:list | grep -i activemq
> 59 | Active | 80 | 5.13.2 | activemq-camel
> 60 | Failure | 80 | 5.13.2 | activemq-osgi
> karaf@root()>
> {noformat}
> Error in Karaf log:
> {noformat}
> 2016-04-11 17:25:25,093 | INFO | nsole user karaf | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | | Adding features:
> activemq-camel/[5.13.2,5.13.2]
> 2016-04-11 17:25:25,804 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | | Changes to perform:
> 2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | | Region: root
> 2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | | Bundles to
> install:
> 2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:org.apache.activemq/activemq-camel/5.13.2
> 2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:org.apache.activemq/activemq-osgi/5.13.2
> 2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:org.apache.camel/camel-blueprint/2.17.0
> 2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:org.apache.camel/camel-jms/2.17.0
> 2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:org.apache.camel/camel-spring/2.17.0
> 2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:commons-net/commons-net/3.3
> 2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:commons-pool/commons-pool/1.6
> 2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:org.apache.commons/commons-pool2/2.4.2
> 2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:org.apache.geronimo.specs/geronimo-j2ee-management_1.1_spec/1.0.1
> 2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:org.apache.geronimo.specs/geronimo-jms_1.1_spec/1.1.1
> 2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 -
[jira] [Commented] (CAMEL-9857) Installing camel-core in Karaf prevents activemq-camel from deploying successfully
[
https://issues.apache.org/jira/browse/CAMEL-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235295#comment-15235295
]
Ralf Steppacher commented on CAMEL-9857:
Will do.
> Installing camel-core in Karaf prevents activemq-camel from deploying
> successfully
> --
>
> Key: CAMEL-9857
> URL: https://issues.apache.org/jira/browse/CAMEL-9857
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.17.0
> Environment: Karaf 4.0.3, Java 8
>Reporter: Ralf Steppacher
>Assignee: Claus Ibsen
>Priority: Critical
>
> Installing {{activemq-camel}} into a virgin Karaf 4.0.3 instance works. If
> {{camel-core}} gets installed before one attempts to install
> {{activemq-camel}}, the latter fails:
> {noformat}
> $ ./karaf
> __ __
>/ //_/ __ _/ __/
> / ,< / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / / / /_/ / __/
> /_/ |_|\__,_/_/ \__,_/_/
> Apache Karaf (4.0.3)
> Hit '' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
> karaf@root()> feature:repo-add activemq 5.13.2
> Adding feature url mvn:org.apache.activemq/activemq-karaf/5.13.2/xml/features
> karaf@root()> feature:repo-add camel 2.17.0
> Adding feature url mvn:org.apache.camel.karaf/apache-camel/2.17.0/xml/features
> karaf@root()> feature:install camel-core
> karaf@root()> feature:install activemq
> activemqactivemq-blueprint activemq-broker
> activemq-broker-noweb
> activemq-camel activemq-client activemq-web-console
> karaf@root()> feature:install activemq-camel
> karaf@root()> bundle:list | grep -i activemq
> 59 | Active | 80 | 5.13.2 | activemq-camel
> 60 | Failure | 80 | 5.13.2 | activemq-osgi
> karaf@root()>
> {noformat}
> Error in Karaf log:
> {noformat}
> 2016-04-11 17:25:25,093 | INFO | nsole user karaf | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | | Adding features:
> activemq-camel/[5.13.2,5.13.2]
> 2016-04-11 17:25:25,804 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | | Changes to perform:
> 2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | | Region: root
> 2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | | Bundles to
> install:
> 2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:org.apache.activemq/activemq-camel/5.13.2
> 2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:org.apache.activemq/activemq-osgi/5.13.2
> 2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:org.apache.camel/camel-blueprint/2.17.0
> 2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:org.apache.camel/camel-jms/2.17.0
> 2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:org.apache.camel/camel-spring/2.17.0
> 2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:commons-net/commons-net/3.3
> 2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:commons-pool/commons-pool/1.6
> 2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:org.apache.commons/commons-pool2/2.4.2
> 2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:org.apache.geronimo.specs/geronimo-j2ee-management_1.1_spec/1.0.1
> 2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:org.apache.geronimo.specs/geronimo-jms_1.1_spec/1.1.1
> 2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
> | 9 - org.apache.karaf.features.core - 4.0.3 | |
> mvn:org.apache.geronimo.specs/geronimo-jta_1.1_spec/1.1.1
>
[jira] [Comment Edited] (CAMEL-9855) REST DSL rest configuration attribute enableCORS has no effect when rendering resource listing/Camel contexts
[
https://issues.apache.org/jira/browse/CAMEL-9855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235193#comment-15235193
]
Ralf Steppacher edited comment on CAMEL-9855 at 4/11/16 3:27 PM:
-
Unfortunately I cannot. My component dependes on activemq-camel which fails to
deploy. With Camel 2.17.0 both version 5.12.1 and 5.13.2 fail to install:
{noformat}
2016-04-11 16:39:55,914 | ERROR | pool-37-thread-1 | BlueprintContainerImpl
| 13 - org.apache.aries.blueprint.core - 1.4.5 | | Unable to start
blueprint container for bundle org.apache.activemq.activemq-osgi/5.13.2
...
Caused by: java.lang.ClassNotFoundException:
org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext not
found by org.apache.activemq.activemq-osgi [53]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)[:1.8.0_77]
... 39 more
{noformat}
I have raised CAMEL-9857 for the activemq issue.
was (Author: ralfsteppacher):
Unfortunately I cannot. My component dependes on activemq-camel which fails to
deploy. With Camel 2.17.0 both version 5.12.1 and 5.13.2 fail to install:
{noformat}
2016-04-11 16:39:55,914 | ERROR | pool-37-thread-1 | BlueprintContainerImpl
| 13 - org.apache.aries.blueprint.core - 1.4.5 | | Unable to start
blueprint container for bundle org.apache.activemq.activemq-osgi/5.13.2
...
Caused by: java.lang.ClassNotFoundException:
org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext not
found by org.apache.activemq.activemq-osgi [53]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)[:1.8.0_77]
... 39 more
{noformat}
> REST DSL rest configuration attribute enableCORS has no effect when rendering
> resource listing/Camel contexts
> -
>
> Key: CAMEL-9855
> URL: https://issues.apache.org/jira/browse/CAMEL-9855
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.16.3
> Environment: Karaf 4.0.3, Java 8, Blueprint
>Reporter: Ralf Steppacher
>Priority: Minor
>
> Setting the attribute {{enableCORS}} to true has no effect, i.e. none of the
> {{Access-Control-*}} are set. To enable CORS headers one has to add an
> {{apiProperty}} element like so:
> {code:xml}
> scheme="http" host="{{host}}" port="{{port}}" apiContextPath="api-docs">
>
>
> />
>
> {code}
> See {{RestSwaggerSupport::renderCamelContexts(...)}} and
> {{RestSwaggerSupport::renderResourceListing(...)}}.
> {{RestSwaggerSupport}} adds the headers with capital first letters:
> {{Access-Control-Allow-Origin}}. However, the response contains the header
> names all lower case. Not sure where they loose the capitalization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9857) Installing camel-core in Karaf prevents activemq-camel from deploying successfully
Ralf Steppacher created CAMEL-9857:
--
Summary: Installing camel-core in Karaf prevents activemq-camel
from deploying successfully
Key: CAMEL-9857
URL: https://issues.apache.org/jira/browse/CAMEL-9857
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.17.0
Environment: Karaf 4.0.3, Java 8
Reporter: Ralf Steppacher
Priority: Critical
Installing {{activemq-camel}} into a virgin Karaf 4.0.3 instance works. If
{{camel-core}} gets installed before one attempts to install
{{activemq-camel}}, the latter fails:
{noformat}
$ ./karaf
__ __
/ //_/ __ _/ __/
/ ,< / __ `/ ___/ __ `/ /_
/ /| |/ /_/ / / / /_/ / __/
/_/ |_|\__,_/_/ \__,_/_/
Apache Karaf (4.0.3)
Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
karaf@root()> feature:repo-add activemq 5.13.2
Adding feature url mvn:org.apache.activemq/activemq-karaf/5.13.2/xml/features
karaf@root()> feature:repo-add camel 2.17.0
Adding feature url mvn:org.apache.camel.karaf/apache-camel/2.17.0/xml/features
karaf@root()> feature:install camel-core
karaf@root()> feature:install activemq
activemqactivemq-blueprint activemq-broker
activemq-broker-noweb
activemq-camel activemq-client activemq-web-console
karaf@root()> feature:install activemq-camel
karaf@root()> bundle:list | grep -i activemq
59 | Active | 80 | 5.13.2 | activemq-camel
60 | Failure | 80 | 5.13.2 | activemq-osgi
karaf@root()>
{noformat}
Error in Karaf log:
{noformat}
2016-04-11 17:25:25,093 | INFO | nsole user karaf | FeaturesServiceImpl
| 9 - org.apache.karaf.features.core - 4.0.3 | | Adding features:
activemq-camel/[5.13.2,5.13.2]
2016-04-11 17:25:25,804 | INFO | pool-41-thread-1 | FeaturesServiceImpl
| 9 - org.apache.karaf.features.core - 4.0.3 | | Changes to perform:
2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
| 9 - org.apache.karaf.features.core - 4.0.3 | | Region: root
2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
| 9 - org.apache.karaf.features.core - 4.0.3 | | Bundles to install:
2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
| 9 - org.apache.karaf.features.core - 4.0.3 | |
mvn:org.apache.activemq/activemq-camel/5.13.2
2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
| 9 - org.apache.karaf.features.core - 4.0.3 | |
mvn:org.apache.activemq/activemq-osgi/5.13.2
2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
| 9 - org.apache.karaf.features.core - 4.0.3 | |
mvn:org.apache.camel/camel-blueprint/2.17.0
2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
| 9 - org.apache.karaf.features.core - 4.0.3 | |
mvn:org.apache.camel/camel-jms/2.17.0
2016-04-11 17:25:25,805 | INFO | pool-41-thread-1 | FeaturesServiceImpl
| 9 - org.apache.karaf.features.core - 4.0.3 | |
mvn:org.apache.camel/camel-spring/2.17.0
2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
| 9 - org.apache.karaf.features.core - 4.0.3 | |
mvn:commons-net/commons-net/3.3
2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
| 9 - org.apache.karaf.features.core - 4.0.3 | |
mvn:commons-pool/commons-pool/1.6
2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
| 9 - org.apache.karaf.features.core - 4.0.3 | |
mvn:org.apache.commons/commons-pool2/2.4.2
2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
| 9 - org.apache.karaf.features.core - 4.0.3 | |
mvn:org.apache.geronimo.specs/geronimo-j2ee-management_1.1_spec/1.0.1
2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
| 9 - org.apache.karaf.features.core - 4.0.3 | |
mvn:org.apache.geronimo.specs/geronimo-jms_1.1_spec/1.1.1
2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
| 9 - org.apache.karaf.features.core - 4.0.3 | |
mvn:org.apache.geronimo.specs/geronimo-jta_1.1_spec/1.1.1
2016-04-11 17:25:25,806 | INFO | pool-41-thread-1 | FeaturesServiceImpl
| 9 - org.apache.karaf.features.core - 4.0.3 | |
mvn:org.apache.zookeeper/zookeeper/3.4.6
2016-04-11 17:25:25,807 | INFO | pool-41-thread-1 | FeaturesServiceImpl
| 9 - org.apache.karaf.features.core - 4.0.3 | |
mvn:org.apache.karaf.bundle/org.apache.karaf.bundle.springstate/4.0.3
2016-04-11 17:25:25,807 | INFO |
[jira] [Created] (CAMEL-9856) RestSwaggerProcessor fails with "Provider org.apache.xalan.processor.TransformerFactoryImpl not found"
Ralf Steppacher created CAMEL-9856:
--
Summary: RestSwaggerProcessor fails with "Provider
org.apache.xalan.processor.TransformerFactoryImpl not found"
Key: CAMEL-9856
URL: https://issues.apache.org/jira/browse/CAMEL-9856
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.16.3
Environment: Karaf 4.0.3, Java 8
Reporter: Ralf Steppacher
When I try to query the Swagger API output for my REST routes, which are
defined in a Blueprint context with the XML DSL, any request to a path that I
think should return API information yields an empty response body (status 200)
on the client and this error on the server. The error is raised by
{{RestSwaggerSupport::getRestDefinitions(String)}} (line 147).
{noformat}
2016-04-11 16:45:29,136 | WARN | qtp215489304-167 | RestSwaggerProcessor
| 78 - org.apache.camel.camel-swagger-java - 2.16.3 | | Error rendering
Swagger API due RuntimeException thrown in RequiredModelMBean while trying to
invoke operation dumpRestsAsXml
javax.management.MBeanException: RuntimeException thrown in RequiredModelMBean
while trying to invoke operation dumpRestsAsXml
at
javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1285)[:1.8.0_77]
at
javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:1085)[:1.8.0_77]
at
org.apache.camel.management.MixinRequiredModelMBean.invoke(MixinRequiredModelMBean.java:70)[71:org.apache.camel.camel-core:2.16.3]
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)[:1.8.0_77]
at
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)[:1.8.0_77]
at
org.apache.camel.swagger.RestSwaggerSupport.getRestDefinitions(RestSwaggerSupport.java:147)[78:org.apache.camel.camel-swagger-java:2.16.3]
at
org.apache.camel.swagger.RestSwaggerSupport.renderResourceListing(RestSwaggerSupport.java:198)[78:org.apache.camel.camel-swagger-java:2.16.3]
at
org.apache.camel.swagger.RestSwaggerProcessor.process(RestSwaggerProcessor.java:95)[78:org.apache.camel.camel-swagger-java:2.16.3]
at
org.apache.camel.component.rest.RestApiProducer.process(RestApiProducer.java:36)[71:org.apache.camel.camel-core:2.16.3]
at
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)[71:org.apache.camel.camel-core:2.16.3]
at
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:145)[71:org.apache.camel.camel-core:2.16.3]
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:77)[71:org.apache.camel.camel-core:2.16.3]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:460)[71:org.apache.camel.camel-core:2.16.3]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:190)[71:org.apache.camel.camel-core:2.16.3]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:190)[71:org.apache.camel.camel-core:2.16.3]
at
org.apache.camel.component.jetty.CamelContinuationServlet.service(CamelContinuationServlet.java:191)[74:org.apache.camel.camel-jetty-common:2.16.3]
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:790)[63:javax.servlet-api:3.1.0]
at
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:808)[122:org.eclipse.jetty.servlet:9.2.10.v20150310]
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1669)[122:org.eclipse.jetty.servlet:9.2.10.v20150310]
at
org.eclipse.jetty.servlets.MultiPartFilter.doFilter(MultiPartFilter.java:146)[123:org.eclipse.jetty.servlets:9.2.10.v20150310]
at
org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:43)[74:org.apache.camel.camel-jetty-common:2.16.3]
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)[122:org.eclipse.jetty.servlet:9.2.10.v20150310]
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)[122:org.eclipse.jetty.servlet:9.2.10.v20150310]
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)[121:org.eclipse.jetty.server:9.2.10.v20150310]
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)[122:org.eclipse.jetty.servlet:9.2.10.v20150310]
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)[121:org.eclipse.jetty.server:9.2.10.v20150310]
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)[121:org.eclipse.jetty.server:9.2.10.v20150310]
at
[jira] [Commented] (CAMEL-9855) REST DSL rest configuration attribute enableCORS has no effect when rendering resource listing/Camel contexts
[
https://issues.apache.org/jira/browse/CAMEL-9855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235193#comment-15235193
]
Ralf Steppacher commented on CAMEL-9855:
Unfortunately I cannot. My component dependes on activemq-camel which fails to
deploy. With Camel 2.17.0 both version 5.12.1 and 5.13.2 fail to install:
{noformat}
2016-04-11 16:39:55,914 | ERROR | pool-37-thread-1 | BlueprintContainerImpl
| 13 - org.apache.aries.blueprint.core - 1.4.5 | | Unable to start
blueprint container for bundle org.apache.activemq.activemq-osgi/5.13.2
...
Caused by: java.lang.ClassNotFoundException:
org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext not
found by org.apache.activemq.activemq-osgi [53]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)[:1.8.0_77]
... 39 more
{noformat}
> REST DSL rest configuration attribute enableCORS has no effect when rendering
> resource listing/Camel contexts
> -
>
> Key: CAMEL-9855
> URL: https://issues.apache.org/jira/browse/CAMEL-9855
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.16.3
> Environment: Karaf 4.0.3, Java 8, Blueprint
>Reporter: Ralf Steppacher
>Priority: Minor
>
> Setting the attribute {{enableCORS}} to true has no effect, i.e. none of the
> {{Access-Control-*}} are set. To enable CORS headers one has to add an
> {{apiProperty}} element like so:
> {code:xml}
> scheme="http" host="{{host}}" port="{{port}}" apiContextPath="api-docs">
>
>
> />
>
> {code}
> See {{RestSwaggerSupport::renderCamelContexts(...)}} and
> {{RestSwaggerSupport::renderResourceListing(...)}}.
> {{RestSwaggerSupport}} adds the headers with capital first letters:
> {{Access-Control-Allow-Origin}}. However, the response contains the header
> names all lower case. Not sure where they loose the capitalization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9855) REST DSL rest configuration attribute enableCORS has no effect when rendering resource listing/Camel contexts
[
https://issues.apache.org/jira/browse/CAMEL-9855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-9855:
---
Description:
Setting the attribute {{enableCORS}} to true has no effect, i.e. none of the
{{Access-Control-*}} are set. To enable CORS headers one has to add an
{{apiProperty}} element like so:
{code:xml}
/>
{code}
See {{RestSwaggerSupport::renderCamelContexts(...)}} and
{{RestSwaggerSupport::renderResourceListing(...)}}.
{{RestSwaggerSupport}} adds the headers with capital first letters:
{{Access-Control-Allow-Origin}}. However, the response contains the header
names all lower case. Not sure where they loose the capitalization.
was:
Setting the attribute {{enableCORS}} to true has no effect, i.e. none of the
{{Access-Control-*}} are set. To enable CORS headers one has to add an
{{apiProperty}} element like so:
{code:xml}
/>
{code}
See {{RestSwaggerSupport::renderCamelContexts(...)}} and
{{RestSwaggerSupport::renderResourceListing(...)}}.
{{RestSwaggerSupport}} adds the headers in with capital first letters:
{{Access-Control-Allow-Origin}}. However, the response contains the header
names all lower case. Not sure where they loose the capitalization.
> REST DSL rest configuration attribute enableCORS has no effect when rendering
> resource listing/Camel contexts
> -
>
> Key: CAMEL-9855
> URL: https://issues.apache.org/jira/browse/CAMEL-9855
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.16.3
> Environment: Karaf 4.0.3, Java 8, Blueprint
>Reporter: Ralf Steppacher
>Priority: Minor
>
> Setting the attribute {{enableCORS}} to true has no effect, i.e. none of the
> {{Access-Control-*}} are set. To enable CORS headers one has to add an
> {{apiProperty}} element like so:
> {code:xml}
> scheme="http" host="{{host}}" port="{{port}}" apiContextPath="api-docs">
>
>
> />
>
> {code}
> See {{RestSwaggerSupport::renderCamelContexts(...)}} and
> {{RestSwaggerSupport::renderResourceListing(...)}}.
> {{RestSwaggerSupport}} adds the headers with capital first letters:
> {{Access-Control-Allow-Origin}}. However, the response contains the header
> names all lower case. Not sure where they loose the capitalization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9855) REST DSL rest configuration attribute enableCORS has no effect when rendering resource listing/Camel contexts
Ralf Steppacher created CAMEL-9855:
--
Summary: REST DSL rest configuration attribute enableCORS has no
effect when rendering resource listing/Camel contexts
Key: CAMEL-9855
URL: https://issues.apache.org/jira/browse/CAMEL-9855
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.16.3
Environment: Karaf 4.0.3, Java 8, Blueprint
Reporter: Ralf Steppacher
Priority: Minor
Setting the attribute {{enableCORS}} to true has no effect, i.e. none of the
{{Access-Control-*}} are set. To enable CORS headers one has to add an
{{apiProperty}} element like so:
{code:xml}
/>
{code}
See {{RestSwaggerSupport::renderCamelContexts(...)}} and
{{RestSwaggerSupport::renderResourceListing(...)}}.
{{RestSwaggerSupport}} adds the headers in with capital first letters:
{{Access-Control-Allow-Origin}}. However, the response contains the header
names all lower case. Not sure where they loose the capitalization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-9040) netty4-http - LEAK: ByteBuf.release() was not called before it's garbage-collected
[
https://issues.apache.org/jira/browse/CAMEL-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15210218#comment-15210218
]
Ralf Steppacher edited comment on CAMEL-9040 at 3/24/16 1:33 PM:
-
Sorry for the long wait!
I tried with 2.16.2 and the problem persists. Though it appears it only shows
under load now. When making single requests there are no errors. But when
running my stress tests I start to get intermittent errors as before (with
-Dio.netty.leakDetectionLevel=paranoid):
{noformat}
2016-03-24 14:28:08,486 | ERROR | qtp99151234-420 | ResourceLeakDetector
| 63 - io.netty.common - 4.0.33.Final |
ID-Ralfs-MacBook-Pro-local-57997-1458825709312-5-15981 | LEAK:
ByteBuf.release() was not called before it's garbage-collected. See
http://netty.io/wiki/reference-counted-objects.html for more information.
Recent access records: 5
#5:
io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:245)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:687)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:42)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:694)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1496)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:42)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
java.io.BufferedInputStream.read(BufferedInputStream.java:345)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.MergedReader.read(MergedReader.java:105)
com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:86)
com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:56)
com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:1001)
com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:1046)
com.ctc.wstx.sr.StreamScanner.getNextChar(StreamScanner.java:793)
com.ctc.wstx.sr.BasicStreamReader.parseAttrValue(BasicStreamReader.java:1894)
com.ctc.wstx.sr.BasicStreamReader.handleNsAttrs(BasicStreamReader.java:3065)
com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2963)
com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2839)
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1073)
ch.vivates.pep.stream.ResponseStatusFilter.handleSimpleMessage(ResponseStatusFilter.java:61)
ch.vivates.pep.stream.BaseStreamFilter.filter(BaseStreamFilter.java:168)
ch.vivates.pep.stream.BaseStreamFilter.run(BaseStreamFilter.java:184)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
java.util.concurrent.FutureTask.run(FutureTask.java:266)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)
#4:
io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:245)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:687)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:42)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:694)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1496)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:42)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
java.io.BufferedInputStream.read(BufferedInputStream.java:345)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.MergedReader.read(MergedReader.java:105)
com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:86)
com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:56)
com.ctc.wstx.sr.StreamScanner.loadMoreFromCurrent(StreamScanner.java:1060)
com.ctc.wstx.sr.StreamScanner.parseLocalName2(StreamScanner.java:1870)
com.ctc.wstx.sr.StreamScanner.parseLocalName(StreamScanner.java:1830)
com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2941)
[jira] [Commented] (CAMEL-9040) netty4-http - LEAK: ByteBuf.release() was not called before it's garbage-collected
[
https://issues.apache.org/jira/browse/CAMEL-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15210218#comment-15210218
]
Ralf Steppacher commented on CAMEL-9040:
I tried with 2.16.2 and the problem persists. Though it appears it only shows
under load now. When making single requests there are no errors. But when
running my stress tests is start to get intermittent errors as before (with
-Dio.netty.leakDetectionLevel=paranoid):
{noformat}
2016-03-24 14:28:08,486 | ERROR | qtp99151234-420 | ResourceLeakDetector
| 63 - io.netty.common - 4.0.33.Final |
ID-Ralfs-MacBook-Pro-local-57997-1458825709312-5-15981 | LEAK:
ByteBuf.release() was not called before it's garbage-collected. See
http://netty.io/wiki/reference-counted-objects.html for more information.
Recent access records: 5
#5:
io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:245)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:687)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:42)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:694)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1496)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:42)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
java.io.BufferedInputStream.read(BufferedInputStream.java:345)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.MergedReader.read(MergedReader.java:105)
com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:86)
com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:56)
com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:1001)
com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:1046)
com.ctc.wstx.sr.StreamScanner.getNextChar(StreamScanner.java:793)
com.ctc.wstx.sr.BasicStreamReader.parseAttrValue(BasicStreamReader.java:1894)
com.ctc.wstx.sr.BasicStreamReader.handleNsAttrs(BasicStreamReader.java:3065)
com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2963)
com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2839)
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1073)
ch.vivates.pep.stream.ResponseStatusFilter.handleSimpleMessage(ResponseStatusFilter.java:61)
ch.vivates.pep.stream.BaseStreamFilter.filter(BaseStreamFilter.java:168)
ch.vivates.pep.stream.BaseStreamFilter.run(BaseStreamFilter.java:184)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
java.util.concurrent.FutureTask.run(FutureTask.java:266)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)
#4:
io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:245)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:687)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:42)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:694)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1496)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:42)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
java.io.BufferedInputStream.read(BufferedInputStream.java:345)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.MergedReader.read(MergedReader.java:105)
com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:86)
com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:56)
com.ctc.wstx.sr.StreamScanner.loadMoreFromCurrent(StreamScanner.java:1060)
com.ctc.wstx.sr.StreamScanner.parseLocalName2(StreamScanner.java:1870)
com.ctc.wstx.sr.StreamScanner.parseLocalName(StreamScanner.java:1830)
com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2941)
com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2839)
[jira] [Comment Edited] (CAMEL-9040) netty4-http - LEAK: ByteBuf.release() was not called before it's garbage-collected
[
https://issues.apache.org/jira/browse/CAMEL-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15210218#comment-15210218
]
Ralf Steppacher edited comment on CAMEL-9040 at 3/24/16 1:32 PM:
-
Sorry for the long wait!
I tried with 2.16.2 and the problem persists. Though it appears it only shows
under load now. When making single requests there are no errors. But when
running my stress tests is start to get intermittent errors as before (with
-Dio.netty.leakDetectionLevel=paranoid):
{noformat}
2016-03-24 14:28:08,486 | ERROR | qtp99151234-420 | ResourceLeakDetector
| 63 - io.netty.common - 4.0.33.Final |
ID-Ralfs-MacBook-Pro-local-57997-1458825709312-5-15981 | LEAK:
ByteBuf.release() was not called before it's garbage-collected. See
http://netty.io/wiki/reference-counted-objects.html for more information.
Recent access records: 5
#5:
io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:245)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:687)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:42)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:694)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1496)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:42)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
java.io.BufferedInputStream.read(BufferedInputStream.java:345)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.MergedReader.read(MergedReader.java:105)
com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:86)
com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:56)
com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:1001)
com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:1046)
com.ctc.wstx.sr.StreamScanner.getNextChar(StreamScanner.java:793)
com.ctc.wstx.sr.BasicStreamReader.parseAttrValue(BasicStreamReader.java:1894)
com.ctc.wstx.sr.BasicStreamReader.handleNsAttrs(BasicStreamReader.java:3065)
com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2963)
com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2839)
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1073)
ch.vivates.pep.stream.ResponseStatusFilter.handleSimpleMessage(ResponseStatusFilter.java:61)
ch.vivates.pep.stream.BaseStreamFilter.filter(BaseStreamFilter.java:168)
ch.vivates.pep.stream.BaseStreamFilter.run(BaseStreamFilter.java:184)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
java.util.concurrent.FutureTask.run(FutureTask.java:266)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)
#4:
io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:245)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:687)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:42)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:694)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1496)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:42)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
java.io.BufferedInputStream.read(BufferedInputStream.java:345)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.MergedReader.read(MergedReader.java:105)
com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:86)
com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:56)
com.ctc.wstx.sr.StreamScanner.loadMoreFromCurrent(StreamScanner.java:1060)
com.ctc.wstx.sr.StreamScanner.parseLocalName2(StreamScanner.java:1870)
com.ctc.wstx.sr.StreamScanner.parseLocalName(StreamScanner.java:1830)
com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2941)
[jira] [Updated] (CAMEL-9623) camel-example-swagger-cdi does not run
[
https://issues.apache.org/jira/browse/CAMEL-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-9623:
---
Description:
I am trying to run the example {{camel-example-swagger-cdi}} as documented in
the {{README.md}} but the goal {{camel:run}} fails:
{noformat}
Ralfs-MacBook-Pro:camel-example-swagger-cdi rsteppac$ ~/dev/maven-3.2.1/bin/mvn
-s ~/dev/git/vivatesmaven/settings-nexus.xml camel:run
[..]
[INFO] Using org.apache.camel.spring.Main to initiate a CamelContext
[INFO] Starting Camel ...
[ERROR] *
[ERROR] Error occurred while running main from: org.apache.camel.spring.Main
[ERROR]
java.lang.ClassNotFoundException: org.apache.camel.spring.Main
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.apache.camel.maven.RunMojo$1.run(RunMojo.java:455)
at java.lang.Thread.run(Thread.java:745)
{noformat}
In response I added {{camel-spring}} to the dependency list in the pom. Next
run fails because no spring context is available:
{noformat}
Caused by: java.io.FileNotFoundException: class path resource
[META-INF/spring/] cannot be resolved to URL because it does not exist
at
org.springframework.core.io.ClassPathResource.getURL(ClassPathResource.java:187)
at
org.springframework.core.io.support.PathMatchingResourcePatternResolver.findPathMatchingResources(PathMatchingResourcePatternResolver.java:413)
at
org.springframework.core.io.support.PathMatchingResourcePatternResolver.getResources(PathMatchingResourcePatternResolver.java:287)
at
org.springframework.context.support.AbstractApplicationContext.getResources(AbstractApplicationContext.java:1166)
at
org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:216)
... 21 more
{noformat}
Indeed no spring context file is provided with the project.
was:
I am trying to run the example {{camel-example-swagger-cdi}} as documented in
the {{README.md}} but the goal {{camel:run}} fails:
{noformat}
Ralfs-MacBook-Pro:camel-example-swagger-cdi rsteppac$ ~/dev/maven-3.2.1/bin/mvn
-s ~/dev/git/vivatesmaven/settings-nexus.xml camel:run
[..]
[INFO] Using org.apache.camel.spring.Main to initiate a CamelContext
[INFO] Starting Camel ...
[ERROR] *
[ERROR] Error occurred while running main from: org.apache.camel.spring.Main
[ERROR]
java.lang.ClassNotFoundException: org.apache.camel.spring.Main
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.apache.camel.maven.RunMojo$1.run(RunMojo.java:455)
at java.lang.Thread.run(Thread.java:745)
[ERROR] *
{noformat}
In response I added {{camel-spring}} to the dependency list in the pom. Next
run fails because no spring context is available:
{noformat}
Caused by: java.io.FileNotFoundException: class path resource
[META-INF/spring/] cannot be resolved to URL because it does not exist
at
org.springframework.core.io.ClassPathResource.getURL(ClassPathResource.java:187)
at
org.springframework.core.io.support.PathMatchingResourcePatternResolver.findPathMatchingResources(PathMatchingResourcePatternResolver.java:413)
at
org.springframework.core.io.support.PathMatchingResourcePatternResolver.getResources(PathMatchingResourcePatternResolver.java:287)
at
org.springframework.context.support.AbstractApplicationContext.getResources(AbstractApplicationContext.java:1166)
at
org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:216)
... 21 more
{noformat}
Indeed no spring context file is provided with the project.
> camel-example-swagger-cdi does not run
> --
>
> Key: CAMEL-9623
> URL: https://issues.apache.org/jira/browse/CAMEL-9623
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.16.2
>Reporter: Ralf Steppacher
>Priority: Minor
>
> I am trying to run the example {{camel-example-swagger-cdi}} as documented in
> the {{README.md}} but the goal {{camel:run}} fails:
> {noformat}
> Ralfs-MacBook-Pro:camel-example-swagger-cdi rsteppac$
> ~/dev/maven-3.2.1/bin/mvn -s ~/dev/git/vivatesmaven/settings-nexus.xml
> camel:run
> [..]
> [INFO] Using org.apache.camel.spring.Main to initiate a CamelContext
> [INFO] Starting Camel ...
> [ERROR] *
> [ERROR] Error occurred while running main from: org.apache.camel.spring.Main
[jira] [Updated] (CAMEL-9623) camel-example-swagger-cdi does not run
[
https://issues.apache.org/jira/browse/CAMEL-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-9623:
---
Description:
I am trying to run the example {{camel-example-swagger-cdi}} as documented in
the {{README.md}} but the goal {{camel:run}} fails:
{noformat}
Ralfs-MacBook-Pro:camel-example-swagger-cdi rsteppac$ ~/dev/maven-3.2.1/bin/mvn
-s ~/dev/git/vivatesmaven/settings-nexus.xml camel:run
[..]
[INFO] Using org.apache.camel.spring.Main to initiate a CamelContext
[INFO] Starting Camel ...
[ERROR] *
[ERROR] Error occurred while running main from: org.apache.camel.spring.Main
[ERROR]
java.lang.ClassNotFoundException: org.apache.camel.spring.Main
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.apache.camel.maven.RunMojo$1.run(RunMojo.java:455)
at java.lang.Thread.run(Thread.java:745)
[ERROR] *
{noformat}
In response I added {{camel-spring}} to the dependency list in the pom. Next
run fails because no spring context is available:
{noformat}
Caused by: java.io.FileNotFoundException: class path resource
[META-INF/spring/] cannot be resolved to URL because it does not exist
at
org.springframework.core.io.ClassPathResource.getURL(ClassPathResource.java:187)
at
org.springframework.core.io.support.PathMatchingResourcePatternResolver.findPathMatchingResources(PathMatchingResourcePatternResolver.java:413)
at
org.springframework.core.io.support.PathMatchingResourcePatternResolver.getResources(PathMatchingResourcePatternResolver.java:287)
at
org.springframework.context.support.AbstractApplicationContext.getResources(AbstractApplicationContext.java:1166)
at
org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:216)
... 21 more
{noformat}
Indeed no spring context file is provided with the project.
was:
I am trying to run the example {{camel-example-swagger-cdi}} as documented in
the {{README.md}} but the goal {{camel:run}} fails:
{noformat}
Ralfs-MacBook-Pro:camel-example-swagger-cdi rsteppac$ ~/dev/maven-3.2.1/bin/mvn
-s ~/dev/git/vivatesmaven/settings-nexus.xml camel:run
[..]
[INFO] Using org.apache.camel.spring.Main to initiate a CamelContext
[INFO] Starting Camel ...
[ERROR] *
[ERROR] Error occurred while running main from: org.apache.camel.spring.Main
[ERROR]
java.lang.ClassNotFoundException: org.apache.camel.spring.Main
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.apache.camel.maven.RunMojo$1.run(RunMojo.java:455)
at java.lang.Thread.run(Thread.java:745)
[ERROR] *
{noformat}
In response I added {{camel-spring}} to the dependency list in the pom. Next
run fails because no spring context is available:
{noformat}
Caused by: java.io.FileNotFoundException: class path resource
[META-INF/spring/] cannot be resolved to URL because it does not exist
at
org.springframework.core.io.ClassPathResource.getURL(ClassPathResource.java:187)
at
org.springframework.core.io.support.PathMatchingResourcePatternResolver.findPathMatchingResources(PathMatchingResourcePatternResolver.java:413)
at
org.springframework.core.io.support.PathMatchingResourcePatternResolver.getResources(PathMatchingResourcePatternResolver.java:287)
at
org.springframework.context.support.AbstractApplicationContext.getResources(AbstractApplicationContext.java:1166)
at
org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:216)
... 21 more
[ERROR] *
{noformat}
Indeed no spring context file is provided with the project.
> camel-example-swagger-cdi does not run
> --
>
> Key: CAMEL-9623
> URL: https://issues.apache.org/jira/browse/CAMEL-9623
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.16.2
>Reporter: Ralf Steppacher
>Priority: Minor
>
> I am trying to run the example {{camel-example-swagger-cdi}} as documented in
> the {{README.md}} but the goal {{camel:run}} fails:
> {noformat}
> Ralfs-MacBook-Pro:camel-example-swagger-cdi rsteppac$
> ~/dev/maven-3.2.1/bin/mvn -s ~/dev/git/vivatesmaven/settings-nexus.xml
> camel:run
> [..]
> [INFO] Using org.apache.camel.spring.Main to initiate a CamelContext
> [INFO] Starting Camel ...
> [ERROR]
[jira] [Created] (CAMEL-9623) camel-example-swagger-cdi does not run
Ralf Steppacher created CAMEL-9623:
--
Summary: camel-example-swagger-cdi does not run
Key: CAMEL-9623
URL: https://issues.apache.org/jira/browse/CAMEL-9623
Project: Camel
Issue Type: Bug
Affects Versions: 2.16.2
Reporter: Ralf Steppacher
Priority: Minor
I am trying to run the example {{camel-example-swagger-cdi}} as documented in
the {{README.md}} but the goal {{camel:run}} fails:
{noformat}
Ralfs-MacBook-Pro:camel-example-swagger-cdi rsteppac$ ~/dev/maven-3.2.1/bin/mvn
-s ~/dev/git/vivatesmaven/settings-nexus.xml camel:run
[..]
[INFO] Using org.apache.camel.spring.Main to initiate a CamelContext
[INFO] Starting Camel ...
[ERROR] *
[ERROR] Error occurred while running main from: org.apache.camel.spring.Main
[ERROR]
java.lang.ClassNotFoundException: org.apache.camel.spring.Main
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.apache.camel.maven.RunMojo$1.run(RunMojo.java:455)
at java.lang.Thread.run(Thread.java:745)
[ERROR] *
{noformat}
In response I added {{camel-spring}} to the dependency list in the pom. Next
run fails because no spring context is available:
{noformat}
Caused by: java.io.FileNotFoundException: class path resource
[META-INF/spring/] cannot be resolved to URL because it does not exist
at
org.springframework.core.io.ClassPathResource.getURL(ClassPathResource.java:187)
at
org.springframework.core.io.support.PathMatchingResourcePatternResolver.findPathMatchingResources(PathMatchingResourcePatternResolver.java:413)
at
org.springframework.core.io.support.PathMatchingResourcePatternResolver.getResources(PathMatchingResourcePatternResolver.java:287)
at
org.springframework.context.support.AbstractApplicationContext.getResources(AbstractApplicationContext.java:1166)
at
org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:216)
... 21 more
[ERROR] *
{noformat}
Indeed no spring context file is provided with the project.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9040) netty4-http - LEAK: ByteBuf.release() was not called before it's garbage-collected
[
https://issues.apache.org/jira/browse/CAMEL-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15147051#comment-15147051
]
Ralf Steppacher commented on CAMEL-9040:
[~davsclaus], thank you for your support! I will try to test, but as I have
completely abandoned {{netty4-http}} in my projects I first need to set up a
test. I hope I can do it some time this week, but cannot promise.
> netty4-http - LEAK: ByteBuf.release() was not called before it's
> garbage-collected
> --
>
> Key: CAMEL-9040
> URL: https://issues.apache.org/jira/browse/CAMEL-9040
> Project: Camel
> Issue Type: Bug
> Components: camel-netty4-http
>Affects Versions: 2.15.1, 2.15.2
> Environment: Karaf 3.0.3
>Reporter: Ralf Steppacher
>Priority: Critical
>
> In a reverse-proxy with multiple routes that utilize the {{netty4-http}}
> component both as the consumer and producer I am receiving the following
> error:
> {noformat}
> 2015-07-30 11:52:34,416 | ERROR | yServerTCPWorker | ResourceLeakDetector
> | 97 - io.netty.common - 4.0.27.Final | | LEAK: ByteBuf.release()
> was not called before it's garbage-collected. See
> http://netty.io/wiki/reference-counted-objects.html for more information.
> {noformat}
> Setting the Netty leak reporting to paranoid
> ({{-Dio.netty.leakDetectionLevel=paranoid}}) yields an error for almost every
> request (it probably is 1:1).
> The stacktraces come in two variants. Variant 1 is far less frequent than
> variant 2.
> Variant 1:
> {noformat}
> Recent access records: 0
> Created at:
> io.netty.buffer.CompositeByteBuf.(CompositeByteBuf.java:60)
> io.netty.buffer.Unpooled.compositeBuffer(Unpooled.java:353)
> io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:153)
> io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:54)
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:242)
> io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:147)
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
> io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
> java.lang.Thread.run(Thread.java:745)
> {noformat}
> Variant 2:
> {noformat}
> Recent access records: 5
> #5:
> io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:223)
> io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:684)
> io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:40)
> io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:677)
> io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1493)
> io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:40)
> io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
> java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
> java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
> java.io.BufferedInputStream.read(BufferedInputStream.java:334)
> org.bouncycastle.util.io.TeeInputStream.read(Unknown Source)
> com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
> com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
> com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
> com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:250)
> com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:133)
> com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:545)
> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:605)
> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:628)
> com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:331)
> ch.vivates.pep.stream.ResponseStatusFilter.filter(ResponseStatusFilter.java:41)
>
[jira] [Commented] (CAMEL-9596) REST DSL - Jetty component ignores custom HTTP Binding
[
https://issues.apache.org/jira/browse/CAMEL-9596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15147049#comment-15147049
]
Ralf Steppacher commented on CAMEL-9596:
Hello [~davsclaus]. Thanks for adding the feature.
>From reading the documentation of the REST DSL I got the impression that I
>should be able to configure the endpoint or component through the
>{{}} tag as if I was using the component directly. Maybe
>the documentation could be improved to point out limitations like this? Also
>that someone would have to extend {{JettyRestHttpBinding}} instead of
>{{DefaultHttpBinding}}.
> REST DSL - Jetty component ignores custom HTTP Binding
> ---
>
> Key: CAMEL-9596
> URL: https://issues.apache.org/jira/browse/CAMEL-9596
> Project: Camel
> Issue Type: Improvement
> Components: camel-jetty
>Affects Versions: 2.16.2
> Environment: Karaf, Blueprint
>Reporter: Ralf Steppacher
>Assignee: Claus Ibsen
> Fix For: 2.16.3, 2.17.0
>
>
> I am attempting to set a custom HTTP binding on the Jetty component used with
> the REST DSL:
> {code:xml}
> class="ch.vivates.vel.rest.JettyNoStacktraceHttpBinding" />
> xmlns="http://camel.apache.org/schema/blueprint; streamCache="false">
> host="{{vel.rest.host}}" port="{{vel.rest.port}}"
> contextPath="{{vel.rest.contextpath}}" bindingMode="json">
> value="jettyNoStackTraceHTTPBinding" />
>
>
>
> {code}
> The http binding is not picked up though. At runtime the custom binding does
> not get triggered.
> The logs show the generated endpoint URL without the {{httpBindingRef}} query
> parameter:
> {noformat}
> 2016-02-12 16:22:15,454 | INFO | pool-37-thread-1 | BlueprintCamelContext
> | 64 - org.apache.camel.camel-core - 2.16.2 | | Route: route1
> started and consuming from:
> Endpoint[jetty:http://0.0.0.0:8181/vivates/vel/event/%7Bid%7D?httpMethodRestrict=PUT]
> {noformat}
> However, if I try to specify a binding bean that does not exist I receive an
> error during context ramp-up (as would be expected); the endpoint URI logged
> in the error message includes the {{httpBindingRef}} query parameter:
> {noformat}
> 2016-02-12 16:26:17,194 | ERROR | Thread-35| BlueprintCamelContext
> | 61 - org.apache.camel.camel-blueprint - 2.16.2 | | Error occurred
> during starting Camel: CamelContext(vel-jetty-rest-service) due Failed to
> resolve endpoint:
> jetty://http://0.0.0.0:8181/vivates/vel/event/%7Bid%7D?httpBindingRef=thisBindingBeanDoesNotExist=PUT
> due to: No bean could be found in the registry for:
> thisBindingBeanDoesNotExist of type: org.apache.camel.http.common.HttpBinding
> org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint:
> jetty://http://0.0.0.0:8181/vivates/vel/event/%7Bid%7D?httpBindingRef=thisBindingBeanDoesNotExist=PUT
> due to: No bean could be found in the registry for:
> thisBindingBeanDoesNotExist of type: org.apache.camel.http.common.HttpBinding
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9596) REST DSL - Jetty component ignores custom HTTP Binding
Ralf Steppacher created CAMEL-9596:
--
Summary: REST DSL - Jetty component ignores custom HTTP Binding
Key: CAMEL-9596
URL: https://issues.apache.org/jira/browse/CAMEL-9596
Project: Camel
Issue Type: Bug
Components: camel-jetty
Affects Versions: 2.16.2
Environment: Karaf, Blueprint
Reporter: Ralf Steppacher
I am attempting to set a custom HTTP binding on the Jetty component used with
the REST DSL:
{code:xml}
http://camel.apache.org/schema/blueprint; streamCache="false">
{code}
The http binding is not picked up though. At runtime the custom binding does
not get triggered.
The logs show the generated endpoint URL without the {{httpBindingRef}} query
parameter:
{noformat}
2016-02-12 16:22:15,454 | INFO | pool-37-thread-1 | BlueprintCamelContext
| 64 - org.apache.camel.camel-core - 2.16.2 | | Route: route1 started
and consuming from:
Endpoint[jetty:http://0.0.0.0:8181/vivates/vel/event/%7Bid%7D?httpMethodRestrict=PUT]
{noformat}
However, if I try to specify a binding bean that does not exist I receive an
error during context ramp-up (as would be expected); the endpoint URI logged in
the error message includes the {{httpBindingRef}} query parameter:
{noformat}
2016-02-12 16:26:17,194 | ERROR | Thread-35| BlueprintCamelContext
| 61 - org.apache.camel.camel-blueprint - 2.16.2 | | Error occurred
during starting Camel: CamelContext(vel-jetty-rest-service) due Failed to
resolve endpoint:
jetty://http://0.0.0.0:8181/vivates/vel/event/%7Bid%7D?httpBindingRef=thisBindingBeanDoesNotExist=PUT
due to: No bean could be found in the registry for:
thisBindingBeanDoesNotExist of type: org.apache.camel.http.common.HttpBinding
org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint:
jetty://http://0.0.0.0:8181/vivates/vel/event/%7Bid%7D?httpBindingRef=thisBindingBeanDoesNotExist=PUT
due to: No bean could be found in the registry for:
thisBindingBeanDoesNotExist of type: org.apache.camel.http.common.HttpBinding
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9502) Re-installing bundle using camel-cxf throws javax.management.InstanceAlreadyExistsException
[
https://issues.apache.org/jira/browse/CAMEL-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15095757#comment-15095757
]
Ralf Steppacher commented on CAMEL-9502:
[~njiang], yes. In fact, the problem is reproducible by re-installing just the
camel-cxf feature.
{code}
karaf@root()> feature:repo-add camel 2.16.1
Adding feature url mvn:org.apache.camel.karaf/apache-camel/2.16.1/xml/features
karaf@root()> feature:install camel-cxf
karaf@root()> feature:uninstall camel-cxf
karaf@root()> feature:install camel-cxf
karaf@root()>
{code}
> Re-installing bundle using camel-cxf throws
> javax.management.InstanceAlreadyExistsException
> ---
>
> Key: CAMEL-9502
> URL: https://issues.apache.org/jira/browse/CAMEL-9502
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf, karaf
>Affects Versions: 2.16.1
> Environment: Karaf 4.0.3
>Reporter: Ralf Steppacher
>Priority: Minor
>
> Re-installing a bundle (in my case via a feature) that uses camel-cxf throws
> 3 instances of {{javax.management.InstanceAlreadyExistsException}}:
> {noformat}
> 2016-01-12 09:57:15,974 | WARN | pache.cxf.osgi]) | MBeanContainer
> | 222 - org.eclipse.jetty.util - 9.2.10.v20150310 | | bean:
> org.eclipse.jetty.server.session.HashSessionIdManager@398c8e55
> javax.management.InstanceAlreadyExistsException:
> org.eclipse.jetty.server.session:type=hashsessionidmanager,id=0
> at
> com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)[:1.8.0_40]
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)[:1.8.0_40]
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)[:1.8.0_40]
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)[:1.8.0_40]
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)[:1.8.0_40]
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)[:1.8.0_40]
> at
> org.eclipse.jetty.jmx.MBeanContainer.beanAdded(MBeanContainer.java:209)[214:org.eclipse.jetty.jmx:9.2.10.v20150310]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:264)[222:org.eclipse.jetty.util:9.2.10.v20150310]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:228)[222:org.eclipse.jetty.util:9.2.10.v20150310]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.updateBean(ContainerLifeCycle.java:777)[222:org.eclipse.jetty.util:9.2.10.v20150310]
> at
> org.eclipse.jetty.server.Server.setSessionIdManager(Server.java:578)[219:org.eclipse.jetty.server:9.2.10.v20150310]
> at
> org.eclipse.jetty.server.session.AbstractSessionManager.doStart(AbstractSessionManager.java:247)[219:org.eclipse.jetty.server:9.2.10.v20150310]
> at
> org.eclipse.jetty.server.session.HashSessionManager.doStart(HashSessionManager.java:153)[219:org.eclipse.jetty.server:9.2.10.v20150310]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)[222:org.eclipse.jetty.util:9.2.10.v20150310]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)[222:org.eclipse.jetty.util:9.2.10.v20150310]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)[222:org.eclipse.jetty.util:9.2.10.v20150310]
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)[219:org.eclipse.jetty.server:9.2.10.v20150310]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.doStart(ScopedHandler.java:120)[219:org.eclipse.jetty.server:9.2.10.v20150310]
> at
> org.eclipse.jetty.server.session.SessionHandler.doStart(SessionHandler.java:116)[219:org.eclipse.jetty.server:9.2.10.v20150310]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)[222:org.eclipse.jetty.util:9.2.10.v20150310]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)[222:org.eclipse.jetty.util:9.2.10.v20150310]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)[222:org.eclipse.jetty.util:9.2.10.v20150310]
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)[219:org.eclipse.jetty.server:9.2.10.v20150310]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.doStart(ScopedHandler.java:120)[219:org.eclipse.jetty.server:9.2.10.v20150310]
> at
[jira] [Comment Edited] (CAMEL-9502) Re-installing bundle using camel-cxf throws javax.management.InstanceAlreadyExistsException
[
https://issues.apache.org/jira/browse/CAMEL-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15095757#comment-15095757
]
Ralf Steppacher edited comment on CAMEL-9502 at 1/13/16 7:28 AM:
-
[~njiang], yes, the camel-cxf bundle was reinstalled. In fact, the problem is
reproducible by reinstalling just the camel-cxf feature.
{code}
karaf@root()> feature:repo-add camel 2.16.1
Adding feature url mvn:org.apache.camel.karaf/apache-camel/2.16.1/xml/features
karaf@root()> feature:install camel-cxf
karaf@root()> feature:uninstall camel-cxf
karaf@root()> feature:install camel-cxf
karaf@root()>
{code}
was (Author: ralfsteppacher):
[~njiang], yes. In fact, the problem is reproducible by re-installing just the
camel-cxf feature.
{code}
karaf@root()> feature:repo-add camel 2.16.1
Adding feature url mvn:org.apache.camel.karaf/apache-camel/2.16.1/xml/features
karaf@root()> feature:install camel-cxf
karaf@root()> feature:uninstall camel-cxf
karaf@root()> feature:install camel-cxf
karaf@root()>
{code}
> Re-installing bundle using camel-cxf throws
> javax.management.InstanceAlreadyExistsException
> ---
>
> Key: CAMEL-9502
> URL: https://issues.apache.org/jira/browse/CAMEL-9502
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf, karaf
>Affects Versions: 2.16.1
> Environment: Karaf 4.0.3
>Reporter: Ralf Steppacher
>Priority: Minor
>
> Re-installing a bundle (in my case via a feature) that uses camel-cxf throws
> 3 instances of {{javax.management.InstanceAlreadyExistsException}}:
> {noformat}
> 2016-01-12 09:57:15,974 | WARN | pache.cxf.osgi]) | MBeanContainer
> | 222 - org.eclipse.jetty.util - 9.2.10.v20150310 | | bean:
> org.eclipse.jetty.server.session.HashSessionIdManager@398c8e55
> javax.management.InstanceAlreadyExistsException:
> org.eclipse.jetty.server.session:type=hashsessionidmanager,id=0
> at
> com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)[:1.8.0_40]
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)[:1.8.0_40]
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)[:1.8.0_40]
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)[:1.8.0_40]
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)[:1.8.0_40]
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)[:1.8.0_40]
> at
> org.eclipse.jetty.jmx.MBeanContainer.beanAdded(MBeanContainer.java:209)[214:org.eclipse.jetty.jmx:9.2.10.v20150310]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:264)[222:org.eclipse.jetty.util:9.2.10.v20150310]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:228)[222:org.eclipse.jetty.util:9.2.10.v20150310]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.updateBean(ContainerLifeCycle.java:777)[222:org.eclipse.jetty.util:9.2.10.v20150310]
> at
> org.eclipse.jetty.server.Server.setSessionIdManager(Server.java:578)[219:org.eclipse.jetty.server:9.2.10.v20150310]
> at
> org.eclipse.jetty.server.session.AbstractSessionManager.doStart(AbstractSessionManager.java:247)[219:org.eclipse.jetty.server:9.2.10.v20150310]
> at
> org.eclipse.jetty.server.session.HashSessionManager.doStart(HashSessionManager.java:153)[219:org.eclipse.jetty.server:9.2.10.v20150310]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)[222:org.eclipse.jetty.util:9.2.10.v20150310]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)[222:org.eclipse.jetty.util:9.2.10.v20150310]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)[222:org.eclipse.jetty.util:9.2.10.v20150310]
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)[219:org.eclipse.jetty.server:9.2.10.v20150310]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.doStart(ScopedHandler.java:120)[219:org.eclipse.jetty.server:9.2.10.v20150310]
> at
> org.eclipse.jetty.server.session.SessionHandler.doStart(SessionHandler.java:116)[219:org.eclipse.jetty.server:9.2.10.v20150310]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)[222:org.eclipse.jetty.util:9.2.10.v20150310]
> at
>
[jira] [Created] (CAMEL-9502) Re-installing bundle using camel-cxf throws javax.management.InstanceAlreadyExistsException
Ralf Steppacher created CAMEL-9502:
--
Summary: Re-installing bundle using camel-cxf throws
javax.management.InstanceAlreadyExistsException
Key: CAMEL-9502
URL: https://issues.apache.org/jira/browse/CAMEL-9502
Project: Camel
Issue Type: Bug
Components: camel-cxf, karaf
Affects Versions: 2.16.1
Environment: Karaf 4.0.3
Reporter: Ralf Steppacher
Priority: Minor
Re-installing a bundle (in my case via a feature) that uses camel-cxf throws 3
instances of {{javax.management.InstanceAlreadyExistsException}}:
{noformat}
2016-01-12 09:57:15,974 | WARN | pache.cxf.osgi]) | MBeanContainer
| 222 - org.eclipse.jetty.util - 9.2.10.v20150310 | | bean:
org.eclipse.jetty.server.session.HashSessionIdManager@398c8e55
javax.management.InstanceAlreadyExistsException:
org.eclipse.jetty.server.session:type=hashsessionidmanager,id=0
at
com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)[:1.8.0_40]
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)[:1.8.0_40]
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)[:1.8.0_40]
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)[:1.8.0_40]
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)[:1.8.0_40]
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)[:1.8.0_40]
at
org.eclipse.jetty.jmx.MBeanContainer.beanAdded(MBeanContainer.java:209)[214:org.eclipse.jetty.jmx:9.2.10.v20150310]
at
org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:264)[222:org.eclipse.jetty.util:9.2.10.v20150310]
at
org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:228)[222:org.eclipse.jetty.util:9.2.10.v20150310]
at
org.eclipse.jetty.util.component.ContainerLifeCycle.updateBean(ContainerLifeCycle.java:777)[222:org.eclipse.jetty.util:9.2.10.v20150310]
at
org.eclipse.jetty.server.Server.setSessionIdManager(Server.java:578)[219:org.eclipse.jetty.server:9.2.10.v20150310]
at
org.eclipse.jetty.server.session.AbstractSessionManager.doStart(AbstractSessionManager.java:247)[219:org.eclipse.jetty.server:9.2.10.v20150310]
at
org.eclipse.jetty.server.session.HashSessionManager.doStart(HashSessionManager.java:153)[219:org.eclipse.jetty.server:9.2.10.v20150310]
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)[222:org.eclipse.jetty.util:9.2.10.v20150310]
at
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)[222:org.eclipse.jetty.util:9.2.10.v20150310]
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)[222:org.eclipse.jetty.util:9.2.10.v20150310]
at
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)[219:org.eclipse.jetty.server:9.2.10.v20150310]
at
org.eclipse.jetty.server.handler.ScopedHandler.doStart(ScopedHandler.java:120)[219:org.eclipse.jetty.server:9.2.10.v20150310]
at
org.eclipse.jetty.server.session.SessionHandler.doStart(SessionHandler.java:116)[219:org.eclipse.jetty.server:9.2.10.v20150310]
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)[222:org.eclipse.jetty.util:9.2.10.v20150310]
at
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)[222:org.eclipse.jetty.util:9.2.10.v20150310]
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)[222:org.eclipse.jetty.util:9.2.10.v20150310]
at
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)[219:org.eclipse.jetty.server:9.2.10.v20150310]
at
org.eclipse.jetty.server.handler.ScopedHandler.doStart(ScopedHandler.java:120)[219:org.eclipse.jetty.server:9.2.10.v20150310]
at
org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:784)[219:org.eclipse.jetty.server:9.2.10.v20150310]
at
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:294)[220:org.eclipse.jetty.servlet:9.2.10.v20150310]
at
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)[219:org.eclipse.jetty.server:9.2.10.v20150310]
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doStart(HttpServiceContext.java:245)[235:org.ops4j.pax.web.pax-web-jetty:4.2.3]
at
[jira] [Commented] (CAMEL-9483) Deploying bundle with Camel routes packaged in KAR fails randomly
[
https://issues.apache.org/jira/browse/CAMEL-9483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15092213#comment-15092213
]
Ralf Steppacher commented on CAMEL-9483:
[~davsclaus], should this be a Karaf ticket instead of a Camel ticket?
> Deploying bundle with Camel routes packaged in KAR fails randomly
> -
>
> Key: CAMEL-9483
> URL: https://issues.apache.org/jira/browse/CAMEL-9483
> Project: Camel
> Issue Type: Bug
> Components: karaf
>Affects Versions: 2.16.1
> Environment: Karaf 4.0.3, blueprint deployment, JDK 1.8_40 on OSX El
> Capitan and JDK 1.8_65 on Centos 6.5
>Reporter: Ralf Steppacher
>Priority: Minor
> Attachments: data_format_lookup_failed.log,
> kar-build-0.0.1-SNAPSHOT.kar, registry_lookup_failed.log
>
>
> I am struggling with random deployment failures of bundles containing Camel
> routes, packaged in a KAR file. Deployment fails mostly because data formats
> cannot be found on the classpath or Camel component beans are not found in
> the registry.
> The attached sample KAR file contains one bundle with the following blueprint
> deployment descriptor:
> {code:xml}
> http://www.osgi.org/xmlns/blueprint/v1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xmlns:camel="http://camel.apache.org/schema/blueprint;
> xsi:schemaLocation="
> http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
> http://camel.apache.org/schema/blueprint
> http://camel.apache.org/schema/blueprint/camel-blueprint-2.16.1.xsd;>
>
>
>xmlns="http://camel.apache.org/schema/blueprint;>
>host="0.0.0.0" port="2016" bindingMode="json">
>
>
>produces="application/json">
>
>
>
>
>
>
>
>
> {code}
> The feature file of the KAR:
> {code:xml}
>
> http://karaf.apache.org/xmlns/features/v1.3.0; name="KAR
> deployment issue PoC">
>
> mvn:org.apache.camel.karaf/apache-camel/2.16.1/xml/features
>
> Sample REST bundle to demonstrate the deployment issue in
> Karaf 4
> dependency="false">camel-jackson
> dependency="false">camel-blueprint
> dependency="false">camel-netty4-http
>
> mvn:ch.rsteppac.kar-issue/poc-rest-service/0.0.1-SNAPSHOT
>
>
> {code}
> On my development machine (OSX) deploying the sample KAR file succeeds about
> 8 out of 10 times. It appears that the more features the KAR file contains
> the lower the probability of success. Our actual project KAR fails deployment
> about 9 out of 10 times.
> Not all Camel components are equally likely to cause the deployment failure.
> The most likely to trigger a failure are data formats, e.g., jackson-json or
> jaxb.
> Once the KAR file has deployed successfully, restarting Karaf will
> consistently deploy the bundles successfully. Until one deletes Karaf's data
> folder, then all bets are off again.
> Adding the feature.xml generated for the KAR with {{feature:repo-add}} and
> then deploying the features with {{feature:install}} virtually never fails.
> Stack traces for most frequent deployment failure of the sample KAR are
> attached to the ticket.
> h4. EDIT
> The issue is actually unrelated to fact that the features are deployed via a
> KAR file. While I can successfully install each feature individually on the
> command line, if I restart Karaf and the features are deployed from the
> {{$KARAF_HOME/data}} directory, the behavior is the same as described above.
> I encountered another class of errors: A bean declared in the blueprint
> context was not resolvable in the Camel context in the same file.
> Defining a start-level for my bundles (90) seems to be a workaround for the
> different issues described above.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9483) Deploying bundle with Camel routes packaged in KAR fails randomly
[
https://issues.apache.org/jira/browse/CAMEL-9483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-9483:
---
Description:
I am struggling with random deployment failures of bundles containing Camel
routes, packaged in a KAR file. Deployment fails mostly because data formats
cannot be found on the classpath or Camel component beans are not found in the
registry.
The attached sample KAR file contains one bundle with the following blueprint
deployment descriptor:
{code:xml}
http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xmlns:camel="http://camel.apache.org/schema/blueprint;
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://camel.apache.org/schema/blueprint
http://camel.apache.org/schema/blueprint/camel-blueprint-2.16.1.xsd;>
http://camel.apache.org/schema/blueprint;>
{code}
The feature file of the KAR:
{code:xml}
http://karaf.apache.org/xmlns/features/v1.3.0; name="KAR
deployment issue PoC">
mvn:org.apache.camel.karaf/apache-camel/2.16.1/xml/features
Sample REST bundle to demonstrate the deployment issue in
Karaf 4
camel-jackson
camel-blueprint
camel-netty4-http
mvn:ch.rsteppac.kar-issue/poc-rest-service/0.0.1-SNAPSHOT
{code}
On my development machine (OSX) deploying the sample KAR file succeeds about 8
out of 10 times. It appears that the more features the KAR file contains the
lower the probability of success. Our actual project KAR fails deployment about
9 out of 10 times.
Not all Camel components are equally likely to cause the deployment failure.
The most likely to trigger a failure are data formats, e.g., jackson-json or
jaxb.
Once the KAR file has deployed successfully, restarting Karaf will consistently
deploy the bundles successfully. Until one deletes Karaf's data folder, then
all bets are off again.
Adding the feature.xml generated for the KAR with {{feature:repo-add}} and then
deploying the features with {{feature:install}} virtually never fails.
Stack traces for most frequent deployment failure of the sample KAR are
attached to the ticket.
h4. EDIT
The issue is actually unrelated to fact that the features are deployed via a
KAR file. While I can successfully install each feature individually on the
command line, if I restart Karaf and the features are deployed from the
{{$KARAF_HOME/data}} directory, the behavior is the same as described above.
I encountered another class of errors: A bean declared in the blueprint context
was not resolvable in the Camel context in the same file.
Defining a start-level for my bundles (90) seems to be a workaround for the
different issues described above.
was:
I am struggling with random deployment failures of bundles containing Camel
routes, packaged in a KAR file. Deployment fails mostly because data formats
cannot be found on the classpath or Camel component beans are not found in the
registry.
The attached sample KAR file contains one bundle with the following blueprint
deployment descriptor:
{code:xml}
http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xmlns:camel="http://camel.apache.org/schema/blueprint;
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://camel.apache.org/schema/blueprint
http://camel.apache.org/schema/blueprint/camel-blueprint-2.16.1.xsd;>
http://camel.apache.org/schema/blueprint;>
{code}
The feature file of the KAR:
{code:xml}
http://karaf.apache.org/xmlns/features/v1.3.0; name="KAR
deployment issue PoC">
mvn:org.apache.camel.karaf/apache-camel/2.16.1/xml/features
Sample REST bundle to demonstrate the deployment issue in
Karaf 4
camel-jackson
camel-blueprint
camel-netty4-http
mvn:ch.rsteppac.kar-issue/poc-rest-service/0.0.1-SNAPSHOT
{code}
On my development machine (OSX) deploying the sample KAR file succeeds about 8
out of 10 times. It appears that the
[jira] [Created] (CAMEL-9483) Deploying bundle with Camel routes packaged in KAR fails randomly
Ralf Steppacher created CAMEL-9483:
--
Summary: Deploying bundle with Camel routes packaged in KAR fails
randomly
Key: CAMEL-9483
URL: https://issues.apache.org/jira/browse/CAMEL-9483
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.16.1
Environment: Karaf 4.0.3, blueprint deployment, JDK 1.8_40 on OSX El
Capitan and JDK 1.8_65 on Centos 6.5
Reporter: Ralf Steppacher
I am struggling with random deployment failures of bundles containing Camel
routes, packaged in a KAR file. Deployment fails mostly because data formats
cannot be found on the classpath or Camel component beans are not found in the
registry.
The attached sample KAR file contains one bundle with the following blueprint
deployment descriptor:
{code:xml}
http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xmlns:camel="http://camel.apache.org/schema/blueprint;
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://camel.apache.org/schema/blueprint
http://camel.apache.org/schema/blueprint/camel-blueprint-2.16.1.xsd;>
http://camel.apache.org/schema/blueprint;>
{code}
The feature file of the KAR:
{code:xml}
http://karaf.apache.org/xmlns/features/v1.3.0; name="KAR
deployment issue PoC">
mvn:org.apache.camel.karaf/apache-camel/2.16.1/xml/features
Sample REST bundle to demonstrate the deployment issue in
Karaf 4
camel-jackson
camel-blueprint
camel-netty4-http
mvn:ch.rsteppac.kar-issue/poc-rest-service/0.0.1-SNAPSHOT
{code}
On my development machine (OSX) deploying the sample KAR file succeeds about 8
out of 10 times. It appears that the more features the KAR file contains the
lower the probability of success. Our actual project KAR fails deployment about
9 out of 10 times.
Not all Camel components are equally likely to cause the deployment failure.
The most likely to trigger a failure are data formats, e.g., jackson-json or
jaxb.
Once the KAR file has deployed successfully, restarting Karaf will consistently
deploy the bundles successfully. Until one deletes Karaf's data folder, then
all bets are off again.
Adding the feature.xml generated for the KAR with {{feature:repo-add}} and then
deploying the features with {{feature:install}} virtually never fails.
Stack traces for most frequent deployment failure of the sample KAR are
attached to the ticket.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9483) Deploying bundle with Camel routes packaged in KAR fails randomly
[
https://issues.apache.org/jira/browse/CAMEL-9483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-9483:
---
Attachment: data_format_lookup_failed.log
> Deploying bundle with Camel routes packaged in KAR fails randomly
> -
>
> Key: CAMEL-9483
> URL: https://issues.apache.org/jira/browse/CAMEL-9483
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.16.1
> Environment: Karaf 4.0.3, blueprint deployment, JDK 1.8_40 on OSX El
> Capitan and JDK 1.8_65 on Centos 6.5
>Reporter: Ralf Steppacher
> Attachments: data_format_lookup_failed.log,
> kar-build-0.0.1-SNAPSHOT.kar, registry_lookup_failed.log
>
>
> I am struggling with random deployment failures of bundles containing Camel
> routes, packaged in a KAR file. Deployment fails mostly because data formats
> cannot be found on the classpath or Camel component beans are not found in
> the registry.
> The attached sample KAR file contains one bundle with the following blueprint
> deployment descriptor:
> {code:xml}
> http://www.osgi.org/xmlns/blueprint/v1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xmlns:camel="http://camel.apache.org/schema/blueprint;
> xsi:schemaLocation="
> http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
> http://camel.apache.org/schema/blueprint
> http://camel.apache.org/schema/blueprint/camel-blueprint-2.16.1.xsd;>
>
>
>xmlns="http://camel.apache.org/schema/blueprint;>
>host="0.0.0.0" port="2016" bindingMode="json">
>
>
>produces="application/json">
>
>
>
>
>
>
>
>
> {code}
> The feature file of the KAR:
> {code:xml}
>
> http://karaf.apache.org/xmlns/features/v1.3.0; name="KAR
> deployment issue PoC">
>
> mvn:org.apache.camel.karaf/apache-camel/2.16.1/xml/features
>
> Sample REST bundle to demonstrate the deployment issue in
> Karaf 4
> dependency="false">camel-jackson
> dependency="false">camel-blueprint
> dependency="false">camel-netty4-http
>
> mvn:ch.rsteppac.kar-issue/poc-rest-service/0.0.1-SNAPSHOT
>
>
> {code}
> On my development machine (OSX) deploying the sample KAR file succeeds about
> 8 out of 10 times. It appears that the more features the KAR file contains
> the lower the probability of success. Our actual project KAR fails deployment
> about 9 out of 10 times.
> Not all Camel components are equally likely to cause the deployment failure.
> The most likely to trigger a failure are data formats, e.g., jackson-json or
> jaxb.
> Once the KAR file has deployed successfully, restarting Karaf will
> consistently deploy the bundles successfully. Until one deletes Karaf's data
> folder, then all bets are off again.
> Adding the feature.xml generated for the KAR with {{feature:repo-add}} and
> then deploying the features with {{feature:install}} virtually never fails.
> Stack traces for most frequent deployment failure of the sample KAR are
> attached to the ticket.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9483) Deploying bundle with Camel routes packaged in KAR fails randomly
[
https://issues.apache.org/jira/browse/CAMEL-9483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-9483:
---
Attachment: kar-build-0.0.1-SNAPSHOT.kar
registry_lookup_failed.log
> Deploying bundle with Camel routes packaged in KAR fails randomly
> -
>
> Key: CAMEL-9483
> URL: https://issues.apache.org/jira/browse/CAMEL-9483
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.16.1
> Environment: Karaf 4.0.3, blueprint deployment, JDK 1.8_40 on OSX El
> Capitan and JDK 1.8_65 on Centos 6.5
>Reporter: Ralf Steppacher
> Attachments: kar-build-0.0.1-SNAPSHOT.kar, registry_lookup_failed.log
>
>
> I am struggling with random deployment failures of bundles containing Camel
> routes, packaged in a KAR file. Deployment fails mostly because data formats
> cannot be found on the classpath or Camel component beans are not found in
> the registry.
> The attached sample KAR file contains one bundle with the following blueprint
> deployment descriptor:
> {code:xml}
> http://www.osgi.org/xmlns/blueprint/v1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xmlns:camel="http://camel.apache.org/schema/blueprint;
> xsi:schemaLocation="
> http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
> http://camel.apache.org/schema/blueprint
> http://camel.apache.org/schema/blueprint/camel-blueprint-2.16.1.xsd;>
>
>
>xmlns="http://camel.apache.org/schema/blueprint;>
>host="0.0.0.0" port="2016" bindingMode="json">
>
>
>produces="application/json">
>
>
>
>
>
>
>
>
> {code}
> The feature file of the KAR:
> {code:xml}
>
> http://karaf.apache.org/xmlns/features/v1.3.0; name="KAR
> deployment issue PoC">
>
> mvn:org.apache.camel.karaf/apache-camel/2.16.1/xml/features
>
> Sample REST bundle to demonstrate the deployment issue in
> Karaf 4
> dependency="false">camel-jackson
> dependency="false">camel-blueprint
> dependency="false">camel-netty4-http
>
> mvn:ch.rsteppac.kar-issue/poc-rest-service/0.0.1-SNAPSHOT
>
>
> {code}
> On my development machine (OSX) deploying the sample KAR file succeeds about
> 8 out of 10 times. It appears that the more features the KAR file contains
> the lower the probability of success. Our actual project KAR fails deployment
> about 9 out of 10 times.
> Not all Camel components are equally likely to cause the deployment failure.
> The most likely to trigger a failure are data formats, e.g., jackson-json or
> jaxb.
> Once the KAR file has deployed successfully, restarting Karaf will
> consistently deploy the bundles successfully. Until one deletes Karaf's data
> folder, then all bets are off again.
> Adding the feature.xml generated for the KAR with {{feature:repo-add}} and
> then deploying the features with {{feature:install}} virtually never fails.
> Stack traces for most frequent deployment failure of the sample KAR are
> attached to the ticket.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9296) camel-blueprint-2.16.0.xsd is broken
Ralf Steppacher created CAMEL-9296:
--
Summary: camel-blueprint-2.16.0.xsd is broken
Key: CAMEL-9296
URL: https://issues.apache.org/jira/browse/CAMEL-9296
Project: Camel
Issue Type: Bug
Components: camel-blueprint
Affects Versions: 2.16.0
Reporter: Ralf Steppacher
The blueprint schema camel-blueprint-2.16.0.xsd breaks elements {{}}
and {{}}:
- {{}}: attributes {{uri}} and {{ref}} are not available
- {{}}: attribute {{ref}} is not available
Deploying a blueprint context in Karaf (4.0.2) fails with
{noformat}
Caused by: org.xml.sax.SAXParseException: cvc-complex-type.3.2.2: Attribute
'uri' is not allowed to appear in element 'enrich'.
at
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
Source)[:]
at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)[:]
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)[:]
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)[:]
[..]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-9070) java.lang.IllegalStateException: SENDING => HEADERS
[
https://issues.apache.org/jira/browse/CAMEL-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14993550#comment-14993550
]
Ralf Steppacher edited comment on CAMEL-9070 at 11/6/15 11:46 AM:
--
I tried to reproduce the issue with a project revision (Karaf 3.0.5, Camel
2.15.2) before I worked around the jetty issue. But could not reproduce the
exact error. Instead I get errors about timed out continuations. Apparently the
backend my proxy route talks to sporadically replies with a 503. This happens
after some hundred requests were placed by my load test (SoapUI).
However, if I use my current setup that replaces the jetty producer with the
http4 producer (Karaf 4.0.2, Camel 2.15.4) in my proxy route, my load test hums
along happily. 10'000 requests and not a hitch. Thus I am not sure the 503
really originates from the backend. I will have to request the logs...
was (Author: ralfsteppacher):
I tried to reproduce the issue with a project revision (Karaf 3.0.5, Camel
2.15.2) before I worked around the jetty issue. But could not reproduce the
exact error. Instead I get errors about timed out continuations. Apparently the
backend my proxy route talks to sporadically replies with a 503. This happens
after some hundred requests were placed by my load test (SoapUI).
However, if I use my current setup that replaces the jetty producer with the
http4 producer (Karaf 4.0.2, Camel 2.15.4) in my proxy route, my load test hums
along happily. 10'000 requests and not a hitch.
> java.lang.IllegalStateException: SENDING => HEADERS
> ---
>
> Key: CAMEL-9070
> URL: https://issues.apache.org/jira/browse/CAMEL-9070
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.15.2
> Environment: Karaf 3.0.3
>Reporter: Ralf Steppacher
>Priority: Minor
>
> When using the jetty component in a simple reverse proxy route deployed in
> {{Karaf 3.0.3}} I randomly receive the following Stacktrace:
> {noformat}
> 2015-08-14 10:44:15,931 | WARN | (0x64868d0a)-184 | HttpExchange
> | 117 - org.eclipse.jetty.aggregate.jetty-all-server -
> 8.1.15.v20140411 | | EXCEPTION
> ContentExchange@22d1b2c3=POST//ibb9931:8081/XDS3/repository/repo2#SENDING(1ms)->EXCEPTED(0ms)sent=388ms
> org.apache.camel.CamelExchangeException: JettyClient failed cause by: SENDING
> => HEADERS. Exchange[HttpMessage@0x4b022edc]. Caused by:
> [java.lang.IllegalStateException - SENDING => HEADERS]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8.doTaskCompleted(JettyContentExchange8.java:210)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8.onException(JettyContentExchange8.java:138)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8$1.onException(JettyContentExchange8.java:98)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:168)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at java.lang.Thread.run(Thread.java:745)[:1.7.0_60]
> Caused by: java.lang.IllegalStateException: SENDING => HEADERS
> at
> org.eclipse.jetty.client.HttpExchange.setStatus(HttpExchange.java:370)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.client.AbstractHttpConnection$Handler.startResponse(AbstractHttpConnection.java:297)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:489)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:135)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> ... 5 more
> {noformat}
> I have found (rather old) posts on the web that claim that the
[jira] [Commented] (CAMEL-9296) camel-blueprint-2.16.0.xsd is broken
[
https://issues.apache.org/jira/browse/CAMEL-9296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14993716#comment-14993716
]
Ralf Steppacher commented on CAMEL-9296:
Sorry. My bad.
> camel-blueprint-2.16.0.xsd is broken
>
>
> Key: CAMEL-9296
> URL: https://issues.apache.org/jira/browse/CAMEL-9296
> Project: Camel
> Issue Type: Bug
> Components: camel-blueprint
>Affects Versions: 2.16.0
>Reporter: Ralf Steppacher
>Assignee: Claus Ibsen
>
> The blueprint schema camel-blueprint-2.16.0.xsd breaks elements {{}}
> and {{}}:
> - {{}}: attributes {{uri}} and {{ref}} are not available
> - {{}}: attribute {{ref}} is not available
> Deploying a blueprint context in Karaf (4.0.2) fails with
> {noformat}
> Caused by: org.xml.sax.SAXParseException: cvc-complex-type.3.2.2: Attribute
> 'uri' is not allowed to appear in element 'enrich'.
> at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)[:]
> at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)[:]
> at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)[:]
> at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)[:]
> [..]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8876) Add an option for HttpProducer to ignore response body avoiding stream caching
[ https://issues.apache.org/jira/browse/CAMEL-8876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14993921#comment-14993921 ] Ralf Steppacher commented on CAMEL-8876: Could this be further enhanced to place the uncached response input stream in the exchange instead of discarding the response? Essentially implementing CAMEL-7638? > Add an option for HttpProducer to ignore response body avoiding stream caching > -- > > Key: CAMEL-8876 > URL: https://issues.apache.org/jira/browse/CAMEL-8876 > Project: Camel > Issue Type: Improvement > Components: camel-http, camel-http4 >Reporter: Willem Jiang >Assignee: Willem Jiang > Fix For: 2.16.0 > > > Sometime the user just want to check the response code and don't want to read > the response, we can enable this kind of feature with the option > "ignoreRequestBody". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-9070) java.lang.IllegalStateException: SENDING => HEADERS
[
https://issues.apache.org/jira/browse/CAMEL-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14993550#comment-14993550
]
Ralf Steppacher edited comment on CAMEL-9070 at 11/6/15 2:11 PM:
-
I tried to reproduce the issue with a project revision (Karaf 3.0.5, Camel
2.15.2) before I worked around the jetty issue. But could not reproduce the
exact error. Instead I get errors about timed out continuations. Apparently the
backend my proxy route talks to sporadically replies with a 503. This happens
after some hundred requests were placed by my load test (SoapUI).
However, if I use my current setup that replaces the jetty producer with the
http4 producer (Karaf 4.0.2, Camel 2.15.4) in my proxy route, my load test hums
along happily. 10'000 requests and not a hitch.
The server actually does have errors when using jetty as the producer in the
proxy route:
{noformat}
javax.servlet.ServletException: Error SOAPPOSTFailed:Read timed out
{noformat}
In the proxy logs I don't see the log statement from the second line of my
route:
{code:xml}
http://{{pep.host}}:{{pep.xds.b.registry.port}}/XDS3/registry?matchOnUriPrefix=truedisableStreamCache=trueenableMultipartFilter=false;
/>
{code}
I do get some application log statements from my proxy processors though. And
this at the last statement with the MDC correlation ID of the request:
{noformat}
2015-11-06 12:13:13,928 | WARN | (0x6bf9aa4d)-268 | CamelContinuationServlet
| 109 - org.apache.camel.camel-http - 2.15.2 |
ID-Ralfs-MacBook-Pro-local-63423-1446807879628-7-22745 | Cannot resume expired
continuation of exchangeId:
ID-Ralfs-MacBook-Pro-local-63423-1446807879628-7-22744
{noformat}
{{ID-Ralfs-MacBook-Pro-local-63423-1446807879628-7-22745}} is the MDC
correlation identifier.
was (Author: ralfsteppacher):
I tried to reproduce the issue with a project revision (Karaf 3.0.5, Camel
2.15.2) before I worked around the jetty issue. But could not reproduce the
exact error. Instead I get errors about timed out continuations. Apparently the
backend my proxy route talks to sporadically replies with a 503. This happens
after some hundred requests were placed by my load test (SoapUI).
However, if I use my current setup that replaces the jetty producer with the
http4 producer (Karaf 4.0.2, Camel 2.15.4) in my proxy route, my load test hums
along happily. 10'000 requests and not a hitch. Thus I am not sure the 503
really originates from the backend. I will have to request the logs...
> java.lang.IllegalStateException: SENDING => HEADERS
> ---
>
> Key: CAMEL-9070
> URL: https://issues.apache.org/jira/browse/CAMEL-9070
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.15.2
> Environment: Karaf 3.0.3
>Reporter: Ralf Steppacher
>Priority: Minor
>
> When using the jetty component in a simple reverse proxy route deployed in
> {{Karaf 3.0.3}} I randomly receive the following Stacktrace:
> {noformat}
> 2015-08-14 10:44:15,931 | WARN | (0x64868d0a)-184 | HttpExchange
> | 117 - org.eclipse.jetty.aggregate.jetty-all-server -
> 8.1.15.v20140411 | | EXCEPTION
> ContentExchange@22d1b2c3=POST//ibb9931:8081/XDS3/repository/repo2#SENDING(1ms)->EXCEPTED(0ms)sent=388ms
> org.apache.camel.CamelExchangeException: JettyClient failed cause by: SENDING
> => HEADERS. Exchange[HttpMessage@0x4b022edc]. Caused by:
> [java.lang.IllegalStateException - SENDING => HEADERS]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8.doTaskCompleted(JettyContentExchange8.java:210)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8.onException(JettyContentExchange8.java:138)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8$1.onException(JettyContentExchange8.java:98)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:168)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
[jira] [Comment Edited] (CAMEL-9070) java.lang.IllegalStateException: SENDING => HEADERS
[
https://issues.apache.org/jira/browse/CAMEL-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14993550#comment-14993550
]
Ralf Steppacher edited comment on CAMEL-9070 at 11/6/15 2:11 PM:
-
I tried to reproduce the issue with a project revision (Karaf 3.0.5, Camel
2.15.2) before I worked around the jetty issue. But could not reproduce the
exact error. Instead I get errors about timed out continuations. Apparently the
backend my proxy route talks to sporadically replies with a 500. This happens
after some hundred requests were placed by my load test (SoapUI).
However, if I use my current setup that replaces the jetty producer with the
http4 producer (Karaf 4.0.2, Camel 2.15.4) in my proxy route, my load test hums
along happily. 10'000 requests and not a hitch.
The server actually does have errors when using jetty as the producer in the
proxy route:
{noformat}
javax.servlet.ServletException: Error SOAPPOSTFailed:Read timed out
{noformat}
In the proxy logs I don't see the log statement from the second line of my
route:
{code:xml}
http://{{pep.host}}:{{pep.xds.b.registry.port}}/XDS3/registry?matchOnUriPrefix=truedisableStreamCache=trueenableMultipartFilter=false;
/>
{code}
I do get some application log statements from my proxy processors though. And
this at the last statement with the MDC correlation ID of the request:
{noformat}
2015-11-06 12:13:13,928 | WARN | (0x6bf9aa4d)-268 | CamelContinuationServlet
| 109 - org.apache.camel.camel-http - 2.15.2 |
ID-Ralfs-MacBook-Pro-local-63423-1446807879628-7-22745 | Cannot resume expired
continuation of exchangeId:
ID-Ralfs-MacBook-Pro-local-63423-1446807879628-7-22744
{noformat}
{{ID-Ralfs-MacBook-Pro-local-63423-1446807879628-7-22745}} is the MDC
correlation identifier.
was (Author: ralfsteppacher):
I tried to reproduce the issue with a project revision (Karaf 3.0.5, Camel
2.15.2) before I worked around the jetty issue. But could not reproduce the
exact error. Instead I get errors about timed out continuations. Apparently the
backend my proxy route talks to sporadically replies with a 503. This happens
after some hundred requests were placed by my load test (SoapUI).
However, if I use my current setup that replaces the jetty producer with the
http4 producer (Karaf 4.0.2, Camel 2.15.4) in my proxy route, my load test hums
along happily. 10'000 requests and not a hitch.
The server actually does have errors when using jetty as the producer in the
proxy route:
{noformat}
javax.servlet.ServletException: Error SOAPPOSTFailed:Read timed out
{noformat}
In the proxy logs I don't see the log statement from the second line of my
route:
{code:xml}
http://{{pep.host}}:{{pep.xds.b.registry.port}}/XDS3/registry?matchOnUriPrefix=truedisableStreamCache=trueenableMultipartFilter=false;
/>
{code}
I do get some application log statements from my proxy processors though. And
this at the last statement with the MDC correlation ID of the request:
{noformat}
2015-11-06 12:13:13,928 | WARN | (0x6bf9aa4d)-268 | CamelContinuationServlet
| 109 - org.apache.camel.camel-http - 2.15.2 |
ID-Ralfs-MacBook-Pro-local-63423-1446807879628-7-22745 | Cannot resume expired
continuation of exchangeId:
ID-Ralfs-MacBook-Pro-local-63423-1446807879628-7-22744
{noformat}
{{ID-Ralfs-MacBook-Pro-local-63423-1446807879628-7-22745}} is the MDC
correlation identifier.
> java.lang.IllegalStateException: SENDING => HEADERS
> ---
>
> Key: CAMEL-9070
> URL: https://issues.apache.org/jira/browse/CAMEL-9070
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.15.2
> Environment: Karaf 3.0.3
>Reporter: Ralf Steppacher
>Priority: Minor
>
> When using the jetty component in a simple reverse proxy route deployed in
> {{Karaf 3.0.3}} I randomly receive the following Stacktrace:
> {noformat}
> 2015-08-14 10:44:15,931 | WARN | (0x64868d0a)-184 | HttpExchange
> | 117 - org.eclipse.jetty.aggregate.jetty-all-server -
> 8.1.15.v20140411 | | EXCEPTION
> ContentExchange@22d1b2c3=POST//ibb9931:8081/XDS3/repository/repo2#SENDING(1ms)->EXCEPTED(0ms)sent=388ms
> org.apache.camel.CamelExchangeException: JettyClient failed cause by: SENDING
> => HEADERS. Exchange[HttpMessage@0x4b022edc]. Caused by:
> [java.lang.IllegalStateException - SENDING => HEADERS]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8.doTaskCompleted(JettyContentExchange8.java:210)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8.onException(JettyContentExchange8.java:138)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
>
[jira] [Commented] (CAMEL-9070) java.lang.IllegalStateException: SENDING => HEADERS
[
https://issues.apache.org/jira/browse/CAMEL-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14993550#comment-14993550
]
Ralf Steppacher commented on CAMEL-9070:
I tried to reproduce the issue with a project revision (Karaf 3.0.5, Camel
2.15.2) before I worked around the jetty issue. But could not reproduce the
exact error. Instead I get errors about timed out continuations. Apparently the
backend my proxy route talks to sporadically replies with a 503. This happens
after some hundred requests were placed by my load test (SoapUI).
However, if I use my current setup that replaces the jetty producer with the
http4 producer (Karaf 4.0.2, Camel 2.15.4) in my proxy route, my load test hums
along happily. 10'000 requests and not a hitch.
> java.lang.IllegalStateException: SENDING => HEADERS
> ---
>
> Key: CAMEL-9070
> URL: https://issues.apache.org/jira/browse/CAMEL-9070
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.15.2
> Environment: Karaf 3.0.3
>Reporter: Ralf Steppacher
>Priority: Minor
>
> When using the jetty component in a simple reverse proxy route deployed in
> {{Karaf 3.0.3}} I randomly receive the following Stacktrace:
> {noformat}
> 2015-08-14 10:44:15,931 | WARN | (0x64868d0a)-184 | HttpExchange
> | 117 - org.eclipse.jetty.aggregate.jetty-all-server -
> 8.1.15.v20140411 | | EXCEPTION
> ContentExchange@22d1b2c3=POST//ibb9931:8081/XDS3/repository/repo2#SENDING(1ms)->EXCEPTED(0ms)sent=388ms
> org.apache.camel.CamelExchangeException: JettyClient failed cause by: SENDING
> => HEADERS. Exchange[HttpMessage@0x4b022edc]. Caused by:
> [java.lang.IllegalStateException - SENDING => HEADERS]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8.doTaskCompleted(JettyContentExchange8.java:210)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8.onException(JettyContentExchange8.java:138)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8$1.onException(JettyContentExchange8.java:98)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:168)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at java.lang.Thread.run(Thread.java:745)[:1.7.0_60]
> Caused by: java.lang.IllegalStateException: SENDING => HEADERS
> at
> org.eclipse.jetty.client.HttpExchange.setStatus(HttpExchange.java:370)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.client.AbstractHttpConnection$Handler.startResponse(AbstractHttpConnection.java:297)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:489)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:135)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> ... 5 more
> {noformat}
> I have found (rather old) posts on the web that claim that the behavior is
> related to message size. I am {{POST}}-ing about 6kb of SOAP XML with the
> following headers:
> {noformat}
> POST http://localhost:8080/XDS3/repository/repo2 HTTP/1.1
> Accept-Encoding: gzip,deflate
> Content-Type: multipart/related; type="application/xop+xml";
> start=""; start-info="application/soap+xml";
> action="urn:ihe:iti:2007:RetrieveDocumentSet";
> boundary="=_Part_139_1471895036.1439218177147"
> MIME-Version: 1.0
> Content-Length: 6858
> Host: localhost:8080
> Connection: Keep-Alive
> User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
> {noformat}
> The issue pops up at random but not evenly distributed. It either almost
> always happens or hardly ever. Re-installing my bundle or restarting Karaf
> usually
[jira] [Commented] (CAMEL-9070) java.lang.IllegalStateException: SENDING => HEADERS
[
https://issues.apache.org/jira/browse/CAMEL-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14875692#comment-14875692
]
Ralf Steppacher commented on CAMEL-9070:
[~davsclaus], no I have not tried outside Karaf and a different jetty (client)
version. As I am in a blueprint-only environment that would require some
effort.
I also overlooked the buffer parameters. I will give that a shot and report
back.
> java.lang.IllegalStateException: SENDING => HEADERS
> ---
>
> Key: CAMEL-9070
> URL: https://issues.apache.org/jira/browse/CAMEL-9070
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.15.2
> Environment: Karaf 3.0.3
>Reporter: Ralf Steppacher
>
> When using the jetty component in a simple reverse proxy route deployed in
> {{Karaf 3.0.3}} I randomly receive the following Stacktrace:
> {noformat}
> 2015-08-14 10:44:15,931 | WARN | (0x64868d0a)-184 | HttpExchange
> | 117 - org.eclipse.jetty.aggregate.jetty-all-server -
> 8.1.15.v20140411 | | EXCEPTION
> ContentExchange@22d1b2c3=POST//ibb9931:8081/XDS3/repository/repo2#SENDING(1ms)->EXCEPTED(0ms)sent=388ms
> org.apache.camel.CamelExchangeException: JettyClient failed cause by: SENDING
> => HEADERS. Exchange[HttpMessage@0x4b022edc]. Caused by:
> [java.lang.IllegalStateException - SENDING => HEADERS]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8.doTaskCompleted(JettyContentExchange8.java:210)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8.onException(JettyContentExchange8.java:138)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8$1.onException(JettyContentExchange8.java:98)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:168)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at java.lang.Thread.run(Thread.java:745)[:1.7.0_60]
> Caused by: java.lang.IllegalStateException: SENDING => HEADERS
> at
> org.eclipse.jetty.client.HttpExchange.setStatus(HttpExchange.java:370)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.client.AbstractHttpConnection$Handler.startResponse(AbstractHttpConnection.java:297)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:489)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:135)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> ... 5 more
> {noformat}
> I have found (rather old) posts on the web that claim that the behavior is
> related to message size. I am {{POST}}-ing about 6kb of SOAP XML with the
> following headers:
> {noformat}
> POST http://localhost:8080/XDS3/repository/repo2 HTTP/1.1
> Accept-Encoding: gzip,deflate
> Content-Type: multipart/related; type="application/xop+xml";
> start=""; start-info="application/soap+xml";
> action="urn:ihe:iti:2007:RetrieveDocumentSet";
> boundary="=_Part_139_1471895036.1439218177147"
> MIME-Version: 1.0
> Content-Length: 6858
> Host: localhost:8080
> Connection: Keep-Alive
> User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
> {noformat}
> The issue pops up at random but not evenly distributed. It either almost
> always happens or hardly ever. Re-installing my bundle or restarting Karaf
> usually triggers a switch between the two scenarios on some machines. On
> others the error is persistent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9070) java.lang.IllegalStateException: SENDING = HEADERS
[
https://issues.apache.org/jira/browse/CAMEL-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-9070:
---
Description:
When using the jetty component in a simple reverse proxy route deployed in
{{Karaf 3.0.3}} I randomly receive the following Stacktrace:
{noformat}
2015-08-14 10:44:15,931 | WARN | (0x64868d0a)-184 | HttpExchange
| 117 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.15.v20140411 |
| EXCEPTION
ContentExchange@22d1b2c3=POST//ibb9931:8081/XDS3/repository/repo2#SENDING(1ms)-EXCEPTED(0ms)sent=388ms
org.apache.camel.CamelExchangeException: JettyClient failed cause by: SENDING
= HEADERS. Exchange[HttpMessage@0x4b022edc]. Caused by:
[java.lang.IllegalStateException - SENDING = HEADERS]
at
org.apache.camel.component.jetty8.JettyContentExchange8.doTaskCompleted(JettyContentExchange8.java:210)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.apache.camel.component.jetty8.JettyContentExchange8.onException(JettyContentExchange8.java:138)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.apache.camel.component.jetty8.JettyContentExchange8$1.onException(JettyContentExchange8.java:98)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:168)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at java.lang.Thread.run(Thread.java:745)[:1.7.0_60]
Caused by: java.lang.IllegalStateException: SENDING = HEADERS
at
org.eclipse.jetty.client.HttpExchange.setStatus(HttpExchange.java:370)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.client.AbstractHttpConnection$Handler.startResponse(AbstractHttpConnection.java:297)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:489)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:135)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
... 5 more
{noformat}
I have found (rather old) posts on the web that claim that the behavior is
related to message size. I am {{POST}}-ing about 6kb of SOAP XML with the
following headers:
{noformat}
POST http://localhost:8080/XDS3/repository/repo2 HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: multipart/related; type=application/xop+xml;
start=rootp...@soapui.org; start-info=application/soap+xml;
action=urn:ihe:iti:2007:RetrieveDocumentSet;
boundary==_Part_139_1471895036.1439218177147
MIME-Version: 1.0
Content-Length: 6858
Host: localhost:8080
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
{noformat}
The issue pops up at random but not evenly distributed. It either almost always
happens or hardly ever. Re-installing my bundle or restarting Karaf usually
triggers a switch between the two scenarios on some machines. On others the
error is persistent.
was:
When using the jetty component in a simple reverse proxy route deployed in
{{Karaf 3.0.3}} I randomly receive the following Stacktrace:
{noformat}
2015-08-14 10:44:15,931 | WARN | (0x64868d0a)-184 | HttpExchange
| 117 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.15.v20140411 |
| EXCEPTION
ContentExchange@22d1b2c3=POST//ibb9931:8081/XDS3/repository/repo2#SENDING(1ms)-EXCEPTED(0ms)sent=388ms
org.apache.camel.CamelExchangeException: JettyClient failed cause by: SENDING
= HEADERS. Exchange[HttpMessage@0x4b022edc]. Caused by:
[java.lang.IllegalStateException - SENDING = HEADERS]
at
org.apache.camel.component.jetty8.JettyContentExchange8.doTaskCompleted(JettyContentExchange8.java:210)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.apache.camel.component.jetty8.JettyContentExchange8.onException(JettyContentExchange8.java:138)[150:org.apache.camel.camel-jetty8:2.15.2]
at
[jira] [Updated] (CAMEL-9070) java.lang.IllegalStateException: SENDING = HEADERS
[
https://issues.apache.org/jira/browse/CAMEL-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-9070:
---
Description:
When using the jetty component in a simple reverse proxy route deployed in
{{Karaf 3.0.3}} I randomly receive the following Stacktrace:
{noformat}
2015-08-14 10:44:15,931 | WARN | (0x64868d0a)-184 | HttpExchange
| 117 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.15.v20140411 |
| EXCEPTION
ContentExchange@22d1b2c3=POST//ibb9931:8081/XDS3/repository/repo2#SENDING(1ms)-EXCEPTED(0ms)sent=388ms
org.apache.camel.CamelExchangeException: JettyClient failed cause by: SENDING
= HEADERS. Exchange[HttpMessage@0x4b022edc]. Caused by:
[java.lang.IllegalStateException - SENDING = HEADERS]
at
org.apache.camel.component.jetty8.JettyContentExchange8.doTaskCompleted(JettyContentExchange8.java:210)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.apache.camel.component.jetty8.JettyContentExchange8.onException(JettyContentExchange8.java:138)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.apache.camel.component.jetty8.JettyContentExchange8$1.onException(JettyContentExchange8.java:98)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:168)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at java.lang.Thread.run(Thread.java:745)[:1.7.0_60]
Caused by: java.lang.IllegalStateException: SENDING = HEADERS
at
org.eclipse.jetty.client.HttpExchange.setStatus(HttpExchange.java:370)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.client.AbstractHttpConnection$Handler.startResponse(AbstractHttpConnection.java:297)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:489)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:135)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
... 5 more
{noformat}
I have found (rather old) posts on the web that claim that the behavior is
related to message size. I am {{POST}}-ing about 6kb of SOAP XML with the
following headers:
{noformat}
POST http://localhost:8080/XDS3/repository/repo2 HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: multipart/related; type=application/xop+xml;
start=rootp...@soapui.org; start-info=application/soap+xml;
action=urn:ihe:iti:2007:RetrieveDocumentSet;
boundary==_Part_139_1471895036.1439218177147
MIME-Version: 1.0
Content-Length: 6858
Host: localhost:8080
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
{noformat}
The issue pops up at random but not evenly distributed. It either almost always
happens or hardly ever. Re-installing my bundle or restarting Karaf usually
triggers a switch between the two scenarios.
was:
When using the jetty component in a simple reverse proxy route deployed in
{{Karaf 3.0.3}} I randomly receive the following Stacktrace:
{noformat}
org.apache.camel.CamelExchangeException: JettyClient failed cause by: SENDING
= HEADERS. Exchange[HttpMessage@0x4b022edc]. Caused by:
[java.lang.IllegalStateException - SENDING = HEADERS]
at
org.apache.camel.component.jetty8.JettyContentExchange8.doTaskCompleted(JettyContentExchange8.java:210)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.apache.camel.component.jetty8.JettyContentExchange8.onException(JettyContentExchange8.java:138)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.apache.camel.component.jetty8.JettyContentExchange8$1.onException(JettyContentExchange8.java:98)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:168)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
[jira] [Updated] (CAMEL-9070) java.lang.IllegalStateException: SENDING = HEADERS
[
https://issues.apache.org/jira/browse/CAMEL-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-9070:
---
Priority: Critical (was: Major)
java.lang.IllegalStateException: SENDING = HEADERS
---
Key: CAMEL-9070
URL: https://issues.apache.org/jira/browse/CAMEL-9070
Project: Camel
Issue Type: Bug
Components: camel-jetty
Affects Versions: 2.15.2
Environment: Karaf 3.0.3
Reporter: Ralf Steppacher
Priority: Critical
When using the jetty component in a simple reverse proxy route deployed in
{{Karaf 3.0.3}} I randomly receive the following Stacktrace:
{noformat}
2015-08-14 10:44:15,931 | WARN | (0x64868d0a)-184 | HttpExchange
| 117 - org.eclipse.jetty.aggregate.jetty-all-server -
8.1.15.v20140411 | | EXCEPTION
ContentExchange@22d1b2c3=POST//ibb9931:8081/XDS3/repository/repo2#SENDING(1ms)-EXCEPTED(0ms)sent=388ms
org.apache.camel.CamelExchangeException: JettyClient failed cause by: SENDING
= HEADERS. Exchange[HttpMessage@0x4b022edc]. Caused by:
[java.lang.IllegalStateException - SENDING = HEADERS]
at
org.apache.camel.component.jetty8.JettyContentExchange8.doTaskCompleted(JettyContentExchange8.java:210)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.apache.camel.component.jetty8.JettyContentExchange8.onException(JettyContentExchange8.java:138)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.apache.camel.component.jetty8.JettyContentExchange8$1.onException(JettyContentExchange8.java:98)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:168)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at java.lang.Thread.run(Thread.java:745)[:1.7.0_60]
Caused by: java.lang.IllegalStateException: SENDING = HEADERS
at
org.eclipse.jetty.client.HttpExchange.setStatus(HttpExchange.java:370)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.client.AbstractHttpConnection$Handler.startResponse(AbstractHttpConnection.java:297)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:489)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:135)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
... 5 more
{noformat}
I have found (rather old) posts on the web that claim that the behavior is
related to message size. I am {{POST}}-ing about 6kb of SOAP XML with the
following headers:
{noformat}
POST http://localhost:8080/XDS3/repository/repo2 HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: multipart/related; type=application/xop+xml;
start=rootp...@soapui.org; start-info=application/soap+xml;
action=urn:ihe:iti:2007:RetrieveDocumentSet;
boundary==_Part_139_1471895036.1439218177147
MIME-Version: 1.0
Content-Length: 6858
Host: localhost:8080
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
{noformat}
The issue pops up at random but not evenly distributed. It either almost
always happens or hardly ever. Re-installing my bundle or restarting Karaf
usually triggers a switch between the two scenarios.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9070) java.lang.IllegalStateException: SENDING = HEADERS
[
https://issues.apache.org/jira/browse/CAMEL-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-9070:
---
Environment: Karaf 3.0.3
java.lang.IllegalStateException: SENDING = HEADERS
---
Key: CAMEL-9070
URL: https://issues.apache.org/jira/browse/CAMEL-9070
Project: Camel
Issue Type: Bug
Components: camel-jetty
Affects Versions: 2.15.2
Environment: Karaf 3.0.3
Reporter: Ralf Steppacher
When using the jetty component in a simple reverse proxy route deployed in
{{Karaf 3.0.3}} I randomly receive the following Stacktrace:
{noformat}
org.apache.camel.CamelExchangeException: JettyClient failed cause by: SENDING
= HEADERS. Exchange[HttpMessage@0x4b022edc]. Caused by:
[java.lang.IllegalStateException - SENDING = HEADERS]
at
org.apache.camel.component.jetty8.JettyContentExchange8.doTaskCompleted(JettyContentExchange8.java:210)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.apache.camel.component.jetty8.JettyContentExchange8.onException(JettyContentExchange8.java:138)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.apache.camel.component.jetty8.JettyContentExchange8$1.onException(JettyContentExchange8.java:98)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:168)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at java.lang.Thread.run(Thread.java:745)[:1.7.0_60]
Caused by: java.lang.IllegalStateException: SENDING = HEADERS
at
org.eclipse.jetty.client.HttpExchange.setStatus(HttpExchange.java:370)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.client.AbstractHttpConnection$Handler.startResponse(AbstractHttpConnection.java:297)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:489)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:135)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
... 5 more
{noformat}
I have found (rather old) posts on the web that claim that the behavior is
related to message size. I am {{POST}}-ing about 6kb of SOAP XML with the
following headers:
{noformat}
POST http://localhost:8080/XDS3/repository/repo2 HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: multipart/related; type=application/xop+xml;
start=rootp...@soapui.org; start-info=application/soap+xml;
action=urn:ihe:iti:2007:RetrieveDocumentSet;
boundary==_Part_139_1471895036.1439218177147
MIME-Version: 1.0
Content-Length: 6858
Host: localhost:8080
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
{noformat}
The issue pops up at random but not evenly distributed. It either almost
always happens or hardly ever. Re-installing my bundle or restarting Karaf
usually triggers a switch between the two scenarios.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9070) java.lang.IllegalStateException: SENDING = HEADERS
Ralf Steppacher created CAMEL-9070:
--
Summary: java.lang.IllegalStateException: SENDING = HEADERS
Key: CAMEL-9070
URL: https://issues.apache.org/jira/browse/CAMEL-9070
Project: Camel
Issue Type: Bug
Components: camel-jetty
Affects Versions: 2.15.2
Reporter: Ralf Steppacher
When using the jetty component in a simple reverse proxy route deployed in
{{Karaf 3.0.3}} I randomly receive the following Stacktrace:
{noformat}
org.apache.camel.CamelExchangeException: JettyClient failed cause by: SENDING
= HEADERS. Exchange[HttpMessage@0x4b022edc]. Caused by:
[java.lang.IllegalStateException - SENDING = HEADERS]
at
org.apache.camel.component.jetty8.JettyContentExchange8.doTaskCompleted(JettyContentExchange8.java:210)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.apache.camel.component.jetty8.JettyContentExchange8.onException(JettyContentExchange8.java:138)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.apache.camel.component.jetty8.JettyContentExchange8$1.onException(JettyContentExchange8.java:98)[150:org.apache.camel.camel-jetty8:2.15.2]
at
org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:168)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at java.lang.Thread.run(Thread.java:745)[:1.7.0_60]
Caused by: java.lang.IllegalStateException: SENDING = HEADERS
at
org.eclipse.jetty.client.HttpExchange.setStatus(HttpExchange.java:370)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.client.AbstractHttpConnection$Handler.startResponse(AbstractHttpConnection.java:297)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:489)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at
org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:135)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
... 5 more
{noformat}
I have found (rather old) posts on the web that claim that the behavior is
related to message size. I am {{POST}}-ing about 6kb of SOAP XML with the
following headers:
{noformat}
POST http://localhost:8080/XDS3/repository/repo2 HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: multipart/related; type=application/xop+xml;
start=rootp...@soapui.org; start-info=application/soap+xml;
action=urn:ihe:iti:2007:RetrieveDocumentSet;
boundary==_Part_139_1471895036.1439218177147
MIME-Version: 1.0
Content-Length: 6858
Host: localhost:8080
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
{noformat}
The issue pops up at random but not evenly distributed. It either almost always
happens or hardly ever. Re-installing my bundle or restarting Karaf usually
triggers a switch between the two scenarios.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9040) netty4-http - LEAK: ByteBuf.release() was not called before it's garbage-collected
[
https://issues.apache.org/jira/browse/CAMEL-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-9040:
---
Description:
In a reverse-proxy with multiple routes that utilize the {{netty4-http}}
component both as the consumer and producer I am receiving the following error:
{noformat}
2015-07-30 11:52:34,416 | ERROR | yServerTCPWorker | ResourceLeakDetector
| 97 - io.netty.common - 4.0.27.Final | | LEAK: ByteBuf.release() was
not called before it's garbage-collected. See
http://netty.io/wiki/reference-counted-objects.html for more information.
{noformat}
Setting the Netty leak reporting to paranoid
({{-Dio.netty.leakDetectionLevel=paranoid}}) yields an error for almost every
request (it probably is 1:1).
The stacktraces come in two variants. Variant 1 is far less frequent than
variant 2.
Variant 1:
{noformat}
Recent access records: 0
Created at:
io.netty.buffer.CompositeByteBuf.init(CompositeByteBuf.java:60)
io.netty.buffer.Unpooled.compositeBuffer(Unpooled.java:353)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:153)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:54)
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:242)
io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:147)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
java.lang.Thread.run(Thread.java:745)
{noformat}
Variant 2:
{noformat}
Recent access records: 5
#5:
io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:223)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:684)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:40)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:677)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1493)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:40)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
java.io.BufferedInputStream.read(BufferedInputStream.java:334)
org.bouncycastle.util.io.TeeInputStream.read(Unknown Source)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:250)
com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:133)
com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:545)
com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:605)
com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:628)
com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:331)
ch.vivates.pep.stream.ResponseStatusFilter.filter(ResponseStatusFilter.java:41)
ch.vivates.pep.stream.BaseStreamFilter.run(BaseStreamFilter.java:141)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
java.util.concurrent.FutureTask.run(FutureTask.java:262)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:745)
#4:
io.netty.buffer.AdvancedLeakAwareByteBuf.release(AdvancedLeakAwareByteBuf.java:45)
io.netty.handler.codec.http.DefaultHttpContent.release(DefaultHttpContent.java:72)
io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:59)
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:91)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
[jira] [Updated] (CAMEL-9040) netty4-http - LEAK: ByteBuf.release() was not called before it's garbage-collected
[
https://issues.apache.org/jira/browse/CAMEL-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-9040:
---
Environment: Karaf 3.0.3
netty4-http - LEAK: ByteBuf.release() was not called before it's
garbage-collected
--
Key: CAMEL-9040
URL: https://issues.apache.org/jira/browse/CAMEL-9040
Project: Camel
Issue Type: Bug
Components: camel-netty4-http
Affects Versions: 2.15.1, 2.15.2
Environment: Karaf 3.0.3
Reporter: Ralf Steppacher
Priority: Critical
In a reverse-proxy with multiple routes that utilize the netty4-http
component both as the consumer and producer I am receiving the following
error:
{noformat}
2015-07-30 11:52:34,416 | ERROR | yServerTCPWorker | ResourceLeakDetector
| 97 - io.netty.common - 4.0.27.Final | | LEAK: ByteBuf.release()
was not called before it's garbage-collected. See
http://netty.io/wiki/reference-counted-objects.html for more information.
{noformat}
Setting the Netty leak reporting to paranoid
({{-Dio.netty.leakDetectionLevel=paranoid}}) yields an error for almost every
request (it probably is 1:1).
The stacktraces come in two variants. Variant 1 is far less frequent than
variant 2.
Variant 1:
{noformat}
Recent access records: 0
Created at:
io.netty.buffer.CompositeByteBuf.init(CompositeByteBuf.java:60)
io.netty.buffer.Unpooled.compositeBuffer(Unpooled.java:353)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:153)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:54)
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:242)
io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:147)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
java.lang.Thread.run(Thread.java:745)
{noformat}
Variant 2:
{noformat}
Recent access records: 5
#5:
io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:223)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:684)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:40)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:677)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1493)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:40)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
java.io.BufferedInputStream.read(BufferedInputStream.java:334)
org.bouncycastle.util.io.TeeInputStream.read(Unknown Source)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:250)
com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:133)
com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:545)
com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:605)
com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:628)
com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:331)
ch.vivates.pep.stream.ResponseStatusFilter.filter(ResponseStatusFilter.java:41)
ch.vivates.pep.stream.BaseStreamFilter.run(BaseStreamFilter.java:141)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
java.util.concurrent.FutureTask.run(FutureTask.java:262)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[jira] [Updated] (CAMEL-9040) netty4-http - LEAK: ByteBuf.release() was not called before it's garbage-collected
[
https://issues.apache.org/jira/browse/CAMEL-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-9040:
---
Affects Version/s: 2.15.1
netty4-http - LEAK: ByteBuf.release() was not called before it's
garbage-collected
--
Key: CAMEL-9040
URL: https://issues.apache.org/jira/browse/CAMEL-9040
Project: Camel
Issue Type: Bug
Components: camel-netty4-http
Affects Versions: 2.15.1, 2.15.2
Reporter: Ralf Steppacher
In a reverse-proxy with multiple routes that utilize the netty4-http
component both as the consumer and producer I am receiving the following
error:
{noformat}
2015-07-30 11:52:34,416 | ERROR | yServerTCPWorker | ResourceLeakDetector
| 97 - io.netty.common - 4.0.27.Final | | LEAK: ByteBuf.release()
was not called before it's garbage-collected. See
http://netty.io/wiki/reference-counted-objects.html for more information.
{noformat}
Setting the Netty leak reporting to paranoid
({{-Dio.netty.leakDetectionLevel=paranoid}}) yields an error for almost every
request (it probably is 1:1).
The stacktraces come in two variants. Variant 1 is far less frequent than
variant 2.
Variant 1:
{noformat}
Recent access records: 0
Created at:
io.netty.buffer.CompositeByteBuf.init(CompositeByteBuf.java:60)
io.netty.buffer.Unpooled.compositeBuffer(Unpooled.java:353)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:153)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:54)
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:242)
io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:147)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
java.lang.Thread.run(Thread.java:745)
{noformat}
Variant 2:
{noformat}
Recent access records: 5
#5:
io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:223)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:684)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:40)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:677)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1493)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:40)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
java.io.BufferedInputStream.read(BufferedInputStream.java:334)
org.bouncycastle.util.io.TeeInputStream.read(Unknown Source)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:250)
com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:133)
com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:545)
com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:605)
com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:628)
com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:331)
ch.vivates.pep.stream.ResponseStatusFilter.filter(ResponseStatusFilter.java:41)
ch.vivates.pep.stream.BaseStreamFilter.run(BaseStreamFilter.java:141)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
java.util.concurrent.FutureTask.run(FutureTask.java:262)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[jira] [Updated] (CAMEL-9040) netty4-http - LEAK: ByteBuf.release() was not called before it's garbage-collected
[
https://issues.apache.org/jira/browse/CAMEL-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-9040:
---
Priority: Critical (was: Major)
netty4-http - LEAK: ByteBuf.release() was not called before it's
garbage-collected
--
Key: CAMEL-9040
URL: https://issues.apache.org/jira/browse/CAMEL-9040
Project: Camel
Issue Type: Bug
Components: camel-netty4-http
Affects Versions: 2.15.1, 2.15.2
Reporter: Ralf Steppacher
Priority: Critical
In a reverse-proxy with multiple routes that utilize the netty4-http
component both as the consumer and producer I am receiving the following
error:
{noformat}
2015-07-30 11:52:34,416 | ERROR | yServerTCPWorker | ResourceLeakDetector
| 97 - io.netty.common - 4.0.27.Final | | LEAK: ByteBuf.release()
was not called before it's garbage-collected. See
http://netty.io/wiki/reference-counted-objects.html for more information.
{noformat}
Setting the Netty leak reporting to paranoid
({{-Dio.netty.leakDetectionLevel=paranoid}}) yields an error for almost every
request (it probably is 1:1).
The stacktraces come in two variants. Variant 1 is far less frequent than
variant 2.
Variant 1:
{noformat}
Recent access records: 0
Created at:
io.netty.buffer.CompositeByteBuf.init(CompositeByteBuf.java:60)
io.netty.buffer.Unpooled.compositeBuffer(Unpooled.java:353)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:153)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:54)
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:242)
io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:147)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
java.lang.Thread.run(Thread.java:745)
{noformat}
Variant 2:
{noformat}
Recent access records: 5
#5:
io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:223)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:684)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:40)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:677)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1493)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:40)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
java.io.BufferedInputStream.read(BufferedInputStream.java:334)
org.bouncycastle.util.io.TeeInputStream.read(Unknown Source)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:250)
com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:133)
com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:545)
com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:605)
com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:628)
com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:331)
ch.vivates.pep.stream.ResponseStatusFilter.filter(ResponseStatusFilter.java:41)
ch.vivates.pep.stream.BaseStreamFilter.run(BaseStreamFilter.java:141)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
java.util.concurrent.FutureTask.run(FutureTask.java:262)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[jira] [Created] (CAMEL-9040) netty4-http - LEAK: ByteBuf.release() was not called before it's garbage-collected
Ralf Steppacher created CAMEL-9040:
--
Summary: netty4-http - LEAK: ByteBuf.release() was not called
before it's garbage-collected
Key: CAMEL-9040
URL: https://issues.apache.org/jira/browse/CAMEL-9040
Project: Camel
Issue Type: Bug
Components: camel-netty4-http
Affects Versions: 2.15.2
Reporter: Ralf Steppacher
In a reverse-proxy with multiple routes that utilize the netty4-http component
both as the consumer and producer I am receiving the following error:
{noformat}
2015-07-30 11:52:34,416 | ERROR | yServerTCPWorker | ResourceLeakDetector
| 97 - io.netty.common - 4.0.27.Final | | LEAK: ByteBuf.release() was
not called before it's garbage-collected. See
http://netty.io/wiki/reference-counted-objects.html for more information.
{noformat}
Setting the Netty leak reporting to paranoid
({{-Dio.netty.leakDetectionLevel=paranoid}}) yields an error for almost every
request (it probably is 1:1).
The stacktraces come in two variants. Variant 1 is far less frequent than
variant 2.
Variant 1:
{noformat}
Recent access records: 0
Created at:
io.netty.buffer.CompositeByteBuf.init(CompositeByteBuf.java:60)
io.netty.buffer.Unpooled.compositeBuffer(Unpooled.java:353)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:153)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:54)
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:242)
io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:147)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
java.lang.Thread.run(Thread.java:745)
{noformat}
Variant 2:
{noformat}
Recent access records: 5
#5:
io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:223)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:684)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:40)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:677)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1493)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:40)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
java.io.BufferedInputStream.read(BufferedInputStream.java:334)
org.bouncycastle.util.io.TeeInputStream.read(Unknown Source)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:250)
com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:133)
com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:545)
com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:605)
com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:628)
com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:331)
ch.vivates.pep.stream.ResponseStatusFilter.filter(ResponseStatusFilter.java:41)
ch.vivates.pep.stream.BaseStreamFilter.run(BaseStreamFilter.java:141)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
java.util.concurrent.FutureTask.run(FutureTask.java:262)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:745)
#4:
io.netty.buffer.AdvancedLeakAwareByteBuf.release(AdvancedLeakAwareByteBuf.java:45)
io.netty.handler.codec.http.DefaultHttpContent.release(DefaultHttpContent.java:72)
io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:59)
[jira] [Updated] (CAMEL-9040) netty4-http - LEAK: ByteBuf.release() was not called before it's garbage-collected
[
https://issues.apache.org/jira/browse/CAMEL-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-9040:
---
Description:
In a reverse-proxy with multiple routes that utilize the netty4-http component
both as the consumer and producer I am receiving the following error:
{noformat}
2015-07-30 11:52:34,416 | ERROR | yServerTCPWorker | ResourceLeakDetector
| 97 - io.netty.common - 4.0.27.Final | | LEAK: ByteBuf.release() was
not called before it's garbage-collected. See
http://netty.io/wiki/reference-counted-objects.html for more information.
{noformat}
Setting the Netty leak reporting to paranoid
({{-Dio.netty.leakDetectionLevel=paranoid}}) yields an error for almost every
request (it probably is 1:1).
The stacktraces come in two variants. Variant 1 is far less frequent than
variant 2.
Variant 1:
{noformat}
Recent access records: 0
Created at:
io.netty.buffer.CompositeByteBuf.init(CompositeByteBuf.java:60)
io.netty.buffer.Unpooled.compositeBuffer(Unpooled.java:353)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:153)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:54)
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:242)
io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:147)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
java.lang.Thread.run(Thread.java:745)
{noformat}
Variant 2:
{noformat}
Recent access records: 5
#5:
io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:223)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:684)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:40)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:677)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1493)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:40)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
java.io.BufferedInputStream.read(BufferedInputStream.java:334)
org.bouncycastle.util.io.TeeInputStream.read(Unknown Source)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:250)
com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:133)
com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:545)
com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:605)
com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:628)
com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:331)
ch.vivates.pep.stream.ResponseStatusFilter.filter(ResponseStatusFilter.java:41)
ch.vivates.pep.stream.BaseStreamFilter.run(BaseStreamFilter.java:141)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
java.util.concurrent.FutureTask.run(FutureTask.java:262)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:745)
#4:
io.netty.buffer.AdvancedLeakAwareByteBuf.release(AdvancedLeakAwareByteBuf.java:45)
io.netty.handler.codec.http.DefaultHttpContent.release(DefaultHttpContent.java:72)
io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:59)
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:91)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
[jira] [Updated] (CAMEL-9040) netty4-http - LEAK: ByteBuf.release() was not called before it's garbage-collected
[
https://issues.apache.org/jira/browse/CAMEL-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-9040:
---
Description:
In a reverse-proxy with multiple routes that utilize the netty4-http component
both as the consumer and producer I am receiving the following error:
{noformat}
2015-07-30 11:52:34,416 | ERROR | yServerTCPWorker | ResourceLeakDetector
| 97 - io.netty.common - 4.0.27.Final | | LEAK: ByteBuf.release() was
not called before it's garbage-collected. See
http://netty.io/wiki/reference-counted-objects.html for more information.
{noformat}
Setting the Netty leak reporting to paranoid
({{-Dio.netty.leakDetectionLevel=paranoid}}) yields an error for almost every
request (it probably is 1:1).
The stacktraces come in two variants. Variant 1 is far less frequent than
variant 2.
Variant 1:
{noformat}
Recent access records: 0
Created at:
io.netty.buffer.CompositeByteBuf.init(CompositeByteBuf.java:60)
io.netty.buffer.Unpooled.compositeBuffer(Unpooled.java:353)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:153)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:54)
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:242)
io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:147)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
java.lang.Thread.run(Thread.java:745)
{noformat}
Variant 2:
{noformat}
Recent access records: 5
#5:
io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:223)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:684)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:40)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:677)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1493)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:40)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
java.io.BufferedInputStream.read(BufferedInputStream.java:334)
org.bouncycastle.util.io.TeeInputStream.read(Unknown Source)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:250)
com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:133)
com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:545)
com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:605)
com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:628)
com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:331)
ch.vivates.pep.stream.ResponseStatusFilter.filter(ResponseStatusFilter.java:41)
ch.vivates.pep.stream.BaseStreamFilter.run(BaseStreamFilter.java:141)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
java.util.concurrent.FutureTask.run(FutureTask.java:262)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:745)
#4:
io.netty.buffer.AdvancedLeakAwareByteBuf.release(AdvancedLeakAwareByteBuf.java:45)
io.netty.handler.codec.http.DefaultHttpContent.release(DefaultHttpContent.java:72)
io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:59)
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:91)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
[jira] [Updated] (CAMEL-8904) Breadcrumb ID changes when using netty4-http as a producer
[
https://issues.apache.org/jira/browse/CAMEL-8904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-8904:
---
Affects Version/s: 2.15.2
Breadcrumb ID changes when using netty4-http as a producer
--
Key: CAMEL-8904
URL: https://issues.apache.org/jira/browse/CAMEL-8904
Project: Camel
Issue Type: Bug
Components: camel-netty4-http
Affects Versions: 2.14.1, 2.15.2
Reporter: Ralf Steppacher
Assignee: Claus Ibsen
When using the {{netty4-http}} component as a producer, the response from the
remote server is processed in a different thread ({{... yClientTCPWorker}})
than the start of the Camel route and thus the breadcrumb ID changes (because
the MDC context changes/is lost).
{code}
2015-06-25 09:55:40,887 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-29 | Call to repository received.
-- remote call; the next line is logged after the response was received --
2015-06-25 09:55:41,155 | INFO | yClientTCPWorker | AuditLogger
| 168 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-9-33 | User id: ...
2015-06-25 09:55:41,171 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-33 | Logging XDS event: ...
{code}
In the example above the breadcrumb changes from
{{ID-ptl9921-45465-1435218175846-9-29}} to
{{ID-ptl9921-45465-1435218175846-9-33}}.
If I use http4 as the producer the breadcrumb is the same for all route
steps. Presumably because the same thread executes all route steps.
Route that reproduces the issue for me:
{code:xml}
route
from
uri=netty4-http:http://{{pep.host}}:{{pep.xds.b.repository.port}}/XDS3/repository?matchOnUriPrefix=trueamp;disableStreamCache=true;
/
log message=Call to repository received. loggingLevel=INFO
logName=pep-xds_b-repository /
process ref=repositoryInboundProcessor /
to
uri=netty4-http:http://{{xds.b.repository.host}}:{{xds.b.repository.port}}/XDS3/repository?bridgeEndpoint=trueamp;throwExceptionOnFailure=falseamp;disableStreamCache=true;
/
process ref=repositoryOutboundProcessor /
/route
onCompletion mode=AfterConsumer parallelProcessing=false
process ref=forkJoinProcessor /
bean ref=auditLogger method=localAuditXDS /
bean ref=auditLogger method=createCommandUserLogXDS /
setExchangePattern pattern=InOnly /
to uri=activemq:queue:{{activemq.queue.events.user.xds}} /
/onCompletion{code}
The {{repositoryOutboundProcessor}} and the {{onCompletion}} parts log a
different breadcrumb (and thread name) than the beginning of the route before
the {{to uri=netty4-http:http:// ...}} step.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8904) Breadcrumb ID changes when using netty4-http as a producer
[
https://issues.apache.org/jira/browse/CAMEL-8904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-8904:
---
Description:
When using the {{netty4-http}} component as a producer, the response from the
remote server is processed in a different thread ({{... yClientTCPWorker}})
than the start of the Camel route and thus the breadcrumb ID changes (because
the MDC context changes/is lost).
{code}
2015-06-25 09:55:40,887 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-29 | Call to repository received.
-- remote call; the next line is logged after the response was received --
2015-06-25 09:55:41,155 | INFO | yClientTCPWorker | AuditLogger
| 168 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-9-33 | User id: ...
2015-06-25 09:55:41,171 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-33 | Logging XDS event: ...
{code}
In the example above the breadcrumb changes from
{{ID-ptl9921-45465-1435218175846-9-29}} to
{{ID-ptl9921-45465-1435218175846-9-33}}.
If I use http4 as the producer the breadcrumb is the same for all route steps.
Presumably because the same thread executes all route steps.
Route that reproduces the issue for me:
{code:xml}
route
from
uri=netty4-http:http://{{pep.host}}:{{pep.xds.b.repository.port}}/XDS3/repository?matchOnUriPrefix=trueamp;disableStreamCache=true;
/
log message=Call to repository received. loggingLevel=INFO
logName=pep-xds_b-repository /
process ref=repositoryInboundProcessor /
to
uri=netty4-http:http://{{xds.b.repository.host}}:{{xds.b.repository.port}}/XDS3/repository?bridgeEndpoint=trueamp;throwExceptionOnFailure=falseamp;disableStreamCache=true;
/
process ref=repositoryOutboundProcessor /
/route
onCompletion mode=AfterConsumer parallelProcessing=false
process ref=forkJoinProcessor /
bean ref=auditLogger method=localAuditXDS /
bean ref=auditLogger method=createCommandUserLogXDS /
setExchangePattern pattern=InOnly /
to uri=activemq:queue:{{activemq.queue.events.user.xds}} /
/onCompletion{code}
The {{repositoryOutboundProcessor}} and the {{onCompletion}} parts log a
different breadcrumb (and thread name) than the beginning of the route before
the {{to uri=netty4-http:http:// ...}} step.
was:
When using the {{netty4-http}} component as a producer, the response from the
remote server is processed in a different thread ({{... yClientTCPWorker}})
than the start of the Camel route and thus the breadcrumb ID changes (because
the MDC context changes/is lost).
{code}
2015-06-25 09:55:40,887 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-29 | Call to repository received.
-- remote call; the next line is logged after the response was received --
2015-06-25 09:55:41,155 | INFO | yClientTCPWorker | AuditLogger
| 168 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-9-33 | User id: ...
2015-06-25 09:55:41,171 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-33 | Logging XDS event: ...
{code}
In the example above the breadcrumb changes from
{{ID-ptl9921-45465-1435218175846-9-29}} to
{{ID-ptl9921-45465-1435218175846-9-33}}.
If I use http4 as the producer the breadcrumb is the same for all route steps.
Presumably because the same thread executes all route steps.
Route that reproduces the issue for me:
{code:xml}
route
from
uri=netty4-http:http://{{pep.host}}:{{pep.xds.b.repository.port}}/XDS3/repository?matchOnUriPrefix=trueamp;disableStreamCache=true;
/
log message=Call to repository received. loggingLevel=INFO
logName=pep-xds_b-repository /
process ref=repositoryInboundProcessor /
to
uri=netty4-http:http://{{xds.b.repository.host}}:{{xds.b.repository.port}}/XDS3/repository?bridgeEndpoint=trueamp;throwExceptionOnFailure=falseamp;disableStreamCache=true;
/
process ref=repositoryOutboundProcessor /
/route
onCompletion mode=AfterConsumer parallelProcessing=false
process ref=forkJoinProcessor /
bean ref=auditLogger method=localAuditXDS /
bean ref=auditLogger method=createCommandUserLogXDS /
setExchangePattern pattern=InOnly /
to uri=activemq:queue:{{activemq.queue.events.user.xds}} /
/onCompletion{code}
The {{repositoryOutboundProcessor}} and the {{onCompletion}} parts log a
different breadcrumb (and thread name) than the beginning of the route before
the {{to uri=netty4-http:http:// ...}}.
Breadcrumb ID changes when using netty4-http
[jira] [Updated] (CAMEL-8904) Breadcrumb ID changes when using netty4-http as a producer
[
https://issues.apache.org/jira/browse/CAMEL-8904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-8904:
---
Description:
When using the {{netty4-http}} component as a producer, the response from the
remote server is processed in a different thread ({{... yClientTCPWorker}})
than the start of the Camel route and thus the breadcrumb ID changes (because
the MDC context changes/is lost).
{code}
2015-06-25 09:55:40,887 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-29 | Call to repository received.
-- remote call; the next line is logged after the response was received --
2015-06-25 09:55:41,155 | INFO | yClientTCPWorker | AuditLogger
| 168 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-9-33 | User id: ...
2015-06-25 09:55:41,171 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-33 | Logging XDS event: ...
{code}
In the example above the breadcrumb changes from
{{ID-ptl9921-45465-1435218175846-9-29}} to
{{ID-ptl9921-45465-1435218175846-9-33}}.
If I use http4 as the producer the breadcrumb is the same for all route steps.
Presumably because the same thread executes all route steps.
Route that reproduces the issue for me:
{code:xml}
route
from
uri=netty4-http:http://{{pep.host}}:{{pep.xds.b.repository.port}}/XDS3/repository?matchOnUriPrefix=trueamp;disableStreamCache=true;
/
log message=Call to repository received.
loggingLevel=INFO logName=pep-xds_b-repository /
process ref=repositoryInboundProcessor /
to
uri=netty4-http:http://{{xds.b.repository.host}}:{{xds.b.repository.port}}/XDS3/repository?bridgeEndpoint=trueamp;throwExceptionOnFailure=falseamp;disableStreamCache=true;
/
process ref=repositoryOutboundProcessor /
/route
onCompletion mode=AfterConsumer parallelProcessing=false
process ref=forkJoinProcessor /
bean ref=auditLogger method=localAuditXDS /
bean ref=auditLogger
method=createCommandUserLogXDS /
setExchangePattern pattern=InOnly /
to
uri=activemq:queue:{{activemq.queue.events.user.xds}} /
/onCompletion
{code}
The {{repositoryOutboundProcessor}} and the {{onCompletion}} parts log a
different breadcrumb (and thread name) than the beginning of the route before
the {{to uri=netty4-http:http:// ...}}.
was:
When using the {{netty4-http}} component as a producer, the response from the
remote server is processed in a different thread ({{... yClientTCPWorker}})
than the start of the Camel route and thus the breadcrumb ID changes (because
the MDC context changes/is lost).
{code}
2015-06-25 09:55:40,887 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-29 | Call to repository received.
-- remote call; the next line is logged after the response was received --
2015-06-25 09:55:41,155 | INFO | yClientTCPWorker | AuditLogger
| 168 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-9-33 | User id: ...
2015-06-25 09:55:41,171 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-33 | Logging XDS event: ...
{code}
In the example above the breadcrumb changes from
{{ID-ptl9921-45465-1435218175846-9-29}} to
{{ID-ptl9921-45465-1435218175846-9-33}}.
If I use http4 as the producer the breadcrumb is the same for all route steps.
Presumably because the same thread executes all route steps.
Breadcrumb ID changes when using netty4-http as a producer
--
Key: CAMEL-8904
URL: https://issues.apache.org/jira/browse/CAMEL-8904
Project: Camel
Issue Type: Bug
Components: camel-netty4-http
Affects Versions: 2.14.1
Reporter: Ralf Steppacher
Assignee: Claus Ibsen
When using the {{netty4-http}} component as a producer, the response from the
remote server is processed in a different thread ({{... yClientTCPWorker}})
than the start of the Camel route and thus the breadcrumb ID changes (because
the MDC context changes/is lost).
{code}
2015-06-25 09:55:40,887 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-29 | Call to repository received.
-- remote call; the next line is logged after the
[jira] [Updated] (CAMEL-8904) Breadcrumb ID changes when using netty4-http as a producer
[
https://issues.apache.org/jira/browse/CAMEL-8904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-8904:
---
Description:
When using the {{netty4-http}} component as a producer, the response from the
remote server is processed in a different thread ({{... yClientTCPWorker}})
than the start of the Camel route and thus the breadcrumb ID changes (because
the MDC context changes/is lost).
{code}
2015-06-25 09:55:40,887 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-29 | Call to repository received.
-- remote call; the next line is logged after the response was received --
2015-06-25 09:55:41,155 | INFO | yClientTCPWorker | AuditLogger
| 168 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-9-33 | User id: ...
2015-06-25 09:55:41,171 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-33 | Logging XDS event: ...
{code}
In the example above the breadcrumb changes from
{{ID-ptl9921-45465-1435218175846-9-29}} to
{{ID-ptl9921-45465-1435218175846-9-33}}.
If I use http4 as the producer the breadcrumb is the same for all route steps.
Presumably because the same thread executes all route steps.
Route that reproduces the issue for me:
{code:xml}
route
from
uri=netty4-http:http://{{pep.host}}:{{pep.xds.b.repository.port}}/XDS3/repository?matchOnUriPrefix=trueamp;disableStreamCache=true;
/
log message=Call to repository received. loggingLevel=INFO
logName=pep-xds_b-repository /
process ref=repositoryInboundProcessor /
to
uri=netty4-http:http://{{xds.b.repository.host}}:{{xds.b.repository.port}}/XDS3/repository?bridgeEndpoint=trueamp;throwExceptionOnFailure=falseamp;disableStreamCache=true;
/
process ref=repositoryOutboundProcessor /
/route
onCompletion mode=AfterConsumer parallelProcessing=false
process ref=forkJoinProcessor /
bean ref=auditLogger method=localAuditXDS /
bean ref=auditLogger method=createCommandUserLogXDS /
setExchangePattern pattern=InOnly /
to uri=activemq:queue:{{activemq.queue.events.user.xds}} /
/onCompletion{code}
The {{repositoryOutboundProcessor}} and the {{onCompletion}} parts log a
different breadcrumb (and thread name) than the beginning of the route before
the {{to uri=netty4-http:http:// ...}}.
was:
When using the {{netty4-http}} component as a producer, the response from the
remote server is processed in a different thread ({{... yClientTCPWorker}})
than the start of the Camel route and thus the breadcrumb ID changes (because
the MDC context changes/is lost).
{code}
2015-06-25 09:55:40,887 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-29 | Call to repository received.
-- remote call; the next line is logged after the response was received --
2015-06-25 09:55:41,155 | INFO | yClientTCPWorker | AuditLogger
| 168 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-9-33 | User id: ...
2015-06-25 09:55:41,171 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-33 | Logging XDS event: ...
{code}
In the example above the breadcrumb changes from
{{ID-ptl9921-45465-1435218175846-9-29}} to
{{ID-ptl9921-45465-1435218175846-9-33}}.
If I use http4 as the producer the breadcrumb is the same for all route steps.
Presumably because the same thread executes all route steps.
Route that reproduces the issue for me:
{code:xml}
route
from
uri=netty4-http:http://{{pep.host}}:{{pep.xds.b.repository.port}}/XDS3/repository?matchOnUriPrefix=trueamp;disableStreamCache=true;
/
log message=Call to repository received.
loggingLevel=INFO logName=pep-xds_b-repository /
process ref=repositoryInboundProcessor /
to
uri=netty4-http:http://{{xds.b.repository.host}}:{{xds.b.repository.port}}/XDS3/repository?bridgeEndpoint=trueamp;throwExceptionOnFailure=falseamp;disableStreamCache=true;
/
process ref=repositoryOutboundProcessor /
/route
onCompletion mode=AfterConsumer parallelProcessing=false
process ref=forkJoinProcessor /
bean ref=auditLogger method=localAuditXDS /
bean ref=auditLogger
method=createCommandUserLogXDS /
setExchangePattern pattern=InOnly /
to
uri=activemq:queue:{{activemq.queue.events.user.xds}} /
/onCompletion
{code}
The
[jira] [Commented] (CAMEL-8904) Breadcrumb ID changes when using netty4-http as a producer
[
https://issues.apache.org/jira/browse/CAMEL-8904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14604913#comment-14604913
]
Ralf Steppacher commented on CAMEL-8904:
[~davsclaus], yes, MDC logging is activated. The breadcrumb is logged in the
6th column. The executing thread is logged in the 3rd column.
Breadcrumb ID changes when using netty4-http as a producer
--
Key: CAMEL-8904
URL: https://issues.apache.org/jira/browse/CAMEL-8904
Project: Camel
Issue Type: Bug
Components: camel-netty4-http
Affects Versions: 2.14.1
Reporter: Ralf Steppacher
When using the {{netty4-http}} component as a producer, the response from the
remote server is processed in a different thread ({{... yClientTCPWorker}})
than the start of the Camel route and thus the breadcrumb ID changes (because
the MDC context changes/is lost).
{code}
2015-06-25 09:55:40,887 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-29 | Call to repository received.
-- remote call; the next line is logged after the response was received --
2015-06-25 09:55:41,155 | INFO | yClientTCPWorker | AuditLogger
| 168 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-9-33 | User id: ...
2015-06-25 09:55:41,171 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-33 | Logging XDS event: ...
{code}
In the example above the breadcrumb changes from
{{ID-ptl9921-45465-1435218175846-9-29}} to
{{ID-ptl9921-45465-1435218175846-9-33}}.
If I use http4 as the producer the breadcrumb is the same for all route
steps. Presumably because the same thread executes all route steps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8904) Breadcrumb ID changes when using netty4-http as a producer
[
https://issues.apache.org/jira/browse/CAMEL-8904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-8904:
---
Description:
When using the {{netty4-http}} component as a producer, the response from the
remote server is processed in a different thread ({{... yClientTCPWorker}})
than the start of the Camel route and thus the breadcrumb ID changes (because
the MDC context changes/is lost).
{code}
2015-06-25 09:55:40,887 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-29 | Call to repository received.
-- remote call; the next line is logged after the response was received --
2015-06-25 09:55:41,155 | INFO | yClientTCPWorker | AuditLogger
| 168 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-9-33 | User id: ...
2015-06-25 09:55:41,171 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-33 | Logging XDS event: ...
{code}
In the example above the breadcrumb changes from
{{ID-ptl9921-45465-1435218175846-9-29}} to
{{ID-ptl9921-45465-1435218175846-9-33}}.
If I use http4 as the producer the breadcrumb is the same for all route steps.
Presumably because the same thread executes all route steps.
was:
When using the {{netty4-http}} component as a producer, the response from the
remote server is processed in a different thread ({{... yClientTCPWorker}})
than the start of the Camel route and thus the breadcrumb ID is lost (because
the MDC context changes/is lost).
{code}
2015-06-25 09:55:40,887 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-29 | Call to repository received.
-- remote call; the next line is logged after the response was received --
2015-06-25 09:55:41,155 | INFO | yClientTCPWorker | AuditLogger
| 168 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-9-33 | User id: ...
2015-06-25 09:55:41,171 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-33 | Logging XDS event: ...
{code}
Breadcrumb ID changes when using netty4-http as a producer
--
Key: CAMEL-8904
URL: https://issues.apache.org/jira/browse/CAMEL-8904
Project: Camel
Issue Type: Bug
Components: camel-netty4-http
Affects Versions: 2.14.1
Reporter: Ralf Steppacher
When using the {{netty4-http}} component as a producer, the response from the
remote server is processed in a different thread ({{... yClientTCPWorker}})
than the start of the Camel route and thus the breadcrumb ID changes (because
the MDC context changes/is lost).
{code}
2015-06-25 09:55:40,887 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-29 | Call to repository received.
-- remote call; the next line is logged after the response was received --
2015-06-25 09:55:41,155 | INFO | yClientTCPWorker | AuditLogger
| 168 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-9-33 | User id: ...
2015-06-25 09:55:41,171 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-33 | Logging XDS event: ...
{code}
In the example above the breadcrumb changes from
{{ID-ptl9921-45465-1435218175846-9-29}} to
{{ID-ptl9921-45465-1435218175846-9-33}}.
If I use http4 as the producer the breadcrumb is the same for all route
steps. Presumably because the same thread executes all route steps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8351) Spring-ws consumer ignores breadcrumbId http header
[
https://issues.apache.org/jira/browse/CAMEL-8351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14600866#comment-14600866
]
Ralf Steppacher commented on CAMEL-8351:
{code}
2015-06-25 10:21:26,794 | INFO | entExecutorGroup | pep-xds_b-registry
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-21-391 | Call to registry received.
2015-06-25 10:21:26,883 | INFO | entExecutorGroup | AuditLogger
| 194 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-21-391 | User id: '14582'; user type:
'LICENSED_DOCTOR'; transaction: 'AdhocQueryRequest'; resource patient id:
'100013866046895035'; resources:
'{100013866046895035={88467e80-c840-83c2-77f7-4ad05d3c447b=XACMLResponse
[emergency=false, decision=Permit]}}'; transaction SUCCEEDED; pep SUCCEEDED
2015-06-25 10:21:26,893 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-21-391 | Logging XDS event: Command [type=LOG,
getVersion()=1, getCorrelationID()=ID-ptl9921-45465-1435218175846-21-391,
getCreatedAt()=1435220486883]
2015-06-25 10:21:26,927 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-21-397 | Call to repository received.
2015-06-25 10:21:27,013 | INFO | entExecutorGroup | AuditLogger
| 194 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-21-397 | User id: '14582'; user type:
'LICENSED_DOCTOR'; transaction: 'RetrieveDocumentSetRequest'; resource patient
id: '100013866046895035'; resources:
'{100013866046895035={88467e80-c840-83c2-77f7-4ad05d3c447b=XACMLResponse
[emergency=false, decision=Permit]}}'; transaction SUCCEEDED; pep SUCCEEDED
2015-06-25 10:21:27,022 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-21-397 | Logging XDS event: Command [type=LOG,
getVersion()=1, getCorrelationID()=ID-ptl9921-45465-1435218175846-21-397,
getCreatedAt()=1435220487013]
{code}
Spring-ws consumer ignores breadcrumbId http header
---
Key: CAMEL-8351
URL: https://issues.apache.org/jira/browse/CAMEL-8351
Project: Camel
Issue Type: Improvement
Components: camel-spring-ws
Affects Versions: 2.14.1
Reporter: Ralf Steppacher
The spring-ws consumer does not pick up a {{breadcrumbId}} HTTP header. I
tried to find a hook where I could jump in and make the breadcrumbId from the
HTTP headers available, but could not find any.
The spring-ws endpoint ({{SpringWebserviceConsumer}}) does not care about
HTTP headers, only about SOAP headers and properties of the
{{org.springframework.ws.context.MessageContext}}. SOAP headers get converted
into exchange headers while message context properties get converted into
exchange properties. Properties could be added by using a
{{org.springframework.ws.server.EndpointInterceptor}}.
A breadcrumbId property is not picked up by Camel though. The
{{org.apache.camel.impl.DefaultUnitOfWork}} creates a new breadcrumbId
because it only checks the headers of the in-message, not the exchange
properties for an already existing breadcrumb ID.
A SOAPHeader breadcrumbId is copied over to the in-message headers and
picked up by the DefaultUnitOfWork, but it is not automagically converted
from {{org.springframework.ws.soap.saaj.SaajSoapHeaderElement}} to its text
content.
Ideally the web service consumer would pick up the breadcrumId (and others)
from the HTTP headers and restore them as in-message headers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (CAMEL-8351) Spring-ws consumer ignores breadcrumbId http header
[
https://issues.apache.org/jira/browse/CAMEL-8351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-8351:
---
Comment: was deleted
(was: {code}
2015-06-25 10:21:26,794 | INFO | entExecutorGroup | pep-xds_b-registry
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-21-391 | Call to registry received.
2015-06-25 10:21:26,883 | INFO | entExecutorGroup | AuditLogger
| 194 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-21-391 | User id: '14582'; user type:
'LICENSED_DOCTOR'; transaction: 'AdhocQueryRequest'; resource patient id:
'100013866046895035'; resources:
'{100013866046895035={88467e80-c840-83c2-77f7-4ad05d3c447b=XACMLResponse
[emergency=false, decision=Permit]}}'; transaction SUCCEEDED; pep SUCCEEDED
2015-06-25 10:21:26,893 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-21-391 | Logging XDS event: Command [type=LOG,
getVersion()=1, getCorrelationID()=ID-ptl9921-45465-1435218175846-21-391,
getCreatedAt()=1435220486883]
2015-06-25 10:21:26,927 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-21-397 | Call to repository received.
2015-06-25 10:21:27,013 | INFO | entExecutorGroup | AuditLogger
| 194 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-21-397 | User id: '14582'; user type:
'LICENSED_DOCTOR'; transaction: 'RetrieveDocumentSetRequest'; resource patient
id: '100013866046895035'; resources:
'{100013866046895035={88467e80-c840-83c2-77f7-4ad05d3c447b=XACMLResponse
[emergency=false, decision=Permit]}}'; transaction SUCCEEDED; pep SUCCEEDED
2015-06-25 10:21:27,022 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-21-397 | Logging XDS event: Command [type=LOG,
getVersion()=1, getCorrelationID()=ID-ptl9921-45465-1435218175846-21-397,
getCreatedAt()=1435220487013]
{code})
Spring-ws consumer ignores breadcrumbId http header
---
Key: CAMEL-8351
URL: https://issues.apache.org/jira/browse/CAMEL-8351
Project: Camel
Issue Type: Improvement
Components: camel-spring-ws
Affects Versions: 2.14.1
Reporter: Ralf Steppacher
The spring-ws consumer does not pick up a {{breadcrumbId}} HTTP header. I
tried to find a hook where I could jump in and make the breadcrumbId from the
HTTP headers available, but could not find any.
The spring-ws endpoint ({{SpringWebserviceConsumer}}) does not care about
HTTP headers, only about SOAP headers and properties of the
{{org.springframework.ws.context.MessageContext}}. SOAP headers get converted
into exchange headers while message context properties get converted into
exchange properties. Properties could be added by using a
{{org.springframework.ws.server.EndpointInterceptor}}.
A breadcrumbId property is not picked up by Camel though. The
{{org.apache.camel.impl.DefaultUnitOfWork}} creates a new breadcrumbId
because it only checks the headers of the in-message, not the exchange
properties for an already existing breadcrumb ID.
A SOAPHeader breadcrumbId is copied over to the in-message headers and
picked up by the DefaultUnitOfWork, but it is not automagically converted
from {{org.springframework.ws.soap.saaj.SaajSoapHeaderElement}} to its text
content.
Ideally the web service consumer would pick up the breadcrumId (and others)
from the HTTP headers and restore them as in-message headers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8904) Breadcrumb ID changes when using netty4-http as a producer
[
https://issues.apache.org/jira/browse/CAMEL-8904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-8904:
---
Description:
When using the {{netty4-http}} component as a producer, the response from the
remote server is processed in a different thread ({{... yClientTCPWorker}})
than the start of the Camel route and thus the breadcrumb ID is lost (because
the MDC context changes/is lost).
{code}
2015-06-25 09:55:40,887 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-29 | Call to repository received.
-- remote call; the next line is logged after the response was received --
2015-06-25 09:55:41,155 | INFO | yClientTCPWorker | AuditLogger
| 168 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-9-33 | User id: ...
2015-06-25 09:55:41,171 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-33 | Logging XDS event: ...
{code}
was:
When using the {{netty4-http}} component as a producer, the response from the
remote server is processed in a different thread ({{... yClientTCPWorker}})
than the start of the Camel route and thus the breadcrumb ID is lost (because
the MDC context changes/is lost).
{code}
2015-06-25 09:55:40,887 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-29 | Call to repository received.
2015-06-25 09:55:41,155 | INFO | yClientTCPWorker | AuditLogger
| 168 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-9-33 | User id: ...
2015-06-25 09:55:41,171 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-33 | Logging XDS event: ...
{code}
Breadcrumb ID changes when using netty4-http as a producer
--
Key: CAMEL-8904
URL: https://issues.apache.org/jira/browse/CAMEL-8904
Project: Camel
Issue Type: Bug
Components: camel-netty4-http
Affects Versions: 2.14.1
Reporter: Ralf Steppacher
When using the {{netty4-http}} component as a producer, the response from the
remote server is processed in a different thread ({{... yClientTCPWorker}})
than the start of the Camel route and thus the breadcrumb ID is lost (because
the MDC context changes/is lost).
{code}
2015-06-25 09:55:40,887 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-29 | Call to repository received.
-- remote call; the next line is logged after the response was received --
2015-06-25 09:55:41,155 | INFO | yClientTCPWorker | AuditLogger
| 168 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-9-33 | User id: ...
2015-06-25 09:55:41,171 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-33 | Logging XDS event: ...
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-8904) Breadcrumb ID changes when using netty4-http as a producer
Ralf Steppacher created CAMEL-8904:
--
Summary: Breadcrumb ID changes when using netty4-http as a producer
Key: CAMEL-8904
URL: https://issues.apache.org/jira/browse/CAMEL-8904
Project: Camel
Issue Type: Bug
Components: camel-netty4-http
Affects Versions: 2.14.1
Reporter: Ralf Steppacher
When using the {{netty4-http}} component as a producer, the response from the
remote server is processed in a different thread ({{... yClientTCPWorker}})
than the start of the Camel route and thus the breadcrumb ID is lost (because
the MDC context changes/is lost).
{code}
2015-06-25 09:55:40,887 | INFO | entExecutorGroup | pep-xds_b-repository
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-29 | Call to repository received.
2015-06-25 09:55:41,155 | INFO | yClientTCPWorker | AuditLogger
| 168 - ch.vivates.ams.pep - 3.0.1.SNAPSHOT |
ID-ptl9921-45465-1435218175846-9-33 | User id: ...
2015-06-25 09:55:41,171 | INFO | EVENTS.USER.XDS] | route_xds_b-activity
| 70 - org.apache.camel.camel-core - 2.14.1 |
ID-ptl9921-45465-1435218175846-9-33 | Logging XDS event: ...
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7638) Use response input stream directly in http producer
[
https://issues.apache.org/jira/browse/CAMEL-7638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14550064#comment-14550064
]
Ralf Steppacher commented on CAMEL-7638:
[~claus_maps...@yahoo.com], setting {{disableStreamCache=true}} only effects
the http consumers, but not the procuders.
All http producers that I am aware of (Jetty, http4, netty-http) read the
response stream into a byte-array, wrap it in an InputStream and place that in
the exchange body. Thus a large http response blows a proxy route out of the
water. None of the producers seem to offer an option to make them put the
original socket input stream into the exchange.
{{http4}}: Everything happens in
org.apache.camel.component.http4.HttpProducer::process() -
populateResponse(..) - extractResponseBody(..) -
doExtractResponseBodyAsStream(); here the original stream is copied into an
instance of CachedOutputStream, backed by a byte-array.
{{Jetty}}: org.eclipse.jetty.client.AsyncHttpConnection::handle() -
org.eclipse.jetty.http.HttpParser::parseNext() will fill a byte-array in
org.eclipse.jetty.client.ContentExchange which is a CachedExchange which is a
HttpExchange.
{{netty-http}}: Builds a pipeline that assembles the HttpResponse content as a
composite ChannelBuffer. The wrapped channel buffers make up the complete
response stream.
Use response input stream directly in http producer
---
Key: CAMEL-7638
URL: https://issues.apache.org/jira/browse/CAMEL-7638
Project: Camel
Issue Type: Improvement
Reporter: Willem Jiang
Assignee: Willem Jiang
It could save us lots of the memory and time if the response is a big and
chunked message.
Here are some discussion in the mailing list about it.
http://camel.465427.n5.nabble.com/Stream-only-reverse-proxy-with-minimal-memory-footprint-tp5754424.html
http://camel.465427.n5.nabble.com/Chunking-issue-with-http-producer-td5735075.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7638) Use response input stream directly in http producer
[ https://issues.apache.org/jira/browse/CAMEL-7638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14380217#comment-14380217 ] Ralf Steppacher commented on CAMEL-7638: Is this ticket somewhere on the roadmap? It would be extremely beneficial to my project if this could be implemented. Another thing I noticed in this context: The netty4-http component currently re-calculates the content length of a response if used in a proxy route. And it seems I have no control over the headers, that is I cannot switch to chunked transfer encoding if I massage the response stream contents in a streaming fashion. I came across at least one recent ticket that was about expected content length/transfer encoding headers in proxy setups. Use response input stream directly in http producer --- Key: CAMEL-7638 URL: https://issues.apache.org/jira/browse/CAMEL-7638 Project: Camel Issue Type: Improvement Reporter: Willem Jiang Assignee: Willem Jiang It could save us lots of the memory and time if the response is a big and chunked message. Here are some discussion in the mailing list about it. http://camel.465427.n5.nabble.com/Stream-only-reverse-proxy-with-minimal-memory-footprint-tp5754424.html http://camel.465427.n5.nabble.com/Chunking-issue-with-http-producer-td5735075.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7971) Setting bean reference in restConfiguration fails with IllegalFormatWidthException
Ralf Steppacher created CAMEL-7971:
--
Summary: Setting bean reference in restConfiguration fails with
IllegalFormatWidthException
Key: CAMEL-7971
URL: https://issues.apache.org/jira/browse/CAMEL-7971
Project: Camel
Issue Type: Bug
Components: camel-core, camel-netty4-http
Affects Versions: 2.14.0
Reporter: Ralf Steppacher
I am trying to set a custom HTTP binding on the netty4-http endpoint created
for the REST-DSL routes. The '#' in the bean ref, URL encoded as %23, makes the
endpoint generation fail because it is interpreted by the string formatter.
{code:xml}
restConfiguration component=netty4-http scheme=http host={{rest.host}}
port={{rest.port}} bindingMode=json
endpointProperty key=nettyHttpBinding
value=#noStackTraceHTTPBinding/
/restConfiguration
rest path=/base produces=application/json
get uri=/path
to uri=direct:myroute /
/get
/rest
{code}
This configuration results in the following template string
(NettyHttpComponent.java line 279):
{{netty4-http:%s://%s:%s/%s?httpMethodRestrict=%s?nettyHttpBinding=%23noStackTraceHTTPBinding}}
The main problem is the hash mark encoded as %23 and interpreted by the
string formatter. Also, the second '?' in the URL probably should be a ''.
Full stacktrace:
{code}
java.util.IllegalFormatWidthException: 23
at
java.util.Formatter$FormatSpecifier.checkText(Formatter.java:2996)[:1.7.0_60]
at
java.util.Formatter$FormatSpecifier.init(Formatter.java:2688)[:1.7.0_60]
at java.util.Formatter.parse(Formatter.java:2528)[:1.7.0_60]
at java.util.Formatter.format(Formatter.java:2469)[:1.7.0_60]
at java.util.Formatter.format(Formatter.java:2423)[:1.7.0_60]
at java.lang.String.format(String.java:2790)[:1.7.0_60]
at
org.apache.camel.component.netty4.http.NettyHttpComponent.createConsumer(NettyHttpComponent.java:279)
at
org.apache.camel.component.rest.RestEndpoint.createConsumer(RestEndpoint.java:167)
at
org.apache.camel.impl.EventDrivenConsumerRoute.addServices(EventDrivenConsumerRoute.java:65)
at
org.apache.camel.impl.DefaultRoute.onStartingServices(DefaultRoute.java:80)
at org.apache.camel.impl.RouteService.warmUp(RouteService.java:134)
at
org.apache.camel.impl.DefaultCamelContext.doWarmUpRoutes(DefaultCamelContext.java:2379)
at
org.apache.camel.impl.DefaultCamelContext.safelyStartRouteServices(DefaultCamelContext.java:2309)
at
org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRoutes(DefaultCamelContext.java:2091)
at
org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1951)
at
org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1777)
at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
at
org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1745)
at
org.apache.camel.blueprint.BlueprintCamelContext.start(BlueprintCamelContext.java:177)
at
org.apache.camel.blueprint.BlueprintCamelContext.maybeStart(BlueprintCamelContext.java:209)
at
org.apache.camel.blueprint.BlueprintCamelContext.serviceChanged(BlueprintCamelContext.java:147)
at
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
at
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419)
at org.apache.felix.framework.Felix.registerService(Felix.java:3423)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:452)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:387)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)
at
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:276)
at
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:245)
at
org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:235)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
at
[jira] [Created] (CAMEL-6953) Camel Simple expression ${headers.CamelHttpUrl} contains 'foo' never becomes true
Ralf Steppacher created CAMEL-6953:
--
Summary: Camel Simple expression ${headers.CamelHttpUrl} contains
'foo' never becomes true
Key: CAMEL-6953
URL: https://issues.apache.org/jira/browse/CAMEL-6953
Project: Camel
Issue Type: Bug
Components: camel-core, camel-jetty
Affects Versions: 2.12.1, 2.11.2, 2.10.5
Reporter: Ralf Steppacher
The exchange header CamelHttpUrl is of type StringBuffer and not String. This
causes the simple expression ${headers.CamelHttpUrl} contains 'foo' to always
evaluate to false, because
org.apache.camel.util.ObjectHelper::contains(Object,Object) does not handle
StringBuffer.
Either the header should be of type String or
org.apache.camel.util.ObjectHelper::contains(Object,Object) should deal with
StringBuffer arguments.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CAMEL-6953) Camel Simple expression ${headers.CamelHttpUrl} contains 'foo' never becomes true
[
https://issues.apache.org/jira/browse/CAMEL-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-6953:
---
Attachment: jetty-CamelHttpUrl-context.xml
Camel Simple expression ${headers.CamelHttpUrl} contains 'foo' never
becomes true
---
Key: CAMEL-6953
URL: https://issues.apache.org/jira/browse/CAMEL-6953
Project: Camel
Issue Type: Bug
Components: camel-core, camel-jetty
Affects Versions: 2.10.5, 2.11.2, 2.12.1
Reporter: Ralf Steppacher
Attachments: jetty-CamelHttpUrl-context.xml
The exchange header CamelHttpUrl is of type StringBuffer and not String. This
causes the simple expression ${headers.CamelHttpUrl} contains 'foo' to
always evaluate to false, because
org.apache.camel.util.ObjectHelper::contains(Object,Object) does not handle
StringBuffer.
Either the header should be of type String or
org.apache.camel.util.ObjectHelper::contains(Object,Object) should deal with
StringBuffer arguments.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CAMEL-6953) Camel Simple expression ${headers.CamelHttpUrl} contains 'foo' never becomes true
[
https://issues.apache.org/jira/browse/CAMEL-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13818824#comment-13818824
]
Ralf Steppacher commented on CAMEL-6953:
Starting the attached context and browsing to localhost:9191/headerbug/foo
will result in log output No match in URL.
Camel Simple expression ${headers.CamelHttpUrl} contains 'foo' never
becomes true
---
Key: CAMEL-6953
URL: https://issues.apache.org/jira/browse/CAMEL-6953
Project: Camel
Issue Type: Bug
Components: camel-core, camel-jetty
Affects Versions: 2.10.5, 2.11.2, 2.12.1
Reporter: Ralf Steppacher
Attachments: jetty-CamelHttpUrl-context.xml
The exchange header CamelHttpUrl is of type StringBuffer and not String. This
causes the simple expression ${headers.CamelHttpUrl} contains 'foo' to
always evaluate to false, because
org.apache.camel.util.ObjectHelper::contains(Object,Object) does not handle
StringBuffer.
Either the header should be of type String or
org.apache.camel.util.ObjectHelper::contains(Object,Object) should deal with
StringBuffer arguments.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CAMEL-6953) Simple expression ${headers.CamelHttpUrl} contains 'foo' never becomes true
[
https://issues.apache.org/jira/browse/CAMEL-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-6953:
---
Priority: Minor (was: Major)
Issue Type: Improvement (was: Bug)
Simple expression ${headers.CamelHttpUrl} contains 'foo' never becomes true
-
Key: CAMEL-6953
URL: https://issues.apache.org/jira/browse/CAMEL-6953
Project: Camel
Issue Type: Improvement
Components: camel-core, camel-jetty
Affects Versions: 2.10.5, 2.11.2, 2.12.1
Reporter: Ralf Steppacher
Priority: Minor
Attachments: jetty-CamelHttpUrl-context.xml
The exchange header CamelHttpUrl is of type StringBuffer and not String. This
causes the simple expression ${headers.CamelHttpUrl} contains 'foo' to
always evaluate to false, because
org.apache.camel.util.ObjectHelper::contains(Object,Object) does not handle
StringBuffer.
Either the header should be of type String or
org.apache.camel.util.ObjectHelper::contains(Object,Object) should deal with
StringBuffer arguments.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CAMEL-6953) Simple expression ${headers.CamelHttpUrl} contains 'foo' never becomes true
[
https://issues.apache.org/jira/browse/CAMEL-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CAMEL-6953:
---
Priority: Major (was: Minor)
Issue Type: Bug (was: Improvement)
Simple expression ${headers.CamelHttpUrl} contains 'foo' never becomes true
-
Key: CAMEL-6953
URL: https://issues.apache.org/jira/browse/CAMEL-6953
Project: Camel
Issue Type: Bug
Components: camel-core, camel-jetty
Affects Versions: 2.10.5, 2.11.2, 2.12.1
Reporter: Ralf Steppacher
Attachments: jetty-CamelHttpUrl-context.xml
The exchange header CamelHttpUrl is of type StringBuffer and not String. This
causes the simple expression ${headers.CamelHttpUrl} contains 'foo' to
always evaluate to false, because
org.apache.camel.util.ObjectHelper::contains(Object,Object) does not handle
StringBuffer.
Either the header should be of type String or
org.apache.camel.util.ObjectHelper::contains(Object,Object) should deal with
StringBuffer arguments.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CAMEL-6086) Unmarshal from ActiveMQ yields warning if message has been marshalled before enqueue and contains BigDecimal or BigInteger
[
https://issues.apache.org/jira/browse/CAMEL-6086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13818755#comment-13818755
]
Ralf Steppacher commented on CAMEL-6086:
Christian, I looked at your test context and to me it looks like you should be
able to reproduce the problem with it. Maybe there is a difference between
running the context in the unit test and running it natively that influences
the behavior?
I am able to reproduce the problem with Camel 2.10.5 but not with 2.11.2.
Unmarshal from ActiveMQ yields warning if message has been marshalled before
enqueue and contains BigDecimal or BigInteger
--
Key: CAMEL-6086
URL: https://issues.apache.org/jira/browse/CAMEL-6086
Project: Camel
Issue Type: Bug
Components: camel-activemq
Affects Versions: 2.9.1, 2.10.3
Reporter: Ralf Steppacher
Priority: Minor
Fix For: Future
Using activemq-camel version 5.8.0 and starting with Camel version 2.9.1
unmarshalling from ActiveMQ yields a warning if
- the exchange body is an object containing a java.math.BigInteger or
BigDecimal or
- the exchange body is an object containing a hierarchy of objects, one of
which contains a BigInteger or BigDecimal
and
- the exchange body has been explicitely marshalled using Java serialization
The warning:
WARN ObjectHelper - Cannot find class: [B
Example route config:
camel:route id=writeToQueue
camel:from uri=trigger /
!-- Put bean with BigDecimal or BigInteger into exchange body. --
camel:process ref=myProcessor /
camel:convertBodyTo type=com.rs.TheBean/
camel:marshal ref=javaSerialization /
camel:to ref=queueTo /
/camel:route
camel:route id=receiveFromQueue
!-- Yields warning. --
camel:from uri=queueFrom /
camel:unmarshal ref=javaSerialization /
camel:convertBodyTo type=com.rs.TheBean/
camel:log message=Received message: ${in.body} loggingLevel=INFO
logName=route:receiveFromQueue /
/camel:route
Despite the warning, un-marshalling the message works.
I have not tried other versions of activemq-camel.
ActiveMQ Server is version 5.8.0
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CAMEL-6445) XML DSL - removeHeaders does not work as expected if more then one excludePatter is speficied
[ https://issues.apache.org/jira/browse/CAMEL-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682762#comment-13682762 ] Ralf Steppacher commented on CAMEL-6445: Well, if it is just a documentation bug, even better. Thanks for the clarification. XML DSL - removeHeaders does not work as expected if more then one excludePatter is speficied - Key: CAMEL-6445 URL: https://issues.apache.org/jira/browse/CAMEL-6445 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.10.3 Reporter: Ralf Steppacher Assignee: Christian Müller To reproduce put the following in a route: camel:setHeader headerName=header1 camel:constant1/camel:constant /camel:setHeader camel:setHeader headerName=header2 camel:constant2/camel:constant /camel:setHeader camel:setHeader headerName=header3 camel:constant3/camel:constant /camel:setHeader camel:removeHeaders pattern=* excludePattern=header1,header2 / Expected behavior: header3 should be gone. Actual behavior: All headers are gone. Specifying only one exclude pattern works. I.e. camel:removeHeaders pattern=* excludePattern=header1 / removes headers header2 and header3 but leaves header1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6445) XML DSL - removeHeaders does not work as expected if more then one excludePatter is speficied
Ralf Steppacher created CAMEL-6445: -- Summary: XML DSL - removeHeaders does not work as expected if more then one excludePatter is speficied Key: CAMEL-6445 URL: https://issues.apache.org/jira/browse/CAMEL-6445 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.10.3 Reporter: Ralf Steppacher To reproduce put the following in a route: camel:setHeader headerName=header1 camel:constant1/camel:constant /camel:setHeader camel:setHeader headerName=header2 camel:constant2/camel:constant /camel:setHeader camel:setHeader headerName=header3 camel:constant3/camel:constant /camel:setHeader camel:removeHeaders pattern=* excludePattern=header1,header2 / Expected behavior: header3 should be gone. Actual behavior: All headers are gone. Specifying only one exclude pattern works. I.e. camel:removeHeaders pattern=* excludePattern=header1 / removes headers header2 and header3 but leaves header1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6086) Unmarshal from ActiveMQ yields warning if message has been marshalled before enqueue and contains BigDecimal or BigInteger
[
https://issues.apache.org/jira/browse/CAMEL-6086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13672979#comment-13672979
]
Ralf Steppacher commented on CAMEL-6086:
The problem is reproducible with a bean that implements Serializable and
contains a BigDecimal or BigInteger as its only class member.
Yes, I realized that I do not have to have an explicit serialization step if I
wanted to use object serialization as the wire format. The step was in my
routes because previously I used JAXB serialization so I could look at the
message via the ActiveMQ web frontend.
Unmarshal from ActiveMQ yields warning if message has been marshalled before
enqueue and contains BigDecimal or BigInteger
--
Key: CAMEL-6086
URL: https://issues.apache.org/jira/browse/CAMEL-6086
Project: Camel
Issue Type: Bug
Components: camel-activemq
Affects Versions: 2.9.1, 2.10.3
Reporter: Ralf Steppacher
Priority: Minor
Fix For: Future
Using activemq-camel version 5.8.0 and starting with Camel version 2.9.1
unmarshalling from ActiveMQ yields a warning if
- the exchange body is an object containing a java.math.BigInteger or
BigDecimal or
- the exchange body is an object containing a hierarchy of objects, one of
which contains a BigInteger or BigDecimal
and
- the exchange body has been explicitely marshalled using Java serialization
The warning:
WARN ObjectHelper - Cannot find class: [B
Example route config:
camel:route id=writeToQueue
camel:from uri=trigger /
!-- Put bean with BigDecimal or BigInteger into exchange body. --
camel:process ref=myProcessor /
camel:convertBodyTo type=com.rs.TheBean/
camel:marshal ref=javaSerialization /
camel:to ref=queueTo /
/camel:route
camel:route id=receiveFromQueue
!-- Yields warning. --
camel:from uri=queueFrom /
camel:unmarshal ref=javaSerialization /
camel:convertBodyTo type=com.rs.TheBean/
camel:log message=Received message: ${in.body} loggingLevel=INFO
logName=route:receiveFromQueue /
/camel:route
Despite the warning, un-marshalling the message works.
I have not tried other versions of activemq-camel.
ActiveMQ Server is version 5.8.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6086) Unmarshal from ActiveMQ yields warning if message has been marshalled before enqueue and contains BigDecimal or BigInteger
[
https://issues.apache.org/jira/browse/CAMEL-6086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669068#comment-13669068
]
Ralf Steppacher commented on CAMEL-6086:
All I had in the logs was the warning.
Unmarshal from ActiveMQ yields warning if message has been marshalled before
enqueue and contains BigDecimal or BigInteger
--
Key: CAMEL-6086
URL: https://issues.apache.org/jira/browse/CAMEL-6086
Project: Camel
Issue Type: Bug
Components: camel-activemq
Affects Versions: 2.9.1, 2.10.3
Reporter: Ralf Steppacher
Priority: Minor
Fix For: Future
Using activemq-camel version 5.8.0 and starting with Camel version 2.9.1
unmarshalling from ActiveMQ yields a warning if
- the exchange body is an object containing a java.math.BigInteger or
BigDecimal or
- the exchange body is an object containing a hierarchy of objects, one of
which contains a BigInteger or BigDecimal
and
- the exchange body has been explicitely marshalled using Java serialization
The warning:
WARN ObjectHelper - Cannot find class: [B
Example route config:
camel:route id=writeToQueue
camel:from uri=trigger /
!-- Put bean with BigDecimal or BigInteger into exchange body. --
camel:process ref=myProcessor /
camel:convertBodyTo type=com.rs.TheBean/
camel:marshal ref=javaSerialization /
camel:to ref=queueTo /
/camel:route
camel:route id=receiveFromQueue
!-- Yields warning. --
camel:from uri=queueFrom /
camel:unmarshal ref=javaSerialization /
camel:convertBodyTo type=com.rs.TheBean/
camel:log message=Received message: ${in.body} loggingLevel=INFO
logName=route:receiveFromQueue /
/camel:route
Despite the warning, un-marshalling the message works.
I have not tried other versions of activemq-camel.
ActiveMQ Server is version 5.8.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6086) Unmarshal from ActiveMQ yields warning if message has been marshalled before enqueue and contains BigDecimal or BigInteger
Ralf Steppacher created CAMEL-6086:
--
Summary: Unmarshal from ActiveMQ yields warning if message has
been marshalled before enqueue and contains BigDecimal or BigInteger
Key: CAMEL-6086
URL: https://issues.apache.org/jira/browse/CAMEL-6086
Project: Camel
Issue Type: Bug
Components: camel-activemq
Affects Versions: 2.10.3, 2.9.1
Reporter: Ralf Steppacher
Using activemq-camel version 5.8.0 and starting with Camel version 2.9.1
unmarshalling from ActiveMQ yields a warning if
- the exchange body is an object containing a java.math.BigInteger or
BigDecimal or
- the exchange body is an object containing a hierarchy of objects, one of
which contains a BigInteger or BigDecimal
and
- the exchange body has been explicitely marshalled using Java serialization
The warning:
WARN ObjectHelper - Cannot find class: [B
Example route config:
camel:route id=writeToQueue
camel:from uri=trigger /
!-- Put bean with BigDecimal or BigInteger into exchange body. --
camel:process ref=myProcessor /
camel:convertBodyTo type=com.rs.TheBean/
camel:marshal ref=javaSerialization /
camel:to ref=queueTo /
/camel:route
camel:route id=receiveFromQueue
!-- Yields warning. --
camel:from uri=queueFrom /
camel:unmarshal ref=javaSerialization /
camel:convertBodyTo type=com.rs.TheBean/
camel:log message=Received message: ${in.body} loggingLevel=INFO
logName=route:receiveFromQueue /
/camel:route
Despite the warning, un-marshalling the message works.
I have not tried other versions of activemq-camel.
ActiveMQ Server is version 5.8.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-5978) Enhancement of BridgePropertyPlaceholderConfigurer
Ralf Steppacher created CAMEL-5978: -- Summary: Enhancement of BridgePropertyPlaceholderConfigurer Key: CAMEL-5978 URL: https://issues.apache.org/jira/browse/CAMEL-5978 Project: Camel Issue Type: Improvement Components: camel-spring Reporter: Ralf Steppacher Priority: Minor Camel 2.10 introduced the BridgePropertyPlaceholderConfigurer bean as a replacement of the Spring context:property-placeholder. The latter - may ignore missing property files (ignore-resource-not-found=true) - falls back to system properties if a requested property could not be found in the (potentially non-existent) properties file. This functionality is not available in the BridgePropertyPlaceholderConfigurer. It would be great if it could be added. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
