date:20160324


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

Claus Ibsen commented on CAMEL-9741:


Can you attach the file as .zip.

> recipientList stop if the second endpoint throw exception
> -
>
> Key: CAMEL-9741
> URL: https://issues.apache.org/jira/browse/CAMEL-9741
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.16.2
>Reporter: courtin
>Assignee: Claus Ibsen
> Fix For: 2.16.3, 2.18.0, 2.17.1
>
> Attachments: recipientList.rar
>
>
> this code is ok and do the agregate :
>  from("direct:rlAggregate")
> .process(new Processor() { String   destinations = 
> "bean:throwingExceptionConsumerB, bean:consumerC";} })
> .recipientList(header("destinations"), 
> ",").parallelProcessing().aggregationStrategy(agg);
> an this one not :
>  from("direct:rlAggregate")
> .process(new Processor() { String   destinations = 
> "bean:consumerC, bean:throwingExceptionConsumerB";} })
> .recipientList(header("destinations"), 
> ",").parallelProcessing().aggregationStrategy(agg);
> it's throwing :
> org.apache.camel.CamelExecutionException: Exception occurred during execution 
> on the exchange
> they should have the same results. And only the option stopOnException should 
> allow to stop when an Exception rise.



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

[jira] [Commented] (CAMEL-9741) recipientList stop if the second endpoint throw exception

2016-03-24 Thread courtin (JIRA)


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

courtin commented on CAMEL-9741:


i attach my unit test

> recipientList stop if the second endpoint throw exception
> -
>
> Key: CAMEL-9741
> URL: https://issues.apache.org/jira/browse/CAMEL-9741
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.16.2
>Reporter: courtin
>Assignee: Claus Ibsen
> Fix For: 2.16.3, 2.18.0, 2.17.1
>
> Attachments: recipientList.rar
>
>
> this code is ok and do the agregate :
>  from("direct:rlAggregate")
> .process(new Processor() { String   destinations = 
> "bean:throwingExceptionConsumerB, bean:consumerC";} })
> .recipientList(header("destinations"), 
> ",").parallelProcessing().aggregationStrategy(agg);
> an this one not :
>  from("direct:rlAggregate")
> .process(new Processor() { String   destinations = 
> "bean:consumerC, bean:throwingExceptionConsumerB";} })
> .recipientList(header("destinations"), 
> ",").parallelProcessing().aggregationStrategy(agg);
> it's throwing :
> org.apache.camel.CamelExecutionException: Exception occurred during execution 
> on the exchange
> they should have the same results. And only the option stopOnException should 
> allow to stop when an Exception rise.



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

[jira] [Updated] (CAMEL-9741) recipientList stop if the second endpoint throw exception

2016-03-24 Thread courtin (JIRA)


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

courtin updated CAMEL-9741:
---
Attachment: recipientList.rar

> recipientList stop if the second endpoint throw exception
> -
>
> Key: CAMEL-9741
> URL: https://issues.apache.org/jira/browse/CAMEL-9741
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.16.2
>Reporter: courtin
>Assignee: Claus Ibsen
> Fix For: 2.16.3, 2.18.0, 2.17.1
>
> Attachments: recipientList.rar
>
>
> this code is ok and do the agregate :
>  from("direct:rlAggregate")
> .process(new Processor() { String   destinations = 
> "bean:throwingExceptionConsumerB, bean:consumerC";} })
> .recipientList(header("destinations"), 
> ",").parallelProcessing().aggregationStrategy(agg);
> an this one not :
>  from("direct:rlAggregate")
> .process(new Processor() { String   destinations = 
> "bean:consumerC, bean:throwingExceptionConsumerB";} })
> .recipientList(header("destinations"), 
> ",").parallelProcessing().aggregationStrategy(agg);
> it's throwing :
> org.apache.camel.CamelExecutionException: Exception occurred during execution 
> on the exchange
> they should have the same results. And only the option stopOnException should 
> allow to stop when an Exception rise.



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

[jira] [Updated] (CAMEL-9755) Allow for nickserv identification

2016-03-24 Thread Kevin Telford (JIRA)


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

Kevin Telford updated CAMEL-9755:
-
Attachment: camel-irc_nickserv-identification_patch.txt

patch for nickserv identification

> Allow for nickserv identification
> -
>
> Key: CAMEL-9755
> URL: https://issues.apache.org/jira/browse/CAMEL-9755
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-irc
>Reporter: Kevin Telford
>Priority: Minor
> Attachments: camel-irc_nickserv-identification_patch.txt
>
>
> I think the Camel IRC component should allow for identifying a user w/the 
> servers nickserv 
> (https://meta.wikimedia.org/wiki/IRC/Instructions#Register_your_nickname.2C_identify.2C_and_enforce).
>   Attached is a patch to allow that to happen for the IrcConsumer.   The same 
> action could be applied to the IrcProducer if the IrcConfiguration was 
> available in that class.
> Part of what I did was also to put a Thread.sleep() before the 
> identification.  I did this because when connecting to some servers (ex 
> irc.anonops.com:6697) I found I needed to pause for a few moments while the 
> server completed the connection and displayed a bunch of banner info.  Having 
> an additional param to pause before joining channels may be worth 
> implementing as well, however I tried not to do too much customization since 
> I'm not that familiar with the component code.



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

[jira] [Created] (CAMEL-9755) Allow for nickserv identification

2016-03-24 Thread Kevin Telford (JIRA)

Kevin Telford created CAMEL-9755:


 Summary: Allow for nickserv identification
 Key: CAMEL-9755
 URL: https://issues.apache.org/jira/browse/CAMEL-9755
 Project: Camel
  Issue Type: Improvement
  Components: camel-irc
Reporter: Kevin Telford
Priority: Minor


I think the Camel IRC component should allow for identifying a user w/the 
servers nickserv 
(https://meta.wikimedia.org/wiki/IRC/Instructions#Register_your_nickname.2C_identify.2C_and_enforce).
  Attached is a patch to allow that to happen for the IrcConsumer.   The same 
action could be applied to the IrcProducer if the IrcConfiguration was 
available in that class.

Part of what I did was also to put a Thread.sleep() before the identification.  
I did this because when connecting to some servers (ex irc.anonops.com:6697) I 
found I needed to pause for a few moments while the server completed the 
connection and displayed a bunch of banner info.  Having an additional param to 
pause before joining channels may be worth implementing as well, however I 
tried not to do too much customization since I'm not that familiar with the 
component code.



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

[jira] [Created] (CAMEL-9754) Convert from maven-bundle-plugin to bnd-maven-plugin

2016-03-24 Thread Quinn Stevenson (JIRA)

Quinn Stevenson created CAMEL-9754:
--

 Summary: Convert from maven-bundle-plugin to bnd-maven-plugin
 Key: CAMEL-9754
 URL: https://issues.apache.org/jira/browse/CAMEL-9754
 Project: Camel
  Issue Type: Improvement
  Components: camel-core
Reporter: Quinn Stevenson


Currently, the v2.3.7 of the maven-bundle-plugin is used to generate the OSGi 
Manifests for the Camel libraries.  The project cannot upgrade to a later 
version of the maven-bundle-plugin because the newer versions break the build.

The bnd-maven-plugin is maintained by the same group that maintains the BND 
libraries (which both plugins use internally) expedites updates to the plugin 
when the underlying libraries change.  Also, the bnd-maven-plugin uses the same 
BND configuration file format as BND, which eliminates the complex mapping from 
XML to BND configuration that the maven-bundle-plugin has to deal with.

The goals are:
 - change from the maven-bundle-plugin to the bnd-maven-plugin
 - upgrade the OSGi version
 - upgrade the default OSGi dependencies in the parent POM




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

[jira] [Comment Edited] (CAMEL-9716) Camel KafkaConsumer should be able to re-consume the Kafka stream.

2016-03-24 Thread JIRA


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

Sebastian Rühl edited comment on CAMEL-9716 at 3/24/16 4:33 PM:


[https://issues.apache.org/jira/browse/KAFKA-3458] this issue might solve the 
problem described in the patch


was (Author: sruehl):
this issue might solve the problem described in the patch

> Camel KafkaConsumer should be able to re-consume the Kafka stream.
> --
>
> Key: CAMEL-9716
> URL: https://issues.apache.org/jira/browse/CAMEL-9716
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-kafka
>Affects Versions: 2.17.0
>Reporter: Sebastian Rühl
>Priority: Minor
> Fix For: 2.18.0
>
> Attachments: 
> _CAMEL_9716__call_wakeup_on_kafka_consumer_to_enforce_shutdown.patch
>
>
> In some corner cases we should be able to re-consume a Kafka stream from the 
> beginning on startup of the endpoint.
> For this the Kafka-KafkaConsumer has a method
> {code:java}
>public void seekToBeginning(TopicPartition... partitions) {
> {code}
> {panel:title= Sidenode 
> |borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> There are other methods to manipulate offsets but for this ticket we just 
> look on the re-consume corner case.
> {panel}
> Currently I have implemented this support in a branch here 
> ([https://github.com/sruehl/camel/tree/feature/kafka-seek-support]) and have 
> also written an jUnit test.
> -At this time this test still fails for unknown reasons.-
> I would be keen on some feedback on this feature and also would like to 
> advance this branch to make it mergable. 



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

[jira] [Commented] (CAMEL-9716) Camel KafkaConsumer should be able to re-consume the Kafka stream.

2016-03-24 Thread JIRA


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

Sebastian Rühl commented on CAMEL-9716:
---

this issue might solve the problem described in the patch

> Camel KafkaConsumer should be able to re-consume the Kafka stream.
> --
>
> Key: CAMEL-9716
> URL: https://issues.apache.org/jira/browse/CAMEL-9716
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-kafka
>Affects Versions: 2.17.0
>Reporter: Sebastian Rühl
>Priority: Minor
> Fix For: 2.18.0
>
> Attachments: 
> _CAMEL_9716__call_wakeup_on_kafka_consumer_to_enforce_shutdown.patch
>
>
> In some corner cases we should be able to re-consume a Kafka stream from the 
> beginning on startup of the endpoint.
> For this the Kafka-KafkaConsumer has a method
> {code:java}
>public void seekToBeginning(TopicPartition... partitions) {
> {code}
> {panel:title= Sidenode 
> |borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> There are other methods to manipulate offsets but for this ticket we just 
> look on the re-consume corner case.
> {panel}
> Currently I have implemented this support in a branch here 
> ([https://github.com/sruehl/camel/tree/feature/kafka-seek-support]) and have 
> also written an jUnit test.
> -At this time this test still fails for unknown reasons.-
> I would be keen on some feedback on this feature and also would like to 
> advance this branch to make it mergable. 



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

[jira] [Assigned] (CAMEL-6132) camel-test-karaf - To allow end users more easily do Camel and Karaf integration test

2016-03-24 Thread Quinn Stevenson (JIRA)


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

Quinn Stevenson reassigned CAMEL-6132:
--

Assignee: Quinn Stevenson

> camel-test-karaf - To allow end users more easily do Camel and Karaf 
> integration test
> -
>
> Key: CAMEL-6132
> URL: https://issues.apache.org/jira/browse/CAMEL-6132
> Project: Camel
>  Issue Type: New Feature
>  Components: karaf
>Reporter: Claus Ibsen
>Assignee: Quinn Stevenson
> Fix For: Future
>
>
> We should introduce a proper camel-test-karaf component that *end users* can 
> use to do Camel and Karaf integration tests.
> The code we have in tests/camel-itest-karaf is for internal usage and testing 
> of Camel. The code is not polished and intended for end users.
> We should create a new module for that, and take the good parts of 
> camel-itest-karaf and make it user friendly etc. And of course have docs to 
> go with as well.
> And when its good, we can use that in camel-itest-karaf also (eat our own dog 
> food)



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

[jira] [Resolved] (CAMEL-9736) SolrComponent gets the wrong Content Type

2016-03-24 Thread Andrea Cosentino (JIRA)


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

Andrea Cosentino resolved CAMEL-9736.
-
Resolution: Fixed

> SolrComponent gets the wrong Content Type
> -
>
> Key: CAMEL-9736
> URL: https://issues.apache.org/jira/browse/CAMEL-9736
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-solr
>Affects Versions: 2.16.2
> Environment: Linux
>Reporter: Mansour Al Akeel
>Assignee: Andrea Cosentino
>Priority: Minor
>  Labels: content-type, indexing, solr
> Fix For: 2.18.0, 2.17.1
>
>
> Currently, there is no way to specify the content type. It's extracted 
> automatically from the File in the body of the Message. This results in error 
> when indexing a document. Setting Exchange.CONTENT_TYPE or 
> Exchange.FILE_CONTENT_TYPE does not help. 
> For example, neither of these would work, as the component ignores the header 
> and reads the file type in SolrProducer:
>if (body instanceof File) {
> MimetypesFileTypeMap mimeTypesMap = new MimetypesFileTypeMap();
> String mimeType = mimeTypesMap.getContentType((File)body);
> ContentStreamUpdateRequest updateRequest = new
> ContentStreamUpdateRequest(getRequestHandler());
> updateRequest.addFile((File) body, mimeType);
> A simple solution could be to check if the Exchange.FILE_CONTENT_TYPE is set, 
> before trying to extract if from mimeTypesMap. 



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

[jira] [Commented] (CAMEL-6132) camel-test-karaf - To allow end users more easily do Camel and Karaf integration test


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

Claus Ibsen commented on CAMEL-6132:


Karaf 2 is no longer supported.

Moving forward we focus on Karaf 4. Karaf 3.x is in maintenance mode and we do 
not want to put so much effort in that release.

> camel-test-karaf - To allow end users more easily do Camel and Karaf 
> integration test
> -
>
> Key: CAMEL-6132
> URL: https://issues.apache.org/jira/browse/CAMEL-6132
> Project: Camel
>  Issue Type: New Feature
>  Components: karaf
>Reporter: Claus Ibsen
> Fix For: Future
>
>
> We should introduce a proper camel-test-karaf component that *end users* can 
> use to do Camel and Karaf integration tests.
> The code we have in tests/camel-itest-karaf is for internal usage and testing 
> of Camel. The code is not polished and intended for end users.
> We should create a new module for that, and take the good parts of 
> camel-itest-karaf and make it user friendly etc. And of course have docs to 
> go with as well.
> And when its good, we can use that in camel-itest-karaf also (eat our own dog 
> food)



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

[jira] [Created] (CAMEL-9753) Improve endpoint configuration

Luca Burgazzoli created CAMEL-9753:
--

 Summary: Improve endpoint configuration
 Key: CAMEL-9753
 URL: https://issues.apache.org/jira/browse/CAMEL-9753
 Project: Camel
  Issue Type: Improvement
  Components: camel-core
Reporter: Luca Burgazzoli
Priority: Minor
 Fix For: 3.0.0, Future


See 
http://camel.465427.n5.nabble.com/Improve-endpoint-configuration-td5779566.html



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

[jira] [Commented] (CAMEL-6132) camel-test-karaf - To allow end users more easily do Camel and Karaf integration test

2016-03-24 Thread Quinn Stevenson (JIRA)


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

Quinn Stevenson commented on CAMEL-6132:


I have a start on this I put together while working with a customer - I'll get 
a PR going so it can be reviewed.

However, with the discussion going on about what version(s) of Karaf will be 
supported, should we have a module for each version of karaf?  (something like 
camel-test-karaf-v2 and camel-test-karaf-v4)

> camel-test-karaf - To allow end users more easily do Camel and Karaf 
> integration test
> -
>
> Key: CAMEL-6132
> URL: https://issues.apache.org/jira/browse/CAMEL-6132
> Project: Camel
>  Issue Type: New Feature
>  Components: karaf
>Reporter: Claus Ibsen
> Fix For: Future
>
>
> We should introduce a proper camel-test-karaf component that *end users* can 
> use to do Camel and Karaf integration tests.
> The code we have in tests/camel-itest-karaf is for internal usage and testing 
> of Camel. The code is not polished and intended for end users.
> We should create a new module for that, and take the good parts of 
> camel-itest-karaf and make it user friendly etc. And of course have docs to 
> go with as well.
> And when its good, we can use that in camel-itest-karaf also (eat our own dog 
> food)



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

[jira] [Comment Edited] (CAMEL-9040) netty4-http - LEAK: ByteBuf.release() was not called before it's garbage-collected

2016-03-24 Thread Ralf Steppacher (JIRA)


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

Ralf Steppacher edited comment on CAMEL-9040 at 3/24/16 1:33 PM:
-

Sorry for the long wait!

I tried with 2.16.2 and the problem persists. Though it appears it only shows 
under load now. When making single requests there are no errors. But when 
running my stress tests I start to get intermittent errors as before (with 
-Dio.netty.leakDetectionLevel=paranoid):

{noformat}
2016-03-24 14:28:08,486 | ERROR | qtp99151234-420  | ResourceLeakDetector   
  | 63 - io.netty.common - 4.0.33.Final | 
ID-Ralfs-MacBook-Pro-local-57997-1458825709312-5-15981  | LEAK: 
ByteBuf.release() was not called before it's garbage-collected. See 
http://netty.io/wiki/reference-counted-objects.html for more information.
Recent access records: 5
#5:

io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:245)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:687)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:42)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:694)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1496)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:42)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
java.io.BufferedInputStream.read(BufferedInputStream.java:345)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.MergedReader.read(MergedReader.java:105)
com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:86)

com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:56)
com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:1001)
com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:1046)
com.ctc.wstx.sr.StreamScanner.getNextChar(StreamScanner.java:793)

com.ctc.wstx.sr.BasicStreamReader.parseAttrValue(BasicStreamReader.java:1894)

com.ctc.wstx.sr.BasicStreamReader.handleNsAttrs(BasicStreamReader.java:3065)

com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2963)

com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2839)
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1073)

