luke
/
sbt
mirror of https://github.com/sbt/sbt.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updated Client server discovery lifecycle (markdown)

Josh Suereth 2013-10-15 12:40:28 -07:00
parent 37113a7142
commit be27184c5b
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
Client-server-discovery-lifecycle.md

@ -105,8 +105,10 @@ The interface has two methods. One responsible for starting the Server, and ano
1. Obtaining the lock file for the CWD + AppConfiguratoin-hash pairing. (That is there can only be one server of a given configuration (organization + module id) in any working directory).
2. Reading the ServerPorts from the active configuration.
3. Checking to see if the old server is alive. If so, report these ports to the client (TODO - how?)
4. If the old server was not alive, start up a new server (fork + detach?). Write the new server bindings to the lock file.
3. Instantiating an instance of the ServerMain class denoted in the configuration.
3. Checking to see if the old server is alive using the ServerMain instance. If so, report these ports to the client (TODO - how?)
4. If the old server was not alive, start up a new server using the ServerMain instance. Write the new server bindings to the lock file and release the lock.
5. Notify the client (via stdout) what the bound ports are.
Port bindings come in java.net.URI, which includes an address, a protocol and a port. The server will actually also write down the PID (process ID) of the server (assuming it can obtain the pid). This enables clients to "kill rogue sbt server" directly.