Because servers have to survive disgraceful shutdown anyway (crash, DOS,
server switched off, casters on the rack broken [1]), there isn't a
graceful procedure. "kill -9"
TDB has to be able to recover in any circumstances so that it what it
does. No graceful shutdown currently.
What resources of your custom dataset are there?
Andy
[1]
https://cloud.google.com/blog/products/management-tools/sre-keeps-digging-to-prevent-problems
On 26/03/2020 10:46, Nouwt, B. (Barry) wrote:
Hi everybody,
We are using embedded FusekiServer in our Java project and have extended Jena's
DatasetImpl class with additional features that require some cleanup when the
FusekiServer shuts down. This dataset is loaded into FusekiServer using a
config.ttl file, so we do not have a direct reference to this custom Dataset
object in our application.
To release these resources of our custom dataset, we implemented the Dataset.close() function, but it is not being called when we shutdown the FusekiServer using FusekiServer.stop().
Fuseki works in DatasetGraphs (DSGs). Dataset (usually) a wrapper to
give a different API.
As SPARQL goes down to the DSG dataset does do much for SPARQL.
I did find that the FusekiServer calls the DatasetGraph.close() function
instead, which is encapsulated by our KnowledgeDataset.
At what point does it call DatasetGraph.close()?
What is the best way to release the resources of our custom dataset
implementation? For now, I've added a shutdownhook to the JVM, but in my
opinion this is not very elegant.
Agreed. Even if there isn't an elegant way now (there maybe, there may
not), let's at least understand what it would take to add.
Thanks in advance!
Regards, Barry
