[jira] [Commented] (CAMEL-10454) Unclear piece in IdempotentConsumer.java

2016-11-14 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15666416#comment-15666416
 ] 

ASF GitHub Bot commented on CAMEL-10454:


Github user kevinearls closed the pull request at:

https://github.com/apache/camel/pull/1271


> Unclear piece in IdempotentConsumer.java
> 
>
> Key: CAMEL-10454
> URL: https://issues.apache.org/jira/browse/CAMEL-10454
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Reporter: Boris Treukhov
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.17.4, 2.18.1, 2.19.0
>
>
> Current implementation of IdempotentConsumer.java has very strange check on 
> whether IdempotentRepository contains the key - if it's 
> ExchangeIdempotentRepository then the result of "contains()" check is not 
> inverted(i.e. there is no NOT operator), while for other types of 
> IdempotentRepository it IS inverted with "!".
>  // check if we already have the key
> if (idempotentRepository instanceof 
> ExchangeIdempotentRepository) {
> newKey = ((ExchangeIdempotentRepository) 
> idempotentRepository).contains(exchange, messageId);
> } else {
> newKey = !idempotentRepository.contains(messageId);
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-10479) camel-servicenow: add missing @Deprecated annotations to ServiceNowConstants

2016-11-14 Thread Luca Burgazzoli (JIRA) 
Luca Burgazzoli created CAMEL-10479:
---

 Summary: camel-servicenow: add missing @Deprecated annotations to 
ServiceNowConstants
 Key: CAMEL-10479
 URL: https://issues.apache.org/jira/browse/CAMEL-10479
 Project: Camel
  Issue Type: Improvement
  Components: camel-servicenow
Reporter: Luca Burgazzoli
Assignee: Luca Burgazzoli
 Fix For: 2.18.1






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-10409) Double release of netty buffer

2016-11-14 Thread Willem Jiang (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15666088#comment-15666088
 ] 

Willem Jiang edited comment on CAMEL-10409 at 11/15/16 5:38 AM:


There were some memory leaks in camel-netty4 unit tests after applied the 
patch.  
{code}
Failed tests:
  NettyUDPAsyncTest>BaseNettyTest.verifyNoLeaks:89 Leaks detected while running 
tests: [org.apache.logging.log4j.core.impl.MutableLogEvent@7c96c85]
  NettyUDPMessageLargerThanDefaultBufferSizeTest>BaseNettyTest.verifyNoLeaks:89 
Leaks detected while running tests: 
[org.apache.logging.log4j.core.impl.MutableLogEvent@73bb1337]
  NettyUDPObjectSyncTest>BaseNettyTest.verifyNoLeaks:89 Leaks detected while 
running tests: [org.apache.logging.log4j.core.impl.MutableLogEvent@5eed6dfb, 
org.apache.logging.log4j.core.impl.MutableLogEvent@7c96c85, 
org.apache.logging.log4j.core.impl.MutableLogEvent@7c96c85]
  NettyUDPSyncTest>BaseNettyTest.verifyNoLeaks:89 Leaks detected while running 
tests: [org.apache.logging.log4j.core.impl.MutableLogEvent@7c96c85, 
org.apache.logging.log4j.core.impl.MutableLogEvent@7c96c85]
{code}
I will take a look at it later today.


was (Author: njiang):
There were some memory leaks in camel-netty4 unit tests after applied the 
patch.  I will take a look at it later today.

> Double release of netty buffer
> --
>
> Key: CAMEL-10409
> URL: https://issues.apache.org/jira/browse/CAMEL-10409
> Project: Camel
>  Issue Type: Bug
>  Components: camel-netty4-http
>Affects Versions: 2.18.0
>Reporter: Vitalii Tymchyshyn
>Assignee: Willem Jiang
>Priority: Critical
> Fix For: 2.18.1, 2.19.0
>
>
> It looks like CAMEL-9040 fix introduced a double release of a netty buffer
>  that leads to IllegalReferenceCountException under load:
> {code}
> 2016-10-22 10:20:15.442  WARN 6853 --- [ClientTCPWorker] 
> io.netty.util.ReferenceCountUtil : Failed to release a message: 
> AdvancedLeakAwareByteBuf(PooledUnsafeDirectByteBuf(freed))
> io.netty.util.IllegalReferenceCountException: refCnt: 0, decrement: 1
>   at 
> io.netty.buffer.AbstractReferenceCountedByteBuf.release(AbstractReferenceCountedByteBuf.java:111)
>  ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at io.netty.buffer.WrappedByteBuf.release(WrappedByteBuf.java:1029) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.buffer.AdvancedLeakAwareByteBuf.release(AdvancedLeakAwareByteBuf.java:951)
>  ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:84) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.util.ReferenceCountUtil.safeRelease(ReferenceCountUtil.java:109) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundBuffer.remove0(ChannelOutboundBuffer.java:296)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundBuffer.failFlushed(ChannelOutboundBuffer.java:621)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.flush0(AbstractChannel.java:869)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.flush0(AbstractNioChannel.java:362)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.flush(AbstractChannel.java:823)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.flush(DefaultChannelPipeline.java:1296)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:786)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:778)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:759)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.flush(CombinedChannelDuplexHandler.java:530)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.CombinedChannelDuplexHandler.flush(CombinedChannelDuplexHandler.java:355)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:786)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
>

[jira] [Commented] (CAMEL-10409) Double release of netty buffer

2016-11-14 Thread Willem Jiang (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15666088#comment-15666088
 ] 

Willem Jiang commented on CAMEL-10409:
--

There were some memory leaks in camel-netty4 unit tests after applied the 
patch.  I will take a look at it later today.

