[jira] [Commented] (CAMEL-12711) SFTP: Cannot specify bind address of local network interface

2018-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CAMEL-12711:


onderson commented on a change in pull request #2452: [CAMEL-12711] Add 
configuration property 'bindAddress' for SFTP
URL: https://github.com/apache/camel/pull/2452#discussion_r208103667
 
 

 ##
 File path: 
components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/SftpOperations.java
 ##
 @@ -1074,4 +1099,64 @@ public synchronized boolean sendSiteCommand(String 
command) throws GenericFileOp
 // is not implemented
 return true;
 }
+
+/*
+ * adapted from com.jcraft.jsch.Util.createSocket(String, int, int)
+ *
+ * added possibility to specify the address of the local network 
interface, against the
+ * connection should bind
+ */
+static Socket createSocketUtil(final String host, final int port, final 
String bindAddress, final int timeout) {
+Socket socket = null;
+if (timeout == 0) {
+try {
+socket = new Socket(InetAddress.getByName(host), port, 
InetAddress.getByName(bindAddress), 0);
+return socket;
+} catch (Exception e) {
+String message = e.toString();
+if (e instanceof Throwable) {
+throw new RuntimeCamelException(message, (Throwable)e);
+}
+throw new RuntimeCamelException(message);
+}
+}
+final Socket[] sockp = new Socket[1];
+final Exception[] ee = new Exception[1];
+String message = "";
+Thread tmp = new Thread(new Runnable() {
+public void run() {
+sockp[0] = null;
+try {
+sockp[0] = new Socket(InetAddress.getByName(host), port, 
InetAddress.getByName(bindAddress), 0);
+} catch (Exception e) {
+ee[0] = e;
+if (sockp[0] != null && sockp[0].isConnected()) {
+try {
+sockp[0].close();
+} catch (Exception eee) { }
+}
+sockp[0] = null;
+}
+}
+});
+tmp.setName("Opening Socket " + host);
+tmp.start();
+try {
+tmp.join(timeout);
+message = "timeout: ";
+} catch (java.lang.InterruptedException eee) {
+}
 
 Review comment:
   Can we at least add here a debug log?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> SFTP: Cannot specify bind address of local network interface
> 
>
> Key: CAMEL-12711
> URL: https://issues.apache.org/jira/browse/CAMEL-12711
> Project: Camel
>  Issue Type: Bug
>  Components: camel-ftp
>Affects Versions: 2.22.0
>Reporter: Felix Feisst
>Priority: Major
>
> In an environment with multiple network interfaces, it might be necessary to 
> specify the address of the local interface, to which the SFTP connection 
> should bind. Unfortunately, this is not possible with the latest version of 
> camel-ftp.
>  
> A new URI parameter 'bindAddress' should be introduces which can then be set 
> to the IP-Address of the local network interface against which the SFTP 
> connection should bind.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12711) SFTP: Cannot specify bind address of local network interface

2018-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CAMEL-12711:


onderson commented on issue #2452: [CAMEL-12711] Add configuration property 
'bindAddress' for SFTP
URL: https://github.com/apache/camel/pull/2452#issuecomment-410938548
 
 
   maybe you can write a Unit test against your environment and mark those test 
case(s) `@Ignored`. (Of course, when you commit, please mask your ip addresses) 
If it is hard to unit test and we can not use any mocking mechanism, that's 
what we can usually do. if it is more complicated, you can leave it as is i 
suppose (in code terms, AFAIU this now looks like a new option without any 
effect on existing users.)


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> SFTP: Cannot specify bind address of local network interface
> 
>
> Key: CAMEL-12711
> URL: https://issues.apache.org/jira/browse/CAMEL-12711
> Project: Camel
>  Issue Type: Bug
>  Components: camel-ftp
>Affects Versions: 2.22.0
>Reporter: Felix Feisst
>Priority: Major
>
> In an environment with multiple network interfaces, it might be necessary to 
> specify the address of the local interface, to which the SFTP connection 
> should bind. Unfortunately, this is not possible with the latest version of 
> camel-ftp.
>  
> A new URI parameter 'bindAddress' should be introduces which can then be set 
> to the IP-Address of the local network interface against which the SFTP 
> connection should bind.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12711) SFTP: Cannot specify bind address of local network interface

2018-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CAMEL-12711:


ffeisst commented on issue #2452: [CAMEL-12711] Add configuration property 
'bindAddress' for SFTP
URL: https://github.com/apache/camel/pull/2452#issuecomment-410856405
 
 
   @davsclaus I have copied the code from jsch.Util.createSocket(..). The 
comment on the method does also link to the original method. I've done this, to 
stay as close as possible to the original Socket creation implementation (the 
original implementation uses Util.createSocket).
   
   @onderson The null check to activate the new behavior only in case of a bind 
address sounds like a good idea to me. I've changed the commit accordingly. I 
also like the idea of a test case and already thought about it, but I dont know 
how I can setup an environment with multiple interfaces to test the bind 
address behavior in an unit test. Do you know how this can easily be done in an 
unit test? I've tested the implementation in a real world setup with multiple 
interfaces and it is working as expected.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> SFTP: Cannot specify bind address of local network interface
> 
>
> Key: CAMEL-12711
> URL: https://issues.apache.org/jira/browse/CAMEL-12711
> Project: Camel
>  Issue Type: Bug
>  Components: camel-ftp
>Affects Versions: 2.22.0
>Reporter: Felix Feisst
>Priority: Major
>
> In an environment with multiple network interfaces, it might be necessary to 
> specify the address of the local interface, to which the SFTP connection 
> should bind. Unfortunately, this is not possible with the latest version of 
> camel-ftp.
>  
> A new URI parameter 'bindAddress' should be introduces which can then be set 
> to the IP-Address of the local network interface against which the SFTP 
> connection should bind.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (CAMEL-12694) camel-itest-spring-boot : improve to run tests behind proxy

2018-08-06 Thread JIRA


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

