Unexpected issue running bloop in docker and using it from outside

[dfarrel1]

I'm able to bring up a docker container and I can use bloop from within the container itself if I move my entire scala project in there, but I'd like to only serve bloop from the container, expose it on the same port and use it as my server while I develop locally.

Here's what I have:

Dockerfile:

ARG BASE_IMAGE_TAG
FROM openjdk:${BASE_IMAGE_TAG:-13.0.1-jdk-oraclelinux7}
# install bloop
RUN curl -L https://github.com/scalacenter/bloop/releases/download/v1.4.0-RC1/install.py | python
ENTRYPOINT [ "/root/.bloop/bloop", "server" ]

docker-compose.yml:

  bloop:
    image: <my-bloop-image>
    container_name: bloop-container
    ports:
      - "8212:8212"

then docker-compose up bloop

and from my local machine if I curl localhost:8212 I'm getting
curl: (52) Empty reply from server both in the case that I run my docker container and in the cast that I'm just running the bloop server locally, not in docker.

Which means to me that the port is exposed, the container is up, and bloop is behaving as similarly as I can tell from a quick smoke test.

However when running bloop about against the dockerized server I get:

Server disconnected unexpectedly: [Errno 54] Connection reset by peer

Where as bloop about against a locally running server outside of docker give me:
the expected:

bloop v1.4.0-RC1

Using Scala v2.12.8 and Zinc v1.3.0-M4+32-b1accb96
Running on Java JDK v1.8.0_232 (/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre)
  -> Supports debugging user code, Java Debug Interface (JDI) is available.
Maintained by the Scala Center (Jorge Vicente Cantero, Martin Duhem)

And running bloop about from within the same container that the server is running will give me the same thing:

bloop v1.4.0-RC1

Using Scala v2.12.8 and Zinc v1.3.0-M4+32-b1accb96
Running on Java JDK v13.0.1 (/usr/java/openjdk-13)
  -> Supports debugging user code, Java Debug Interface (JDI) is available.
Maintained by the Scala Center (Jorge Vicente Cantero, Martin Duhem)

Can someone give me some guidance about what might be causing the disconnect between my container and my local bloop implementation?

[jvican]

Thanks for the detailed ticket @dfarrel1. I'm not sure what could be causing that error. It might be an error with Python because you're using our current python nailgun client to talk to the server.

In the past months, we've worked on a new CLI that is built on GraalVM and https://github.com/jvican/snailgun, it's called bloopgun. Could you try running coursier launch ch.epfl.scala:bloopgun_2.12:latest.release -- about and see if it works? If it doesn't, run the same invocation with --nailgun-verbose to print some logs.

[dene-latch]

@jvican thanks for getting back to me. Before we delve deeper I just wanted to reiterate the basic scope of the problem to make sure our wires didn't get crossed at the start. I want to run a bloop server in a container and use it from outside of that container. I expect that this pattern might be helpful in normalizing development across teams and eventually hosting a shared bloop server if I understand this tool that I'm just starting to use. I haven't managed to see any example or documentation for this, but if you can point me towards something I'd gladly start from there. Is there no example or documentation for dockerizing and exposing bloop for use from outside of the container that it runs in?

[dene-latch]

here are the three results of using bloopgun as you outlined (in docker against itself, locally against docker, locally against local):

inside of docker against itself

bloop v1.4.0-RC1

Using Scala v2.12.8 and Zinc v1.3.0-M4+32-b1accb96
Running on Java JDK v12.0.1 (/usr/java/openjdk-12)
  -> Supports debugging user code, Java Debug Interface (JDI) is available.
Maintained by the Scala Center (Jorge Vicente Cantero, Martin Duhem)

locally against docker verbose

/usr/local/Cellar/bloop/1.4.0-RC1/bin/blp-coursier launch ch.epfl.scala:bloopgun_2.12:latest.release -- about --nailgun-verbose

debug: Sending arguments '' to Nailgun server
debug: Sending environment variables to Nailgun server
error: Unexpected error forces client exit!
java.net.SocketException: Broken pipe (Write failed)
        at java.base/java.net.SocketOutputStream.socketWrite0(Native Method)
        at java.base/java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:110)
        at java.base/java.net.SocketOutputStream.write(SocketOutputStream.java:129)
        at java.base/java.io.DataOutputStream.writeInt(DataOutputStream.java:200)
        at bloop.shaded.snailgun.protocol.Protocol.sendChunk(Protocol.scala:158)
        at bloop.shaded.snailgun.protocol.Protocol.$anonfun$sendCommand$2(Protocol.scala:95)
        at bloop.shaded.snailgun.protocol.Protocol.$anonfun$sendCommand$2$adapted(Protocol.scala:95)
        at scala.collection.immutable.HashMap$HashMap1.foreach(HashMap.scala:234)
        at scala.collection.immutable.HashMap$HashTrieMap.foreach(HashMap.scala:465)
        at scala.collection.immutable.HashMap$HashTrieMap.foreach(HashMap.scala:465)
        at bloop.shaded.snailgun.protocol.Protocol.sendCommand(Protocol.scala:95)
        at bloop.shaded.snailgun.TcpClient.run(TcpClient.scala:34)
        at bloop.bloopgun.BloopgunCli.executeCmd$1(Bloopgun.scala:262)
        at bloop.bloopgun.BloopgunCli.fireCommand(Bloopgun.scala:268)
        at bloop.bloopgun.BloopgunCli.run(Bloopgun.scala:224)
        at bloop.bloopgun.Bloopgun$.main(Bloopgun.scala:567)
        at bloop.bloopgun.Bloopgun.main(Bloopgun.scala)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at coursier.cli.launch.Launch$.$anonfun$launch$6(Launch.scala:116)
        at coursier.cli.launch.Launch$.$anonfun$task$28(Launch.scala:295)
        at coursier.cli.launch.Launch$.run(Launch.scala:356)
        at coursier.cli.Coursier$.$anonfun$runA$2(Coursier.scala:79)
        at coursier.cli.Coursier$.$anonfun$runA$2$adapted(Coursier.scala:67)
        at coursier.cli.CommandAppPreA.run(CommandAppPreA.scala:22)
        at caseapp.core.app.CommandAppWithPreCommand.$anonfun$main$5(CommandAppWithPreCommand.scala:98)
        at caseapp.core.app.CommandAppWithPreCommand.$anonfun$main$5$adapted(CommandAppWithPreCommand.scala:98)
        at scala.util.Either.fold(Either.scala:191)
        at caseapp.core.app.CommandAppWithPreCommand.$anonfun$main$3(CommandAppWithPreCommand.scala:98)
        at caseapp.core.app.CommandAppWithPreCommand.$anonfun$main$3$adapted(CommandAppWithPreCommand.scala:84)
        at scala.Option.foreach(Option.scala:274)
        at caseapp.core.app.CommandAppWithPreCommand.main(CommandAppWithPreCommand.scala:84)
        at coursier.cli.Coursier.main(Coursier.scala)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at coursier.bootstrap.launcher.a.a(Unknown Source)
        at coursier.bootstrap.launcher.Launcher.main(Unknown Source)
debug: Waiting for stdin thread to finish...
debug: Waiting for heartbeat thread to finish...
debug: Returning exit code...
debug: Return code is 1

locally against local installation of bloop

bloop v1.4.0-RC1

Using Scala v2.12.8 and Zinc v1.3.0-M4+32-b1accb96
Running on Java JDK v1.8.0_232 (/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre)
  -> Supports debugging user code, Java Debug Interface (JDI) is available.
Maintained by the Scala Center (Jorge Vicente Cantero, Martin Duhem)

[jvican]

Yes, I confirm we're on the same page here, I think I've understood your issue correctly.

I want to run a bloop server in a container and use it from outside of that container. I expect that this pattern might be helpful in normalizing development across teams and eventually hosting a shared bloop server if I understand this tool that I'm just starting to use

Bloop is a great tool to normalize development across teams. Note that if you reuse one bloop server from different workstations, you will experience long incremental compilations and possibly correctness issues, as the incremental compiler might have some bugs and the compilations you trigger from the different workstations are different in non-trivial ways. In such cases, every compilation you make in bloop will trigger a long incremental compile. I recommend using bloop as a local resident server in one workstation, rather than trying to reuse one server across many workstations.

Is there no example or documentation for dockerizing and exposing bloop for use from outside of the container that it runs in?

No, we haven't had this use case yet, people are running bloop automatically in the background (or another tool, like Metals, is), and a Docker setup for Scala development is not common.

It looks like the issue you ran into is legit, and I don't know where that "Broken pipe" is coming from, but I would expect that you can reproduce it outside of bloop since I don't think we're doing anything fancy when talking to clients via TCP. What does the internet say? Could this be an issue with the JVM<>Docker integration?

[jvican]

@dfarrel1 Let me know if you follow up on this. I'm curious to find a solution.

[gregghz]

fwiw, i've hit this same issue on both a macos host and a linux host.

[DylanArnold]

Same issue here. I think this could be because the server is listening on 127.0.0.1 but may need to listen on 0.0.0.0 for docker to port forward correctly.

I'm trying to change the listen address to test but haven't figured out how yet. Does anyone know how?

[jvican]

Yes, that's a good hint @DylanArnold, I think that's what's happening. Bloop decides the listening address that forwards to Nailgun here. Usually, the launcher is the piece running the server, so if we want to make the address configurable we would need to add an option there and propagate it all the way to the server. The server already accepts an argument to customize the local address it listens to, so the change should only be done in the launcher.

However, I think changing the launcher might be too much, so I would recommend that someone changes the lines I linked above to detect a docker environment. If bloop runs in a docker environment, it's safe to listen on 0.0.0.0 instead of the loopback address.