hrm.. it almost seems that patch was intended to fix the very problem I am seeing..
I'll look a little further, may be there is something I'm missing... Thanks for your help. On 11/12/06, andyhot <[EMAIL PROTECTED]> wrote:
Jeff Poetker wrote: > Ok, Looking at the status.xml file in that revision I see the > following diff, are the changes in question related to "Double checked > locking bug prevents use of multi processor environments (efficiently)."? Yea, looks like it... Here's the jira: http://issues.apache.org/jira/browse/TAPESTRY-806 It describes that exact change... Weird thing is that the issue is marked as 'affects version:3.0.5' and 'fix version:3.0.5' but from the date and this http://svn.apache.org/viewvc/tapestry/tapestry4/tags/3.0.4/framework/src/org/apache/tapestry/enhance/DefaultComponentClassEnhancer.java?view=log and the code, it was indeed included in 3.0.4 > > > --- jakarta/tapestry/branches/branch-3-0/status.xml 2006/03/14 > 13:43:09 385801 > +++ jakarta/tapestry/branches/branch-3-0/status.xml 2006/03/14 > 13:47:10 385802 > @@ -11,6 +11,7 @@ > <person name="Tsvetelin Saykov" id="TS"/> > <person name="Neil Clayton" id="NC"/> > <person name="Paul Ferraro" id="PF"/> > + <person name="Jesse Kuhnert" id="JK" /> > <!-- Retired --> > <person name="Malcom Edgar" id="ME"/> > <!-- Add more people here --> > @@ -126,6 +127,21 @@ > <changes> > <release version="3.0.4" date="unreleased"> > <action type="fix" dev="GL" fixes-bug="TAPESTRY-431"> Fixed > TemplateParser throws an exception and stops parsing when duplicate > attributes are found in a tag. </action> > + <action type="fix" dev="JK" fixes-bug="TAPESTRY-877" > due-to="Brian K. Wallace"> > + Javassist url was incorrect. > + </action> > + <action type="remove" dev="JK" fixes-bug="TAPESTRY-878" > due-to="Brian K. Wallace" > > + Removed old tutorial example. > + </action> > + <action type="fix" dev="JK" fixes-bug="TAPESTRY-806" > due-to="Nick Westgate" > > + Double checked locking bug prevents use of multi processor > environments (efficiently). > + </action> > + <action type="fix" dev="JK" fixes-bug="TAPESTRY-241" > due-to="Kurtis Williams" > > + binding for convertor needed to be inherited-binding > + </action> > + <action type="fix" dev="JK" fixes-bug="TAPESTRY-193" > due-to="Brian K. Wallace" > > + AssetService not resolving file prefixes correctly. > + </action> > </release> > <release version="3.0.3" date="Mar 26 2005"> > <action type="fix" dev="PF" fixes-bug="TAPESTRY-278"> Fixes > security flaw in asset service. </action> > > > On Nov 11, 2006, at 2:51 PM, andyhot wrote: > >> Here's the history of that file >> http://svn.apache.org/viewvc/tapestry/tapestry4/branches/branch-3-0/framework/src/org/apache/tapestry/enhance/DefaultComponentClassEnhancer.java?view=log >> >> and here's the diffs to the previous version >> http://svn.apache.org/viewvc/tapestry/tapestry4/branches/branch-3-0/framework/src/org/apache/tapestry/enhance/DefaultComponentClassEnhancer.java?r1=243897&r2=385802 >> >> >> Jesse's change log states "Applied patches/fixed bugs" though i >> couldn't find any related entry in JIRA during my brief research... >> So, there seems to have been a reason for that change, perhaps Jesse >> can shed more light. >> >> >> >> Jeff Poetker wrote: >>> I work on a project that is using Tapestry 3. We're currently >>> working on version 4 of this product, and in this release we have >>> upgraded to version 3.0.4 of Tapestry. In every version of our >>> product we have done some amount of load testing as part of our >>> quality assurance process. >>> >>> In this release, we've started seeing this sort of exception a lot >>> during load (and occasionally in our functional) testing. >>> >>> Tapestry exception >>> java.lang.Throwable: Unable to define class >>> org.apache.tapestry.link.PageLink$Enhance_32: >>> org/apache/tapestry/link/PageLink$Enhance_32 (Repetitive method >>> name/signature) >>> >>> at >>> org.apache.tapestry.enhance.EnhancedClassLoader.defineClass( EnhancedClassLoader.java:55) >>> >>> at >>> org.apache.tapestry.enhance.javassist.EnhancedClass.createEnhancedSubclass (EnhancedClass.java:133) >>> >>> at >>> org.apache.tapestry.enhance.ComponentClassFactory.createEnhancedSubclass( ComponentClassFactory.java:336) >>> >>> at >>> org.apache.tapestry.enhance.DefaultComponentClassEnhancer.constructComponentClass (DefaultComponentClassEnhancer.java:139) >>> >>> >>> at >>> org.apache.tapestry.enhance.DefaultComponentClassEnhancer.getEnhancedClass (DefaultComponentClassEnhancer.java:94) >>> >>> >>> at >>> org.apache.tapestry.pageload.PageLoader.instantiateComponent( PageLoader.java:603) >>> >>> >>> This doesn't always seem to happen on the same page, and it isn't >>> always the same component that throws the exception. (Here it is >>> PageLink, I've also seen Any and Body throw this). >>> >>> I've been scratching my head on this for a while, trying to figure >>> out why we hadn't seen this in previous releases... Then I >>> remembered we switch to 3.0.4, and I decided to look into the >>> differences. >>> >>> I found something in the DefaultComponentClassEnhancer which has >>> changed, and I'd be interested in hearing if anybody believes this >>> could cause my problem. >>> >>> Specifically the method getEnhancedClass has changed from the >>> following in 3.0.3 >>> >>> public Class getEnhancedClass(IComponentSpecification specification, >>> String className) >>> { >>> Class result = getCachedClass(specification); >>> >>> if (result == null) >>> { >>> synchronized(this) >>> { >>> result = getCachedClass(specification); >>> if (result == null) >>> { >>> result = constructComponentClass(specification, >>> className); >>> storeCachedClass(specification, result); >>> } >>> } >>> } >>> return result; >>> } >>> >>> to this in 3.0.4 >>> >>> public Class getEnhancedClass(IComponentSpecification specification, >>> String className) >>> { >>> synchronized(specification) >>> { >>> Class result = getCachedClass(specification); >>> if (result == null) >>> { >>> result = constructComponentClass(specification, className); >>> storeCachedClass(specification, result); >>> } >>> return result; >>> } >>> } >>> >>> Now, my understanding of the tapestry internals has plenty of holes >>> in it, so I don't know if this can be related to my problem or not, >>> but the circumstances are such that it feels like a likely candidate. >>> >>> To try to test this theory myself, I have created a custom >>> ComponentClassEnhancer implementation which basically reverts back >>> to the 3.0.3 synchronization style - however, I haven't had an >>> opportunity to get it into a load test environment yet. I should be >>> able to do this sometime early this week. >>> >>> I'd love to hear from any developers who feel they can verify that >>> this is my problem, or debunk it totally. :) >>> >>> Thanks much, >>> Jeff Poetker >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
