Rajiv,
So it's happened once?
I suspect the process exited and the message would have been on stderr,
which is not send to the log4j log.
I don't know how you are running it as a service but the script in the
distributuion sends stderr to a file called 'stderrout.log'
Andy
On 04/02/14 18:21, Chaudhuri, Rajiv wrote:
Hi Andy,
I checked whether fuseki process was running or not when customer reported
that data was not displaying at UI and found that Fuseki process was no
more running after performing the scheduled backup during peak load and I
had to start the Fuseki server again.
Regards,
Rajiv
On Tue, Feb 4, 2014 at 1:04 PM, Andy Seaborne <[email protected]> wrote:
On 04/02/14 15:33, Chaudhuri, Rajiv wrote:
Hi Andy,
The process gets killed- So it stops permanently.
I don't understand - does some other process kill it, or does it exit (if
so, with what exit code?)
Andy
Regards,
Rajiv
On Tue, Feb 4, 2014 at 10:30 AM, Andy Seaborne <[email protected]> wrote:
On 04/02/14 13:28, Chaudhuri, Rajiv wrote:
Hi,
We are taking Fuseki dataset backup on daily basis and we have
configured
this backup process at cronjob.
When should we take the backup-
1. During off time
Or
2. During peak time- Will it cause any issue if we consider the
concurrency
and data corruption?
We have found Fuseki stop responding (with no error log at all) during
peak
time and during this time our backup process was also triggered.
Our data file directory size-
300 MB
and backup (nq.gz) file size is 7.6 MB
What do you recommend? What is the suitable time to take the backup of
Fuseki dataset?
A backup, if you're calling the Fuseki server backup function, is a
read-transaction. A writer can be active at the same time but if there
are
many updates, it accumulates waiting for the DB to become free for the
main
DB files to be updated from the journal.
If you have a frequent update load, then off-peak is better but it should
all work.
What do you mean by "stop responding" - permanently or for the duration
of
the backup?
Andy
