Community
Participate
Working Groups
IFileManagerExtended.deleteFile(String/FileIdentifierList) are asynchronous. The Test Project is seeing an odd behavior with: org.eclipse.hyades.execution.core.file.IFileManager.deleteFile(String) org.eclipse.hyades.execution.core.file.IFileManagerExtended.deleteFile(FileIdentifierList) It appears that these methods are asynchronous since some files still exist after the call returns. The work-around is to delay after the call to ensure all of the files are deleted. Shouldn't these methods be blocking like the putFile/getFile methods? See the /org.eclipse.hyades.test.core.tests/junit/harness/Test.Harness.JavaExecutionDeploymentAdapter.Test.testsuite for more details.
Note, this is blocking a Test Project JUnit/BVT test (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=303080).
I think this would be an enhancement, rather than a defect, given that the existing behaviour is as expected when it was written.
(In reply to comment #2) > I think this would be an enhancement, rather than a defect, given that the > existing behaviour is as expected when it was written. I disagree. The other IFileManagerExtended APIs are blocking so callers of this public API would expect that the IFileManagerExtended.deleteFile(String/FileIdentifierList) APIs to be the same. In addition, asynchronous APIs typically do not throw exceptions since there is no expectation of when the operation is executed. Albeit, this defect falls lower on the priority list.de
IMHO I don't think get/put versus delete are similar enough that we would necessarily expect their blocking behaviour to be the same. In comparison, the file transfer agent that was implemented for the new execution framework also has a non-blocking delete command. Similarly, the reason I feel it's expected/by design is because no changes have been made to the API or behaviour within the 5.5 years since the code was checked into CVS, despite the substantive use of many consumers.
If turns out that the problems with these APIs go beyond synchronicity. When running the /org.eclipse.hyades.test.core.tests/junit/harness/Test.Harness.JavaExecutionDeploymentAdapter.Test.testsuite test, the files slated for deletion using these APIs still exist in the file system. Please reconsider for TPTP 4.7.0.
Hi Paul, the problem you are reporting is because the test was written assuming that the deletes are blocking. As you can see, there are plenty of areas where a delete is immediately followed by an existence test: assertTrue(sourceFile.delete()); assertFalse(sourceFile.exists()); As you previously noted, a delay is required after the delete. When I added a 2 second sleep after the delete, I was able to run Test.Harness.JavaExecutionDeploymentAdapter.Test with no problems. It passed and exhibited the correct behaviour.
(In reply to comment #6) > Hi Paul, the problem you are reporting is because the test was written assuming > that the deletes are blocking. As you can see, there are plenty of areas where > a delete is immediately followed by an existence test: > > assertTrue(sourceFile.delete()); > assertFalse(sourceFile.exists()); > > As you previously noted, a delay is required after the delete. When I added a 2 > second sleep after the delete, I was able to run > Test.Harness.JavaExecutionDeploymentAdapter.Test with no problems. It passed > and exhibited the correct behaviour. Apologies Jonathan. After a closer inspection of the JUnit test (org.eclipse.hyades.test.core.tests.junit.TestHarnessJavaExecutionDeploymentAdapterTest), the assertion failure (assertFalse(sourceFile.exists())) causes the test case to terminate without deleting the temporary files. I have refactored the test to introduce a delay after the calls to IFileManagerExtended.deleteFile(String/FileIdentifierList) and added code to delete the temporary files.
Based on Paul's last comment, I'm not sure what exactly needs to be fixed at this point. Paul, please clarify.
(In reply to comment #8) > Based on Paul's last comment, I'm not sure what exactly needs to be fixed at > this point. > > Paul, please clarify. Sure. The following methods are asynchronous since some files still exist after the call returns: org.eclipse.hyades.execution.core.file.IFileManager.deleteFile(String) org.eclipse.hyades.execution.core.file.IFileManagerExtended.deleteFile(FileIdentifierList) This is a problem (albeit lower in priority) since the other IFileManagerExtended APIs are blocking so callers of this public API would expect that the IFileManagerExtended.deleteFile(String/FileIdentifierList) APIs to be the same. In addition, asynchronous APIs typically do not throw exceptions since there is no expectation of when the operation is executed.
Based on the current resource on the project, there's no plan to address this defect/enhancement.
Closing.
