Re: 3.0.4 and repetitive method name/signature problem (class enhancement)

Thu, 16 Nov 2006 20:23:58 -0800

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to