Hello Allen, I would need some more info for this, e.g.,
1) Are the clients using FTP or FTPS? 2) Are they using a 'publicly available' FTP client? which one? 3) Is it possible that you're capturing some exceptions silently? If I understand you correctly, FTPServer itself has logging disabled; is it so? First option here is that you ask your client if they have any logs of the file transfer... Otherwise, I don't find it easy to find your problem... Maybe you can try to obtain finer grained logging in FTPServer by using an implementation that allows Filters to be specified so you don't have to turn on all the logging output if you're worried about system performance (I don't actually know if there's reason to worry). 2011/6/8 Allen Firstenberg <[email protected]>: > On Wed, Jun 8, 2011 at 5:44 AM, Niklas Gustavsson <[email protected]>wrote: > >> >> Which exact log statement is it that you were expecting? From >> FtpLoggingFilter? >> >> What logging provider are you using? Assuming this is a race >> condition, it could be both in FtpServer, slf4j and the logging >> provider. > > > The "logging" in this case isn't code level logging, it is command/transfer > logging. It is an ftplet that can be configured to log various attributes > from an FtpSession, FtpRequest, and/or FtpReply. It is intended for xferlog > and similar logging capabilities. We've mentioned this in the past as > something we're working on and that we intend to release to the project when > we feel its ready for prime time. > > In this case, log messages are saved to a file during both beforeCommand() > and afterCommand() in several different ftplets. In order for it to be a > race condition, these would have had to fail multiple times - and just for > this particular instance. I can't rule it out, of course, but it seems > unlikely. > > Allen >
