java.lang.Error: Maximum lock count exceeded about jena HOT 4 OPEN

Hi @awoestmann - could you give some context because the stacktrace isn't enough to investigate.

• What is the server configuration - the stack trace has DatasetImpl so is it some kind of configuration file setup.
• What operation of the server is this occurring at the time of the stacktrace?
• How is data loaded into this dataset?
• Is it HTTP/1 or HTTP/2 connections to the server?
• Are calling clients properly ending their closing their HTTP connections?

from jena.

Hi @afs,

thanks for quick reply.

I will try to give you some context:

What is the server configuration - the stack trace has DatasetImpl so is it some kind of configuration file setup.

I am not entirely sure what you mean here. We are creating the dataset using something like:

Dataset dataset = TDB2Factory.connectDataset("path/to/tdb/dir")

What operation of the server is this occurring at the time of the stacktrace?

At the time of the stacktrace the server is handling a request that should return the result of a sparql query. The error then occurs when we start the transaction to execute the query:

    dataset.begin(TxnType.READ);
    try {
      //Execute query and return result
    } finally {
      dataset.end();
    }

How is data loaded into this dataset?

Like mentioned above we are using TDB2Factory.connectDataset(String location) once when the REST-Controller is created.

Is it HTTP/1 or HTTP/2 connections to the server?

We only have HTTP/1 connections.

Are calling clients properly ending their closing their HTTP connections?

It looks like the connections are closed properly, we could not find any requests with connections that have been aborted before the response was sent.

from jena.

What is the server configuration - the stack trace has DatasetImpl so is it some kind of configuration file setup.

I am not entirely sure what you mean here. We are creating the dataset using something like:

Andy initially assumed that this was an issue with the Fuseki server provided by the project, likely because the potential related issue you referenced was specific to Fuseki.

Like mentioned above we are using TDB2Factory.connectDataset(String location) once when the REST-Controller is created.

Are you certain that is only gets created once? Depending on what REST framework you are using there's no guarantee that it doesn't create and destroy instances of your REST controller over the lifetime of your server, have you tried adding some logging to verify whether this is the case?

The REST framework used may be a pertinent detail here.

from jena.

Yes, I was assuming this was inside Fuseki because of the link to #1499.

TDB2Factory.connectDataset returns the same dataset on all calls for the same location. There's a computeIfAbsent cache.
There shouldn't be a need to create it more than once and keep an object reference.

Is the TDB2Factory.connectDataset always was same directory path?

I'm assuming that writes are not blocking before this problem is seen.

It looks like somewhere that is a code path which is not ending a read transaction code.
That's what was behind #1499.

from jena.