Incident #171
closed
Recently updated file for gCubeApps/BlueBridgeProject Folder error
100%
Description
The portlet receives the following exception in the backend, I checked the scope for the storage service endpoint and is present.
[PORTAL] 439292456 [TP-Processor17] ERROR org.gcube.common.homelibrary.jcr.workspace.JCRWorkspaceItem - Error getPublicLinkForFolderItemId for item: 86524f1f-6958-491d-9bda-abf81a050fd9
org.gcube.common.homelibrary.home.exceptions.InternalErrorException: Sorry, The Public Link for selected file is unavailable
at org.gcube.common.homelibrary.jcr.workspace.JCRWorkspaceItem.getPublicLinkForFolderItemId(JCRWorkspaceItem.java:1310)
at org.gcube.common.homelibrary.jcr.workspace.JCRWorkspaceItem.getPublicLink(JCRWorkspaceItem.java:1263)
at org.gcube.portlets.user.lastupdatedfiles.server.FileServiceImpl.getLastUpdateFiles(FileServiceImpl.java:95)
Files
Updated by Pasquale Pagano over 10 years ago
- Priority changed from Urgent to Immediate
Updated by Valentina Marioli over 10 years ago
- Status changed from New to In Progress
Updated by Valentina Marioli over 10 years ago
- Assignee changed from Valentina Marioli to Roberto Cirillo
The file is in the storage, but it's not possible to download it.
Roberto, could you please check it?
Updated by Roberto Cirillo over 10 years ago
This is not exact: the metadata fields are stored in MongoDB but the file payload is missing.
Could I have more details about it?
This problem is happen for only one file? Or for a whole folder?
Could I have the history of this file?
Can this problem be reproduced?
I guess, If the problem is happened only for one file then it could be a MongoDB bug but if the problem is related to a whole folder maybe this is an "illegal" sequence of operations or a bug in storageManager/HomeLibrary libraries.
Updated by Valentina Marioli over 10 years ago
All the files in the folder "Old" are not available, they are 35 files.
Today the folder "Old" and other folders have been moved into "Proposal" folder by Leonardo, but jut "Old" is corrupt.
The missing files have been created in December 2014 and January 2015 and the last reading date was the 14th January 2015. So we don't know if before the moving the files were available.
I could not reproduce the problem. The remote path of a file is changed if the operation on the storage was successful.
We could ask Leonardo is something happened during the moving into "Proposal".
Updated by Roberto Cirillo over 10 years ago
I've attached the history of "Proposal" folder: I see at the same time a "cut" and an "add" operation of the "Old" folder. The "Old" folder is the corrupted folder. I guess it's not possible to move and move again the same folder (that have inside 35 files) in just one second. Maybe the "add" operation in the history, is another "move" operation in the folder "Proposal"
So, in this case, the first move operation has been overwrited by the second move operation and this probably has caused a data lost. I think that this behavior can be avoided if the Workspace refresh the tree folder only when the previous operation is completed, so in a synchronized way with the "Home Library" library
Updated by Roberto Cirillo over 10 years ago
- Priority changed from Immediate to Urgent
Updated by Roberto Cirillo over 10 years ago
- Priority changed from Urgent to High
- % Done changed from 0 to 90
All the files were restored from a mongoDB backup of 31 Jan 2015 except one:
BlueBRIDGE_Part_B_Sec1-3 20150113.docx
The file above is not present on backup. From history I don't see any operation on that file. I'm going to investigate about this
Updated by Roberto Cirillo over 10 years ago
- Status changed from In Progress to Paused
Updated by Pasquale Pagano over 10 years ago
why this activity has been paused? Are you waiting for feedback?
Updated by Roberto Cirillo about 10 years ago
No I wanted to recover another older backup but unfortunately we don't have a backup before the 31 January.
I've also better analyzed the actions performed on the file: "BlueBRIDGE_Part_B_Sec1-3 20150113.docx" (that is the only one missing). The problem seems to be the same.
From history, It seems another sequence of forbidden actions:
First, the file is cut from the BlueBridge folder and after few seconds the file has been removed from the BlueBrdge folder (without exceptions I suppose).
This sequence of actions it is not possible: if I cut a file X from a folder A (and paste it on the folder B) after few seconds I cannot remove the file X from the folder A because the file has been previously moved to the folder B.
Vale could you attach the history of the BlueBridge folder, please?
Updated by Valentina Marioli about 10 years ago
- File history.png history.png added
History of "BlueBRIDGE_Part_B_Sec1-3 20150113.docx" in attachment.
Updated by Roberto Cirillo about 10 years ago
The problem for "BlueBRIDGE_Part_B_Sec1-3 20150113.docx" file, has been identified:
if we try to move a file to another folder that contains another file with the same name, we receive an alert from WS because this operation is not allowed by HomeLibrary.
But if this happens, the HL first moves the file in the storage and after sends the alert to the workspace. As a result, in the Workspace the file remains in its original location while in the storage the file is transferred in the destination folder and conseguently, the payload in the original location is not available
Updated by Pasquale Pagano about 10 years ago
Ok, thanks. This issue is therefore related to a bud in the HL. I suggest to close this ticket and open a specific one for the HL to assign to Valentina.
Updated by Valentina Marioli about 10 years ago
- Status changed from Paused to Closed
- % Done changed from 90 to 100
