[MGNLBACKUP-34] Jackrabbit's node state serialization can lead to failures in content retrieving Created: 08/Jun/11  Updated: 29/Mar/22  Resolved: 22/Jun/11

Status: Closed
Project: Backup
Component/s: None
Affects Version/s: 1.1.2
Fix Version/s: 1.1.3

Type: Bug Priority: Critical
Reporter: Zdenek Skodik Assignee: Jan Haderka
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File log.txt    
Issue Links:
causality
supersession
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Team: Nucleus

 Description   

Imagine an use case that a backup is performed and its target folder renamed or removed afterwards.
With next repository request (content activation, dms file download, whatever) Jackrabbit tries to resolve such content from that (nonexistent for him) path (log is attached). Perhaps we shouldn't let him store the backup related state at all so that he'll be looking for the content in repository again.

As a workaround it's enough to restart the server. If it's not possible, you need to keep the original backup file in the original path for a while.



 Comments   
Comment by Nils Breunese [ 15/Jun/11 ]

Restarting the production servers every night is not a workable solution for us. Any idea how long 'a while' might be?

Comment by Nils Breunese [ 15/Jun/11 ]

We're considering using a symbolic link to point to the most recent backup, updating that link when a backup has run and then deleting the previous backup. Would that work or would we still have broken references to the older backup after deleting that?

Comment by Zdenek Skodik [ 15/Jun/11 ]

Probably till the next activity on the node so that new state is referred. Running new backup covers also this scenario, no references to the previous one should be in there.

@Jan, any chance we would include this to the incoming release of the module?

Comment by Jan Haderka [ 17/Jun/11 ]

@Nils: I think that should work fine. Just make sure you switch the link only after backup is done.

As to the cause of this, I think that once we serialize the item, it still stays in the JR in-memory cache and points to the data on the disk rather then DB/DataStore ... one possible solution would be to re-serialize item state again to the proper data source as manipulation of the JR cache is not possible.
I'll keep you posted on the progress.

Comment by Jan Haderka [ 22/Jun/11 ]

JR indeed modifies internal values of properties as part of the serialization process. We work around this by copying the values before and restoring the original internal values after serialization.

Comment by Nils Breunese [ 22/Jun/11 ]

Is this a Jackrabbit bug or feature? Is there a patch we can apply or do we need to wait for the next release?

Comment by Jan Haderka [ 23/Jun/11 ]

The code works properly from the JR point of view as replacing the internal value upon serialization is correct in case you have in-memory entry pointing to the temp file and you want to redirect it to the permanent storage upon saving.
It is not correct however in case of backup where we are doing basically the opposite.

As for the solution, you can just grab the snapshot of backup module and use it, but I would recommend to wait for few days. We are still looking into the ways to optimize the solution and make it less error prone in the future.

Once this issue is closed, we will release new version of the backup module. Pbly during next week.

Generated at Sun Feb 11 23:24:56 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.