4:51 p.m.
oh - I'm not saying this is the biggest part of the IntialContext blocks.
The largest by far is all the calls to "lookup". This was just the first
one that I pinned down, and seemed like an easy fix. I'm looking at the
lookup calls, and will post more on it.
FYI - When I profiled with the patch I included the block simply moved
farther down into the InitialContext creation code. So a real fix would be
limiting the number of instantiations, but as you say it might not be worth
the effort. We'll have to see once we have optimized else where.
-Jay
On Tue, Sep 30, 2008 at 4:37 PM, Gavin King <gavin(a)hibernate.org> wrote:
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(a)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/N...
> ).
>
> 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/I...
> ).
>
> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
--
blog: http://in.relation.to/Bloggers/Jay