You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Jeff Poetker <je...@gmail.com> on 2006/11/11 17:13:17 UTC
3.0.4 and repetitive method name/signature problem (class enhancement)
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.createEnhancedSubcla
ss(EnhancedClass.java:133)
at
org.apache.tapestry.enhance.ComponentClassFactory.createEnhancedSubclass
(ComponentClassFactory.java:336)
at
org.apache.tapestry.enhance.DefaultComponentClassEnhancer.constructCompo
nentClass(DefaultComponentClassEnhancer.java:139)
at
org.apache.tapestry.enhance.DefaultComponentClassEnhancer.getEnhancedCla
ss(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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: 3.0.4 and repetitive method name/signature problem (class enhancement)
Posted by Jeff Poetker <je...@gmail.com>.
Well, you're welcome. :)
Also, as for the double-checked locking working, there is a reasonably good
article on wikipedia:
http://en.wikipedia.org/wiki/Double-checked_lockingthat seems to imply
that in Java 5 it can work with volatile. However, I
read somewhere else that the new constructs for volatile may mean that you
won't see any better performance than you would if you just synchronized the
method (but I don't remember where I read that).
On 11/15/06, Nick Westgate <ni...@key-planning.co.jp> wrote:
>
> Canonical use of ReentrantLock here wouldn't be any better than
> synchronize(this), would it? I'm wondering what you have in mind.
>
> Anyway, my company is only just starting to look at using Java 5,
> so I'm not really familiar with the concurrent classes yet.
>
> Jeff: Thanks for your testing. I was finally going to put 3.04 in
> production after our next round of development! It would be handy
> if something like double-checked locking was guaranteed to work.
> (I think it's valid in Python.)
>
> Cheers,
> Nick.
>
>
> Jesse Kuhnert wrote:
> > You could always just use the apis provided by backport-util-concurrent
> as
> > well....It makes it almost trivial to do these tasks, all without being
> > retarded about thread management. (as would be the default behavior
> > exhibited when using the "synchronized" keyword )
> >
> > On 11/14/06, Jeff Poetker <je...@gmail.com> wrote:
> >>
> >> Ok... Well, I'm not sure I'm ready to go there just yet... I did want
> to
> >> send an update to whom it may concern...
> >>
> >> I worked with our load test environment today, and was able to
> reproduce
> >> my
> >> problem fairly easily. We ran a set of about 20 virtual users in a
> script
> >> that would have all 20 request a page at the same time, wait for all
> >> 20 to
> >> get responses, then send all 20 at another page. All, on a freshly
> >> started
> >> server, with no page objects pooled yet.
> >>
> >> The repetitive method errors started showing up almost immediately with
> >> the
> >> 3.0.4 code.
> >>
> >> So, next I overloaded the getter in the engine that returns the
> >> DefaultComponentClassEnhancer, and had it return my own
> >> ComponentClassEnhancer. My version works the way 3.0.3 did, with the
> >> double-checked locking code. (I know this code is not guaranteed to
> work,
> >> but because we hadn't seen this problem before, it seemed like it had
> >> been
> >> working for us).
> >>
> >> I ran the same test with the double-checked locking code. No problems.
> >> (FYI
> >> - I was testing against a dual Xeon (NetBurst, not Core) server and the
> >> JRockit VM on RedHat Linux).
> >>
> >> Ok, so, this "fixes" my problem, but I've been studying up on this
> >> double-checked locking thing, and get that it isn't really safe to
> assume
> >> it
> >> will work... So, I tried doing the only thing that most of the articles
> I
> >> read said you could do - synchronize the whole thing. So I
> re-implemented
> >> my
> >> custom ComponentClassEnhancer to syncrhonize the method in question...
> >>
> >> Of course, this also works... It also made my simple 20 user test take
> 2
> >> minutes longer. :(
> >>
> >> My test of course was a worst case, hitting new pages with nothing
> >> pooled.
> >> Tomorrow I'm going to try both solutions with a more realistic load,
> and
> >> find out if the synchronization solution is really going to hurt us or
> >> not.
> >>
> >>
> >> On 11/13/06, Jesse Kuhnert <jk...@gmail.com> wrote:
> >> >
> >> > Yep, a much more efficient means of doing it would be to use
> >> > http://dcl.mathcs.emory.edu/util/backport-util-concurrent/ . It seems
> >> like
> >> > this is crossing over on the annotation exceptions being thrown when
> >> > caching
> >> > is disabled as well. (though maybe the solution for t4 won't be the
> >> same
> >> > as
> >> > t3 since t4 is based around hivemind. )
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: 3.0.4 and repetitive method name/signature problem (class enhancement)
Posted by Jesse Kuhnert <jk...@gmail.com>.
No, I don't think that's true. Wouldn't really scale well or make sense. It
also wouldn't make threads magically be handled correctly. A thread pool
alone would have 0 to do with how something handles "synchronized" blocks.
On 11/16/06, Jeff Poetker <je...@gmail.com> wrote:
>
> I'm not sure it would be a huge difference based on your hypothetical
> situation. I believe most app servers (I know weblogic does) serves
> requests from a thread pool, which generally has much less than 1000
> threads - I believe by a couple of orders of magnitude... So you're
> probably not really going to actually have 100's of threads waking up
> to get that lock.
>
> On Nov 15, 2006, at 10:22 PM, Jesse Kuhnert wrote:
>
> > Yeah, I think it would be a huge difference - but only when the
> > load on your
> > server is especially high or you are dealing with multiple cpus.
> > (Who knows,
> > maybe sun fixed synchronized in recent jre's)
> >
> > The biggest difference and easiest example I always use is a simple
> > scenario. Let's say you have a synchronized block (and not method,
> > I won't
> > get into why that is particularly harmful wrt locking up the entire
> > object
> > vs a single block of logic) and 1000 concurrent requests to get
> > access to
> > that block.
> >
> > With "synchronized" the first thread that wins gets the lock. When it
> > releases the lock all 999 of the remaining sleeping threads are
> > woken up and
> > each one attempts to get the lock. Again, only 1 wins and everyone
> > else goes
> > to bed.
> >
> > Keeping in mind that each thread has its own heap space to be managed,
> > native counterparts to interact with, etc...This is a lot of
> > processing in
> > the grand scheme of things when thinking about it on the micro level.
> >
> > The biggest thing backport-util (and which is the exact same library
> > included in >= 1.5 jres by default) does is handle this particular
> > logic.
> > Much like "synchronized" all 999 threads will go to sleep after the
> > first
> > one wins. The difference is that only one thread will be woken up
> > when it is
> > done. So...wake up 999 threads vs 1.
> >
> > There's a lot more but that's the basic gist as I've understood it.
> >
> > On 11/15/06, Nick Westgate <ni...@key-planning.co.jp> wrote:
> >>
> >> Canonical use of ReentrantLock here wouldn't be any better than
> >> synchronize(this), would it? I'm wondering what you have in mind.
> >>
> >> Anyway, my company is only just starting to look at using Java 5,
> >> so I'm not really familiar with the concurrent classes yet.
> >>
> >> Jeff: Thanks for your testing. I was finally going to put 3.04 in
> >> production after our next round of development! It would be handy
> >> if something like double-checked locking was guaranteed to work.
> >> (I think it's valid in Python.)
> >>
> >> Cheers,
> >> Nick.
> >>
> >>
> >> Jesse Kuhnert wrote:
> >> > You could always just use the apis provided by backport-util-
> >> concurrent
> >> as
> >> > well....It makes it almost trivial to do these tasks, all
> >> without being
> >> > retarded about thread management. (as would be the default behavior
> >> > exhibited when using the "synchronized" keyword )
> >> >
> >> > On 11/14/06, Jeff Poetker <je...@gmail.com> wrote:
> >> >>
> >> >> Ok... Well, I'm not sure I'm ready to go there just yet... I
> >> did want
> >> to
> >> >> send an update to whom it may concern...
> >> >>
> >> >> I worked with our load test environment today, and was able to
> >> reproduce
> >> >> my
> >> >> problem fairly easily. We ran a set of about 20 virtual users in a
> >> script
> >> >> that would have all 20 request a page at the same time, wait
> >> for all
> >> >> 20 to
> >> >> get responses, then send all 20 at another page. All, on a freshly
> >> >> started
> >> >> server, with no page objects pooled yet.
> >> >>
> >> >> The repetitive method errors started showing up almost
> >> immediately with
> >> >> the
> >> >> 3.0.4 code.
> >> >>
> >> >> So, next I overloaded the getter in the engine that returns the
> >> >> DefaultComponentClassEnhancer, and had it return my own
> >> >> ComponentClassEnhancer. My version works the way 3.0.3 did,
> >> with the
> >> >> double-checked locking code. (I know this code is not
> >> guaranteed to
> >> work,
> >> >> but because we hadn't seen this problem before, it seemed like
> >> it had
> >> >> been
> >> >> working for us).
> >> >>
> >> >> I ran the same test with the double-checked locking code. No
> >> problems.
> >> >> (FYI
> >> >> - I was testing against a dual Xeon (NetBurst, not Core) server
> >> and the
> >> >> JRockit VM on RedHat Linux).
> >> >>
> >> >> Ok, so, this "fixes" my problem, but I've been studying up on this
> >> >> double-checked locking thing, and get that it isn't really safe to
> >> assume
> >> >> it
> >> >> will work... So, I tried doing the only thing that most of the
> >> articles
> >> I
> >> >> read said you could do - synchronize the whole thing. So I
> >> re-implemented
> >> >> my
> >> >> custom ComponentClassEnhancer to syncrhonize the method in
> >> question...
> >> >>
> >> >> Of course, this also works... It also made my simple 20 user
> >> test take
> >> 2
> >> >> minutes longer. :(
> >> >>
> >> >> My test of course was a worst case, hitting new pages with nothing
> >> >> pooled.
> >> >> Tomorrow I'm going to try both solutions with a more realistic
> >> load,
> >> and
> >> >> find out if the synchronization solution is really going to
> >> hurt us or
> >> >> not.
> >> >>
> >> >>
> >> >> On 11/13/06, Jesse Kuhnert <jk...@gmail.com> wrote:
> >> >> >
> >> >> > Yep, a much more efficient means of doing it would be to use
> >> >> > http://dcl.mathcs.emory.edu/util/backport-util-concurrent/ .
> >> It seems
> >> >> like
> >> >> > this is crossing over on the annotation exceptions being
> >> thrown when
> >> >> > caching
> >> >> > is disabled as well. (though maybe the solution for t4 won't
> >> be the
> >> >> same
> >> >> > as
> >> >> > t3 since t4 is based around hivemind. )
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > Jesse Kuhnert
> > Tapestry/Dojo/(and a dash of TestNG), team member/developer
> >
> > Open source based consulting work centered around
> > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: 3.0.4 and repetitive method name/signature problem (class enhancement)
Posted by Jeff Poetker <je...@gmail.com>.
I'm not sure it would be a huge difference based on your hypothetical
situation. I believe most app servers (I know weblogic does) serves
requests from a thread pool, which generally has much less than 1000
threads - I believe by a couple of orders of magnitude... So you're
probably not really going to actually have 100's of threads waking up
to get that lock.
On Nov 15, 2006, at 10:22 PM, Jesse Kuhnert wrote:
> Yeah, I think it would be a huge difference - but only when the
> load on your
> server is especially high or you are dealing with multiple cpus.
> (Who knows,
> maybe sun fixed synchronized in recent jre's)
>
> The biggest difference and easiest example I always use is a simple
> scenario. Let's say you have a synchronized block (and not method,
> I won't
> get into why that is particularly harmful wrt locking up the entire
> object
> vs a single block of logic) and 1000 concurrent requests to get
> access to
> that block.
>
> With "synchronized" the first thread that wins gets the lock. When it
> releases the lock all 999 of the remaining sleeping threads are
> woken up and
> each one attempts to get the lock. Again, only 1 wins and everyone
> else goes
> to bed.
>
> Keeping in mind that each thread has its own heap space to be managed,
> native counterparts to interact with, etc...This is a lot of
> processing in
> the grand scheme of things when thinking about it on the micro level.
>
> The biggest thing backport-util (and which is the exact same library
> included in >= 1.5 jres by default) does is handle this particular
> logic.
> Much like "synchronized" all 999 threads will go to sleep after the
> first
> one wins. The difference is that only one thread will be woken up
> when it is
> done. So...wake up 999 threads vs 1.
>
> There's a lot more but that's the basic gist as I've understood it.
>
> On 11/15/06, Nick Westgate <ni...@key-planning.co.jp> wrote:
>>
>> Canonical use of ReentrantLock here wouldn't be any better than
>> synchronize(this), would it? I'm wondering what you have in mind.
>>
>> Anyway, my company is only just starting to look at using Java 5,
>> so I'm not really familiar with the concurrent classes yet.
>>
>> Jeff: Thanks for your testing. I was finally going to put 3.04 in
>> production after our next round of development! It would be handy
>> if something like double-checked locking was guaranteed to work.
>> (I think it's valid in Python.)
>>
>> Cheers,
>> Nick.
>>
>>
>> Jesse Kuhnert wrote:
>> > You could always just use the apis provided by backport-util-
>> concurrent
>> as
>> > well....It makes it almost trivial to do these tasks, all
>> without being
>> > retarded about thread management. (as would be the default behavior
>> > exhibited when using the "synchronized" keyword )
>> >
>> > On 11/14/06, Jeff Poetker <je...@gmail.com> wrote:
>> >>
>> >> Ok... Well, I'm not sure I'm ready to go there just yet... I
>> did want
>> to
>> >> send an update to whom it may concern...
>> >>
>> >> I worked with our load test environment today, and was able to
>> reproduce
>> >> my
>> >> problem fairly easily. We ran a set of about 20 virtual users in a
>> script
>> >> that would have all 20 request a page at the same time, wait
>> for all
>> >> 20 to
>> >> get responses, then send all 20 at another page. All, on a freshly
>> >> started
>> >> server, with no page objects pooled yet.
>> >>
>> >> The repetitive method errors started showing up almost
>> immediately with
>> >> the
>> >> 3.0.4 code.
>> >>
>> >> So, next I overloaded the getter in the engine that returns the
>> >> DefaultComponentClassEnhancer, and had it return my own
>> >> ComponentClassEnhancer. My version works the way 3.0.3 did,
>> with the
>> >> double-checked locking code. (I know this code is not
>> guaranteed to
>> work,
>> >> but because we hadn't seen this problem before, it seemed like
>> it had
>> >> been
>> >> working for us).
>> >>
>> >> I ran the same test with the double-checked locking code. No
>> problems.
>> >> (FYI
>> >> - I was testing against a dual Xeon (NetBurst, not Core) server
>> and the
>> >> JRockit VM on RedHat Linux).
>> >>
>> >> Ok, so, this "fixes" my problem, but I've been studying up on this
>> >> double-checked locking thing, and get that it isn't really safe to
>> assume
>> >> it
>> >> will work... So, I tried doing the only thing that most of the
>> articles
>> I
>> >> read said you could do - synchronize the whole thing. So I
>> re-implemented
>> >> my
>> >> custom ComponentClassEnhancer to syncrhonize the method in
>> question...
>> >>
>> >> Of course, this also works... It also made my simple 20 user
>> test take
>> 2
>> >> minutes longer. :(
>> >>
>> >> My test of course was a worst case, hitting new pages with nothing
>> >> pooled.
>> >> Tomorrow I'm going to try both solutions with a more realistic
>> load,
>> and
>> >> find out if the synchronization solution is really going to
>> hurt us or
>> >> not.
>> >>
>> >>
>> >> On 11/13/06, Jesse Kuhnert <jk...@gmail.com> wrote:
>> >> >
>> >> > Yep, a much more efficient means of doing it would be to use
>> >> > http://dcl.mathcs.emory.edu/util/backport-util-concurrent/ .
>> It seems
>> >> like
>> >> > this is crossing over on the annotation exceptions being
>> thrown when
>> >> > caching
>> >> > is disabled as well. (though maybe the solution for t4 won't
>> be the
>> >> same
>> >> > as
>> >> > t3 since t4 is based around hivemind. )
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo/(and a dash of TestNG), team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: 3.0.4 and repetitive method name/signature problem (class enhancement)
Posted by Jesse Kuhnert <jk...@gmail.com>.
Yeah, I think it would be a huge difference - but only when the load on your
server is especially high or you are dealing with multiple cpus. (Who knows,
maybe sun fixed synchronized in recent jre's)
The biggest difference and easiest example I always use is a simple
scenario. Let's say you have a synchronized block (and not method, I won't
get into why that is particularly harmful wrt locking up the entire object
vs a single block of logic) and 1000 concurrent requests to get access to
that block.
With "synchronized" the first thread that wins gets the lock. When it
releases the lock all 999 of the remaining sleeping threads are woken up and
each one attempts to get the lock. Again, only 1 wins and everyone else goes
to bed.
Keeping in mind that each thread has its own heap space to be managed,
native counterparts to interact with, etc...This is a lot of processing in
the grand scheme of things when thinking about it on the micro level.
The biggest thing backport-util (and which is the exact same library
included in >= 1.5 jres by default) does is handle this particular logic.
Much like "synchronized" all 999 threads will go to sleep after the first
one wins. The difference is that only one thread will be woken up when it is
done. So...wake up 999 threads vs 1.
There's a lot more but that's the basic gist as I've understood it.
On 11/15/06, Nick Westgate <ni...@key-planning.co.jp> wrote:
>
> Canonical use of ReentrantLock here wouldn't be any better than
> synchronize(this), would it? I'm wondering what you have in mind.
>
> Anyway, my company is only just starting to look at using Java 5,
> so I'm not really familiar with the concurrent classes yet.
>
> Jeff: Thanks for your testing. I was finally going to put 3.04 in
> production after our next round of development! It would be handy
> if something like double-checked locking was guaranteed to work.
> (I think it's valid in Python.)
>
> Cheers,
> Nick.
>
>
> Jesse Kuhnert wrote:
> > You could always just use the apis provided by backport-util-concurrent
> as
> > well....It makes it almost trivial to do these tasks, all without being
> > retarded about thread management. (as would be the default behavior
> > exhibited when using the "synchronized" keyword )
> >
> > On 11/14/06, Jeff Poetker <je...@gmail.com> wrote:
> >>
> >> Ok... Well, I'm not sure I'm ready to go there just yet... I did want
> to
> >> send an update to whom it may concern...
> >>
> >> I worked with our load test environment today, and was able to
> reproduce
> >> my
> >> problem fairly easily. We ran a set of about 20 virtual users in a
> script
> >> that would have all 20 request a page at the same time, wait for all
> >> 20 to
> >> get responses, then send all 20 at another page. All, on a freshly
> >> started
> >> server, with no page objects pooled yet.
> >>
> >> The repetitive method errors started showing up almost immediately with
> >> the
> >> 3.0.4 code.
> >>
> >> So, next I overloaded the getter in the engine that returns the
> >> DefaultComponentClassEnhancer, and had it return my own
> >> ComponentClassEnhancer. My version works the way 3.0.3 did, with the
> >> double-checked locking code. (I know this code is not guaranteed to
> work,
> >> but because we hadn't seen this problem before, it seemed like it had
> >> been
> >> working for us).
> >>
> >> I ran the same test with the double-checked locking code. No problems.
> >> (FYI
> >> - I was testing against a dual Xeon (NetBurst, not Core) server and the
> >> JRockit VM on RedHat Linux).
> >>
> >> Ok, so, this "fixes" my problem, but I've been studying up on this
> >> double-checked locking thing, and get that it isn't really safe to
> assume
> >> it
> >> will work... So, I tried doing the only thing that most of the articles
> I
> >> read said you could do - synchronize the whole thing. So I
> re-implemented
> >> my
> >> custom ComponentClassEnhancer to syncrhonize the method in question...
> >>
> >> Of course, this also works... It also made my simple 20 user test take
> 2
> >> minutes longer. :(
> >>
> >> My test of course was a worst case, hitting new pages with nothing
> >> pooled.
> >> Tomorrow I'm going to try both solutions with a more realistic load,
> and
> >> find out if the synchronization solution is really going to hurt us or
> >> not.
> >>
> >>
> >> On 11/13/06, Jesse Kuhnert <jk...@gmail.com> wrote:
> >> >
> >> > Yep, a much more efficient means of doing it would be to use
> >> > http://dcl.mathcs.emory.edu/util/backport-util-concurrent/ . It seems
> >> like
> >> > this is crossing over on the annotation exceptions being thrown when
> >> > caching
> >> > is disabled as well. (though maybe the solution for t4 won't be the
> >> same
> >> > as
> >> > t3 since t4 is based around hivemind. )
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: 3.0.4 and repetitive method name/signature problem (class enhancement)
Posted by Nick Westgate <ni...@key-planning.co.jp>.
Canonical use of ReentrantLock here wouldn't be any better than
synchronize(this), would it? I'm wondering what you have in mind.
Anyway, my company is only just starting to look at using Java 5,
so I'm not really familiar with the concurrent classes yet.
Jeff: Thanks for your testing. I was finally going to put 3.04 in
production after our next round of development! It would be handy
if something like double-checked locking was guaranteed to work.
(I think it's valid in Python.)
Cheers,
Nick.
Jesse Kuhnert wrote:
> You could always just use the apis provided by backport-util-concurrent as
> well....It makes it almost trivial to do these tasks, all without being
> retarded about thread management. (as would be the default behavior
> exhibited when using the "synchronized" keyword )
>
> On 11/14/06, Jeff Poetker <je...@gmail.com> wrote:
>>
>> Ok... Well, I'm not sure I'm ready to go there just yet... I did want to
>> send an update to whom it may concern...
>>
>> I worked with our load test environment today, and was able to reproduce
>> my
>> problem fairly easily. We ran a set of about 20 virtual users in a script
>> that would have all 20 request a page at the same time, wait for all
>> 20 to
>> get responses, then send all 20 at another page. All, on a freshly
>> started
>> server, with no page objects pooled yet.
>>
>> The repetitive method errors started showing up almost immediately with
>> the
>> 3.0.4 code.
>>
>> So, next I overloaded the getter in the engine that returns the
>> DefaultComponentClassEnhancer, and had it return my own
>> ComponentClassEnhancer. My version works the way 3.0.3 did, with the
>> double-checked locking code. (I know this code is not guaranteed to work,
>> but because we hadn't seen this problem before, it seemed like it had
>> been
>> working for us).
>>
>> I ran the same test with the double-checked locking code. No problems.
>> (FYI
>> - I was testing against a dual Xeon (NetBurst, not Core) server and the
>> JRockit VM on RedHat Linux).
>>
>> Ok, so, this "fixes" my problem, but I've been studying up on this
>> double-checked locking thing, and get that it isn't really safe to assume
>> it
>> will work... So, I tried doing the only thing that most of the articles I
>> read said you could do - synchronize the whole thing. So I re-implemented
>> my
>> custom ComponentClassEnhancer to syncrhonize the method in question...
>>
>> Of course, this also works... It also made my simple 20 user test take 2
>> minutes longer. :(
>>
>> My test of course was a worst case, hitting new pages with nothing
>> pooled.
>> Tomorrow I'm going to try both solutions with a more realistic load, and
>> find out if the synchronization solution is really going to hurt us or
>> not.
>>
>>
>> On 11/13/06, Jesse Kuhnert <jk...@gmail.com> wrote:
>> >
>> > Yep, a much more efficient means of doing it would be to use
>> > http://dcl.mathcs.emory.edu/util/backport-util-concurrent/ . It seems
>> like
>> > this is crossing over on the annotation exceptions being thrown when
>> > caching
>> > is disabled as well. (though maybe the solution for t4 won't be the
>> same
>> > as
>> > t3 since t4 is based around hivemind. )
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: 3.0.4 and repetitive method name/signature problem (class enhancement)
Posted by Jesse Kuhnert <jk...@gmail.com>.
You could always just use the apis provided by backport-util-concurrent as
well....It makes it almost trivial to do these tasks, all without being
retarded about thread management. (as would be the default behavior
exhibited when using the "synchronized" keyword )
On 11/14/06, Jeff Poetker <je...@gmail.com> wrote:
>
> Ok... Well, I'm not sure I'm ready to go there just yet... I did want to
> send an update to whom it may concern...
>
> I worked with our load test environment today, and was able to reproduce
> my
> problem fairly easily. We ran a set of about 20 virtual users in a script
> that would have all 20 request a page at the same time, wait for all 20 to
> get responses, then send all 20 at another page. All, on a freshly started
> server, with no page objects pooled yet.
>
> The repetitive method errors started showing up almost immediately with
> the
> 3.0.4 code.
>
> So, next I overloaded the getter in the engine that returns the
> DefaultComponentClassEnhancer, and had it return my own
> ComponentClassEnhancer. My version works the way 3.0.3 did, with the
> double-checked locking code. (I know this code is not guaranteed to work,
> but because we hadn't seen this problem before, it seemed like it had been
> working for us).
>
> I ran the same test with the double-checked locking code. No problems.
> (FYI
> - I was testing against a dual Xeon (NetBurst, not Core) server and the
> JRockit VM on RedHat Linux).
>
> Ok, so, this "fixes" my problem, but I've been studying up on this
> double-checked locking thing, and get that it isn't really safe to assume
> it
> will work... So, I tried doing the only thing that most of the articles I
> read said you could do - synchronize the whole thing. So I re-implemented
> my
> custom ComponentClassEnhancer to syncrhonize the method in question...
>
> Of course, this also works... It also made my simple 20 user test take 2
> minutes longer. :(
>
> My test of course was a worst case, hitting new pages with nothing pooled.
> Tomorrow I'm going to try both solutions with a more realistic load, and
> find out if the synchronization solution is really going to hurt us or
> not.
>
>
> On 11/13/06, Jesse Kuhnert <jk...@gmail.com> wrote:
> >
> > Yep, a much more efficient means of doing it would be to use
> > http://dcl.mathcs.emory.edu/util/backport-util-concurrent/ . It seems
> like
> > this is crossing over on the annotation exceptions being thrown when
> > caching
> > is disabled as well. (though maybe the solution for t4 won't be the same
> > as
> > t3 since t4 is based around hivemind. )
> >
> > On 11/13/06, Nick Westgate <ni...@key-planning.co.jp> wrote:
> > >
> > > Hi Jeff.
> > >
> > > > hrm.. it almost seems that patch was intended to fix the very
> problem
> > I
> > > am
> > > > seeing..
> > >
> > > Indeed.
> > >
> > > > I'll look a little further, may be there is something I'm missing...
> > >
> > > The original code is definitely flawed. Unfortunately, it seems that
> > > the new code:
> > > synchronized(specification)
> > >
> > > is not sufficient to replace:
> > > synchronized(this)
> > >
> > > which suggests synchronizing on "this" is necessary, or equivalently
> > > removing the synchronization block and synchronizing the method.
> > >
> > > The only other way to address it would be at a higher level outside
> > > this method, which would be nice to avoid the performance hit.
> > >
> > > Cheers,
> > > Nick.
> > >
> > >
> > > > On 11/12/06, andyhot <an...@di.uoa.gr> 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: dev-unsubscribe@tapestry.apache.org
> > > >> >>> For additional commands, e-mail: dev-help@tapestry.apache.org
> > > >> >>>
> > > >> >>>
> > > >> >>
> > > >> >>
> > > >> >>
> > > ---------------------------------------------------------------------
> > > >> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > >> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> > > >> >>
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > >> For additional commands, e-mail: dev-help@tapestry.apache.org
> > > >>
> > > >>
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > Jesse Kuhnert
> > Tapestry/Dojo/(and a dash of TestNG), team member/developer
> >
> > Open source based consulting work centered around
> > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> >
> >
>
>
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: 3.0.4 and repetitive method name/signature problem (class enhancement)
Posted by Jeff Poetker <je...@gmail.com>.
Ok... Well, I'm not sure I'm ready to go there just yet... I did want to
send an update to whom it may concern...
I worked with our load test environment today, and was able to reproduce my
problem fairly easily. We ran a set of about 20 virtual users in a script
that would have all 20 request a page at the same time, wait for all 20 to
get responses, then send all 20 at another page. All, on a freshly started
server, with no page objects pooled yet.
The repetitive method errors started showing up almost immediately with the
3.0.4 code.
So, next I overloaded the getter in the engine that returns the
DefaultComponentClassEnhancer, and had it return my own
ComponentClassEnhancer. My version works the way 3.0.3 did, with the
double-checked locking code. (I know this code is not guaranteed to work,
but because we hadn't seen this problem before, it seemed like it had been
working for us).
I ran the same test with the double-checked locking code. No problems. (FYI
- I was testing against a dual Xeon (NetBurst, not Core) server and the
JRockit VM on RedHat Linux).
Ok, so, this "fixes" my problem, but I've been studying up on this
double-checked locking thing, and get that it isn't really safe to assume it
will work... So, I tried doing the only thing that most of the articles I
read said you could do - synchronize the whole thing. So I re-implemented my
custom ComponentClassEnhancer to syncrhonize the method in question...
Of course, this also works... It also made my simple 20 user test take 2
minutes longer. :(
My test of course was a worst case, hitting new pages with nothing pooled.
Tomorrow I'm going to try both solutions with a more realistic load, and
find out if the synchronization solution is really going to hurt us or not.
On 11/13/06, Jesse Kuhnert <jk...@gmail.com> wrote:
>
> Yep, a much more efficient means of doing it would be to use
> http://dcl.mathcs.emory.edu/util/backport-util-concurrent/ . It seems like
> this is crossing over on the annotation exceptions being thrown when
> caching
> is disabled as well. (though maybe the solution for t4 won't be the same
> as
> t3 since t4 is based around hivemind. )
>
> On 11/13/06, Nick Westgate <ni...@key-planning.co.jp> wrote:
> >
> > Hi Jeff.
> >
> > > hrm.. it almost seems that patch was intended to fix the very problem
> I
> > am
> > > seeing..
> >
> > Indeed.
> >
> > > I'll look a little further, may be there is something I'm missing...
> >
> > The original code is definitely flawed. Unfortunately, it seems that
> > the new code:
> > synchronized(specification)
> >
> > is not sufficient to replace:
> > synchronized(this)
> >
> > which suggests synchronizing on "this" is necessary, or equivalently
> > removing the synchronization block and synchronizing the method.
> >
> > The only other way to address it would be at a higher level outside
> > this method, which would be nice to avoid the performance hit.
> >
> > Cheers,
> > Nick.
> >
> >
> > > On 11/12/06, andyhot <an...@di.uoa.gr> 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: dev-unsubscribe@tapestry.apache.org
> > >> >>> For additional commands, e-mail: dev-help@tapestry.apache.org
> > >> >>>
> > >> >>>
> > >> >>
> > >> >>
> > >> >>
> > ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > >> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> > >> >>
> > >> >
> > >> >
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > >> For additional commands, e-mail: dev-help@tapestry.apache.org
> > >>
> > >>
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo/(and a dash of TestNG), team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
>
Re: 3.0.4 and repetitive method name/signature problem (class enhancement)
Posted by Jesse Kuhnert <jk...@gmail.com>.
Yep, a much more efficient means of doing it would be to use
http://dcl.mathcs.emory.edu/util/backport-util-concurrent/ . It seems like
this is crossing over on the annotation exceptions being thrown when caching
is disabled as well. (though maybe the solution for t4 won't be the same as
t3 since t4 is based around hivemind. )
On 11/13/06, Nick Westgate <ni...@key-planning.co.jp> wrote:
>
> Hi Jeff.
>
> > hrm.. it almost seems that patch was intended to fix the very problem I
> am
> > seeing..
>
> Indeed.
>
> > I'll look a little further, may be there is something I'm missing...
>
> The original code is definitely flawed. Unfortunately, it seems that
> the new code:
> synchronized(specification)
>
> is not sufficient to replace:
> synchronized(this)
>
> which suggests synchronizing on "this" is necessary, or equivalently
> removing the synchronization block and synchronizing the method.
>
> The only other way to address it would be at a higher level outside
> this method, which would be nice to avoid the performance hit.
>
> Cheers,
> Nick.
>
>
> > On 11/12/06, andyhot <an...@di.uoa.gr> 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: dev-unsubscribe@tapestry.apache.org
> >> >>> For additional commands, e-mail: dev-help@tapestry.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >> >>
> >> >
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: 3.0.4 and repetitive method name/signature problem (class enhancement)
Posted by Nick Westgate <ni...@key-planning.co.jp>.
Hi Jeff.
> hrm.. it almost seems that patch was intended to fix the very problem I am
> seeing..
Indeed.
> I'll look a little further, may be there is something I'm missing...
The original code is definitely flawed. Unfortunately, it seems that
the new code:
synchronized(specification)
is not sufficient to replace:
synchronized(this)
which suggests synchronizing on "this" is necessary, or equivalently
removing the synchronization block and synchronizing the method.
The only other way to address it would be at a higher level outside
this method, which would be nice to avoid the performance hit.
Cheers,
Nick.
> On 11/12/06, andyhot <an...@di.uoa.gr> 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: dev-unsubscribe@tapestry.apache.org
>> >>> For additional commands, e-mail: dev-help@tapestry.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: dev-help@tapestry.apache.org
>> >>
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: 3.0.4 and repetitive method name/signature problem (class enhancement)
Posted by Jeff Poetker <je...@gmail.com>.
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 <an...@di.uoa.gr> 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: dev-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: 3.0.4 and repetitive method name/signature problem (class enhancement)
Posted by andyhot <an...@di.uoa.gr>.
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: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: 3.0.4 and repetitive method name/signature problem (class enhancement)
Posted by Jeff Poetker <je...@gmail.com>.
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)."?
--- 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.createEnhancedSub
>> class(EnhancedClass.java:133)
>> at
>> org.apache.tapestry.enhance.ComponentClassFactory.createEnhancedSubcl
>> ass(ComponentClassFactory.java:336)
>> at
>> org.apache.tapestry.enhance.DefaultComponentClassEnhancer.constructCo
>> mponentClass(DefaultComponentClassEnhancer.java:139)
>>
>> at
>> org.apache.tapestry.enhance.DefaultComponentClassEnhancer.getEnhanced
>> Class(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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
Re: 3.0.4 and repetitive method name/signature problem (class enhancement)
Posted by Jeff Poetker <je...@gmail.com>.
Thanks, I looked for that earlier, but didn't know where the 3.0 code
lived any more (I guess I didn't look hard enough), but now I know...
Thanks again..
Interesting that revision seems to have some random fixes in it...
But there was at least one other class enhancement related file in
it... And some table stuff..
Well, it would be good to hear if Jesse remembers anything...
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.createEnhancedSub
>> class(EnhancedClass.java:133)
>> at
>> org.apache.tapestry.enhance.ComponentClassFactory.createEnhancedSubcl
>> ass(ComponentClassFactory.java:336)
>> at
>> org.apache.tapestry.enhance.DefaultComponentClassEnhancer.constructCo
>> mponentClass(DefaultComponentClassEnhancer.java:139)
>>
>> at
>> org.apache.tapestry.enhance.DefaultComponentClassEnhancer.getEnhanced
>> Class(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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: 3.0.4 and repetitive method name/signature problem (class enhancement)
Posted by andyhot <an...@di.uoa.gr>.
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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org