Floating licenses have a use limit, which is enforced by monitoring when tokens are issued/released. If all tokens are in use, any application attempting to use Gurobi to solve optimization problems will get the error “Request denied: use limit (N) exceeded”.
Compute Server and Instant Cloud are based on the client-server paradigm. As such, optimization jobs are issued to the optimization server by clients. Users may observe that a job is still running, even after the optimization task has finished.
One reason for the situations described above is that the user forgot to dispose of all models and environments at the end of the session. The steps to do so vary by programming language:
- C: Call GRBfreemodel() for each model, then call GRBfreeenv() for the Gurobi environment.
- C++: If you use pointers to GRBModel and GRBEnv objects, delete all GRBModel objects, then delete the GRBEnv object.
- .Java: Call GRBModel.dispose() on all GRBModel objects, then call GRBEnv.dispose() on the GRBEnv object.
- .NET: Call GRBModel.Dispose() on all GRBModel objects, then call GRBEnv.Dispose() on the GRBEnv object.
-
Python:
- Please refer to How do I manage Gurobi environments in gurobipy? to learn how to manage Gurobi environments using context managers. This is our recommended way. Otherwise:
- For Gurobi 9.0.0 or newer: Call Model.dispose() on all Model objects. Then, if using custom-made environments, call Env.dispose() on all Env objects. Otherwise, call disposeDefaultEnv().
- For Gurobi 8.1.1 or older: Delete all Model objects, delete all Env objects (if used), then call disposeDefaultEnv().
If you neglect to do this cleanup, the token or service may be temporarily unavailable for other applications.
Running multiple models in sequence
When Gurobi is running locally, creating an environment will obtain a license, and disposing of the environment will release that license. When running Gurobi on a remote server, starting an environment will start a job on the server, and the disposing of the environment will end that job. Therefore, creating an environment incurs an overhead cost which can be as small as a quick license check in the case of running Gurobi locally or as big as spinning up a new machine in case of running Gurobi remotely.
When solving many models sequentially, it may be better to use a single Gurobi environment to avoid paying the overhead cost multiple times. For an example, see How do I manage Gurobi environments in gurobipy?.