I have been trying to get Rhino.Compute running but running into some issues when running it on a Windows Server. I have been getting an exception “Unable to start a local compute server” when I send a request to Rhino.Compute. Complete output of the log:
As a separate test I also started compute.geometry.exe up and was able to connect and execute endpoints, however because compute.geometry.exe appears to bill for uptime not for usage it’s not sustainable for us to keep the exe running outside of just verifying that it does work and our Rhino Token is valid.
Hi Daniel. Thanks for your inquiry. Looking at the top of the picture you provided, I can see that you’re launching the rhino.compute.exe manually. You don’t need to do this (assuming you’ve run the bootstrap script described here). Instead, whenever you start your VM, IIS will automatically get started. When IIS gets started, it will then automatically try to launch rhino.compute.exe. This is the parent program but when this is launched, you are not getting billed by McNeel (via core-hour billing). Rhino.compute.exe will wait for any incoming HTTP requests sent to it via IIS whenever it receives one on port 80. You will need to include the API key that you should have provided during the bootstrap process as part of the header in the HTTP request. So, once you send it a proper request with your API key, IIS will get it and forward it to rhino.compute.exe. Then, rhino.compute.exe will authenticate your request (checking the API key) and then look to see if there are any children processes of compute.geometry.exe already running. If not, it will start one up. Whenever an instance of compute.geometry.exe is started up… that’s when your core-hour billing will then kick in. So, the rhino.compute.exe will spin up a child process of compute.geometry.exe and then forward the request that it received on to the child. The child will then process the request and send the response back to you. If, after 1 hour (which is the default idlespan parameter) the rhino.compute.exe has not received any new authenticated requests, then it will automatically shut down any child processes that are currently running. This means you will then stop being billed by McNeel. The parent process will then stay up and listening for requests, but again, you aren’t billed until you actually send a properly authenticated request and the child compute.geometry.exe actually gets started.
So, long story short… I think you need to not manually launch the rhino.compute.exe process. Instead, simply restart your VM and let IIS launch everything for you. Ideally, you should be able to send a GET request to your VM URL (making sure you’re on port 80 and that you’ve included your API key in the header) to the endpoint /healthcheck and it should return a value of Healthy if all is working. You can then send another request to the endpoint /activeChildren which will return an integer showing you how many child processes are running. The first time, this will likely be zero but this endpoint will tell rhino.compute.exe to spin up the default number of children (which is set to 4) so if you send this again after a short amount of time (allowing the time to start 4 instances of rhino and grasshopper in the background) then this value should show something larger than zero (hopefully 4). Let me know if this helps.
I have tried running with IIS and it worked for a little while and then stopped, so I have been trying to run rhino compute through the console to get some logs because no logs were reported when using IIS. I assume that Rhino Compute running on IIS is pretty much the same as running it in the console as long as I supply the correct CLI arguments?
Yes, that is correct. Launching the rhino.compute.exe manually via the CLI is essentially the same as having IIS do it. If you look at the web.config file in the rhino.compute directory, you can look at the default settings/parameters for how IIS launches rhino.compute.exe.
