Bugzilla – Full Text Bug Listing
| Summary: | PublishHelper 'hangs' during publish | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP ServerTools | Reporter: | Tim deBoer <deboer> | ||||
| Component: | wst.server | Assignee: | Elson Yuen <eyuen7> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Elson Yuen <eyuen7> | ||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | cbridgha, eyuen7, neil.hauge | ||||
| Version: | 3.2 | Flags: | eyuen7:
pmc_approved?
(david_williams) eyuen7: pmc_approved? (raghunathan.srinivasan) eyuen7: pmc_approved? (naci.dai) neil.hauge: pmc_approved+ eyuen7: pmc_approved? (kaloyan) eyuen7: pmc_approved? |
||||
| Target Milestone: | 3.4.2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| See Also: |
https://git.eclipse.org/r/109149 https://git.eclipse.org/r/109148 |
||||||
| Whiteboard: | PMC_approved | ||||||
| Attachments: |
|
||||||
|
Description
Tim deBoer
Created attachment 225737 [details]
v1.0
The changes look good. Using Tomcat 7.0, I published a dynamic web project. To hit the code, I use "clean" to call the method org.eclipse.wst.server.core.util.PublishHelper.publishFull(IModuleResource[], IPath, IProgressMonitor), as a normal publish does not hit it. 1. With debug breakpoint in org.eclipse.wst.server.core.util.PublishHelper.copy(IModuleResource, IPath, IProgressMonitor), I cancel the copy to ensure the monitor.isCanceled check will cause the copy to be cancelled 2. I hacked in a case where f.mkdirs fails in org.eclipse.wst.server.core.util.PublishHelper.copy(IModuleResource, IPath, IProgressMonitor), to ensure that copyFile is not called (which can cause the hang) and verified that an error is returned immediately 3. I tested a simple publish, update, and clean with a servlet and HTML to ensure that the smoke test scenario was not broken Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. This problem causes publish to hang in some cases when dealing with large application. Is there a work-around? If so, why do you believe the work-around is insufficient? There is no good workaround given that the existing code does not check for the progress monitor cancel. Therefore, the user have to wait forever. How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Tested using on tomcat manually to make sure the publish clean scenario is still working fine (the described code will be executed during a publish clean). Give a brief technical overview. Who has reviewed this fix? Adding monitor cancel check in various places. Also, check to make use of the result from mkdirs() and an error status instead of continue to copy when the parent directory failed to be created. Reviewed by Steven Hung. What is the risk associated with this fix? Relatively low since the code affects the publish full and publish clean operation only which is not a very frequent operation (comparing to delta publish). Also, the code change is fairly straight forward. I assume the initial publish will hit this code, so a fairly high risk area to make changes. That said, the changes look straight forward, and assuming adequate testing and review, seems like a good bug to fix. I recommend other PMC members review this fix, but will approve for now. The initial publish does not call this. This method will only get called when someone do a clean publish from the GUI or some adopter explicitly calls the publishFull() API. Patch looks good - thanks Code released to 3.5 Changes released 3.4.2. New Gerrit change created: https://git.eclipse.org/r/109149 New Gerrit change created: https://git.eclipse.org/r/109148 |