Önder Sezgin updated CAMEL-12694:
-
Description: As mentioned 
[here|https://github.com/apache/camel/pull/2434#issuecomment-408092655], itest 
may need to be improved ro run behind proxy  (was: As mentioned 
here[|https://github.com/nicolaferraro], itest may need to be improved ro run 
behind proxy)

> camel-itest-spring-boot : improve to run tests behind proxy
> ---
>
> Key: CAMEL-12694
> URL: https://issues.apache.org/jira/browse/CAMEL-12694
> Project: Camel
>  Issue Type: Improvement
>Reporter: Önder Sezgin
>Priority: Minor
> Fix For: Future
>
>
> As mentioned 
> [here|https://github.com/apache/camel/pull/2434#issuecomment-408092655], 
> itest may need to be improved ro run behind proxy



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (CAMEL-11886) Post guide on how to contribute to documentation updates

2018-08-06 Thread JIRA


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

Önder Sezgin updated CAMEL-11886:
-
Estimated Complexity: Novice  (was: Unknown)

> Post guide on how to contribute to documentation updates
> 
>
> Key: CAMEL-11886
> URL: https://issues.apache.org/jira/browse/CAMEL-11886
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Claus Ibsen
>Assignee: Önder Sezgin
>Priority: Major
> Fix For: 2.23.0
>
>
> As we migrate from wiki to adoc files we should have a better guide on how to 
> update or contribute to the documentation.
> Also we should post a news on the Camel front page about this, so users can 
> better know the state of the docs - as the old wiki is toasted and unfixable 
> at this moment.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (CAMEL-11886) Post guide on how to contribute to documentation updates

2018-08-06 Thread JIRA


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

Önder Sezgin reassigned CAMEL-11886:


Assignee: (was: Önder Sezgin)

> Post guide on how to contribute to documentation updates
> 
>
> Key: CAMEL-11886
> URL: https://issues.apache.org/jira/browse/CAMEL-11886
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: 2.23.0
>
>
> As we migrate from wiki to adoc files we should have a better guide on how to 
> update or contribute to the documentation.
> Also we should post a news on the Camel front page about this, so users can 
> better know the state of the docs - as the old wiki is toasted and unfixable 
> at this moment.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (CAMEL-6840) Allow Throttler EIP to specify SLA per client/correlated-group

2018-08-06 Thread JIRA


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

Önder Sezgin resolved CAMEL-6840.
-
Resolution: Implemented

> Allow Throttler EIP to specify SLA per client/correlated-group
> --
>
> Key: CAMEL-6840
> URL: https://issues.apache.org/jira/browse/CAMEL-6840
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Reporter: Christian Posta
>Assignee: Önder Sezgin
>Priority: Major
> Fix For: 2.23.0
>
>
> Basic idea is to allow throttler to have a predicate to determine whether or 
> not to apply throttling to that exchange. 
> From this Mailing List discussion:
> http://camel.465427.n5.nabble.com/Throttling-by-client-ID-td5741032.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12709) UseOriginalAggregationStrategy in outer loops

2018-08-06 Thread Matthias Humbert (JIRA)


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

Matthias Humbert commented on CAMEL-12709:
--

Guten Tag

Ich bin am 20. August wieder im Büro.

Freundliche Grüsse
Matthias Humbert


> UseOriginalAggregationStrategy in outer loops
> -
>
> Key: CAMEL-12709
> URL: https://issues.apache.org/jira/browse/CAMEL-12709
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.21.2
>Reporter: Matthias Humbert
>Priority: Major
>
> Using splitters with the UseOriginalAggregationStrategy +in a loop+ causes 
> the splitter to return always the same original exchange.
>  
> {code:java}
> // my code is similar to the following one:
> from("direct:myLoop")
>   .loop(simple("{{export.maxLoopsPerRun}}"))
> .setHeader(...) // changing header fields
> .split(body(), new UseOriginalAggregationStrategy(null, false))
>   .to("direct:handleRecord")
> .end()
> .log("${in.headers}") // the headers of the exchange of the very first 
> loop iteration
>   .end()
> {code}
> Reason: Once the original exchange is set by 
> UseOriginalAggregationStrategy#setOriginal(Exchange), it is not updated any 
> more for loop iterations > 1.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12709) UseOriginalAggregationStrategy in outer loops

2018-08-06 Thread JIRA


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

Önder Sezgin commented on CAMEL-12709:
--

i think this is on purpose. what loop-eip and split-eip with 
UseOriginalAggregationStrategy do it is right with the route definition you 
have given. i think this is not a bug, this is your routing design issue.

> UseOriginalAggregationStrategy in outer loops
> -
>
> Key: CAMEL-12709
> URL: https://issues.apache.org/jira/browse/CAMEL-12709
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.21.2
>Reporter: Matthias Humbert
>Priority: Major
>
> Using splitters with the UseOriginalAggregationStrategy +in a loop+ causes 
> the splitter to return always the same original exchange.
>  
> {code:java}
> // my code is similar to the following one:
> from("direct:myLoop")
>   .loop(simple("{{export.maxLoopsPerRun}}"))
> .setHeader(...) // changing header fields
> .split(body(), new UseOriginalAggregationStrategy(null, false))
>   .to("direct:handleRecord")
> .end()
> .log("${in.headers}") // the headers of the exchange of the very first 
> loop iteration
>   .end()
> {code}
> Reason: Once the original exchange is set by 
> UseOriginalAggregationStrategy#setOriginal(Exchange), it is not updated any 
> more for loop iterations > 1.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12515) the camel splitter loses attachments

2018-08-06 Thread JIRA


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

Önder Sezgin commented on CAMEL-12515:
--

[~ronny.aerts.intris], it is not clear what you are trying to do. if the camel 
exchange body is and iterable object and if you split the body using iterator, 
split is OOB. i am not quite sure what you mean. could you give an example? or 
am i missing something?

> the camel splitter loses attachments
> 
>
> Key: CAMEL-12515
> URL: https://issues.apache.org/jira/browse/CAMEL-12515
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core-xml
>Affects Versions: 2.20.3
> Environment: I use camel 2.20.3 in xml not java. 
>Reporter: Ronny Aerts
>Priority: Minor
>
> * I have a process which uses at lot of attachments (coming in from a mail) 
> and I have to filter on several of them.
>  * I created a javascript to loop over the attachments and use the attachment 
> id in combination with a regex to determine if the attachment is applicable. 
> Several of these attachments can be applicable. I keep an ArrayList of 
> applicable attachments which I put in the body. 
>  * I split on the (arraylist) body to handle the individual attachments one 
> by one but this doesn't work because there are no attachments anymore inside 
> the split. 
>  * It would be very helpful to me if I could use the attachments inside the 
> split. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (CAMEL-12549) Upgrade to Groovy 2.5

2018-08-06 Thread JIRA


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

Önder Sezgin reassigned CAMEL-12549:


Assignee: Önder Sezgin

> Upgrade to Groovy 2.5
> -
>
> Key: CAMEL-12549
> URL: https://issues.apache.org/jira/browse/CAMEL-12549
> Project: Camel
>  Issue Type: Task
>  Components: camel-groovy
>Reporter: Claus Ibsen
>Assignee: Önder Sezgin
>Priority: Minor
> Fix For: 2.23.0
>
>
> Groovy 2.5 was just released.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (CAMEL-12700) Checkstyle issues in camel-core

2018-08-06 Thread JIRA


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

Önder Sezgin resolved CAMEL-12700.
--
Resolution: Not A Problem
  Assignee: Önder Sezgin

no checkstyle error.

> Checkstyle issues in camel-core
> ---
>
> Key: CAMEL-12700
> URL: https://issues.apache.org/jira/browse/CAMEL-12700
> Project: Camel
>  Issue Type: Task
>  Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Önder Sezgin
>Priority: Major
> Fix For: 2.23.0
>
>
> We got some errors reported
> {code}
> [INFO] --- maven-checkstyle-plugin:3.0.0:checkstyle (default-cli) @ 
> camel-core ---
> [INFO] Starting audit...
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/test/java/org/apache/camel/util/GroupTokenIteratorTest.java:22:1:
>  Redundant import from the same package - org.apache.camel.util.Scanner. 
> [RedundantImport]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/test/java/org/apache/camel/util/GroupTokenIteratorTest.java:24:
>  Wrong order for 'org.apache.camel.CamelContext' import. [ImportOrder]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/impl/FileStateRepository.java:25:
>  Wrong order for 'java.util.concurrent.atomic.AtomicBoolean' import. 
> [ImportOrder]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/converter/jaxp/XmlConverter.java:95:39:
>  Name 'domLoggingErrorHandler' must match pattern 
> '^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$'. [ConstantName]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/util/SkipIterator.java:22:1:
>  Redundant import from the same package - org.apache.camel.util.Scanner. 
> [RedundantImport]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/util/SkipIterator.java:23:
>  Wrong order for 'java.util.concurrent.atomic.AtomicBoolean' import. 
> [ImportOrder]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/util/Scanner.java:58:21:
>  Variable 'inputExhausted' explicitly initialized to 'false' (default value 
> for its type). [ExplicitInitialization]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/util/Scanner.java:59:21:
>  Variable 'needInput' explicitly initialized to 'false' (default value for 
> its type). [ExplicitInitialization]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/util/Scanner.java:60:21:
>  Variable 'skipped' explicitly initialized to 'false' (default value for its 
> type). [ExplicitInitialization]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/util/Scanner.java:62:21:
>  Variable 'closed' explicitly initialized to 'false' (default value for its 
> type). [ExplicitInitialization]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/util/Scanner.java:197:14:
>  Unnecessary parentheses around identifier 'inputExhausted'. 
> [UnnecessaryParentheses]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/util/IntrospectionSupport.java:136:22:
>  Name 'CACHE' must match pattern '^[a-z][a-zA-Z0-9]*$'. [LocalVariableName]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/util/GroupTokenIterator.java:24:1:
>  Redundant import from the same package - org.apache.camel.util.Scanner. 
> [RedundantImport]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/util/GroupTokenIterator.java:25:
>  Wrong order for 'java.util.concurrent.atomic.AtomicBoolean' import. 
> [ImportOrder]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/processor/idempotent/FileIdempotentRepository.java:26:
>  Wrong order for 'java.util.concurrent.atomic.AtomicBoolean' import. 
> [ImportOrder]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/processor/Splitter.java:27:
>  Wrong order for 'java.util.concurrent.ExecutorService' import. [ImportOrder]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/support/TokenPairExpressionIterator.java:25:
>  Wrong order for 'org.apache.camel.Exchange' import. [ImportOrder]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/support/TokenXMLPairExpressionIterator.java:24:
>  Wrong order for 'java.util.regex.Matcher' import. [ImportOrder]
> [ERROR] 
> /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/builder/ExpressionBuilder.java:31:
>  Wrong order for 'java.util.Set' import. [ImportOrder]
> Audit done.
> [INFO] There are 19 errors reported by Checkstyle 7.6.1 with 
> camel-checkstyle.xml ruleset.
> 

[jira] [Resolved] (CAMEL-11151) Double release of netty buffer

2018-08-06 Thread Claus Ibsen (JIRA)


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

Claus Ibsen resolved CAMEL-11151.
-
Resolution: Later

Its more than a year ago and this is harder to reproduce. Try with latest 
version and reopen or create a new ticket if anybody see similar issue again.

> Double release of netty buffer
> --
>
> Key: CAMEL-11151
> URL: https://issues.apache.org/jira/browse/CAMEL-11151
> Project: Camel
>  Issue Type: Bug
>  Components: camel-netty4-http
>Affects Versions: 2.18.3
>Reporter: Valentin Tsvetkov
>Priority: Major
>
> I try to make simple proxy application with netty4-http component to transfer 
> http request with large content.
> Example
> 
> from(String.format("netty4-http:http://0.0.0.0:%d?httpMethodRestrict=GET,HEAD,POST,PUT,DELETE,TRACE,OPTIONS,CONNECT,PATCH=1=true;,
>  8081))
> 
> .toD("netty4-http:http://somehost:8080/?bridgeEndpoint=true=false=true;).end();
> So if i use =true option then i get 
> [Camel Thread #3 - NettyClientTCPWorker] WARN 
> io.netty.util.concurrent.DefaultPromise - An exception was thrown by 
> org.apache.camel.component.netty4.NettyProducer$ChannelConnectedListener.operationComplete()
> io.netty.util.IllegalReferenceCountException: refCnt: 0, decrement: 1
>   at 
> io.netty.buffer.AbstractReferenceCountedByteBuf.release0(AbstractReferenceCountedByteBuf.java:101)
>   at 
> io.netty.buffer.AbstractReferenceCountedByteBuf.release(AbstractReferenceCountedByteBuf.java:89)
>   at 
> io.netty.handler.codec.http.DefaultFullHttpRequest.release(DefaultFullHttpRequest.java:102)
>   at io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:84)
> If i does not use  =true, all works fine. But for large 
> content i get heap space error.
> There are several resolved bugs in camel and netty4 that seems to be related
> https://issues.apache.org/jira/browse/CAMEL-10409
> and https://issues.apache.org/jira/browse/CAMEL-7638



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (CAMEL-12264) Concurrent modification in safeCopyProperties Method of DefaultExchange

2018-08-06 Thread Claus Ibsen (JIRA)


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

Claus Ibsen resolved CAMEL-12264.
-
Resolution: Cannot Reproduce

> Concurrent modification in safeCopyProperties Method of DefaultExchange
> ---
>
> Key: CAMEL-12264
> URL: https://issues.apache.org/jira/browse/CAMEL-12264
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.20.2
>Reporter: Yifan Wu
>Priority: Minor
>
> {color:#ffc66d}{color:#33}safeCopyProperties method  of DefaultExchange 
> class,{color} {color}
> {code:java}
> // new LinkedList<>(Collection c) is not thread-safe.
> answer.put(Exchange.MESSAGE_HISTORY, new LinkedList<>(history));
> {code}
>  new LinkedList<>(Collection c) is not thread-safe. Quote from LinkedList 
> implementation "The behavior of this operation is undefined if{color:#629755} 
> the specified collection is modified while the operation is 
> in{color}{color:#629755} progress."{color}
>  
>  {color:#33}In our case, when we have high throughput, we see the 
> following exception (when the history is concurrently being modified.):{color}
> {color:#33}java.lang.ArrayIndexOutOfBoundsException: 19
>      at java.util.LinkedList.toArray(LinkedList.java:1053)
>      at java.util.LinkedList.addAll(LinkedList.java:408)
>      at java.util.LinkedList.addAll(LinkedList.java:387)
>      at java.util.LinkedList.(LinkedList.java:119)
>      at 
> org.apache.camel.impl.DefaultExchange.safeCopyProperties(DefaultExchange.java:152)
>      at 
> org.apache.camel.impl.DefaultExchange.copy(DefaultExchange.java:97)
>      at 
> org.apache.camel.util.ExchangeHelper.createCorrelatedCopy(ExchangeHelper.java:235)
>      at 
> org.apache.camel.util.ExchangeHelper.createCorrelatedCopy(ExchangeHelper.java:218)
>      at 
> org.apache.camel.processor.OnCompletionProcessor.prepareExchange(OnCompletionProcessor.java:190)
>      at 
> org.apache.camel.processor.OnCompletionProcessor$OnCompletionSynchronizationAfterConsumer.onComplete(OnCompletionProcessor.java:235)
>      at 
> org.apache.camel.util.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:104)
>      at 
> org.apache.camel.impl.DefaultUnitOfWork.done(DefaultUnitOfWork.java:229)
>      at 
> org.apache.camel.util.UnitOfWorkHelper.doneUow(UnitOfWorkHelper.java:65){color}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (CAMEL-12565) outputTypeWithValidate (or inputTypeWithValidate) + validator()... doesn't work as expected

2018-08-06 Thread Claus Ibsen (JIRA)


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

Claus Ibsen resolved CAMEL-12565.
-
   Resolution: Fixed
Fix Version/s: 2.22.1
   2.21.3

Thanks for the unit test its been added to the source code and also a input 
validation variation.

> outputTypeWithValidate (or inputTypeWithValidate) + validator()... doesn't 
> work as expected
> ---
>
> Key: CAMEL-12565
> URL: https://issues.apache.org/jira/browse/CAMEL-12565
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.21.1
> Environment: Tested on camel 2.21.1, Java 8, Win
>Reporter: Michael Dzuba
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 2.21.3, 2.22.1, 2.23.0
>
>
> {code:java}
> package org.mike.tests;
> import org.apache.camel.ValidationException;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.junit.Test;
> public class ValidatorTests extends CamelTestSupport {
> @Override
> protected RouteBuilder createRouteBuilder() throws Exception {
> return new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> validator()
> .type(String.class)
> 
> .withExpression(bodyAs(String.class).isEqualToIgnoreCase("valid"));
> onException(ValidationException.class)
> .handled(true)
> .log("Invalid predicate: ${exception.message}")
> .to("mock:invalid");
> from("direct:in")
> 
> //.validate(bodyAs(String.class).isEqualToIgnoreCase("valid"))
> .outputTypeWithValidate(String.class) // or 
> .inputTypeWithValidate(String.class)
> .to("mock:out");
> }
> };
> }
> @Test
> public void testValid() throws InterruptedException {
> getMockEndpoint("mock:out").expectedMessageCount(1);
> getMockEndpoint("mock:invalid").expectedMessageCount(0);
> template.sendBody("direct:in", "valid");
> assertMockEndpointsSatisfied();
> }
> @Test
> public void testInvalid() throws InterruptedException {
> getMockEndpoint("mock:out").expectedMessageCount(0);
> getMockEndpoint("mock:invalid").expectedMessageCount(1);
> template.sendBody("direct:in", "wrong");
> assertMockEndpointsSatisfied();
> }
> }
> {code}
> Expected result: both tests pass
> Actual result: 'testValid' - passed, 'testInvalid' - failed
> If uncomment line 25 & comment 26
> {code:java}
> .validate(bodyAs(String.class).isEqualToIgnoreCase("valid"))
> //.inputTypeWithValidate(String.class)
> {code}
> tests will OK
>  
> Other test case with same results
>  
> {code:java}
> package org.mike.tests;
> import org.apache.camel.Message;
> import org.apache.camel.ValidationException;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.impl.JndiRegistry;
> import org.apache.camel.spi.DataType;
> import org.apache.camel.spi.Validator;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.junit.Test;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> public class BeanValidatorTest extends CamelTestSupport {
> @Override
> protected RouteBuilder createRouteBuilder() throws Exception {
> return new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> validator()
> .type("toValidate")
> .withBean("testValidator");
> onException(ValidationException.class)
> .handled(true)
> .log("Invalid validation: ${exception.message}")
> .to("mock:invalid");
> from("direct:in")
> .outputTypeWithValidate("toValidate")
> .to("mock:out");
> }
> };
> }
> public static class TestValidator extends Validator {
> private static final Logger LOG = 
> LoggerFactory.getLogger(TestValidator.class);
> @Override
> public void validate(Message message, DataType type) throws 
> ValidationException {
> Object body = message.getBody();
> LOG.info("Validating : [{}]", body);
> if (body instanceof String && body.equals("valid")) {
> LOG.info("OK");
> } else {
> throw new ValidationException(message.getExchange(), "Wrong 
> content");
> }
> }
> }
> 

[jira] [Commented] (CAMEL-12711) SFTP: Cannot specify bind address of local network interface

2018-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CAMEL-12711:


davsclaus commented on issue #2452: [CAMEL-12711] Add configuration property 
'bindAddress' for SFTP
URL: https://github.com/apache/camel/pull/2452#issuecomment-410790167
 
 
   Thanks for the PR. Is the code where you create a new `Thread` and so some 
socket validation some code you have seen/copied from JCraft or how do you come 
up with that?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> SFTP: Cannot specify bind address of local network interface
> 
>
> Key: CAMEL-12711
> URL: https://issues.apache.org/jira/browse/CAMEL-12711
> Project: Camel
>  Issue Type: Bug
>  Components: camel-ftp
>Affects Versions: 2.22.0
>Reporter: Felix Feisst
>Priority: Major
>
> In an environment with multiple network interfaces, it might be necessary to 
> specify the address of the local interface, to which the SFTP connection 
> should bind. Unfortunately, this is not possible with the latest version of 
> camel-ftp.
>  
> A new URI parameter 'bindAddress' should be introduces which can then be set 
> to the IP-Address of the local network interface against which the SFTP 
> connection should bind.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12565) outputTypeWithValidate (or inputTypeWithValidate) + validator()... doesn't work as expected

2018-08-06 Thread Claus Ibsen (JIRA)


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

Claus Ibsen commented on CAMEL-12565:
-

However there was a little bug in the validator somewhere else which I have 
fixed.

> outputTypeWithValidate (or inputTypeWithValidate) + validator()... doesn't 
> work as expected
> ---
>
> Key: CAMEL-12565
> URL: https://issues.apache.org/jira/browse/CAMEL-12565
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.21.1
> Environment: Tested on camel 2.21.1, Java 8, Win
>Reporter: Michael Dzuba
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 2.23.0
>
>
> {code:java}
> package org.mike.tests;
> import org.apache.camel.ValidationException;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.junit.Test;
> public class ValidatorTests extends CamelTestSupport {
> @Override
> protected RouteBuilder createRouteBuilder() throws Exception {
> return new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> validator()
> .type(String.class)
> 
> .withExpression(bodyAs(String.class).isEqualToIgnoreCase("valid"));
> onException(ValidationException.class)
> .handled(true)
> .log("Invalid predicate: ${exception.message}")
> .to("mock:invalid");
> from("direct:in")
> 
> //.validate(bodyAs(String.class).isEqualToIgnoreCase("valid"))
> .outputTypeWithValidate(String.class) // or 
> .inputTypeWithValidate(String.class)
> .to("mock:out");
> }
> };
> }
> @Test
> public void testValid() throws InterruptedException {
> getMockEndpoint("mock:out").expectedMessageCount(1);
> getMockEndpoint("mock:invalid").expectedMessageCount(0);
> template.sendBody("direct:in", "valid");
> assertMockEndpointsSatisfied();
> }
> @Test
> public void testInvalid() throws InterruptedException {
> getMockEndpoint("mock:out").expectedMessageCount(0);
> getMockEndpoint("mock:invalid").expectedMessageCount(1);
> template.sendBody("direct:in", "wrong");
> assertMockEndpointsSatisfied();
> }
> }
> {code}
> Expected result: both tests pass
> Actual result: 'testValid' - passed, 'testInvalid' - failed
> If uncomment line 25 & comment 26
> {code:java}
> .validate(bodyAs(String.class).isEqualToIgnoreCase("valid"))
> //.inputTypeWithValidate(String.class)
> {code}
> tests will OK
>  
> Other test case with same results
>  
> {code:java}
> package org.mike.tests;
> import org.apache.camel.Message;
> import org.apache.camel.ValidationException;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.impl.JndiRegistry;
> import org.apache.camel.spi.DataType;
> import org.apache.camel.spi.Validator;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.junit.Test;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> public class BeanValidatorTest extends CamelTestSupport {
> @Override
> protected RouteBuilder createRouteBuilder() throws Exception {
> return new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> validator()
> .type("toValidate")
> .withBean("testValidator");
> onException(ValidationException.class)
> .handled(true)
> .log("Invalid validation: ${exception.message}")
> .to("mock:invalid");
> from("direct:in")
> .outputTypeWithValidate("toValidate")
> .to("mock:out");
> }
> };
> }
> public static class TestValidator extends Validator {
> private static final Logger LOG = 
> LoggerFactory.getLogger(TestValidator.class);
> @Override
> public void validate(Message message, DataType type) throws 
> ValidationException {
> Object body = message.getBody();
> LOG.info("Validating : [{}]", body);
> if (body instanceof String && body.equals("valid")) {
> LOG.info("OK");
> } else {
> throw new ValidationException(message.getExchange(), "Wrong 
> content");
> }
> }
> }
> @Override
> protected JndiRegistry createRegistry() throws Exception {
> 

[jira] [Assigned] (CAMEL-12565) outputTypeWithValidate (or inputTypeWithValidate) + validator()... doesn't work as expected

2018-08-06 Thread Claus Ibsen (JIRA)


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

Claus Ibsen reassigned CAMEL-12565:
---

Assignee: Claus Ibsen

> outputTypeWithValidate (or inputTypeWithValidate) + validator()... doesn't 
> work as expected
> ---
>
> Key: CAMEL-12565
> URL: https://issues.apache.org/jira/browse/CAMEL-12565
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.21.1
> Environment: Tested on camel 2.21.1, Java 8, Win
>Reporter: Michael Dzuba
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 2.23.0
>
>
> {code:java}
> package org.mike.tests;
> import org.apache.camel.ValidationException;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.junit.Test;
> public class ValidatorTests extends CamelTestSupport {
> @Override
> protected RouteBuilder createRouteBuilder() throws Exception {
> return new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> validator()
> .type(String.class)
> 
> .withExpression(bodyAs(String.class).isEqualToIgnoreCase("valid"));
> onException(ValidationException.class)
> .handled(true)
> .log("Invalid predicate: ${exception.message}")
> .to("mock:invalid");
> from("direct:in")
> 
> //.validate(bodyAs(String.class).isEqualToIgnoreCase("valid"))
> .outputTypeWithValidate(String.class) // or 
> .inputTypeWithValidate(String.class)
> .to("mock:out");
> }
> };
> }
> @Test
> public void testValid() throws InterruptedException {
> getMockEndpoint("mock:out").expectedMessageCount(1);
> getMockEndpoint("mock:invalid").expectedMessageCount(0);
> template.sendBody("direct:in", "valid");
> assertMockEndpointsSatisfied();
> }
> @Test
> public void testInvalid() throws InterruptedException {
> getMockEndpoint("mock:out").expectedMessageCount(0);
> getMockEndpoint("mock:invalid").expectedMessageCount(1);
> template.sendBody("direct:in", "wrong");
> assertMockEndpointsSatisfied();
> }
> }
> {code}
> Expected result: both tests pass
> Actual result: 'testValid' - passed, 'testInvalid' - failed
> If uncomment line 25 & comment 26
> {code:java}
> .validate(bodyAs(String.class).isEqualToIgnoreCase("valid"))
> //.inputTypeWithValidate(String.class)
> {code}
> tests will OK
>  
> Other test case with same results
>  
> {code:java}
> package org.mike.tests;
> import org.apache.camel.Message;
> import org.apache.camel.ValidationException;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.impl.JndiRegistry;
> import org.apache.camel.spi.DataType;
> import org.apache.camel.spi.Validator;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.junit.Test;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> public class BeanValidatorTest extends CamelTestSupport {
> @Override
> protected RouteBuilder createRouteBuilder() throws Exception {
> return new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> validator()
> .type("toValidate")
> .withBean("testValidator");
> onException(ValidationException.class)
> .handled(true)
> .log("Invalid validation: ${exception.message}")
> .to("mock:invalid");
> from("direct:in")
> .outputTypeWithValidate("toValidate")
> .to("mock:out");
> }
> };
> }
> public static class TestValidator extends Validator {
> private static final Logger LOG = 
> LoggerFactory.getLogger(TestValidator.class);
> @Override
> public void validate(Message message, DataType type) throws 
> ValidationException {
> Object body = message.getBody();
> LOG.info("Validating : [{}]", body);
> if (body instanceof String && body.equals("valid")) {
> LOG.info("OK");
> } else {
> throw new ValidationException(message.getExchange(), "Wrong 
> content");
> }
> }
> }
> @Override
> protected JndiRegistry createRegistry() throws Exception {
> JndiRegistry registry = super.createRegistry();
> 

[jira] [Commented] (CAMEL-12565) outputTypeWithValidate (or inputTypeWithValidate) + validator()... doesn't work as expected

2018-08-06 Thread Claus Ibsen (JIRA)


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

Claus Ibsen commented on CAMEL-12565:
-

Okay so this is expected to happen, because the validation is at the output, 
which happens after the message has completed being routed. So any error 
handler with onException does not apply here. (chicken and egg).



> outputTypeWithValidate (or inputTypeWithValidate) + validator()... doesn't 
> work as expected
> ---
>
> Key: CAMEL-12565
> URL: https://issues.apache.org/jira/browse/CAMEL-12565
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.21.1
> Environment: Tested on camel 2.21.1, Java 8, Win
>Reporter: Michael Dzuba
>Priority: Major
> Fix For: 2.23.0
>
>
> {code:java}
> package org.mike.tests;
> import org.apache.camel.ValidationException;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.junit.Test;
> public class ValidatorTests extends CamelTestSupport {
> @Override
> protected RouteBuilder createRouteBuilder() throws Exception {
> return new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> validator()
> .type(String.class)
> 
> .withExpression(bodyAs(String.class).isEqualToIgnoreCase("valid"));
> onException(ValidationException.class)
> .handled(true)
> .log("Invalid predicate: ${exception.message}")
> .to("mock:invalid");
> from("direct:in")
> 
> //.validate(bodyAs(String.class).isEqualToIgnoreCase("valid"))
> .outputTypeWithValidate(String.class) // or 
> .inputTypeWithValidate(String.class)
> .to("mock:out");
> }
> };
> }
> @Test
> public void testValid() throws InterruptedException {
> getMockEndpoint("mock:out").expectedMessageCount(1);
> getMockEndpoint("mock:invalid").expectedMessageCount(0);
> template.sendBody("direct:in", "valid");
> assertMockEndpointsSatisfied();
> }
> @Test
> public void testInvalid() throws InterruptedException {
> getMockEndpoint("mock:out").expectedMessageCount(0);
> getMockEndpoint("mock:invalid").expectedMessageCount(1);
> template.sendBody("direct:in", "wrong");
> assertMockEndpointsSatisfied();
> }
> }
> {code}
> Expected result: both tests pass
> Actual result: 'testValid' - passed, 'testInvalid' - failed
> If uncomment line 25 & comment 26
> {code:java}
> .validate(bodyAs(String.class).isEqualToIgnoreCase("valid"))
> //.inputTypeWithValidate(String.class)
> {code}
> tests will OK
>  
> Other test case with same results
>  
> {code:java}
> package org.mike.tests;
> import org.apache.camel.Message;
> import org.apache.camel.ValidationException;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.impl.JndiRegistry;
> import org.apache.camel.spi.DataType;
> import org.apache.camel.spi.Validator;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.junit.Test;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> public class BeanValidatorTest extends CamelTestSupport {
> @Override
> protected RouteBuilder createRouteBuilder() throws Exception {
> return new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> validator()
> .type("toValidate")
> .withBean("testValidator");
> onException(ValidationException.class)
> .handled(true)
> .log("Invalid validation: ${exception.message}")
> .to("mock:invalid");
> from("direct:in")
> .outputTypeWithValidate("toValidate")
> .to("mock:out");
> }
> };
> }
> public static class TestValidator extends Validator {
> private static final Logger LOG = 
> LoggerFactory.getLogger(TestValidator.class);
> @Override
> public void validate(Message message, DataType type) throws 
> ValidationException {
> Object body = message.getBody();
> LOG.info("Validating : [{}]", body);
> if (body instanceof String && body.equals("valid")) {
> LOG.info("OK");
> } else {
> throw new ValidationException(message.getExchange(), "Wrong 
> content");
> }
>  

[jira] [Commented] (CAMEL-11497) Migrate the rest of the Confluence content

2018-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CAMEL-11497:


fbolton commented on a change in pull request #2451: CAMEL-11497: Migrate error 
handling related guides and EIPs
URL: https://github.com/apache/camel/pull/2451#discussion_r207966852
 
 

 ##
 File path: camel-core/src/main/docs/eips/dead-letter-channel.adoc
 ##
 @@ -384,7 +384,7 @@ The onPrepare is also available using the default error 
handler.
 *Available as of Camel 2.10.4/2.11*
 
 When Camel error handler handles an error such as
-link:dead-letter-channel.html[Dead Letter Channel] or using
+<> or using
 
 Review comment:
   The beauty of this style of cross-reference link:
   ```
   <>
   ```
   Which references the anchor:
   ```
   [[DeadLetterChannel-DeadLetterChannel]]
   ```
   In the file:
   
https://raw.githubusercontent.com/apache/camel/master/camel-core/src/main/docs/eips/dead-letter-channel.adoc
   
   Is that the link does not break if you rename the target file or if you move 
the target file to a different directory in the repo. Using the anchor 
reference gives you a level of abstraction that makes the link far less brittle.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Migrate the rest of the Confluence content
> --
>
> Key: CAMEL-11497
> URL: https://issues.apache.org/jira/browse/CAMEL-11497
> Project: Camel
>  Issue Type: Sub-task
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Önder Sezgin
>Priority: Major
> Fix For: Future
>
>
> There are still pages in the Confluence that are not migrated to Asciidoctor



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-11497) Migrate the rest of the Confluence content

2018-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CAMEL-11497:


fbolton commented on a change in pull request #2451: CAMEL-11497: Migrate error 
handling related guides and EIPs
URL: https://github.com/apache/camel/pull/2451#discussion_r207966852
 
 

 ##
 File path: camel-core/src/main/docs/eips/dead-letter-channel.adoc
 ##
 @@ -384,7 +384,7 @@ The onPrepare is also available using the default error 
handler.
 *Available as of Camel 2.10.4/2.11*
 
 When Camel error handler handles an error such as
-link:dead-letter-channel.html[Dead Letter Channel] or using
+<> or using
 
 Review comment:
   The beauty of this style of cross-reference:
   ```
   <>
   ```
   Which references the anchor:
   ```
   [[DeadLetterChannel-DeadLetterChannel]]
   ```
   In the file:
   
https://raw.githubusercontent.com/apache/camel/master/camel-core/src/main/docs/eips/dead-letter-channel.adoc
   
   Is that the link does not break if you rename the target file or if you move 
the target file to a different directory in the repo. Using the anchor 
reference gives you a level of abstraction that makes the link far less brittle.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Migrate the rest of the Confluence content
> --
>
> Key: CAMEL-11497
> URL: https://issues.apache.org/jira/browse/CAMEL-11497
> Project: Camel
>  Issue Type: Sub-task
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Önder Sezgin
>Priority: Major
> Fix For: Future
>
>
> There are still pages in the Confluence that are not migrated to Asciidoctor



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-11497) Migrate the rest of the Confluence content

2018-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CAMEL-11497:


fbolton commented on a change in pull request #2451: CAMEL-11497: Migrate error 
handling related guides and EIPs
URL: https://github.com/apache/camel/pull/2451#discussion_r207966852
 
 

 ##
 File path: camel-core/src/main/docs/eips/dead-letter-channel.adoc
 ##
 @@ -384,7 +384,7 @@ The onPrepare is also available using the default error 
handler.
 *Available as of Camel 2.10.4/2.11*
 
 When Camel error handler handles an error such as
-link:dead-letter-channel.html[Dead Letter Channel] or using
+<> or using
 
 Review comment:
   The beauty of this style of anchor:
   ```
   <>
   ```
   Which references the anchor:
   ```
   [[DeadLetterChannel-DeadLetterChannel]]
   ```
   In the file:
   
https://raw.githubusercontent.com/apache/camel/master/camel-core/src/main/docs/eips/dead-letter-channel.adoc
   
   Is that the link does not break if you rename the target file or if you move 
the target file to a different directory in the repo. Using the anchor 
reference gives you a level of abstraction that makes the link far less brittle.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Migrate the rest of the Confluence content
> --
>
> Key: CAMEL-11497
> URL: https://issues.apache.org/jira/browse/CAMEL-11497
> Project: Camel
>  Issue Type: Sub-task
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Önder Sezgin
>Priority: Major
> Fix For: Future
>
>
> There are still pages in the Confluence that are not migrated to Asciidoctor



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (CAMEL-12712) Camel Salesforce can easily hang when used within an aggregator

2018-08-06 Thread Jesse Sightler (JIRA)


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

Jesse Sightler updated CAMEL-12712:
---
Description: 
Reproducer project:

https://github.com/jsight/camel-salesforce-http-aggregator-issue

 

Run the unit tests and you will observe it hanging.

 

A workaround is also present. Uncomment this line:
{quote}// .to("seda:enrichWithJobId?waitForTaskToComplete=Always")
{quote}
 

The code that hangs is this:
{quote}.enrich("direct:createJobAndGetID", new AggregationStrategy() {
 @Override
 public Exchange aggregate(Exchange oldExchange, Exchange newExchange)
Unknown macro: \{ oldExchange.getIn().setHeader("jobId", 
newExchange.getIn().getBody(JobInfo.class).getId()); return oldExchange; }
})
{quote}
 

 

 

  was:
Run 
[Style|https://issues.apache.org/jira/projects/CAMEL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page]the
 unit tests and you will observe it hanging.

 

A workaround is also present. Uncomment this line:
{quote}// .to("seda:enrichWithJobId?waitForTaskToComplete=Always")
{quote}
 

The code that hangs is this:
{quote}
 .enrich("direct:createJobAndGetID", new AggregationStrategy() {
 @Override
 public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
 oldExchange.getIn().setHeader("jobId", 
newExchange.getIn().getBody(JobInfo.class).getId());
 return oldExchange;
 }
 })
{quote}
 

 

 


> Camel Salesforce can easily hang when used within an aggregator
> ---
>
> Key: CAMEL-12712
> URL: https://issues.apache.org/jira/browse/CAMEL-12712
> Project: Camel
>  Issue Type: Bug
>  Components: camel-salesforce
>Reporter: Jesse Sightler
>Priority: Major
>
> Reproducer project:
> https://github.com/jsight/camel-salesforce-http-aggregator-issue
>  
> Run the unit tests and you will observe it hanging.
>  
> A workaround is also present. Uncomment this line:
> {quote}// .to("seda:enrichWithJobId?waitForTaskToComplete=Always")
> {quote}
>  
> The code that hangs is this:
> {quote}.enrich("direct:createJobAndGetID", new AggregationStrategy() {
>  @Override
>  public Exchange aggregate(Exchange oldExchange, Exchange newExchange)
> Unknown macro: \{ oldExchange.getIn().setHeader("jobId", 
> newExchange.getIn().getBody(JobInfo.class).getId()); return oldExchange; }
> })
> {quote}
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (CAMEL-12712) Camel Salesforce can easily hang when used within an aggregator

2018-08-06 Thread Jesse Sightler (JIRA)
Jesse Sightler created CAMEL-12712:
--

 Summary: Camel Salesforce can easily hang when used within an 
aggregator
 Key: CAMEL-12712
 URL: https://issues.apache.org/jira/browse/CAMEL-12712
 Project: Camel
  Issue Type: Bug
  Components: camel-salesforce
Reporter: Jesse Sightler


Run 
[Style|https://issues.apache.org/jira/projects/CAMEL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page]the
 unit tests and you will observe it hanging.

 

A workaround is also present. Uncomment this line:
{quote}// .to("seda:enrichWithJobId?waitForTaskToComplete=Always")
{quote}
 

The code that hangs is this:
{quote}
 .enrich("direct:createJobAndGetID", new AggregationStrategy() {
 @Override
 public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
 oldExchange.getIn().setHeader("jobId", 
newExchange.getIn().getBody(JobInfo.class).getId());
 return oldExchange;
 }
 })
{quote}
 

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12484) Camel-salesforce component does not try to reconnect on specific error

2018-08-06 Thread Claus Ibsen (JIRA)


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

Claus Ibsen commented on CAMEL-12484:
-

Any update on this, or we will have to close it with cannot reproduce

> Camel-salesforce component does not try to reconnect on specific error
> --
>
> Key: CAMEL-12484
> URL: https://issues.apache.org/jira/browse/CAMEL-12484
> Project: Camel
>  Issue Type: Bug
>  Components: camel-salesforce
>Affects Versions: 2.21.0
>Reporter: Hemang Ajmera
>Priority: Major
>
> The issue is very much identical to CAMEL-10238 where camel component does 
> not try to reconnect. It was resolved for that particular case, however there 
> is additional scenario where we are facing exactly similar problem.
> Here is the key log message after which component stops retrying
> {{2018-05-03 17:19:50.257 WARN 7636 — [nt@911561694-23] 
> o.a.c.c.s.i.s.SubscriptionHelper : Connect failure: 
> {clientId=3qi3g4psrtqrntt15ockewu0a59q, advice=
> {reconnect=none, interval=0}
> , channel=/meta/connect, id=154, error=403::Unknown client, 
> successful=false}}}
> Please note that we are getting Connect failure multiple times but it is able 
> to reconnect where there is exception or when the advice is to do handshake 
> again. Here are those sample which works...
>  * The one with exceptions
> {quote}2018-05-03 17:19:17.965  WARN 7636 — [nt@911561694-23] 
> o.a.c.c.s.i.s.SubscriptionHelper : Connect failure: {failure=
> Unknown macro: \{exception=java.io.EOFException}
> ],recv=HttpReceiverOverHTTP@144e8ebb(rsp=IDLE,failure=null)[HttpParser
> Unknown macro: \{s=CLOSED,0 of -1}
> ]]<-DecryptedEndPoint@245db684
> Unknown macro: \{telia-fi--dev.cs88.my.salesforce.com/85.222.137.144}
> ->HttpConnectionOverHTTP@69f41507(l:/0:0:0:0:0:0:0:1:60369 <-> 
> r:telia-fi--dev.cs88.my.salesforce.com/85.222.137.144:443,closed=false)=>HttpChannelOverHTTP@3109c579(exchange=HttpExchange@76b96e24
>  req=TERMINATED/null@null 
> res=PENDING/null@null)[send=HttpSenderOverHTTP@5d6efa04(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator@43ac2f18
> Unknown macro: \{s=START}
> ],recv=HttpReceiverOverHTTP@144e8ebb(rsp=IDLE,failure=null)[HttpParser
> ]]->SocketChannelEndPoint@6b93b346
> Unknown macro: \{telia-fi--dev.cs88.my.salesforce.com/85.222.137.144}
> Unknown macro: \{io=0/0,kio=0,kro=1}
>  
> ->SslConnection@53bc7193\{NEED_WRAP,eio=-1/-1,di=-1}=>HttpConnectionOverHTTP@69f41507(l:/0:0:0:0:0:0:0:1:60369
>  <-> 
> r:telia-fi--dev.cs88.my.salesforce.com/85.222.137.144:443,closed=false)=>HttpChannelOverHTTP@3109c579(exchange=HttpExchange@76b96e24
>  req=TERMINATED/null@null 
> res=PENDING/null@null)[send=HttpSenderOverHTTP@5d6efa04(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator@43ac2f18
> Unknown macro: \{s=START}
> ],recv=HttpReceiverOverHTTP@144e8ebb(rsp=IDLE,failure=null)[HttpParser
> Unknown macro: \{s=CLOSED,0 of -1}
> ]], message=\{clientId=3qi3g4psrtqrntt15ockewu0a59q, channel=/meta/connect, 
> id=153, connectionType=long-polling}, connectionType=long-polling}, 
> channel=/meta/connect, id=153, successful=false}
> {quote}
>  
>  * The one with advice for new handshake
> {quote}2018-05-03 16:31:08.970  WARN 7636 — [nt@911561694-21] 
> o.a.c.c.s.i.s.SubscriptionHelper : Connect failure:
> Unknown macro: \{advice=Unknown macro}
> , channel=/meta/connect, id=83, error=403::Unknown client, successful=false}
> {quote}
>  
> One more thing, this log is coming from line 168 {{LOG.warn("Connect failure: 
> {}", message);}} of the 
> [https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/streaming/SubscriptionHelper.java#L168].
>  I see that there is no attempt to reconnect. If this information helps move 
> things faster...
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12492) Camel kafka producer is blocking and processing sequentially

2018-08-06 Thread Claus Ibsen (JIRA)


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

Claus Ibsen commented on CAMEL-12492:
-

You can set synchronous=true on the Camel endpoint then camel-kafka uses a 
synchronous process method that does not use Kafka callbacks.

> Camel kafka producer is blocking and processing sequentially
> 
>
> Key: CAMEL-12492
> URL: https://issues.apache.org/jira/browse/CAMEL-12492
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-kafka
>Affects Versions: 2.21.0
> Environment: Windows/Centos
>Reporter: Omri Tavor
>Priority: Major
>
> Camel Kafka producer (org.apache.camel.component.kafka.KafkaProducer) is 
> blocking on the Kafka producer 
> (org.apache.kafka.clients.producer.KafkaProducer) callback. This highly 
> affects performance when there is a big latency between the client and the 
> Kafka server. For example, if there is a latency of 100ms between the 
> servers, then the Kafka producer will run at a throughput of 10 events per 
> second (per Camel worker thread). This means that each worker thread will 
> only handle one kafka event at a time resulting in very bad performance.
> Changing the 'Process()' method in 
> org.apache.camel.component.kafka.KafkaProducer to always return true (work 
> synchronously) will boost performance on a machine with a latency of 150mb- 
> from 6 events per second to 5000 events per second.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (CAMEL-12492) Camel kafka producer is blocking and processing sequentially

2018-08-06 Thread Claus Ibsen (JIRA)


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

Claus Ibsen updated CAMEL-12492:

Issue Type: Improvement  (was: Bug)

> Camel kafka producer is blocking and processing sequentially
> 
>
> Key: CAMEL-12492
> URL: https://issues.apache.org/jira/browse/CAMEL-12492
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-kafka
>Affects Versions: 2.21.0
> Environment: Windows/Centos
>Reporter: Omri Tavor
>Priority: Major
>
> Camel Kafka producer (org.apache.camel.component.kafka.KafkaProducer) is 
> blocking on the Kafka producer 
> (org.apache.kafka.clients.producer.KafkaProducer) callback. This highly 
> affects performance when there is a big latency between the client and the 
> Kafka server. For example, if there is a latency of 100ms between the 
> servers, then the Kafka producer will run at a throughput of 10 events per 
> second (per Camel worker thread). This means that each worker thread will 
> only handle one kafka event at a time resulting in very bad performance.
> Changing the 'Process()' method in 
> org.apache.camel.component.kafka.KafkaProducer to always return true (work 
> synchronously) will boost performance on a machine with a latency of 150mb- 
> from 6 events per second to 5000 events per second.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (CAMEL-12510) Camel servlet component throw "IOException: Stream closed" during route processing for HTTP get request with custom processor

2018-08-06 Thread Claus Ibsen (JIRA)


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

Claus Ibsen resolved CAMEL-12510.
-
Resolution: Not A Bug
  Assignee: Claus Ibsen

> Camel servlet component throw "IOException: Stream closed" during route 
> processing for HTTP get request with custom processor
> -
>
> Key: CAMEL-12510
> URL: https://issues.apache.org/jira/browse/CAMEL-12510
> Project: Camel
>  Issue Type: Bug
>  Components: camel-servlet
>Affects Versions: 2.21.0
>Reporter: Thomas Papke
>Assignee: Claus Ibsen
>Priority: Major
>
> If i just build a simple Route like this to proxy a incoming Get request to 
> external host:
> {code:java}
>     @Override
>     public void configure() throws Exception {
>     from(format("servlet://%s?httpMethodRestrict=GET=%s", 
> RETRIEVE_PATH, servletName))
>     .process((exchange) -> {
>     exchange.getOut().setHeader(Exchange.HTTP_URI, 
> "https://some.external.system/;);
>     }).to("https4:something");
>     }
> {code}
> The following exception is thrown:
> {code:java}
> org.apache.camel.RuntimeCamelException: java.io.IOException: Stream closed
>   at 
> org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:80)
>   at org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:54)
>   at 
> org.apache.camel.processor.DefaultExchangeFormatter.getBodyTypeAsString(DefaultExchangeFormatter.java:468)
>   at 
> org.apache.camel.processor.DefaultExchangeFormatter.format(DefaultExchangeFormatter.java:126)
>   at 
> org.apache.camel.processor.CamelLogProcessor.process(CamelLogProcessor.java:88)
>   at 
> org.apache.camel.component.log.LogProducer.process(LogProducer.java:40)
>   at 
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
>   at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
>   at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>   at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
>   at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
>   at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:97)
>   at 
> org.apache.camel.http.common.CamelServlet.doService(CamelServlet.java:208)
>   at 
> org.apache.camel.http.common.CamelServlet.service(CamelServlet.java:78)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>   at 
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>   at 
> org.springframework.boot.actuate.trace.WebRequestTraceFilter.doFilterInternal(WebRequestTraceFilter.java:110)
>   at 
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>   at 
> org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
>   at 
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>   at 
> org.springframework.web.filter.HttpPutFormContentFilter.doFilterInternal(HttpPutFormContentFilter.java:108)
>   at 
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>   at 
> org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:81)
>   at 
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)

[jira] [Commented] (CAMEL-12510) Camel servlet component throw "IOException: Stream closed" during route processing for HTTP get request with custom processor

2018-08-06 Thread Claus Ibsen (JIRA)


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

Claus Ibsen commented on CAMEL-12510:
-

No the OUT header is not a valid, as then you need to copy over other stuff, 
like its body and whatnot. Use getMessage is better.

> Camel servlet component throw "IOException: Stream closed" during route 
> processing for HTTP get request with custom processor
> -
>
> Key: CAMEL-12510
> URL: https://issues.apache.org/jira/browse/CAMEL-12510
> Project: Camel
>  Issue Type: Bug
>  Components: camel-servlet
>Affects Versions: 2.21.0
>Reporter: Thomas Papke
>Priority: Major
>
> If i just build a simple Route like this to proxy a incoming Get request to 
> external host:
> {code:java}
>     @Override
>     public void configure() throws Exception {
>     from(format("servlet://%s?httpMethodRestrict=GET=%s", 
> RETRIEVE_PATH, servletName))
>     .process((exchange) -> {
>     exchange.getOut().setHeader(Exchange.HTTP_URI, 
> "https://some.external.system/;);
>     }).to("https4:something");
>     }
> {code}
> The following exception is thrown:
> {code:java}
> org.apache.camel.RuntimeCamelException: java.io.IOException: Stream closed
>   at 
> org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:80)
>   at org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:54)
>   at 
> org.apache.camel.processor.DefaultExchangeFormatter.getBodyTypeAsString(DefaultExchangeFormatter.java:468)
>   at 
> org.apache.camel.processor.DefaultExchangeFormatter.format(DefaultExchangeFormatter.java:126)
>   at 
> org.apache.camel.processor.CamelLogProcessor.process(CamelLogProcessor.java:88)
>   at 
> org.apache.camel.component.log.LogProducer.process(LogProducer.java:40)
>   at 
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
>   at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
>   at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>   at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
>   at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
>   at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>   at 
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:97)
>   at 
> org.apache.camel.http.common.CamelServlet.doService(CamelServlet.java:208)
>   at 
> org.apache.camel.http.common.CamelServlet.service(CamelServlet.java:78)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>   at 
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>   at 
> org.springframework.boot.actuate.trace.WebRequestTraceFilter.doFilterInternal(WebRequestTraceFilter.java:110)
>   at 
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>   at 
> org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
>   at 
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>   at 
> org.springframework.web.filter.HttpPutFormContentFilter.doFilterInternal(HttpPutFormContentFilter.java:108)
>   at 
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>   at 
> org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:81)
>   at 
> 

