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]
