Mailing-List: contact issues-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Date: Thu, 24 Jan 2013 00:09:12 +0000 (UTC)
From: "Aki Yoshida (JIRA)" <jira@apache.org>
To: issues@camel.apache.org
Message-ID: <JIRA.12628577.1358786191241.182522.1358986152939@arcas>
In-Reply-To: <JIRA.12628577.1358786191241@arcas>
References: <JIRA.12628577.1358786191241@arcas>
Subject: [jira] [Commented] (CAMEL-5989) Camel SFTP endpoint throws
 exception when running camel route on Windows OS
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Aki Yoshida commented on CAMEL-5989:
------------------------------------

Hi Claus,
this issue seems to be unrelated to CAMEL-5574, as it is occurring with no-stepwise mode and when trying to go back to root "/" (but incorrectly to "\"). Whereas CAMEL-5574 only changed the stepwise traversal behavior in 2.10.2. I suspect, if Joe uses the stepwise mode (and likely also with the non-stepwise mode), it will work with 2.10.2 but unfortunately not with 2.10.3 because of rev 1410217 in trunk that changed FileUtil.java. This change interferes with the directory path comparison in SFTPOperations's. And this mismatch was fixed with rev 1424437 in trunk and the current 2.10.4-SNAPSHOT should contains the fix.

Hi Joe,
I may be wrong with my assumption, but can you try your scenario with 2.10.4-SNAPSHOT to see if the problem is resolved? (I think 2.10.2 will also work for you). 

regards, aki

                
> Camel SFTP endpoint throws exception when running camel route on Windows OS
> ---------------------------------------------------------------------------
>
>                 Key: CAMEL-5989
>                 URL: https://issues.apache.org/jira/browse/CAMEL-5989
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-ftp
>    Affects Versions: 2.10.3
>            Reporter: Joe Luo
>            Assignee: Claus Ibsen
>
> I have a rather simple camel route involving sftp endpoints:
> from("sftp://jluo@192.168.0.196/outbox?password=******&binary=true&autoCreate=true&move=.done").to("sftp://jluo@192.168.0.196/inbox?password=******&autoCreate=true&binary=true");
> The camel sftp consumer and producer endpoints are pointing to my Mac OSX host (192.168.0.196). When I ran the camel route on Windows machine (here I was using Windows 7 Pro 64-bit OS) to try to use sftp to consume and produce files from/to Mac OSX machine, I got following error:
>  15:46:59,941 | INFO  | 168.0.196/outbox | SftpOperations                   |  -  -  | JSCH -> SSH_MSG_NEWKEYS received
> 15:46:59,941 | INFO  | 168.0.196/outbox | SftpOperations                   |  -  -  | JSCH -> SSH_MSG_SERVICE_REQUEST sent
> 15:46:59,941 | INFO  | 168.0.196/outbox | SftpOperations                   |  -  -  | JSCH -> SSH_MSG_SERVICE_ACCEPT received
> 15:46:59,941 | INFO  | 168.0.196/outbox | SftpOperations                   |  -  -  | JSCH -> Authentications that can continue: publickey,keyboard-interactive,password
> 15:46:59,941 | INFO  | 168.0.196/outbox | SftpOperations                   |  -  -  | JSCH -> Next authentication method: publickey
> 15:46:59,941 | INFO  | 168.0.196/outbox | SftpOperations                   |  -  -  | JSCH -> Authentications that can continue: keyboard-interactive,password
> 15:46:59,941 | INFO  | 168.0.196/outbox | SftpOperations                   |  -  -  | JSCH -> Next authentication method: keyboard-interactive
> 15:47:00,003 | INFO  | 168.0.196/outbox | SftpOperations                   |  -  -  | JSCH -> Authentication succeeded (keyboard-interactive).
> 15:47:00,003 | TRACE | 168.0.196/outbox | SftpOperations                   |  -  -  | Channel isn't connected, trying to recreate and connect.
> 15:47:00,003 | TRACE | 168.0.196/outbox | SftpOperations                   |  -  -  | Connecting use connectTimeout: 10000 ...
> 15:47:00,034 | INFO  | 168.0.196/outbox | SftpOperations                   |  -  -  | Connected to sftp://jluo@192.168.0.196:22
> 15:47:00,034 | INFO  | 168.0.196/outbox | SftpConsumer                     |  -  -  | Connected and logged in to: sftp://jluo@192.168.0.196:22
> 15:47:00,034 | TRACE | 168.0.196/outbox | SftpOperations                   |  -  -  | getCurrentDirectory()
> 15:47:00,034 | TRACE | 168.0.196/outbox | SftpConsumer                     |  -  -  | doPollDirectory from absolutePath: outbox, dirName: null
> 15:47:00,034 | TRACE | 168.0.196/outbox | SftpOperations                   |  -  -  | changeCurrentDirectory(outbox)
> 15:47:00,034 | TRACE | 168.0.196/outbox | SftpOperations                   |  -  -  | getCurrentDirectory()
> 15:47:00,034 | TRACE | 168.0.196/outbox | SftpOperations                   |  -  -  | Changing directory: outbox
> 15:47:00,034 | TRACE | 168.0.196/outbox | SftpConsumer                     |  -  -  | Polling directory: outbox
> 15:47:00,034 | TRACE | 168.0.196/outbox | SftpOperations                   |  -  -  | listFiles(.)
> 15:47:00,050 | TRACE | 168.0.196/outbox | SftpConsumer                     |  -  -  | Found 3 in directory: outbox
> 15:47:00,050 | TRACE | 168.0.196/outbox | SftpOperations                   |  -  -  | changeCurrentDirectory(/Users/jluo)
> 15:47:00,050 | TRACE | 168.0.196/outbox | SftpOperations                   |  -  -  | getCurrentDirectory()
> 15:47:00,050 | TRACE | 168.0.196/outbox | SftpOperations                   |  -  -  | Changing directory: \
> 15:47:00,050 | WARN  | 168.0.196/outbox | eFilePollingConsumerPollStrategy |  -  -  | Trying to recover by disconnecting from remote server forcing a re-connect at next poll: sftp://jluo@192.168.0.196:22
> 15:47:00,050 | DEBUG | 168.0.196/outbox | SftpConsumer                     |  -  -  | Disconnecting from: sftp://jluo@192.168.0.196:22
> 15:47:00,050 | INFO  | 168.0.196/outbox | SftpOperations                   |  -  -  | JSCH -> Disconnecting from 192.168.0.196 port 22
> 15:47:00,066 | INFO  | 68.0.196 session | SftpOperations                   |  -  -  | JSCH -> Caught an exception, leaving main loop due to socket closed
> 15:47:00,066 | WARN  | 168.0.196/outbox | SftpConsumer                     |  -  -  | Consumer Consumer[sftp://jluo@192.168.0.196/outbox?autoCreate=true&binary=true&move=.done&password=******] failed polling endpoint: Endpoint[sftp://jluo@192.168.0.196/outbox?autoCreate=true&binary=true&move=.done&password=******]. Will try again at next poll. Caused by: [org.apache.camel.component.file.GenericFileOperationFailedException - Cannot change directory to: \]
> org.apache.camel.component.file.GenericFileOperationFailedException: Cannot change directory to: \
> 	at org.apache.camel.component.file.remote.SftpOperations.doChangeDirectory(SftpOperations.java:434)[camel-ftp-2.10.3.jar:2.10.3]
> 	at org.apache.camel.component.file.remote.SftpOperations.changeCurrentDirectory(SftpOperations.java:407)[camel-ftp-2.10.3.jar:2.10.3]
> 	at org.apache.camel.component.file.remote.SftpConsumer.pollDirectory(SftpConsumer.java:52)[camel-ftp-2.10.3.jar:2.10.3]
> 	at org.apache.camel.component.file.GenericFileConsumer.poll(GenericFileConsumer.java:107)[camel-core-2.10.3.jar:2.10.3]
> 	at org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:142)[camel-core-2.10.3.jar:2.10.3]
> 	at org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:92)[camel-core-2.10.3.jar:2.10.3]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_33]
> 	at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)[:1.6.0_33]
> 	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)[:1.6.0_33]
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)[:1.6.0_33]
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)[:1.6.0_33]
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)[:1.6.0_33]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_33]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_33]
> 	at java.lang.Thread.run(Thread.java:662)[:1.6.0_33]
> I tried to run the same camel route on my Mac OSX host (so it was from Mac OSX -> Mac OSX) and everything worked fine. In another word, running the camel route on an Unix like OS, it worked fine. It looks like a bug was introduced from 2.9.x to 2.10 that relates to Windows since I also tested on Camel 2.9.2 version and when I run the same route on Windows machine with camel 2.9.2, it worked fine though. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira