[
https://issues.apache.org/jira/browse/NET-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Lynch-Milner updated NET-696:
------------------------------------
Description:
When a thread sends a no-op to the FTPClient, and then the main UI thread I
have running lists the files for a specified directory I get an exception trace
similar to the one found in issue NET-476 similar to this:
{noformat}
Caused by: org.apache.commons.net.ftp.parser.ParserInitializationException:
Unknown parser type: PORT command successful. Consider using PASV.
at
org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactory.createFileEntryParser(DefaultFTPFileEntryParserFactory.java:118)
at
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2359)
at
org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2142){noformat}
But in my case after the no-op is sent, the Unknown parser type is: NOOP ok or
something along the lines of that.
I have been struggling to reproduce it as it happens occasionally and I can't
find a pattern to it. Could it be because of a race condition, when the thread
sends a no-op at the exact same time the main thread sends a listFiles command?
(They use the same ftpClient objects, the main UI thread and the thread sending
no-ops). I wish I could find a workaround to this issue but not sure where to
start with it.
It also happens with getModificationTime. Here is an exception from trying to
parse the modification time returned by ftpClient.getModificationTime:
{noformat}
Exception in thread "JavaFX Application Thread"
java.time.format.DateTimeParseException: Text 'NOOP ok.' could not be parsed at
index 0
at
java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2046)
at
java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1948)
at
java.base/java.time.LocalDateTime.parse(LocalDateTime.java:492){noformat}
was:
When a thread sends a no-op to the FTPClient, and then the main UI thread I
have running lists the files for a specified directory I get an exception trace
similar to the one found in issue NET-476 similar to this:
{noformat}
Caused by: org.apache.commons.net.ftp.parser.ParserInitializationException:
Unknown parser type: PORT command successful. Consider using PASV.
at
org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactory.createFileEntryParser(DefaultFTPFileEntryParserFactory.java:118)
at
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2359)
at
org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2142){noformat}
But in my case after the no-op is sent, the Unknown parser type is: NOOP Reply
ok or something along the lines of that.
I have been struggling to reproduce it as it happens occasionally and I can't
find a pattern to it. Could it be because of a race condition, when the thread
sends a no-op at the exact same time the main thread sends a listFiles command?
(They use the same ftpClient objects, the main UI thread and the thread sending
no-ops). I wish I could find a workaround to this issue but not sure where to
start with it.
> Issue with ParserInitializationException: Unknown Parser Type: NOOP Reply ok
> ----------------------------------------------------------------------------
>
> Key: NET-696
> URL: https://issues.apache.org/jira/browse/NET-696
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 3.7
> Reporter: Edward Lynch-Milner
> Priority: Major
>
> When a thread sends a no-op to the FTPClient, and then the main UI thread I
> have running lists the files for a specified directory I get an exception
> trace similar to the one found in issue NET-476 similar to this:
> {noformat}
> Caused by: org.apache.commons.net.ftp.parser.ParserInitializationException:
> Unknown parser type: PORT command successful. Consider using PASV.
> at
> org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactory.createFileEntryParser(DefaultFTPFileEntryParserFactory.java:118)
> at
> org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2359)
> at
> org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2142){noformat}
> But in my case after the no-op is sent, the Unknown parser type is: NOOP ok
> or something along the lines of that.
> I have been struggling to reproduce it as it happens occasionally and I can't
> find a pattern to it. Could it be because of a race condition, when the
> thread sends a no-op at the exact same time the main thread sends a listFiles
> command? (They use the same ftpClient objects, the main UI thread and the
> thread sending no-ops). I wish I could find a workaround to this issue but
> not sure where to start with it.
> It also happens with getModificationTime. Here is an exception from trying to
> parse the modification time returned by ftpClient.getModificationTime:
> {noformat}
> Exception in thread "JavaFX Application Thread"
> java.time.format.DateTimeParseException: Text 'NOOP ok.' could not be parsed
> at index 0
> at
> java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2046)
> at
> java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1948)
> at
> java.base/java.time.LocalDateTime.parse(LocalDateTime.java:492){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
