[seam-dev] InitialContext performance issues

[Jay Balunas]

ok great - I have intentionally not updated my svn for performance testing
so that day to day changes do not inadvertently effect the tests.

On Wed, Oct 1, 2008 at 9:14 AM, Shane Bryzak <shane.bryzak at jboss.com> wrote:

> Jay Balunas wrote:
>
>> I have been looking more into the InitialContext and some of the
>> performance issues surrounding it.
>>
>> There are really a couple of things to look at.  One is how the
>> InitialContext is created, and manged, and the other broad category is how
>> often and what items are looked up?  I have investigated the first, and have
>> begun investigating the second.
>>
>> InitialContext creation and management
>> ------------------------------------------------
>> The only location were seam creates and manages the InitialContext is the
>> "org.jboss.seam.util.Naming" class (see:
>> http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/util/Naming.java?r=5444).
>> The properties are set in one location and done only once in the
>> initialization of seam (see:
>> http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/init/Initialization.java?r=9116#l915).
>>
>> I see two issues here - one is creating the initial context every single
>> time it is needed, and the other is processing/checking the properties every
>> time it is called.
>>
>> The first issue would require some caching mechanism or logic for reuse.
>>  I am not an expert on when it makes sense to reuse an instance of the
>> InitialContext, and when we need to get it fresh.  I can say that we
>> currently use they exact same properties to initialize it and those are set
>> during Seam initialization and do not appear to ever change once created.
>>  Is there a way to cache and optimize this instantiation?
>>
>> The second issue is that we do a certain amount of processing every time
>> the context is requested, this could be optimized.  Currently I see a few
>> blocked threads on the "props.size()" call in the Naming class which is a
>> synchronized method on the Hashtable.  This could easily be avoided.
>>  Although we need to maintain the logic that if the property list is empty
>> we continue to call "new InitialContext()" and not pass in the properties
>> object.  This is because the first thing the InitialContext constructor does
>> with a properties object is clone it which can be costly.  I have attached a
>> patch that implements these changes for review.
>>
>> Another item I noticed is that the only place (excluding some test code)
>> that does not use "Naming.getInitialContext()" is the
>> "org.jboss.seam.remoting.messaging.JBossConnectionProvider".  It using the
>> "new InitialContext()" directly.  Shane - is there a reason for this?
>>
> That class is gone now, I removed it recently.
>
>>
>> I'll write up my findings on the lookup usage asap.
>>
>> Thanks,
>> Jay
>> --
>> blog: http://in.relation.to/Bloggers/Jay
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>
>


-- 
blog: http://in.relation.to/Bloggers/Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20081001/da7cf693/attachment.html