We know it is being initialized - it works for nearly all of the commands. It even appears to work for other commands in the session, and even most downloads. Just not for "some". We're not even sure where the problem is - just that either it means that we aren't running through this ftplet... or somehow the user isn't actually downloading the file when they think they are (or is downloading something else).
We are hesitant to turn on debugging. The server gets over 30k connections, over 13k logins, and over 10k downloads a day, and of these, fewer than 100 are having problems. Thats kinda our next step - but we're hesitant about it. (Tho we do wonder why an ftplet throwing an exception disconnects with only a logging to debug, but thats another issue.) As it is, we had to turn off logging for warnings and errors in some classes because of the volume of logs they produced for "routine" connections, and we're considering turning off even more. We find there are a LOT of misbehaved clients out there who will close the control or data connections unexpectedly, causing an exception. Thanks for the suggestions - any more welcome. :) We're still floundering around trying to figure out whats going on. Allen On Tue, Jun 7, 2011 at 9:36 PM, Toli Kuznets <[email protected]>wrote: > Allen, > > Not aware of any default ftplets... but if the user is willing to help > out to repro the problem, you can try turning on all logging to > "debug" and seeing what the chain of command is when the user logs in > and uploads the file... > > Also, can you print out some logging messages in your Ftplet > constructor? perhaps it's not being loaded into the system the way you > expect, so it never gets executed? > > that'd be my first attempt > > On Tue, Jun 7, 2011 at 6:32 PM, Allen Firstenberg > <[email protected]> wrote: > > We're trying to track down a problem with an ftplet (our logging ftplet, > > which we're testing in production) that is totally baffling us. We have > a > > user that reports that they downloaded a file. As far as we can tell, > > neither the beforeCommand() nor afterCommand() methods were called - > > although the transfer appears to have succeeded. There are numerous > errors > > sent to stdout about pipes being closed on either the command or data > > channel, so we can't trace them to a specific instance. > > > > Can anyone think of a way that the file could be transfered without our > > ftplet being called? Are there default ftplets that might have told it > to > > skip further processing before it got to ours? > > > > Any thoughts about this, or how to track down the problem on a production > > server, would be greatly appreciated. > > > > Thanks! > > Allen > > >