[jira] [Commented] (CAMEL-12525) camel-kafka component commits the offset as soon as it is retrieved

2018-08-06 Thread Claus Ibsen (JIRA)


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

Claus Ibsen commented on CAMEL-12525:
-

Can you try with a newer Camel version

> camel-kafka component commits the offset as soon as it is retrieved
> ---
>
> Key: CAMEL-12525
> URL: https://issues.apache.org/jira/browse/CAMEL-12525
> Project: Camel
>  Issue Type: Bug
>  Components: camel-kafka
>Affects Versions: 2.21.0
> Environment: Linux
>Reporter: Mukesh
>Priority: Major
>
> I am trying the maual commit from consumer below is the code snippet, i want 
> to consume and  commit the message after 2 mins of its arrival in the topic. 
> My consumer retrieves and checks the time difference if it is above 2 mins 
> then it should commit. But message once retrieved and not committed manually. 
> I am expecting it to come back but it does not comeback ever.  when i try 
> creating kafka consumer it works fine
> public void configure() throws Exception {
> from("kafka:BENEFITSLOADER.LOAD?brokers=:9092,:9092,:9092=BENEFITSLOADER=1=1000=false=true=1")
> .process(new Processor() {
>  @Override
>  public void process(Exchange exchange) throws Exception {
>  Long msgDateTime = (Long) 
> exchange.getIn().getHeaders().get(KafkaConstants.TIMESTAMP);
>  System.out.println("Message : " + (exchange.getIn().getHeaders()));
>  System.out.println("Message : " + (exchange.getIn().getBody()));
>  Date msgDate = new Date(msgDateTime);
>  Date currentDate = new Date();
>  long diff = currentDate.getTime() - msgDate.getTime();
>  long diffMinutes = diff / (60 * 1000) % 60;
>  System.out.println("Difference in Minutes " + diffMinutes);
>  KafkaManualCommit manualCommit = 
> exchange.getIn().getHeader(KafkaConstants.MANUAL_COMMIT, 
> KafkaManualCommit.class);
> if(diffMinutes > 2)
>  {
>  System.out.println("Commiting Message " + exchange.getIn().getBody()); 
>  manualCommit.commitSync(); 
>  } 
>  }
>  });
>  }
>  }
>  
>  
> Code that works fine
>  
> public class TestKafkaConsumer {
>  static Consumer consumer = null;
>  static ConsumerRecord fetchedRecord; 
>  static ConsumerRecords records;
>  public static void main(String... args) {
> String topicName = "BENEFITSLOADER.LOAD";
>  consumer = createConsumer();
>  consumer.subscribe(Collections.singletonList(topicName));
> try {
>  while (true) {
>  
>  if(fetchedRecord == null)
>  records = consumer.poll(1000);
>  
>  
>  records.forEach(record -> { 
>  fetchedRecord = record; 
>  });
>  
>  if(fetchedRecord != null)
>  {
>  Date msgDate = new Date(fetchedRecord.timestamp());
>  Date date = new Date(System.currentTimeMillis());
>  long diff = date.getTime() - msgDate.getTime();
>  long diffMinutes = diff / (60 * 1000) % 60;
>  
>  System.out.printf("Consumer Record:(%s, %s, %d, %d)\n",
>  fetchedRecord.key(), fetchedRecord.value(),
>  fetchedRecord.partition(), fetchedRecord.offset());
>  if(diffMinutes > 2)
>  {
>  System.out.printf("Consumer Record Commiting:(%s, %s, %d, %d)\n",
>  fetchedRecord.key(), fetchedRecord.value(),
>  fetchedRecord.partition(), fetchedRecord.offset());
>  consumer.commitSync();
>  System.out.println("Commited");
>  fetchedRecord = null;
>  }
>  } 
>  }
>  }
> catch (Exception ex) {
>  ex.printStackTrace();
>  } finally { 
>  consumer.close();
>  }
> }
> private static Consumer createConsumer() {
>  Properties props = new Properties();
>  props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, 
> "xxx:9092,xxx:9092,xxx:9093");
>  props.put(ConsumerConfig.GROUP_ID_CONFIG, "BENEFITSLOADER");
>  props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, 
> StringDeserializer.class.getName());
>  props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, 
> StringDeserializer.class.getName());
>  props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, false);
>  props.put(ConsumerConfig.MAX_POLL_RECORDS_CONFIG, 1);
>  return new KafkaConsumer<>(props);
>  }
> }



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12668) Aggregate with forcecompleteonstop doesn't seem to be honored

2018-08-06 Thread Dmitry Volodin (JIRA)


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

Dmitry Volodin commented on CAMEL-12668:


[~chirag0103] it's not a Context option, it's a route option. Your route must 
looks like

{code:java}
from("stream:file?fileName=src/main/resources/test.txt").shutdownRoute(ShutdownRoute.Defer)...
{code}


> Aggregate with forcecompleteonstop doesn't seem to be honored
> -
>
> Key: CAMEL-12668
> URL: https://issues.apache.org/jira/browse/CAMEL-12668
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.17.0
>Reporter: Chirag Anand
>Assignee: Dmitry Volodin
>Priority: Major
> Fix For: 2.22.1
>
>
> I have a camel project where I am using twitter component of the camel and 
> using the streaming/filter endpoint. The route is something like 
> from().aggregate().completionSize().forceCompletionOnStop().process().
>  The problem here is when I stop the context the remaining aggregated 
> exchanges are not being flushed to the processor. Earlier I was using version 
> 2.16.2 and it worked fine, but with the latest release i.e 2.22.0 I am facing 
> this issue. The configuration hasn’t changed a bit. To be certain i tried it 
> with version 2.17.0 also, doesn't work either.
>  
> I tried debugging and I noticed at somepoint there is a 
> RejectedExecutionException, not sure why because there is no change in the 
> configuration.
>  
> Can you please resolve this at the earliest? or at least tell me if there has 
> been any change in the functionality/usage?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12668) Aggregate with forcecompleteonstop doesn't seem to be honored

