Oh, my bad. My eyes saw onUploadEnd() but, for some reason, my fingers kept typing handleOnClose()....
sorry for the confusion.... On Mon, Feb 14, 2011 at 1:46 AM, David Latorre <[email protected]> wrote: > Uh, I see that's what you did :) > > > > 2011/2/14 David Latorre <[email protected]>: >> Hello Toli, >> >> why don't you set your ftpet to be run after STOR (and STOU...) >> command? In the old way this was the method onUploadEnd(). >> >> >> 2011/2/12 Toli Kuznets <[email protected]>: >>> Hi, >>> >>> I have a custom FtpLet and I wan to kick off a job on file upload, so >>> i override the handleOnClose() call. >>> >>> I'm running into a situation where when my users use SSIS (scary >>> Microsoft product) to send files over FTP, they are not able to >>> establish a data connection to my server (separate problem), there's >>> an internal exception in STOR.execute() but I still get a callback in >>> onHandleClose() >>> >>> However, when I get the callback, it's impossible for me to tell the >>> difference between a "successful" upload or a callback after an >>> exception when there was no physical file placed on disk. >>> >>> Looking in the debugger, I notice that the incoming FtpSession is >>> actually a DefaultFtpSession that has an FtpIoSession that has a >>> getLatReply() method that can return me something useful >>> (REPLY_425_CANT_OPEN_DATA_CONNECTION in my case). >>> However, getting to lastReply is not exposed. >>> >>> is there a better way to tell if handleOnClose() is being called on >>> success or failure? How can i tell those 2 situations apart? >>> >>> My server is setup with all defaults for connections - in this case, >>> the connection is coming in as ACTIVE and for some reason i get an >>> exception when opening data connection, so i want to catch that case >>> and not kick of an event in handleOnClose() >>> >>> This is on FtpServer-1.0.5, and the relevant stacktrace from the call >>> to handleOnClose() after the failed open of data connection is: >>> at >>> com.marin.plugin.ftpserver.FileUploadNotifierFtplet.onUploadEnd(FileUploadNotifierFtplet.java:70) >>> at >>> org.apache.ftpserver.ftplet.DefaultFtplet.afterCommand(DefaultFtplet.java:89) >>> at >>> org.apache.ftpserver.ftpletcontainer.impl.DefaultFtpletContainer.afterCommand(DefaultFtpletContainer.java:144) >>> at >>> org.apache.ftpserver.impl.DefaultFtpHandler.messageReceived(DefaultFtpHandler.java:220) >>> >>> The "unable to open data connection" is below if it helps: >>> 11 Feb 2011 16:15:30,977 DEBUG [pool-5-thread-1] >>> nativefs.impl.NativeFtpFile (NativeFtpFile.java:212) - Checking if >>> file exists >>> 11 Feb 2011 16:15:30,977 DEBUG [pool-5-thread-1] >>> nativefs.impl.NativeFtpFile (NativeFtpFile.java:218) - Authorized >>> 11 Feb 2011 16:16:45,931 DEBUG [pool-5-thread-1] command.impl.STOR >>> (STOR.java:134) - Exception getting the input data stream >>> java.net.ConnectException: Operation timed out >>> at java.net.PlainSocketImpl.socketConnect(Native Method) >>> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) >>> at >>> java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) >>> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) >>> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:432) >>> at java.net.Socket.connect(Socket.java:529) >>> at java.net.Socket.connect(Socket.java:478) >>> at >>> org.apache.ftpserver.impl.IODataConnectionFactory.createDataSocket(IODataConnectionFactory.java:314) >>> at >>> org.apache.ftpserver.impl.IODataConnectionFactory.openConnection(IODataConnectionFactory.java:259) >>> at org.apache.ftpserver.command.impl.STOR.execute(STOR.java:132) >>> at >>> org.apache.ftpserver.impl.DefaultFtpHandler.messageReceived(DefaultFtpHandler.java:210) >>> >>> This is very reproducible, so i can provide any other information that >>> may be helpful. >>> >>> I'm seeing similar behaviour directly from Windows FTP command-line shell. >>> >>> all other use cases (from Mac, from Windows FileZilla, etc work just fine) >>> >>> thanks! >>> >> >
