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

Mill Client-Daemon mode hanging in WSL2 Ubuntu 18.04 #874

Closed
lihaoyi opened this issue May 10, 2020 · 3 comments
Closed

Mill Client-Daemon mode hanging in WSL2 Ubuntu 18.04 #874

lihaoyi opened this issue May 10, 2020 · 3 comments
Milestone

Comments

@lihaoyi
Copy link
Member

lihaoyi commented May 10, 2020

As far as I can tell so far, this is because the following code that tries to get a file lock fails silently on WSL2 Ubuntu:

val raf = new java.io.RandomAccessFile("/home/ubuntu/hello", "rw")
val chan = raf.getChannel
val lock = chan.tryLock()

I can run this in two separate Ammonite REPLs and both of them will claim to successfully take the lock. In contrast, doing this on OS-X or a proper Ubuntu machine will have the second call to tryLock() return null.

This ends up confusing the client-server handshake, where the client waits for the server to claim the processLock to indicate that it is up and running: since the client always sees the lock as free, it thinks the server never starts and just hangs

Seems to be caused by this underlying issue: microsoft/WSL#1927

@edrevo
Copy link

edrevo commented Aug 14, 2020

Just FYI, according to microsoft/WSL#1927 (comment) locks are working fine in WSL2, so the root cause might be something else.

lefou added a commit that referenced this issue Feb 6, 2021
Various fixes only shown on Windows, probably also elsewhere.

* Fixed string stream writer/reader used for mill client-server communication, by using an explicit charset for byte conversion
* Avoid `java.nio.file.Paths.get(url.getFile())` in favour of `java.nio.file.Paths.get(url.toURI())` as the latter handles windows paths with leading drive letters well
* Improved CI setup for Windows
* Better run/spawn of Java sub-processes by selecting the same Java executable which is used by mill

We still have some CI failures on Windows, as we need some of these fixed in mill before we can benefit from it. Expect more PRs.

Probably related issues:
* #781
* #874
* #646
* #1098

Commits:

* CI: Added test on Windows

* Try a better handing of windows absolute paths
I hope to avoid a error like:
  Illegal char <:> at index 2: /D:/a/mill/mill/

* Improve string assertion message?

* More details in assertion error

* Use explicit charset for string-byte conversion

* Search java exe in same JAVA_HOME as mill is using

* CI: job deps

* check for Win

* Debug run java process

Pull request: #1146
@sake92
Copy link
Contributor

sake92 commented Aug 28, 2021

Seems to work now, maybe #1230 fixed it.. 😄

sake@DESKTOP-4KROVCU:/mnt/c/scala/mill/0.9.9/example-1$ ../mill-0.9.9.bat foo.compile
Preparing Java 11.0.11 runtime; this may take a minute or two ...
Compiling /mnt/c/scala/mill/0.9.9/example-1/build.sc
[26/26] foo.compile
[info] compiling 1 Scala source to /mnt/c/scala/mill/0.9.9/example-1/out/foo/compile/dest/classes ...
[info] done compiling
sake@DESKTOP-4KROVCU:/mnt/c/scala/mill/0.9.9/example-1$ ../mill-0.9.9.bat foo.run
[39/39] foo.run
Hello World

@lefou
Copy link
Member

lefou commented Dec 1, 2023

Probably fixed by #2901.

@lefou lefou closed this as completed Dec 1, 2023
@lefou lefou added this to the 0.11.7 milestone Dec 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants