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 times out when connecting to a running docker container, but the same works on Calva and lein CLI (among others) #2769

Closed
setzer22 opened this issue Dec 12, 2019 · 4 comments

Comments

@setzer22
Copy link

setzer22 commented Dec 12, 2019

I am having trouble when connecting cider to a docker container deployed using docker swarm. The port from the container is forwarded to the host, so to cider, it all sould look as if connecting to a regular localhost repl. However, it appears that cider-connect timeouts on its first nrepl request.

There are some important things to consider:

  • I am only able to reproduce this when deploying my containers using docker swarm. If I use regular docker commands it all works as expected.
  • I have no trouble whatsoever connecting to the same repl (running inside swarm) when using either Calva (the VS Code clojure plugin), or lein connect from a terminal. This is especially puzzling: What are all other editors doing differently than cider/emacs to connect to the repl? This also hints that this is likely not a networking issue with docker containers.
  • Other teammates could not replicate this issue (they can connect in both kinds of docker containers just fine). So there must be some hidden factors I'm not taking into account in my setup.
  • When killing the docker container after having attempted a cider-connect I get a "connection broken by remote peer" message, hinting that the connection was at least partially established.

Expected behavior

cider-connect is able to connect to a running nrepl server inside a docker container deployed using docker swarm, with a port mapping to the host for the nrepl port.

Actual behavior

After specifying host and port, the cider-connect command hangs until timeout.

Steps to reproduce the problem

  1. Start a docker container, which in turn starts an nrepl server in port 35000 (actual port number does not matter).
  2. Run cider-connect in emacs.
  3. Introduce host "localhost" and port "35000"
  4. Cider hangs. After 10 seconds, the message "nREPL Sync request timeout failed" is printed to the Messages buffer.

Of course, as already stated, this may not be so simple to reproduce, as some of my teammates are not able to do so. However, any help with debugging this will be much appreciated.

Environment & Version information

CIDER version information

;; CIDER 0.24.0snapshot (package: 20191211.1133), nREPL 0.6.0

Lein/Boot version

Leiningen 2.9.1 on Java 13.0.1 OpenJDK 64-Bit Server VM

Emacs version

26.3

Operating system

Manjaro Linux

EDIT: I would also like to add that I tested all this in a freshly installed spacemacs, so apart from what spacemacs' clojure layer may be configuring, I have not done any additional configuration of my own. My ~/.lein/profiles.clj is also empty.

@bbatsov
Copy link
Member

bbatsov commented Jan 26, 2020

@dpsutton is our resident docker expert. I don't use it much, so I can't comment on this.

@bbatsov bbatsov added the bug label Feb 22, 2020
@setzer22
Copy link
Author

Some progress: I've finally been able to find some time to try isolate this issue. I created two separate virtual machines, one running ubuntu 18.04, the other Manjaro GNOME (latest version, as of today). I installed the same emacs version (26.3) in each distro and ran my docker container in swarm mode.

I was able to reproduce my issue in the Manjaro VM, but not in the Ubuntu one. I made sure the version of docker and emacs were the same, so that may indicate that some system libraries may be causing a bad interaction between cider, emacs and docker running in swarm mode.

Any ideas of what could be going on?

@stale
Copy link

stale bot commented Jun 16, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!

@stale stale bot added the stale label Jun 16, 2020
@stale
Copy link

stale bot commented Jul 16, 2020

This issues been automatically closed due to lack of activity. Feel free to re-open it if you ever come back to it.

@stale stale bot closed this as completed Jul 16, 2020
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

2 participants