Running SBT as a daemon
663 views
Skip to first unread message
Tomás Lázaro
Jan 14, 2012, 3:29:58 PM1/14/12
to simple-b...@googlegroups.com
Hi everyone,
I'm doing quite of a hack to have sbt as daemon and would like to know if there is a better way or if it can be added as a feature somehow
I use Netbeans to develop and use the netbeans-sbt to create de Netbeans project structure, that works pretty well. The thing is, Netbeans uses ant to issue commands like compile, clean, run, etc, like this:
<target description="Run a main class." name="run">
<exec executable="sbt" dir="path-to-project">
<arg value=";project desktop;run"></arg>
</exec>
</target>
It works great but every single time I compile or run a new vm and sbt instance has to be loaded and it takes time. So I started to work on a way to run sbt as a daemon.
This is what I did:
1) I created a way of piping the process input and output through my own application. So I created a really simple app in Java, called 'sbt-hack' that launches an instance of sbt in the current directory and connects it's System.in and System.out streams to the new sbt process. By doing that I was able to launch 'sbt-hack' instead of 'sbt' and it worked just as the regular sbt. All input and output was being channelled without trouble.
2) Then I added a server socket to receive input and channel it as if it was coming from System.in into the sbt process. That allowed me to send text to the running sbt-hack from a different Scala console and see it working as if I were typing it from the actual sbt console.
3) Added a pretty simple way of marking when an instance is running by creating a temporary file called ".sbt-hack-tmp" and wrote there the port the sbt-hack would listen to. Then when a second instance is opened it would only send data to the running sbt-hack instead of launching a second sbt instance.
So now I can open sbt-hack from the console as I would open regular sbt. Then from Netbeans instead of calling 'sbt' I changed the ant build into calling sbt-hack. That loads really fast, just sends the commands received by argument to the existing instance, like ";project desktop;run" and then closes itself. Thus I have sbt running as a daemon and can compile and run really fast.
If I were to leave partial text in the sbt prompt and issued a build from Netbeans all the text would mix up and fail. I also do not receive the report of the build, the ant task always thinks it succeeded. But I'm able to the the actual result on the one running instance of sbt so it's not that bad.
I'm also running the instance from a Terminal inside Netbeans itself so it really feels self contained and like an actual IDE :P.
So, what do you think? Is there be a prettier way of doing it? I'm kind of cheating since sbt is totally clueless about the whole hack.
Cheers
Tomás
I'm doing quite of a hack to have sbt as daemon and would like to know if there is a better way or if it can be added as a feature somehow
I use Netbeans to develop and use the netbeans-sbt to create de Netbeans project structure, that works pretty well. The thing is, Netbeans uses ant to issue commands like compile, clean, run, etc, like this:
<target description="Run a main class." name="run">
<exec executable="sbt" dir="path-to-project">
<arg value=";project desktop;run"></arg>
</exec>
</target>
It works great but every single time I compile or run a new vm and sbt instance has to be loaded and it takes time. So I started to work on a way to run sbt as a daemon.
This is what I did:
1) I created a way of piping the process input and output through my own application. So I created a really simple app in Java, called 'sbt-hack' that launches an instance of sbt in the current directory and connects it's System.in and System.out streams to the new sbt process. By doing that I was able to launch 'sbt-hack' instead of 'sbt' and it worked just as the regular sbt. All input and output was being channelled without trouble.
2) Then I added a server socket to receive input and channel it as if it was coming from System.in into the sbt process. That allowed me to send text to the running sbt-hack from a different Scala console and see it working as if I were typing it from the actual sbt console.
3) Added a pretty simple way of marking when an instance is running by creating a temporary file called ".sbt-hack-tmp" and wrote there the port the sbt-hack would listen to. Then when a second instance is opened it would only send data to the running sbt-hack instead of launching a second sbt instance.
So now I can open sbt-hack from the console as I would open regular sbt. Then from Netbeans instead of calling 'sbt' I changed the ant build into calling sbt-hack. That loads really fast, just sends the commands received by argument to the existing instance, like ";project desktop;run" and then closes itself. Thus I have sbt running as a daemon and can compile and run really fast.
If I were to leave partial text in the sbt prompt and issued a build from Netbeans all the text would mix up and fail. I also do not receive the report of the build, the ant task always thinks it succeeded. But I'm able to the the actual result on the one running instance of sbt so it's not that bad.
I'm also running the instance from a Terminal inside Netbeans itself so it really feels self contained and like an actual IDE :P.
So, what do you think? Is there be a prettier way of doing it? I'm kind of cheating since sbt is totally clueless about the whole hack.
Cheers
Tomás
Paul Phillips
Jan 20, 2012, 10:55:33 AM1/20/12
to simple-b...@googlegroups.com
2012/1/14 Tomás Lázaro <to...@belfrygames.com>
This is what I did:
1) I created a way of piping the process input and output through my own application. So I created a really simple app in Java, called 'sbt-hack' that launches an instance of sbt in the current directory and connects it's System.in and System.out streams to the new sbt process. By doing that I was able to launch 'sbt-hack' instead of 'sbt' and it worked just as the regular sbt. All input and output was being channelled without trouble.
2) Then I added a server socket to receive input and channel it as if it was coming from System.in into the sbt process. That allowed me to send text to the running sbt-hack from a different Scala console and see it working as if I were typing it from the actual sbt console.
Before you go any further...
% netcat -l -p 1776 -e sbt
# goes to other terminal on other side of world
% telnet localhost 1776
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Starting sbt: invoke with -help for other options
[info] Loading global plugins from /Users/paulp/.sbt/plugins
[info] Loading project definition from /repo/scala-improving/project
[info] Set current project to scala-improving (in build file:/repo/scala-improving/)
> compile
compile
[warn] Credentials file /Users/paulp/.ivy2/.credentials does not exist
[info] Updating {file:/repo/scala-improving/}scala-improving...
[info] Resolving org.scala-lang#scala-compiler;2.10.0-SNAPSHOT ...
[info] Resolving org.scala-lang#scala-library;2.10.0-SNAPSHOT ...
[info] Resolving javax.mail#mail;1.4.4 ...
[info] Resolving javax.activation#activation;1.1 ...
[info] Resolving org.scala-tools.testing#scalacheck_2.9.1;1.9 ...
[info] Resolving org.scala-tools.testing#test-interface;0.5 ...
[info] Resolving org.scala-tools.testing#specs_2.9.1;1.6.9 ...
[info] Done updating.
etc etc
Doug Tangren
Jan 20, 2012, 11:29:24 AM1/20/12
to simple-b...@googlegroups.com
Whoa. Awesome!
Tomás Lázaro
Jan 23, 2012, 11:30:42 AM1/23/12
to simple-b...@googlegroups.com
Thanks Paul, I new there had to be a more general way to do it. I'm having an issue though with that solution. The interactive command line doesn't work with auto-completion like sbt and my hackish wrapper do.
Anyway I was looking for a better way of doing it like harnessing an sbt API. Being able to queue jobs and know when those are finished as well as their results. Instead of just plain text hijacking.
Anyway I was looking for a better way of doing it like harnessing an sbt API. Being able to queue jobs and know when those are finished as well as their results. Instead of just plain text hijacking.
--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To post to this group, send email to simple-b...@googlegroups.com.
To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.
Jesus Gonzalez Vera
Nov 4, 2014, 4:40:35 PM11/4/14
to simple-b...@googlegroups.com
Dear friends,
I have a spray application on a linux server running over port 8090 but after few hours this process is killed unexpectly.
What could be happening?
Please, I would aprecciate your help. Thanks!
Ravinder Payal
Nov 6, 2017, 2:31:34 AM11/6/17
to simple-build-tool
Same happening with us for our Play Application.
Reply all
Reply to author
Forward
0 new messages