Java Interface: ERROR: No Gurobi license found

[Phillip]

Dear all,

I have have made excellent experiences with Gurobi. It is a great
tool. Recently, there appears a strange problem though.

I am using Gurobi with academic license.
I control Gurobi via the Java interface.
I start the solver 2800 - 3000 times per hour with different problem
(*.mps) files.

The academic license is valid until March 2011.

However, today the solver stopped every 2 to 3 hours. The Java console
told me: "ERROR: No Gurobi license found".

How can that be?

Thanks a lot in advance for your advice!
Phil

[Greg Glockner]

Since it runs for a while then stops intermittently, our best guess is that this involves Java memory management. See the section titled "Memory Management" in:

http://www.gurobi.com/doc/30/refman/node201.html

Additionally, if you are solving all these models within the same process, it is recommended to use the same GRBEnv object, instead of creating a separate GRBEnv object for each model.

[Phillip Kriett]

Thanks a lot!!!

The additional advice about the GRBEnv object brought the relieve.

Phil

[Phillip Kriett]

Dear Support,

I have replicated the exact same experiment on a different machine.

- Academic license is still valid
- the solver starts 2800 - 3000 times per hour with different problem
(*.mps) files.
- Unused GRBModel are set to null and System.gc() is properly used.
- A separate GRBEnv object is used for each problem instance and set
to null simultaneously with GRBModel objects
- Java VM Option: -Xmx1024m

And still, after 2 - 3 hours, operation stops and I see these error
messages in the output window of Netbeans:
Optimal solution found (tolerance 1.00e-04)
Best objective 4.8359136968e+02, best bound 4.8354795606e+02, gap 0.0090%
gurobi.GRBException: Unable to write to file 'C://*.sol'

Then java creates another problem instance and tries to call Gurobi
solver another time. Gurobi solver's answer is:
ERROR: No Gurobi license found (user *, host *, *)

What can be the reason that writing a solution file fails suddenly?

Thank you so much and best regards,
Phillip

On Sat, Aug 21, 2010 at 2:16 AM, Greg Glockner <gloc...@gurobi.com> wrote:

[Ed Rothberg]

> gurobi.GRBException: Unable to write to file 'C://*.sol'

It is exhausting some resource. It is probably hitting a limit on the
number of open files, although you should check to see if it is
running out of memory or disk space.

Is your program writing any other files? My guess is that some of
them aren't being closed. I don't think it is us that is leaving the
files open, but we can investigate if you believe it is.

Ed

[Phillip Kriett]

Ed,

Thanks for the quick response.

I double checked:
There is >500 Gig diskspace available.
Less than 3 Gig out of 4 Gig Memory in use at the time of the crash
(64 bit system)
All BufferedReaders are closed.
All BufferedWriters are flushed and closed.

I also call the GLPK package periodically to write MPS files. The
error comes from Gurobi though when Gurobi shall write the *.sol file.

Why does Gurobi come with a "No License" error as a subsequent error
of the "gurobi.GRBException: Unable to write to file" ?
Do I have to synchronize Gurobi with some Java thread?
What other limited resource could I check?

Many thanks!!!
Phillip

[Phillip Kriett]

Ed,

This is the code of the method that solves a problem and writes the
solution. After writing the solution, I check whether the solution
file has been created. If no, the very same method is called one more
time with the exact same parameter setting.

This is what happens, when the error occurs:
1. guMo.write() throws exception Error Code:10013
2. solveAndWriteSolutionWithGurobi returns FALSE
3. solveAndWriteSolutionWithGurobi is called one more time
4. guMo.optimize() throws exception Error Code:10009

Why does guMo.optimize() fail to obtain a valid license?

Thank you very much for you help!
Phillip

boolean solveAndWriteSolutionWithGurobi(String
gurobiLogFileOutputPath, String mpsFileInputPath, String
solutionFileOutputPath) {

try {

GRBEnv grbEnv = new GRBEnv(gurobiLogFileOutputPath);
GRBModel guMo = new GRBModel(grbEnv, mpsFileInputPath);
guMo.optimize();
guMo.write(solutionFileOutputPath);
grbEnv = null;
guMo = null;

} catch (GRBException e) {
System.out.println(e.toString());
}

if (checkIfFileExists(solutionFileOutputPath)) {
return true;
} else {
return false;

[Ed Rothberg]

> Why does Gurobi come with a "No License" error as a subsequent error
> of the "gurobi.GRBException: Unable to write to file"?

My guess is that they are caused by the same underlying issue. Once
you are unable to write a (solution) file, you are probably also going
to be unable to read a (license) file.

> What other limited resource could I check?

Memory and file descriptors are the two that seem most likely.


We have a few Java stress tests that test generally similar things.
We'll look at modifying one to more closely resemble your usage, to
see if we can induce the failure you are seeing.


Ed

[Ed Rothberg]

> We have a few Java stress tests that test generally similar things.
> We'll look at modifying one to more closely resemble your usage, to
> see if we can induce the failure you are seeing.

I think we've figured out what's going on. Could you try running the
same test without creating a Gurobi log file (using the GRBEnv
constructor that takes no argument)? That will most likely not run
into the issue.

It looks like the problem is that each environment has it's own log
file, and these files are staying open until the environment is
reclaimed. The result is that it is running out of file descriptors.
We can't rely on garbage collection to reclaim these in a timely
manner. We'll need to extend the interface to give more direct
control over when these are released.

Ed