[jira] [Commented] (CAMEL-8979) Camel Kafka component is using Producer and KeyedMessage class
[ https://issues.apache.org/jira/browse/CAMEL-8979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14650164#comment-14650164 ] Anbumani Balusamy commented on CAMEL-8979: -- Hi Claus, Please let me know if any changes are required in the patch Camel Kafka component is using Producer and KeyedMessage class -- Key: CAMEL-8979 URL: https://issues.apache.org/jira/browse/CAMEL-8979 Project: Camel Issue Type: Improvement Components: camel-kafka Reporter: Anbumani Balusamy Priority: Minor Attachments: CAMEL-8979-Kafka-Documentation.txt, CAMEL-8979-camel-kafka-pom.txt, CAMEL-8979-src.txt, camel-kafka.zip Hi, I looked into the camel-kafka component version 2.15.2 and it's using old Producer and KeyedMessage class for posting the message to kafka topic. From 0.8.2 version we have new KafkaProducer and ProduceRecord classes. Can we change the component to use the KafkaProducer and ProduceRecord classes? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9040) netty4-http - LEAK: ByteBuf.release() was not called before it's garbage-collected
Ralf Steppacher created CAMEL-9040:
--
Summary: netty4-http - LEAK: ByteBuf.release() was not called
before it's garbage-collected
Key: CAMEL-9040
URL: https://issues.apache.org/jira/browse/CAMEL-9040
Project: Camel
Issue Type: Bug
Components: camel-netty4-http
Affects Versions: 2.15.2
Reporter: Ralf Steppacher
In a reverse-proxy with multiple routes that utilize the netty4-http component
both as the consumer and producer I am receiving the following error:
{noformat}
2015-07-30 11:52:34,416 | ERROR | yServerTCPWorker | ResourceLeakDetector
| 97 - io.netty.common - 4.0.27.Final | | LEAK: ByteBuf.release() was
not called before it's garbage-collected. See
http://netty.io/wiki/reference-counted-objects.html for more information.
{noformat}
Setting the Netty leak reporting to paranoid
({{-Dio.netty.leakDetectionLevel=paranoid}}) yields an error for almost every
request (it probably is 1:1).
The stacktraces come in two variants. Variant 1 is far less frequent than
variant 2.
Variant 1:
{noformat}
Recent access records: 0
Created at:
io.netty.buffer.CompositeByteBuf.init(CompositeByteBuf.java:60)
io.netty.buffer.Unpooled.compositeBuffer(Unpooled.java:353)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:153)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:54)
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:242)
io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:147)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
java.lang.Thread.run(Thread.java:745)
{noformat}
Variant 2:
{noformat}
Recent access records: 5
#5:
io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:223)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:684)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:40)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:677)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1493)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:40)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
java.io.BufferedInputStream.read(BufferedInputStream.java:334)
org.bouncycastle.util.io.TeeInputStream.read(Unknown Source)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:250)
com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:133)
com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:545)
com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:605)
com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:628)
com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:331)
ch.vivates.pep.stream.ResponseStatusFilter.filter(ResponseStatusFilter.java:41)
ch.vivates.pep.stream.BaseStreamFilter.run(BaseStreamFilter.java:141)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
java.util.concurrent.FutureTask.run(FutureTask.java:262)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:745)
#4:
io.netty.buffer.AdvancedLeakAwareByteBuf.release(AdvancedLeakAwareByteBuf.java:45)
io.netty.handler.codec.http.DefaultHttpContent.release(DefaultHttpContent.java:72)
io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:59)
[jira] [Created] (CAMEL-9041) Is it possible to reuse http port on karaf
Sergey created CAMEL-9041:
--
Summary: Is it possible to reuse http port on karaf
Key: CAMEL-9041
URL: https://issues.apache.org/jira/browse/CAMEL-9041
Project: Camel
Issue Type: Wish
Components: camel-jetty
Environment: karaf 3.0.x
Reporter: Sergey
Its not clear from component documentation how to reuse the same port when
running on karaf. For example, webconsole and hawtion using port 8181, but if I
try to specify jetty endpoint as:
{code:xml}
endpoint id=jetty-ep
uri=jetty:http://0.0.0.0:8181/suffix?matchOnUriPrefix=true/
{code}
then I've got an error during endpoint init (java.net.BindException: Address
already in use).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-8942) aws-sqs - Make it easier to configure http proxy
[ https://issues.apache.org/jira/browse/CAMEL-8942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino reassigned CAMEL-8942: --- Assignee: Andrea Cosentino aws-sqs - Make it easier to configure http proxy Key: CAMEL-8942 URL: https://issues.apache.org/jira/browse/CAMEL-8942 Project: Camel Issue Type: Improvement Components: camel-aws Reporter: Claus Ibsen Assignee: Andrea Cosentino Fix For: Future To use http proxy you need to configure the aws client manually which can be a bit cumbersome to do, especially for xml dsl. http://camel.apache.org/aws-sqs.html We should make this configuration possible from uri options / component options so ppl can easily do this. See also https://developer.jboss.org/thread/260836 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9042) Incorrect default value in a documentation of camel-atom
Tomas Turek created CAMEL-9042:
--
Summary: Incorrect default value in a documentation of camel-atom
Key: CAMEL-9042
URL: https://issues.apache.org/jira/browse/CAMEL-9042
Project: Camel
Issue Type: Bug
Components: documentation
Affects Versions: 2.15.2
Reporter: Tomas Turek
Option {{consumer.delay}} in documentaion of
[camel-atom|https://camel.apache.org/atom.html] has incorrect default value
{{6}} but correct value is {{500}}.
--
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] [Commented] (CAMEL-8942) aws-sqs - Make it easier to configure http proxy
[ https://issues.apache.org/jira/browse/CAMEL-8942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649366#comment-14649366 ] Andrea Cosentino commented on CAMEL-8942: - I will check the other components and I'll open single ticket for each one. aws-sqs - Make it easier to configure http proxy Key: CAMEL-8942 URL: https://issues.apache.org/jira/browse/CAMEL-8942 Project: Camel Issue Type: Improvement Components: camel-aws Reporter: Claus Ibsen Assignee: Andrea Cosentino Fix For: Future To use http proxy you need to configure the aws client manually which can be a bit cumbersome to do, especially for xml dsl. http://camel.apache.org/aws-sqs.html We should make this configuration possible from uri options / component options so ppl can easily do this. See also https://developer.jboss.org/thread/260836 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8554) camel-jackson should provide Map = Object converter
[
https://issues.apache.org/jira/browse/CAMEL-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649458#comment-14649458
]
Henryk Konsek commented on CAMEL-8554:
--
Thanks Claus!
camel-jackson should provide Map = Object converter
Key: CAMEL-8554
URL: https://issues.apache.org/jira/browse/CAMEL-8554
Project: Camel
Issue Type: Improvement
Components: camel-jackson
Reporter: Henryk Konsek
Assignee: Claus Ibsen
Fix For: 2.16.0
Jackson's {{ObjectMapper}} can be used to convert {{Map}} to pojo. It would
be nice if Jackson component provide this kind of fallback converter then.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-8942) aws-sqs - Make it easier to configure http proxy
[ https://issues.apache.org/jira/browse/CAMEL-8942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-8942. - Resolution: Fixed aws-sqs - Make it easier to configure http proxy Key: CAMEL-8942 URL: https://issues.apache.org/jira/browse/CAMEL-8942 Project: Camel Issue Type: Improvement Components: camel-aws Reporter: Claus Ibsen Assignee: Andrea Cosentino Fix For: Future To use http proxy you need to configure the aws client manually which can be a bit cumbersome to do, especially for xml dsl. http://camel.apache.org/aws-sqs.html We should make this configuration possible from uri options / component options so ppl can easily do this. See also https://developer.jboss.org/thread/260836 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9038) Make the existing tests of camle-olingo2 automatically executable
[ https://issues.apache.org/jira/browse/CAMEL-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida resolved CAMEL-9038. - Resolution: Fixed Fix Version/s: 2.15.3 2.16.0 - Some refactoring to the test code to make the tests executed without much overhead. - removed the unused test profile that is no longer needed (as the tests are executed automatically without any manual interaction). Make the existing tests of camle-olingo2 automatically executable - Key: CAMEL-9038 URL: https://issues.apache.org/jira/browse/CAMEL-9038 Project: Camel Issue Type: Task Components: camel-olingo2 Reporter: Akitoshi Yoshida Assignee: Akitoshi Yoshida Fix For: 2.16.0, 2.15.3 Currently, the tests included in camel-olingo2 are not executed automatically and because of this situation, those tests are not frequently executed and this could lead to the situation where we may not be able to spot some issues early. I propose to make the current tests executable during the normal test phase. Although the current tests are marked as the integration tests, their test scope corresponds to the other unit tests that are executed by other components. Since the olingo sample project itself is not currently available as a downloadable jar but only available via its architype generator, we can add this process in the build to make the sample server available during the test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9020) Splunk component should use TLS instead of SSLv3
[ https://issues.apache.org/jira/browse/CAMEL-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649373#comment-14649373 ] ASF GitHub Bot commented on CAMEL-9020: --- GitHub user pax95 opened a pull request: https://github.com/apache/camel/pull/581 CAMEL-9020 : polished - only set TLS when using https You can merge this pull request into a Git repository by running: $ git pull https://github.com/pax95/camel master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/581.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #581 commit 7166508f7b29ced25642f16464a2eb97654becf8 Author: Preben Asmussen preben.asmus...@gmail.com Date: 2015-07-31T15:41:17Z CAMEL-9020 : polished - only set TLS when using https Splunk component should use TLS instead of SSLv3 Key: CAMEL-9020 URL: https://issues.apache.org/jira/browse/CAMEL-9020 Project: Camel Issue Type: Improvement Affects Versions: 2.15.2 Environment: jdk 8 Reporter: Preben Asmussen Assignee: Claus Ibsen Priority: Minor Fix For: 2.16.0 SSLv3 support has been removed in jdk 8. The component should be upgraded to Splunk sdk 1.4.0, and use TLS instead. See https://github.com/splunk/splunk-sdk-java#java-and-ant. A bundle is ready at http://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.splunk/1.4.0.0_1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9020) Splunk component should use TLS instead of SSLv3
[ https://issues.apache.org/jira/browse/CAMEL-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649405#comment-14649405 ] Preben Asmussen commented on CAMEL-9020: No need for a None option since it's covered by the scheme option Splunk component should use TLS instead of SSLv3 Key: CAMEL-9020 URL: https://issues.apache.org/jira/browse/CAMEL-9020 Project: Camel Issue Type: Improvement Affects Versions: 2.15.2 Environment: jdk 8 Reporter: Preben Asmussen Assignee: Claus Ibsen Priority: Minor Fix For: 2.16.0 SSLv3 support has been removed in jdk 8. The component should be upgraded to Splunk sdk 1.4.0, and use TLS instead. See https://github.com/splunk/splunk-sdk-java#java-and-ant. A bundle is ready at http://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.splunk/1.4.0.0_1 -- 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] [Created] (CAMEL-9043) Fix camel-example-cxf-osgi/blueprint examples
Tomas Rohovsky created CAMEL-9043: - Summary: Fix camel-example-cxf-osgi/blueprint examples Key: CAMEL-9043 URL: https://issues.apache.org/jira/browse/CAMEL-9043 Project: Camel Issue Type: Bug Components: examples Affects Versions: 2.15.2 Reporter: Tomas Rohovsky Assignee: Tomas Rohovsky Cannot deploy camel-example-cxf-osgi because of wrong Import-Package requirement. Expression for output filename is not evaluated properly in both examples. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9043) Fix camel-example-cxf-osgi/blueprint examples
[ https://issues.apache.org/jira/browse/CAMEL-9043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649588#comment-14649588 ] Tomas Rohovsky commented on CAMEL-9043: --- https://github.com/apache/camel/pull/582 Fix camel-example-cxf-osgi/blueprint examples - Key: CAMEL-9043 URL: https://issues.apache.org/jira/browse/CAMEL-9043 Project: Camel Issue Type: Bug Components: examples Affects Versions: 2.15.2 Reporter: Tomas Rohovsky Assignee: Tomas Rohovsky Cannot deploy camel-example-cxf-osgi because of wrong Import-Package requirement. Expression for output filename is not evaluated properly in both examples. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7985) camel-test-blueprint - Upgrading to newer felix fails with NPE in fileinstall
[
https://issues.apache.org/jira/browse/CAMEL-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649699#comment-14649699
]
ASF GitHub Bot commented on CAMEL-7985:
---
Github user luigidemasi closed the pull request at:
https://github.com/apache/camel/pull/578
camel-test-blueprint - Upgrading to newer felix fails with NPE in fileinstall
-
Key: CAMEL-7985
URL: https://issues.apache.org/jira/browse/CAMEL-7985
Project: Camel
Issue Type: Improvement
Components: camel-blueprint, camel-test
Affects Versions: 2.14.0
Reporter: Claus Ibsen
Assignee: Grzegorz Grzybek
Priority: Minor
Fix For: 2.16.0, 2.15.3
Attachments: Screen Shot 2014-10-30 at 11.44.58 AM.png
We get a bunch of these errors during testing with osgi blueprint
{code}
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
{code}
Run tests here
{code}
camel/tests/camel-blueprint-cxf-test (master)/$ mvn clean install
{code}
And upgrade Felix in parent/pom.xml
{code}
-felix-configadmin-version1.4.0/felix-configadmin-version
-felix-fileinstall-version3.2.6/felix-fileinstall-version
-felix-framework-version3.2.2/felix-framework-version
+felix-configadmin-version1.8.0/felix-configadmin-version
+felix-fileinstall-version3.4.2/felix-fileinstall-version
+felix-framework-version3.4.2/felix-framework-version
{code}
And you get these NPEs.
Maybe something needs to be fixed in camel-test-blueprint with that pojosr
library, so bundle 0 is that system bundle, as the NPE is at:
https://github.com/apache/felix/blame/trunk/fileinstall/src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java#L303
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9039) Feature camel-core contains bundles, which should be made optional for micro-services deployment
[
https://issues.apache.org/jira/browse/CAMEL-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dhiraj Bokde resolved CAMEL-9039.
-
Resolution: Fixed
Fix Version/s: 2.15.3
2.16.0
Wrapped {{camel-commands-core, camel-karaf-commands}} in a conditional for
karaf {{shell}} feature. Commit pushed to master and camel-2.15.x branches.
Feature camel-core contains bundles, which should be made optional for
micro-services deployment
Key: CAMEL-9039
URL: https://issues.apache.org/jira/browse/CAMEL-9039
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.15.2
Reporter: Dhiraj Bokde
Assignee: Dhiraj Bokde
Fix For: 2.16.0, 2.15.3
The camel-core feature loads the following bundles that are only useful in a
console based karaf container:
{code}
bundlemvn:org.apache.camel/camel-catalog/${project.version}/bundle
bundlemvn:org.apache.camel/camel-commands-core/${project.version}/bundle
bundlemvn:org.apache.camel.karaf/camel-karaf-commands/${project.version}/bundle
{code}
Loading these bundles should be made optional so that the camel-core feature
(and all the component features that depend on it) can be easily used in a
micro-services deployment of Karaf4.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9039) Feature camel-core contains bundles, which should be made optional for micro-services deployment
[
https://issues.apache.org/jira/browse/CAMEL-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649709#comment-14649709
]
Dhiraj Bokde commented on CAMEL-9039:
-
So Karaf supports loading bundles and config on the condition that some other
feature is already installed. It is used in Karaf to conditionally load its own
features, when the {{shell}} feature is loaded, the same thing we want to do
for camel-core.
I have committed the change to add the same conditional check around bundles
{{camel-commands-core, camel-karaf-commands}} and left {{camel-catalog}} as it
is for tooling support. So if camel-core is loaded in a karaf container with
{{shell}} feature, the command bundles will be loaded, otherwise they won't.
This way existing karaf containers won't be affected, and we don't have to
worry about all the component features that load {{camel-core}} feature.
Feature camel-core contains bundles, which should be made optional for
micro-services deployment
Key: CAMEL-9039
URL: https://issues.apache.org/jira/browse/CAMEL-9039
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.15.2
Reporter: Dhiraj Bokde
Assignee: Dhiraj Bokde
The camel-core feature loads the following bundles that are only useful in a
console based karaf container:
{code}
bundlemvn:org.apache.camel/camel-catalog/${project.version}/bundle
bundlemvn:org.apache.camel/camel-commands-core/${project.version}/bundle
bundlemvn:org.apache.camel.karaf/camel-karaf-commands/${project.version}/bundle
{code}
Loading these bundles should be made optional so that the camel-core feature
(and all the component features that depend on it) can be easily used in a
micro-services deployment of Karaf4.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-9039) Feature camel-core contains bundles, which should be made optional for micro-services deployment
[
https://issues.apache.org/jira/browse/CAMEL-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dhiraj Bokde reassigned CAMEL-9039:
---
Assignee: Dhiraj Bokde
Feature camel-core contains bundles, which should be made optional for
micro-services deployment
Key: CAMEL-9039
URL: https://issues.apache.org/jira/browse/CAMEL-9039
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.15.2
Reporter: Dhiraj Bokde
Assignee: Dhiraj Bokde
The camel-core feature loads the following bundles that are only useful in a
console based karaf container:
{code}
bundlemvn:org.apache.camel/camel-catalog/${project.version}/bundle
bundlemvn:org.apache.camel/camel-commands-core/${project.version}/bundle
bundlemvn:org.apache.camel.karaf/camel-karaf-commands/${project.version}/bundle
{code}
Loading these bundles should be made optional so that the camel-core feature
(and all the component features that depend on it) can be easily used in a
micro-services deployment of Karaf4.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9039) Feature camel-core contains bundles, which should be made optional for micro-services deployment
[
https://issues.apache.org/jira/browse/CAMEL-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648869#comment-14648869
]
Claus Ibsen commented on CAMEL-9039:
Yeah but we should make sure they are loaded by default when people do a
'camel' feature install. You may move these to some new 'camel-core' feature or
something that just has the very basics, i guess even without camel-blueprint
or camel-spring either.
Feature camel-core contains bundles, which should be made optional for
micro-services deployment
Key: CAMEL-9039
URL: https://issues.apache.org/jira/browse/CAMEL-9039
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.15.2
Reporter: Dhiraj Bokde
Assignee: Dhiraj Bokde
The camel-core feature loads the following bundles that are only useful in a
console based karaf container:
{code}
bundlemvn:org.apache.camel/camel-catalog/${project.version}/bundle
bundlemvn:org.apache.camel/camel-commands-core/${project.version}/bundle
bundlemvn:org.apache.camel.karaf/camel-karaf-commands/${project.version}/bundle
{code}
Loading these bundles should be made optional so that the camel-core feature
(and all the component features that depend on it) can be easily used in a
micro-services deployment of Karaf4.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9020) Splunk component should use TLS instead of SSLv3
[ https://issues.apache.org/jira/browse/CAMEL-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9020. Resolution: Fixed Assignee: Claus Ibsen Fix Version/s: 2.16.0 Thanks for the PR Splunk component should use TLS instead of SSLv3 Key: CAMEL-9020 URL: https://issues.apache.org/jira/browse/CAMEL-9020 Project: Camel Issue Type: Improvement Affects Versions: 2.15.2 Environment: jdk 8 Reporter: Preben Asmussen Assignee: Claus Ibsen Priority: Minor Fix For: 2.16.0 SSLv3 support has been removed in jdk 8. The component should be upgraded to Splunk sdk 1.4.0, and use TLS instead. See https://github.com/splunk/splunk-sdk-java#java-and-ant. A bundle is ready at http://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.splunk/1.4.0.0_1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9039) Feature camel-core contains bundles, which should be made optional for micro-services deployment
[
https://issues.apache.org/jira/browse/CAMEL-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9039:
---
Issue Type: Improvement (was: Bug)
Feature camel-core contains bundles, which should be made optional for
micro-services deployment
Key: CAMEL-9039
URL: https://issues.apache.org/jira/browse/CAMEL-9039
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.15.2
Reporter: Dhiraj Bokde
Assignee: Dhiraj Bokde
The camel-core feature loads the following bundles that are only useful in a
console based karaf container:
{code}
bundlemvn:org.apache.camel/camel-catalog/${project.version}/bundle
bundlemvn:org.apache.camel/camel-commands-core/${project.version}/bundle
bundlemvn:org.apache.camel.karaf/camel-karaf-commands/${project.version}/bundle
{code}
Loading these bundles should be made optional so that the camel-core feature
(and all the component features that depend on it) can be easily used in a
micro-services deployment of Karaf4.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9020) Splunk component should use TLS instead of SSLv3
[ https://issues.apache.org/jira/browse/CAMEL-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648891#comment-14648891 ] ASF GitHub Bot commented on CAMEL-9020: --- Github user pax95 closed the pull request at: https://github.com/apache/camel/pull/580 Splunk component should use TLS instead of SSLv3 Key: CAMEL-9020 URL: https://issues.apache.org/jira/browse/CAMEL-9020 Project: Camel Issue Type: Improvement Affects Versions: 2.15.2 Environment: jdk 8 Reporter: Preben Asmussen Assignee: Claus Ibsen Priority: Minor Fix For: 2.16.0 SSLv3 support has been removed in jdk 8. The component should be upgraded to Splunk sdk 1.4.0, and use TLS instead. See https://github.com/splunk/splunk-sdk-java#java-and-ant. A bundle is ready at http://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.splunk/1.4.0.0_1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9020) Splunk component should use TLS instead of SSLv3
[ https://issues.apache.org/jira/browse/CAMEL-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648876#comment-14648876 ] Claus Ibsen commented on CAMEL-9020: Btw is there no way to use no TLS at all? eg if you can set the value to None or something to indicate SSL not to be used? Splunk component should use TLS instead of SSLv3 Key: CAMEL-9020 URL: https://issues.apache.org/jira/browse/CAMEL-9020 Project: Camel Issue Type: Improvement Affects Versions: 2.15.2 Environment: jdk 8 Reporter: Preben Asmussen Assignee: Claus Ibsen Priority: Minor Fix For: 2.16.0 SSLv3 support has been removed in jdk 8. The component should be upgraded to Splunk sdk 1.4.0, and use TLS instead. See https://github.com/splunk/splunk-sdk-java#java-and-ant. A bundle is ready at http://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.splunk/1.4.0.0_1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9020) Splunk component should use TLS instead of SSLv3
[ https://issues.apache.org/jira/browse/CAMEL-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648886#comment-14648886 ] Preben Asmussen commented on CAMEL-9020: Yeah - you right if using plain http. I'll add an option 'None' and do a PR. Splunk component should use TLS instead of SSLv3 Key: CAMEL-9020 URL: https://issues.apache.org/jira/browse/CAMEL-9020 Project: Camel Issue Type: Improvement Affects Versions: 2.15.2 Environment: jdk 8 Reporter: Preben Asmussen Assignee: Claus Ibsen Priority: Minor Fix For: 2.16.0 SSLv3 support has been removed in jdk 8. The component should be upgraded to Splunk sdk 1.4.0, and use TLS instead. See https://github.com/splunk/splunk-sdk-java#java-and-ant. A bundle is ready at http://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.splunk/1.4.0.0_1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8241) Exec command failures using Java 8 on Unix
[ https://issues.apache.org/jira/browse/CAMEL-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648988#comment-14648988 ] Claus Ibsen commented on CAMEL-8241: Thanks Brian I just improved to check ignoring the case. Exec command failures using Java 8 on Unix -- Key: CAMEL-8241 URL: https://issues.apache.org/jira/browse/CAMEL-8241 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.0 Environment: JDK 1.8 on Unix systems Reporter: Dave Heath Assignee: Claus Ibsen Fix For: 2.14.2, 2.15.0 Attachments: CamelExecTest.java I'm attaching a test case that shows an issue I've been running into with the exec command since updating my environment to Java 8. It appears that I'm running into a race condition where a stream is sometimes closed prematurely before DefaultExecutor has a chance to close it, causing DefaultExecCommandExecutor to throw and exit (even though the command did execute properly). I've tested this against the updated version of commons-exec as well just to make sure this hasn't somehow been fixed in that library. Please note that the attached test doesn't always fail; you may need to run it a few times before the error will show up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9033) Abstract undertow HttpHandler creation
[ https://issues.apache.org/jira/browse/CAMEL-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648949#comment-14648949 ] ASF GitHub Bot commented on CAMEL-9033: --- Github user tdiesler closed the pull request at: https://github.com/apache/camel/pull/579 Abstract undertow HttpHandler creation -- Key: CAMEL-9033 URL: https://issues.apache.org/jira/browse/CAMEL-9033 Project: Camel Issue Type: Improvement Components: camel-undertow Reporter: Thomas Diesler Assignee: Claus Ibsen Fix For: 2.16.0 This would allow Undertow consumers to get created on the default host of an already running server, which would be the case for wildfly integration CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/779 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9037) DefaultJmsMessageListenerContainer leaks threads
[ https://issues.apache.org/jira/browse/CAMEL-9037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9037. Resolution: Fixed DefaultJmsMessageListenerContainer leaks threads Key: CAMEL-9037 URL: https://issues.apache.org/jira/browse/CAMEL-9037 Project: Camel Issue Type: Bug Components: camel-jms Affects Versions: 2.12.3 Reporter: shpelda2 Assignee: Claus Ibsen Fix For: 2.16.0, 2.15.3 Threads created by DefaultTaskExecutorType.ThreadPool at org.apache.camel.component.jms.DefaultJmsMessageListenerContainer.createDefaultTaskExecutor() are never stopped, as destroy method is never called on the ThreadPoolTaskExecutor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9035) unbind smpp connection bug
[
https://issues.apache.org/jira/browse/CAMEL-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9035:
---
Description:
Suppose SMSC allowed one connection to client and due to any reason if
session.unbindAndClose failed it will set session to null and dont retry to
unbind.
Connection/Session will remain open on SMSC till its TransactionTimeOut, mostly
SMSc Admin set it to 5 to 10 mins.
Following are snippet of org.apache.camel.component.smpp.SmppProducer and
details are like
1- if for any reason Camel try to unbind connection and it got failed below
code print log and set session=null in both success/fail cases.
2- After sending unbind it will try to reconnect.
3- As SMSc allowed 1 connection which was not unbinded successfull it will not
allowed second connection so reconnect will get failed.
4- Camel call closesession on reconnection failure and will verify if session
!= null, as session is already null so this code will not send unbind again and
apache camel will not able to get connection from SMSc until timeout happen on
SMSc and this will results in 10 mins outage.
If we change closeSession() like below
current:
{code}
private void closeSession() {
if (session != null) {
session.removeSessionStateListener(this.internalSessionStateListener);
try {
Thread.sleep(1000);
session.unbindAndClose();
} catch (Exception e) {
LOG.warn(Could not close session + session);
}
session = null;
}
}
{code}
Suggested:
{code}
private void closeSession() {
if (session != null) {
session.removeSessionStateListener(this.internalSessionStateListener);
try {
Thread.sleep(1000);
session.unbindAndClose();
session = null; // if we put here then it will retry for unbind
} catch (Exception e) {
LOG.warn(Could not close session + session);
}
session = null; // remove his line
}
}
{code}
was:
Suppose SMSC allowed one connection to client and due to any reason if
session.unbindAndClose failed it will set session to null and dont retry to
unbind.
Connection/Session will remain open on SMSC till its TransactionTimeOut, mostly
SMSc Admin set it to 5 to 10 mins.
Following are snippet of org.apache.camel.component.smpp.SmppProducer and
details are like
1- if for any reason Camel try to unbind connection and it got failed below
code print log and set session=null in both success/fail cases.
2- After sending unbind it will try to reconnect.
3- As SMSc allowed 1 connection which was not unbinded successfull it will not
allowed second connection so reconnect will get failed.
4- Camel call closesession on reconnection failure and will verify if session
!= null, as session is already null so this code will not send unbind again and
apache camel will not able to get connection from SMSc until timeout happen on
SMSc and this will results in 10 mins outage.
If we change closeSession() like below
current:
private void closeSession() {
if (session != null) {
session.removeSessionStateListener(this.internalSessionStateListener);
try {
Thread.sleep(1000);
session.unbindAndClose();
} catch (Exception e) {
LOG.warn(Could not close session + session);
}
session = null;
}
}
Suggested:
private void closeSession() {
if (session != null) {
session.removeSessionStateListener(this.internalSessionStateListener);
try {
Thread.sleep(1000);
session.unbindAndClose();
session = null; // if we put here then it will retry for unbind
} catch (Exception e) {
LOG.warn(Could not close session + session);
}
session = null; // remove his line
}
}
unbind smpp connection bug
---
Key: CAMEL-9035
URL: https://issues.apache.org/jira/browse/CAMEL-9035
Project: Camel
Issue Type: Bug
Components: camel-smpp
Affects Versions: 2.14.0, 2.15.2
Reporter: imran raza khan
Labels: patch
Fix For: 2.15.2
Suppose SMSC allowed one connection to client and due to any reason if
session.unbindAndClose failed it will set session to null and dont retry to
unbind.
Connection/Session will remain open on SMSC till its TransactionTimeOut,
mostly SMSc Admin set it to 5 to 10 mins.
Following are snippet of org.apache.camel.component.smpp.SmppProducer and
details are like
1- if for any reason Camel try to unbind
[jira] [Updated] (CAMEL-9035) unbind smpp connection bug
[
https://issues.apache.org/jira/browse/CAMEL-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9035:
---
Fix Version/s: 2.16.0
unbind smpp connection bug
---
Key: CAMEL-9035
URL: https://issues.apache.org/jira/browse/CAMEL-9035
Project: Camel
Issue Type: Bug
Components: camel-smpp
Affects Versions: 2.14.0, 2.15.2
Reporter: imran raza khan
Labels: patch
Fix For: 2.15.2, 2.16.0
Suppose SMSC allowed one connection to client and due to any reason if
session.unbindAndClose failed it will set session to null and dont retry to
unbind.
Connection/Session will remain open on SMSC till its TransactionTimeOut,
mostly SMSc Admin set it to 5 to 10 mins.
Following are snippet of org.apache.camel.component.smpp.SmppProducer and
details are like
1- if for any reason Camel try to unbind connection and it got failed below
code print log and set session=null in both success/fail cases.
2- After sending unbind it will try to reconnect.
3- As SMSc allowed 1 connection which was not unbinded successfull it will
not allowed second connection so reconnect will get failed.
4- Camel call closesession on reconnection failure and will verify if session
!= null, as session is already null so this code will not send unbind again
and apache camel will not able to get connection from SMSc until timeout
happen on SMSc and this will results in 10 mins outage.
If we change closeSession() like below
current:
{code}
private void closeSession() {
if (session != null) {
session.removeSessionStateListener(this.internalSessionStateListener);
try {
Thread.sleep(1000);
session.unbindAndClose();
} catch (Exception e) {
LOG.warn(Could not close session + session);
}
session = null;
}
}
{code}
Suggested:
{code}
private void closeSession() {
if (session != null) {
session.removeSessionStateListener(this.internalSessionStateListener);
try {
Thread.sleep(1000);
session.unbindAndClose();
session = null; // if we put here then it will retry for
unbind
} catch (Exception e) {
LOG.warn(Could not close session + session);
}
session = null; // remove his line
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-9035) unbind smpp connection bug
[
https://issues.apache.org/jira/browse/CAMEL-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-9035:
--
Assignee: Claus Ibsen
unbind smpp connection bug
---
Key: CAMEL-9035
URL: https://issues.apache.org/jira/browse/CAMEL-9035
Project: Camel
Issue Type: Bug
Components: camel-smpp
Affects Versions: 2.14.0, 2.15.2
Reporter: imran raza khan
Assignee: Claus Ibsen
Labels: patch
Fix For: 2.15.2, 2.16.0
Suppose SMSC allowed one connection to client and due to any reason if
session.unbindAndClose failed it will set session to null and dont retry to
unbind.
Connection/Session will remain open on SMSC till its TransactionTimeOut,
mostly SMSc Admin set it to 5 to 10 mins.
Following are snippet of org.apache.camel.component.smpp.SmppProducer and
details are like
1- if for any reason Camel try to unbind connection and it got failed below
code print log and set session=null in both success/fail cases.
2- After sending unbind it will try to reconnect.
3- As SMSc allowed 1 connection which was not unbinded successfull it will
not allowed second connection so reconnect will get failed.
4- Camel call closesession on reconnection failure and will verify if session
!= null, as session is already null so this code will not send unbind again
and apache camel will not able to get connection from SMSc until timeout
happen on SMSc and this will results in 10 mins outage.
If we change closeSession() like below
current:
{code}
private void closeSession() {
if (session != null) {
session.removeSessionStateListener(this.internalSessionStateListener);
try {
Thread.sleep(1000);
session.unbindAndClose();
} catch (Exception e) {
LOG.warn(Could not close session + session);
}
session = null;
}
}
{code}
Suggested:
{code}
private void closeSession() {
if (session != null) {
session.removeSessionStateListener(this.internalSessionStateListener);
try {
Thread.sleep(1000);
session.unbindAndClose();
session = null; // if we put here then it will retry for
unbind
} catch (Exception e) {
LOG.warn(Could not close session + session);
}
session = null; // remove his line
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9035) unbind smpp connection bug
[
https://issues.apache.org/jira/browse/CAMEL-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-9035.
Resolution: Fixed
Fix Version/s: (was: 2.15.2)
2.15.3
Thanks for the patch.
unbind smpp connection bug
---
Key: CAMEL-9035
URL: https://issues.apache.org/jira/browse/CAMEL-9035
Project: Camel
Issue Type: Bug
Components: camel-smpp
Affects Versions: 2.14.0, 2.15.2
Reporter: imran raza khan
Assignee: Claus Ibsen
Priority: Minor
Labels: patch
Fix For: 2.16.0, 2.15.3
Suppose SMSC allowed one connection to client and due to any reason if
session.unbindAndClose failed it will set session to null and dont retry to
unbind.
Connection/Session will remain open on SMSC till its TransactionTimeOut,
mostly SMSc Admin set it to 5 to 10 mins.
Following are snippet of org.apache.camel.component.smpp.SmppProducer and
details are like
1- if for any reason Camel try to unbind connection and it got failed below
code print log and set session=null in both success/fail cases.
2- After sending unbind it will try to reconnect.
3- As SMSc allowed 1 connection which was not unbinded successfull it will
not allowed second connection so reconnect will get failed.
4- Camel call closesession on reconnection failure and will verify if session
!= null, as session is already null so this code will not send unbind again
and apache camel will not able to get connection from SMSc until timeout
happen on SMSc and this will results in 10 mins outage.
If we change closeSession() like below
current:
{code}
private void closeSession() {
if (session != null) {
session.removeSessionStateListener(this.internalSessionStateListener);
try {
Thread.sleep(1000);
session.unbindAndClose();
} catch (Exception e) {
LOG.warn(Could not close session + session);
}
session = null;
}
}
{code}
Suggested:
{code}
private void closeSession() {
if (session != null) {
session.removeSessionStateListener(this.internalSessionStateListener);
try {
Thread.sleep(1000);
session.unbindAndClose();
session = null; // if we put here then it will retry for
unbind
} catch (Exception e) {
LOG.warn(Could not close session + session);
}
session = null; // remove his line
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7985) camel-test-blueprint - Upgrading to newer felix fails with NPE in fileinstall
[
https://issues.apache.org/jira/browse/CAMEL-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7985:
---
Fix Version/s: 2.15.3
camel-test-blueprint - Upgrading to newer felix fails with NPE in fileinstall
-
Key: CAMEL-7985
URL: https://issues.apache.org/jira/browse/CAMEL-7985
Project: Camel
Issue Type: Improvement
Components: camel-blueprint, camel-test
Affects Versions: 2.14.0
Reporter: Claus Ibsen
Assignee: Grzegorz Grzybek
Priority: Minor
Fix For: 2.16.0, 2.15.3
Attachments: Screen Shot 2014-10-30 at 11.44.58 AM.png
We get a bunch of these errors during testing with osgi blueprint
{code}
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
{code}
Run tests here
{code}
camel/tests/camel-blueprint-cxf-test (master)/$ mvn clean install
{code}
And upgrade Felix in parent/pom.xml
{code}
-felix-configadmin-version1.4.0/felix-configadmin-version
-felix-fileinstall-version3.2.6/felix-fileinstall-version
-felix-framework-version3.2.2/felix-framework-version
+felix-configadmin-version1.8.0/felix-configadmin-version
+felix-fileinstall-version3.4.2/felix-fileinstall-version
+felix-framework-version3.4.2/felix-framework-version
{code}
And you get these NPEs.
Maybe something needs to be fixed in camel-test-blueprint with that pojosr
library, so bundle 0 is that system bundle, as the NPE is at:
https://github.com/apache/felix/blame/trunk/fileinstall/src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java#L303
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-9037) DefaultJmsMessageListenerContainer leaks threads
[ https://issues.apache.org/jira/browse/CAMEL-9037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-9037: -- Assignee: Claus Ibsen DefaultJmsMessageListenerContainer leaks threads Key: CAMEL-9037 URL: https://issues.apache.org/jira/browse/CAMEL-9037 Project: Camel Issue Type: Bug Components: camel-jms Affects Versions: 2.12.3 Reporter: shpelda2 Assignee: Claus Ibsen Fix For: 2.16.0, 2.15.3 Threads created by DefaultTaskExecutorType.ThreadPool at org.apache.camel.component.jms.DefaultJmsMessageListenerContainer.createDefaultTaskExecutor() are never stopped, as destroy method is never called on the ThreadPoolTaskExecutor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9037) DefaultJmsMessageListenerContainer leaks threads
[ https://issues.apache.org/jira/browse/CAMEL-9037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9037: --- Fix Version/s: 2.15.3 2.16.0 DefaultJmsMessageListenerContainer leaks threads Key: CAMEL-9037 URL: https://issues.apache.org/jira/browse/CAMEL-9037 Project: Camel Issue Type: Bug Components: camel-jms Affects Versions: 2.12.3 Reporter: shpelda2 Fix For: 2.16.0, 2.15.3 Threads created by DefaultTaskExecutorType.ThreadPool at org.apache.camel.component.jms.DefaultJmsMessageListenerContainer.createDefaultTaskExecutor() are never stopped, as destroy method is never called on the ThreadPoolTaskExecutor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