2018-08-06 Thread Chirag Anand (JIRA)


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

Chirag Anand commented on CAMEL-12668:
--

[~dmvolod] Can you please provide me with a code snippet on how to shutdown the 
route? i tried context.shutdownRoute("Routeid"), it still failed with the same 
exception.

> Aggregate with forcecompleteonstop doesn't seem to be honored
> -
>
> Key: CAMEL-12668
> URL: https://issues.apache.org/jira/browse/CAMEL-12668
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.17.0
>Reporter: Chirag Anand
>Assignee: Dmitry Volodin
>Priority: Major
> Fix For: 2.22.1
>
>
> I have a camel project where I am using twitter component of the camel and 
> using the streaming/filter endpoint. The route is something like 
> from().aggregate().completionSize().forceCompletionOnStop().process().
>  The problem here is when I stop the context the remaining aggregated 
> exchanges are not being flushed to the processor. Earlier I was using version 
> 2.16.2 and it worked fine, but with the latest release i.e 2.22.0 I am facing 
> this issue. The configuration hasn’t changed a bit. To be certain i tried it 
> with version 2.17.0 also, doesn't work either.
>  
> I tried debugging and I noticed at somepoint there is a 
> RejectedExecutionException, not sure why because there is no change in the 
> configuration.
>  
> Can you please resolve this at the earliest? or at least tell me if there has 
> been any change in the functionality/usage?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12668) Aggregate with forcecompleteonstop doesn't seem to be honored

2018-08-06 Thread Dmitry Volodin (JIRA)


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

Dmitry Volodin commented on CAMEL-12668:


[~chirag0103], you can try to use shutdownRoute(Defer) option as workaround, 
but it doesn't solve a core problem. If it helps in your case I will close this 
issue and open a new one with the root case description.

> Aggregate with forcecompleteonstop doesn't seem to be honored
> -
>
> Key: CAMEL-12668
> URL: https://issues.apache.org/jira/browse/CAMEL-12668
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.17.0
>Reporter: Chirag Anand
>Assignee: Dmitry Volodin
>Priority: Major
> Fix For: 2.22.1
>
>
> I have a camel project where I am using twitter component of the camel and 
> using the streaming/filter endpoint. The route is something like 
> from().aggregate().completionSize().forceCompletionOnStop().process().
>  The problem here is when I stop the context the remaining aggregated 
> exchanges are not being flushed to the processor. Earlier I was using version 
> 2.16.2 and it worked fine, but with the latest release i.e 2.22.0 I am facing 
> this issue. The configuration hasn’t changed a bit. To be certain i tried it 
> with version 2.17.0 also, doesn't work either.
>  
> I tried debugging and I noticed at somepoint there is a 
> RejectedExecutionException, not sure why because there is no change in the 
> configuration.
>  
> Can you please resolve this at the earliest? or at least tell me if there has 
> been any change in the functionality/usage?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12698) Unmarshaling a CSV file with the NEL (next line) character will cause Bindy to misread the entire file

2018-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CAMEL-12698:


onderson commented on a change in pull request #2454: CAMEL-12698: Use the 
Stream API to read files instead of Scanner
URL: https://github.com/apache/camel/pull/2454#discussion_r207786126
 
 

 ##
 File path: 
components/camel-bindy/src/main/java/org/apache/camel/dataformat/bindy/csv/BindyCsvDataFormat.java
 ##
 @@ -138,58 +144,74 @@ public Object unmarshal(Exchange exchange, InputStream 
inputStream) throws Excep
 // List of Pojos
 List> models = new ArrayList<>();
 
-// Pojos of the model
-Map model;
 InputStreamReader in = null;
