On Wed, 2010-03-03 at 17:32 -0500, Dan wrote: > That isn't exactly what we need since our clients aren't expecting any delay > and won't know to look for a .ok file (or other file trick). Also, right > after the upload they might want to download but of course the processing is > still running. > > We tried creating our own OutputStream that overrides the close() method to > do the processing but that triggers the client to upload again as it > timeouts waiting for a response > > On the surface it doesn't look like you can block effectively after an > upload since the client will timeout waiting in any case and then retry. > > Dan >
You only have 2 choices, sync or async processing. In sync processing you should start a 226 Reply, then do your procesing and end the 226 reply, for example: 200 Command PORT okay. 150 File status okay; about to open data connection. 226- Starting processing for file filename ... time consumes here Processing ok/Failed 226 Transfer complete. 5866 bytes received in 0.02 secs (365.6 kB/s) If you choose for async, you delegate to a thread who does the processing, and delete file if result was bad, but you loose control with a default FTP client. I haven't try yet but I will need it in a near future, and probably will choose both options depending on filesize, so if you find a solution let me know ;) Thanks.
