Community
Participate
Working Groups
I only suspect that this problem is due to a webtools plugin. Could be somewhere else in Eclipse. I am running 3.1M6 + the I20050519 build of WST and JST What I am observing is a rapid, steady stream of HTTP requests (I would estimate 3-5 per sec) from Eclipse to the main HTTP server in my company's domain (i.e. www.ptc.com). The rate is so high that the Eclipse GUI is very unresponsive. I don't observe this behavior everytime I start Eclipse and I think there have been cases when it eventually stopped. As I type this message, I've been monitoring the problem for 10-15 minutes.
Interesting report ... but not sure how to narrow down. What kind of work are you doing? Do you reference DTDs or Schema's on your companies site? Exploring for web services? Doing data base work? Thanks,
(In reply to comment #1) > What kind of work are you doing? > Do you reference DTDs or Schema's on your companies > site? The only thing I could find is this. Some JSP files have tag library entries like this: <%@ taglib uri="http://www.ptc.com/windchill/taglib/util" prefix="util" %> where the URI references the main PTC web site. But the web.xml for this application has this entry: <taglib> <taglib-uri> http://www.ptc.com/windchill/taglib/util </taglib-uri> <taglib-location>/WEB-INF/util.tld</taglib-location> </taglib> Could this be confusing Eclipse? > Exploring for web services? No. > Doing data base work? No.
Thanks Bill ... we'll take a look.
This definitely sounds like the taglib indexing at work. Bill, is your web.xml file within a folder named WEB-INF?
(In reply to comment #4) > This definitely sounds like the taglib indexing at work. Bill, is your web.xml > file within a folder named WEB-INF? Yes, its in WEB-INF.
Taglib resolution currently falls back to the Common URI Resolver if a matching URI can't be found in its index. If the Internet Cache is enabled (bug 101398 mentions the lack of defaults on that page), it tries to download the URI if it has an "ftp" or "http" protocol in it. I won't mark this as blocking bug 101393, but it could make that a non-starter.
I forgot to ask, Bill, do you have the cache enabled in your Preferences (the Internet/Cache preference page)? Also, could you list the in-workspace paths for a .jsp file that causes this and the web.xml file that you're using? The taglib indexing makes certain assumptions that rely on the respective locations of those files.
Created attachment 24027 [details] web.xml file for our web application
(In reply to comment #7) > I forgot to ask, Bill, do you have the cache enabled in your Preferences (the > Internet/Cache preference page)? The Disable Caching checkbox is *not* checked. There are no entries in the Cache Entries list box. Also, could you list the in-workspace paths > for a .jsp file that causes this and the web.xml file that you're using? I'm not really sure which jsp file(s) causes the problem. Here is path info for one file: In workspace: Windchill/ProjectLink_src_web/netmarkets/jsp/document/view.jsp ProjectLink_src_web is linked to S:\ProjectLink\NetMarkets\src_web I've attached the web.xml file.
Bill, where was this web.xml file located? We make certain assumptions right now about the location of the web.xml in relation to a .jsp that's using taglibs defined by it, and your layout may just fall outside of our assumptions.
(In reply to comment #10) > Bill, where was this web.xml file located? We make certain assumptions right > now about the location of the web.xml in relation to a .jsp that's using taglibs > defined by it, and your layout may just fall outside of our assumptions. web.xml is in: S:\Windchill\codebase\WEB-INF Its one thing not to support a particular directory layout but quite another to fail in such a way that the whole IDE becomes unusable.
Lawrence, can you confirm if the cache is off by default? Bill, you might just need to disable the Internet Cache.
The cache is now (as of last week's I-build) off by default.
Resolving this as invalid, since this is what the design does when the cache is enabled. I'm blocking bug 88260 so that the Cache can be reworked. It shouldn't hit the firewall with the same request more than once and certainly not more than one at a time for the same URL.
Marking as verified to confirm this issue correctly categorized. If, as originator, you disagree please re-open, or open a new bug. Thanks very much for reporting and helping make WTP better.
Closing