-Scanner scanner = null;
 try {
 if (checkEmptyStream(factory, inputStream)) {
 return models;
 }
 
 in = new InputStreamReader(inputStream, 
IOHelper.getCharsetName(exchange));
-
-// Scanner is used to read big file
-scanner = new Scanner(in);
-
+
 // Retrieve the separator defined to split the record
 String separator = factory.getSeparator();
 String quote = factory.getQuote();
 ObjectHelper.notNull(separator, "The separator has not been 
defined in the annotation @CsvRecord or not instantiated during initModel.");
-
-int count = 0;
-
-// If the first line of the CSV file contains columns name, then we
-// skip this line
-if (factory.getSkipFirstLine()) {
-// Check if scanner is empty
-if (scanner.hasNextLine()) {
-scanner.nextLine();
+AtomicInteger count = new AtomicInteger(0);
+
+// Use a Stream to stream a file across.
+try (Stream lines = new BufferedReader(in).lines()) {
 
 Review comment:
   yes i agree, but this is for backward compatibility. some parts may be 
dropped or cleaned up in camel 3 or maybe your change may be only introduced in 
2.23 unless earlier versions would require the same thing. @oscerd wdyt?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Unmarshaling a CSV file with the NEL (next line) character will cause Bindy 
> to misread the entire file
> --
>
> Key: CAMEL-12698
> URL: https://issues.apache.org/jira/browse/CAMEL-12698
> Project: Camel
>  Issue Type: Bug
>  Components: camel-bindy
>Affects Versions: 2.22.0
>Reporter: Jason Black
>Priority: Major
>
> I am using Apache Camel to process a lot of large CSV files, and relying on 
> Bindy to assist with unmarshalling them into POJOs.
> We have an upstream data bug which causes a record of ours to contain the 
> Unicode character 
> [NEL|http://www.fileformat.info/info/unicode/char/85/index.htm], but while 
> we're working through the cause of that, I found it curious as to what Bindy 
> is actually doing with it.  We rely on the unmarshal process to perform a 
> batch insert, and because our POJO is missing certain fields, we started 
> observing that the 
> Bindy is relying on Scanner to read lines in a large file; however, Scanner 
> itself also does some parsing of the line with the assumption that, if it 
> sees the NEL character, it will regard it as a newline character.  The modern 
> Files API does not make this distinction and reads to a newline designation 
> only (e.g \n, \r, or \r\n).
> There are two ways to fix this from what I've been able to smoke test:
>  * Change the Scanner implementation to use a delimeter of the more 
> traditional newline characters
>  * Use Java 8's Files API and stream the file in
> I would personally want to use the Files API to handle this since it's more 
> robust and capable of higher performance, but I'll explore both approaches 
> and see where I end up.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12711) SFTP: Cannot specify bind address of local network interface

2018-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CAMEL-12711:


onderson commented on a change in pull request #2452: [CAMEL-12711] Add 
configuration property 'bindAddress' for SFTP
URL: https://github.com/apache/camel/pull/2452#discussion_r207785251
 
 

 ##
 File path: 
components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/SftpOperations.java
 ##
 @@ -1074,4 +1097,64 @@ public synchronized boolean sendSiteCommand(String 
command) throws GenericFileOp
 // is not implemented
 return true;
 }
+
+/*
+ * adapted from com.jcraft.jsch.Util.createSocket(String, int, int)
+ *
+ * added possibility to specify the address of the local network 
interface, against the
+ * connection should bind
+ */
+static Socket createSocketUtil(final String host, final int port, final 
String bindAddress, final int timeout) {
+Socket socket = null;
+if (timeout == 0) {
+try {
+socket = bindAddress == null ? new Socket(host, port) : new 
Socket(InetAddress.getByName(host), port, InetAddress.getByName(bindAddress), 
0);
 
 Review comment:
   what you do is reasonably good as the class and method has default access 
modifers.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> SFTP: Cannot specify bind address of local network interface
> 
>
> Key: CAMEL-12711
> URL: https://issues.apache.org/jira/browse/CAMEL-12711
> Project: Camel
>  Issue Type: Bug
>  Components: camel-ftp
>Affects Versions: 2.22.0
>Reporter: Felix Feisst
>Priority: Major
>
> In an environment with multiple network interfaces, it might be necessary to 
> specify the address of the local interface, to which the SFTP connection 
> should bind. Unfortunately, this is not possible with the latest version of 
> camel-ftp.
>  
> A new URI parameter 'bindAddress' should be introduces which can then be set 
> to the IP-Address of the local network interface against which the SFTP 
> connection should bind.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12711) SFTP: Cannot specify bind address of local network interface

2018-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CAMEL-12711:


onderson commented on a change in pull request #2452: [CAMEL-12711] Add 
configuration property 'bindAddress' for SFTP
URL: https://github.com/apache/camel/pull/2452#discussion_r207785251
 
 

 ##
 File path: 
components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/SftpOperations.java
 ##
 @@ -1074,4 +1097,64 @@ public synchronized boolean sendSiteCommand(String 
command) throws GenericFileOp
 // is not implemented
 return true;
 }
+
+/*
+ * adapted from com.jcraft.jsch.Util.createSocket(String, int, int)
+ *
+ * added possibility to specify the address of the local network 
interface, against the
+ * connection should bind
+ */
+static Socket createSocketUtil(final String host, final int port, final 
String bindAddress, final int timeout) {
+Socket socket = null;
+if (timeout == 0) {
+try {
+socket = bindAddress == null ? new Socket(host, port) : new 
Socket(InetAddress.getByName(host), port, InetAddress.getByName(bindAddress), 
0);
 
 Review comment:
   what you do is reasonably good as the class and method has default access 
modifers.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> SFTP: Cannot specify bind address of local network interface
> 
>
> Key: CAMEL-12711
> URL: https://issues.apache.org/jira/browse/CAMEL-12711
> Project: Camel
>  Issue Type: Bug
>  Components: camel-ftp
>Affects Versions: 2.22.0
>Reporter: Felix Feisst
>Priority: Major
>
> In an environment with multiple network interfaces, it might be necessary to 
> specify the address of the local interface, to which the SFTP connection 
> should bind. Unfortunately, this is not possible with the latest version of 
> camel-ftp.
>  
> A new URI parameter 'bindAddress' should be introduces which can then be set 
> to the IP-Address of the local network interface against which the SFTP 
> connection should bind.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12711) SFTP: Cannot specify bind address of local network interface

2018-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CAMEL-12711:


onderson commented on a change in pull request #2452: [CAMEL-12711] Add 
configuration property 'bindAddress' for SFTP
URL: https://github.com/apache/camel/pull/2452#discussion_r207785238
 
 

 ##
 File path: 
components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/SftpOperations.java
 ##
 @@ -1074,4 +1097,64 @@ public synchronized boolean sendSiteCommand(String 
command) throws GenericFileOp
 // is not implemented
 return true;
 }
+
+/*
+ * adapted from com.jcraft.jsch.Util.createSocket(String, int, int)
+ *
+ * added possibility to specify the address of the local network 
interface, against the
+ * connection should bind
+ */
+static Socket createSocketUtil(final String host, final int port, final 
String bindAddress, final int timeout) {
+Socket socket = null;
+if (timeout == 0) {
+try {
+socket = bindAddress == null ? new Socket(host, port) : new 
Socket(InetAddress.getByName(host), port, InetAddress.getByName(bindAddress), 
0);
+return socket;
+} catch (Exception e) {
+String message = e.toString();
+if (e instanceof Throwable) {
+throw new RuntimeCamelException(message, (Throwable)e);
+}
+throw new RuntimeCamelException(message);
+}
+}
+final Socket[] sockp = new Socket[1];
+final Exception[] ee = new Exception[1];
+String message = "";
+Thread tmp = new Thread(new Runnable() {
+public void run() {
+sockp[0] = null;
+try {
+sockp[0] = bindAddress == null ? new Socket(host, port) : 
new Socket(InetAddress.getByName(host), port, 
InetAddress.getByName(bindAddress), 0);
 
 Review comment:
   not sure if null check for the new configuration option would be nicer 
before creating socket factory. othwerwise new Socket(host,port) will 
be created which may affect as-is users unless provide unit test case. I guess 
test case would be nicer to showcase your requirement.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> SFTP: Cannot specify bind address of local network interface
> 
>
> Key: CAMEL-12711
> URL: https://issues.apache.org/jira/browse/CAMEL-12711
> Project: Camel
>  Issue Type: Bug
>  Components: camel-ftp
>Affects Versions: 2.22.0
>Reporter: Felix Feisst
>Priority: Major
>
> In an environment with multiple network interfaces, it might be necessary to 
> specify the address of the local interface, to which the SFTP connection 
> should bind. Unfortunately, this is not possible with the latest version of 
> camel-ftp.
>  
> A new URI parameter 'bindAddress' should be introduces which can then be set 
> to the IP-Address of the local network interface against which the SFTP 
> connection should bind.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12711) SFTP: Cannot specify bind address of local network interface

2018-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CAMEL-12711:


onderson commented on a change in pull request #2452: [CAMEL-12711] Add 
configuration property 'bindAddress' for SFTP
URL: https://github.com/apache/camel/pull/2452#discussion_r207785091
 
 

 ##
 File path: 
components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/SftpOperations.java
 ##
 @@ -1074,4 +1097,64 @@ public synchronized boolean sendSiteCommand(String 
command) throws GenericFileOp
 // is not implemented
 return true;
 }
+
+/*
+ * adapted from com.jcraft.jsch.Util.createSocket(String, int, int)
+ *
+ * added possibility to specify the address of the local network 
interface, against the
+ * connection should bind
+ */
+static Socket createSocketUtil(final String host, final int port, final 
String bindAddress, final int timeout) {
 
 Review comment:
   what you do is reasonably good as the class and method has default access 
modifers.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> SFTP: Cannot specify bind address of local network interface
> 
>
> Key: CAMEL-12711
> URL: https://issues.apache.org/jira/browse/CAMEL-12711
> Project: Camel
>  Issue Type: Bug
>  Components: camel-ftp
>Affects Versions: 2.22.0
>Reporter: Felix Feisst
>Priority: Major
>
> In an environment with multiple network interfaces, it might be necessary to 
> specify the address of the local interface, to which the SFTP connection 
> should bind. Unfortunately, this is not possible with the latest version of 
> camel-ftp.
>  
> A new URI parameter 'bindAddress' should be introduces which can then be set 
> to the IP-Address of the local network interface against which the SFTP 
> connection should bind.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CAMEL-12698) Unmarshaling a CSV file with the NEL (next line) character will cause Bindy to misread the entire file

2018-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CAMEL-12698:


MakotoTheKnight commented on a change in pull request #2454: CAMEL-12698: Use 
the Stream API to read files instead of Scanner
URL: https://github.com/apache/camel/pull/2454#discussion_r207784002
 
 

 ##
 File path: 
components/camel-bindy/src/main/java/org/apache/camel/dataformat/bindy/csv/BindyCsvDataFormat.java
 ##
 @@ -138,58 +144,74 @@ public Object unmarshal(Exchange exchange, InputStream 
inputStream) throws Excep
 // List of Pojos
 List> models = new ArrayList<>();
 
-// Pojos of the model
-Map model;
 InputStreamReader in = null;
-Scanner scanner = null;
 try {
 if (checkEmptyStream(factory, inputStream)) {
 return models;
 }
 
 in = new InputStreamReader(inputStream, 
IOHelper.getCharsetName(exchange));
-
-// Scanner is used to read big file
-scanner = new Scanner(in);
-
+
 // Retrieve the separator defined to split the record
 String separator = factory.getSeparator();
 String quote = factory.getQuote();
 ObjectHelper.notNull(separator, "The separator has not been 
defined in the annotation @CsvRecord or not instantiated during initModel.");
-
-int count = 0;
-
-// If the first line of the CSV file contains columns name, then we
-// skip this line
-if (factory.getSkipFirstLine()) {
-// Check if scanner is empty
-if (scanner.hasNextLine()) {
-scanner.nextLine();
+AtomicInteger count = new AtomicInteger(0);
+
+// Use a Stream to stream a file across.
+try (Stream lines = new BufferedReader(in).lines()) {
 
 Review comment:
   Good call on the other classes; I'll take a look at those and follow up with 
another commit to address those deficiencies.  A quick skim suggests that they 
too would suffer from the same bug.
   
   As for adding a boolean option to address this - I'm not entirely convinced 
of the value of it.  The assumption the code is making is that an entire line 
from the file is being read, but it leaves the definition of a line to the 
implementation of `Scanner`, when it really should be the convention we all 
have come to expect and demand of lines from a file (carriage return, line 
feed, or both).  By and large, `Scanner` does catch almost every use case there 
is when it comes to lines, with the exception of this very peculiar instance.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Unmarshaling a CSV file with the NEL (next line) character will cause Bindy 
> to misread the entire file
> --
>
> Key: CAMEL-12698
> URL: https://issues.apache.org/jira/browse/CAMEL-12698
> Project: Camel
>  Issue Type: Bug
>  Components: camel-bindy
>Affects Versions: 2.22.0
>Reporter: Jason Black
>Priority: Major
>
> I am using Apache Camel to process a lot of large CSV files, and relying on 
> Bindy to assist with unmarshalling them into POJOs.
> We have an upstream data bug which causes a record of ours to contain the 
> Unicode character 
> [NEL|http://www.fileformat.info/info/unicode/char/85/index.htm], but while 
> we're working through the cause of that, I found it curious as to what Bindy 
> is actually doing with it.  We rely on the unmarshal process to perform a 
> batch insert, and because our POJO is missing certain fields, we started 
> observing that the 
> Bindy is relying on Scanner to read lines in a large file; however, Scanner 
> itself also does some parsing of the line with the assumption that, if it 
> sees the NEL character, it will regard it as a newline character.  The modern 
> Files API does not make this distinction and reads to a newline designation 
> only (e.g \n, \r, or \r\n).
> There are two ways to fix this from what I've been able to smoke test:
>  * Change the Scanner implementation to use a delimeter of the more 
> traditional newline characters
>  * Use Java 8's Files API and stream the file in
> I would personally want to use the Files API to handle this since it's more 
> robust and capable of higher performance, but I'll explore both approaches 
> and see where I end up.
>  



--
This message was sent by