> Double release of netty buffer
> --
>
> Key: CAMEL-10409
> URL: https://issues.apache.org/jira/browse/CAMEL-10409
> Project: Camel
>  Issue Type: Bug
>  Components: camel-netty4-http
>Affects Versions: 2.18.0
>Reporter: Vitalii Tymchyshyn
>Assignee: Willem Jiang
>Priority: Critical
> Fix For: 2.18.1, 2.19.0
>
>
> It looks like CAMEL-9040 fix introduced a double release of a netty buffer
>  that leads to IllegalReferenceCountException under load:
> {code}
> 2016-10-22 10:20:15.442  WARN 6853 --- [ClientTCPWorker] 
> io.netty.util.ReferenceCountUtil : Failed to release a message: 
> AdvancedLeakAwareByteBuf(PooledUnsafeDirectByteBuf(freed))
> io.netty.util.IllegalReferenceCountException: refCnt: 0, decrement: 1
>   at 
> io.netty.buffer.AbstractReferenceCountedByteBuf.release(AbstractReferenceCountedByteBuf.java:111)
>  ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at io.netty.buffer.WrappedByteBuf.release(WrappedByteBuf.java:1029) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.buffer.AdvancedLeakAwareByteBuf.release(AdvancedLeakAwareByteBuf.java:951)
>  ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:84) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.util.ReferenceCountUtil.safeRelease(ReferenceCountUtil.java:109) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundBuffer.remove0(ChannelOutboundBuffer.java:296)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundBuffer.failFlushed(ChannelOutboundBuffer.java:621)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.flush0(AbstractChannel.java:869)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.flush0(AbstractNioChannel.java:362)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.flush(AbstractChannel.java:823)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.flush(DefaultChannelPipeline.java:1296)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:786)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:778)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:759)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.flush(CombinedChannelDuplexHandler.java:530)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.CombinedChannelDuplexHandler.flush(CombinedChannelDuplexHandler.java:355)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:786)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:812)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:824)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:804)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:841)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1032)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:296) 
> [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> org.apache.camel.component.netty4.NettyHelper.writeBodyAsync(NettyHelper.java:105)
>  [camel-netty4-2.18.0.jar:2.18.0]
>   at 
>

[jira] [Commented] (CAMEL-10409) Double release of netty buffer

2016-11-14 Thread Willem Jiang (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15665891#comment-15665891
 ] 

Willem Jiang commented on CAMEL-10409:
--

Applied  the patch into camel-2.18.x and master branch with thanks to Vitalii.

> Double release of netty buffer
> --
>
> Key: CAMEL-10409
> URL: https://issues.apache.org/jira/browse/CAMEL-10409
> Project: Camel
>  Issue Type: Bug
>  Components: camel-netty4-http
>Affects Versions: 2.18.0
>Reporter: Vitalii Tymchyshyn
>Assignee: Willem Jiang
>Priority: Critical
> Fix For: 2.18.1, 2.19.0
>
>
> It looks like CAMEL-9040 fix introduced a double release of a netty buffer
>  that leads to IllegalReferenceCountException under load:
> {code}
> 2016-10-22 10:20:15.442  WARN 6853 --- [ClientTCPWorker] 
> io.netty.util.ReferenceCountUtil : Failed to release a message: 
> AdvancedLeakAwareByteBuf(PooledUnsafeDirectByteBuf(freed))
> io.netty.util.IllegalReferenceCountException: refCnt: 0, decrement: 1
>   at 
> io.netty.buffer.AbstractReferenceCountedByteBuf.release(AbstractReferenceCountedByteBuf.java:111)
>  ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at io.netty.buffer.WrappedByteBuf.release(WrappedByteBuf.java:1029) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.buffer.AdvancedLeakAwareByteBuf.release(AdvancedLeakAwareByteBuf.java:951)
>  ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:84) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.util.ReferenceCountUtil.safeRelease(ReferenceCountUtil.java:109) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundBuffer.remove0(ChannelOutboundBuffer.java:296)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundBuffer.failFlushed(ChannelOutboundBuffer.java:621)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.flush0(AbstractChannel.java:869)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.flush0(AbstractNioChannel.java:362)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.flush(AbstractChannel.java:823)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.flush(DefaultChannelPipeline.java:1296)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:786)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:778)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:759)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.flush(CombinedChannelDuplexHandler.java:530)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.CombinedChannelDuplexHandler.flush(CombinedChannelDuplexHandler.java:355)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:786)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:812)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:824)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:804)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:841)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1032)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:296) 
> [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> org.apache.camel.component.netty4.NettyHelper.writeBodyAsync(NettyHelper.java:105)
>  [camel-netty4-2.18.0.jar:2.18.0]
>   at 
> org.apache.camel.component.netty4.NettyProducer.processWithConnectedChannel(NettyProducer.java:306)
>  [camel-netty4-2.18.0.jar:2.18.0]

[jira] [Commented] (CAMEL-10409) Double release of netty buffer

2016-11-14 Thread Vitalii Tymchyshyn (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15665885#comment-15665885
 ] 

Vitalii Tymchyshyn commented on CAMEL-10409:


I'll see. I also see a low hanging fruit: Server must send "Connection: close" 
when it is going to close connection shortly (e.g. when authentication failed). 
Otherwise client may try to send another request over the connection being 
closed. Some of the tests are flacky because of this. I'll make another JIRA 
and fix if confirmed. 

> Double release of netty buffer
> --
>
> Key: CAMEL-10409
> URL: https://issues.apache.org/jira/browse/CAMEL-10409
> Project: Camel
>  Issue Type: Bug
>  Components: camel-netty4-http
>Affects Versions: 2.18.0
>Reporter: Vitalii Tymchyshyn
>Assignee: Willem Jiang
>Priority: Critical
> Fix For: 2.18.1, 2.19.0
>
>
> It looks like CAMEL-9040 fix introduced a double release of a netty buffer
>  that leads to IllegalReferenceCountException under load:
> {code}
> 2016-10-22 10:20:15.442  WARN 6853 --- [ClientTCPWorker] 
> io.netty.util.ReferenceCountUtil : Failed to release a message: 
> AdvancedLeakAwareByteBuf(PooledUnsafeDirectByteBuf(freed))
> io.netty.util.IllegalReferenceCountException: refCnt: 0, decrement: 1
>   at 
> io.netty.buffer.AbstractReferenceCountedByteBuf.release(AbstractReferenceCountedByteBuf.java:111)
>  ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at io.netty.buffer.WrappedByteBuf.release(WrappedByteBuf.java:1029) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.buffer.AdvancedLeakAwareByteBuf.release(AdvancedLeakAwareByteBuf.java:951)
>  ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:84) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.util.ReferenceCountUtil.safeRelease(ReferenceCountUtil.java:109) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundBuffer.remove0(ChannelOutboundBuffer.java:296)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundBuffer.failFlushed(ChannelOutboundBuffer.java:621)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.flush0(AbstractChannel.java:869)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.flush0(AbstractNioChannel.java:362)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.flush(AbstractChannel.java:823)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.flush(DefaultChannelPipeline.java:1296)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:786)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:778)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:759)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.flush(CombinedChannelDuplexHandler.java:530)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.CombinedChannelDuplexHandler.flush(CombinedChannelDuplexHandler.java:355)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:786)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:812)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:824)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:804)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:841)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1032)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:296) 
> [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at

[jira] [Commented] (CAMEL-10478) Support for simple language in message headers for camel-salesforce

2016-11-14 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15664965#comment-15664965
 ] 

ASF GitHub Bot commented on CAMEL-10478:


GitHub user zregvart opened a pull request:

https://github.com/apache/camel/pull/1274

CAMEL-10478 Support simple language expressions in header values in 
camel-salesforce

This is a PR against 2.18.x, as this functionality would be beneficial to 
2.18
users as well.

Implements support for simple language expressions in header values for
the camel-salesforce component.

AbstractSalesforceProcessor was modified to post-process values
retrieved from message header and evaluate them with simple language.
This greatly simplifies usage in downstream salesforce components as
they can have access upstream values. For instance:

salesforce:queryMore?sObjectQuery=${header.nextRecordsUrl}...

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/zregvart/camel CAMEL-10478-camel-2.18.x

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1274.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 #1274


commit 6a28486d6714672ea67a40331d339df506aa1db2
Author: Zoran Regvart 
Date:   2016-11-14T20:45:07Z

Support simple language expressions in header values in camel-salesforce

Implements support for simple language expressions in header values for
the camel-salesforce component.

AbstractSalesforceProcessor was modified to post-process values
retrieved from message header and evaluate them with simple language.
This greatly simplifies usage in downstream salesforce components as
they can have access upstream values. For instance:

salesforce:queryMore?sObjectQuery=${header.nextRecordsUrl}...




> Support for simple language in message headers for camel-salesforce
> ---
>
> Key: CAMEL-10478
> URL: https://issues.apache.org/jira/browse/CAMEL-10478
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-salesforce
>Affects Versions: 2.17.4, 2.18.1
> Environment: Any
>Reporter: Zoran Regvart
>
> Salesforce component could benefit greatly from supporting simple expressions 
> in header values. This would allow for natural chaining of salesforce 
> components for the `query` and `queryNext` operations, as former returns the 
> URL needed for the later.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10478) Support for simple language in message headers for camel-salesforce

2016-11-14 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15664959#comment-15664959
 ] 

ASF GitHub Bot commented on CAMEL-10478:


GitHub user zregvart opened a pull request:

https://github.com/apache/camel/pull/1273

CAMEL-10478 Support simple language expressions in header values in 
camel-salesforce

This is a PR against 2.17.x, as this functionality would be beneficial to 
2.17
users as well.

Implements support for simple language expressions in header values for
the camel-salesforce component.

AbstractSalesforceProcessor was modified to post-process values
retrieved from message header and evaluate them with simple language.
This greatly simplifies usage in downstream salesforce components as
they can have access upstream values. For instance:

salesforce:queryMore?sObjectQuery=${header.nextRecordsUrl}...

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/zregvart/camel CAMEL-10478-camel-2.17.x

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1273.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 #1273


commit 214fb5d6ad3384d86e2e64e76b40f3798dfa2bd3
Author: Zoran Regvart 
Date:   2016-11-14T20:41:29Z

Support simple language expressions in header values in camel-salesforce

Implements support for simple language expressions in header values for
the camel-salesforce component.

AbstractSalesforceProcessor was modified to post-process values
retrieved from message header and evaluate them with simple language.
This greatly simplifies usage in downstream salesforce components as
they can have access upstream values. For instance:

salesforce:queryMore?sObjectQuery=${header.nextRecordsUrl}...




> Support for simple language in message headers for camel-salesforce
> ---
>
> Key: CAMEL-10478
> URL: https://issues.apache.org/jira/browse/CAMEL-10478
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-salesforce
>Affects Versions: 2.17.4, 2.18.1
> Environment: Any
>Reporter: Zoran Regvart
>
> Salesforce component could benefit greatly from supporting simple expressions 
> in header values. This would allow for natural chaining of salesforce 
> components for the `query` and `queryNext` operations, as former returns the 
> URL needed for the later.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10478) Support for simple language in message headers for camel-salesforce

2016-11-14 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15664945#comment-15664945
 ] 

ASF GitHub Bot commented on CAMEL-10478:


GitHub user zregvart opened a pull request:

https://github.com/apache/camel/pull/1272

CAMEL-10478 Support for simple language in message headers for 
camel-salesforce

Implements support for simple language expressions in header values for
the camel-salesforce component.

AbstractSalesforceProcessor was modified to post-process values
retrieved from message header and evaluate them with simple language.
This greatly simplifies usage in downstream salesforce components as
they can have access upstream values. For instance:

salesforce:queryMore?sObjectQuery=${header.nextRecordsUrl}...

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/zregvart/camel CAMEL-10478

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1272.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 #1272


commit 2760d6a6f166047b6491d819baaae5eb47bafda1
Author: Zoran Regvart 
Date:   2016-11-14T20:33:44Z

Support simple language expressions in header values in camel-salesforce

Implements support for simple language expressions in header values for
the camel-salesforce component.

AbstractSalesforceProcessor was modified to post-process values
retrieved from message header and evaluate them with simple language.
This greatly simplifies usage in downstream salesforce components as
they can have access upstream values. For instance:

salesforce:queryMore?sObjectQuery=${header.nextRecordsUrl}...




> Support for simple language in message headers for camel-salesforce
> ---
>
> Key: CAMEL-10478
> URL: https://issues.apache.org/jira/browse/CAMEL-10478
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-salesforce
>Affects Versions: 2.17.4, 2.18.1
> Environment: Any
>Reporter: Zoran Regvart
>
> Salesforce component could benefit greatly from supporting simple expressions 
> in header values. This would allow for natural chaining of salesforce 
> components for the `query` and `queryNext` operations, as former returns the 
> URL needed for the later.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-10478) Support for simple language in message headers for camel-salesforce

2016-11-14 Thread Zoran Regvart (JIRA) 
Zoran Regvart created CAMEL-10478:
-

 Summary: Support for simple language in message headers for 
camel-salesforce
 Key: CAMEL-10478
 URL: https://issues.apache.org/jira/browse/CAMEL-10478
 Project: Camel
  Issue Type: Improvement
  Components: camel-salesforce
Affects Versions: 2.17.4, 2.18.1
 Environment: Any
Reporter: Zoran Regvart


Salesforce component could benefit greatly from supporting simple expressions 
in header values. This would allow for natural chaining of salesforce 
components for the `query` and `queryNext` operations, as former returns the 
URL needed for the later.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders

2016-11-14 Thread Quinn Stevenson (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15664529#comment-15664529
 ] 

Quinn Stevenson commented on CAMEL-9570:


I've had a few discussions on the mailing list about this one, and I thought I 
should add the relevant information here.

The root of this problem is the CamelDependenciesFinder - it is forcing the 
BlueprintContainer to create objects before it should.  This puts the 
BlueprintContainer in a strange state, where service references and such are 
not handled correctly.

The PR removes the CamelDependenciesFinder, and the expected net effect is 
described in the PR comment above.  IMO this is more intuitive behavior than 
what occurs now.  It turns out that the CamelDependenciesFinder bit me in the 
past - with a custom DataFormat.  It caused the CamelContext to timeout when 
starting because of a service dependent, but the DataFormat was defined in the 
same bundle as the rest of the code, so there wasn't a service reference 
required - this one was tough to work around.

