Dear Andy, Thanks for looking into this! I’ve added the relevant info to the GitHub issue.
Best regards, Samuel On 2024/02/07 20:41:49 Andy Seaborne wrote: > Recorded as https://github.com/apache/jena/issues/2254 > > On 06/02/2024 23:06, Andy Seaborne wrote: > > Hi Samuel, > > > > This is when the server exists for some reason? > > > > (If it's an internal exception, there should be a stack trace in the log > > file.) > > > > What operating system are you running on? > > > > What's in the new Data-0002 directory? > > > > It does look like some defensive measures are needed to not choose to > > use the incomplete storage directory. > > > > Andy > > > > > > On 06/02/2024 09:26, Samuel Börlin wrote: > >> Hi everybody, > >> > >> I recently noticed that when Fuseki (4.10.0) is stopped during a > >> compaction task (started via the HTTP endpoint > >> `/$/compact/{name}?deleteOld=true`) > >> then it uses the new and still incomplete database (e.g. Data-0002 > >> instead of the original non-compacted Data-0001) when it is started > >> again. > >> Is there a way to do compaction in an atomic manner so that this > >> doesn't happen? > >> > >> As a workaround I'm currently thinking about simply deleting (or > >> perhaps renaming/moving) all Data-XXXX directories but the one with > >> the lowest index when the database is started. > >> I always use `?deleteOld=true`, so I only ever expect there to be one > >> Data-XXXX directory when it starts. If there are multiple directories > >> then that means that there must have been an incomplete compaction. > >> Does this seem like a reasonable approach? > >> > >> Thanks and best regards, > >> Samuel > -- Samuel Börlin DaSCH - Swiss National Data and Service Center for the Humanities Engineering | Infrastructure | Infrastructure Engineer University of Basel Gewerbestrasse 24 CH-4123 Allschwil, Switzerland @: samuel.boerlin <mailto:[email protected]>@dasch.swiss <mailto:[email protected]> www: https://dasch.swiss <https://dasch.swiss/>
