Developing for Compute Server
With only a few exceptions, using Gurobi Compute Server requires no changes to your program. This section covers the exceptions. We'll talk about program robustness issues that may arise specifically in a Compute Server environment, and we'll give a full list of the Gurobi features that aren't supported in Compute Server.
Coding for Robustness
Client-server computing introduces a few robustness situations that you wouldn't face when all of your computation happens on a single machine. Specifically, by passing data between a client and a server, your program is dependent on both machines being available, and on an uninterrupted network connection between the two systems. The queuing and failover capabilities of Gurobi Compute Server can handle the vast majority of issues that may come up, but you can take a few additional steps in your program if you want to achieve the maximum possible robustness.
The one scenario you may need to guard against is the situation where
you lose the connection to the server while the portion of your
program that builds and solves an optimization model is running.
Gurobi Compute Server will automatically route queued jobs to another
server, but jobs that are running when the server goes down are
interrupted (the client will receive a
NETWORK error).
If you want your program
to be able to survive such failures, you will need to architect it in
such a way that it will rebuild and resolve the optimization model in
response to a NETWORK error. The exact steps for doing so are
application dependent, but they generally involve encapsulating the
code between the initial Gurobi environment creation and the last
Gurobi call into a function that can be reinvoked in case of an error.
Features Not Supported in Compute Server
As noted earlier, there are a few Gurobi features that are not supported in Compute Server. We've mentioned some of them already, but we'll give the full list here for completeness. You will need to avoid using these features if you want your application to work in a Compute Server environment.
The unsupported features are:
- Lazy constraints: While we do provide
MIPSOLcallbacks, we don't allow you to add lazy constraints to cut off the associated MIP solutions. - User cuts: The
MIPNODEcallback isn't supported, so you won't have the opportunity to add your own cuts. User cuts aren't necessary for correctness, but applications that heavily rely on them may experience performance issues. - Multi-threading within a single Gurobi environment: This isn't actually supported in Gurobi programs in general, but the results in a Compute Server environment are sufficiently difficult to track down that we wanted to mention it again here. All models built from an environment share a single socket connection to the Compute Server. This one socket can't handle multiple simultaneous messages. If you wish to call Gurobi from multiple threads in the same program, you should make sure that each thread works within its own Gurobi environment.
- Advanced simplex basis routines: The C routines that work with the simplex basis ( GRBFSolve, GRBBSolve, GRBBinvColj, GRBBinvRowi, and GRBgetBasisHead) are not supported.
