Bugzilla – Full Text Bug Listing
| Summary: | [externalization] lost activity context after system crash | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Mik Kersten <mik.kersten> | ||||||
| Component: | Mylyn | Assignee: | Project Inbox <mylyn-triaged> | ||||||
| Status: | CLOSED MOVED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P2 | CC: | robert.elves, shawn.minto, steffen.pingel | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 240987 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Mik Kersten
Rob, you might want to check if the reading of the activity file ignore parsing errors. I remember that some changes were made to avoid logging of errors when the file was corrupted. Rob: you might just need to copy over the copy-and-move code due to the fact that we haven't yet extracted saving into commons. Committed activity snapshots. Any further improvements will need to happen for 3.1 and frequency being addressed on bug#236365. I just experience the loss again, running from HEAD. Same story with the crash: ThinkPad froze during sleep, I had to hard reset it. Task List and all else looked fine, but activity was lost. Updated to restore if file exists and length = 0. Please bootstrap when you get a chance. The problem here is that if sequentially a Task List or Activity rule is acquired, subsequently the root rule can be acquired without blocking. Lets pair on this today. Created attachment 106528 [details]
fix for concurrency issue
Updated and tested as per our discussion. Also added the conflict with root check to the task list scheduling rule. If this seems fine just commit it and we can work bootstrapped on this for a while.
Patch applied. I lost my task activity again. Looks like it happened on Sunday, since I only see activity for Monday and Tuesday. I've been working from HEAD. Reopening to make sure that this is fixed now? The bug was fixed yesterday. This happened to me again a few weeks ago. Probably after a hard reset, which I have not being doing muc lately. Both .activity.zip and activity.xml.zip were 441 bytes afterwards Had to manual restore from backup. [Fatal Error] :1:1621448: Attribute "EndDate" was already specified for element "InteractionEvent". [Fatal Error] :1:1621448: Attribute "EndDate" was already specified for element "InteractionEvent". Created attachment 117099 [details]
log
Haven't seen this problem in a long time. Moving to backlog... Rob, how are out of memory or other VM errors currently handled in the externalization participants? Is there a scenario where repeated failed attempts to save could cause good snapshots to be overridden with corrupt versions (see also bug 251473)? From my knowledge, this could happen as we don't have a way to validate that the snapshot or the file is not corrupt (which we should probably do before overwriting and saving the snapshot). If we add support for a verification check given a file, I think that there would be very little chance of corruption. Both have yet to be done. Validation of what is externalized and a pass through the code to ensure we handle the exceptions similarly to bug 251473. But before diving into validation we'll need to first consider it conjunction with the mechanism used to achieve bug#236365. Validation of the entire activity history with every append would not be practical. I'll gather these and other activity concerns and then schedule a design discussion. Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn |