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-23 10:58:34 -07:00
parent 87f73dd7b7
commit b0c4c88dbf
1 changed files with 6 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
Client-server-discovery-lifecycle.md

@ -13,6 +13,12 @@ How should the [server](https://github.com/sbt/sbt/wiki/Client-server-split) be
* Potentially controversial, but based on experience: operating system lockfile functionality tends to be platform-specific and flaky (e.g. not working on NFS/AFS, not working between threads, stuff like that), so avoid if possible. This is likely a main question (whether to use FileLock).
* There are more robust platform-specific solutions available, such as D-Bus on Linux, COM or window-based mechanisms on Windows, and launchd on Mac. These are likely a total pain in the ass to use from the JVM, though. Is there any sane-from-JVM way to do a reliable named lock?
## Concerns (possibly newly discovered)
1. Passing sys.props down from forked process to the server. Things like:
`-Dhttp.proxyHost`
`-Dsbt.version`
## Proposal 1: active.properties
This proposal is intended to "self-heal" and work in practice without asking users to kill processes or delete lockfiles - but nobody will call it elegant. The general idea is that a server suicides if the file pointing to that server is overwritten or deleted.