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

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&gt; 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&gt; 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

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/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? > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev >