Hi Markos, nope, it was not something related to the worker being restarted.
Anyway, I think I could find a solution... we are using monit to monitor the status of the services, ftp service included. FTP monitoring was always behaving weirdly (not matching the real status of the service, for instance) so I thought about a possible "conflict" between the two and I tried to switch it off. After two weeks everything is working and I had not received any further complain from the customer so I guess it's working now :) To sum it up: looks like monit can break your FTP connection. I'll update this post as soon as I have more positive feedback on this. Thanks for your answer! S. On Sun, Mar 8, 2015 at 3:16 PM, Markos Gogoulos <[email protected]> wrote: > Hi Simone, > > is there a chance that the worker restarts during the upload and this > closes the connection? No idea if this could be related. Btw I just tried > uploading 10 small videos (<10Mb) through ftp and they all got uploaded. > Problem is they weren't picked by the transcodedaemon, something that Olof > from Sweden has also reported recently. I had to restart the worker and > press retranscode one or two times for them to be handled correctly by the > transcodedaemon... > > Cheers > > > > On Mon, Feb 23, 2015 at 12:52 PM, Simone Orsi <[email protected]> wrote: > >> Hi, >> >> sometimes the FTP server that rely on worker instance is really unstable. >> >> I just tried to upload video and while uploading it got 4 disconnections >> that were fortunately handled well and the upload resumed from where it >> stopped. >> >> After some minutes the connection went away again and didn't get up in >> time, so that Filezilla's log said: >> >> Status: Delaying connection for 5 seconds due to previously failed >> connection attempt... >> Status: Resolving address of ####### >> Status: Connecting to #######:21... >> Status: Connection attempt failed with "ECONNREFUSED - Connection >> refused by server". >> Error: Could not connect to server >> >> and ploneftp log said: >> >> []2.236.246.250:52364 Connected. >> 2.236.246.250:52364 ==> 220 pyftpdlib 0.7.0 ready. >> 2.236.246.250:52364 <== USER ##### >> 2.236.246.250:52364 ==> 331 Username ok, send password. >> 2.236.246.250:52364 <== PASS ****** >> authenticating to Zope FTP server 0.0.0.0:8021 >> with username ##### >> authenticated successfully with Plone FTP >> 2.236.246.250:52364 ==> 230 >> 2.236.246.250:52364 <== OPTS MLST >> type;perm;size;modify;unix.mode;unix.uid;unix.gid; >> 2.236.246.250:52364 ==> 200 MLST OPTS >> type;perm;size;modify;unix.mode;unix.uid;unix.gid; >> 2.236.246.250:52364 <== CWD / >> 2.236.246.250:52364 ==> 250 "/" is the current directory. >> 2.236.246.250:52364 <== PWD >> 2.236.246.250:52364 ==> 257 "/" is the current directory. >> 2.236.246.250:52364 <== TYPE I >> 2.236.246.250:52364 ==> 200 Type set to: Binary. >> 2.236.246.250:52364 <== PASV >> 2.236.246.250:52364 ==> 227 Entering passive mode >> (192,107,92,224,201,23). >> 2.236.246.250:52364 <== STOR millumino-test-upload.mp4 >> 2.236.246.250:52364 ==> 150 File status okay. About to open data >> connection. >> []@127.0.0.1:49417 Disconnected. >> ZopeHandler got a closed connection >> >> So, it seems that the zope instance (the worker in this case, as per >> plumi default setup) is closing the connection on the FTP port. >> >> We tried to increment the number of threads of this instance from 2 to 10 >> but it looks like it has no effects. >> >> What could cause this weird behavior in your experience? >> What can we do to debug this or to tweak our server setup in order to >> avoid this? >> >> Thanks in advance for any pointers :) >> >> Cheers, >> S. >> >> > > > -- > https://unweb.me > state of the art information systems >
_______________________________________________ Discuss mailing list [email protected] http://lists.plumi.org/listinfo/discuss
