You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Edward Lynch-Milner (Jira)" <ji...@apache.org> on 2020/12/18 16:41:00 UTC
[jira] [Updated] (NET-696) Issue with
ParserInitializationException: Unknown Parser Type: NOOP Reply ok
[ 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)