Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connection timeout #591

Closed
daaru00 opened this issue Nov 23, 2016 · 25 comments
Closed

Connection timeout #591

daaru00 opened this issue Nov 23, 2016 · 25 comments
Assignees

Comments

@daaru00
Copy link

daaru00 commented Nov 23, 2016

with the latest update (0.9.4) the connection frequently goes to timeout and when I save a file the connection will not reconnect in automatic (previous version did it).
Same problem when I change project or open new one.

I'm using Atom 1.11.2 on Linux Mint 18

@jimmaaay
Copy link
Collaborator

Are you using ftp or sftp?

@daaru00
Copy link
Author

daaru00 commented Nov 25, 2016

I'm using a ftp configuration

@QwertyZW
Copy link
Contributor

Probably should include your ftp daemon info here

@jimmaaay
Copy link
Collaborator

@daaru00 Could you open dev tools / inspector and paste the contents of the console when you have a timeout?

@jimmaaay jimmaaay added the bug label Nov 30, 2016
@daaru00
Copy link
Author

daaru00 commented Dec 1, 2016

570/home/fabio/.atom/packages/Remote-FTP/lib/client.js:347 < 200 NOOP command successful
/home/fabio/.atom/packages/Remote-FTP/lib/client.js:347 < 421 No transfer timeout (600 seconds): closing control connection
events.js:248 (node) warning: possible EventEmitter memory leak detected. 11 connected listeners added. Use emitter.setMaxListeners() to increase limit.addListener @ events.js:248once @ events.js:278onceConnected @ client.js [sm]:250upload @ client.js [sm]:502fileSaved @ remote-ftp.js [sm]:98module.exports.Emitter.simpleDispatch @ /usr/share/atom/resources/app.asar/node_modules/event-kit/lib/emitter.js:25module.exports.Emitter.emit @ /usr/share/atom/resources/app.asar/node_modules/event-kit/lib/emitter.js:129module.exports.TextBuffer.saveAs @ /usr/share/atom/resources/app.asar/node_modules/text-buffer/lib/text-buffer.js:1154module.exports.TextBuffer.save @ /usr/share/atom/resources/app.asar/node_modules/text-buffer/lib/text-buffer.js:1124module.exports.TextEditor.save @ text-editor.coffee:865module.exports.Pane.saveItem @ pane.coffee:627(anonymous function) @ pane.coffee:1module.exports.Pane.saveActiveItem @ pane.coffee:602module.exports.Workspace.saveActivePaneItem @ workspace.coffee:679commandRegistry.add.core:save @ register-default-commands.coffee:76module.exports.CommandRegistry.handleCommandEvent @ command-registry.coffee:256(anonymous function) @ command-registry.coffee:1module.exports.KeymapManager.dispatchCommandEvent @ /usr/share/atom/resources/app.asar/node_modules/atom-keymap/lib/keymap-manager.js:580module.exports.KeymapManager.handleKeyboardEvent @ /usr/share/atom/resources/app.asar/node_modules/atom-keymap/lib/keymap-manager.js:388module.exports.WindowEventHandler.handleDocumentKeyEvent @ window-event-handler.coffee:81(anonymous function) @ window-event-handler.coffee:1
events.js:252 console.trace()addListener @ events.js:252once @ events.js:278onceConnected @ client.js [sm]:250upload @ client.js [sm]:502fileSaved @ remote-ftp.js [sm]:98module.exports.Emitter.simpleDispatch @ /usr/share/atom/resources/app.asar/node_modules/event-kit/lib/emitter.js:25module.exports.Emitter.emit @ /usr/share/atom/resources/app.asar/node_modules/event-kit/lib/emitter.js:129module.exports.TextBuffer.saveAs @ /usr/share/atom/resources/app.asar/node_modules/text-buffer/lib/text-buffer.js:1154module.exports.TextBuffer.save @ /usr/share/atom/resources/app.asar/node_modules/text-buffer/lib/text-buffer.js:1124module.exports.TextEditor.save @ text-editor.coffee:865module.exports.Pane.saveItem @ pane.coffee:627(anonymous function) @ pane.coffee:1module.exports.Pane.saveActiveItem @ pane.coffee:602module.exports.Workspace.saveActivePaneItem @ workspace.coffee:679commandRegistry.add.core:save @ register-default-commands.coffee:76module.exports.CommandRegistry.handleCommandEvent @ command-registry.coffee:256(anonymous function) @ command-registry.coffee:1module.exports.KeymapManager.dispatchCommandEvent @ /usr/share/atom/resources/app.asar/node_modules/atom-keymap/lib/keymap-manager.js:580module.exports.KeymapManager.handleKeyboardEvent @ /usr/share/atom/resources/app.asar/node_modules/atom-keymap/lib/keymap-manager.js:388module.exports.WindowEventHandler.handleDocumentKeyEvent @ window-event-handler.coffee:81(anonymous function) @ window-event-handler.coffee:1

