Bugzilla – Full Text Bug Listing
| Summary: | EARComponentExportOperation shouldn't lock entire workspace | ||
|---|---|---|---|
| Product: | [WebTools] WTP ServerTools | Reporter: | Kapil Katyal <kkatyal> |
| Component: | jst.server | Assignee: | Tim deBoer <deboer> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | major | ||
| Priority: | P4 | CC: | darryl, deboer, gorkem.ercan, kelvinhc, yenlu, zhang, zina |
| Version: | 0.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| See Also: | https://git.eclipse.org/r/107329 | ||
| Whiteboard: | |||
|
Description
Kapil Katyal
We will continue to work on this, but reducing severity because its not blocking the WTP M5 milestone This defect is blocking FVT test pass so we need to increase the severity. I now create a scheduling rule for exports, that include the projects, plus dep projects (modules). Also needed to combine with eclipse "build" rule. Offline Chuck found out that they are doing a build, which is locking the entire workspace. Since they can't remove the build, the only other option to get this scenario working is to also lock the entire workspace when publishing. This is less than ideal (e.g. two servers with different projects will not be able to publish at the same time), but will get us through 0.7. I've made the change to the publish job and tagged for RC2. Usability problems have already been found in stack products due to this issue. One example is that you can't create a new module while the server is publishing in the background, since that now blocks all resource operation. Likewise, you wouldn't be able to build, save files, etc. The only fix I can see here is that the build within the export operation shouldn't lock the entire workspace. Instead, it should trigger an incremental build() specifically on the projects that are required within the export. At the least this will allow jobs within other projects to continue and not hold each other up. Reopening this bug, but marking severity down so that it doesn't hold up 0.7. Maybe we should open this up on jdt? The build uses the predefined "build" rule, that happens to lock the workspace. I think we are already calling incremental build, but I can check. After investigating - we do call an incremental build. How should we proceed? Awaiting on your response for direction on how to proceed. There appears to be no recent activity on this bug. Please retarget out of 1.0. Thx. Resetting target milestone, since it wasn't me who set it. I've seen some other issues (e.g. how do we do delta calculation if there are changes that occur during the publish/export operation?) which are making me second-guess this bug, and I think the more important issue is the performance of this operation. I'll discuss this offline with Kapil. (In reply to comment #4) > This is > less than ideal (e.g. two servers with different projects will not be able to > publish at the same time), but will get us through 0.7. On a side note, if this is still a genuine goal (two instances of server runtimes can be published to at the same time) in version 1.0 and beyond. Then I think there is a thread-unsafe buffer used in org/eclipse/jst/server/core/PublishUtil.java. Part of https://bugs.eclipse.org/bugs/attachment.cgi?id=29406 might suggest one way to change this (if you search the attachment for "buf"). This bug has been open for a long time. Although we've attempted to open this up, this lock has actually avoided a couple bugs as well because it avoided concurrency with other jobs that did not have their locks defined correctly. I haven't heard any complaints about this recently and we've had no performance concerns over this job blocking other jobs or not publishing concurrently to multiple servers, even with very large workspaces. Therefore, I am going to close this bug for now. If anyone still has any concerns or has seen other issues related to this, please let me know. Closing old bugs. New Gerrit change created: https://git.eclipse.org/r/107329 |