Task #11880
closedWorkspace in dev doesn't delete correctly the files stored on MongoDB when a delete from trash is performed
100%
Description
From dev workspace: https://next.d4science.org/group/next/workspace
The files deleted from trash are not deleted from MongoDB.
In production the delete operation works well.
For testing I've tried to put the production storage libraries on the dev portal but nothing change.
Please could you check?
Updated by Roberto Cirillo almost 7 years ago
I'm going to put the new storage libs on dev2. I could restore the storage production libraries if you need to do some tests.
Updated by Roberto Cirillo almost 7 years ago
I've also tried to put the HL libraries currently deployed on production portal but the behavior is the same.
Updated by Francesco Mangiacrapa almost 7 years ago
Hi Roberto,
the Workspace Portlet does not interact with Storage directly but through the HL component.
On dev and prod the snippet of (identical) code implemented by Worspace Portlet to empty the Trash is the following one:
WorkspaceTrashFolder trash = workspace.getTrash(); //The object 'WorkspaceTrashFolder' is from HL GWTWorkspaceBuilder builder = getGWTWorkspaceBuilder(); TrashContent result = new TrashContent(); switch (operation) { case EMPTY_TRASH: listErrors = trash.emptyTrash(); //[1] break; case RESTORE_ALL: listErrors = trash.restoreAll(); break; case REFRESH: default: result.setTrashContent(builder.buildGXTListTrashContent(trash)); return result; }
The method at point [1] is implemented by HL as following:
@Override public List<String> emptyTrash() throws InternalErrorException { logger.trace("Calling Empty Trash Servlet"); GetMethod getMethod = null; try { HttpClient httpClient = new HttpClient(); //System.out.println(servlets.get(ServletName.SAVE_CURRENT_VERSION).uri().toString() + "?" + ServletParameter.ID + "=" + id + "&" + ServletParameter.REMOTE_PATH + "=" + URLEncoder.encode(remotePath, "UTF-8") + "&" + ServletParameter.PORTAL_LOGIN + "=" + portalLogin); getMethod = new GetMethod(JCRRepository.servlets.get(ServletName.EMPTY_TRASH).uri().toString() + "?" + ServletParameter.PORTAL_LOGIN + "=" + workspace.getOwner().getPortalLogin()); TokenUtility.setHeader(getMethod); int response = httpClient.executeMethod(getMethod); // Check response code if (response != HttpStatus.SC_OK) throw new HttpException("Received error status " + response); } catch (Exception e) { logger.error("Error deleting item from trash ID " + getId(), e); throw new InternalErrorException(e); } finally { if(getMethod != null) getMethod.releaseConnection(); } return null; }
and HL seems to perform a HTT GET call to the servlet "EmptyTrash" and so on..
However, I tried to perform some tests:
First access to my WS performing the action "EMPTY" Trash (a lot of items were in the Trash), no changes appears (starting with 417 items, remaining 417 items). KO
Removed 3 files:
Removing just one item by the action "Delete Permanently". Starting with 417 items, remaining 416 items. OK
Emptying the whole Trash. Starting with 416 items, remaining 416 items. K0Removed 5 files:
Removing just two items by the action "Delete Permanently". Starting with 416 items, remaining 414 items. OK
Emptying the whole Trash. Starting with 414 items, remaining 411 items. OK
After the above tests, now performing the action "EMPTY" Trash the number of items decreases correctly.
Could the issue related to old items either existing in the Trash or saved in the Storage? It seems that removing new items the Storage statistics become right. If it is not the case, you and @lucio.lelii@isti.cnr.it should investigate starting from above HL method.
Updated by Roberto Cirillo almost 7 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
In order to reproduce your test, I've tried to delete my Trash directly by StorageManager libraries, after that, I've tried to upload and delete some files by workspace and now the files have been properly removed from my workspace.
So I think you are right: there was something blocking the HomeLibrary calls for deleting the trash.
I don't think it was a storageManager problem because the deleting operation performed by storageManager client has been successfully executed. I'm going yo close this ticket. Thanks.