@TomS-
Copy link

TomS- commented Dec 9, 2016

Same problem here, when the FTP times out, trying to open a file or save a file will do nothing, rather than reconnecting. You have to manually reconnect by going to Packages -> Remote-FTP -> Connect.

@vitalijm
Copy link

< 421 Timeout (No operation for 1800 seconds)

@qbadev
Copy link

qbadev commented Jan 25, 2017

version 0.10.3, same problem. I set a 'keepalive' value to 5 minutes (300000ms), but received "No operation for 1800 seconds"
Edit
I found out that my ftp server (proftpd) does not accept NOOP message to keep connection alive. It must be a "list dir" command or any file transfer. Looks like it's not only Remote-FTP issue

@jpxd
Copy link
Collaborator

jpxd commented Feb 21, 2017

@jacobro Just out of curiosity, how did you find out?

@qbadev
Copy link

qbadev commented Feb 22, 2017

First I searched a phrase 'proftpd timeout'. Then went here: http://www.proftpd.org/docs/directives/linked/config_ref_TimeoutIdle.html.
Then I read at the bottom about TimeoutNoTransfer, so finally I went here: http://www.proftpd.org/docs/directives/linked/config_ref_TimeoutNoTransfer.html.
I have a VPS. I investigated my config: timeout value was set to 900 seconds.

Looks like connection timeout is not my issue, but, after disconnecting, automatic re-connect is a must, as mentioned here #349 and here #408.

@StefanBoettcherASMB
Copy link

< 200 NOOP command successfull but the error still occurs after a while (different ftp servers)

@steffnomidi
Copy link

< 421 Timeout (No operation for 1800 seconds)
This mistake is awful!
Sorry for my English please.

@fransstudio2
Copy link

Im a noob - but if the server cant have a keep alive connection or even maybe the router kill off any idle connection - cant remote ftp just run list_dir every 2 minutes or so?

I believe it would be much complicated than what i just describe, but just an idea :)

@qbadev
Copy link

qbadev commented Jun 22, 2017

@fransstudio2 i hope it is possible as probably it solves this major problem

@daaru00
Copy link
Author

daaru00 commented Jun 22, 2017

@fransstudio2 @jacobro there's a specific command for this purpose: NOOP (NO OPeration), can be used like a ping

@StefanBoettcherASMB
Copy link

NOOP seems to timeout after a while (see #591 (comment)). remote-ftp used to reconnect which doesn't work anymore.

@qbadev
Copy link

qbadev commented Jun 22, 2017

@daaru00 unfortunatelly noop cmd does not refresh connection session on my server which is running proFtpd on Debian 8 x64. Double checked that.

@daaru00
Copy link
Author

daaru00 commented Jun 22, 2017

I wonder, however, that making a list of folders can be a bit heavy, I thinking of a hundred folders to retrieve

@icetee
Copy link
Owner

icetee commented Jun 22, 2017

Check this commit: 3898805 (theoretically it has improved.)
Please wait for new Remote-FTP version!

@TomS-
Copy link

TomS- commented Jul 4, 2017

1.1.0 Still doesn't reconnect on save. This is still an issue, you still have to go to Packages -> Remote-FTP -> Connect. This resets where you are in the file tree.

@qbadev
Copy link

qbadev commented Jul 4, 2017

After recent update, I noticed that it reconnects while saving when a password is set in .ftpconfig. It worked even if RemoteFTP was telling that there is a 421 connection timeout. If a password was not set, reconnection was not working at all.

After newest update, nothing changed. Even setting a password in config does not make any diff.

IMHO it should store a password somehwere, it should do all the job in background. it should even reconnect when browsing a file tree.

@icetee icetee reopened this Jul 4, 2017
@TomS-
Copy link

TomS- commented Jul 5, 2017

I've just scan through the code to try figure out why this might not be working.
Is it possible that it should check the current connection status during "self.client.upload" and if the status is 421, then reconnect and atom.project.remoteftp.on('queue-changed') for files or folders being opened?

icetee added a commit that referenced this issue Jul 11, 2017
@icetee
Copy link
Owner

icetee commented Jul 11, 2017

@TomS- Has solved 1.1.3 version?

icetee added a commit that referenced this issue Jul 11, 2017
@TomS-
Copy link

TomS- commented Jul 12, 2017

@icetee can confirm 1.1.3 has fixed this

EDIT:
I had it where it displayed "<200 Zzz..." however, I couldn't open folders or save/open files. However this seemed to happen when I left it for hours.

@icetee
Copy link
Owner

icetee commented Aug 17, 2017

@toms I think the internet aborted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests