Bugzilla – Full Text Bug Listing
| Summary: | PublishUtil.createZipFile() has problem deleting file | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP ServerTools | Reporter: | Kathy Chan <kathy> | ||||
| Component: | jst.server | Assignee: | Tim deBoer <deboer> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P2 | CC: | jeffliu, larryisaacs, thatnitind | ||||
| Version: | 1.0.1 | ||||||
| Target Milestone: | 1.5.1 M151 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| See Also: |
https://git.eclipse.org/r/107802 https://git.eclipse.org/r/107938 |
||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Kathy Chan
Added to the 1.5 hot list. Setting priority to P2. assuming will be addressed next milestone. If I'm mistaken, please correct. ETA: Will work on it over the next couple weeks. Will be addressed by "friendly publishing", where we'll try multiple times to do the publish and will give a better error message if it still fails. There is a chance this will still cause the problem (e.g. if the server has locked the file and never lets go) but it will solve problems with temporary locks and will provide better feedback. Tim, any updates on this hot bug? Fix checked into HEAD. Will release for 1.5 once I-build is declared. *** Bug 120709 has been marked as a duplicate of this bug. *** Update all 1.5 hot bugs to use the new hot bug process. Released to 1.5 stream. I retried the scenario with WTP 1.5 06150639 driver and a similar problem is still there. Here's the trace (note that "u1" is the name of the utility Jar the Web project is dependent on):
Publishing failed
Error creating zip file u1.jar: Could not delete previous copy, which may be locked by another process.
java.lang.Exception: Could not delete previous copy, which may be locked by another process.
at org.eclipse.jst.server.core.PublishUtil.moveTempFile(PublishUtil.java:476)
at org.eclipse.jst.server.core.PublishUtil.createZipFile(PublishUtil.java:407)
at org.eclipse.jst.server.tomcat.core.internal.PublishOperation2.publishJar(PublishOperation2.java:108)
at org.eclipse.jst.server.tomcat.core.internal.PublishOperation2.execute(PublishOperation2.java:53)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.performTasks(ServerBehaviourDelegate.java:801)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:590)
at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:803)
at org.eclipse.wst.server.core.internal.Server.publish(Server.java:791)
at org.eclipse.jst.ws.internal.consumption.ui.command.StartServerCommand$1.run(StartServerCommand.java:129)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113)
If WTP can't delete the file, it probably means that the server is actually locking the file. If that's true, it's regular Tomcat behaviour and nothing WTP can do about it - can you show anything that would prove this is a WTP problem? I can't at the moment speak about class files, but I know for certain that Windows locks the file handle for jars while the JarFile is kept open by Tomcat's webapp classloader. The jar can't be deleted until Tomcat is shutdown. However, even though it can't be deleted, it *can* be rewritten. For consideration, I'm attaching a patch that works around this issue by rewritting the jar file with the contents of the temp file if the jar can't be deleted. This particular patch goes the whole nine yards by adding a boolean "allowRewrite" argument to more than just the jar related methods. Old public methods are preserved with new versions added with the new argument, in case some adopter determined to use internal API might want the choice. The patch also updates the Tomcat plug-in to specify allowRewrite true. This fixes the publish issue for me on Windows, at least for updating utility projects used by a webapp that is published to a running Tomcat server. I would expect it to fix this bug as well with respect to jars. I'm not aware of the same kind of locking problem for class files, which has been mentioned in other bugs, so I'm not sure if this would help in those cases. This patch could be scaled down to just address jar file replacement if desired. Let me know if you want me to create a smaller version of the patch. Created attachment 47122 [details]
Patch to rewrite files during publish if they can't be deleted
This patch was developed for 1.5.1. I haven't checked it against 2.0 yet, but I'll do so and attach another patch for 2.0 if necessary.
Thanks for the patch, Larry. The 2.0 stream is identical to 1.5.1 right now, so no additional work needs to be done. I'll review the patch and check the changes in. I may be wrong, but I think Larry's patch is great and I can't see any reason why someone wouldn't want to use it. Therefore, I'm skipping duplicating all of the API and putting the fix directly into the main stream so that all servers will take advantage of it. I hope everyone is ok with this and I'm not missing any reason why a server wouldn't want to try this behaviour. Fix dropped to HEAD. I can't claim we don't have any bugs or are still missing something, but at this point we try several different methods and are bending over backwards attempting to work with files locked by the server. If a publish still fails after this fix, it seems likely that the file is simply locked and it will be a limitation of the server. Fix released to 1.5.1 and 2.0 streams. I tried the original scenarios a few times on WTP 1.5.1 200609220504 and the problem has not surface. Thanks Tim and Larry for the fix. Closing. This is part of a "mass update" where bugs showing "fixed" between 7/1/2006 and 9/27/2006 are assumed fixed in WTP 1.5.1. feel free to change the target milestone if you know a more accurate setting. Darryl Miles raised an issue on the newsgroup about rewriting jars causing JVM problems. I had tested the rewriting with a utility jar with multiple classes and verified that with Tomcat, changes to all classes in the jar occurred successfully. Darryl's post reminded me that for this to succeed, automatic reloading of the web application has to occur. I had intended to eventually set the "allowRewrite" argument in my patch based on the auto-reload setting on the web application. This seemed too big a change for WTP 1.5.x, but I failed to mention it in comments. Since this argument wasn't included in the released changes, at some point I'll create an enhancement request to consider adding the "allowRewrite" argument to some extent in WTP 2.0 to better address this issue. At the moment for jars, I believe the Tomcat plug-in is the only consumer so this shouldn't be a problem in general. However, we should be watchful concerning any new uses of jar publishing. As Darryl points out, it's probably a bad idea to rewrite the jar in situations where there isn't good chance that stale classes will be discarded. New Gerrit change created: https://git.eclipse.org/r/107802 New Gerrit change created: https://git.eclipse.org/r/107938 |