> Blueprint Proxies are not used when injected into Java RouteBuilders
> 
>
> Key: CAMEL-9570
> URL: https://issues.apache.org/jira/browse/CAMEL-9570
> Project: Camel
>  Issue Type: Bug
>  Components: camel-blueprint, camel-core
>Affects Versions: 2.16.2
>Reporter: Quinn Stevenson
>Assignee: Christian Schneider
>
> Basic Conditions:
> - Java interface used for OSGi Services
> - Implementation of the Java interface registered as a OSGi service.  Note 
> that the package containing implementation is NOT exported
> - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, 
> with a setter for the bean implementing the interface
> - Wire everything together with Blueprint - create a  for the 
> service, a  for the RouteBuilder and inject the service reference, 
> and use the RouteBuilder in a CamelContext.
> After all this is deployed, stop the bundle implementing the service.  A 
> ServiceUnavailableException should be thrown after a timeout, but the object 
> that was injected into the RouteBuilder process the request - so the 
> Blueprint Proxy is not used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10477) [jruby] Upgrade to 1.7.26

2016-11-14 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15664484#comment-15664484
 ] 

ASF GitHub Bot commented on CAMEL-10477:


GitHub user paoloantinori opened a pull request:

https://github.com/apache/camel/pull/1270

CAMEL-10477 - jruby 1.7.26



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/paoloantinori/camel CAMEL-10477

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1270.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 #1270


commit ba1035b72a99ae28da24117fd9d678f2a0051365
Author: Paolo Antinori 
Date:   2016-11-14T17:33:21Z

CAMEL-10477 - jruby 1.7.26




> [jruby] Upgrade to 1.7.26
> -
>
> Key: CAMEL-10477
> URL: https://issues.apache.org/jira/browse/CAMEL-10477
> Project: Camel
>  Issue Type: Bug
>  Components: camel-script
>Affects Versions: 2.18.0
>Reporter: Paolo Antinori
>Assignee: Paolo Antinori
> Fix For: 2.19.0
>
>
> Upgrade {{jruby}} to {{v1.7.26}}
> Note: this requires to explicitly set in test, while in used in multithread 
> envs.
> {code}
> System.setProperty("org.jruby.embed.localcontext.scope", "threadsafe")
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10477) [jruby] Upgrade to 1.7.26

2016-11-14 Thread Paolo Antinori (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CAMEL-10477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paolo Antinori updated CAMEL-10477:
---
Description: 
Upgrade {{jruby}} to {{v1.7.26}}

Note: this requires to explicitly set in test, while in used in multithread 
envs.

{code}
System.setProperty("org.jruby.embed.localcontext.scope", "threadsafe")
{code}

  was:
Upgrade `jruby` to `v1.7.26`

Note: this requires to explicitly set in test, while in used in multithread 
envs.

```
System.setProperty("org.jruby.embed.localcontext.scope", "threadsafe")
```


> [jruby] Upgrade to 1.7.26
> -
>
> Key: CAMEL-10477
> URL: https://issues.apache.org/jira/browse/CAMEL-10477
> Project: Camel
>  Issue Type: Bug
>  Components: camel-script
>Affects Versions: 2.18.0
>Reporter: Paolo Antinori
>Assignee: Paolo Antinori
> Fix For: 2.19.0
>
>
> Upgrade {{jruby}} to {{v1.7.26}}
> Note: this requires to explicitly set in test, while in used in multithread 
> envs.
> {code}
> System.setProperty("org.jruby.embed.localcontext.scope", "threadsafe")
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-10477) [jruby] Upgrade to 1.7.26

2016-11-14 Thread Paolo Antinori (JIRA) 
Paolo Antinori created CAMEL-10477:
--

 Summary: [jruby] Upgrade to 1.7.26
 Key: CAMEL-10477
 URL: https://issues.apache.org/jira/browse/CAMEL-10477
 Project: Camel
  Issue Type: Bug
  Components: camel-script
Affects Versions: 2.18.0
Reporter: Paolo Antinori
Assignee: Paolo Antinori
 Fix For: 2.19.0


Upgrade `jruby` to `v1.7.26`

Note: this requires to explicitly set in test, while in used in multithread 
envs.

```
System.setProperty("org.jruby.embed.localcontext.scope", "threadsafe")
```



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders

2016-11-14 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15664376#comment-15664376
 ] 

ASF GitHub Bot commented on CAMEL-9570:
---

GitHub user hqstevenson opened a pull request:

https://github.com/apache/camel/pull/1269

CAMEL-9570:  Blueprint service proxies aren't used

This PR has two main pieces.  First, the CamelDependenciesFinder was 
removed from the CamelNamespaceHandler.  This code caused the issue described 
in CAMEL-9570 as well as CAMEL-10394.  The net effect of removing this class is 
the CamelContext may attempt to start when a service isn't available because 
the reference hasn't been specified in the XML.  This is better than what 
happens today which is service references sometimes get registered for services 
that don't exist - therefore, starting Blueprint Context times-out waiting for 
service references.  This one actually bit me 18-mo ago with a customer - I'm 
just didn't know at the time what was causing it.

The second piece of the PR is changing the BlueprintCamelContext so it 
starts after the BlueprintContainer is created (on the BlueprintEvent.CREATED). 
 This fixes some startup issues.  Basically what was happening is if the 
serviceChanged method (which previously was used to start the camel context) 
threw a RuntimeException, the Karaf container would spin until a stack overflow 
occurred.  I didn't see this behavior when the context is started after the 
BlueprintContainer is fully initialized.

The only thing I changed in the CamelContextFactoryBean was removing a 
space that caused a Checkstyle error.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/hqstevenson/camel CAMEL-9570

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1269.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 #1269


commit 0376e45defaaa70e4795dcc8ef54905025568a79
Author: Quinn Stevenson 
Date:   2016-11-14T16:09:10Z

CAMEL-9570: Remove CamelDependenciesFinder from CamelNamespaceHandler

commit 57d92619ac62655eafe9434e2149616f025c21df
Author: Quinn Stevenson 
Date:   2016-11-14T16:29:49Z

CAMEL-9570: Start BlueprintCamelContext on BlueprintEvent.CREATED

commit c4a7e820be90c5101cef2b04aa5d057e6820b57e
Author: Quinn Stevenson 
Date:   2016-11-14T16:30:16Z

Fix checkstyle issue




> Blueprint Proxies are not used when injected into Java RouteBuilders
> 
>
> Key: CAMEL-9570
> URL: https://issues.apache.org/jira/browse/CAMEL-9570
> Project: Camel
>  Issue Type: Bug
>  Components: camel-blueprint, camel-core
>Affects Versions: 2.16.2
>Reporter: Quinn Stevenson
>Assignee: Christian Schneider
>
> Basic Conditions:
> - Java interface used for OSGi Services
> - Implementation of the Java interface registered as a OSGi service.  Note 
> that the package containing implementation is NOT exported
> - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, 
> with a setter for the bean implementing the interface
> - Wire everything together with Blueprint - create a  for the 
> service, a  for the RouteBuilder and inject the service reference, 
> and use the RouteBuilder in a CamelContext.
> After all this is deployed, stop the bundle implementing the service.  A 
> ServiceUnavailableException should be thrown after a timeout, but the object 
> that was injected into the RouteBuilder process the request - so the 
> Blueprint Proxy is not used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10476) configAdminFile not used to populate property placeholders in camel-test-blueprint when run via camel-maven-plugin

