On Wed, Jun 8, 2011 at 7:21 AM, David Latorre <[email protected]> wrote:
> Hello Allen, > > I would need some more info for this, e.g., > > 1) Are the clients using FTP or FTPS? > The clients are using FTP. We have tried setting up packet sniffing for some of this, but the volume of traffic is too high to sift through it. > 2) Are they using a 'publicly available' FTP client? which one? > This is a little unclear. They are either using a library from Microsoft (although they haven't been able to tell us which one), or a library from "DART PowerTCP FTP". We have had problems with both in the past against this server, when we didn't when using ProFTPD, but we thought we had traced them to an issue with some redundancy network hardware that was resolved. > 3) Is it possible that you're capturing some exceptions silently? > I never say its impossible. But any exceptions in my code that I catch are logged (using jdk logging) at a warning level, and none seem to have been reported. The ftplets might, in theory, rethrow exceptions - and if they are, they are caught and logged at a debugging level, so it is possible this is being swallowed. But it is difficult to see how this is happening given the rest of the circumstances. > 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... > Yeah... we're working on that front. So far all they can tell us is "Error 1"... which means nothing to them or us. They can't even report what command exactly is causing the error. We're still trying to get more out of them. It is compounded that we're not convinced that the server is being hit at all for some of the problems, or if it is the network redundancy configuration or some other configuration outside the FTP server itself that is messing things up again. So even if we add more logging to ours, at best we might be able to prove it has nothing to do with the FTP server... > Otherwise, I don't find it easy to find your problem... Us either. :) But thank you for insights. > 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). We're not too worried about performance of the server... we're more concerned that somehow we would have to sift through lots of information that doesn't indicate anything in search of one line that might. And then, somehow, tie it to the actual session and command that caused the problem. We'll go this route if we need to, and narrow it as much as we can... but we're trying to figure out what might be the cause before we go to that point.
