[jira] [Resolved] (CAMEL-14049) camel-netty - Should include scheme in its endpoint url when creating endpoint
[ https://issues.apache.org/jira/browse/CAMEL-14049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-14049. - Resolution: Fixed > camel-netty - Should include scheme in its endpoint url when creating endpoint > -- > > Key: CAMEL-14049 > URL: https://issues.apache.org/jira/browse/CAMEL-14049 > Project: Camel > Issue Type: Improvement > Components: camel-netty >Affects Versions: 3.0.0.RC2 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.0.0 > > > It skip having netty in the uri so it is just tcp|udp:host etc for historical > reasons, but Camel components should include its scheme in endpoint uri, like > all the other component does -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14048) camel-core - ServicePool should wait while starting service when acquiring
[ https://issues.apache.org/jira/browse/CAMEL-14048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-14048. - Resolution: Fixed > camel-core - ServicePool should wait while starting service when acquiring > -- > > Key: CAMEL-14048 > URL: https://issues.apache.org/jira/browse/CAMEL-14048 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 3.0.0.RC2 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.0.0 > > > If using concurrency then producer template / producer cache may concurrently > acquire a producer from same endpoint, and while it may be starting up the > pool should wait for it to be ready before handing it out. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-11750) Camel route with multicast (parallel) generate huge CPU load
[
https://issues.apache.org/jira/browse/CAMEL-11750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948377#comment-16948377
]
Claus Ibsen commented on CAMEL-11750:
-
Thanks [~vzinkevich] are you able to submit a fix as a github PR ?
> Camel route with multicast (parallel) generate huge CPU load
>
>
> Key: CAMEL-11750
> URL: https://issues.apache.org/jira/browse/CAMEL-11750
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.18.4, 2.19.2
>Reporter: Nazar Vishka
>Assignee: Claus Ibsen
>Priority: Critical
> Fix For: 2.18.5, 2.19.3, 2.20.0
>
>
> I've created simple [Spring Camel Route
> application|https://github.com/leofromgroza/camel-long-term-route] that can
> be used for issue reproducing. Here we have very simple route:
> {code}
> public void configure() throws Exception {
> from("direct:start").routeId("start")
> .multicast().parallelProcessing()
> .to("direct:very-long-task", "direct:long-task")
> .end();
> from("direct:long-task").routeId("long-task")
> .log("Started long-task")
> .process(exchange -> Thread.sleep(5000))
> .log("Finished long-task")
> .end();
> from("direct:very-long-task").routeId("very-long-task")
> .log("Started very-long-task")
> .process(exchange -> Thread.sleep(35000))
> .log("Finished very-long-task")
> .end();
> }{code}
> From our main route 'start' we are starting in parallel two sub-routes:
> 'long-task' and 'very-long-task'. They are just doing something for some
> period of time and do not generate any load to the system.
> But I found that when one task finished earlier than other one, route start
> to make a huge CPU load. Here you can see a CPU usage during executiong of
> Camel route that was mentioned earlier (after finishing of 'long-task' usage
> of CPU uncreased from 0 to 12.5%):
> !https://content.screencast.com/users/NazarV/folders/Jing/media/830268f0-d184-4c57-adb1-b782ea63fa6d/2017-09-06_1241.png!
> Screenshot was made when I was running route on my Windows PC with 4 physical
> CPU cores + 4 HT. On Unix systems we found that after end of 'long-task' it
> used 100% of one core till the end of work.
> One more interesting thing that i've found is that the main load on the
> system was generated by the thread MulticastProcessor-AggregateTask that was
> spending a lot of time in the method
> java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#awaitNanos
> that was called from java.util.concurrent.DelayQueue#poll(long,
> java.util.concurrent.TimeUnit):
> {code}"Camel (camel-1) thread #2 - MulticastProcessor-AggregateTask" #29
> daemon prio=5 os_prio=0 tid=0x215e3000 nid=0x7a0 runnable
> [0x22eaf000]
>java.lang.Thread.State: RUNNABLE
> at java.lang.Thread.isInterrupted(Native Method)
> at java.lang.Thread.interrupted(Thread.java:944)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.checkInterruptWhileWaiting(AbstractQueuedSynchronizer.java:2002)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2079)
> at java.util.concurrent.DelayQueue.poll(DelayQueue.java:273)
> at
> org.apache.camel.util.concurrent.SubmitOrderedCompletionService.poll(SubmitOrderedCompletionService.java:127)
> at
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.aggregateOnTheFly(MulticastProcessor.java:463)
> at
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.run(MulticastProcessor.java:418)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745){code}
> In DelayQueue#poll(long, java.util.concurrent.TimeUnit) we have a piece of
> code:
> {code}E first = q.peek();
> if (first == null) {
> ...
> } else {
> long delay = first.getDelay(NANOSECONDS);
> ...
> long timeLeft = available.awaitNanos(delay) {code}
> During debugging I found that E first is object of class
> [org.apache.camel.util.concurrent.SubmitOrderedCompletionService.SubmitOrderFutureTask|https://github.com/apache/camel/blob/camel-2.19.2/camel-core/src/main/java/org/apache/camel/util/concurrent/SubmitOrderedCompletionService.java]
> and it's very interesting [getDelay(TimeUnit)
[jira] [Commented] (CAMEL-11750) Camel route with multicast (parallel) generate huge CPU load
[
https://issues.apache.org/jira/browse/CAMEL-11750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948428#comment-16948428
]
Claus Ibsen commented on CAMEL-11750:
-
Yeah its fine to 1001 and then maybe just add a little code comment above why
we do this
> Camel route with multicast (parallel) generate huge CPU load
>
>
> Key: CAMEL-11750
> URL: https://issues.apache.org/jira/browse/CAMEL-11750
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.18.4, 2.19.2
>Reporter: Nazar Vishka
>Assignee: Claus Ibsen
>Priority: Critical
> Fix For: 2.18.5, 2.19.3, 2.20.0
>
>
> I've created simple [Spring Camel Route
> application|https://github.com/leofromgroza/camel-long-term-route] that can
> be used for issue reproducing. Here we have very simple route:
> {code}
> public void configure() throws Exception {
> from("direct:start").routeId("start")
> .multicast().parallelProcessing()
> .to("direct:very-long-task", "direct:long-task")
> .end();
> from("direct:long-task").routeId("long-task")
> .log("Started long-task")
> .process(exchange -> Thread.sleep(5000))
> .log("Finished long-task")
> .end();
> from("direct:very-long-task").routeId("very-long-task")
> .log("Started very-long-task")
> .process(exchange -> Thread.sleep(35000))
> .log("Finished very-long-task")
> .end();
> }{code}
> From our main route 'start' we are starting in parallel two sub-routes:
> 'long-task' and 'very-long-task'. They are just doing something for some
> period of time and do not generate any load to the system.
> But I found that when one task finished earlier than other one, route start
> to make a huge CPU load. Here you can see a CPU usage during executiong of
> Camel route that was mentioned earlier (after finishing of 'long-task' usage
> of CPU uncreased from 0 to 12.5%):
> !https://content.screencast.com/users/NazarV/folders/Jing/media/830268f0-d184-4c57-adb1-b782ea63fa6d/2017-09-06_1241.png!
> Screenshot was made when I was running route on my Windows PC with 4 physical
> CPU cores + 4 HT. On Unix systems we found that after end of 'long-task' it
> used 100% of one core till the end of work.
> One more interesting thing that i've found is that the main load on the
> system was generated by the thread MulticastProcessor-AggregateTask that was
> spending a lot of time in the method
> java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#awaitNanos
> that was called from java.util.concurrent.DelayQueue#poll(long,
> java.util.concurrent.TimeUnit):
> {code}"Camel (camel-1) thread #2 - MulticastProcessor-AggregateTask" #29
> daemon prio=5 os_prio=0 tid=0x215e3000 nid=0x7a0 runnable
> [0x22eaf000]
>java.lang.Thread.State: RUNNABLE
> at java.lang.Thread.isInterrupted(Native Method)
> at java.lang.Thread.interrupted(Thread.java:944)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.checkInterruptWhileWaiting(AbstractQueuedSynchronizer.java:2002)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2079)
> at java.util.concurrent.DelayQueue.poll(DelayQueue.java:273)
> at
> org.apache.camel.util.concurrent.SubmitOrderedCompletionService.poll(SubmitOrderedCompletionService.java:127)
> at
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.aggregateOnTheFly(MulticastProcessor.java:463)
> at
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.run(MulticastProcessor.java:418)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745){code}
> In DelayQueue#poll(long, java.util.concurrent.TimeUnit) we have a piece of
> code:
> {code}E first = q.peek();
> if (first == null) {
> ...
> } else {
> long delay = first.getDelay(NANOSECONDS);
> ...
> long timeLeft = available.awaitNanos(delay) {code}
> During debugging I found that E first is object of class
> [org.apache.camel.util.concurrent.SubmitOrderedCompletionService.SubmitOrderFutureTask|https://github.com/apache/camel/blob/camel-2.19.2/camel-core/src/main/java/org/apache/camel/util/concurrent/SubmitOrderedCompletionService.java]
> and it's very
[jira] [Created] (CAMEL-14052) camel-paho - Make it possible to configure userName, password from application.properties
Claus Ibsen created CAMEL-14052: --- Summary: camel-paho - Make it possible to configure userName, password from application.properties Key: CAMEL-14052 URL: https://issues.apache.org/jira/browse/CAMEL-14052 Project: Camel Issue Type: Improvement Components: camel-paho Affects Versions: 3.0.0.RC2 Reporter: Claus Ibsen Fix For: 3.0.0 When using spring boot then the connectorOptions is null, so when you do camel.component.paho.brokerUrl=tcp://localhost:61617 camel.component.paho.connectOptions.userName=admin camel.component.paho.connectOptions.password=admin123. It will fail -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14051) camel-ftp - receiveBufferSize is actually also used for producer
Claus Ibsen created CAMEL-14051: --- Summary: camel-ftp - receiveBufferSize is actually also used for producer Key: CAMEL-14051 URL: https://issues.apache.org/jira/browse/CAMEL-14051 Project: Camel Issue Type: Improvement Components: camel-ftp Reporter: Claus Ibsen Fix For: 3.0.0 The receiveBufferSize was intended for consumer only when it was added, but the ftp client uses it also for producer. And therefore we can use the existing bufferSize from file endpoint (ftp extend file) and then deprecate receiveBufferSize. Mind that this buffer size is larger (128kb) but that is the size the file component uses too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14027) Camel-Netty-Http: NettyHttpStreamTest is failing consistently
[
https://issues.apache.org/jira/browse/CAMEL-14027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino updated CAMEL-14027:
-
Fix Version/s: 3.0.0.RC3
> Camel-Netty-Http: NettyHttpStreamTest is failing consistently
> -
>
> Key: CAMEL-14027
> URL: https://issues.apache.org/jira/browse/CAMEL-14027
> Project: Camel
> Issue Type: Bug
> Components: camel-netty-http
>Affects Versions: 3.0.0.RC2
>Reporter: Andrea Cosentino
>Assignee: Zheng Feng
>Priority: Major
> Fix For: 3.0.0, 3.0.0.RC3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> [INFO] Running
> org.apache.camel.component.netty.http.NettyHttpStreamTest[INFO] Running
> org.apache.camel.component.netty.http.NettyHttpStreamTest[ERROR] Tests run:
> 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.482 s <<< FAILURE! -
> in org.apache.camel.component.netty.http.NettyHttpStreamTest[ERROR]
> org.apache.camel.component.netty.http.NettyHttpStreamTest Time elapsed:
> 0.345 s <<< FAILURE!java.lang.AssertionError: Leaks detected while running
> tests: Logger=io.netty.util.ResourceLeakDetector Level=ERROR Message=LEAK:
> ByteBuf.release() was not called before it's garbage-collected. See
> https://netty.io/wiki/reference-counted-objects.html for more
> information.Recent access records: #1:
> io.netty.handler.codec.http.HttpObjectAggregator$AggregatedFullHttpMessage.release(HttpObjectAggregator.java:379)
> io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:88)
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:112)
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
>
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:56)
>
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:365)
>
> io.netty.util.concurrent.DefaultEventExecutor.run(DefaultEventExecutor.java:66)
>
> io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1044)
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> java.lang.Thread.run(Thread.java:748)#2:
> io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.retain(AdvancedLeakAwareCompositeByteBuf.java:36)
>
> org.apache.camel.component.netty.http.DefaultNettyHttpBinding.toCamelMessage(DefaultNettyHttpBinding.java:104)
>
> org.apache.camel.component.netty.http.NettyHttpEndpoint.createExchange(NettyHttpEndpoint.java:121)
>
> org.apache.camel.component.netty.handlers.ServerChannelHandler.channelRead0(ServerChannelHandler.java:91)
>
> org.apache.camel.component.netty.http.handlers.HttpServerChannelHandler.channelRead0(HttpServerChannelHandler.java:202)
>
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>
> org.apache.camel.component.netty.http.handlers.HttpServerMultiplexChannelHandler.channelRead0(HttpServerMultiplexChannelHandler.java:156)
>
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
>
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:56)
>
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:365)
>
> io.netty.util.concurrent.DefaultEventExecutor.run(DefaultEventExecutor.java:66)
>
> io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1044)
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> java.lang.Thread.run(Thread.java:748)#3:
> io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.retain(AdvancedLeakAwareCompositeByteBuf.java:36)
>
> org.apache.camel.component.netty.http.handlers.HttpServerMultiplexChannelHandler.channelRead0(HttpServerMultiplexChannelHandler.java:154)
>
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
>
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:56)
>
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:365)
>
> io.netty.util.concurrent.DefaultEventExecutor.run(DefaultEventExecutor.java:66)
>
> io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1044)
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> java.lang.Thread.run(Thread.java:748)#4: Hint: 'handler' will handle the
> message
[jira] [Commented] (CAMEL-11750) Camel route with multicast (parallel) generate huge CPU load
[
https://issues.apache.org/jira/browse/CAMEL-11750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948381#comment-16948381
]
Viachaslau Zinkevich commented on CAMEL-11750:
--
[~davsclaus] will do! I'm planning to do a quick fix to avoid those 1000L value
to just be as 1001L. Looks like a hack, but it will suffice I guess...
> Camel route with multicast (parallel) generate huge CPU load
>
>
> Key: CAMEL-11750
> URL: https://issues.apache.org/jira/browse/CAMEL-11750
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.18.4, 2.19.2
>Reporter: Nazar Vishka
>Assignee: Claus Ibsen
>Priority: Critical
> Fix For: 2.18.5, 2.19.3, 2.20.0
>
>
> I've created simple [Spring Camel Route
> application|https://github.com/leofromgroza/camel-long-term-route] that can
> be used for issue reproducing. Here we have very simple route:
> {code}
> public void configure() throws Exception {
> from("direct:start").routeId("start")
> .multicast().parallelProcessing()
> .to("direct:very-long-task", "direct:long-task")
> .end();
> from("direct:long-task").routeId("long-task")
> .log("Started long-task")
> .process(exchange -> Thread.sleep(5000))
> .log("Finished long-task")
> .end();
> from("direct:very-long-task").routeId("very-long-task")
> .log("Started very-long-task")
> .process(exchange -> Thread.sleep(35000))
> .log("Finished very-long-task")
> .end();
> }{code}
> From our main route 'start' we are starting in parallel two sub-routes:
> 'long-task' and 'very-long-task'. They are just doing something for some
> period of time and do not generate any load to the system.
> But I found that when one task finished earlier than other one, route start
> to make a huge CPU load. Here you can see a CPU usage during executiong of
> Camel route that was mentioned earlier (after finishing of 'long-task' usage
> of CPU uncreased from 0 to 12.5%):
> !https://content.screencast.com/users/NazarV/folders/Jing/media/830268f0-d184-4c57-adb1-b782ea63fa6d/2017-09-06_1241.png!
> Screenshot was made when I was running route on my Windows PC with 4 physical
> CPU cores + 4 HT. On Unix systems we found that after end of 'long-task' it
> used 100% of one core till the end of work.
> One more interesting thing that i've found is that the main load on the
> system was generated by the thread MulticastProcessor-AggregateTask that was
> spending a lot of time in the method
> java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#awaitNanos
> that was called from java.util.concurrent.DelayQueue#poll(long,
> java.util.concurrent.TimeUnit):
> {code}"Camel (camel-1) thread #2 - MulticastProcessor-AggregateTask" #29
> daemon prio=5 os_prio=0 tid=0x215e3000 nid=0x7a0 runnable
> [0x22eaf000]
>java.lang.Thread.State: RUNNABLE
> at java.lang.Thread.isInterrupted(Native Method)
> at java.lang.Thread.interrupted(Thread.java:944)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.checkInterruptWhileWaiting(AbstractQueuedSynchronizer.java:2002)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2079)
> at java.util.concurrent.DelayQueue.poll(DelayQueue.java:273)
> at
> org.apache.camel.util.concurrent.SubmitOrderedCompletionService.poll(SubmitOrderedCompletionService.java:127)
> at
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.aggregateOnTheFly(MulticastProcessor.java:463)
> at
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.run(MulticastProcessor.java:418)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745){code}
> In DelayQueue#poll(long, java.util.concurrent.TimeUnit) we have a piece of
> code:
> {code}E first = q.peek();
> if (first == null) {
> ...
> } else {
> long delay = first.getDelay(NANOSECONDS);
> ...
> long timeLeft = available.awaitNanos(delay) {code}
> During debugging I found that E first is object of class
>
[jira] [Work logged] (CAMEL-14027) Camel-Netty-Http: NettyHttpStreamTest is failing consistently
[
https://issues.apache.org/jira/browse/CAMEL-14027?focusedWorklogId=326164=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-326164
]
ASF GitHub Bot logged work on CAMEL-14027:
--
Author: ASF GitHub Bot
Created on: 10/Oct/19 08:00
Start Date: 10/Oct/19 08:00
Worklog Time Spent: 10m
Work Description: oscerd commented on pull request #3231: CAMEL-14027
Update to fix the NettyHttpStreamTest to release the buffer
URL: https://github.com/apache/camel/pull/3231
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 326164)
Time Spent: 20m (was: 10m)
> Camel-Netty-Http: NettyHttpStreamTest is failing consistently
> -
>
> Key: CAMEL-14027
> URL: https://issues.apache.org/jira/browse/CAMEL-14027
> Project: Camel
> Issue Type: Bug
> Components: camel-netty-http
>Affects Versions: 3.0.0.RC2
>Reporter: Andrea Cosentino
>Assignee: Zheng Feng
>Priority: Major
> Fix For: 3.0.0, 3.0.0.RC3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> [INFO] Running
> org.apache.camel.component.netty.http.NettyHttpStreamTest[INFO] Running
> org.apache.camel.component.netty.http.NettyHttpStreamTest[ERROR] Tests run:
> 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.482 s <<< FAILURE! -
> in org.apache.camel.component.netty.http.NettyHttpStreamTest[ERROR]
> org.apache.camel.component.netty.http.NettyHttpStreamTest Time elapsed:
> 0.345 s <<< FAILURE!java.lang.AssertionError: Leaks detected while running
> tests: Logger=io.netty.util.ResourceLeakDetector Level=ERROR Message=LEAK:
> ByteBuf.release() was not called before it's garbage-collected. See
> https://netty.io/wiki/reference-counted-objects.html for more
> information.Recent access records: #1:
> io.netty.handler.codec.http.HttpObjectAggregator$AggregatedFullHttpMessage.release(HttpObjectAggregator.java:379)
> io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:88)
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:112)
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
>
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:56)
>
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:365)
>
> io.netty.util.concurrent.DefaultEventExecutor.run(DefaultEventExecutor.java:66)
>
> io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1044)
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> java.lang.Thread.run(Thread.java:748)#2:
> io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.retain(AdvancedLeakAwareCompositeByteBuf.java:36)
>
> org.apache.camel.component.netty.http.DefaultNettyHttpBinding.toCamelMessage(DefaultNettyHttpBinding.java:104)
>
> org.apache.camel.component.netty.http.NettyHttpEndpoint.createExchange(NettyHttpEndpoint.java:121)
>
> org.apache.camel.component.netty.handlers.ServerChannelHandler.channelRead0(ServerChannelHandler.java:91)
>
> org.apache.camel.component.netty.http.handlers.HttpServerChannelHandler.channelRead0(HttpServerChannelHandler.java:202)
>
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>
> org.apache.camel.component.netty.http.handlers.HttpServerMultiplexChannelHandler.channelRead0(HttpServerMultiplexChannelHandler.java:156)
>
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
>
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:56)
>
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:365)
>
> io.netty.util.concurrent.DefaultEventExecutor.run(DefaultEventExecutor.java:66)
>
> io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1044)
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> java.lang.Thread.run(Thread.java:748)#3:
> io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.retain(AdvancedLeakAwareCompositeByteBuf.java:36)
>
>
[jira] [Resolved] (CAMEL-14027) Camel-Netty-Http: NettyHttpStreamTest is failing consistently
[
https://issues.apache.org/jira/browse/CAMEL-14027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino resolved CAMEL-14027.
--
Resolution: Fixed
> Camel-Netty-Http: NettyHttpStreamTest is failing consistently
> -
>
> Key: CAMEL-14027
> URL: https://issues.apache.org/jira/browse/CAMEL-14027
> Project: Camel
> Issue Type: Bug
> Components: camel-netty-http
>Affects Versions: 3.0.0.RC2
>Reporter: Andrea Cosentino
>Assignee: Zheng Feng
>Priority: Major
> Fix For: 3.0.0, 3.0.0.RC3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> [INFO] Running
> org.apache.camel.component.netty.http.NettyHttpStreamTest[INFO] Running
> org.apache.camel.component.netty.http.NettyHttpStreamTest[ERROR] Tests run:
> 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.482 s <<< FAILURE! -
> in org.apache.camel.component.netty.http.NettyHttpStreamTest[ERROR]
> org.apache.camel.component.netty.http.NettyHttpStreamTest Time elapsed:
> 0.345 s <<< FAILURE!java.lang.AssertionError: Leaks detected while running
> tests: Logger=io.netty.util.ResourceLeakDetector Level=ERROR Message=LEAK:
> ByteBuf.release() was not called before it's garbage-collected. See
> https://netty.io/wiki/reference-counted-objects.html for more
> information.Recent access records: #1:
> io.netty.handler.codec.http.HttpObjectAggregator$AggregatedFullHttpMessage.release(HttpObjectAggregator.java:379)
> io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:88)
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:112)
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
>
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:56)
>
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:365)
>
> io.netty.util.concurrent.DefaultEventExecutor.run(DefaultEventExecutor.java:66)
>
> io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1044)
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> java.lang.Thread.run(Thread.java:748)#2:
> io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.retain(AdvancedLeakAwareCompositeByteBuf.java:36)
>
> org.apache.camel.component.netty.http.DefaultNettyHttpBinding.toCamelMessage(DefaultNettyHttpBinding.java:104)
>
> org.apache.camel.component.netty.http.NettyHttpEndpoint.createExchange(NettyHttpEndpoint.java:121)
>
> org.apache.camel.component.netty.handlers.ServerChannelHandler.channelRead0(ServerChannelHandler.java:91)
>
> org.apache.camel.component.netty.http.handlers.HttpServerChannelHandler.channelRead0(HttpServerChannelHandler.java:202)
>
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>
> org.apache.camel.component.netty.http.handlers.HttpServerMultiplexChannelHandler.channelRead0(HttpServerMultiplexChannelHandler.java:156)
>
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
>
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:56)
>
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:365)
>
> io.netty.util.concurrent.DefaultEventExecutor.run(DefaultEventExecutor.java:66)
>
> io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1044)
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> java.lang.Thread.run(Thread.java:748)#3:
> io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.retain(AdvancedLeakAwareCompositeByteBuf.java:36)
>
> org.apache.camel.component.netty.http.handlers.HttpServerMultiplexChannelHandler.channelRead0(HttpServerMultiplexChannelHandler.java:154)
>
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
>
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:56)
>
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:365)
>
> io.netty.util.concurrent.DefaultEventExecutor.run(DefaultEventExecutor.java:66)
>
> io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1044)
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> java.lang.Thread.run(Thread.java:748)#4: Hint: 'handler' will handle the
> message from
[jira] [Created] (CAMEL-14050) camel-main - Add logic for automatic RouteBuilder class detection ala camel-spring-boot has
Claus Ibsen created CAMEL-14050: --- Summary: camel-main - Add logic for automatic RouteBuilder class detection ala camel-spring-boot has Key: CAMEL-14050 URL: https://issues.apache.org/jira/browse/CAMEL-14050 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 3.0.0.RC2 Reporter: Claus Ibsen Fix For: 3.0.0 On spring boot we have some options to filter routes and set the location of xml routes/rests: https://github.com/apache/camel/blob/master/components/camel-spring-boot/src/main/java/org/apache/camel/spring/boot/CamelConfigurationProperties.java#L50-L98 And also it has automatic route builder detection from registry. We should add that. Then we can move this logic to came-main in general and let camel-spring-boot use that, which then also makes it available for camel-quarkus and others. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-11750) Camel route with multicast (parallel) generate huge CPU load
[
https://issues.apache.org/jira/browse/CAMEL-11750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948369#comment-16948369
]
Viachaslau Zinkevich commented on CAMEL-11750:
--
[~davsclaus] hi, this appeared to be an issue with java 11 due to minor, but
affecting changes to
java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#awaitNanos.
In java 8 the condition to wait was
`
{color:#80}if {color}(nanosTimeout >=
{color:#660e7a}SPIN_FOR_TIMEOUT_THRESHOLD{color})
`
but got changed to
`
{color:#80}if {color}(nanosTimeout >
{color:#660e7a}SPIN_FOR_TIMEOUT_THRESHOLD{color})
`
And this is breaking change for Camel, because
{color:#660e7a}SPIN_FOR_TIMEOUT_THRESHOLD{color} = 1000L and
org.apache.camel.util.concurrent.SubmitOrderedCompletionService.SubmitOrderFutureTask#getDelay
returns 1000 as well, when called with NANOSECONDS.
If the values is 1001 for example, it works fine, otherwise the CPU is highly
loaded.
> Camel route with multicast (parallel) generate huge CPU load
>
>
> Key: CAMEL-11750
> URL: https://issues.apache.org/jira/browse/CAMEL-11750
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.18.4, 2.19.2
>Reporter: Nazar Vishka
>Assignee: Claus Ibsen
>Priority: Critical
> Fix For: 2.18.5, 2.19.3, 2.20.0
>
>
> I've created simple [Spring Camel Route
> application|https://github.com/leofromgroza/camel-long-term-route] that can
> be used for issue reproducing. Here we have very simple route:
> {code}
> public void configure() throws Exception {
> from("direct:start").routeId("start")
> .multicast().parallelProcessing()
> .to("direct:very-long-task", "direct:long-task")
> .end();
> from("direct:long-task").routeId("long-task")
> .log("Started long-task")
> .process(exchange -> Thread.sleep(5000))
> .log("Finished long-task")
> .end();
> from("direct:very-long-task").routeId("very-long-task")
> .log("Started very-long-task")
> .process(exchange -> Thread.sleep(35000))
> .log("Finished very-long-task")
> .end();
> }{code}
> From our main route 'start' we are starting in parallel two sub-routes:
> 'long-task' and 'very-long-task'. They are just doing something for some
> period of time and do not generate any load to the system.
> But I found that when one task finished earlier than other one, route start
> to make a huge CPU load. Here you can see a CPU usage during executiong of
> Camel route that was mentioned earlier (after finishing of 'long-task' usage
> of CPU uncreased from 0 to 12.5%):
> !https://content.screencast.com/users/NazarV/folders/Jing/media/830268f0-d184-4c57-adb1-b782ea63fa6d/2017-09-06_1241.png!
> Screenshot was made when I was running route on my Windows PC with 4 physical
> CPU cores + 4 HT. On Unix systems we found that after end of 'long-task' it
> used 100% of one core till the end of work.
> One more interesting thing that i've found is that the main load on the
> system was generated by the thread MulticastProcessor-AggregateTask that was
> spending a lot of time in the method
> java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#awaitNanos
> that was called from java.util.concurrent.DelayQueue#poll(long,
> java.util.concurrent.TimeUnit):
> {code}"Camel (camel-1) thread #2 - MulticastProcessor-AggregateTask" #29
> daemon prio=5 os_prio=0 tid=0x215e3000 nid=0x7a0 runnable
> [0x22eaf000]
>java.lang.Thread.State: RUNNABLE
> at java.lang.Thread.isInterrupted(Native Method)
> at java.lang.Thread.interrupted(Thread.java:944)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.checkInterruptWhileWaiting(AbstractQueuedSynchronizer.java:2002)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2079)
> at java.util.concurrent.DelayQueue.poll(DelayQueue.java:273)
> at
> org.apache.camel.util.concurrent.SubmitOrderedCompletionService.poll(SubmitOrderedCompletionService.java:127)
> at
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.aggregateOnTheFly(MulticastProcessor.java:463)
> at
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.run(MulticastProcessor.java:418)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
>
[jira] [Resolved] (CAMEL-14046) Make ValidatorReifier constructor public and add a way to register custom reifiers
[ https://issues.apache.org/jira/browse/CAMEL-14046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved CAMEL-14046. - Resolution: Fixed > Make ValidatorReifier constructor public and add a way to register custom > reifiers > -- > > Key: CAMEL-14046 > URL: https://issues.apache.org/jira/browse/CAMEL-14046 > Project: Camel > Issue Type: Improvement >Affects Versions: 3.0.0.RC2 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14045) Protect against ByteBuffer / CharBuffer inconsistencies between jdk 8 and 9
[
https://issues.apache.org/jira/browse/CAMEL-14045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved CAMEL-14045.
-
Assignee: Guillaume Nodet
Resolution: Fixed
> Protect against ByteBuffer / CharBuffer inconsistencies between jdk 8 and 9
> ---
>
> Key: CAMEL-14045
> URL: https://issues.apache.org/jira/browse/CAMEL-14045
> Project: Camel
> Issue Type: Improvement
>Affects Versions: 3.0.0.RC2
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 3.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When built on JDK 9, some features method calls become broken on JDK 8 such
> as {{ByteBuffer.flip()}} or {{CharBuffer.position(int)}}. We need to protect
> against those problems using something similar to
> [[https://github.com/gnodet/mvnd/blob/master/src/main/java/org/jboss/fuse/mvnd/daemon/BufferCaster.java]]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14053) Routes Loader SPI
Luca Burgazzoli created CAMEL-14053:
---
Summary: Routes Loader SPI
Key: CAMEL-14053
URL: https://issues.apache.org/jira/browse/CAMEL-14053
Project: Camel
Issue Type: New Feature
Components: camel-core-api
Reporter: Luca Burgazzoli
Fix For: 3.x
Both camel-quarkus and camel-k have now a concept of routes loader which allow
to customize how and if routes are loaded in the case of camel-quarkus or to
provide support for routes written in additional languages in the case of
camel-k.
It would be nice to introduce an official SPI in camel and leverage as example
in camel-main, so one could write something like:
{code:java}
Main main = new Main()
main.addRoutes(
"classpath:my.company.MyRouteImpl.class",
"file:/etc/camel/integration.js",
...
);
main.run()
{code}
And loading of the routes is the delegated to a loader discovered by camel
using the SPI mechanic.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (CAMEL-14045) Protect against ByteBuffer / CharBuffer inconsistencies between jdk 8 and 9
[
https://issues.apache.org/jira/browse/CAMEL-14045?focusedWorklogId=326294=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-326294
]
ASF GitHub Bot logged work on CAMEL-14045:
--
Author: ASF GitHub Bot
Created on: 10/Oct/19 13:03
Start Date: 10/Oct/19 13:03
Worklog Time Spent: 10m
Work Description: gnodet commented on pull request #3240: [CAMEL-14045]
Protect against ByteBuffer / CharBuffer inconsistencies…
URL: https://github.com/apache/camel/pull/3240
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 326294)
Time Spent: 20m (was: 10m)
> Protect against ByteBuffer / CharBuffer inconsistencies between jdk 8 and 9
> ---
>
> Key: CAMEL-14045
> URL: https://issues.apache.org/jira/browse/CAMEL-14045
> Project: Camel
> Issue Type: Improvement
>Affects Versions: 3.0.0.RC2
>Reporter: Guillaume Nodet
>Priority: Major
> Fix For: 3.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When built on JDK 9, some features method calls become broken on JDK 8 such
> as {{ByteBuffer.flip()}} or {{CharBuffer.position(int)}}. We need to protect
> against those problems using something similar to
> [[https://github.com/gnodet/mvnd/blob/master/src/main/java/org/jboss/fuse/mvnd/daemon/BufferCaster.java]]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14052) camel-paho - Make it possible to configure userName, password from application.properties
[
https://issues.apache.org/jira/browse/CAMEL-14052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948477#comment-16948477
]
Claus Ibsen commented on CAMEL-14052:
-
As workaround you can do
{code}
@Bean
public MqttConnectOptions myMqttConnectOptions(@Value("myUsername") String
user, @Value("myPassword") String pw) {
MqttConnectOptions mq = new MqttConnectOptions();
mq.setUserName(user);
mq.setPassword(pw.toCharArray());
return mq;
}
{code}
in the spring boot application class etc and in application.properties you can
have the configuration
myUsername=myuser
myPassword=mysecret
> camel-paho - Make it possible to configure userName, password from
> application.properties
> -
>
> Key: CAMEL-14052
> URL: https://issues.apache.org/jira/browse/CAMEL-14052
> Project: Camel
> Issue Type: Improvement
> Components: camel-paho
>Affects Versions: 3.0.0.RC2
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: 3.0.0
>
>
> When using spring boot then the connectorOptions is null, so when you do
> camel.component.paho.brokerUrl=tcp://localhost:61617
> camel.component.paho.connectOptions.userName=admin
> camel.component.paho.connectOptions.password=admin123.
> It will fail
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-14052) camel-paho - Make it possible to configure userName, password from application.properties
[
https://issues.apache.org/jira/browse/CAMEL-14052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948477#comment-16948477
]
Claus Ibsen edited comment on CAMEL-14052 at 10/10/19 11:37 AM:
As workaround you can do
{code}
@Bean
public MqttConnectOptions myMqttConnectOptions(@Value("myUsername") String
user, @Value("myPassword") String pw) {
MqttConnectOptions mq = new MqttConnectOptions();
mq.setUserName(user);
mq.setPassword(pw.toCharArray());
return mq;
}
{code}
in the spring boot application class etc and in application.properties you can
have the configuration
camel.component.paho.connect-options=#myMqttConnectOptions
myUsername=myuser
myPassword=mysecret
was (Author: davsclaus):
As workaround you can do
{code}
@Bean
public MqttConnectOptions myMqttConnectOptions(@Value("myUsername") String
user, @Value("myPassword") String pw) {
MqttConnectOptions mq = new MqttConnectOptions();
mq.setUserName(user);
mq.setPassword(pw.toCharArray());
return mq;
}
{code}
in the spring boot application class etc and in application.properties you can
have the configuration
myUsername=myuser
myPassword=mysecret
> camel-paho - Make it possible to configure userName, password from
> application.properties
> -
>
> Key: CAMEL-14052
> URL: https://issues.apache.org/jira/browse/CAMEL-14052
> Project: Camel
> Issue Type: Improvement
> Components: camel-paho
>Affects Versions: 3.0.0.RC2
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: 3.0.0
>
>
> When using spring boot then the connectorOptions is null, so when you do
> camel.component.paho.brokerUrl=tcp://localhost:61617
> camel.component.paho.connectOptions.userName=admin
> camel.component.paho.connectOptions.password=admin123.
> It will fail
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-14017) camel-netty-http - support the full streaming both on inbound and outbound
[ https://issues.apache.org/jira/browse/CAMEL-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Feng resolved CAMEL-14017. Resolution: Fixed > camel-netty-http - support the full streaming both on inbound and outbound > -- > > Key: CAMEL-14017 > URL: https://issues.apache.org/jira/browse/CAMEL-14017 > Project: Camel > Issue Type: Improvement > Components: camel-netty-http >Reporter: Zheng Feng >Assignee: Zheng Feng >Priority: Major > Fix For: 3.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > As the fix of CAMEL-12983, we can support stream uploading by using the > ChunkedWriterHandler. But on the server side, the consumer still needs to > read all of the content into the FullHttpRequest even when disable the stream > caching. I think it could be useful to support the full streaming both on > inbound and outbound side. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-11750) Camel route with multicast (parallel) generate huge CPU load
[
https://issues.apache.org/jira/browse/CAMEL-11750?focusedWorklogId=326304=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-326304
]
ASF GitHub Bot logged work on CAMEL-11750:
--
Author: ASF GitHub Bot
Created on: 10/Oct/19 13:15
Start Date: 10/Oct/19 13:15
Worklog Time Spent: 10m
Work Description: Viachaslau-Zinkevich commented on pull request #3241:
CAMEL-11750: Fix delay alignment for java 11
URL: https://github.com/apache/camel/pull/3241
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 326304)
Remaining Estimate: 0h
Time Spent: 10m
> Camel route with multicast (parallel) generate huge CPU load
>
>
> Key: CAMEL-11750
> URL: https://issues.apache.org/jira/browse/CAMEL-11750
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.18.4, 2.19.2
>Reporter: Nazar Vishka
>Assignee: Claus Ibsen
>Priority: Critical
> Fix For: 2.18.5, 2.19.3, 2.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I've created simple [Spring Camel Route
> application|https://github.com/leofromgroza/camel-long-term-route] that can
> be used for issue reproducing. Here we have very simple route:
> {code}
> public void configure() throws Exception {
> from("direct:start").routeId("start")
> .multicast().parallelProcessing()
> .to("direct:very-long-task", "direct:long-task")
> .end();
> from("direct:long-task").routeId("long-task")
> .log("Started long-task")
> .process(exchange -> Thread.sleep(5000))
> .log("Finished long-task")
> .end();
> from("direct:very-long-task").routeId("very-long-task")
> .log("Started very-long-task")
> .process(exchange -> Thread.sleep(35000))
> .log("Finished very-long-task")
> .end();
> }{code}
> From our main route 'start' we are starting in parallel two sub-routes:
> 'long-task' and 'very-long-task'. They are just doing something for some
> period of time and do not generate any load to the system.
> But I found that when one task finished earlier than other one, route start
> to make a huge CPU load. Here you can see a CPU usage during executiong of
> Camel route that was mentioned earlier (after finishing of 'long-task' usage
> of CPU uncreased from 0 to 12.5%):
> !https://content.screencast.com/users/NazarV/folders/Jing/media/830268f0-d184-4c57-adb1-b782ea63fa6d/2017-09-06_1241.png!
> Screenshot was made when I was running route on my Windows PC with 4 physical
> CPU cores + 4 HT. On Unix systems we found that after end of 'long-task' it
> used 100% of one core till the end of work.
> One more interesting thing that i've found is that the main load on the
> system was generated by the thread MulticastProcessor-AggregateTask that was
> spending a lot of time in the method
> java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#awaitNanos
> that was called from java.util.concurrent.DelayQueue#poll(long,
> java.util.concurrent.TimeUnit):
> {code}"Camel (camel-1) thread #2 - MulticastProcessor-AggregateTask" #29
> daemon prio=5 os_prio=0 tid=0x215e3000 nid=0x7a0 runnable
> [0x22eaf000]
>java.lang.Thread.State: RUNNABLE
> at java.lang.Thread.isInterrupted(Native Method)
> at java.lang.Thread.interrupted(Thread.java:944)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.checkInterruptWhileWaiting(AbstractQueuedSynchronizer.java:2002)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2079)
> at java.util.concurrent.DelayQueue.poll(DelayQueue.java:273)
> at
> org.apache.camel.util.concurrent.SubmitOrderedCompletionService.poll(SubmitOrderedCompletionService.java:127)
> at
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.aggregateOnTheFly(MulticastProcessor.java:463)
> at
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.run(MulticastProcessor.java:418)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
>
[jira] [Work logged] (CAMEL-14045) Protect against ByteBuffer / CharBuffer inconsistencies between jdk 8 and 9
[
https://issues.apache.org/jira/browse/CAMEL-14045?focusedWorklogId=326236=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-326236
]
ASF GitHub Bot logged work on CAMEL-14045:
--
Author: ASF GitHub Bot
Created on: 10/Oct/19 11:29
Start Date: 10/Oct/19 11:29
Worklog Time Spent: 10m
Work Description: gnodet commented on pull request #3240: [CAMEL-14045]
Protect against ByteBuffer / CharBuffer inconsistencies…
URL: https://github.com/apache/camel/pull/3240
… between jdk 8 and 9
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 326236)
Remaining Estimate: 0h
Time Spent: 10m
> Protect against ByteBuffer / CharBuffer inconsistencies between jdk 8 and 9
> ---
>
> Key: CAMEL-14045
> URL: https://issues.apache.org/jira/browse/CAMEL-14045
> Project: Camel
> Issue Type: Improvement
>Affects Versions: 3.0.0.RC2
>Reporter: Guillaume Nodet
>Priority: Major
> Fix For: 3.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When built on JDK 9, some features method calls become broken on JDK 8 such
> as {{ByteBuffer.flip()}} or {{CharBuffer.position(int)}}. We need to protect
> against those problems using something similar to
> [[https://github.com/gnodet/mvnd/blob/master/src/main/java/org/jboss/fuse/mvnd/daemon/BufferCaster.java]]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14053) Routes Loader SPI
[
https://issues.apache.org/jira/browse/CAMEL-14053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luca Burgazzoli updated CAMEL-14053:
Description:
Both camel-quarkus and camel-k have now a concept of routes loader which allow
to customize how and if routes are loaded in the case of camel-quarkus or to
provide support for routes written in additional languages in the case of
camel-k.
It would be nice to introduce an official SPI in camel and leverage as example
in camel-main, so one could write something like:
{code:java}
Main main = new Main()
main.addRoutes(
"classpath:my.company.MyRouteImpl.class",
"file:/etc/camel/integration.js",
...
);
main.run()
{code}
And loading of the routes is the delegated to a loader discovered by camel
using the SPI mechanic.
We could also provide some helpers similar to what we have as today to load XML
routes like:
{code:java}
Routes.load(context, "file:/etc/camel/integration.js");
{code}
was:
Both camel-quarkus and camel-k have now a concept of routes loader which allow
to customize how and if routes are loaded in the case of camel-quarkus or to
provide support for routes written in additional languages in the case of
camel-k.
It would be nice to introduce an official SPI in camel and leverage as example
in camel-main, so one could write something like:
{code:java}
Main main = new Main()
main.addRoutes(
"classpath:my.company.MyRouteImpl.class",
"file:/etc/camel/integration.js",
...
);
main.run()
{code}
And loading of the routes is the delegated to a loader discovered by camel
using the SPI mechanic.
> Routes Loader SPI
> -
>
> Key: CAMEL-14053
> URL: https://issues.apache.org/jira/browse/CAMEL-14053
> Project: Camel
> Issue Type: New Feature
> Components: camel-core-api
>Reporter: Luca Burgazzoli
>Priority: Minor
> Fix For: 3.x
>
>
> Both camel-quarkus and camel-k have now a concept of routes loader which
> allow to customize how and if routes are loaded in the case of camel-quarkus
> or to provide support for routes written in additional languages in the case
> of camel-k.
> It would be nice to introduce an official SPI in camel and leverage as
> example in camel-main, so one could write something like:
> {code:java}
> Main main = new Main()
> main.addRoutes(
> "classpath:my.company.MyRouteImpl.class",
> "file:/etc/camel/integration.js",
> ...
> );
> main.run()
> {code}
> And loading of the routes is the delegated to a loader discovered by camel
> using the SPI mechanic.
> We could also provide some helpers similar to what we have as today to load
> XML routes like:
> {code:java}
> Routes.load(context, "file:/etc/camel/integration.js");
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14054) PLaceholder are not resolved when using GeneratedPropertyConfigurer
Luca Burgazzoli created CAMEL-14054:
---
Summary: PLaceholder are not resolved when using
GeneratedPropertyConfigurer
Key: CAMEL-14054
URL: https://issues.apache.org/jira/browse/CAMEL-14054
Project: Camel
Issue Type: Bug
Affects Versions: 3.0.0.RC2
Reporter: Luca Burgazzoli
Assignee: Luca Burgazzoli
Fix For: 3.0.0.RC3
If a property is defined like:
camel.component.twitter-timeline.consumer-key =
{{env:TWITTER_COMNSUMER_KEY}}
then the property will be set on the target object as it is without resolving
placeholders.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14054) Placeholder are not resolved when using GeneratedPropertyConfigurer
[
https://issues.apache.org/jira/browse/CAMEL-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luca Burgazzoli updated CAMEL-14054:
Summary: Placeholder are not resolved when using
GeneratedPropertyConfigurer (was: PLaceholder are not resolved when using
GeneratedPropertyConfigurer )
> Placeholder are not resolved when using GeneratedPropertyConfigurer
>
>
> Key: CAMEL-14054
> URL: https://issues.apache.org/jira/browse/CAMEL-14054
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.0.0.RC2
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Major
> Fix For: 3.0.0.RC3
>
>
> If a property is defined like:
> camel.component.twitter-timeline.consumer-key =
> {{env:TWITTER_COMNSUMER_KEY}}
> then the property will be set on the target object as it is without resolving
> placeholders.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14055) Improve support for custom SSLHandler
Adam Campbell created CAMEL-14055: - Summary: Improve support for custom SSLHandler Key: CAMEL-14055 URL: https://issues.apache.org/jira/browse/CAMEL-14055 Project: Camel Issue Type: Improvement Components: camel-netty-http Reporter: Adam Campbell There is currently no check for whether SslHandler implements ChannelHandlerFactory to add support for reusing custom SslHandler. Ideally, there would be a check similar to the encoders and decoders [https://github.com/apache/camel/blob/release/3.0.0-RC2/components/camel-netty-http/src/main/java/org/apache/camel/component/netty/http/HttpServerInitializerFactory.java#L89] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14055) Improve support for custom SSLHandler
[ https://issues.apache.org/jira/browse/CAMEL-14055?focusedWorklogId=326559=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-326559 ] ASF GitHub Bot logged work on CAMEL-14055: -- Author: ASF GitHub Bot Created on: 10/Oct/19 20:17 Start Date: 10/Oct/19 20:17 Worklog Time Spent: 10m Work Description: adamcamp commented on pull request #3243: Improve support for custom SSLHandler CAMEL-14055 URL: https://github.com/apache/camel/pull/3243 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 326559) Remaining Estimate: 0h Time Spent: 10m > Improve support for custom SSLHandler > - > > Key: CAMEL-14055 > URL: https://issues.apache.org/jira/browse/CAMEL-14055 > Project: Camel > Issue Type: Improvement > Components: camel-netty-http >Reporter: Adam Campbell >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > There is currently no check for whether SslHandler implements > ChannelHandlerFactory to add support for reusing custom SslHandler. > Ideally, there would be a check similar to the encoders and decoders > [https://github.com/apache/camel/blob/release/3.0.0-RC2/components/camel-netty-http/src/main/java/org/apache/camel/component/netty/http/HttpServerInitializerFactory.java#L89] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14055) Improve support for custom SSLHandler
[ https://issues.apache.org/jira/browse/CAMEL-14055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948922#comment-16948922 ] Adam Campbell commented on CAMEL-14055: --- Pull request submitted: [https://github.com/apache/camel/pull/3243] > Improve support for custom SSLHandler > - > > Key: CAMEL-14055 > URL: https://issues.apache.org/jira/browse/CAMEL-14055 > Project: Camel > Issue Type: Improvement > Components: camel-netty-http >Reporter: Adam Campbell >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > There is currently no check for whether SslHandler implements > ChannelHandlerFactory to add support for reusing custom SslHandler. > Ideally, there would be a check similar to the encoders and decoders > [https://github.com/apache/camel/blob/release/3.0.0-RC2/components/camel-netty-http/src/main/java/org/apache/camel/component/netty/http/HttpServerInitializerFactory.java#L89] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14055) Improve support for custom SSLHandler
[ https://issues.apache.org/jira/browse/CAMEL-14055?focusedWorklogId=326688=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-326688 ] ASF GitHub Bot logged work on CAMEL-14055: -- Author: ASF GitHub Bot Created on: 11/Oct/19 03:22 Start Date: 11/Oct/19 03:22 Worklog Time Spent: 10m Work Description: davsclaus commented on pull request #3243: Improve support for custom SSLHandler CAMEL-14055 URL: https://github.com/apache/camel/pull/3243 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 326688) Time Spent: 20m (was: 10m) > Improve support for custom SSLHandler > - > > Key: CAMEL-14055 > URL: https://issues.apache.org/jira/browse/CAMEL-14055 > Project: Camel > Issue Type: Improvement > Components: camel-netty-http >Reporter: Adam Campbell >Priority: Minor > Fix For: 3.0.0.RC3 > > Time Spent: 20m > Remaining Estimate: 0h > > There is currently no check for whether SslHandler implements > ChannelHandlerFactory to add support for reusing custom SslHandler. > Ideally, there would be a check similar to the encoders and decoders > [https://github.com/apache/camel/blob/release/3.0.0-RC2/components/camel-netty-http/src/main/java/org/apache/camel/component/netty/http/HttpServerInitializerFactory.java#L89] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14055) Improve support for custom SSLHandler
[ https://issues.apache.org/jira/browse/CAMEL-14055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-14055. - Fix Version/s: 3.0.0.RC3 Resolution: Fixed > Improve support for custom SSLHandler > - > > Key: CAMEL-14055 > URL: https://issues.apache.org/jira/browse/CAMEL-14055 > Project: Camel > Issue Type: Improvement > Components: camel-netty-http >Reporter: Adam Campbell >Priority: Minor > Fix For: 3.0.0.RC3 > > Time Spent: 20m > Remaining Estimate: 0h > > There is currently no check for whether SslHandler implements > ChannelHandlerFactory to add support for reusing custom SslHandler. > Ideally, there would be a check similar to the encoders and decoders > [https://github.com/apache/camel/blob/release/3.0.0-RC2/components/camel-netty-http/src/main/java/org/apache/camel/component/netty/http/HttpServerInitializerFactory.java#L89] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14054) Placeholder are not resolved when using GeneratedPropertyConfigurer
[
https://issues.apache.org/jira/browse/CAMEL-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-14054.
-
Resolution: Fixed
> Placeholder are not resolved when using GeneratedPropertyConfigurer
>
>
> Key: CAMEL-14054
> URL: https://issues.apache.org/jira/browse/CAMEL-14054
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.0.0.RC2
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Major
> Fix For: 3.0.0.RC3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a property is defined like:
> camel.component.twitter-timeline.consumer-key =
> {{env:TWITTER_COMNSUMER_KEY}}
> then the property will be set on the target object as it is without resolving
> placeholders.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14054) Placeholder are not resolved when using GeneratedPropertyConfigurer
[
https://issues.apache.org/jira/browse/CAMEL-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-14054:
Component/s: camel-core
> Placeholder are not resolved when using GeneratedPropertyConfigurer
>
>
> Key: CAMEL-14054
> URL: https://issues.apache.org/jira/browse/CAMEL-14054
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.0.0.RC2
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Major
> Fix For: 3.0.0.RC3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a property is defined like:
> camel.component.twitter-timeline.consumer-key =
> {{env:TWITTER_COMNSUMER_KEY}}
> then the property will be set on the target object as it is without resolving
> placeholders.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (CAMEL-11750) Camel route with multicast (parallel) generate huge CPU load
[
https://issues.apache.org/jira/browse/CAMEL-11750?focusedWorklogId=326683=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-326683
]
ASF GitHub Bot logged work on CAMEL-11750:
--
Author: ASF GitHub Bot
Created on: 11/Oct/19 03:12
Start Date: 11/Oct/19 03:12
Worklog Time Spent: 10m
Work Description: davsclaus commented on pull request #3241: CAMEL-11750:
Fix delay alignment for java 11
URL: https://github.com/apache/camel/pull/3241
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 326683)
Time Spent: 20m (was: 10m)
> Camel route with multicast (parallel) generate huge CPU load
>
>
> Key: CAMEL-11750
> URL: https://issues.apache.org/jira/browse/CAMEL-11750
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.18.4, 2.19.2
>Reporter: Nazar Vishka
>Assignee: Claus Ibsen
>Priority: Critical
> Fix For: 2.18.5, 2.19.3, 2.20.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I've created simple [Spring Camel Route
> application|https://github.com/leofromgroza/camel-long-term-route] that can
> be used for issue reproducing. Here we have very simple route:
> {code}
> public void configure() throws Exception {
> from("direct:start").routeId("start")
> .multicast().parallelProcessing()
> .to("direct:very-long-task", "direct:long-task")
> .end();
> from("direct:long-task").routeId("long-task")
> .log("Started long-task")
> .process(exchange -> Thread.sleep(5000))
> .log("Finished long-task")
> .end();
> from("direct:very-long-task").routeId("very-long-task")
> .log("Started very-long-task")
> .process(exchange -> Thread.sleep(35000))
> .log("Finished very-long-task")
> .end();
> }{code}
> From our main route 'start' we are starting in parallel two sub-routes:
> 'long-task' and 'very-long-task'. They are just doing something for some
> period of time and do not generate any load to the system.
> But I found that when one task finished earlier than other one, route start
> to make a huge CPU load. Here you can see a CPU usage during executiong of
> Camel route that was mentioned earlier (after finishing of 'long-task' usage
> of CPU uncreased from 0 to 12.5%):
> !https://content.screencast.com/users/NazarV/folders/Jing/media/830268f0-d184-4c57-adb1-b782ea63fa6d/2017-09-06_1241.png!
> Screenshot was made when I was running route on my Windows PC with 4 physical
> CPU cores + 4 HT. On Unix systems we found that after end of 'long-task' it
> used 100% of one core till the end of work.
> One more interesting thing that i've found is that the main load on the
> system was generated by the thread MulticastProcessor-AggregateTask that was
> spending a lot of time in the method
> java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#awaitNanos
> that was called from java.util.concurrent.DelayQueue#poll(long,
> java.util.concurrent.TimeUnit):
> {code}"Camel (camel-1) thread #2 - MulticastProcessor-AggregateTask" #29
> daemon prio=5 os_prio=0 tid=0x215e3000 nid=0x7a0 runnable
> [0x22eaf000]
>java.lang.Thread.State: RUNNABLE
> at java.lang.Thread.isInterrupted(Native Method)
> at java.lang.Thread.interrupted(Thread.java:944)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.checkInterruptWhileWaiting(AbstractQueuedSynchronizer.java:2002)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2079)
> at java.util.concurrent.DelayQueue.poll(DelayQueue.java:273)
> at
> org.apache.camel.util.concurrent.SubmitOrderedCompletionService.poll(SubmitOrderedCompletionService.java:127)
> at
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.aggregateOnTheFly(MulticastProcessor.java:463)
> at
> org.apache.camel.processor.MulticastProcessor$AggregateOnTheFlyTask.run(MulticastProcessor.java:418)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
[jira] [Work logged] (CAMEL-14054) Placeholder are not resolved when using GeneratedPropertyConfigurer
[
https://issues.apache.org/jira/browse/CAMEL-14054?focusedWorklogId=326687=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-326687
]
ASF GitHub Bot logged work on CAMEL-14054:
--
Author: ASF GitHub Bot
Created on: 11/Oct/19 03:20
Start Date: 11/Oct/19 03:20
Worklog Time Spent: 10m
Work Description: davsclaus commented on pull request #3242: CAMEL-14054:
Placeholder are not resolved when using GeneratedPropertyConfigurer
URL: https://github.com/apache/camel/pull/3242
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 326687)
Remaining Estimate: 0h
Time Spent: 10m
> Placeholder are not resolved when using GeneratedPropertyConfigurer
>
>
> Key: CAMEL-14054
> URL: https://issues.apache.org/jira/browse/CAMEL-14054
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.0.0.RC2
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Major
> Fix For: 3.0.0.RC3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a property is defined like:
> camel.component.twitter-timeline.consumer-key =
> {{env:TWITTER_COMNSUMER_KEY}}
> then the property will be set on the target object as it is without resolving
> placeholders.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
