You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by "Nouwt, B. (Barry)" <ba...@tno.nl.INVALID> on 2020/03/26 10:46:29 UTC
Graceful shutdown of FusekiServer
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(). I did find that the FusekiServer calls the DatasetGraph.close() function instead, which is encapsulated by our KnowledgeDataset.
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.
Thanks in advance!
Regards, Barry
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
RE: Graceful shutdown of FusekiServer
Posted by "Nouwt, B. (Barry)" <ba...@tno.nl.INVALID>.
I think we cannot build such a map. We let Fuseki load the dataset from an assembler config.ttl file. Therefore we do not have access to the custom Dataset object. This custom Dataset is created during the assembler process and disregarded by Fuseki when actually loading it, because it only needs its DatasetGraph.
Regards, Barry
-----Original Message-----
From: Andy Seaborne <an...@apache.org>
Sent: maandag 30 maart 2020 12:59
To: users@jena.apache.org
Subject: Re: Graceful shutdown of FusekiServer
You'll need to keep a map DatasetGraph->Dataset.
Fuseki only really knows about DatasetGraph.
Andy
On 30/03/2020 08:07, Nouwt, B. (Barry) wrote:
> Hi Andy, thanks for you elaborate reply. Regarding you example code; this does not (seem to) work because with that code, only the DatasetGraph.close() is called and not the Dataset.close() which we override. I think I'll stick with the shutdownhook of Java for now. Thanks for your advice. Regards, Barry
>
> -----Original Message-----
> From: Andy Seaborne <an...@apache.org>
> Sent: zondag 29 maart 2020 12:15
> To: users@jena.apache.org
> Subject: Re: Graceful shutdown of FusekiServer
>
> Hi Barry,
>
> Whatever you do, the overall distributed system has to deal with sudden shutdown of a server. Because it happens.
>
> One thing I've been wanting to do is dynamic restart - reread the configuration file while the server is running and gracefully switch over to the new configuration. Having a formal service lifecycle would be on the path to that.
>
> How are you finding the dataset?
>
> If you haven't found it, at the moment, you can find all the dataservices by walking the server setup:
>
> FusekiServer server = ...;
> server.getDataAccessPointRegistry().forEach((name,svc)->{
> svc.getDataService().shutdown();
> });
>
> Not beautiful, but, weakly, principled.
>
> This probably works after FusekiServer.stop has been called. The Fuseki server itself is still there untouched (current design), it is just that Jetty has stopped. There is going to be a timing issue if done before JettyServer.stop.
>
> Seem to be what is needed is FusekiServer shutdown hooks, one of which is DataService.shutdown() coupled with a grace period. Any mechanism needs to protect itself from faulty shutdowns that block for a long time.
>
> This is Fuseki-main which is Jetty specific and Jetty has mechanism for shutdown; I haven't investigated. Fuseki-full is a webapp for any webapp container server; it could tap into the end of the ServletContext in FusekiServerListener.
>
> Caution: as it is today, DataService.shutdown does a TDB expel if it can find a TDB dataset in nested datasets (e.g. text index). That throws the TDB DatasetGraph out of the system without ceremony.
>
> It is not thread safe. No transaction can be running at the time.
> It does not loose data. All caching is lost.
> It is really for testing.
> You can not reconnect to the database if running on MS Windows (long time Java bug).
>
> Andy
>
> On 27/03/2020 07:52, Nouwt, B. (Barry) wrote:
>> Hi Andy, thanks for your reply! Interesting read, that's some impressive digging indeed.
>>
>> I was wrong on the DatasetGraph.close() call, the FusekiServer.stop() method just calls JettyServer.stop(). I assumed it would close the DatasetGraph via the DataAccessPoint and the DataService.shutdown(), but it doesn't call DataService.shutdown() anywhere.
>>
>> Our custom dataset has registered itself to some external service and it would be nice if it would unregister itself before shutdown, but you are right that we should not rely on that and take measures on 'the other side' as well. The custom dataset also holds an Apache ActiveMQ instance with several subscriptions and a ExecutionService that we would like to clean up.
>>
>> What would be your advice? Should we not even try to shutdown gracefully using the shutdownHook and just take measures on the other side to detect the custom dataset is no longer available?
>>
>> Thanks again! Regards, Barry
>>
>>
>> -----Original Message-----
>> From: Andy Seaborne <an...@apache.org>
>> Sent: donderdag 26 maart 2020 17:12
>> To: users@jena.apache.org
>> Subject: Re: Graceful shutdown of FusekiServer
>>
>> 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-digg
>> ing-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
>> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
>>
Re: Graceful shutdown of FusekiServer
Posted by Andy Seaborne <an...@apache.org>.
You'll need to keep a map DatasetGraph->Dataset.
Fuseki only really knows about DatasetGraph.
Andy
On 30/03/2020 08:07, Nouwt, B. (Barry) wrote:
> Hi Andy, thanks for you elaborate reply. Regarding you example code; this does not (seem to) work because with that code, only the DatasetGraph.close() is called and not the Dataset.close() which we override. I think I'll stick with the shutdownhook of Java for now. Thanks for your advice. Regards, Barry
>
> -----Original Message-----
> From: Andy Seaborne <an...@apache.org>
> Sent: zondag 29 maart 2020 12:15
> To: users@jena.apache.org
> Subject: Re: Graceful shutdown of FusekiServer
>
> Hi Barry,
>
> Whatever you do, the overall distributed system has to deal with sudden shutdown of a server. Because it happens.
>
> One thing I've been wanting to do is dynamic restart - reread the configuration file while the server is running and gracefully switch over to the new configuration. Having a formal service lifecycle would be on the path to that.
>
> How are you finding the dataset?
>
> If you haven't found it, at the moment, you can find all the dataservices by walking the server setup:
>
> FusekiServer server = ...;
> server.getDataAccessPointRegistry().forEach((name,svc)->{
> svc.getDataService().shutdown();
> });
>
> Not beautiful, but, weakly, principled.
>
> This probably works after FusekiServer.stop has been called. The Fuseki server itself is still there untouched (current design), it is just that Jetty has stopped. There is going to be a timing issue if done before JettyServer.stop.
>
> Seem to be what is needed is FusekiServer shutdown hooks, one of which is DataService.shutdown() coupled with a grace period. Any mechanism needs to protect itself from faulty shutdowns that block for a long time.
>
> This is Fuseki-main which is Jetty specific and Jetty has mechanism for shutdown; I haven't investigated. Fuseki-full is a webapp for any webapp container server; it could tap into the end of the ServletContext in FusekiServerListener.
>
> Caution: as it is today, DataService.shutdown does a TDB expel if it can find a TDB dataset in nested datasets (e.g. text index). That throws the TDB DatasetGraph out of the system without ceremony.
>
> It is not thread safe. No transaction can be running at the time.
> It does not loose data. All caching is lost.
> It is really for testing.
> You can not reconnect to the database if running on MS Windows (long time Java bug).
>
> Andy
>
> On 27/03/2020 07:52, Nouwt, B. (Barry) wrote:
>> Hi Andy, thanks for your reply! Interesting read, that's some impressive digging indeed.
>>
>> I was wrong on the DatasetGraph.close() call, the FusekiServer.stop() method just calls JettyServer.stop(). I assumed it would close the DatasetGraph via the DataAccessPoint and the DataService.shutdown(), but it doesn't call DataService.shutdown() anywhere.
>>
>> Our custom dataset has registered itself to some external service and it would be nice if it would unregister itself before shutdown, but you are right that we should not rely on that and take measures on 'the other side' as well. The custom dataset also holds an Apache ActiveMQ instance with several subscriptions and a ExecutionService that we would like to clean up.
>>
>> What would be your advice? Should we not even try to shutdown gracefully using the shutdownHook and just take measures on the other side to detect the custom dataset is no longer available?
>>
>> Thanks again! Regards, Barry
>>
>>
>> -----Original Message-----
>> From: Andy Seaborne <an...@apache.org>
>> Sent: donderdag 26 maart 2020 17:12
>> To: users@jena.apache.org
>> Subject: Re: Graceful shutdown of FusekiServer
>>
>> 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-digg
>> ing-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
>> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
>>
Re: Graceful shutdown of FusekiServer
Posted by Andy Seaborne <an...@apache.org>.
List-Unsubscribe: <ma...@jena.apache.org>
(It is in the email header, not that email clients tend to show this
these days)
Also:
http://www.apache.org/foundation/mailinglists.html
Andy
On 30/03/2020 08:22, Sanjanaa Jeevandass wrote:
> I'd liked to be removed from this user group. Can someone please tell me the procedure.
>
> -----Original Message-----
> From: Nouwt, B. (Barry) <ba...@tno.nl.INVALID>
> Sent: Monday, March 30, 2020 12:38 PM
> To: users@jena.apache.org
> Subject: RE: Graceful shutdown of FusekiServer
>
> CAUTION: External email, Please do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> Hi Andy, thanks for you elaborate reply. Regarding you example code; this does not (seem to) work because with that code, only the DatasetGraph.close() is called and not the Dataset.close() which we override. I think I'll stick with the shutdownhook of Java for now. Thanks for your advice. Regards, Barry
>
> -----Original Message-----
> From: Andy Seaborne <an...@apache.org>
> Sent: zondag 29 maart 2020 12:15
> To: users@jena.apache.org
> Subject: Re: Graceful shutdown of FusekiServer
>
> Hi Barry,
>
> Whatever you do, the overall distributed system has to deal with sudden shutdown of a server. Because it happens.
>
> One thing I've been wanting to do is dynamic restart - reread the configuration file while the server is running and gracefully switch over to the new configuration. Having a formal service lifecycle would be on the path to that.
>
> How are you finding the dataset?
>
> If you haven't found it, at the moment, you can find all the dataservices by walking the server setup:
>
> FusekiServer server = ...;
> server.getDataAccessPointRegistry().forEach((name,svc)->{
> svc.getDataService().shutdown();
> });
>
> Not beautiful, but, weakly, principled.
>
> This probably works after FusekiServer.stop has been called. The Fuseki server itself is still there untouched (current design), it is just that Jetty has stopped. There is going to be a timing issue if done before JettyServer.stop.
>
> Seem to be what is needed is FusekiServer shutdown hooks, one of which is DataService.shutdown() coupled with a grace period. Any mechanism needs to protect itself from faulty shutdowns that block for a long time.
>
> This is Fuseki-main which is Jetty specific and Jetty has mechanism for shutdown; I haven't investigated. Fuseki-full is a webapp for any webapp container server; it could tap into the end of the ServletContext in FusekiServerListener.
>
> Caution: as it is today, DataService.shutdown does a TDB expel if it can find a TDB dataset in nested datasets (e.g. text index). That throws the TDB DatasetGraph out of the system without ceremony.
>
> It is not thread safe. No transaction can be running at the time.
> It does not loose data. All caching is lost.
> It is really for testing.
> You can not reconnect to the database if running on MS Windows (long time Java bug).
>
> Andy
>
> On 27/03/2020 07:52, Nouwt, B. (Barry) wrote:
>> Hi Andy, thanks for your reply! Interesting read, that's some impressive digging indeed.
>>
>> I was wrong on the DatasetGraph.close() call, the FusekiServer.stop() method just calls JettyServer.stop(). I assumed it would close the DatasetGraph via the DataAccessPoint and the DataService.shutdown(), but it doesn't call DataService.shutdown() anywhere.
>>
>> Our custom dataset has registered itself to some external service and it would be nice if it would unregister itself before shutdown, but you are right that we should not rely on that and take measures on 'the other side' as well. The custom dataset also holds an Apache ActiveMQ instance with several subscriptions and a ExecutionService that we would like to clean up.
>>
>> What would be your advice? Should we not even try to shutdown gracefully using the shutdownHook and just take measures on the other side to detect the custom dataset is no longer available?
>>
>> Thanks again! Regards, Barry
>>
>>
>> -----Original Message-----
>> From: Andy Seaborne <an...@apache.org>
>> Sent: donderdag 26 maart 2020 17:12
>> To: users@jena.apache.org
>> Subject: Re: Graceful shutdown of FusekiServer
>>
>> 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-digg
>> ing-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
>> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
>>
> ******************* CAUTION ******************* This e-mail is intended exclusively for the individual(s) to whom it is addressed and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, please notify the sender and delete the original message. Further, you are not to copy, disclose or disseminate this e-mail or the information contained to any other person and any such actions are unlawful. Zifo Technologies has taken every reasonable precaution to ensure that this e-mail and attachment(s) has been swept for viruses, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment(s). Zifo Technologies is neither liable for the proper and complete transmission of the information contained in this e-mail nor for any delay in its receipt. *************************************************
>
RE: Graceful shutdown of FusekiServer
Posted by Sanjanaa Jeevandass <Sa...@zifornd.com.INVALID>.
I'd liked to be removed from this user group. Can someone please tell me the procedure.
-----Original Message-----
From: Nouwt, B. (Barry) <ba...@tno.nl.INVALID>
Sent: Monday, March 30, 2020 12:38 PM
To: users@jena.apache.org
Subject: RE: Graceful shutdown of FusekiServer
CAUTION: External email, Please do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Andy, thanks for you elaborate reply. Regarding you example code; this does not (seem to) work because with that code, only the DatasetGraph.close() is called and not the Dataset.close() which we override. I think I'll stick with the shutdownhook of Java for now. Thanks for your advice. Regards, Barry
-----Original Message-----
From: Andy Seaborne <an...@apache.org>
Sent: zondag 29 maart 2020 12:15
To: users@jena.apache.org
Subject: Re: Graceful shutdown of FusekiServer
Hi Barry,
Whatever you do, the overall distributed system has to deal with sudden shutdown of a server. Because it happens.
One thing I've been wanting to do is dynamic restart - reread the configuration file while the server is running and gracefully switch over to the new configuration. Having a formal service lifecycle would be on the path to that.
How are you finding the dataset?
If you haven't found it, at the moment, you can find all the dataservices by walking the server setup:
FusekiServer server = ...;
server.getDataAccessPointRegistry().forEach((name,svc)->{
svc.getDataService().shutdown();
});
Not beautiful, but, weakly, principled.
This probably works after FusekiServer.stop has been called. The Fuseki server itself is still there untouched (current design), it is just that Jetty has stopped. There is going to be a timing issue if done before JettyServer.stop.
Seem to be what is needed is FusekiServer shutdown hooks, one of which is DataService.shutdown() coupled with a grace period. Any mechanism needs to protect itself from faulty shutdowns that block for a long time.
This is Fuseki-main which is Jetty specific and Jetty has mechanism for shutdown; I haven't investigated. Fuseki-full is a webapp for any webapp container server; it could tap into the end of the ServletContext in FusekiServerListener.
Caution: as it is today, DataService.shutdown does a TDB expel if it can find a TDB dataset in nested datasets (e.g. text index). That throws the TDB DatasetGraph out of the system without ceremony.
It is not thread safe. No transaction can be running at the time.
It does not loose data. All caching is lost.
It is really for testing.
You can not reconnect to the database if running on MS Windows (long time Java bug).
Andy
On 27/03/2020 07:52, Nouwt, B. (Barry) wrote:
> Hi Andy, thanks for your reply! Interesting read, that's some impressive digging indeed.
>
> I was wrong on the DatasetGraph.close() call, the FusekiServer.stop() method just calls JettyServer.stop(). I assumed it would close the DatasetGraph via the DataAccessPoint and the DataService.shutdown(), but it doesn't call DataService.shutdown() anywhere.
>
> Our custom dataset has registered itself to some external service and it would be nice if it would unregister itself before shutdown, but you are right that we should not rely on that and take measures on 'the other side' as well. The custom dataset also holds an Apache ActiveMQ instance with several subscriptions and a ExecutionService that we would like to clean up.
>
> What would be your advice? Should we not even try to shutdown gracefully using the shutdownHook and just take measures on the other side to detect the custom dataset is no longer available?
>
> Thanks again! Regards, Barry
>
>
> -----Original Message-----
> From: Andy Seaborne <an...@apache.org>
> Sent: donderdag 26 maart 2020 17:12
> To: users@jena.apache.org
> Subject: Re: Graceful shutdown of FusekiServer
>
> 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-digg
> ing-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
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
>
******************* CAUTION ******************* This e-mail is intended exclusively for the individual(s) to whom it is addressed and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, please notify the sender and delete the original message. Further, you are not to copy, disclose or disseminate this e-mail or the information contained to any other person and any such actions are unlawful. Zifo Technologies has taken every reasonable precaution to ensure that this e-mail and attachment(s) has been swept for viruses, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment(s). Zifo Technologies is neither liable for the proper and complete transmission of the information contained in this e-mail nor for any delay in its receipt. *************************************************
RE: Graceful shutdown of FusekiServer
Posted by "Nouwt, B. (Barry)" <ba...@tno.nl.INVALID>.
Hi Andy, thanks for you elaborate reply. Regarding you example code; this does not (seem to) work because with that code, only the DatasetGraph.close() is called and not the Dataset.close() which we override. I think I'll stick with the shutdownhook of Java for now. Thanks for your advice. Regards, Barry
-----Original Message-----
From: Andy Seaborne <an...@apache.org>
Sent: zondag 29 maart 2020 12:15
To: users@jena.apache.org
Subject: Re: Graceful shutdown of FusekiServer
Hi Barry,
Whatever you do, the overall distributed system has to deal with sudden shutdown of a server. Because it happens.
One thing I've been wanting to do is dynamic restart - reread the configuration file while the server is running and gracefully switch over to the new configuration. Having a formal service lifecycle would be on the path to that.
How are you finding the dataset?
If you haven't found it, at the moment, you can find all the dataservices by walking the server setup:
FusekiServer server = ...;
server.getDataAccessPointRegistry().forEach((name,svc)->{
svc.getDataService().shutdown();
});
Not beautiful, but, weakly, principled.
This probably works after FusekiServer.stop has been called. The Fuseki server itself is still there untouched (current design), it is just that Jetty has stopped. There is going to be a timing issue if done before JettyServer.stop.
Seem to be what is needed is FusekiServer shutdown hooks, one of which is DataService.shutdown() coupled with a grace period. Any mechanism needs to protect itself from faulty shutdowns that block for a long time.
This is Fuseki-main which is Jetty specific and Jetty has mechanism for shutdown; I haven't investigated. Fuseki-full is a webapp for any webapp container server; it could tap into the end of the ServletContext in FusekiServerListener.
Caution: as it is today, DataService.shutdown does a TDB expel if it can find a TDB dataset in nested datasets (e.g. text index). That throws the TDB DatasetGraph out of the system without ceremony.
It is not thread safe. No transaction can be running at the time.
It does not loose data. All caching is lost.
It is really for testing.
You can not reconnect to the database if running on MS Windows (long time Java bug).
Andy
On 27/03/2020 07:52, Nouwt, B. (Barry) wrote:
> Hi Andy, thanks for your reply! Interesting read, that's some impressive digging indeed.
>
> I was wrong on the DatasetGraph.close() call, the FusekiServer.stop() method just calls JettyServer.stop(). I assumed it would close the DatasetGraph via the DataAccessPoint and the DataService.shutdown(), but it doesn't call DataService.shutdown() anywhere.
>
> Our custom dataset has registered itself to some external service and it would be nice if it would unregister itself before shutdown, but you are right that we should not rely on that and take measures on 'the other side' as well. The custom dataset also holds an Apache ActiveMQ instance with several subscriptions and a ExecutionService that we would like to clean up.
>
> What would be your advice? Should we not even try to shutdown gracefully using the shutdownHook and just take measures on the other side to detect the custom dataset is no longer available?
>
> Thanks again! Regards, Barry
>
>
> -----Original Message-----
> From: Andy Seaborne <an...@apache.org>
> Sent: donderdag 26 maart 2020 17:12
> To: users@jena.apache.org
> Subject: Re: Graceful shutdown of FusekiServer
>
> 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-digg
> ing-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
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
>
Re: Graceful shutdown of FusekiServer
Posted by Andy Seaborne <an...@apache.org>.
Hi Barry,
Whatever you do, the overall distributed system has to deal with sudden
shutdown of a server. Because it happens.
One thing I've been wanting to do is dynamic restart - reread the
configuration file while the server is running and gracefully switch
over to the new configuration. Having a formal service lifecycle would
be on the path to that.
How are you finding the dataset?
If you haven't found it, at the moment, you can find all the
dataservices by walking the server setup:
FusekiServer server = ...;
server.getDataAccessPointRegistry().forEach((name,svc)->{
svc.getDataService().shutdown();
});
Not beautiful, but, weakly, principled.
This probably works after FusekiServer.stop has been called. The Fuseki
server itself is still there untouched (current design), it is just that
Jetty has stopped. There is going to be a timing issue if done before
JettyServer.stop.
Seem to be what is needed is FusekiServer shutdown hooks, one of which
is DataService.shutdown() coupled with a grace period. Any mechanism
needs to protect itself from faulty shutdowns that block for a long time.
This is Fuseki-main which is Jetty specific and Jetty has mechanism for
shutdown; I haven't investigated. Fuseki-full is a webapp for any
webapp container server; it could tap into the end of the ServletContext
in FusekiServerListener.
Caution: as it is today, DataService.shutdown does a TDB expel if it can
find a TDB dataset in nested datasets (e.g. text index). That throws
the TDB DatasetGraph out of the system without ceremony.
It is not thread safe. No transaction can be running at the time.
It does not loose data. All caching is lost.
It is really for testing.
You can not reconnect to the database if running on MS Windows (long
time Java bug).
Andy
On 27/03/2020 07:52, Nouwt, B. (Barry) wrote:
> Hi Andy, thanks for your reply! Interesting read, that's some impressive digging indeed.
>
> I was wrong on the DatasetGraph.close() call, the FusekiServer.stop() method just calls JettyServer.stop(). I assumed it would close the DatasetGraph via the DataAccessPoint and the DataService.shutdown(), but it doesn't call DataService.shutdown() anywhere.
>
> Our custom dataset has registered itself to some external service and it would be nice if it would unregister itself before shutdown, but you are right that we should not rely on that and take measures on 'the other side' as well. The custom dataset also holds an Apache ActiveMQ instance with several subscriptions and a ExecutionService that we would like to clean up.
>
> What would be your advice? Should we not even try to shutdown gracefully using the shutdownHook and just take measures on the other side to detect the custom dataset is no longer available?
>
> Thanks again! Regards, Barry
>
>
> -----Original Message-----
> From: Andy Seaborne <an...@apache.org>
> Sent: donderdag 26 maart 2020 17:12
> To: users@jena.apache.org
> Subject: Re: Graceful shutdown of FusekiServer
>
> 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
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
>
RE: Graceful shutdown of FusekiServer
Posted by "Nouwt, B. (Barry)" <ba...@tno.nl.INVALID>.
Hi Andy, thanks for your reply! Interesting read, that's some impressive digging indeed.
I was wrong on the DatasetGraph.close() call, the FusekiServer.stop() method just calls JettyServer.stop(). I assumed it would close the DatasetGraph via the DataAccessPoint and the DataService.shutdown(), but it doesn't call DataService.shutdown() anywhere.
Our custom dataset has registered itself to some external service and it would be nice if it would unregister itself before shutdown, but you are right that we should not rely on that and take measures on 'the other side' as well. The custom dataset also holds an Apache ActiveMQ instance with several subscriptions and a ExecutionService that we would like to clean up.
What would be your advice? Should we not even try to shutdown gracefully using the shutdownHook and just take measures on the other side to detect the custom dataset is no longer available?
Thanks again! Regards, Barry
-----Original Message-----
From: Andy Seaborne <an...@apache.org>
Sent: donderdag 26 maart 2020 17:12
To: users@jena.apache.org
Subject: Re: Graceful shutdown of FusekiServer
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
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
Re: Graceful shutdown of FusekiServer
Posted by Andy Seaborne <an...@apache.org>.
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