[jira] [Comment Edited] (CAMEL-12510) Camel servlet component throw "IOException: Stream closed" during route processing for HTTP get request with custom processor
[
https://issues.apache.org/jira/browse/CAMEL-12510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476936#comment-16476936
]
Thomas Papke edited comment on CAMEL-12510 at 5/16/18 7:06 AM:
---
If I rewrite the code (where the "Stream closed" issue occure) from:
{code}
@Override
public void configure() throws Exception {
from(format("servlet://%s?httpMethodRestrict=GET=%s",
RETRIEVE_PATH, servletName))
.process((exchange) -> {
exchange.getOut().setHeader(Exchange.HTTP_URI,
"https://some.external.system/;);
}).to("http4://oldhost");
}
{code}
to your suggestion:
{code}
@Override
public void configure() throws Exception {
from(format("servlet://%s?httpMethodRestrict=GET=%s",
RETRIEVE_PATH, servletName))
.process((exchange) -> {
Message msg = exchange.getMessage();
msg.setHeader(Exchange.HTTP_URI,
"https://some.external.system/;);
}).to("http4://oldhost");
}
{code}
the behavior also change (so no longer occurs).
But isn't the first example setting the out header also a valid approach?
was (Author: thopap):
If I rewrite the code (where the "Stream closed" issue occure) from:
{code}
@Override
public void configure() throws Exception {
from(format("servlet://%s?httpMethodRestrict=GET=%s",
RETRIEVE_PATH, servletName))
.process((exchange) -> {
exchange.getOut().setHeader(Exchange.HTTP_URI,
"https://some.external.system/;);
}).to("http4://oldhost");
}
{code}
to your suggestion:
{code}
@Override
public void configure() throws Exception {
from(format("servlet://%s?httpMethodRestrict=GET=%s",
RETRIEVE_PATH, servletName))
.process((exchange) -> {
Message msg = exchange.getMessage();
msg.setHeader(Exchange.HTTP_URI,
"https://some.external.system/;);
}).to("http4://oldhost");
}
{code}
the behavior also change.
But isn't the first example setting the out header also a valid approach?
> Camel servlet component throw "IOException: Stream closed" during route
> processing for HTTP get request with custom processor
> -
>
> Key: CAMEL-12510
> URL: https://issues.apache.org/jira/browse/CAMEL-12510
> Project: Camel
> Issue Type: Bug
> Components: camel-servlet
>Affects Versions: 2.21.0
>Reporter: Thomas Papke
>Priority: Major
>
> If i just build a simple Route like this to proxy a incoming Get request to
> external host:
> {code:java}
> @Override
> public void configure() throws Exception {
> from(format("servlet://%s?httpMethodRestrict=GET=%s",
> RETRIEVE_PATH, servletName))
> .process((exchange) -> {
> exchange.getOut().setHeader(Exchange.HTTP_URI,
> "https://some.external.system/;);
> }).to("https4:something");
> }
> {code}
> The following exception is thrown:
> {code:java}
> org.apache.camel.RuntimeCamelException: java.io.IOException: Stream closed
> at
> org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:80)
> at org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:54)
> at
> org.apache.camel.processor.DefaultExchangeFormatter.getBodyTypeAsString(DefaultExchangeFormatter.java:468)
> at
> org.apache.camel.processor.DefaultExchangeFormatter.format(DefaultExchangeFormatter.java:126)
> at
> org.apache.camel.processor.CamelLogProcessor.process(CamelLogProcessor.java:88)
> at
> org.apache.camel.component.log.LogProducer.process(LogProducer.java:40)
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:97)
> at
> org.apache.camel.http.common.CamelServlet.doService(CamelServlet.java:208)
> at
> org.apache.camel.http.common.CamelServlet.service(CamelServlet.java:78)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
> at
>
[jira] [Commented] (CAMEL-12510) Camel servlet component throw "IOException: Stream closed" during route processing for HTTP get request with custom processor
[
https://issues.apache.org/jira/browse/CAMEL-12510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476936#comment-16476936
]
Thomas Papke commented on CAMEL-12510:
--
If I rewrite the code (where the "Stream closed" issue occure) from:
{code}
@Override
public void configure() throws Exception {
from(format("servlet://%s?httpMethodRestrict=GET=%s",
RETRIEVE_PATH, servletName))
.process((exchange) -> {
exchange.getOut().setHeader(Exchange.HTTP_URI,
"https://some.external.system/;);
}).to("http4://oldhost");
}
{code}
to your suggestion:
{code}
@Override
public void configure() throws Exception {
from(format("servlet://%s?httpMethodRestrict=GET=%s",
RETRIEVE_PATH, servletName))
.process((exchange) -> {
Message msg = exchange.getMessage();
msg.setHeader(Exchange.HTTP_URI,
"https://some.external.system/;);
}).to("http4://oldhost");
}
{code}
the behavior also change.
But isn't the first example setting the out header also a valid approach?
> Camel servlet component throw "IOException: Stream closed" during route
> processing for HTTP get request with custom processor
> -
>
> Key: CAMEL-12510
> URL: https://issues.apache.org/jira/browse/CAMEL-12510
> Project: Camel
> Issue Type: Bug
> Components: camel-servlet
>Affects Versions: 2.21.0
>Reporter: Thomas Papke
>Priority: Major
>
> If i just build a simple Route like this to proxy a incoming Get request to
> external host:
> {code:java}
> @Override
> public void configure() throws Exception {
> from(format("servlet://%s?httpMethodRestrict=GET=%s",
> RETRIEVE_PATH, servletName))
> .process((exchange) -> {
> exchange.getOut().setHeader(Exchange.HTTP_URI,
> "https://some.external.system/;);
> }).to("https4:something");
> }
> {code}
> The following exception is thrown:
> {code:java}
> org.apache.camel.RuntimeCamelException: java.io.IOException: Stream closed
> at
> org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:80)
> at org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:54)
> at
> org.apache.camel.processor.DefaultExchangeFormatter.getBodyTypeAsString(DefaultExchangeFormatter.java:468)
> at
> org.apache.camel.processor.DefaultExchangeFormatter.format(DefaultExchangeFormatter.java:126)
> at
> org.apache.camel.processor.CamelLogProcessor.process(CamelLogProcessor.java:88)
> at
> org.apache.camel.component.log.LogProducer.process(LogProducer.java:40)
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:97)
> at
> org.apache.camel.http.common.CamelServlet.doService(CamelServlet.java:208)
> at
> org.apache.camel.http.common.CamelServlet.service(CamelServlet.java:78)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.springframework.boot.actuate.trace.WebRequestTraceFilter.doFilterInternal(WebRequestTraceFilter.java:110)
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
> at
>
[jira] [Updated] (CAMEL-12510) Camel servlet component throw "IOException: Stream closed" during route processing for HTTP get request with custom processor
[
https://issues.apache.org/jira/browse/CAMEL-12510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Papke updated CAMEL-12510:
-
Description:
If i just build a simple Route like this to proxy a incoming Get request to
external host:
{code:java}
@Override
public void configure() throws Exception {
from(format("servlet://%s?httpMethodRestrict=GET=%s",
RETRIEVE_PATH, servletName))
.process((exchange) -> {
exchange.getOut().setHeader(Exchange.HTTP_URI,
"https://some.external.system/;);
}).to("https4:something");
}
{code}
The following exception is thrown:
{code:java}
org.apache.camel.RuntimeCamelException: java.io.IOException: Stream closed
at
org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:80)
at org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:54)
at
org.apache.camel.processor.DefaultExchangeFormatter.getBodyTypeAsString(DefaultExchangeFormatter.java:468)
at
org.apache.camel.processor.DefaultExchangeFormatter.format(DefaultExchangeFormatter.java:126)
at
org.apache.camel.processor.CamelLogProcessor.process(CamelLogProcessor.java:88)
at
org.apache.camel.component.log.LogProducer.process(LogProducer.java:40)
at
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:97)
at
org.apache.camel.http.common.CamelServlet.doService(CamelServlet.java:208)
at
org.apache.camel.http.common.CamelServlet.service(CamelServlet.java:78)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.springframework.boot.actuate.trace.WebRequestTraceFilter.doFilterInternal(WebRequestTraceFilter.java:110)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.springframework.web.filter.HttpPutFormContentFilter.doFilterInternal(HttpPutFormContentFilter.java:108)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:81)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:197)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
[jira] [Updated] (CAMEL-12510) Camel servlet component throw "IOException: Stream closed" during route processing for HTTP get request with custom processor
[
https://issues.apache.org/jira/browse/CAMEL-12510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Papke updated CAMEL-12510:
-
Summary: Camel servlet component throw "IOException: Stream closed" during
route processing for HTTP get request with custom processor (was: Camel
servlet component throw "IOException: Stream closed" during route processing)
> Camel servlet component throw "IOException: Stream closed" during route
> processing for HTTP get request with custom processor
> -
>
> Key: CAMEL-12510
> URL: https://issues.apache.org/jira/browse/CAMEL-12510
> Project: Camel
> Issue Type: Bug
> Components: camel-servlet
>Affects Versions: 2.21.0
>Reporter: Thomas Papke
>Priority: Major
>
> If i just build a simple Route like this to proxy a incoming Get request to
> external host:
> {code:java}
> @Override
> public void configure() throws Exception {
> from(format("servlet://%s?httpMethodRestrict=GET=%s",
> RETRIEVE_PATH, servletName))
> .process((exchange) -> {
> exchange.getOut().setHeader(Exchange.HTTP_URI,
> "https://some.external.system/;);
> }).to("https4:something");
> }
> {code}
> The following exception is thrown:
> {code:java}
> org.apache.camel.RuntimeCamelException: java.io.IOException: Stream closed
> at
> org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:80)
> at org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:54)
> at
> org.apache.camel.processor.DefaultExchangeFormatter.getBodyTypeAsString(DefaultExchangeFormatter.java:468)
> at
> org.apache.camel.processor.DefaultExchangeFormatter.format(DefaultExchangeFormatter.java:126)
> at
> org.apache.camel.processor.CamelLogProcessor.process(CamelLogProcessor.java:88)
> at
> org.apache.camel.component.log.LogProducer.process(LogProducer.java:40)
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:97)
> at
> org.apache.camel.http.common.CamelServlet.doService(CamelServlet.java:208)
> at
> org.apache.camel.http.common.CamelServlet.service(CamelServlet.java:78)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.springframework.boot.actuate.trace.WebRequestTraceFilter.doFilterInternal(WebRequestTraceFilter.java:110)
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.springframework.web.filter.HttpPutFormContentFilter.doFilterInternal(HttpPutFormContentFilter.java:108)
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
>
[jira] [Created] (CAMEL-12510) Camel servlet component throw "IOException: Stream closed" during route processing
Thomas Papke created CAMEL-12510:
Summary: Camel servlet component throw "IOException: Stream
closed" during route processing
Key: CAMEL-12510
URL: https://issues.apache.org/jira/browse/CAMEL-12510
Project: Camel
Issue Type: Bug
Components: camel-servlet
Affects Versions: 2.21.0
Reporter: Thomas Papke
If i just build a simple Route like this to proxy a incoming Get request to
external host:
{code:java}
@Override
public void configure() throws Exception {
from(format("servlet://%s?httpMethodRestrict=GET=%s",
RETRIEVE_PATH, servletName))
.process((exchange) -> {
exchange.getOut().setHeader(Exchange.HTTP_URI,
"https://some.external.system/;);
}).to("https4:something");
}
{code}
The following exception is thrown:
{code:java}
org.apache.camel.RuntimeCamelException: java.io.IOException: Stream closed
at
org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:80)
at org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:54)
at
org.apache.camel.processor.DefaultExchangeFormatter.getBodyTypeAsString(DefaultExchangeFormatter.java:468)
at
org.apache.camel.processor.DefaultExchangeFormatter.format(DefaultExchangeFormatter.java:126)
at
org.apache.camel.processor.CamelLogProcessor.process(CamelLogProcessor.java:88)
at
org.apache.camel.component.log.LogProducer.process(LogProducer.java:40)
at
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:97)
at
org.apache.camel.http.common.CamelServlet.doService(CamelServlet.java:208)
at
org.apache.camel.http.common.CamelServlet.service(CamelServlet.java:78)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.springframework.boot.actuate.trace.WebRequestTraceFilter.doFilterInternal(WebRequestTraceFilter.java:110)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.springframework.web.filter.HttpPutFormContentFilter.doFilterInternal(HttpPutFormContentFilter.java:108)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:81)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:197)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at
[jira] [Commented] (CAMEL-12021) ProducerTemplate.requestBody with responseType throw a InvalidPayloadException instead of original exception (wrapped in a CamelExecutionException)
[
https://issues.apache.org/jira/browse/CAMEL-12021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16263931#comment-16263931
]
Thomas Papke commented on CAMEL-12021:
--
Looks good, thank you for providing a fix.
[~davsclaus]:
Just for my understanding: The ConvertBodyProcessor where you have done the
fix, looks the same in Camel 2.19 and 2.20. Why is the behavior different in
both releases? Which change or fix in 2.20 has broken the behavior?
> ProducerTemplate.requestBody with responseType throw a
> InvalidPayloadException instead of original exception (wrapped in a
> CamelExecutionException)
> ---
>
> Key: CAMEL-12021
> URL: https://issues.apache.org/jira/browse/CAMEL-12021
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.1
>Reporter: Thomas Papke
>Assignee: Claus Ibsen
> Fix For: 2.20.2, 2.21.0
>
> Attachments: camel-issue.patch
>
>
> I try to upgrade from camel 2.19.3 to camel 2.20.1 and the behavior of
> {{org.apache.camel.ProducerTemplate.requestBody(String, Object, Class)}}
> seems to be broken in case of exceptions.
> From the API the exception behavior is documented as "CamelExecutionException
> if the processing of the exchange failed"
> --> in camel 2.19 it works without any issues
> --> since camel 2.20.1 the underlying exception is lost and instead a
> InvalidPayloadException is thrown.
> A first analyze looks like the internal camel processing in 2.20 try to
> convert the exchange in body to the given response type. But i don't think
> this is make sense in case of a exception. Using the requestBody without the
> response type work correctly - here the unterlying exception is correctly
> propagated back as a wrapped CamelExecutionException.
> I was not able to find the root cause, so I could not provide a patch here -
> but I have attached a junit test to reproduce the issue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CAMEL-12021) ProducerTemplate.requestBody with responseType throw a InvalidPayloadException instead of original exception (wrapped in a CamelExecutionException)
[
https://issues.apache.org/jira/browse/CAMEL-12021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Papke updated CAMEL-12021:
-
Summary: ProducerTemplate.requestBody with responseType throw a
InvalidPayloadException instead of original exception (wrapped in a
CamelExecutionException) (was: RequestBody with responseType throw a
InvalidPayloadException instead of original exception (wrapped in a
CamelExecutionException))
> ProducerTemplate.requestBody with responseType throw a
> InvalidPayloadException instead of original exception (wrapped in a
> CamelExecutionException)
> ---
>
> Key: CAMEL-12021
> URL: https://issues.apache.org/jira/browse/CAMEL-12021
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.1
>Reporter: Thomas Papke
> Attachments: camel-issue.patch
>
>
> I try to upgrade from camel 2.19.3 to camel 2.20.1 and the behavior of
> {{org.apache.camel.ProducerTemplate.requestBody(String, Object, Class)}}
> seems to be broken in case of exceptions.
> From the API the exception behavior is documented as "CamelExecutionException
> if the processing of the exchange failed"
> --> in camel 2.19 it works without any issues
> --> since camel 2.20.1 the underlying exception is lost and instead a
> InvalidPayloadException is thrown.
> A first analyze looks like the internal camel processing in 2.20 try to
> convert the exchange in body to the given response type. But i don't think
> this is make sense in case of a exception. Using the requestBody without the
> response type work correctly - here the unterlying exception is correctly
> propagated back as a wrapped CamelExecutionException.
> I was not able to find the root cause, so I could not provide a patch here -
> but I have attached a junit test to reproduce the issue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CAMEL-12021) RequestBody with responseType throw a InvalidPayloadException instead of original exception
[
https://issues.apache.org/jira/browse/CAMEL-12021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Papke updated CAMEL-12021:
-
Description:
I try to upgrade from camel 2.19.3 to camel 2.20.1 and the behavior of
{{org.apache.camel.ProducerTemplate.requestBody(String, Object, Class)}}
seems to be broken in case of exceptions.
>From the API the exception behavior is documented as "CamelExecutionException
>if the processing of the exchange failed"
--> in camel 2.19 it works without any issues
--> since camel 2.20.1 the underlying exception is lost and instead a
InvalidPayloadException is thrown.
A first analyze looks like the internal camel processing in 2.20 try to convert
the exchange in body to the given response type. But i don't think this is make
sense in case of a exception. Using the requestBody without the response type
work correctly - here the unterlying exception is correctly propagated back as
a wrapped CamelExecutionException.
I was not able to find the root cause, so I could not provide a patch here -
but I have attached a junit test to reproduce the issue.
was:
I try to upgrade from camel 2.19.3 to camel 2.20.1 and the behavior of
{{org.apache.camel.ProducerTemplate.requestBody(String, Object, Class)}}
seems to be broken in case of exceptions.
>From the API the exception behavior is documented as "CamelExecutionException
>if the processing of the exchange failed"
--> in camel 2.19 it works without any issues
--> since camel 2.20.1 the underlying exception is lost and instead a
InvalidPayloadException is thrown.
A first analyze looks like the internal camel processing in 2.20 try to convert
the exchange in body to the given response type. But i don't think this is make
sense in case of a exception.
I was not able to find the root cause, so I could not provide a patch here -
but I have attached a junit test to reproduce the issue.
> RequestBody with responseType throw a InvalidPayloadException instead of
> original exception
> ---
>
> Key: CAMEL-12021
> URL: https://issues.apache.org/jira/browse/CAMEL-12021
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.1
>Reporter: Thomas Papke
> Attachments: camel-issue.patch
>
>
> I try to upgrade from camel 2.19.3 to camel 2.20.1 and the behavior of
> {{org.apache.camel.ProducerTemplate.requestBody(String, Object, Class)}}
> seems to be broken in case of exceptions.
> From the API the exception behavior is documented as "CamelExecutionException
> if the processing of the exchange failed"
> --> in camel 2.19 it works without any issues
> --> since camel 2.20.1 the underlying exception is lost and instead a
> InvalidPayloadException is thrown.
> A first analyze looks like the internal camel processing in 2.20 try to
> convert the exchange in body to the given response type. But i don't think
> this is make sense in case of a exception. Using the requestBody without the
> response type work correctly - here the unterlying exception is correctly
> propagated back as a wrapped CamelExecutionException.
> I was not able to find the root cause, so I could not provide a patch here -
> but I have attached a junit test to reproduce the issue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CAMEL-12021) RequestBody with responseType throw a InvalidPayloadException instead of original exception
[
https://issues.apache.org/jira/browse/CAMEL-12021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Papke updated CAMEL-12021:
-
Description:
I try to upgrade from camel 2.19.3 to camel 2.20.1 and the behavior of
{{org.apache.camel.ProducerTemplate.requestBody(String, Object, Class)}}
seems to be broken in case of exceptions.
>From the API the exception behavior is documented as "CamelExecutionException
>if the processing of the exchange failed"
--> in camel 2.19 it works without any issues
--> since camel 2.20.1 the underlying exception is lost and instead a
InvalidPayloadException is thrown.
A first analyze looks like the internal camel processing in 2.20 try to convert
the exchange in body to the given response type. But i don't think this is make
sense in case of a exception.
I was not able to find the root cause, so I could not provide a patch here -
but I have attached a junit test to reproduce the issue.
was:
I try to upgrade from camel 2.19.3 to camel 2.20.1 and the behavior of
{{org.apache.camel.ProducerTemplate.requestBody(String, Object, Class)}}
seems to be broken in case of exceptions.
>From the API the exception behavior is documented as "CamelExecutionException
>if the processing of the exchange failed"
--> in camel 2.19 it works without any issues
--> since camel 2.20.1 the underlying exception is lost and instead a
InvalidPayloadException is thrown.
A first analyze looks like the internal camel processing in 2.20 try to convert
the exchange in body to the given response type. But i don't think this is make
sense in case of a exception.
> RequestBody with responseType throw a InvalidPayloadException instead of
> original exception
> ---
>
> Key: CAMEL-12021
> URL: https://issues.apache.org/jira/browse/CAMEL-12021
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.1
>Reporter: Thomas Papke
> Attachments: camel-issue.patch
>
>
> I try to upgrade from camel 2.19.3 to camel 2.20.1 and the behavior of
> {{org.apache.camel.ProducerTemplate.requestBody(String, Object, Class)}}
> seems to be broken in case of exceptions.
> From the API the exception behavior is documented as "CamelExecutionException
> if the processing of the exchange failed"
> --> in camel 2.19 it works without any issues
> --> since camel 2.20.1 the underlying exception is lost and instead a
> InvalidPayloadException is thrown.
> A first analyze looks like the internal camel processing in 2.20 try to
> convert the exchange in body to the given response type. But i don't think
> this is make sense in case of a exception.
> I was not able to find the root cause, so I could not provide a patch here -
> but I have attached a junit test to reproduce the issue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CAMEL-12021) RequestBody with responseType throw a InvalidPayloadException instead of original exception
[
https://issues.apache.org/jira/browse/CAMEL-12021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Papke updated CAMEL-12021:
-
Attachment: camel-issue.patch
Attaching a patch containing a Junit test for showing the issue
(DefaultProducerTemplateTest.testExceptionOnRequestBodyWithResponseType)
> RequestBody with responseType throw a InvalidPayloadException instead of
> original exception
> ---
>
> Key: CAMEL-12021
> URL: https://issues.apache.org/jira/browse/CAMEL-12021
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.1
>Reporter: Thomas Papke
> Attachments: camel-issue.patch
>
>
> I try to upgrade from camel 2.19.3 to camel 2.20.1 and the behavior of
> {{org.apache.camel.ProducerTemplate.requestBody(String, Object, Class)}}
> seems to be broken in case of exceptions.
> From the API the exception behavior is documented as "CamelExecutionException
> if the processing of the exchange failed"
> --> in camel 2.19 it works without any issues
> --> since camel 2.20.1 the underlying exception is lost and instead a
> InvalidPayloadException is thrown.
> A first analyze looks like the internal camel processing in 2.20 try to
> convert the exchange in body to the given response type. But i don't think
> this is make sense in case of a exception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CAMEL-12021) RequestBody with responseType throw a InvalidPayloadException instead of original exception
Thomas Papke created CAMEL-12021:
Summary: RequestBody with responseType throw a
InvalidPayloadException instead of original exception
Key: CAMEL-12021
URL: https://issues.apache.org/jira/browse/CAMEL-12021
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.20.1
Reporter: Thomas Papke
I try to upgrade from camel 2.19.3 to camel 2.20.1 and the behavior of
{{org.apache.camel.ProducerTemplate.requestBody(String, Object, Class)}}
seems to be broken in case of exceptions.
>From the API the exception behavior is documented as "CamelExecutionException
>if the processing of the exchange failed"
--> in camel 2.19 it works without any issues
--> since camel 2.20.1 the underlying exception is lost and instead a
InvalidPayloadException is thrown.
A first analyze looks like the internal camel processing in 2.20 try to convert
the exchange in body to the given response type. But i don't think this is make
sense in case of a exception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (CAMEL-11948) NPE on DefaultMessage setBody if deprecated constructor was used
[
https://issues.apache.org/jira/browse/CAMEL-11948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Papke closed CAMEL-11948.
Thanks for commit and merge to branch.
> NPE on DefaultMessage setBody if deprecated constructor was used
>
>
> Key: CAMEL-11948
> URL: https://issues.apache.org/jira/browse/CAMEL-11948
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Affects Versions: 2.20.0
>Reporter: Thomas Papke
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.20.1, 2.21.0
>
>
> After upgrade camel 2.20.0, some operations fail with a NullPointerException:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.camel.impl.MessageSupport.setBody(MessageSupport.java:122)
> {code}
> The issue seems to be introduced with the change CAMEL-11380.
> The issue could be easily reproduced by using the deprecated constructor,
> where no camelContext is set:
> {code}
> Message message = new DefaultMessage();
> message.setBody("something");
> {code}
> To remain better backward compatibility, i would suggest a nullcheck in the
> setBody for cases where the CamelContext is not set.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CAMEL-11948) NPE on DefaultMessage setBody if deprecated constructor was used
Thomas Papke created CAMEL-11948:
Summary: NPE on DefaultMessage setBody if deprecated constructor
was used
Key: CAMEL-11948
URL: https://issues.apache.org/jira/browse/CAMEL-11948
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.20.0
Reporter: Thomas Papke
After upgrade camel 2.20.0, some operations fail with a NullPointerException:
{code}
Caused by: java.lang.NullPointerException
at org.apache.camel.impl.MessageSupport.setBody(MessageSupport.java:122)
{code}
The issue seems to be introduced with the change CAMEL-11380.
The issue could be easily reproduced by using the deprecated constructor, where
no camelContext is set:
{code}
Message message = new DefaultMessage();
message.setBody("something");
{code}
To remain better backward compatibility, i would suggest a nullcheck in the
setBody for cases where the CamelContext is not set.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-10756) Mina2 Producer "hang" until timeout if the response message could not be decoded
[
https://issues.apache.org/jira/browse/CAMEL-10756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15854171#comment-15854171
]
Thomas Papke commented on CAMEL-10756:
--
Just my two cents on this: I think closing the session in an mina internal
error would make sense. E.g. If Mina receive UDP packages and of them is
causing an session exception, further processing might make no sense. From my
understandning the "disconnect" flag is intended in case i want to stop the
session after valid processing the request.
I have prepared a proposal which fix the test and switch back to a basic close
connection behavior as suggested by Arno:
https://github.com/Thopap/camel/commit/16d1f57640752d8c5a8fcace1299decc50176c46
> Mina2 Producer "hang" until timeout if the response message could not be
> decoded
>
>
> Key: CAMEL-10756
> URL: https://issues.apache.org/jira/browse/CAMEL-10756
> Project: Camel
> Issue Type: Bug
> Components: camel-mina2
>Affects Versions: 2.18.1
>Reporter: Thomas Papke
> Attachments: camel_mina2.patch
>
>
> I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
> camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
> *The scenario which fail:*
> A Mina2 producer send a request to a server, the server provide a response
> which could not be interpreted/decoded by a custom codec on the producer side
> (e.g. due to invalid encoding).
> *Expected behavior:*
> * The Exception from the decoder on the producer side will be directly
> propogated to the caller. The mina2 session will be closed.
> *Current behavior:*
> * Instead of the exception from the decoder, the producer wait until the
> timeout is reached and the caller get a timeout exception after the timeout
> is reached.
> *First analysis:*
> I have attached a patch for the camel-mina2 module which contain a test
> {{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
> to reproduce this issue.
> *If i revert the changes done within CAMEL-10024, the test run correct.* If I
> debug into the new code, i see that the producer "hang" in
> {{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
> {{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced
> with CAML-10024.
> I could not yet provide a fix as well, since I don't really understand the
> details of CAMEL-10024. But hopefully my testcase helps to fix this issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (CAMEL-10765) Remove unused oauth dependency from camel-cxf pom
Title: Message Title Thomas Papke closed an issue as Fixed Camel / CAMEL-10765 Remove unused oauth dependency from camel-cxf pom Change By: Thomas Papke Estimated Complexity: Unknown Novice Status: Resolved Closed Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
[jira] (CAMEL-10765) Remove unused oauth dependency from camel-cxf pom
Title: Message Title Thomas Papke commented on CAMEL-10765 Re: Remove unused oauth dependency from camel-cxf pom Create a pull request: https://github.com/apache/camel/pull/1428 Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
[jira] (CAMEL-10765) Remove unused oauth dependency from camel-cxf pom
Title: Message Title
Thomas Papke updated an issue
Camel / CAMEL-10765
Remove unused oauth dependency from camel-cxf pom
Change By:
Thomas Papke
I use camel-cxf component, which currently bring some transitive "oauth" jars:{code}[INFO] +- org.apache.camel:camel-cxf:jar:2.18.1:compile[INFO] | \- org.apache.cxf:cxf-rt-rs-security-oauth:jar:3.1.9:compile[INFO] | \- net.oauth.core:oauth-provider:jar:20100527:compile[INFO] |\- net.oauth.core:oauth:jar:20100527:compile{code}I have looked at the camel-cxf documentation and also scan the code of camel-cxf, but here is currently no oauth(1) handling implemented. So I assume this dependency is not correctly defined. I have tried to remove it, but camel-cxf seems to transitive rely on cxf-rt-rs-client.*Proposal for change:** Remove oauth dependency and proper define dependency to cxf-rt-rs-client (since this module compile against org.apache.cxf.jaxrs.client):{code}diff --git a/components/camel-cxf/pom.xml b/components/camel-cxf/pom.xmlindex 5c917bc..0415781 100644--- a/components/camel-cxf/pom.xml+++ b/components/camel-cxf/pom.xml@@ -110,7 +110,7 @@ org.apache.cxf-cxf-rt-rs-security-oauth+cxf-rt-rs-client ${cxf-version} {code}With this patch, camel-cxf module still run successfully.
Add Comment
This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
[jira] (CAMEL-10765) Remove unused oauth dependency from camel-cxf pom
Title: Message Title Thomas Papke created an issue Camel / CAMEL-10765 Remove unused oauth dependency from camel-cxf pom Issue Type: Improvement Affects Versions: 2.18.1 Assignee: Unassigned Components: camel-cxf Created: 30/Jan/17 14:08 Priority: Major Reporter: Thomas Papke I use camel-cxf component, which currently bring some transitive "oauth" jars: [INFO] +- org.apache.camel:camel-cxf:jar:2.18.1:compile [INFO] | \- org.apache.cxf:cxf-rt-rs-security-oauth:jar:3.1.9:compile [INFO] | \- net.oauth.core:oauth-provider:jar:20100527:compile [INFO] |\- net.oauth.core:oauth:jar:20100527:compile I have looked at the camel-cxf documentation and also scan the code of camel-cxf, but here is currently no oauth(1) handling implemented. So I assume this dependency is not correctly defined. I have tried to remove it, but camel-cxf seems to transitive rely on cxf-rt-rs-client. Proposal for change:
[jira] [Updated] (CAMEL-10756) Mina2 Producer "hang" until timeout if the response message could not be decoded
[
https://issues.apache.org/jira/browse/CAMEL-10756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Papke updated CAMEL-10756:
-
Description:
I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
*The scenario which fail:*
A Mina2 producer send a request to a server, the server provide a response
which could not be interpreted/decoded by a custom codec on the producer side
(e.g. due to invalid encoding).
*Expected behavior:*
* The Exception from the decoder on the producer side will be directly
propogated to the caller. The mina2 session will be closed.
*Current behavior:*
* Instead of the exception from the decoder, the producer wait until the
timeout is reached and the caller get a timeout exception after the timeout is
reached.
*First analysis:*
I have attached a patch for the camel-mina2 module which contain a test
{{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
to reproduce this issue.
*If i revert the changes done within CAMEL-10024, the test run correct.* If I
debug into the new code, i see that the producer "hang" in
{{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
{{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced with
CAML-10024.
I could not yet provide a fix as well, since I don't really understand the
details of CAMEL-10024. But hopefully my testcase helps to fix this issue.
was:
I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
*The scenario which fail:*
A Mina2 producer send a request to a server, the server provide a response
which could not be interpreted/decoded by a custom codec on the producer side
(e.g. due to invalid encoding).
*Expected behavior:*
* The Exception from the decoder on the producer side will be directly
propogated to the caller. The mina2 session will be closed.
*Current behavior:*
* Instead of the exception from the decoder, the producer wait until the
timeout is reached and i get a timeout exception.
*First analysis:*
I have attached a patch for the camel-mina2 module which contain a test
{{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
to reproduce this issue.
*If i revert the changes done within CAMEL-10024, the test run correct.* If I
debug into the new code, i see that the producer "hang" in
{{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
{{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced with
CAML-10024.
I could not yet provide a fix as well, since I don't really understand the
details of CAMEL-10024. But hopefully my testcase helps to fix this issue.
> Mina2 Producer "hang" until timeout if the response message could not be
> decoded
>
>
> Key: CAMEL-10756
> URL: https://issues.apache.org/jira/browse/CAMEL-10756
> Project: Camel
> Issue Type: Bug
> Components: camel-mina2
>Affects Versions: 2.18.1
>Reporter: Thomas Papke
> Attachments: camel_mina2.patch
>
>
> I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
> camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
> *The scenario which fail:*
> A Mina2 producer send a request to a server, the server provide a response
> which could not be interpreted/decoded by a custom codec on the producer side
> (e.g. due to invalid encoding).
> *Expected behavior:*
> * The Exception from the decoder on the producer side will be directly
> propogated to the caller. The mina2 session will be closed.
> *Current behavior:*
> * Instead of the exception from the decoder, the producer wait until the
> timeout is reached and the caller get a timeout exception after the timeout
> is reached.
> *First analysis:*
> I have attached a patch for the camel-mina2 module which contain a test
> {{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
> to reproduce this issue.
> *If i revert the changes done within CAMEL-10024, the test run correct.* If I
> debug into the new code, i see that the producer "hang" in
> {{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
> {{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced
> with CAML-10024.
> I could not yet provide a fix as well, since I don't really understand the
> details of CAMEL-10024. But hopefully my testcase helps to fix this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-10756) Mina2 Producer "hang" until timeout if the response message could not be decoded
[
https://issues.apache.org/jira/browse/CAMEL-10756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Papke updated CAMEL-10756:
-
Description:
I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
*The scenario which fail:*
A Mina2 producer send a request to a server, the server provide a response
which could not be interpreted/decoded by a custom codec on the producer side
(e.g. due to invalid encoding).
*Expected behavior:*
* The Exception from the decoder on the producer side will be directly
propogated to the caller. The mina2 session will be closed.
*Current behavior:*
* Instead of the exception from the decoder, the producer wait until the
timeout is reached and i get a timeout exception.
*First analysis:*
I have attached a patch for the camel-mina2 module which contain a test
{{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
to reproduce this issue.
*If i revert the changes done within CAMEL-10024, the test run correct.* If I
debug into the new code, i see that the producer "hang" in
{{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
{{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced with
CAML-10024.
I could not yet provide a fix as well, since I don't really understand the
details of CAMEL-10024. But hopefully my testcase helps to fix this issue.
was:
I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
*The scenario which fail:*
A Mina2 producer send a request to a server, the server provide a response
which could not be interpreted by a custom codec (e.g. due to invalid encoding).
*Expected behavior:*
* The Exception from the decoder on the producer side will be directly
propogated to the caller. The mina2 session will be closed.
*Current behavior:*
* Instead of the exception from the decoder, the producer wait until the
timeout is reached and i get a timeout exception.
*First analysis:*
I have attached a patch for the camel-mina2 module which contain a test
{{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
to reproduce this issue.
*If i revert the changes done within CAMEL-10024, the test run correct.* If I
debug into the new code, i see that the producer "hang" in
{{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
{{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced with
CAML-10024.
I could not yet provide a fix as well, since I don't really understand the
details of CAMEL-10024. But hopefully my testcase helps to fix this issue.
> Mina2 Producer "hang" until timeout if the response message could not be
> decoded
>
>
> Key: CAMEL-10756
> URL: https://issues.apache.org/jira/browse/CAMEL-10756
> Project: Camel
> Issue Type: Bug
> Components: camel-mina2
>Affects Versions: 2.18.1
>Reporter: Thomas Papke
> Attachments: camel_mina2.patch
>
>
> I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
> camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
> *The scenario which fail:*
> A Mina2 producer send a request to a server, the server provide a response
> which could not be interpreted/decoded by a custom codec on the producer side
> (e.g. due to invalid encoding).
> *Expected behavior:*
> * The Exception from the decoder on the producer side will be directly
> propogated to the caller. The mina2 session will be closed.
> *Current behavior:*
> * Instead of the exception from the decoder, the producer wait until the
> timeout is reached and i get a timeout exception.
> *First analysis:*
> I have attached a patch for the camel-mina2 module which contain a test
> {{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
> to reproduce this issue.
> *If i revert the changes done within CAMEL-10024, the test run correct.* If I
> debug into the new code, i see that the producer "hang" in
> {{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
> {{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced
> with CAML-10024.
> I could not yet provide a fix as well, since I don't really understand the
> details of CAMEL-10024. But hopefully my testcase helps to fix this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-10756) Mina2 Producer "hang" until timeout if the response message could not be decoded
[
https://issues.apache.org/jira/browse/CAMEL-10756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Papke updated CAMEL-10756:
-
Flags: (was: Patch)
> Mina2 Producer "hang" until timeout if the response message could not be
> decoded
>
>
> Key: CAMEL-10756
> URL: https://issues.apache.org/jira/browse/CAMEL-10756
> Project: Camel
> Issue Type: Bug
> Components: camel-mina2
>Affects Versions: 2.18.1
>Reporter: Thomas Papke
> Attachments: camel_mina2.patch
>
>
> I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
> camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
> *The scenario which fail:*
> A Mina2 producer send a request to a server, the server provide a response
> which could not be interpreted by a custom codec (e.g. due to invalid
> encoding).
> *Expected behavior:*
> * The Exception from the decoder on the producer side will be directly
> propogated to the caller. The mina2 session will be closed.
> *Current behavior:*
> * Instead of the exception from the decoder, the producer wait until the
> timeout is reached and i get a timeout exception.
> *First analysis:*
> I have attached a patch for the camel-mina2 module which contain a test
> {{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
> to reproduce this issue.
> *If i revert the changes done within CAMEL-10024, the test run correct.* If I
> debug into the new code, i see that the producer "hang" in
> {{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
> {{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced
> with CAML-10024.
> I could not yet provide a fix as well, since I don't really understand the
> details of CAMEL-10024. But hopefully my testcase helps to fix this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-10756) Mina2 Producer "hang" until timeout if the response message could not be decoded
[
https://issues.apache.org/jira/browse/CAMEL-10756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Papke updated CAMEL-10756:
-
Description:
I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
*The scenario which fail:*
A Mina2 producer send a request to a server, the server provide a response
which could not be interpreted by a custom codec (e.g. due to invalid encoding).
*Expected behavior:*
* The Exception from the decoder on the producer side will be directly
propogated to the caller. The mina2 session will be closed.
*Current behavior:*
* Instead of the exception from the decoder, the producer wait until the
timeout is reached and i get a timeout exception.
*First analysis:*
I have attached a patch for the camel-mina2 module which contain a test
{{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
to reproduce this issue.
*If i revert the changes done within CAMEL-10024, the test run correct.* If I
debug into the new code, i see that the producer "hang" in
{{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
{{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced with
CAML-10024.
I could not yet provide a fix as well, since I don't really understand the
details of CAMEL-10024. But hopefully my testcase helps to fix this issue.
was:
I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
*The scenario which fail:*
A Mina2 producer send a request to a server, the server provide a response
which could not be interpreted by a custom coded (e.g. due to invalid encoding).
*Expected behavior:*
* The Exception from the decoder on the producer side will be directly
propogated to the caller. The mina2 session will be closed.
*Current behavior:*
* Instead of the exception from the decoder, the producer wait until the
timeout is reached and i get a timeout exception.
*First analysis:*
I have attached a patch for the camel-mina2 module which contain a test
{{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
to reproduce this issue.
*If i revert the changes done within CAMEL-10024, the test run correct.* If I
debug into the new code, i see that the producer "hang" in
{{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
{{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced with
CAML-10024.
I could not yet provide a fix as well, since I don't really understand the
details of CAMEL-10024. But hopefully my testcase helps to fix this issue.
> Mina2 Producer "hang" until timeout if the response message could not be
> decoded
>
>
> Key: CAMEL-10756
> URL: https://issues.apache.org/jira/browse/CAMEL-10756
> Project: Camel
> Issue Type: Bug
> Components: camel-mina2
>Affects Versions: 2.18.1
>Reporter: Thomas Papke
> Attachments: camel_mina2.patch
>
>
> I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
> camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
> *The scenario which fail:*
> A Mina2 producer send a request to a server, the server provide a response
> which could not be interpreted by a custom codec (e.g. due to invalid
> encoding).
> *Expected behavior:*
> * The Exception from the decoder on the producer side will be directly
> propogated to the caller. The mina2 session will be closed.
> *Current behavior:*
> * Instead of the exception from the decoder, the producer wait until the
> timeout is reached and i get a timeout exception.
> *First analysis:*
> I have attached a patch for the camel-mina2 module which contain a test
> {{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
> to reproduce this issue.
> *If i revert the changes done within CAMEL-10024, the test run correct.* If I
> debug into the new code, i see that the producer "hang" in
> {{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
> {{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced
> with CAML-10024.
> I could not yet provide a fix as well, since I don't really understand the
> details of CAMEL-10024. But hopefully my testcase helps to fix this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-10756) Mina2 Producer "hang" until timeout if the response message could not be decoded
[
https://issues.apache.org/jira/browse/CAMEL-10756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Papke updated CAMEL-10756:
-
Description:
I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
*The scenario which fail:*
A Mina2 producer send a request to a server, the server provide a response
which could not be interpreted by a custom coded (e.g. due to invalid encoding).
*Expected behavior:*
* The Exception from the decoder on the producer side will be directly
propogated to the caller. The mina2 session will be closed.
*Current behavior:*
* Instead of the exception from the decoder, the producer wait until the
timeout is reached and i get a timeout exception.
*First analysis:*
I have attached a patch for the camel-mina2 module which contain a test
{{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
to reproduce this issue.
*If i revert the changes done within CAMEL-10024, the test run correct.* If I
debug into the new code, i see that the producer "hang" in
{{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
{{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced with
CAML-10024.
I could not yet provide a fix as well, since I don't really understand the
details of CAMEL-10024. But hopefully my testcase helps to fix this issue.
was:
I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
The scenario which fail:
A Mina2 producer send a request to a server, the server provide a response
which could not be interpreted by a custom coded (e.g. due to invalid encoding).
*Expected behavior:*
* The Exception from the decoder on the producer side will be directly
propogated to the caller. The mina2 session will be closed.
*Current behavior:*
* Instead of the exception from the decoder, the producer wait until the
timeout is reached and i get a timeout exception.
*First analysis:*
I have attached a patch for the camel-mina2 module which contain a test
{{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
to reproduce this issue.
*If i revert the changes done within CAMEL-10024, the test run correct.* If I
debug into the new code, i see that the producer "hang" in
{{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
{{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced with
CAML-10024.
> Mina2 Producer "hang" until timeout if the response message could not be
> decoded
>
>
> Key: CAMEL-10756
> URL: https://issues.apache.org/jira/browse/CAMEL-10756
> Project: Camel
> Issue Type: Bug
> Components: camel-mina2
>Affects Versions: 2.18.1
>Reporter: Thomas Papke
> Attachments: camel_mina2.patch
>
>
> I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
> camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
> *The scenario which fail:*
> A Mina2 producer send a request to a server, the server provide a response
> which could not be interpreted by a custom coded (e.g. due to invalid
> encoding).
> *Expected behavior:*
> * The Exception from the decoder on the producer side will be directly
> propogated to the caller. The mina2 session will be closed.
> *Current behavior:*
> * Instead of the exception from the decoder, the producer wait until the
> timeout is reached and i get a timeout exception.
> *First analysis:*
> I have attached a patch for the camel-mina2 module which contain a test
> {{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
> to reproduce this issue.
> *If i revert the changes done within CAMEL-10024, the test run correct.* If I
> debug into the new code, i see that the producer "hang" in
> {{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
> {{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced
> with CAML-10024.
> I could not yet provide a fix as well, since I don't really understand the
> details of CAMEL-10024. But hopefully my testcase helps to fix this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-10756) Mina2 Producer "hang" until timeout if the response message could not be decoded
[
https://issues.apache.org/jira/browse/CAMEL-10756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Papke updated CAMEL-10756:
-
Attachment: camel_mina2.patch
> Mina2 Producer "hang" until timeout if the response message could not be
> decoded
>
>
> Key: CAMEL-10756
> URL: https://issues.apache.org/jira/browse/CAMEL-10756
> Project: Camel
> Issue Type: Bug
> Components: camel-mina2
>Affects Versions: 2.18.1
>Reporter: Thomas Papke
> Attachments: camel_mina2.patch
>
>
> I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
> camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
> The scenario which fail:
> A Mina2 producer send a request to a server, the server provide a response
> which could not be interpreted by a custom coded (e.g. due to invalid
> encoding).
> *Expected behavior:*
> * The Exception from the decoder on the producer side will be directly
> propogated to the caller. The mina2 session will be closed.
> *Current behavior:*
> * Instead of the exception from the decoder, the producer wait until the
> timeout is reached and i get a timeout exception.
> *First analysis:*
> I have attached a patch for the camel-mina2 module which contain a test
> {{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
> to reproduce this issue.
> *If i revert the changes done within CAMEL-10024, the test run correct.* If I
> debug into the new code, i see that the producer "hang" in
> {{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
> {{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced
> with CAML-10024.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-10756) Mina2 Producer "hang" until timeout if the response message could not be decoded
Thomas Papke created CAMEL-10756:
Summary: Mina2 Producer "hang" until timeout if the response
message could not be decoded
Key: CAMEL-10756
URL: https://issues.apache.org/jira/browse/CAMEL-10756
Project: Camel
Issue Type: Bug
Components: camel-mina2
Affects Versions: 2.18.1
Reporter: Thomas Papke
I have tried to upgrade from camel 2.16 to 2.18 and run into an issue with
camel-mina2. It looks like CAMEL-10024 has maybe introduced this issue.
The scenario which fail:
A Mina2 producer send a request to a server, the server provide a response
which could not be interpreted by a custom coded (e.g. due to invalid encoding).
*Expected behavior:*
* The Exception from the decoder on the producer side will be directly
propogated to the caller. The mina2 session will be closed.
*Current behavior:*
* Instead of the exception from the decoder, the producer wait until the
timeout is reached and i get a timeout exception.
*First analysis:*
I have attached a patch for the camel-mina2 module which contain a test
{{org.apache.camel.component.mina2.Mina2CustomCodecTest.testProducerFailInDecodingResponse()}}
to reproduce this issue.
*If i revert the changes done within CAMEL-10024, the test run correct.* If I
debug into the new code, i see that the producer "hang" in
{{Mina2Producer.closeSessionIfNeededAndAwaitCloseInHandler(IoSession)}} --
{{closeLatch.await(timeout, TimeUnit.MILLISECONDS);}} which was introduced with
CAML-10024.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9739) Mina2Consumer exception handler do close session also for IOException
[
https://issues.apache.org/jira/browse/CAMEL-9739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Papke updated CAMEL-9739:
Attachment: IoException.patch
> Mina2Consumer exception handler do close session also for IOException
> -
>
> Key: CAMEL-9739
> URL: https://issues.apache.org/jira/browse/CAMEL-9739
> Project: Camel
> Issue Type: Bug
> Components: camel-mina2
>Affects Versions: 2.16.2
>Reporter: Thomas Papke
> Attachments: IoException.patch
>
>
> The camel-mina2 consumer Exception handler
> ({{org.apache.camel.component.mina2.Mina2Consumer.ReceiveHandler.exceptionCaught(IoSession,
> Throwable)}}
> Is an implementation of the Mina2 interface
> {{org.apache.mina.core.service.IoHandler}}. The Javadoc Mina2 documentation
> of exceptionCaught explicitly mention, that Mina2 will close the connection
> for all IOExceptions automatically. But camel-mina2 seems to close the
> connection for any kind of exception.
> *Current behavior:* If an error occurs on the transport layer (e.g. secure
> TCP connection where the certificate was not trusted and a SSLException
> occure), I saw the following warning:
> {code}
> org.apache.camel.component.mina2.Mina2Consumer#exceptionCaught(376) - Closing
> session as an exception was thrown from MINA
> {code}
> And also an error from mina2:
> {code}
> org.apache.mina.filter.ssl.SslHandler#destroy(210) - Unexpected exception
> from SSLEngine.closeInbound().
> " javax.net.ssl.SSLException: Inbound closed before receiving peer's
> close_notify: possible truncation attack?
> {code}
> From a functional perspective, beside the annoying log entries, it looks like
> the SSL error details are sometime not send properly back to the client.
> *Current workaround:* I don’t have one.
> *Suggested bugfix:* Implement the Mina2Consumer exception handling similar to
> {{org.apache.mina.handler.stream.StreamIoHandler.exceptionCaught(IoSession,
> Throwable)}} and do not handle IoException and simply rethrow them. E.g.
> {code}
> if (cause instanceof IOException) {
> LOG.info("IOException will be closed by Mina itself")
> return;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9738) Thread leak for camel-mina2 consumers
[
https://issues.apache.org/jira/browse/CAMEL-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Papke updated CAMEL-9738:
Description:
The camel-mina2 consumer
({{org.apache.camel.component.mina2.Mina2Consumer.doStart()}}) internally start
a Mina2 IoAcceptor ({{org.apache.mina.core.service.IoAcceptor}}), but the
{{org.apache.camel.component.mina2.Mina2Consumer.doStop()}} do not invoke
{{acceptor.dispose(true);}} to release the threadpool started by Mina2.
*Current behavior:* While stopping the web application, the threadpool started
by Mina2 IoAcceptor will not be stopped, so we have several thread which do not
properly shutdown.
*Current workaround:* I create custom CamelShutdownStrategy and collect all
Mina2Consumer and invoke Mina2consumer.getAcceptor.dispose(true); OR as an
alternative create a dedicated consumer and overwrite the stop method of the
Mina2 consumer as seen here:
https://github.com/oehf/ipf/commit/12fdde8df7e7cd9966aadeab3ea3bed8fe75
*Suggested bugfix:* In
{{org.apache.camel.component.mina2.Mina2Consumer.doShutdown()}} call the
IoAcceptor dispose(true) method after unbind from the address.
was:
The camel-mina2 consumer
({{org.apache.camel.component.mina2.Mina2Consumer.doStart()}}) internally start
a Mina2 IoAcceptor ({{org.apache.mina.core.service.IoAcceptor}}), but the
{{org.apache.camel.component.mina2.Mina2Consumer.doStop()}} do not invoke
{{acceptor.dispose(true);}} to release the threadpool started by Mina2.
*Current behavior:* While stopping the web application, the threadpool started
by Mina2 IoAcceptor will not be stopped, so we have several thread which do not
properly shutdown.
*Current workaround:* I create custom CamelShutdownStrategy and collect all
Mina2Consumer and invoke Mina2consumer.getAcceptor.dispose(true); OR as an
alternative create a dedicated consumer and overwrite the stop method of the
Mina2 consumer as seen here:
https://github.com/oehf/ipf/commit/12fdde8df7e7cd9966aadeab3ea3bed8fe75
*Suggested bugfix:* In
{{org.apache.camel.component.mina2.Mina2Consumer.doStop()}} call the IoAcceptor
dispose(true) method after unbind from the address.
> Thread leak for camel-mina2 consumers
> -
>
> Key: CAMEL-9738
> URL: https://issues.apache.org/jira/browse/CAMEL-9738
> Project: Camel
> Issue Type: Bug
> Components: camel-mina2
>Affects Versions: 2.16.2
>Reporter: Thomas Papke
> Attachments: ConsumerDispose.patch
>
>
> The camel-mina2 consumer
> ({{org.apache.camel.component.mina2.Mina2Consumer.doStart()}}) internally
> start a Mina2 IoAcceptor ({{org.apache.mina.core.service.IoAcceptor}}), but
> the {{org.apache.camel.component.mina2.Mina2Consumer.doStop()}} do not invoke
> {{acceptor.dispose(true);}} to release the threadpool started by Mina2.
> *Current behavior:* While stopping the web application, the threadpool
> started by Mina2 IoAcceptor will not be stopped, so we have several thread
> which do not properly shutdown.
> *Current workaround:* I create custom CamelShutdownStrategy and collect all
> Mina2Consumer and invoke Mina2consumer.getAcceptor.dispose(true); OR as an
> alternative create a dedicated consumer and overwrite the stop method of the
> Mina2 consumer as seen here:
> https://github.com/oehf/ipf/commit/12fdde8df7e7cd9966aadeab3ea3bed8fe75
> *Suggested bugfix:* In
> {{org.apache.camel.component.mina2.Mina2Consumer.doShutdown()}} call the
> IoAcceptor dispose(true) method after unbind from the address.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9738) Thread leak for camel-mina2 consumers
[
https://issues.apache.org/jira/browse/CAMEL-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15206228#comment-15206228
]
Thomas Papke commented on CAMEL-9738:
-
I have attached a patch to this issue.
> Thread leak for camel-mina2 consumers
> -
>
> Key: CAMEL-9738
> URL: https://issues.apache.org/jira/browse/CAMEL-9738
> Project: Camel
> Issue Type: Bug
> Components: camel-mina2
>Affects Versions: 2.16.2
>Reporter: Thomas Papke
> Attachments: ConsumerDispose.patch
>
>
> The camel-mina2 consumer
> ({{org.apache.camel.component.mina2.Mina2Consumer.doStart()}}) internally
> start a Mina2 IoAcceptor ({{org.apache.mina.core.service.IoAcceptor}}), but
> the {{org.apache.camel.component.mina2.Mina2Consumer.doStop()}} do not invoke
> {{acceptor.dispose(true);}} to release the threadpool started by Mina2.
> *Current behavior:* While stopping the web application, the threadpool
> started by Mina2 IoAcceptor will not be stopped, so we have several thread
> which do not properly shutdown.
> *Current workaround:* I create custom CamelShutdownStrategy and collect all
> Mina2Consumer and invoke Mina2consumer.getAcceptor.dispose(true); OR as an
> alternative create a dedicated consumer and overwrite the stop method of the
> Mina2 consumer as seen here:
> https://github.com/oehf/ipf/commit/12fdde8df7e7cd9966aadeab3ea3bed8fe75
> *Suggested bugfix:* In
> {{org.apache.camel.component.mina2.Mina2Consumer.doShutdown()}} call the
> IoAcceptor dispose(true) method after unbind from the address.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9738) Thread leak for camel-mina2 consumers
[
https://issues.apache.org/jira/browse/CAMEL-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Papke updated CAMEL-9738:
Attachment: ConsumerDispose.patch
> Thread leak for camel-mina2 consumers
> -
>
> Key: CAMEL-9738
> URL: https://issues.apache.org/jira/browse/CAMEL-9738
> Project: Camel
> Issue Type: Bug
> Components: camel-mina2
>Affects Versions: 2.16.2
>Reporter: Thomas Papke
> Attachments: ConsumerDispose.patch
>
>
> The camel-mina2 consumer
> ({{org.apache.camel.component.mina2.Mina2Consumer.doStart()}}) internally
> start a Mina2 IoAcceptor ({{org.apache.mina.core.service.IoAcceptor}}), but
> the {{org.apache.camel.component.mina2.Mina2Consumer.doStop()}} do not invoke
> {{acceptor.dispose(true);}} to release the threadpool started by Mina2.
> *Current behavior:* While stopping the web application, the threadpool
> started by Mina2 IoAcceptor will not be stopped, so we have several thread
> which do not properly shutdown.
> *Current workaround:* I create custom CamelShutdownStrategy and collect all
> Mina2Consumer and invoke Mina2consumer.getAcceptor.dispose(true); OR as an
> alternative create a dedicated consumer and overwrite the stop method of the
> Mina2 consumer as seen here:
> https://github.com/oehf/ipf/commit/12fdde8df7e7cd9966aadeab3ea3bed8fe75
> *Suggested bugfix:* In
> {{org.apache.camel.component.mina2.Mina2Consumer.doStop()}} call the
> IoAcceptor dispose(true) method after unbind from the address.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9739) Mina2Consumer exception handler do close session also for IOException
Thomas Papke created CAMEL-9739:
---
Summary: Mina2Consumer exception handler do close session also for
IOException
Key: CAMEL-9739
URL: https://issues.apache.org/jira/browse/CAMEL-9739
Project: Camel
Issue Type: Bug
Components: camel-mina2
Affects Versions: 2.16.2
Reporter: Thomas Papke
The camel-mina2 consumer Exception handler
({{org.apache.camel.component.mina2.Mina2Consumer.ReceiveHandler.exceptionCaught(IoSession,
Throwable)}}
Is an implementation of the Mina2 interface
{{org.apache.mina.core.service.IoHandler}}. The Javadoc Mina2 documentation of
exceptionCaught explicitly mention, that Mina2 will close the connection for
all IOExceptions automatically. But camel-mina2 seems to close the connection
for any kind of exception.
*Current behavior:* If an error occurs on the transport layer (e.g. secure TCP
connection where the certificate was not trusted and a SSLException occure), I
saw the following warning:
{code}
org.apache.camel.component.mina2.Mina2Consumer#exceptionCaught(376) - Closing
session as an exception was thrown from MINA
{code}
And also an error from mina2:
{code}
org.apache.mina.filter.ssl.SslHandler#destroy(210) - Unexpected exception from
SSLEngine.closeInbound().
" javax.net.ssl.SSLException: Inbound closed before receiving peer's
close_notify: possible truncation attack?
{code}
>From a functional perspective, beside the annoying log entries, it looks like
>the SSL error details are sometime not send properly back to the client.
*Current workaround:* I don’t have one.
*Suggested bugfix:* Implement the Mina2Consumer exception handling similar to
{{org.apache.mina.handler.stream.StreamIoHandler.exceptionCaught(IoSession,
Throwable)}} and do not handle IoException and simply rethrow them. E.g.
{code}
if (cause instanceof IOException) {
LOG.info("IOException will be closed by Mina itself")
return;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9738) Thread leak for camel-mina2 consumers
Thomas Papke created CAMEL-9738:
---
Summary: Thread leak for camel-mina2 consumers
Key: CAMEL-9738
URL: https://issues.apache.org/jira/browse/CAMEL-9738
Project: Camel
Issue Type: Bug
Components: camel-mina2
Affects Versions: 2.16.2
Reporter: Thomas Papke
The camel-mina2 consumer
({{org.apache.camel.component.mina2.Mina2Consumer.doStart()}}) internally start
a Mina2 IoAcceptor ({{org.apache.mina.core.service.IoAcceptor}}), but the
{{org.apache.camel.component.mina2.Mina2Consumer.doStop()}} do not invoke
{{acceptor.dispose(true);}} to release the threadpool started by Mina2.
*Current behavior:* While stopping the web application, the threadpool started
by Mina2 IoAcceptor will not be stopped, so we have several thread which do not
properly shutdown.
*Current workaround:* I create custom CamelShutdownStrategy and collect all
Mina2Consumer and invoke Mina2consumer.getAcceptor.dispose(true); OR as an
alternative create a dedicated consumer and overwrite the stop method of the
Mina2 consumer as seen here:
https://github.com/oehf/ipf/commit/12fdde8df7e7cd9966aadeab3ea3bed8fe75
*Suggested bugfix:* In
{{org.apache.camel.component.mina2.Mina2Consumer.doStop()}} call the IoAcceptor
dispose(true) method after unbind from the address.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