2016-11-14 Thread Ryan Colwell (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CAMEL-10476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Colwell updated CAMEL-10476:
-
Description: 
Problem: When running with a Camel Blueprint project a configAdminFile is not 
used to populate propertyplacehoders in camel-test-blueprint when exectued with 
camel-maven-plugin(camel:run). So a user can't run camel locally in a similar 
way to running in Karaf with file based property placeholder values. 

Workaround: I think, but haven't tested yet, that you can work around this 
locally using the methods described here: 
http://ggrzybek.blogspot.com/2015/12/camel-blueprint-test-support.html and/or 
how this solution  
https://github.com/cschneider/Karaf-Tutorial/tree/master/camel/order/src 
appears to use exec:java locally and loads the properties via 
PropertiesComponent.

To reproduce the problem:
Create a new project using camel-archetype-blueprint. (You need to change the 
log4j config to make it run.) To reduce the time, I created a project that runs 
here: https://github.com/ryanco/propertyconfig. Instead of using a default in 
the blueprint XML for the propertyplaceholder, I setup the POM to include the 
following:
{code:xml}
  
org.apache.camel
camel-maven-plugin
2.18.0

  truecom.yarsquidy.props.propertyconfig
  
etc/com.yarsquidy.props.propertyconfig

  
{code}
In Camel 2.15.2 or earlier, this file would be loaded when mvn camel:run was 
invoked and the properties would be available via the PID at run time. After 
the changes made in CAMEL-9313, it appears that the method 
{{org.apache.camel.test.blueprint.CamelBlueprintHelper#setPersistentFileForConfigAdmin}}
 is only called in when the createTestBundle pathway is taken in 
{{org.apache.camel.test.blueprint.CamelBlueprintHelper#createBundleContext(java.lang.String,
 java.lang.String, boolean, java.lang.String, java.lang.String, 
java.lang.String, java.lang.String[]...)}}. So it appears test using 
CamelBlueprintTestSupport get this functionality (as shown by the tests) but 
things executed from camel:run do not.

Here you can see in Camel 2.14 that call to 
{{org.apache.camel.test.blueprint.CamelBlueprintHelper#setPersistentFileForConfigAdmin}}
 is made after the bundelContext is created.
https://github.com/apache/camel/blob/camel-2.14.x/components/camel-test-blueprint/src/main/java/org/apache/camel/test/blueprint/Main.java#L103

In the master branch version, that call is no longer made from main after the 
context is returned.
https://github.com/apache/camel/blob/master/components/camel-test-blueprint/src/main/java/org/apache/camel/test/blueprint/Main.java#L106

I made a change locally to add a similar call to 
{{org.apache.camel.test.blueprint.CamelBlueprintHelper#setPersistentFileForConfigAdmin}}
 in Camel 2.18:
{code}
LOG.debug("Starting Blueprint XML file: " + descriptors);
if (configAdminPid != null && configAdminFileName != null) {
// pid/file is used to set INITIAL content of ConfigAdmin to be 
used when blueprint container is started
LOG.info("ConfigAdminPid and ConfigAdminFileName are not null");
bundleContext = createBundleContext(bundleName, new String[] 
{configAdminFileName, configAdminPid});
} else {
bundleContext = createBundleContext(bundleName);
}
CamelBlueprintHelper.setPersistentFileForConfigAdmin(bundleContext, 
configAdminPid, configAdminFileName, new Properties(), null, null, false);
{code}

Here is the output of the log statement from the example before this change:
{noformat}
[ntext  INFO  Apache Camel 2.18.0 (CamelContext: 
blueprint-bean-context) started in 0.214 seconds
[ntext) thread #0 - timer://foo] timerToLog INFO  The 
message contains ${greeting} at 2016-11-14 08:42:03
[ntext) thread #0 - timer://foo] timerToLog INFO  The 
message contains ${greeting} at 2016-11-14 08:42:08
{noformat}

Here is the output of the log statement from the example after this change:
{noformat}
[ Blueprint Extender: 3] BlueprintCamelContext  INFO  Apache 
Camel 2.18.1-SNAPSHOT (CamelContext: blueprint-bean-context) started in 0.257 
seconds
[ntext) thread #0 - timer://foo] timerToLog INFO  The 
message contains Hello From File! at 2016-11-14 08:54:09
[ntext) thread #0 - timer://foo] timerToLog INFO  The 
message contains Hello From File! at 2016-11-14 08:54:14
{noformat}

As you can see before the change, the ${greeting} property is not poplulated 
via propertyplacehoder. After the change it is replaced.

Given all the discussion of timing related issues in CAMEL-9313, I'm hesitant 
to say this is a good enough solution or that it aligns with the intention of 
the changes made in that fix. Given that configAdminFileName and configAdminPid 
are passed into createBundleContext, perhaps the

[jira] [Updated] (CAMEL-10476) configAdminFile not used to populate property placeholders in camel-test-blueprint when run via camel-maven-plugin

2016-11-14 Thread Ryan Colwell (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CAMEL-10476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Colwell updated CAMEL-10476:
-
Description: 
Problem: When running with a Camel Blueprint project a configAdminFile is not 
used to populate propertyplacehoders in camel-test-blueprint when exectued with 
camel-maven-plugin(camel:run). So a user can't run camel locally in a similar 
way to running in Karaf with file based property placeholder values. 

Workaround: I think, but haven't tested yet, that you can work around this 
locally using the methods described here: 
http://ggrzybek.blogspot.com/2015/12/camel-blueprint-test-support.html and/or 
how this solution  
https://github.com/cschneider/Karaf-Tutorial/tree/master/camel/order/src 
appears to use exec:java locally and loads the properties via 
PropertiesComponent.

To reproduce the problem:
Create a new project using camel-archetype-blueprint. (You need to change the 
log4j config to make it run.) To reduce the time, I created a project that runs 
here: https://github.com/ryanco/propertyconfig. Instead of using a default in 
the blueprint XML for the propertyplaceholder, I setup the POM to include the 
following:
{code:xml}
  
org.apache.camel
camel-maven-plugin
2.18.0

  truecom.yarsquidy.props.propertyconfig
  
etc/com.yarsquidy.props.propertyconfig

  
{code}
In Camel 2.15.2 or earlier, this file would be loaded when mvn camel:run was 
invoked and the properties would be available via the PID at run time. After 
the changes made in CAMEL-9313, it appears that the method 
{{org.apache.camel.test.blueprint.CamelBlueprintHelper#setPersistentFileForConfigAdmin}}
 is only called in when the createTestBundle pathway is taken in 
{{org.apache.camel.test.blueprint.CamelBlueprintHelper#createBundleContext(java.lang.String,
 java.lang.String, boolean, java.lang.String, java.lang.String, 
java.lang.String, java.lang.String[]...)}}. So it appears test using 
CamelBlueprintTestSupport get this functionality (as shown by the tests) but 
things executed from camel:run do not.

Here you can see in Camel 2.14 that call to 
{{org.apache.camel.test.blueprint.CamelBlueprintHelper#setPersistentFileForConfigAdmin}}
 is made after the bundelContext is created.
https://github.com/apache/camel/blob/camel-2.14.x/components/camel-test-blueprint/src/main/java/org/apache/camel/test/blueprint/Main.java#L103

In the master branch version, that call is no longer made from main after the 
context is returned.
https://github.com/apache/camel/blob/master/components/camel-test-blueprint/src/main/java/org/apache/camel/test/blueprint/Main.java#L106

I made a change locally to add a similar call to 
{{org.apache.camel.test.blueprint.CamelBlueprintHelper#setPersistentFileForConfigAdmin}}
 in Camel 2.18:
{code}
LOG.debug("Starting Blueprint XML file: " + descriptors);
if (configAdminPid != null && configAdminFileName != null) {
// pid/file is used to set INITIAL content of ConfigAdmin to be 
used when blueprint container is started
LOG.info("ConfigAdminPid and ConfigAdminFileName are not null");
bundleContext = createBundleContext(bundleName, new String[] 
{configAdminFileName, configAdminPid});
} else {
bundleContext = createBundleContext(bundleName);
}
CamelBlueprintHelper.setPersistentFileForConfigAdmin(bundleContext, 
configAdminPid, configAdminFileName, new Properties(), null, null, false);
{code}

Here is the output of the log statement from the example before this change:
{noformat}
[ntext  INFO  Apache Camel 2.18.0 (CamelContext: 
blueprint-bean-context) started in 0.214 seconds
[ntext) thread #0 - timer://foo] timerToLog INFO  The 
message contains ${greeting} at 2016-11-14 08:42:03
[ntext) thread #0 - timer://foo] timerToLog INFO  The 
message contains ${greeting} at 2016-11-14 08:42:08
{noformat}

Here is the output of the log statement from the example after this change:
{noformat}
[ Blueprint Extender: 3] BlueprintCamelContext  INFO  Apache 
Camel 2.18.1-SNAPSHOT (CamelContext: blueprint-bean-context) started in 0.257 
seconds
[ntext) thread #0 - timer://foo] timerToLog INFO  The 
message contains Hello From File! at 2016-11-14 08:54:09
[ntext) thread #0 - timer://foo] timerToLog INFO  The 
message contains Hello From File! at 2016-11-14 08:54:14
{noformat}

As you can see before the change, the {{${greeting}}} property is not 
poplulated via propertyplacehoder. After the change it is replaced.

Given all the discussion of timing related issues in CAMEL-9313, I'm hesitant 
to say this is a good enough solution or that it aligns with the intention of 
the changes made in that fix. Given that configAdminFileName and configAdminPid 
are passed into createBundleContext, perhaps

[jira] [Created] (CAMEL-10476) configAdminFile not used to populate property placeholders in camel-test-blueprint when run via camel-maven-plugin

2016-11-14 Thread Ryan Colwell (JIRA) 
Ryan Colwell created CAMEL-10476:


 Summary: configAdminFile not used to populate property 
placeholders in camel-test-blueprint when run via camel-maven-plugin
 Key: CAMEL-10476
 URL: https://issues.apache.org/jira/browse/CAMEL-10476
 Project: Camel
  Issue Type: Bug
  Components: camel-blueprint
Affects Versions: 2.18.0, 2.17.3, 2.17.2, 2.17.1, 2.17.0, 2.16.4, 2.16.3, 
2.16.2, 2.15.6, 2.15.5, 2.16.1, 2.15.4, 2.16.0, 2.15.3
Reporter: Ryan Colwell
Assignee: Grzegorz Grzybek
Priority: Minor


Problem: When running with a Camel Blueprint project a configAdminFile is not 
used to populate propertyplacehoders in camel-test-blueprint when exectued with 
camel-maven-plugin(camel:run). So a user can't run camel locally in a similar 
way to running in Karaf with file based property placeholder values. 

Workaround: I think, but haven't tested yet, that you can work around this 
locally using the methods described here: 
http://ggrzybek.blogspot.com/2015/12/camel-blueprint-test-support.html and/or 
how this solution  
https://github.com/cschneider/Karaf-Tutorial/tree/master/camel/order/src 
appears to use exec:java locally and loads the properties via 
PropertiesComponent.

To reproduce the problem:
Create a new project using camel-archetype-blueprint. (You need to change the 
log4j config to make it run.) To reduce the time, I created a project that runs 
here: https://github.com/ryanco/propertyconfig. Instead of using a default in 
the blueprint XML for the propertyplaceholder, I setup the POM to include the 
following:
{code:xml}
  
org.apache.camel
camel-maven-plugin
2.18.0

  truecom.yarsquidy.props.propertyconfig
  
etc/com.yarsquidy.props.propertyconfig

  
{code}
In Camel 2.15.2 or earlier, this file would be loaded when mvn camel:run was 
invoked and the properties would be available via the PID at run time. After 
the changes made in CAMEL-9313, it appears that the method 
{{org.apache.camel.test.blueprint.CamelBlueprintHelper#setPersistentFileForConfigAdmin}}
 is only called in when the createTestBundle pathway is taken in 
{{org.apache.camel.test.blueprint.CamelBlueprintHelper#createBundleContext(java.lang.String,
 java.lang.String, boolean, java.lang.String, java.lang.String, 
java.lang.String, java.lang.String[]...)}}. So it appears test using 
CamelBlueprintTestSupport get this functionality (as shown by the tests) but 
things executed from camel:run do not.

Here you can see in Camel 2.14 that call to 
{{org.apache.camel.test.blueprint.CamelBlueprintHelper#setPersistentFileForConfigAdmin}}
 is made after the bundelContext is created.
https://github.com/apache/camel/blob/camel-2.14.x/components/camel-test-blueprint/src/main/java/org/apache/camel/test/blueprint/Main.java#L103

In the master branch version, that call is no longer made from main after the 
context is returned.
https://github.com/apache/camel/blob/master/components/camel-test-blueprint/src/main/java/org/apache/camel/test/blueprint/Main.java#L106

I made a change locally to add a similar call to 
{{org.apache.camel.test.blueprint.CamelBlueprintHelper#setPersistentFileForConfigAdmin}}
 in Camel 2.18:
{code}
LOG.debug("Starting Blueprint XML file: " + descriptors);
if (configAdminPid != null && configAdminFileName != null) {
// pid/file is used to set INITIAL content of ConfigAdmin to be 
used when blueprint container is started
LOG.info("ConfigAdminPid and ConfigAdminFileName are not null");
bundleContext = createBundleContext(bundleName, new String[] 
{configAdminFileName, configAdminPid});
} else {
bundleContext = createBundleContext(bundleName);
}
CamelBlueprintHelper.setPersistentFileForConfigAdmin(bundleContext, 
configAdminPid, configAdminFileName, new Properties(), null, null, false);
{code}

Here is the output of the log statement from the example before this change:
{quote}
[ntext  INFO  Apache Camel 2.18.0 (CamelContext: 
blueprint-bean-context) started in 0.214 seconds
[ntext) thread #0 - timer://foo] timerToLog INFO  The 
message contains ${greeting} at 2016-11-14 08:42:03
[ntext) thread #0 - timer://foo] timerToLog INFO  The 
message contains ${greeting} at 2016-11-14 08:42:08
{quote}

Here is the output of the log statement from the example after this change:
{quote}
[ Blueprint Extender: 3] BlueprintCamelContext  INFO  Apache 
Camel 2.18.1-SNAPSHOT (CamelContext: blueprint-bean-context) started in 0.257 
seconds
[ntext) thread #0 - timer://foo] timerToLog INFO  The 
message contains Hello From File! at 2016-11-14 08:54:09
[ntext) thread #0 - timer://foo] timerToLog INFO  The 
message contains Hello From File! at 2016-11-14 08:54:14
{quote}

As

[jira] [Assigned] (CAMEL-10454) Unclear piece in IdempotentConsumer.java

2016-11-14 Thread Andrea Cosentino (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CAMEL-10454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Cosentino reassigned CAMEL-10454:


Assignee: Andrea Cosentino

> Unclear piece in IdempotentConsumer.java
> 
>
> Key: CAMEL-10454
> URL: https://issues.apache.org/jira/browse/CAMEL-10454
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Reporter: Boris Treukhov
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.17.4, 2.18.1, 2.19.0
>
>
> Current implementation of IdempotentConsumer.java has very strange check on 
> whether IdempotentRepository contains the key - if it's 
> ExchangeIdempotentRepository then the result of "contains()" check is not 
> inverted(i.e. there is no NOT operator), while for other types of 
> IdempotentRepository it IS inverted with "!".
>  // check if we already have the key
> if (idempotentRepository instanceof 
> ExchangeIdempotentRepository) {
> newKey = ((ExchangeIdempotentRepository) 
> idempotentRepository).contains(exchange, messageId);
> } else {
> newKey = !idempotentRepository.contains(messageId);
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CAMEL-10453) camel-elsql does not set CamelSqlUpdateCount header on update operation

2016-11-14 Thread Andrea Cosentino (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CAMEL-10453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Cosentino reassigned CAMEL-10453:


Assignee: Andrea Cosentino

> camel-elsql does not set CamelSqlUpdateCount header on update operation
> ---
>
> Key: CAMEL-10453
> URL: https://issues.apache.org/jira/browse/CAMEL-10453
> Project: Camel
>  Issue Type: Bug
>  Components: camel-elsql
>Affects Versions: 2.18.0
>Reporter: Tomas Turek
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.18.1, 2.19.0
>
>
> Camel ElSql should store number of rows updated for update operation into 
> CamelSqlUpdateCount header.
> Route:
> {code}
> 
>   
>   
>   
> 
> {code}
> ElSQL
> {code}
> @NAME(updateLicense)
> UPDATE projects
> SET license = :lic
> WHERE id = :id
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10409) Double release of netty buffer

2016-11-14 Thread Claus Ibsen (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CAMEL-10409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10409:

Fix Version/s: 2.19.0
   2.18.1

> Double release of netty buffer
> --
>
> Key: CAMEL-10409
> URL: https://issues.apache.org/jira/browse/CAMEL-10409
> Project: Camel
>  Issue Type: Bug
>  Components: camel-netty4-http
>Affects Versions: 2.18.0
>Reporter: Vitalii Tymchyshyn
>Assignee: Willem Jiang
>Priority: Critical
> Fix For: 2.18.1, 2.19.0
>
>
> It looks like CAMEL-9040 fix introduced a double release of a netty buffer
>  that leads to IllegalReferenceCountException under load:
> {code}
> 2016-10-22 10:20:15.442  WARN 6853 --- [ClientTCPWorker] 
> io.netty.util.ReferenceCountUtil : Failed to release a message: 
> AdvancedLeakAwareByteBuf(PooledUnsafeDirectByteBuf(freed))
> io.netty.util.IllegalReferenceCountException: refCnt: 0, decrement: 1
>   at 
> io.netty.buffer.AbstractReferenceCountedByteBuf.release(AbstractReferenceCountedByteBuf.java:111)
>  ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at io.netty.buffer.WrappedByteBuf.release(WrappedByteBuf.java:1029) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.buffer.AdvancedLeakAwareByteBuf.release(AdvancedLeakAwareByteBuf.java:951)
>  ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:84) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.util.ReferenceCountUtil.safeRelease(ReferenceCountUtil.java:109) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundBuffer.remove0(ChannelOutboundBuffer.java:296)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundBuffer.failFlushed(ChannelOutboundBuffer.java:621)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.flush0(AbstractChannel.java:869)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.flush0(AbstractNioChannel.java:362)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.flush(AbstractChannel.java:823)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.flush(DefaultChannelPipeline.java:1296)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:786)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:778)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:759)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.flush(CombinedChannelDuplexHandler.java:530)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.CombinedChannelDuplexHandler.flush(CombinedChannelDuplexHandler.java:355)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:786)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:812)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:824)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:804)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:841)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1032)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:296) 
> [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> org.apache.camel.component.netty4.NettyHelper.writeBodyAsync(NettyHelper.java:105)
>  [camel-netty4-2.18.0.jar:2.18.0]
>   at 
> org.apache.camel.component.netty4.NettyProducer.processWithConnectedChannel(NettyProducer.java:306)
>  [camel-netty4-2.18.0.jar:2.18.0]
>   at 
>

[jira] [Commented] (CAMEL-10409) Double release of netty buffer

2016-11-14 Thread Claus Ibsen (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15663201#comment-15663201
 ] 

Claus Ibsen commented on CAMEL-10409:
-

Thanks [~tivv]

I wonder if would help with https://issues.apache.org/jira/browse/CAMEL-10301 
as well - and see if you can reproduce this with latest code, and possible fix 
it too ;)

> Double release of netty buffer
> --
>
> Key: CAMEL-10409
> URL: https://issues.apache.org/jira/browse/CAMEL-10409
> Project: Camel
>  Issue Type: Bug
>  Components: camel-netty4-http
>Affects Versions: 2.18.0
>Reporter: Vitalii Tymchyshyn
>Assignee: Willem Jiang
>Priority: Critical
> Fix For: 2.18.1, 2.19.0
>
>
> It looks like CAMEL-9040 fix introduced a double release of a netty buffer
>  that leads to IllegalReferenceCountException under load:
> {code}
> 2016-10-22 10:20:15.442  WARN 6853 --- [ClientTCPWorker] 
> io.netty.util.ReferenceCountUtil : Failed to release a message: 
> AdvancedLeakAwareByteBuf(PooledUnsafeDirectByteBuf(freed))
> io.netty.util.IllegalReferenceCountException: refCnt: 0, decrement: 1
>   at 
> io.netty.buffer.AbstractReferenceCountedByteBuf.release(AbstractReferenceCountedByteBuf.java:111)
>  ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at io.netty.buffer.WrappedByteBuf.release(WrappedByteBuf.java:1029) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.buffer.AdvancedLeakAwareByteBuf.release(AdvancedLeakAwareByteBuf.java:951)
>  ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:84) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.util.ReferenceCountUtil.safeRelease(ReferenceCountUtil.java:109) 
> ~[netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundBuffer.remove0(ChannelOutboundBuffer.java:296)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundBuffer.failFlushed(ChannelOutboundBuffer.java:621)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.flush0(AbstractChannel.java:869)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.flush0(AbstractNioChannel.java:362)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.flush(AbstractChannel.java:823)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.flush(DefaultChannelPipeline.java:1296)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:786)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:778)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:759)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.flush(CombinedChannelDuplexHandler.java:530)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:115)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.CombinedChannelDuplexHandler.flush(CombinedChannelDuplexHandler.java:355)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:786)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:812)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:824)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:804)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:841)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1032)
>  [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:296) 
> [netty-all-4.1.5.Final.jar:4.1.5.Final]
>   at 
> org.apache.camel.component.netty4.NettyHelper.writeBodyAsync(NettyHelper.java:105)
>  [camel-netty4-2.18.0.jar:2.18.0]
>   at 
>

[jira] [Resolved] (CAMEL-10178) Google Cloud PubSub Component

2016-11-14 Thread Andrea Cosentino (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CAMEL-10178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Cosentino resolved CAMEL-10178.
--
Resolution: Fixed

> Google Cloud PubSub Component
> -
>
> Key: CAMEL-10178
> URL: https://issues.apache.org/jira/browse/CAMEL-10178
> Project: Camel
>  Issue Type: New Feature
>Reporter: Evgeny Minkevich
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.19.0
>
>
> As a solution architect I need a Google Cloud PubSub component - both 
> producer and consumer parts - to be available as a part of the Camel stack.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10336) Complete AMI features

2016-11-14 Thread Claus Ibsen (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CAMEL-10336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10336:

Component/s: (was: el-asterisk)
 camel-asterisk

> Complete AMI features
> -
>
> Key: CAMEL-10336
> URL: https://issues.apache.org/jira/browse/CAMEL-10336
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-asterisk
>Affects Versions: 2.18.0
>Reporter: Fabrizio Spataro
>Assignee: Fabrizio Spataro
> Fix For: 2.19.0, 2.18.2
>
>
> After resolution of CAMEL-10321 apache camel have a new component: 
> "camel-asterisk".
> This initial release support a little subset of AMI API
> This issue to remember me to insert new functionalities.
> http://www.voip-info.org/wiki/view/Asterisk+manager+API



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10336) Complete AMI features

2016-11-14 Thread Claus Ibsen (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CAMEL-10336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10336:

Component/s: el-asterisk

> Complete AMI features
> -
>
> Key: CAMEL-10336
> URL: https://issues.apache.org/jira/browse/CAMEL-10336
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-asterisk
>Affects Versions: 2.18.0
>Reporter: Fabrizio Spataro
>Assignee: Fabrizio Spataro
> Fix For: 2.19.0, 2.18.2
>
>
> After resolution of CAMEL-10321 apache camel have a new component: 
> "camel-asterisk".
> This initial release support a little subset of AMI API
> This issue to remember me to insert new functionalities.
> http://www.voip-info.org/wiki/view/Asterisk+manager+API



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10178) Google Cloud PubSub Component

2016-11-14 Thread Andrea Cosentino (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CAMEL-10178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Cosentino updated CAMEL-10178:
-
Fix Version/s: 2.19.0

> Google Cloud PubSub Component
> -
>
> Key: CAMEL-10178
> URL: https://issues.apache.org/jira/browse/CAMEL-10178
> Project: Camel
>  Issue Type: New Feature
>Reporter: Evgeny Minkevich
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.19.0
>
>
> As a solution architect I need a Google Cloud PubSub component - both 
> producer and consumer parts - to be available as a part of the Camel stack.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10336) Complete AMI features

2016-11-14 Thread Claus Ibsen (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CAMEL-10336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10336:

Fix Version/s: (was: 2.18.1)
   2.19.0
   2.18.2

> Complete AMI features
> -
>
> Key: CAMEL-10336
> URL: https://issues.apache.org/jira/browse/CAMEL-10336
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-asterisk
>Affects Versions: 2.18.0
>Reporter: Fabrizio Spataro
>Assignee: Fabrizio Spataro
> Fix For: 2.19.0, 2.18.2
>
>
> After resolution of CAMEL-10321 apache camel have a new component: 
> "camel-asterisk".
> This initial release support a little subset of AMI API
> This issue to remember me to insert new functionalities.
> http://www.voip-info.org/wiki/view/Asterisk+manager+API



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10353) Enable Hazelcast Distributed Computing

2016-11-14 Thread Claus Ibsen (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CAMEL-10353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10353:

Fix Version/s: (was: 2.18.1)
   2.19.0

> Enable Hazelcast Distributed Computing
> --
>
> Key: CAMEL-10353
> URL: https://issues.apache.org/jira/browse/CAMEL-10353
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-hazelcast
>Reporter: Fabrizio Spataro
>Assignee: Fabrizio Spataro
> Fix For: 2.19.0
>
>
> Add the ability to execute distributed task through Hazelcast Cluster
> http://docs.hazelcast.org/docs/3.7/manual/html-single/index.html#distributed-computing



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10178) Google Cloud PubSub Component

2016-11-14 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-10178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15663113#comment-15663113
 ] 

ASF GitHub Bot commented on CAMEL-10178:


Github user evmin closed the pull request at:

https://github.com/apache/camel/pull/1267


> Google Cloud PubSub Component
> -
>
> Key: CAMEL-10178
> URL: https://issues.apache.org/jira/browse/CAMEL-10178
> Project: Camel
>  Issue Type: New Feature
>Reporter: Evgeny Minkevich
>Assignee: Andrea Cosentino
>Priority: Minor
>
> As a solution architect I need a Google Cloud PubSub component - both 
> producer and consumer parts - to be available as a part of the Camel stack.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)