[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: |
|
||||||||
| Issue Links: |
|
||||||||
| 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: | |||||||||
| Description |
|
Imagine an use case that a backup is performed and its target folder renamed or removed afterwards. 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. |
| 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. 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. |