ch.vivates.pep.stream.ResponseStatusFilter.handleSimpleMessage(ResponseStatusFilter.java:61)
ch.vivates.pep.stream.BaseStreamFilter.filter(BaseStreamFilter.java:168)
ch.vivates.pep.stream.BaseStreamFilter.run(BaseStreamFilter.java:184)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
java.util.concurrent.FutureTask.run(FutureTask.java:266)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)
#4:

io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:245)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:687)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:42)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:694)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1496)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:42)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
java.io.BufferedInputStream.read(BufferedInputStream.java:345)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.MergedReader.read(MergedReader.java:105)
com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:86)

com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:56)

com.ctc.wstx.sr.StreamScanner.loadMoreFromCurrent(StreamScanner.java:1060)
com.ctc.wstx.sr.StreamScanner.parseLocalName2(StreamScanner.java:1870)
com.ctc.wstx.sr.StreamScanner.parseLocalName(StreamScanner.java:1830)

com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2941)

[jira] [Commented] (CAMEL-9040) netty4-http - LEAK: ByteBuf.release() was not called before it's garbage-collected

2016-03-24 Thread Ralf Steppacher (JIRA)


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

Ralf Steppacher commented on CAMEL-9040:


I tried with 2.16.2 and the problem persists. Though it appears it only shows 
under load now. When making single requests there are no errors. But when 
running my stress tests is start to get intermittent errors as before (with 
-Dio.netty.leakDetectionLevel=paranoid):

{noformat}
2016-03-24 14:28:08,486 | ERROR | qtp99151234-420  | ResourceLeakDetector   
  | 63 - io.netty.common - 4.0.33.Final | 
ID-Ralfs-MacBook-Pro-local-57997-1458825709312-5-15981  | LEAK: 
ByteBuf.release() was not called before it's garbage-collected. See 
http://netty.io/wiki/reference-counted-objects.html for more information.
Recent access records: 5
#5:

io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:245)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:687)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:42)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:694)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1496)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:42)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
java.io.BufferedInputStream.read(BufferedInputStream.java:345)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.MergedReader.read(MergedReader.java:105)
com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:86)

com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:56)
com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:1001)
com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:1046)
com.ctc.wstx.sr.StreamScanner.getNextChar(StreamScanner.java:793)

com.ctc.wstx.sr.BasicStreamReader.parseAttrValue(BasicStreamReader.java:1894)

com.ctc.wstx.sr.BasicStreamReader.handleNsAttrs(BasicStreamReader.java:3065)

com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2963)

com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2839)
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1073)

ch.vivates.pep.stream.ResponseStatusFilter.handleSimpleMessage(ResponseStatusFilter.java:61)
ch.vivates.pep.stream.BaseStreamFilter.filter(BaseStreamFilter.java:168)
ch.vivates.pep.stream.BaseStreamFilter.run(BaseStreamFilter.java:184)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
java.util.concurrent.FutureTask.run(FutureTask.java:266)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)
#4:

io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:245)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:687)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:42)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:694)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1496)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:42)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
java.io.BufferedInputStream.read(BufferedInputStream.java:345)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.MergedReader.read(MergedReader.java:105)
com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:86)

com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:56)

com.ctc.wstx.sr.StreamScanner.loadMoreFromCurrent(StreamScanner.java:1060)
com.ctc.wstx.sr.StreamScanner.parseLocalName2(StreamScanner.java:1870)
com.ctc.wstx.sr.StreamScanner.parseLocalName(StreamScanner.java:1830)

com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2941)

com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2839)

[jira] [Comment Edited] (CAMEL-9040) netty4-http - LEAK: ByteBuf.release() was not called before it's garbage-collected

2016-03-24 Thread Ralf Steppacher (JIRA)


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

Ralf Steppacher edited comment on CAMEL-9040 at 3/24/16 1:32 PM:
-

Sorry for the long wait!

I tried with 2.16.2 and the problem persists. Though it appears it only shows 
under load now. When making single requests there are no errors. But when 
running my stress tests is start to get intermittent errors as before (with 
-Dio.netty.leakDetectionLevel=paranoid):

{noformat}
2016-03-24 14:28:08,486 | ERROR | qtp99151234-420  | ResourceLeakDetector   
  | 63 - io.netty.common - 4.0.33.Final | 
ID-Ralfs-MacBook-Pro-local-57997-1458825709312-5-15981  | LEAK: 
ByteBuf.release() was not called before it's garbage-collected. See 
http://netty.io/wiki/reference-counted-objects.html for more information.
Recent access records: 5
#5:

io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:245)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:687)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:42)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:694)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1496)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:42)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
java.io.BufferedInputStream.read(BufferedInputStream.java:345)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.MergedReader.read(MergedReader.java:105)
com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:86)

com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:56)
com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:1001)
com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:1046)
com.ctc.wstx.sr.StreamScanner.getNextChar(StreamScanner.java:793)

com.ctc.wstx.sr.BasicStreamReader.parseAttrValue(BasicStreamReader.java:1894)

com.ctc.wstx.sr.BasicStreamReader.handleNsAttrs(BasicStreamReader.java:3065)

com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2963)

com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2839)
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1073)

ch.vivates.pep.stream.ResponseStatusFilter.handleSimpleMessage(ResponseStatusFilter.java:61)
ch.vivates.pep.stream.BaseStreamFilter.filter(BaseStreamFilter.java:168)
ch.vivates.pep.stream.BaseStreamFilter.run(BaseStreamFilter.java:184)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
java.util.concurrent.FutureTask.run(FutureTask.java:266)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)
#4:

io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:245)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:687)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:42)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:694)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1496)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:42)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
java.io.BufferedInputStream.read(BufferedInputStream.java:345)
com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
com.ctc.wstx.io.MergedReader.read(MergedReader.java:105)
com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:86)

com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:56)

com.ctc.wstx.sr.StreamScanner.loadMoreFromCurrent(StreamScanner.java:1060)
com.ctc.wstx.sr.StreamScanner.parseLocalName2(StreamScanner.java:1870)
com.ctc.wstx.sr.StreamScanner.parseLocalName(StreamScanner.java:1830)

com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2941)

[jira] [Resolved] (CAMEL-9752) Quartz2 Scheduled route too many workers

2016-03-24 Thread Andrea Cosentino (JIRA)


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

Andrea Cosentino resolved CAMEL-9752.
-
Resolution: Fixed

> Quartz2 Scheduled route too many workers
> 
>
> Key: CAMEL-9752
> URL: https://issues.apache.org/jira/browse/CAMEL-9752
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core, camel-quartz2
>Affects Versions: 2.16.2
> Environment: ALL
>Reporter: Hans Orbaan
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.16.3, 2.18.0, 2.17.1
>
> Attachments: camel.patch, stacktrace.txt
>
>
> When any file:// or ftp:// consumer has a quartz2 schedule it can start 
> throwing exceptions because too many worker-threads are busy at the same time 
> (FileNotFoundException).
> Both workers can find the same files during filling the maxMessagesPerPoll, 
> or during processing of those files. This happens when the route can not 
> process all files before the next trigger happens.
> example (every minute):
> from(file:///mnt/sl-nl/bij/outbox/?sortBy=ignoreCase:file:name=#fileFilter=false=processed=failed=0+0/1+0-23+?+*+1,2,3,4,5,6,7=quartz2=nl_bij-export-to-archive-276)
> to(file:///data/work/sl/work-archive/work/276/)
> Attached you can find a stacktrace that would happen very often if worker1 
> processes and moves files that worker2 would also like to start processing.
> This does not happen when using scheduler=spring or when using delay=1m.
> The only way I have found to make sure a file or ftp component does not use 
> multiple threads while consuming very large batches is to annotate the 
> QuartzScheduledPollConsumerJob class with @DisallowConcurrentExecution.
> I am not familiar enough with the Camelcode to say what side effects it has 
> and if this would prevent any quartz job in camel to now be single threaded, 
> even if the user does not want it to be.
> But to me it looks like an oversight when moving from quartz to quartz2. A 
> file or ftp consumer should be single threaded while retrieving.



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

[jira] [Commented] (CAMEL-9749) Missing qpid-amqp-1-0-client-jms dependency in the camel-amqp feature


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

Claus Ibsen commented on CAMEL-9749:


Can you provide the fix as a patch or PR?

> Missing qpid-amqp-1-0-client-jms dependency in the camel-amqp feature
> -
>
> Key: CAMEL-9749
> URL: https://issues.apache.org/jira/browse/CAMEL-9749
> Project: Camel
>  Issue Type: Bug
>  Components: karaf
>Affects Versions: 2.16.2
> Environment: Java 8
>Reporter: Xilai Dai
> Fix For: 2.16.3
>
>
> There is error exception when trying to install camel-amqp feature install 
> karaf OSGi container with command: feature:install camel-amqp
> {code}
> 13:45:39,884 | ERROR | nsole user karaf | he.karaf.shell.support.ShellUtil  
> 149 | 52 - org.apache.karaf.shell.core - 4.0.4 | Exception caught while 
> executing command
> org.osgi.service.resolver.ResolutionException: Unable to resolve root: 
> missing requirement [root] osgi.identity; osgi.identity=camel-amqp; 
> type=karaf.feature; version="[2.16.2,2.16.2]"; 
> filter:="(&(osgi.identity=camel-amqp)(type=karaf.feature)(version>=2.16.2)(version<=2.16.2))"
>  [caused by: Unable to resolve camel-amqp/2.16.2: missing requirement 
> [camel-amqp/2.16.2] osgi.identity; osgi.identity=org.apache.camel.camel-amqp; 
> type=osgi.bundle; version="[2.16.2,2.16.2]"; resolution:=mandatory [caused 
> by: Unable to resolve org.apache.camel.camel-amqp/2.16.2: missing requirement 
> [org.apache.camel.camel-amqp/2.16.2] osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=org.apache.qpid.amqp_1_0.jms.impl)(version>=0.20.0)(!(version>=1.0.0)))"]]
> {code}
> the camel-amqp 2.16.2 bundle introduce a new qpid-amqp-1-0-client-jms 
> dependency, it should be also added into camel-amqp feature definition.
> Fix proposal (tested):
> {code}
> wrap:mvn:org.apache.qpid/qpid-amqp-1-0-client-jms/0.28$Bundle-SymbolicName=qpid-amqp-1-0-client-jmsBundle-Version=0.28Export-Package=org.apache.qpid.amqp_1_0.jms.*;version=0.28
> {code}



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

[jira] [Updated] (CAMEL-9749) Missing qpid-amqp-1-0-client-jms dependency in the camel-amqp feature


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

Claus Ibsen updated CAMEL-9749:
---
Fix Version/s: 2.16.3

> Missing qpid-amqp-1-0-client-jms dependency in the camel-amqp feature
> -
>
> Key: CAMEL-9749
> URL: https://issues.apache.org/jira/browse/CAMEL-9749
> Project: Camel
>  Issue Type: Bug
>  Components: karaf
>Affects Versions: 2.16.2
> Environment: Java 8
>Reporter: Xilai Dai
> Fix For: 2.16.3
>
>
> There is error exception when trying to install camel-amqp feature install 
> karaf OSGi container with command: feature:install camel-amqp
> {code}
> 13:45:39,884 | ERROR | nsole user karaf | he.karaf.shell.support.ShellUtil  
> 149 | 52 - org.apache.karaf.shell.core - 4.0.4 | Exception caught while 
> executing command
> org.osgi.service.resolver.ResolutionException: Unable to resolve root: 
> missing requirement [root] osgi.identity; osgi.identity=camel-amqp; 
> type=karaf.feature; version="[2.16.2,2.16.2]"; 
> filter:="(&(osgi.identity=camel-amqp)(type=karaf.feature)(version>=2.16.2)(version<=2.16.2))"
>  [caused by: Unable to resolve camel-amqp/2.16.2: missing requirement 
> [camel-amqp/2.16.2] osgi.identity; osgi.identity=org.apache.camel.camel-amqp; 
> type=osgi.bundle; version="[2.16.2,2.16.2]"; resolution:=mandatory [caused 
> by: Unable to resolve org.apache.camel.camel-amqp/2.16.2: missing requirement 
> [org.apache.camel.camel-amqp/2.16.2] osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=org.apache.qpid.amqp_1_0.jms.impl)(version>=0.20.0)(!(version>=1.0.0)))"]]
> {code}
> the camel-amqp 2.16.2 bundle introduce a new qpid-amqp-1-0-client-jms 
> dependency, it should be also added into camel-amqp feature definition.
> Fix proposal (tested):
> {code}
> wrap:mvn:org.apache.qpid/qpid-amqp-1-0-client-jms/0.28$Bundle-SymbolicName=qpid-amqp-1-0-client-jmsBundle-Version=0.28Export-Package=org.apache.qpid.amqp_1_0.jms.*;version=0.28
> {code}



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

[jira] [Commented] (CAMEL-9752) Quartz2 Scheduled route too many workers

2016-03-24 Thread Andrea Cosentino (JIRA)


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

Andrea Cosentino commented on CAMEL-9752:
-

[~davsclaus], yes :-)

> Quartz2 Scheduled route too many workers
> 
>
> Key: CAMEL-9752
> URL: https://issues.apache.org/jira/browse/CAMEL-9752
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core, camel-quartz2
>Affects Versions: 2.16.2
> Environment: ALL
>Reporter: Hans Orbaan
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.16.3, 2.18.0, 2.17.1
>
> Attachments: camel.patch, stacktrace.txt
>
>
> When any file:// or ftp:// consumer has a quartz2 schedule it can start 
> throwing exceptions because too many worker-threads are busy at the same time 
> (FileNotFoundException).
> Both workers can find the same files during filling the maxMessagesPerPoll, 
> or during processing of those files. This happens when the route can not 
> process all files before the next trigger happens.
> example (every minute):
> from(file:///mnt/sl-nl/bij/outbox/?sortBy=ignoreCase:file:name=#fileFilter=false=processed=failed=0+0/1+0-23+?+*+1,2,3,4,5,6,7=quartz2=nl_bij-export-to-archive-276)
> to(file:///data/work/sl/work-archive/work/276/)
> Attached you can find a stacktrace that would happen very often if worker1 
> processes and moves files that worker2 would also like to start processing.
> This does not happen when using scheduler=spring or when using delay=1m.
> The only way I have found to make sure a file or ftp component does not use 
> multiple threads while consuming very large batches is to annotate the 
> QuartzScheduledPollConsumerJob class with @DisallowConcurrentExecution.
> I am not familiar enough with the Camelcode to say what side effects it has 
> and if this would prevent any quartz job in camel to now be single threaded, 
> even if the user does not want it to be.
> But to me it looks like an oversight when moving from quartz to quartz2. A 
> file or ftp consumer should be single threaded while retrieving.



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

[jira] [Resolved] (CAMEL-9750) Tests should not log on stdout by default


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

Luca Burgazzoli resolved CAMEL-9750.

   Resolution: Fixed
Fix Version/s: 2.18.0

> Tests should not log on stdout by default
> -
>
> Key: CAMEL-9750
> URL: https://issues.apache.org/jira/browse/CAMEL-9750
> Project: Camel
>  Issue Type: Task
>  Components: camel-etcd
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Minor
> Fix For: 2.18.0
>
>




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

[jira] [Commented] (CAMEL-9752) Quartz2 Scheduled route too many workers


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

Claus Ibsen commented on CAMEL-9752:


Andrea can you apply the patch to those branches.

Thanks Hans for the patch.

> Quartz2 Scheduled route too many workers
> 
>
> Key: CAMEL-9752
> URL: https://issues.apache.org/jira/browse/CAMEL-9752
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core, camel-quartz2
>Affects Versions: 2.16.2
> Environment: ALL
>Reporter: Hans Orbaan
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.16.3, 2.18.0, 2.17.1
>
> Attachments: camel.patch, stacktrace.txt
>
>
> When any file:// or ftp:// consumer has a quartz2 schedule it can start 
> throwing exceptions because too many worker-threads are busy at the same time 
> (FileNotFoundException).
> Both workers can find the same files during filling the maxMessagesPerPoll, 
> or during processing of those files. This happens when the route can not 
> process all files before the next trigger happens.
> example (every minute):
> from(file:///mnt/sl-nl/bij/outbox/?sortBy=ignoreCase:file:name=#fileFilter=false=processed=failed=0+0/1+0-23+?+*+1,2,3,4,5,6,7=quartz2=nl_bij-export-to-archive-276)
> to(file:///data/work/sl/work-archive/work/276/)
> Attached you can find a stacktrace that would happen very often if worker1 
> processes and moves files that worker2 would also like to start processing.
> This does not happen when using scheduler=spring or when using delay=1m.
> The only way I have found to make sure a file or ftp component does not use 
> multiple threads while consuming very large batches is to annotate the 
> QuartzScheduledPollConsumerJob class with @DisallowConcurrentExecution.
> I am not familiar enough with the Camelcode to say what side effects it has 
> and if this would prevent any quartz job in camel to now be single threaded, 
> even if the user does not want it to be.
> But to me it looks like an oversight when moving from quartz to quartz2. A 
> file or ftp consumer should be single threaded while retrieving.



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

[jira] [Commented] (CAMEL-9750) Tests should not log on stdout by default


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

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

Github user lburgazzoli closed the pull request at:

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


> Tests should not log on stdout by default
> -
>
> Key: CAMEL-9750
> URL: https://issues.apache.org/jira/browse/CAMEL-9750
> Project: Camel
>  Issue Type: Task
>  Components: camel-etcd
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Minor
>




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

[jira] [Updated] (CAMEL-9752) Quartz2 Scheduled route too many workers


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

Claus Ibsen updated CAMEL-9752:
---
Assignee: Andrea Cosentino

> Quartz2 Scheduled route too many workers
> 
>
> Key: CAMEL-9752
> URL: https://issues.apache.org/jira/browse/CAMEL-9752
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core, camel-quartz2
>Affects Versions: 2.16.2
> Environment: ALL
>Reporter: Hans Orbaan
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.16.3, 2.18.0, 2.17.1
>
> Attachments: camel.patch, stacktrace.txt
>
>
> When any file:// or ftp:// consumer has a quartz2 schedule it can start 
> throwing exceptions because too many worker-threads are busy at the same time 
> (FileNotFoundException).
> Both workers can find the same files during filling the maxMessagesPerPoll, 
> or during processing of those files. This happens when the route can not 
> process all files before the next trigger happens.
> example (every minute):
> from(file:///mnt/sl-nl/bij/outbox/?sortBy=ignoreCase:file:name=#fileFilter=false=processed=failed=0+0/1+0-23+?+*+1,2,3,4,5,6,7=quartz2=nl_bij-export-to-archive-276)
> to(file:///data/work/sl/work-archive/work/276/)
> Attached you can find a stacktrace that would happen very often if worker1 
> processes and moves files that worker2 would also like to start processing.
> This does not happen when using scheduler=spring or when using delay=1m.
> The only way I have found to make sure a file or ftp component does not use 
> multiple threads while consuming very large batches is to annotate the 
> QuartzScheduledPollConsumerJob class with @DisallowConcurrentExecution.
> I am not familiar enough with the Camelcode to say what side effects it has 
> and if this would prevent any quartz job in camel to now be single threaded, 
> even if the user does not want it to be.
> But to me it looks like an oversight when moving from quartz to quartz2. A 
> file or ftp consumer should be single threaded while retrieving.



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

[jira] [Commented] (CAMEL-9737) Create camel component for ServiceNow


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

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

Github user lburgazzoli closed the pull request at:

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


> Create camel component for ServiceNow
> -
>
> Key: CAMEL-9737
> URL: https://issues.apache.org/jira/browse/CAMEL-9737
> Project: Camel
>  Issue Type: New Feature
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
> Fix For: 2.18.0
>
>




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

[jira] [Resolved] (CAMEL-9737) Create camel component for ServiceNow


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

Luca Burgazzoli resolved CAMEL-9737.

   Resolution: Fixed
Fix Version/s: 2.18.0

> Create camel component for ServiceNow
> -
>
> Key: CAMEL-9737
> URL: https://issues.apache.org/jira/browse/CAMEL-9737
> Project: Camel
>  Issue Type: New Feature
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
> Fix For: 2.18.0
>
>




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

[jira] [Updated] (CAMEL-9752) Quartz2 Scheduled route too many workers


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

Claus Ibsen updated CAMEL-9752:
---
Fix Version/s: (was: 2.17.0)
   2.17.1
   2.18.0

> Quartz2 Scheduled route too many workers
> 
>
> Key: CAMEL-9752
> URL: https://issues.apache.org/jira/browse/CAMEL-9752
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core, camel-quartz2
>Affects Versions: 2.16.2
> Environment: ALL
>Reporter: Hans Orbaan
>Priority: Minor
> Fix For: 2.16.3, 2.18.0, 2.17.1
>
> Attachments: camel.patch, stacktrace.txt
>
>
> When any file:// or ftp:// consumer has a quartz2 schedule it can start 
> throwing exceptions because too many worker-threads are busy at the same time 
> (FileNotFoundException).
> Both workers can find the same files during filling the maxMessagesPerPoll, 
> or during processing of those files. This happens when the route can not 
> process all files before the next trigger happens.
> example (every minute):
> from(file:///mnt/sl-nl/bij/outbox/?sortBy=ignoreCase:file:name=#fileFilter=false=processed=failed=0+0/1+0-23+?+*+1,2,3,4,5,6,7=quartz2=nl_bij-export-to-archive-276)
> to(file:///data/work/sl/work-archive/work/276/)
> Attached you can find a stacktrace that would happen very often if worker1 
> processes and moves files that worker2 would also like to start processing.
> This does not happen when using scheduler=spring or when using delay=1m.
> The only way I have found to make sure a file or ftp component does not use 
> multiple threads while consuming very large batches is to annotate the 
> QuartzScheduledPollConsumerJob class with @DisallowConcurrentExecution.
> I am not familiar enough with the Camelcode to say what side effects it has 
> and if this would prevent any quartz job in camel to now be single threaded, 
> even if the user does not want it to be.
> But to me it looks like an oversight when moving from quartz to quartz2. A 
> file or ftp consumer should be single threaded while retrieving.



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

[jira] [Updated] (CAMEL-9752) Quartz2 Scheduled route too many workers


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

Claus Ibsen updated CAMEL-9752:
---
Priority: Minor  (was: Critical)

> Quartz2 Scheduled route too many workers
> 
>
> Key: CAMEL-9752
> URL: https://issues.apache.org/jira/browse/CAMEL-9752
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core, camel-quartz2
>Affects Versions: 2.16.2
> Environment: ALL
>Reporter: Hans Orbaan
>Priority: Minor
> Fix For: 2.16.3, 2.17.0
>
> Attachments: camel.patch, stacktrace.txt
>
>
> When any file:// or ftp:// consumer has a quartz2 schedule it can start 
> throwing exceptions because too many worker-threads are busy at the same time 
> (FileNotFoundException).
> Both workers can find the same files during filling the maxMessagesPerPoll, 
> or during processing of those files. This happens when the route can not 
> process all files before the next trigger happens.
> example (every minute):
> from(file:///mnt/sl-nl/bij/outbox/?sortBy=ignoreCase:file:name=#fileFilter=false=processed=failed=0+0/1+0-23+?+*+1,2,3,4,5,6,7=quartz2=nl_bij-export-to-archive-276)
> to(file:///data/work/sl/work-archive/work/276/)
> Attached you can find a stacktrace that would happen very often if worker1 
> processes and moves files that worker2 would also like to start processing.
> This does not happen when using scheduler=spring or when using delay=1m.
> The only way I have found to make sure a file or ftp component does not use 
> multiple threads while consuming very large batches is to annotate the 
> QuartzScheduledPollConsumerJob class with @DisallowConcurrentExecution.
> I am not familiar enough with the Camelcode to say what side effects it has 
> and if this would prevent any quartz job in camel to now be single threaded, 
> even if the user does not want it to be.
> But to me it looks like an oversight when moving from quartz to quartz2. A 
> file or ftp consumer should be single threaded while retrieving.



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

[jira] [Updated] (CAMEL-9752) Quartz2 Scheduled route too many workers


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

Claus Ibsen updated CAMEL-9752:
---
Issue Type: Improvement  (was: Bug)

> Quartz2 Scheduled route too many workers
> 
>
> Key: CAMEL-9752
> URL: https://issues.apache.org/jira/browse/CAMEL-9752
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core, camel-quartz2
>Affects Versions: 2.16.2
> Environment: ALL
>Reporter: Hans Orbaan
>Priority: Minor
> Fix For: 2.16.3, 2.17.0
>
> Attachments: camel.patch, stacktrace.txt
>
>
> When any file:// or ftp:// consumer has a quartz2 schedule it can start 
> throwing exceptions because too many worker-threads are busy at the same time 
> (FileNotFoundException).
> Both workers can find the same files during filling the maxMessagesPerPoll, 
> or during processing of those files. This happens when the route can not 
> process all files before the next trigger happens.
> example (every minute):
> from(file:///mnt/sl-nl/bij/outbox/?sortBy=ignoreCase:file:name=#fileFilter=false=processed=failed=0+0/1+0-23+?+*+1,2,3,4,5,6,7=quartz2=nl_bij-export-to-archive-276)
> to(file:///data/work/sl/work-archive/work/276/)
> Attached you can find a stacktrace that would happen very often if worker1 
> processes and moves files that worker2 would also like to start processing.
> This does not happen when using scheduler=spring or when using delay=1m.
> The only way I have found to make sure a file or ftp component does not use 
> multiple threads while consuming very large batches is to annotate the 
> QuartzScheduledPollConsumerJob class with @DisallowConcurrentExecution.
> I am not familiar enough with the Camelcode to say what side effects it has 
> and if this would prevent any quartz job in camel to now be single threaded, 
> even if the user does not want it to be.
> But to me it looks like an oversight when moving from quartz to quartz2. A 
> file or ftp consumer should be single threaded while retrieving.



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

[jira] [Commented] (CAMEL-9737) Create camel component for ServiceNow


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

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

GitHub user lburgazzoli opened a pull request:

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

CAMEL-9737 : add an option to configure default resource to access



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

$ git pull https://github.com/lburgazzoli/apache-camel CAMEL-9737-fix

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

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


commit 8db5c3cc92822c9f95f68244a3581d38fe941c0a
Author: lburgazzoli 
Date:   2016-03-24T09:32:15Z

CAMEL-9737 : add an option to configure default resource to access




> Create camel component for ServiceNow
> -
>
> Key: CAMEL-9737
> URL: https://issues.apache.org/jira/browse/CAMEL-9737
> Project: Camel
>  Issue Type: New Feature
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>




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

[jira] [Commented] (CAMEL-9695) OSGi - During shutdown, Camel cannot unregister error handler

2016-03-24 Thread Martin Lichtin (JIRA)


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

Martin Lichtin commented on CAMEL-9695:
---

Thanks for the info. We will be ugprading Camel as soon as possible.

> OSGi - During shutdown, Camel cannot unregister error handler
> -
>
> Key: CAMEL-9695
> URL: https://issues.apache.org/jira/browse/CAMEL-9695
> Project: Camel
>  Issue Type: Bug
>  Components: karaf
>Affects Versions: 2.15.5
> Environment: Karaf 3.0.3
>Reporter: Martin Lichtin
>Priority: Minor
>
> According to http://camel.apache.org/redeliverypolicy.html
> my camel context is like
> {code:xml}
> http://camel.apache.org/schema/blueprint; 
> xsi:schemaLocation="http://camel.apache.org/schema/blueprint 
> http://camel.apache.org/schema/blueprint/camel-blueprint.xsd;
>   id="myIdxt" messageHistory="false">
>redeliveryPolicyRef="myRedeliveryPolicy" />
>   
>   
>   
>   
>   etc.etc.
>   
> 
> {code}
> During shutdown, the following is output:
> {noformat}
> 2016-03-10 12:33:44,649 | WARN  | FelixStartLevel  | 
> faultManagementLifecycleStrategy | faultManagementLifecycleStrategy  640 | 
> 130 - org.apache.camel.camel-core - 2.15.5 | Could not unregister error 
> handler: org.apache.camel.management.mbean.ManagedErrorHandler@72c1
> e7c3 as ErrorHandler MBean.
> org.apache.camel.NoSuchBeanException: No bean could be found in the registry 
> for: myErrorHandler of type: org.apache.camel.builder.ErrorHandlerBuilder
> at 
> org.apache.camel.util.CamelContextHelper.mandatoryLookup(CamelContextHelper.java:159)
> at 
> org.apache.camel.impl.DefaultRouteContext.mandatoryLookup(DefaultRouteContext.java:151)
> at 
> org.apache.camel.builder.ErrorHandlerBuilderRef.lookupErrorHandlerBuilder(ErrorHandlerBuilderRef.java:137)
> at 
> org.apache.camel.management.DefaultManagementNamingStrategy.getObjectNameForErrorHandler(DefaultManagementNamingStrategy.java:154)
> at 
> org.apache.camel.management.ManagedManagementStrategy.getManagedObjectName(ManagedManagementStrategy.java:104)
> at 
> org.apache.camel.management.ManagedManagementStrategy.unmanageObject(ManagedManagementStrategy.java:143)
> at 
> org.apache.camel.management.DefaultManagementLifecycleStrategy.unmanageObject(DefaultManagementLifecycleStrategy.java:839)
> at 
> org.apache.camel.management.DefaultManagementLifecycleStrategy.onErrorHandlerRemove(DefaultManagementLifecycleStrategy.java:638)
> at 
> org.apache.camel.impl.RouteService.stopChildService(RouteService.java:351)
> at org.apache.camel.impl.RouteService.doStop(RouteService.java:237)
> at 
> org.apache.camel.support.ChildServiceSupport.stop(ChildServiceSupport.java:77)
> at 
> org.apache.camel.support.ChildServiceSupport.stop(ChildServiceSupport.java:101)
> at 
> org.apache.camel.util.ServiceHelper.stopService(ServiceHelper.java:141)
> at 
> org.apache.camel.util.ServiceHelper.stopAndShutdownService(ServiceHelper.java:204)
> at 
> org.apache.camel.impl.DefaultCamelContext.shutdownServices(DefaultCamelContext.java:2843)
> at 
> org.apache.camel.impl.DefaultCamelContext.shutdownServices(DefaultCamelContext.java:2868)
> at 
> org.apache.camel.impl.DefaultCamelContext.shutdownServices(DefaultCamelContext.java:2856)
> at 
> org.apache.camel.impl.DefaultCamelContext.doStop(DefaultCamelContext.java:2691)
> at 
> org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
> at 
> org.apache.camel.blueprint.BlueprintCamelContext.destroy(BlueprintCamelContext.java:122)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)[:1.8.0_66]
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_66]
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497)[:1.8.0_66]
> at 
> org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[15:org.apache.aries.blueprint.core:1.4.2]
> at 
> org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)[15:org.apache.aries.blueprint.core:1.4.2]
> etc..
> {noformat}



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

[jira] [Resolved] (CAMEL-9746) Write documentation for camel-servicenow


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

Luca Burgazzoli resolved CAMEL-9746.

   Resolution: Fixed
Fix Version/s: 2.18.0

> Write documentation for camel-servicenow
> 
>
> Key: CAMEL-9746
> URL: https://issues.apache.org/jira/browse/CAMEL-9746
> Project: Camel
>  Issue Type: Sub-task
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
> Fix For: 2.18.0
>
>




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

[jira] [Updated] (CAMEL-9752) Quartz2 Scheduled route too many workers


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

Hans Orbaan updated CAMEL-9752:
---
 Flags: Patch
Patch Info: Patch Available

> Quartz2 Scheduled route too many workers
> 
>
> Key: CAMEL-9752
> URL: https://issues.apache.org/jira/browse/CAMEL-9752
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core, camel-quartz2
>Affects Versions: 2.16.2
> Environment: ALL
>Reporter: Hans Orbaan
>Priority: Critical
> Fix For: 2.16.3, 2.17.0
>
> Attachments: camel.patch, stacktrace.txt
>
>
> When any file:// or ftp:// consumer has a quartz2 schedule it can start 
> throwing exceptions because too many worker-threads are busy at the same time 
> (FileNotFoundException).
> Both workers can find the same files during filling the maxMessagesPerPoll, 
> or during processing of those files. This happens when the route can not 
> process all files before the next trigger happens.
> example (every minute):
> from(file:///mnt/sl-nl/bij/outbox/?sortBy=ignoreCase:file:name=#fileFilter=false=processed=failed=0+0/1+0-23+?+*+1,2,3,4,5,6,7=quartz2=nl_bij-export-to-archive-276)
> to(file:///data/work/sl/work-archive/work/276/)
> Attached you can find a stacktrace that would happen very often if worker1 
> processes and moves files that worker2 would also like to start processing.
> This does not happen when using scheduler=spring or when using delay=1m.
> The only way I have found to make sure a file or ftp component does not use 
> multiple threads while consuming very large batches is to annotate the 
> QuartzScheduledPollConsumerJob class with @DisallowConcurrentExecution.
> I am not familiar enough with the Camelcode to say what side effects it has 
> and if this would prevent any quartz job in camel to now be single threaded, 
> even if the user does not want it to be.
> But to me it looks like an oversight when moving from quartz to quartz2. A 
> file or ftp consumer should be single threaded while retrieving.



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

[jira] [Updated] (CAMEL-9752) Quartz2 Scheduled route too many workers


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

Hans Orbaan updated CAMEL-9752:
---
Attachment: camel.patch

> Quartz2 Scheduled route too many workers
> 
>
> Key: CAMEL-9752
> URL: https://issues.apache.org/jira/browse/CAMEL-9752
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core, camel-quartz2
>Affects Versions: 2.16.2
> Environment: ALL
>Reporter: Hans Orbaan
>Priority: Critical
> Fix For: 2.16.3, 2.17.0
>
> Attachments: camel.patch, stacktrace.txt
>
>
> When any file:// or ftp:// consumer has a quartz2 schedule it can start 
> throwing exceptions because too many worker-threads are busy at the same time 
> (FileNotFoundException).
> Both workers can find the same files during filling the maxMessagesPerPoll, 
> or during processing of those files. This happens when the route can not 
> process all files before the next trigger happens.
> example (every minute):
> from(file:///mnt/sl-nl/bij/outbox/?sortBy=ignoreCase:file:name=#fileFilter=false=processed=failed=0+0/1+0-23+?+*+1,2,3,4,5,6,7=quartz2=nl_bij-export-to-archive-276)
> to(file:///data/work/sl/work-archive/work/276/)
> Attached you can find a stacktrace that would happen very often if worker1 
> processes and moves files that worker2 would also like to start processing.
> This does not happen when using scheduler=spring or when using delay=1m.
> The only way I have found to make sure a file or ftp component does not use 
> multiple threads while consuming very large batches is to annotate the 
> QuartzScheduledPollConsumerJob class with @DisallowConcurrentExecution.
> I am not familiar enough with the Camelcode to say what side effects it has 
> and if this would prevent any quartz job in camel to now be single threaded, 
> even if the user does not want it to be.
> But to me it looks like an oversight when moving from quartz to quartz2. A 
> file or ftp consumer should be single threaded while retrieving.



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

[jira] [Updated] (CAMEL-9752) Quartz2 Scheduled route too many workers


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

Hans Orbaan updated CAMEL-9752:
---
Description: 
When any file:// or ftp:// consumer has a quartz2 schedule it can start 
throwing exceptions because too many worker-threads are busy at the same time 
(FileNotFoundException).
Both workers can find the same files during filling the maxMessagesPerPoll, or 
during processing of those files. This happens when the route can not process 
all files before the next trigger happens.

example (every minute):
from(file:///mnt/sl-nl/bij/outbox/?sortBy=ignoreCase:file:name=#fileFilter=false=processed=failed=0+0/1+0-23+?+*+1,2,3,4,5,6,7=quartz2=nl_bij-export-to-archive-276)
to(file:///data/work/sl/work-archive/work/276/)

Attached you can find a stacktrace that would happen very often if worker1 
processes and moves files that worker2 would also like to start processing.
This does not happen when using scheduler=spring or when using delay=1m.

The only way I have found to make sure a file or ftp component does not use 
multiple threads while consuming very large batches is to annotate the 
QuartzScheduledPollConsumerJob class with @DisallowConcurrentExecution.
I am not familiar enough with the Camelcode to say what side effects it has and 
if this would prevent any quartz job in camel to now be single threaded, even 
if the user does not want it to be.
But to me it looks like an oversight when moving from quartz to quartz2. A file 
or ftp consumer should be single threaded while retrieving.


  was:
When any file:// or ftp:// consumer has a quartz2 schedule it can start 
throwing exceptions because too many worker-threads are busy at the same time 
(FileNotFoundException).
Both workers can find the same files during filling the maxMessagesPerPoll, or 
during processing of those files. This happens when the route can not process 
all files before the next trigger happens.

example (every minute):
from(file:///mnt/sl-nl/bij/outbox/?sortBy=ignoreCase:file:name=#fileFilter=false=processed=failed=0+0/1+0-23+?+*+1,2,3,4,5,6,7=quartz2=nl_bij-export-to-archive-276)

Attached you can find a stacktrace that would happen very often if worker1 
processes and moves files that worker2 would also like to start processing.
This does not happen when using scheduler=spring or when using delay=1m.

The only way I have found to make sure a file or ftp component does not use 
multiple threads while consuming very large batches is to annotate the 
QuartzScheduledPollConsumerJob class with @DisallowConcurrentExecution.
I am not familiar enough with the Camelcode to say what side effects it has and 
if this would prevent any quartz job in camel to now be single threaded, even 
if the user does not want it to be.
But to me it looks like an oversight when moving from quartz to quartz2. A file 
or ftp consumer should be single threaded while retrieving.



> Quartz2 Scheduled route too many workers
> 
>
> Key: CAMEL-9752
> URL: https://issues.apache.org/jira/browse/CAMEL-9752
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core, camel-quartz2
>Affects Versions: 2.16.2
> Environment: ALL
>Reporter: Hans Orbaan
>Priority: Critical
> Fix For: 2.16.3, 2.17.0
>
> Attachments: stacktrace.txt
>
>
> When any file:// or ftp:// consumer has a quartz2 schedule it can start 
> throwing exceptions because too many worker-threads are busy at the same time 
> (FileNotFoundException).
> Both workers can find the same files during filling the maxMessagesPerPoll, 
> or during processing of those files. This happens when the route can not 
> process all files before the next trigger happens.
> example (every minute):
> from(file:///mnt/sl-nl/bij/outbox/?sortBy=ignoreCase:file:name=#fileFilter=false=processed=failed=0+0/1+0-23+?+*+1,2,3,4,5,6,7=quartz2=nl_bij-export-to-archive-276)
> to(file:///data/work/sl/work-archive/work/276/)
> Attached you can find a stacktrace that would happen very often if worker1 
> processes and moves files that worker2 would also like to start processing.
> This does not happen when using scheduler=spring or when using delay=1m.
> The only way I have found to make sure a file or ftp component does not use 
> multiple threads while consuming very large batches is to annotate the 
> QuartzScheduledPollConsumerJob class with @DisallowConcurrentExecution.
> I am not familiar enough with the Camelcode to say what side effects it has 
> and if this would prevent any quartz job in camel to now be single threaded, 
> even if the user does not want it to be.
> But to me it looks like an oversight when moving from quartz to quartz2. A 
> file or ftp consumer should be single threaded while retrieving.



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

[jira] [Updated] (CAMEL-9752) Quartz2 Scheduled route too many workers


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

Hans Orbaan updated CAMEL-9752:
---
Attachment: stacktrace.txt

> Quartz2 Scheduled route too many workers
> 
>
> Key: CAMEL-9752
> URL: https://issues.apache.org/jira/browse/CAMEL-9752
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core, camel-quartz2
>Affects Versions: 2.16.2
> Environment: ALL
>Reporter: Hans Orbaan
>Priority: Critical
> Fix For: 2.16.3, 2.17.0
>
> Attachments: stacktrace.txt
>
>
> When any file:// or ftp:// consumer has a quartz2 schedule it can start 
> throwing exceptions because too many worker-threads are busy at the same time 
> (FileNotFoundException).
> Both workers can find the same files during filling the maxMessagesPerPoll, 
> or during processing of those files. This happens when the route can not 
> process all files before the next trigger happens.
> example (every minute):
> from(file:///mnt/sl-nl/bij/outbox/?sortBy=ignoreCase:file:name=#fileFilter=false=processed=failed=0+0/1+0-23+?+*+1,2,3,4,5,6,7=quartz2=nl_bij-export-to-archive-276)
> Attached you can find a stacktrace that would happen very often if worker1 
> processes and moves files that worker2 would also like to start processing.
> This does not happen when using scheduler=spring or when using delay=1m.
> The only way I have found to make sure a file or ftp component does not use 
> multiple threads while consuming very large batches is to annotate the 
> QuartzScheduledPollConsumerJob class with @DisallowConcurrentExecution.
> I am not familiar enough with the Camelcode to say what side effects it has 
> and if this would prevent any quartz job in camel to now be single threaded, 
> even if the user does not want it to be.
> But to me it looks like an oversight when moving from quartz to quartz2. A 
> file or ftp consumer should be single threaded while retrieving.



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

[jira] [Created] (CAMEL-9752) Quartz2 Scheduled route too many workers

Hans Orbaan created CAMEL-9752:
--

Summary: Quartz2 Scheduled route too many workers
Key: CAMEL-9752
URL: https://issues.apache.org/jira/browse/CAMEL-9752
Project: Camel
Issue Type: Bug
Components: camel-core, camel-quartz2
Affects Versions: 2.16.2
Environment: ALL
Reporter: Hans Orbaan
Priority: Critical
Fix For: 2.16.3, 2.17.0

When any file:// or ftp:// consumer has a quartz2 schedule it can start
throwing exceptions because too many worker-threads are busy at the same time
(FileNotFoundException).
Both workers can find the same files during filling the maxMessagesPerPoll, or
during processing of those files. This happens when the route can not process
all files before the next trigger happens.

example (every minute):
from(file:///mnt/sl-nl/bij/outbox/?sortBy=ignoreCase:file:name=#fileFilter=false=processed=failed=0+0/1+0-23+?+*+1,2,3,4,5,6,7=quartz2=nl_bij-export-to-archive-276)

Attached you can find a stacktrace that would happen very often if worker1
processes and moves files that worker2 would also like to start processing.
This does not happen when using scheduler=spring or when using delay=1m.

The only way I have found to make sure a file or ftp component does not use
multiple threads while consuming very large batches is to annotate the
QuartzScheduledPollConsumerJob class with @DisallowConcurrentExecution.
I am not familiar enough with the Camelcode to say what side effects it has and
if this would prevent any quartz job in camel to now be single threaded, even
if the user does not want it to be.
But to me it looks like an oversight when moving from quartz to quartz2. A file
or ftp consumer should be single threaded while retrieving.

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

[jira] [Updated] (CAMEL-9751) Add support for security requirements to swagger java component


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

Claus Ibsen updated CAMEL-9751:
---
Fix Version/s: 2.18.0

> Add support for security requirements to swagger java component
> ---
>
> Key: CAMEL-9751
> URL: https://issues.apache.org/jira/browse/CAMEL-9751
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-swagger
>Reporter: Tim Dudgeon
> Fix For: 2.18.0
>
>
> Swagger Java component does not currently allow security requirements to be 
> specified. Would be useful to be able to do so.
> But as security is usually applied at the container level its not clear what 
> the best approach would be. 



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

[jira] [Commented] (CAMEL-9751) Add support for security requirements to swagger java component


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

Claus Ibsen commented on CAMEL-9751:


This is only about documenting the security requirements. How they are actually 
enforced/implemented is depending on which http component you use and how its 
to be configured or other means of security from 3rd party, such as api 
gateways like http://www.apiman.io/

> Add support for security requirements to swagger java component
> ---
>
> Key: CAMEL-9751
> URL: https://issues.apache.org/jira/browse/CAMEL-9751
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-swagger
>Reporter: Tim Dudgeon
> Fix For: 2.18.0
>
>
> Swagger Java component does not currently allow security requirements to be 
> specified. Would be useful to be able to do so.
> But as security is usually applied at the container level its not clear what 
> the best approach would be. 



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

[jira] [Created] (CAMEL-9751) Add support for security requirements to swagger java component

2016-03-24 Thread Tim Dudgeon (JIRA)

Tim Dudgeon created CAMEL-9751:
--

 Summary: Add support for security requirements to swagger java 
component
 Key: CAMEL-9751
 URL: https://issues.apache.org/jira/browse/CAMEL-9751
 Project: Camel
  Issue Type: New Feature
  Components: camel-swagger
Reporter: Tim Dudgeon


Swagger Java component does not currently allow security requirements to be 
specified. Would be useful to be able to do so.
But as security is usually applied at the container level its not clear what 
the best approach would be. 



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

[jira] [Commented] (CAMEL-9750) Tests should not log on stdout by default


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

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

GitHub user lburgazzoli opened a pull request:

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

CAMEL-9750 : Tests should not log on stdout by default



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

$ git pull https://github.com/lburgazzoli/apache-camel CAMEL-9750

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

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


commit 44c426f36b19b98bbc9cb3164bdf8a35264d0c26
Author: lburgazzoli 
Date:   2016-03-24T07:05:34Z

CAMEL-9750 : Tests should not log on stdout by default




> Tests should not log on stdout by default
> -
>
> Key: CAMEL-9750
> URL: https://issues.apache.org/jira/browse/CAMEL-9750
> Project: Camel
>  Issue Type: Task
>  Components: camel-etcd
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Minor
>




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

[jira] [Work started] (CAMEL-9750) Tests should not log on stdout by default


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

Work on CAMEL-9750 started by Luca Burgazzoli.
--
> Tests should not log on stdout by default
> -
>
> Key: CAMEL-9750
> URL: https://issues.apache.org/jira/browse/CAMEL-9750
> Project: Camel
>  Issue Type: Task
>  Components: camel-etcd
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Minor
>




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

[jira] [Created] (CAMEL-9750) Tests should not log on stdout by default