search

facebook / buck

A fast build system that encourages the creation of small, reusable modules over a variety of platforms and languages.
https://buck.build
Apache License 2.0
8.56k stars 1.16k forks source link

Allow buck WebServer to choose between a range of ports rather than a single port #2094

Open kageiit opened 5 years ago

kageiit commented 5 years ago

There are use cases when there are multiple copies of a working repo on the same machine trying to use buck/ Multiple buck daemons are spawned in such cases and do not interfere with each other. The same can be done inside the IDE and buck intellij plugin does not leak state across repo clones. The buck webserver however currently supports only one port to bind to which creates issues when there are multiple repo copies. This feature request is to allow a range/list of ports to try to fallback on when binding the socket

kageiit commented 5 years ago

We are open to creating a PR for this. Thoughts from FB folks @styurin @ttsugriy ?

ttsugriy commented 5 years ago

isn't it sufficient to use automatic port selection? Buck is using Jetty under the hood and passing 0 should tell it to select a random port.

ttsugriy commented 5 years ago

This is the line that explains this https://phabricator.internmc.facebook.com/diffusion/BUCK/browse/master/src/com/facebook/buck/httpserver/WebServer.java;dfbc693ca0ee42c6f21929021a6d9d80e70d1ddd$71

and I believe something like buck server status --port can be used to get the actually assigned port.

kageiit commented 5 years ago

Using 0 causes the buck intellij plugin to crash with

null
java.lang.NullPointerException
    at org.eclipse.jetty.client.HttpClient.destinationFor(HttpClient.java:532)
    at org.eclipse.jetty.client.HttpClient.send(HttpClient.java:572)
    at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:727)
    at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:719)
    at org.eclipse.jetty.websocket.client.WebSocketUpgradeRequest.send(WebSocketUpgradeRequest.java:542)
    at org.eclipse.jetty.websocket.client.WebSocketUpgradeRequest.sendAsync(WebSocketUpgradeRequest.java:547)
    at org.eclipse.jetty.websocket.client.WebSocketClient.connect(WebSocketClient.java:401)
    at org.eclipse.jetty.websocket.client.WebSocketClient.connect(WebSocketClient.java:327)
    at org.eclipse.jetty.websocket.client.WebSocketClient.connect(WebSocketClient.java:309)
    at com.facebook.buck.intellij.ideabuck.ws.BuckClient.connectToWebServer(BuckClient.java:139)
    at com.facebook.buck.intellij.ideabuck.ws.BuckClient.access$200(BuckClient.java:33)
    at com.facebook.buck.intellij.ideabuck.ws.BuckClient$2.run(BuckClient.java:92)
    at com.intellij.openapi.application.impl.ApplicationImpl$1.run(ApplicationImpl.java:305)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
ttsugriy commented 5 years ago

hm, that looks like a bug in IntelliJ plugin which should probably be fixed :) cc @mkillianey

mkillianey commented 5 years ago

Yup, that NPE is a bug, but IIRC, I don't believe that it is caused by setting httpserver.port to 0; the problem is that ideabuck expects a buck daemon to be available, and if none has yet been started, ideabuck won't start one on its own. I believe the workaround (for now) is for the user to do anything that starts up their daemon before opening up their project in IntelliJ.

I don't believe we've (yet) articulated a strategy/policy as to what ideabuck features should or shouldn't be supported for developers who do not use a buck daemon. I'm sure some features degrade or are unusable, but I don't have a list off the top of my head; it's unclear to me how gracefully that happens.

A possible strategy might be to start a buck daemon if none it running, but it seems like it could be an overreach to assume that all developers are willing/able to run with a buck daemon.

ZacSweers commented 5 years ago

can the plugin just no-op itself? Or pick up the port from the specific project? This issue came up on our end because right now it is impossible to run two clones of the same project locally