[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] [Updated] (CAMEL-5402) Parameter Binding Annotations used for Camel Proxy
[
https://issues.apache.org/jira/browse/CAMEL-5402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-5402:
---
Fix Version/s: (was: Future)
2.16.0
Parameter Binding Annotations used for Camel Proxy
--
Key: CAMEL-5402
URL: https://issues.apache.org/jira/browse/CAMEL-5402
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.9.2
Reporter: Anton Koscejev
Assignee: Claus Ibsen
Priority: Minor
Labels: annotations, bean, binding, parameters, proxy
Fix For: 2.16.0
Parameter Binding Annotations (e.g., @Property, @Header, @Body) could be used
to annotate an interface being proxied by Camel Proxy.
http://camel.apache.org/parameter-binding-annotations.html used for
http://camel.apache.org/using-camelproxy.html
Currently these are used to identify which parameters Camel should provide
when invoking a method of a bean. With the proposed functionality they could
also be used to identify which parameter in the bean invocation map to body,
and which parameters should be used to modify properties/headers. Possibly
bypassing the creation of BeanInvocation object altogether, if @Body is
specified.
Example:
public interface MyListener {
nbsp;nbsp;nbsp;nbsp;void sendBodyWithHeader(@Body String body,
@Header(foo) String headerFoo);
}
And when a Camel Proxy is created, invoking it will result in exchange having
the String body as the OUT message with the header foo set to String
headerFoo.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9066) Include any headers unmarshalled by SoapJaxbDataFormat in content marshalled by the same.
[ https://issues.apache.org/jira/browse/CAMEL-9066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Blackard updated CAMEL-9066: Attachment: (was: attempt_to_create_unit_tests.txt) Include any headers unmarshalled by SoapJaxbDataFormat in content marshalled by the same. - Key: CAMEL-9066 URL: https://issues.apache.org/jira/browse/CAMEL-9066 Project: Camel Issue Type: Improvement Components: camel-soap Affects Versions: 2.12.5, 2.16.0, 2.15.3, 2.14.4, Future, 2.16 Environment: Any Reporter: Bob Blackard Assignee: Willem Jiang Labels: patch Fix For: 2.16.0, 2.15.3, 2.14.4, Future, 2.16 Attachments: camel.patch, soapjaxb-header-marshal-example.zip The current implementation of the Soap11DataFormatAdapter and Soap12DataFormatAdapter will never generate SOAP Headers when a JAXB object is the inputObject. If the unmarshal is done with ignoreUnmarshalledHeaders set to false, then the SoapJaxbDataFormat.SOAP_UNMARSHALLED_HEADER_LIST message header is populated with a list of Objects or JAXBElement?s. However, during the doMarshal, this message header is never referenced. Therefore, the sequence: from(direct:source).unmarshal(fromSoapDataFormat).process(doSomething).marshal(toSoapDataFormat).to(mock:end); will never produce SOAP Headers in the outbound document. The doUnmarshal passes the inputObject and an empty ListJAXBElement? into createContentFromObject. However, is the inputObject is an ordinary JAXB object (or JAXBElement?) then no header content will be created, and since the Exchange isn't sent to createContentFromObject, the SoapJaxbDataFormat.SOAP_UNMARSHALLED_HEADER_LIST cannot be referenced. It seems to me that, if ignoreUnmarshalledHeaders is false, and the SoapJaxbDataFormat.SOAP_UNMARSHALLED_HEADER_LIST is non-empty, and in the event the inbound Exchange does not contain an Exception, then the contents of the SoapJaxbDataFormat.SOAP_UNMARSHALLED_HEADER_LIST should be added to the headerContent before the call to createContentFromObject. I have checked the code for SoapJaxbDataFormat, Soap11DataFormatAdapter and Soap12DataFormatAdapter from camel-soap 2.12.0 through 2.15.2 and it looks like these three classes haven't changed. I crated a demo project and patch, originally against JBoss Fuse 6.1.0, but offer it here for the camel-soap 2.12.x branch. I have also applied and tested the patch against camel-soap in the master branch (2.16-SNAPSHOT). Indeed, it looks like this patch can be applied from any point 2.12 and forward. The demo can be run against 2.12.5 (or any released version - just change the camel.version property in the POM) to demonstrate what I think is the failure. It can also be run against a patched 2.12.6-SNAPSHOT or 2.16-SNAPSHOT (again, just play around with the camel.version property) to demonstrate what I think is correct behavior. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (CAMEL-9066) Include any headers unmarshalled by SoapJaxbDataFormat in content marshalled by the same.
[
https://issues.apache.org/jira/browse/CAMEL-9066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bob Blackard updated CAMEL-9066:
Comment: was deleted
(was: I tried to create unit tests based on my example, but they're not
behaving the same. I'm attaching the patch, but be warned that for reasons I
don't understand yet the unmarshal is producing a Body of type
com.sun.org.apache.xerces.internal.dom.ElementNSImp rather than
com.example.contact.Contact. The log for the three new tests shows:
2015-08-10 14:38:47,582 [main ] INFO Tracer
- ID-blackard-vm-50620-1439231926880-0-2 (route1) from(direct://start) --
unmarshal[org.apache.camel.dataformat.soap.SoapJaxbDataFormat@3c643130]
Pattern:InOnly, Headers:{breadcrumbId=ID-blackard-vm-50620-1439231926880-0-1},
BodyType:java.io.BufferedInputStream, Body:[Body is instance of
java.io.InputStream]
2015-08-10 14:38:47,865 [main ] INFO Tracer
- ID-blackard-vm-50620-1439231926880-0-2 (route1)
unmarshal[org.apache.camel.dataformat.soap.SoapJaxbDataFormat@3c643130] --
marshal[org.apache.camel.dataformat.soap.SoapJaxbDataFormat@3c643130]
Pattern:InOnly, Headers:{breadcrumbId=ID-blackard-vm-50620-1439231926880-0-1,
org.apache.camel.dataformat.soap.UNMARSHALLED_HEADER_LIST=[com.example.soapheaders.Comment@770d8fe9]},
BodyType:com.sun.org.apache.xerces.internal.dom.ElementNSImpl,
Body:cont:Contact xmlns:cont=http://www.example.com/contact;
xmlns:env=http://schemas.xmlsoap.org/soap/envelope/;nameSmith/namenumOrders0/numOrdersrevenue10.0/revenue
/cont:Contact
2015-08-10 14:38:47,865 [main ] ERROR DefaultErrorHandler
- Failed delivery for (MessageId: ID-blackard-vm-50620-1439231926880-0-1 on
ExchangeId: ID-blackard-vm-50620-1439231926880-0-2). Exhausted after delivery
attempt: 1 caught: java.lang.RuntimeException: The type
com.sun.org.apache.xerces.internal.dom.ElementNSImpl needs to have an XmlType
annotation with name
Message History
---
RouteId ProcessorId Processor
Elapsed (ms)
[route1] [route1] [direct://start
] [ 283]
[route1] [unmarshal1]
[unmarshal[org.apache.camel.model.DataFormatDefinition@79f361e5]
] [ 236]
[route1] [marshal1 ]
[marshal[org.apache.camel.model.DataFormatDefinition@59a03fef]
] [47]
Exchange
---
Exchange[###REPLACE_ME### Id
ID-blackard-vm-50620-1439231926880-0-2###REPLACE_ME### ExchangePattern
InOnly###REPLACE_ME### Headers
{breadcrumbId=ID-blackard-vm-50620-1439231926880-0-1, CamelRedelivered=false,
CamelRedeliveryCounter=0,
org.apache.camel.dataformat.soap.UNMARSHALLED_HEADER_LIST=[com.example.soapheaders.Comment@770d8fe9]}###REPLACE_ME###
BodyType
com.sun.org.apache.xerces.internal.dom.ElementNSImpl###REPLACE_ME###
Bodycont:Contact xmlns:cont=http://www.example.com/contact;
xmlns:env=http://schemas.xmlsoap.org/soap/envelope/;nameSmith/namenumOrders0/numOrdersrevenue10.0/revenue
/cont:Contact]
Stacktrace
---
java.lang.RuntimeException: The type
com.sun.org.apache.xerces.internal.dom.ElementNSImpl needs to have an XmlType
annotation with name
at
org.apache.camel.dataformat.soap.name.TypeNameStrategy.findQNameForSoapActionOrType(TypeNameStrategy.java:39)
)
Include any headers unmarshalled by SoapJaxbDataFormat in content marshalled
by the same.
-
Key: CAMEL-9066
URL: https://issues.apache.org/jira/browse/CAMEL-9066
Project: Camel
Issue Type: Improvement
Components: camel-soap
Affects Versions: 2.12.5, 2.16.0, 2.15.3, 2.14.4, Future, 2.16
Environment: Any
Reporter: Bob Blackard
Assignee: Willem Jiang
Labels: patch
Fix For: 2.16.0, 2.15.3, 2.14.4, Future, 2.16
Attachments: camel.patch, soapjaxb-header-marshal-example.zip
The current implementation of the Soap11DataFormatAdapter and
Soap12DataFormatAdapter will never generate SOAP Headers when a JAXB object
is the inputObject.
If the unmarshal is done with ignoreUnmarshalledHeaders set to
[jira] [Updated] (CAMEL-9066) Include any headers unmarshalled by SoapJaxbDataFormat in content marshalled by the same.
[ https://issues.apache.org/jira/browse/CAMEL-9066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Blackard updated CAMEL-9066: Attachment: unit_tests.patch Patch to add functioning unit tests to camel-soap. My first attempt at this I made a mistake in capitalization which caused the tests to fail. This patch should work from 2.12.x through 2.16.x. Include any headers unmarshalled by SoapJaxbDataFormat in content marshalled by the same. - Key: CAMEL-9066 URL: https://issues.apache.org/jira/browse/CAMEL-9066 Project: Camel Issue Type: Improvement Components: camel-soap Affects Versions: 2.12.5, 2.16.0, 2.15.3, 2.14.4, Future, 2.16 Environment: Any Reporter: Bob Blackard Assignee: Willem Jiang Labels: patch Fix For: 2.16.0, 2.15.3, 2.14.4, Future, 2.16 Attachments: camel.patch, soapjaxb-header-marshal-example.zip, unit_tests.patch The current implementation of the Soap11DataFormatAdapter and Soap12DataFormatAdapter will never generate SOAP Headers when a JAXB object is the inputObject. If the unmarshal is done with ignoreUnmarshalledHeaders set to false, then the SoapJaxbDataFormat.SOAP_UNMARSHALLED_HEADER_LIST message header is populated with a list of Objects or JAXBElement?s. However, during the doMarshal, this message header is never referenced. Therefore, the sequence: from(direct:source).unmarshal(fromSoapDataFormat).process(doSomething).marshal(toSoapDataFormat).to(mock:end); will never produce SOAP Headers in the outbound document. The doUnmarshal passes the inputObject and an empty ListJAXBElement? into createContentFromObject. However, is the inputObject is an ordinary JAXB object (or JAXBElement?) then no header content will be created, and since the Exchange isn't sent to createContentFromObject, the SoapJaxbDataFormat.SOAP_UNMARSHALLED_HEADER_LIST cannot be referenced. It seems to me that, if ignoreUnmarshalledHeaders is false, and the SoapJaxbDataFormat.SOAP_UNMARSHALLED_HEADER_LIST is non-empty, and in the event the inbound Exchange does not contain an Exception, then the contents of the SoapJaxbDataFormat.SOAP_UNMARSHALLED_HEADER_LIST should be added to the headerContent before the call to createContentFromObject. I have checked the code for SoapJaxbDataFormat, Soap11DataFormatAdapter and Soap12DataFormatAdapter from camel-soap 2.12.0 through 2.15.2 and it looks like these three classes haven't changed. I crated a demo project and patch, originally against JBoss Fuse 6.1.0, but offer it here for the camel-soap 2.12.x branch. I have also applied and tested the patch against camel-soap in the master branch (2.16-SNAPSHOT). Indeed, it looks like this patch can be applied from any point 2.12 and forward. The demo can be run against 2.12.5 (or any released version - just change the camel.version property in the POM) to demonstrate what I think is the failure. It can also be run against a patched 2.12.6-SNAPSHOT or 2.16-SNAPSHOT (again, just play around with the camel.version property) to demonstrate what I think is correct behavior. -- 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] [Commented] (CAMEL-9066) Include any headers unmarshalled by SoapJaxbDataFormat in content marshalled by the same.
[
https://issues.apache.org/jira/browse/CAMEL-9066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680605#comment-14680605
]
Bob Blackard commented on CAMEL-9066:
-
I tried to create unit tests based on my example, but they're not behaving the
same. I'm attaching the patch, but be warned that for reasons I don't
understand yet the unmarshal is producing a Body of type
com.sun.org.apache.xerces.internal.dom.ElementNSImp rather than
com.example.contact.Contact. The log for the three new tests shows:
2015-08-10 14:38:47,582 [main ] INFO Tracer
- ID-blackard-vm-50620-1439231926880-0-2 (route1) from(direct://start) --
unmarshal[org.apache.camel.dataformat.soap.SoapJaxbDataFormat@3c643130]
Pattern:InOnly, Headers:{breadcrumbId=ID-blackard-vm-50620-1439231926880-0-1},
BodyType:java.io.BufferedInputStream, Body:[Body is instance of
java.io.InputStream]
2015-08-10 14:38:47,865 [main ] INFO Tracer
- ID-blackard-vm-50620-1439231926880-0-2 (route1)
unmarshal[org.apache.camel.dataformat.soap.SoapJaxbDataFormat@3c643130] --
marshal[org.apache.camel.dataformat.soap.SoapJaxbDataFormat@3c643130]
Pattern:InOnly, Headers:{breadcrumbId=ID-blackard-vm-50620-1439231926880-0-1,
org.apache.camel.dataformat.soap.UNMARSHALLED_HEADER_LIST=[com.example.soapheaders.Comment@770d8fe9]},
BodyType:com.sun.org.apache.xerces.internal.dom.ElementNSImpl,
Body:cont:Contact xmlns:cont=http://www.example.com/contact;
xmlns:env=http://schemas.xmlsoap.org/soap/envelope/;nameSmith/namenumOrders0/numOrdersrevenue10.0/revenue
/cont:Contact
2015-08-10 14:38:47,865 [main ] ERROR DefaultErrorHandler
- Failed delivery for (MessageId: ID-blackard-vm-50620-1439231926880-0-1 on
ExchangeId: ID-blackard-vm-50620-1439231926880-0-2). Exhausted after delivery
attempt: 1 caught: java.lang.RuntimeException: The type
com.sun.org.apache.xerces.internal.dom.ElementNSImpl needs to have an XmlType
annotation with name
Message History
---
RouteId ProcessorId Processor
Elapsed (ms)
[route1] [route1] [direct://start
] [ 283]
[route1] [unmarshal1]
[unmarshal[org.apache.camel.model.DataFormatDefinition@79f361e5]
] [ 236]
[route1] [marshal1 ]
[marshal[org.apache.camel.model.DataFormatDefinition@59a03fef]
] [47]
Exchange
---
Exchange[###REPLACE_ME### Id
ID-blackard-vm-50620-1439231926880-0-2###REPLACE_ME### ExchangePattern
InOnly###REPLACE_ME### Headers
{breadcrumbId=ID-blackard-vm-50620-1439231926880-0-1, CamelRedelivered=false,
CamelRedeliveryCounter=0,
org.apache.camel.dataformat.soap.UNMARSHALLED_HEADER_LIST=[com.example.soapheaders.Comment@770d8fe9]}###REPLACE_ME###
BodyType
com.sun.org.apache.xerces.internal.dom.ElementNSImpl###REPLACE_ME###
Bodycont:Contact xmlns:cont=http://www.example.com/contact;
xmlns:env=http://schemas.xmlsoap.org/soap/envelope/;nameSmith/namenumOrders0/numOrdersrevenue10.0/revenue
/cont:Contact]
Stacktrace
---
java.lang.RuntimeException: The type
com.sun.org.apache.xerces.internal.dom.ElementNSImpl needs to have an XmlType
annotation with name
at
org.apache.camel.dataformat.soap.name.TypeNameStrategy.findQNameForSoapActionOrType(TypeNameStrategy.java:39)
Include any headers unmarshalled by SoapJaxbDataFormat in content marshalled
by the same.
-
Key: CAMEL-9066
URL: https://issues.apache.org/jira/browse/CAMEL-9066
Project: Camel
Issue Type: Improvement
Components: camel-soap
Affects Versions: 2.12.5, 2.16.0, 2.15.3, 2.14.4, Future, 2.16
Environment: Any
Reporter: Bob Blackard
Assignee: Willem Jiang
Labels: patch
Fix For: 2.16.0, 2.15.3, 2.14.4, Future, 2.16
Attachments: camel.patch, soapjaxb-header-marshal-example.zip
The current implementation of the Soap11DataFormatAdapter and
Soap12DataFormatAdapter will never generate SOAP Headers when a JAXB object
is the inputObject.
If the unmarshal is done with
[jira] [Created] (CAMEL-9071) Camel apply lock on a file while FTP is in progress
Malolan Raman created CAMEL-9071: Summary: Camel apply lock on a file while FTP is in progress Key: CAMEL-9071 URL: https://issues.apache.org/jira/browse/CAMEL-9071 Project: Camel Issue Type: Bug Components: camel-ftp Affects Versions: 2.10.1 Environment: This issue is seen in Linux version 5.9 and above. Reporter: Malolan Raman Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9066) Include any headers unmarshalled by SoapJaxbDataFormat in content marshalled by the same.
[ https://issues.apache.org/jira/browse/CAMEL-9066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Blackard updated CAMEL-9066: Attachment: attempt_to_create_unit_tests.txt This is a patch file, but I have intentionally not used the .patch extension since the tests don't actually run the way I expected - and I'm not sure why what's happening is happening. Include any headers unmarshalled by SoapJaxbDataFormat in content marshalled by the same. - Key: CAMEL-9066 URL: https://issues.apache.org/jira/browse/CAMEL-9066 Project: Camel Issue Type: Improvement Components: camel-soap Affects Versions: 2.12.5, 2.16.0, 2.15.3, 2.14.4, Future, 2.16 Environment: Any Reporter: Bob Blackard Assignee: Willem Jiang Labels: patch Fix For: 2.16.0, 2.15.3, 2.14.4, Future, 2.16 Attachments: attempt_to_create_unit_tests.txt, camel.patch, soapjaxb-header-marshal-example.zip The current implementation of the Soap11DataFormatAdapter and Soap12DataFormatAdapter will never generate SOAP Headers when a JAXB object is the inputObject. If the unmarshal is done with ignoreUnmarshalledHeaders set to false, then the SoapJaxbDataFormat.SOAP_UNMARSHALLED_HEADER_LIST message header is populated with a list of Objects or JAXBElement?s. However, during the doMarshal, this message header is never referenced. Therefore, the sequence: from(direct:source).unmarshal(fromSoapDataFormat).process(doSomething).marshal(toSoapDataFormat).to(mock:end); will never produce SOAP Headers in the outbound document. The doUnmarshal passes the inputObject and an empty ListJAXBElement? into createContentFromObject. However, is the inputObject is an ordinary JAXB object (or JAXBElement?) then no header content will be created, and since the Exchange isn't sent to createContentFromObject, the SoapJaxbDataFormat.SOAP_UNMARSHALLED_HEADER_LIST cannot be referenced. It seems to me that, if ignoreUnmarshalledHeaders is false, and the SoapJaxbDataFormat.SOAP_UNMARSHALLED_HEADER_LIST is non-empty, and in the event the inbound Exchange does not contain an Exception, then the contents of the SoapJaxbDataFormat.SOAP_UNMARSHALLED_HEADER_LIST should be added to the headerContent before the call to createContentFromObject. I have checked the code for SoapJaxbDataFormat, Soap11DataFormatAdapter and Soap12DataFormatAdapter from camel-soap 2.12.0 through 2.15.2 and it looks like these three classes haven't changed. I crated a demo project and patch, originally against JBoss Fuse 6.1.0, but offer it here for the camel-soap 2.12.x branch. I have also applied and tested the patch against camel-soap in the master branch (2.16-SNAPSHOT). Indeed, it looks like this patch can be applied from any point 2.12 and forward. The demo can be run against 2.12.5 (or any released version - just change the camel.version property in the POM) to demonstrate what I think is the failure. It can also be run against a patched 2.12.6-SNAPSHOT or 2.16-SNAPSHOT (again, just play around with the camel.version property) to demonstrate what I think is correct behavior. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9065) Exchange created needs to be aware of its FROM endpoint.
[
https://issues.apache.org/jira/browse/CAMEL-9065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679748#comment-14679748
]
Claus Ibsen commented on CAMEL-9065:
I found some other components to improve as well, now they are all done
davsclaus:~/workspace/camel (master)/$ find . -name '*Endpoint.java' | xargs
grep new DefaultExchange
./camel-core/src/main/java/org/apache/camel/impl/DefaultEndpoint.java:
return new DefaultExchange(this, pattern);
Exchange created needs to be aware of its FROM endpoint.
-
Key: CAMEL-9065
URL: https://issues.apache.org/jira/browse/CAMEL-9065
Project: Camel
Issue Type: Bug
Components: camel-mongodb
Affects Versions: 2.15.2
Reporter: omar alles
Assignee: Claus Ibsen
Priority: Minor
Fix For: 2.16.0
In 2.16, DefaultRuntimeEndpointRegistry (an EventNotifier) is extended to
being able to handle ExchangeCreatedEvent s.
In its notify(EventObjet), when processing an ExchangeCreateEvent, a
reference to exchange's from endpoint is needed in order to obtain its
endpoint uri.
{code:title=DefaultRuntimeEndpointRegistry.java|borderStyle=solid}
} else if (extended event instanceof ExchangeCreatedEvent) {
// we only capture details in extended mode
ExchangeCreatedEvent ece = (ExchangeCreatedEvent) event;
Endpoint endpoint = ece.getExchange().getFromEndpoint();
String routeId = ece.getExchange().getFromRouteId();
String uri = endpoint.getEndpointUri();
String key = asUtilizationKey(routeId, uri);
if (key != null) {
inputUtilization.onHit(key);
}
{code}
The problem is located in MongoDbEndpoint createMongoDbExchange)()
{code:title=MongoDbEndpoint.java|borderStyle=solid}
public Exchange createMongoDbExchange(DBObject dbObj) {
Exchange exchange = new DefaultExchange(this.getCamelContext(),
getExchangePattern());
...
}
{code}
This Exchange constructor does not take into consideration exchange's from
endpoint, consequently causing a NPE when processing its associated
ExchangeCreatedEvent.
When constructing an exchange, MongoDbEndpoint should use its parent 's
createExchange() which uses the proper Exchange constructors.
{code:title=MongoDbEndpoint.java|borderStyle=solid}
public Exchange createMongoDbExchange(DBObject dbObj) {
//Exchange exchange = new DefaultExchange(this.getCamelContext(),
getExchangePattern());
Exchange exchange = super.createExchange();
...
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9067) File consumer - Allow to filter by expression and have two options one for directory and another for file name
Claus Ibsen created CAMEL-9067:
--
Summary: File consumer - Allow to filter by expression and have
two options one for directory and another for file name
Key: CAMEL-9067
URL: https://issues.apache.org/jira/browse/CAMEL-9067
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Claus Ibsen
Fix For: Future
See nabble
People who want to consume from a directory using today as timestamp need to
write a custom filter java impl to do so.
We have a bunch of include/antInclude etc options today but they are regex/ant
based.
We should have a way of using an expression (simple language) so you can filter
such as
{code}
filterDirectory=${date:now:MMdd}filterFile=${file:ext} == 'xml'
${file:size} 2
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9068) Log output to show which route is shutdown and has a pending message
[
https://issues.apache.org/jira/browse/CAMEL-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679858#comment-14679858
]
Claus Ibsen commented on CAMEL-9068:
This happens today when the timeout is hit, then you get logging details about
those inflights. You can also set the logging level to DEBUG for
org.apache.camel.impl.DefaultShutdownStrategy to have it sooner.
Log output to show which route is shutdown and has a pending message
Key: CAMEL-9068
URL: https://issues.apache.org/jira/browse/CAMEL-9068
Project: Camel
Issue Type: Improvement
Affects Versions: 2.15.1
Reporter: Martin Lichtin
Priority: Minor
It'd be great to see in the log output which route is shutdown and has a
pending message:
{noformat}
2015-08-06 09:11:45,312 | INFO | FelixDispatchQueue |
DefaultShutdownStrategy | mel.impl.DefaultShutdownStrategy 184 | 94
- org.apache.camel.camel-core - 2.15.1 | Starting to graceful shutdown 1
routes (timeout 300 seconds)
2015-08-06 09:11:45,318 | INFO | hread #23 - ShutdownTask |
DefaultShutdownStrategy | ultShutdownStrategy$ShutdownTask 606 | 94
- org.apache.camel.camel-core - 2.15.1 | Waiting as there are still 1
inflight and pending exchanges to complete, timeout in 300 seconds.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9068) Log output to show which route is shutdown and has a pending message
Martin Lichtin created CAMEL-9068:
-
Summary: Log output to show which route is shutdown and has a
pending message
Key: CAMEL-9068
URL: https://issues.apache.org/jira/browse/CAMEL-9068
Project: Camel
Issue Type: Improvement
Affects Versions: 2.15.1
Reporter: Martin Lichtin
Priority: Minor
It'd be great to see in the log output which route is shutdown and has a
pending message:
{noformat}
2015-08-06 09:11:45,312 | INFO | FelixDispatchQueue |
DefaultShutdownStrategy | mel.impl.DefaultShutdownStrategy 184 | 94 -
org.apache.camel.camel-core - 2.15.1 | Starting to graceful shutdown 1 routes
(timeout 300 seconds)
2015-08-06 09:11:45,318 | INFO | hread #23 - ShutdownTask |
DefaultShutdownStrategy | ultShutdownStrategy$ShutdownTask 606 | 94 -
org.apache.camel.camel-core - 2.15.1 | Waiting as there are still 1 inflight
and pending exchanges to complete, timeout in 300 seconds.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9067) File consumer - Allow to filter by expression and have two options one for directory and another for file name
[
https://issues.apache.org/jira/browse/CAMEL-9067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9067:
---
Description:
See nabble
http://camel.465427.n5.nabble.com/smb-endpoint-modified-files-not-copied-to-destination-tp5770499p5770521.html
People who want to consume from a directory using today as timestamp need to
write a custom filter java impl to do so.
We have a bunch of include/antInclude etc options today but they are regex/ant
based.
We should have a way of using an expression (simple language) so you can filter
such as
{code}
filterDirectory=${date:now:MMdd}filterFile=${file:ext} == 'xml'
${file:size} 2
{code}
was:
See nabble
People who want to consume from a directory using today as timestamp need to
write a custom filter java impl to do so.
We have a bunch of include/antInclude etc options today but they are regex/ant
based.
We should have a way of using an expression (simple language) so you can filter
such as
{code}
filterDirectory=${date:now:MMdd}filterFile=${file:ext} == 'xml'
${file:size} 2
{code}
File consumer - Allow to filter by expression and have two options one for
directory and another for file name
--
Key: CAMEL-9067
URL: https://issues.apache.org/jira/browse/CAMEL-9067
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Claus Ibsen
Fix For: Future
See nabble
http://camel.465427.n5.nabble.com/smb-endpoint-modified-files-not-copied-to-destination-tp5770499p5770521.html
People who want to consume from a directory using today as timestamp need to
write a custom filter java impl to do so.
We have a bunch of include/antInclude etc options today but they are
regex/ant based.
We should have a way of using an expression (simple language) so you can
filter such as
{code}
filterDirectory=${date:now:MMdd}filterFile=${file:ext} == 'xml'
${file:size} 2
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9065) Exchange created needs to be aware of its FROM endpoint.
[
https://issues.apache.org/jira/browse/CAMEL-9065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679720#comment-14679720
]
ASF GitHub Bot commented on CAMEL-9065:
---
Github user asfgit closed the pull request at:
https://github.com/apache/camel/pull/591
Exchange created needs to be aware of its FROM endpoint.
-
Key: CAMEL-9065
URL: https://issues.apache.org/jira/browse/CAMEL-9065
Project: Camel
Issue Type: Bug
Components: camel-mongodb
Affects Versions: 2.15.2
Reporter: omar alles
Assignee: Claus Ibsen
Priority: Minor
Fix For: 2.16.0
In 2.16, DefaultRuntimeEndpointRegistry (an EventNotifier) is extended to
being able to handle ExchangeCreatedEvent s.
In its notify(EventObjet), when processing an ExchangeCreateEvent, a
reference to exchange's from endpoint is needed in order to obtain its
endpoint uri.
{code:title=DefaultRuntimeEndpointRegistry.java|borderStyle=solid}
} else if (extended event instanceof ExchangeCreatedEvent) {
// we only capture details in extended mode
ExchangeCreatedEvent ece = (ExchangeCreatedEvent) event;
Endpoint endpoint = ece.getExchange().getFromEndpoint();
String routeId = ece.getExchange().getFromRouteId();
String uri = endpoint.getEndpointUri();
String key = asUtilizationKey(routeId, uri);
if (key != null) {
inputUtilization.onHit(key);
}
{code}
The problem is located in MongoDbEndpoint createMongoDbExchange)()
{code:title=MongoDbEndpoint.java|borderStyle=solid}
public Exchange createMongoDbExchange(DBObject dbObj) {
Exchange exchange = new DefaultExchange(this.getCamelContext(),
getExchangePattern());
...
}
{code}
This Exchange constructor does not take into consideration exchange's from
endpoint, consequently causing a NPE when processing its associated
ExchangeCreatedEvent.
When constructing an exchange, MongoDbEndpoint should use its parent 's
createExchange() which uses the proper Exchange constructors.
{code:title=MongoDbEndpoint.java|borderStyle=solid}
public Exchange createMongoDbExchange(DBObject dbObj) {
//Exchange exchange = new DefaultExchange(this.getCamelContext(),
getExchangePattern());
Exchange exchange = super.createExchange();
...
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9065) Exchange created needs to be aware of its FROM endpoint.
[
https://issues.apache.org/jira/browse/CAMEL-9065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-9065.
Resolution: Fixed
Assignee: Claus Ibsen
Thanks for the PR
Exchange created needs to be aware of its FROM endpoint.
-
Key: CAMEL-9065
URL: https://issues.apache.org/jira/browse/CAMEL-9065
Project: Camel
Issue Type: Bug
Components: camel-mongodb
Affects Versions: 2.15.2
Reporter: omar alles
Assignee: Claus Ibsen
Priority: Minor
Fix For: 2.16.0
In 2.16, DefaultRuntimeEndpointRegistry (an EventNotifier) is extended to
being able to handle ExchangeCreatedEvent s.
In its notify(EventObjet), when processing an ExchangeCreateEvent, a
reference to exchange's from endpoint is needed in order to obtain its
endpoint uri.
{code:title=DefaultRuntimeEndpointRegistry.java|borderStyle=solid}
} else if (extended event instanceof ExchangeCreatedEvent) {
// we only capture details in extended mode
ExchangeCreatedEvent ece = (ExchangeCreatedEvent) event;
Endpoint endpoint = ece.getExchange().getFromEndpoint();
String routeId = ece.getExchange().getFromRouteId();
String uri = endpoint.getEndpointUri();
String key = asUtilizationKey(routeId, uri);
if (key != null) {
inputUtilization.onHit(key);
}
{code}
The problem is located in MongoDbEndpoint createMongoDbExchange)()
{code:title=MongoDbEndpoint.java|borderStyle=solid}
public Exchange createMongoDbExchange(DBObject dbObj) {
Exchange exchange = new DefaultExchange(this.getCamelContext(),
getExchangePattern());
...
}
{code}
This Exchange constructor does not take into consideration exchange's from
endpoint, consequently causing a NPE when processing its associated
ExchangeCreatedEvent.
When constructing an exchange, MongoDbEndpoint should use its parent 's
createExchange() which uses the proper Exchange constructors.
{code:title=MongoDbEndpoint.java|borderStyle=solid}
public Exchange createMongoDbExchange(DBObject dbObj) {
//Exchange exchange = new DefaultExchange(this.getCamelContext(),
getExchangePattern());
Exchange exchange = super.createExchange();
...
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-9066) Include any headers unmarshalled by SoapJaxbDataFormat in content marshalled by the same.
[ https://issues.apache.org/jira/browse/CAMEL-9066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-9066: --- Assignee: Willem Jiang Include any headers unmarshalled by SoapJaxbDataFormat in content marshalled by the same. - Key: CAMEL-9066 URL: https://issues.apache.org/jira/browse/CAMEL-9066 Project: Camel Issue Type: Improvement Components: camel-soap Affects Versions: 2.12.5, 2.16.0, 2.15.3, 2.14.4, Future, 2.16 Environment: Any Reporter: Bob Blackard Assignee: Willem Jiang Labels: patch Fix For: 2.16.0, 2.15.3, 2.14.4, Future, 2.16 Attachments: camel.patch, soapjaxb-header-marshal-example.zip The current implementation of the Soap11DataFormatAdapter and Soap12DataFormatAdapter will never generate SOAP Headers when a JAXB object is the inputObject. If the unmarshal is done with ignoreUnmarshalledHeaders set to false, then the SoapJaxbDataFormat.SOAP_UNMARSHALLED_HEADER_LIST message header is populated with a list of Objects or JAXBElement?s. However, during the doMarshal, this message header is never referenced. Therefore, the sequence: from(direct:source).unmarshal(fromSoapDataFormat).process(doSomething).marshal(toSoapDataFormat).to(mock:end); will never produce SOAP Headers in the outbound document. The doUnmarshal passes the inputObject and an empty ListJAXBElement? into createContentFromObject. However, is the inputObject is an ordinary JAXB object (or JAXBElement?) then no header content will be created, and since the Exchange isn't sent to createContentFromObject, the SoapJaxbDataFormat.SOAP_UNMARSHALLED_HEADER_LIST cannot be referenced. It seems to me that, if ignoreUnmarshalledHeaders is false, and the SoapJaxbDataFormat.SOAP_UNMARSHALLED_HEADER_LIST is non-empty, and in the event the inbound Exchange does not contain an Exception, then the contents of the SoapJaxbDataFormat.SOAP_UNMARSHALLED_HEADER_LIST should be added to the headerContent before the call to createContentFromObject. I have checked the code for SoapJaxbDataFormat, Soap11DataFormatAdapter and Soap12DataFormatAdapter from camel-soap 2.12.0 through 2.15.2 and it looks like these three classes haven't changed. I crated a demo project and patch, originally against JBoss Fuse 6.1.0, but offer it here for the camel-soap 2.12.x branch. I have also applied and tested the patch against camel-soap in the master branch (2.16-SNAPSHOT). Indeed, it looks like this patch can be applied from any point 2.12 and forward. The demo can be run against 2.12.5 (or any released version - just change the camel.version property in the POM) to demonstrate what I think is the failure. It can also be run against a patched 2.12.6-SNAPSHOT or 2.16-SNAPSHOT (again, just play around with the camel.version property) to demonstrate what I think is correct behavior. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9068) Log output to show which route is shutdown and has a pending message
[
https://issues.apache.org/jira/browse/CAMEL-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680128#comment-14680128
]
Martin Lichtin commented on CAMEL-9068:
---
Setting log level to DEBUG for org.apache.camel.impl.DefaultShutdownStrategy
would be an approach, thanks.
I still think above mentioned INFO messages would become useful once they
contain route name(s).
Currently one reads them and cannot deduce anything meaningful without knowing
which route is affected.
Log output to show which route is shutdown and has a pending message
Key: CAMEL-9068
URL: https://issues.apache.org/jira/browse/CAMEL-9068
Project: Camel
Issue Type: Improvement
Affects Versions: 2.15.1
Reporter: Martin Lichtin
Priority: Minor
It'd be great to see in the log output which route is shutdown and has a
pending message:
{noformat}
2015-08-06 09:11:45,312 | INFO | FelixDispatchQueue |
DefaultShutdownStrategy | mel.impl.DefaultShutdownStrategy 184 | 94
- org.apache.camel.camel-core - 2.15.1 | Starting to graceful shutdown 1
routes (timeout 300 seconds)
2015-08-06 09:11:45,318 | INFO | hread #23 - ShutdownTask |
DefaultShutdownStrategy | ultShutdownStrategy$ShutdownTask 606 | 94
- org.apache.camel.camel-core - 2.15.1 | Waiting as there are still 1
inflight and pending exchanges to complete, timeout in 300 seconds.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9069) Add processor to immediately handle exception while in retry loop
Kevin Telford created CAMEL-9069: Summary: Add processor to immediately handle exception while in retry loop Key: CAMEL-9069 URL: https://issues.apache.org/jira/browse/CAMEL-9069 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Kevin Telford Priority: Trivial We have a recipientList of http4 endpoints. Occasionally an endpoint won't be available, and will return an exception (whether a ConnectException, or any other ex and a status code of =400). To handle these errors we can use a defaultErrorHandler or leverage onException, and setup redelivery. What we then would like to do is some custom error handling on each occurrence of an exception. Both the defaultErrorHandler and onException support .onRedelivery(). While this is nice, when a retry delay grows large enough the lag between the exception and the .onRedelivery() call really begins to grow and so our custom error handling isn't as much “on error” as it is “on error and after a wait”. onException also supports a .process() call, however this only occurs once all redeliveries have failed. What would be ideal would be an additional .onExceptionOccur(Processor processor) method (or some such name) that allows for immediate processing upon an exception, even if its being handled within a retry loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-9063) Add useGetBytesForBlob option in camel-jdbc
[ https://issues.apache.org/jira/browse/CAMEL-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680001#comment-14680001 ] João Antonio da Cruz Júnior edited comment on CAMEL-9063 at 8/10/15 12:01 PM: -- I made it that way to preserve backward compatibilities, but using getBytes by default will increase performance because we would need only change the interface method implementation. was (Author: joaoacj): I made it that way to preserve backward compatibilities, but using getBytes by default will increase performance because we would only change the interface method implementation. Add useGetBytesForBlob option in camel-jdbc --- Key: CAMEL-9063 URL: https://issues.apache.org/jira/browse/CAMEL-9063 Project: Camel Issue Type: Improvement Components: camel-jdbc Affects Versions: 2.15.2 Reporter: João Antonio da Cruz Júnior Attachments: useGetBytesForBlob.patch As described in Oracle documentation(avaliable at http://docs.oracle.com/cd/E18283_01/java.112/e16548/oralob.htm#CHDCDFAC ): The getString and getNString methods cannot be used for retrieving BLOB column values. So i changed the component to accept an option to use the getBytes method instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9063) Add useGetBytesForBlob option in camel-jdbc
[ https://issues.apache.org/jira/browse/CAMEL-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680001#comment-14680001 ] João Antonio da Cruz Júnior commented on CAMEL-9063: I made it that way to preserve backward compatibilities, but using getBytes by default will increase performance because we would only change the interface method implementation. Add useGetBytesForBlob option in camel-jdbc --- Key: CAMEL-9063 URL: https://issues.apache.org/jira/browse/CAMEL-9063 Project: Camel Issue Type: Improvement Components: camel-jdbc Affects Versions: 2.15.2 Reporter: João Antonio da Cruz Júnior Attachments: useGetBytesForBlob.patch As described in Oracle documentation(avaliable at http://docs.oracle.com/cd/E18283_01/java.112/e16548/oralob.htm#CHDCDFAC ): The getString and getNString methods cannot be used for retrieving BLOB column values. So i changed the component to accept an option to use the getBytes method instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
