Bug 111497
Summary: | error on simultaneous first hit | ||
---|---|---|---|
Product: | [Retired] Red Hat Enterprise CMS | Reporter: | Bryan Che <bche> |
Component: | other | Assignee: | Justin Ross <jross> |
Status: | CLOSED WONTFIX | QA Contact: | Jon Orris <jorris> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | nightly | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-09-05 17:35:51 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 106481 |
Description
Bryan Che
2003-12-04 16:46:04 UTC
Vaguely reminiscent of this thread: https://www.redhat.com/archives/redhat-ccm-list/2003-December/msg00003.html com.arsdigita.bebop.jsp.DefinePage is lacking any thread safety whatsoever. We fixed this in London 5.2 & I was sure we had the fix merged with mainline, but evidently not. p4 31469 needs to be merged with 5.2, 6.0, dev. Dan, What's the multiplicity of DefinePage instances per .jsp file? If a .jsp file has a single <define:page> tag, does this mean there will be a single DefinePage instance per JVM (webapp context)? One DefinePage instance per worker thread? Or something else entirely? I'm trying to form a clear picture of how this stuff works. In the olden days, the assumption was, you instantiate each page once per webapp context. This was achieved, I think, by having a single instance of BebopMapDispatcher (or some such) per webapp context. Do DefinePage and friends have roughly the same multiplicity implications as BebopMapDispatcher and friends? Pardon my ignorance. There is usually a single <define:page> per JSP file. I imagine the servlet container will only compile a JSP file once. The problem is that the <define:page> tag (because it is just part of the JSP body) will be *run* on every request - the first time through it actually creates the bebop page, the subsequent times it basically just does the generate XML bit. The race condition is that under load several threads may request a page between the JSP being compiled & the calling on lock() on the bebop page. The fix I did is basically constructs a string that uniquely identifies the JSP file within the servlet. THis is based on DispatcherHelper.getCurrentResourcePath ((HttpServletRequest)pageContext.getRequest()); there is a 1-1 cardinality between this string & constructing a bebop page, so it then takes a lock on this string. This sounds complicated, but it ensures that the global lock is held for the minimum amount of time, so multiple *different* JSP files can be constructed pretty concurrently. Since implemneting this, basically all concurrency errors relating to JSPs have completely dissappeared from our production server logfs, so I wouldn't be inclined to try another approach unless this is proven inaquate in further production testing. Ah, yes, I remember now http://post-office.corp.redhat.com/archives/ccm-engineering-list/2003-May/msg00107.html merged on trunk @39143 Closing old tickets |