[seam-dev] InitialContext performance issues

[Gavin King]

Good work, Jay. I'm surprised to find that this is an issue. Really, creation of
an InitialContext should be very lightweight (it should be optimized by the
appserver). But if it's not, then Seam should optimize it.

On Tue, Sep 30, 2008 at 2:01 PM, Jay Balunas <tech4j at gmail.com> 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?
>
> 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
>
>



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org