JNDI Lookups, and UserTransation lookup breakdown
by Jay Balunas
These are my findings during my investigation of the
"IntitialContext.lookup" calls. Remember from my previous email that all
lookups are routed through the "org.jboss.seam.util.Naming" class.
Where do we do JNDI lookups?
---------------------------------------
Below are all of the places in the code where Seam performs these look ups:
* org.jboss.seam.bpm.Jbpm.initJbpmConfiguration()*
- Naming.getInitialContext().lookup(jbpmConfigurationJndiName);
-
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/bpm/Jb...
* org.jboss.seam.jms.ManagedQueueSender.getQueue()*
- Naming.getInitialContext().lookup(queueJndiName);
-
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/jms/Ma...
* org.jboss.seam.jms.ManagedTopicPublisher.getTopic()*
- Naming.getInitialContext().lookup(topicJndiName);
-
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/jms/Ma...
* org.jboss.seam.jms.QueueConnection.getQueueConnectionFactory()*
- Naming.getInitialContext().lookup(queueConnectionFactoryJndiName);
-
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/jms/Qu...
* org.jboss.seam.jms.TopicConnection.getTopicConnectionFactory()*
- Naming.getInitialContext().lookup(topicConnectionFactoryJndiName);
-
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/jms/To...
* org.jboss.seam.mail.MailSession.getSession()*
- Naming.getInitialContext().lookup(getSessionJndiName());
-
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/mail/M...
*
org.jboss.seam.persistence.ManagedHibernateSession.getSessionFactoryFromJndiOrValueBinding()*
- Naming.getInitialContext().lookup(sessionFactoryJndiName);
-
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/persis...
*
org.jboss.seam.persistence.ManagedPersistenceContext.getEntityManagerFactoryFromJndiOrValueBinding()*
- Naming.getInitialContext().lookup(persistenceUnitJndiName);
-
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/persis...
* org.jboss.seam.transaction.Transaction.getUserTransaction()*
- Naming.getInitialContext();
- context.lookup("java:comp/UserTransaction");
- context.lookup("UserTransaction");
-
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/transa...
* org.jboss.seam.util.EJB.getEJBContext()*
- Naming.getInitialContext().lookup(ejbContextName);
- Naming.getInitialContext().lookup(STANDARD_EJB_CONTEXT_NAME);
-
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/util/E...
* org.jboss.seam.Component.instantiateSessionBean()*
- Naming.getInitialContext().lookup(jndiName);
-
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/Compon...
JNDI Lookups
---------------------
The important thing to investigate is who the the big culprit(s) are - who
is making all the lookups. We all obviously had our suspicions, and they
were right.
A single user making a single request to the Seam user forum front page
performs 114 JNDI lookups for "java:comp/UserTransation". This means that
not only are 144 instances of IntialContext created, but we have 114 actual
lookups as well. This is nearly linear with 2 requests creating 228 JNDI
lookups + some for ajax4jsf caching calls as described below. Extrapolating
to the 25 user test that would be 25x114=2850 jndi lookups for each round of
requests.
At least for the wiki page I am testing there were no other JNDI lookups.
Who is looking up "java:comp/UserTransation"
--------------------------------------------------------
All of these calls can be traced to Transaction.instance(). I broke down
all of the calls to Transaction.instance() during a single request to the
user forum page on the wiki.
81 - seam.util.Work.workInTransaction(Work.java:34) via
(TransactionInterceptor.java:34)
1 -
SeamPhaseListener.handleTransactionsBeforePhase(SeamPhaseListener.java:319)
3 -
SeamPhaseListener.begin(SeamPhaseListener.java:591)
3 -
SeamPhaseListener.begin(SeamPhaseListener.java:594)
3 - SeamPhaseListener.commitOrRollback(SeamPhaseListener.java:611)
3 - SeamPhaseListener.commitOrRollback(SeamPhaseListener.java:614)
8 -
ManagedPersistenceContext.joinTransaction(ManagedPersistenceContext.java:120)
6 -
Contexts.flushAndDestroyContexts(Contexts.java:331)
6 -
ManagedPersistenceContext.close(ManagedPersistenceContext.java:192)
-------------
114 - Total
I then broke it down by which JSF lifecycle phase it was done in.
Phase Breakdown:
------------------
3 - During RESTORE_VIEW
2 - Between RESTORE_VIEW and RENDER_RESPONSE
91 - During RENDER_RESPONSE
18 - After RENDER_RESPONSE
----------
114 total
I then did the same break down on a second follow up request with the same
session
Second Request showed a different distribution:
------------------------------------------------
3 - During RESTORE_VIEW
2 - Between RESTORE_VIEW and RENDER_RESPONSE
91 - During RENDER_RESPONSE
5 - After RENDER_RESPONSE
3 - During 2nd RESTORE_VIEW
0 - Between 2nd RESTORE_VIEW and RENDER_RESPONSE
1 - During 2nd RENDER_RESPONSE
3 - After 2nd RENDER_RESPONSE
3 - During 3rd RESTORE_VIEW
0 - Between 3rd RESTORE_VIEW and RENDER_RESPONSE
1 - During 3rd RENDER_RESPONSE
16 - After 3rd RENDER_RESPONSE
------------
128 total
The extra 14 lookups are all during the extra 2 mini requests. They all
pass through this ajax4jsf class
"org.ajax4jsf.resource.ResourceLifecycle.invokePhaseListener(ResourceLifecycle.java:[199/201])".
I'm assuming that these extra calls are related to page fragment caching
and/or resources that are provided through the ajax4jsf
InternetResourceService. Christian can you confirm?
Conclusions:
---------------------
We obviously need to find more ways to improve this behavior. The primary
offender is "Work.java" (see:
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/util/W...).
This single line is checking if the transaction is currently active.
81
time it is active and processing continues as normal. Is there a way we can
cache this value for the length of the request (either the transaction, or
the result)? Caching the result could be bad if something changed during
the request, so we would need the actual transaction.
Also many of the lookups were the result of EL processing during the
RENDER_RESPONSE phase. Ideally these would primarily be read-only requests
or close to it. Could there be a way to disable the transactional calls for
items somehow tagged read only? I have not give that much thought yet so it
might need some flushing out ;-)
These finding just cover the wiki application. We need to do similar
investigations with other applications like dvdstore and chatroom to
exercise some of the other areas.
More to come, but any comments suggestions, or ideas for improving this are
welcome :-)
-Jay
--
blog: http://in.relation.to/Bloggers/Jay
17 years, 10 months
Re: [Richfaces-exadel] Fwd: [seam-dev] Some profiling of blockingthreads
by Jay Balunas
forgot to cc seam-dev :-)
On Thu, Oct 2, 2008 at 9:51 AM, Jay Balunas <tech4j(a)gmail.com> wrote:
>
>
> On Wed, Oct 1, 2008 at 8:12 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
>
>> Jay,
>>
>> This is great work and very interesting to follow.
>
> thanks
>
>>
>>
>> I would like to make a suggestion regarding the tests. Putting the
>> wiki under test is extremely valuable because it is a complex
>> application and therefore reflective of our users' applications.
>> However, it is tricky for others to follow along, because as you
>> mentioned, it is not trivial to setup. To supplement those tests,
>> perhaps you can generate a seam-gen application with a test schema
>> (perhaps stealing from one of the example application) so that we can
>> compare numbers with yours. What makes a seam-gen application valuable
>> to test is that it uses the Seam Application Framework, which is a
>> well known performance bottleneck in Seam because of its excessive use
>> of getInstance() and joinTransaction().
>
>
> I think you are correct for the reasons you state and others. The wiki
> example also does not use EJBs which I suspect a large number of seam apps
> do. I was planning on looking at the dvdstore next and that uses several
> technologies (EJB, JBPM, etc...).
>
> However I could look at a seam-gen EAR project as well, but I would like to
> get some other opinions on this. I do not think that I will have enough
> time to do both.
>
>
>>
>> It shouldn't take too long to generate the seam-gen application and
>> reverse engineer the schema. The tedious part is generating a whole
>> bunch of fake data, but emacs or vi should make quick work of that.
>
>
> Yeah - the fake data is tricky, but there are some tools that can do this
> for us.
>
>
>>
>>
>> -Dan
>>
>> On Wed, Oct 1, 2008 at 6:02 PM, Jay Balunas <tech4j(a)gmail.com> wrote:
>> > The example I was using was the seam wiki example, but that is not a
>> trivial
>> > thing to set up. I have not tried the same profiling on the other seam
>> > examples so I am not 100% sure that they will show the same behavior,
>> > although I would think that they would.
>> >
>> > As for the profiler report - what are you looking for exactly?
>> Basically
>> > under load (25 users) I noticed threads blocking on the
>> > ViewHandlerWrapper.fillChain method. The details are below.
>> >
>> > Regards,
>> > Jay
>> >
>> > On Wed, Oct 1, 2008 at 5:56 PM, Alexandr Smirnov <asmirnov(a)exadel.com>
>> > wrote:
>> >>
>> >> Jay, can you send me profiler report or a reference application ?
>> >>
>> >> Jay Balunas wrote:
>> >> > I was able to update and build with RichFaces 3.3.0-SNAPSHOT and saw
>> >> > your changes.
>> >> >
>> >> > The good news is that I no longer see any blocking threads in the
>> >> > "org.ajax4jsf.application.
>> >> > AjaxViewHandler" - none at all which is great.
>> >> >
>> >> > The bad news is that the performance has not increased in any
>> >> > meaningful or repeatable way.
>> >> >
>> >> > During my profiling I noticed a definite increase in the blocked
>> >> > threads performing JNDI lookups. My theory is that the
>> >> > AjaxViewHandler was acting as a gate and effectively slowing down
>> >> > concurrent requests into Seam proper. These threads now fly straight
>> >> > through and into Seam processing. They the end up blocked with the
>> >> > other threads performing the lookups.
>> >> >
>> >> > I will continue to look at the lookup issues, and let you all know
>> >> > what I find.
>> >> >
>> >> > -Jay
>> >> >
>> >> >
>> >> > On Tue, Sep 30, 2008 at 2:05 PM, Jay Balunas <jbalunas(a)redhat.com
>> >> > <mailto:jbalunas@redhat.com>> wrote:
>> >> >
>> >> > Excellent - I will build from sources and test the changes.
>> >> >
>> >> > I'll post the findings up on seam-dev.
>> >> >
>> >> > -Jay
>> >> > ----- "Nick Belaevski" <nbelaevski(a)exadel.com
>> >> > <mailto:nbelaevski@exadel.com>> wrote:
>> >> >
>> >> > > All,
>> >> > >
>> >> > > I've created JIRA issue for this optimization:
>> >> > > https://jira.jboss.org/jira/browse/RF-4554 and have just fixed
>> it.
>> >> > >
>> >> > > As from now ViewHandlerWrapper#fillChain method is not
>> >> > synchronized
>> >> > > anymore.
>> >> > >
>> >> > > Best regards,
>> >> > > Nick Belaevski
>> >> > >
>> >> > > > -----Original Message-----
>> >> > > > From: richfaces-exadel-bounces(a)redhat.com
>> >> > <mailto:richfaces-exadel-bounces@redhat.com>
>> >> > [mailto:richfaces-exadel- <mailto:richfaces-exadel->
>> >> > > > bounces(a)redhat.com <mailto:bounces@redhat.com>] On Behalf Of
>> >> > Max Rydahl Andersen
>> >> > > > Sent: Tuesday, September 30, 2008 10:32 AM
>> >> > > > To: Jay Balunas; richfaces-exadel(a)redhat.com
>> >> > <mailto:richfaces-exadel@redhat.com>
>> >> > > > Subject: Re: [Richfaces-exadel] Fwd: [seam-dev] Some
>> profiling
>> >> > of
>> >> > > > blockingthreads
>> >> > > >
>> >> > > > Sergey/Nik ? Any news on this one ?
>> >> > > >
>> >> > > > /max
>> >> > > >
>> >> > > > > Hi Guys,
>> >> > > > >
>> >> > > > > I have been doing some performance testing on seam
>> >> > applications
>> >> > > and have
>> >> > > > > been able to post some of the results. One of the areas
>> that
>> >> > I
>> >> > > have
>> >> > > > > investigated so far was blocking/waiting threads.
>> >> > > > >
>> >> > > > > In my example I am running 25 concurrent users and hitting
>> the
>> >> > > seam wiki
>> >> > > > > example. I am seeing blocked threads waiting on
>> >> > > > > "org.ajax4jsf.application.AjaxViewHandler".
>> >> > > > > I have investigated it a bit (see below), and have included
>> >> > some
>> >> > > of the
>> >> > > > > discussions on the seam-dev list.
>> >> > > > >
>> >> > > > > I would like to get an opinion of the synchronized
>> fillChain
>> >> > > method, and
>> >> > > > > see
>> >> > > > > if there is another way to handle this.
>> >> > > > >
>> >> > > > > Thoughts?
>> >> > > > >
>> >> > > > > Thanks,
>> >> > > > > Jay
>> >> > > > >
>> >> > > > > ---------- Forwarded message ----------
>> >> > > > > From: Emmanuel Bernard <emmanuel(a)hibernate.org
>> >> > <mailto:emmanuel@hibernate.org>>
>> >> > > > > Date: Thu, Sep 25, 2008 at 10:01 AM
>> >> > > > > Subject: Re: [seam-dev] Some profiling of blocking threads
>> >> > > > > To: Jay Balunas <tech4j(a)gmail.com <mailto:tech4j@gmail.com
>> >>
>> >> > > > > Cc: Pete Muir <pmuir(a)redhat.com <mailto:pmuir@redhat.com
>> >>,
>> >> > "seam-dev(a)lists.jboss.org <mailto:seam-dev@lists.jboss.org>" <
>> >> > > > > seam-dev(a)lists.jboss.org <mailto:seam-dev@lists.jboss.org
>> >>
>> >> > > > >
>> >> > > > >
>> >> > > > >
>> >> > > > > On Sep 25, 2008, at 09:17, Jay Balunas wrote:
>> >> > > > >
>> >> > > > > org.ajax4jsf.application.AjaxViewHandler
>> >> > > > >> --------------------------------------------
>> >> > > > >> - This was not a large % of the blocked threads but
>> caught
>> >> > my
>> >> > > eye as a
>> >> > > > >> potential trouble spot because it seemed directly related
>> to
>> >> > > ajax
>> >> > > > calls.
>> >> > > > >> - This was easier to track down and the root cause is in
>> the
>> >> > > > >> org.ajax4jsf.application.ViewHandlerWrapper class.
>> >> > > > >> - see
>> >> > > > >>
>> >> > > >
>> >> > >
>> >> >
>> >> >
>> http://anonsvn.jboss.org/repos/richfaces/trunk/framework/api/src/main/java
>> >> > > > /org/ajax4jsf/application/ViewHandlerWrapper.java
>> >> > > > >> - The problem is all the calls to "fillChain" which is a
>> >> > > synchronized
>> >> > > > >> method in the class.
>> >> > > > >> - We need to find out how often the "_initialized" field
>> is
>> >> > > false - is
>> >> > > > >> this once a request, once for each component, etc...
>> >> > > > >> - it appears to be called many times - I will look
>> further
>> >> > into
>> >> > > this.
>> >> > > > >>
>> >> > > > >>
>> >> > > > > I will raise this the richfaces dev guys, and see what can
>> be
>> >> > > done.
>> >> > > > >
>> >> > > > >
>> >> > > > > Using the double check lock pattern with a volatile should
>> >> > make
>> >> > > things
>> >> > > > > better. It has to be done right though :)
>> >> > > > >
>> >> > > > >
>> >> > > > >
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > > --
>> >> > > > /max
>> >> > > >
>> >> > > > _______________________________________________
>> >> > > > Richfaces-exadel mailing list
>> >> > > > Richfaces-exadel(a)redhat.com <mailto:
>> Richfaces-exadel(a)redhat.com>
>> >> > > > https://www.redhat.com/mailman/listinfo/richfaces-exadel
>> >> > >
>> >> > > _______________________________________________
>> >> > > Richfaces-exadel mailing list
>> >> > > Richfaces-exadel(a)redhat.com <mailto:
>> Richfaces-exadel(a)redhat.com>
>> >> > > https://www.redhat.com/mailman/listinfo/richfaces-exadel
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > blog: http://in.relation.to/Bloggers/Jay
>> >> >
>> ------------------------------------------------------------------------
>> >> >
>> >> > _______________________________________________
>> >> > Richfaces-exadel mailing list
>> >> > Richfaces-exadel(a)redhat.com
>> >> > https://www.redhat.com/mailman/listinfo/richfaces-exadel
>> >>
>> >
>> >
>> >
>> > --
>> > blog: http://in.relation.to/Bloggers/Jay
>> >
>> > _______________________________________________
>> > Richfaces-exadel mailing list
>> > Richfaces-exadel(a)redhat.com
>> > https://www.redhat.com/mailman/listinfo/richfaces-exadel
>> >
>>
>>
>>
>> --
>> Dan Allen
>> Software consultant | Author of Seam in Action
>>
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>>
>> NOTE: While I make a strong effort to keep up with my email on a daily
>> basis, personal or other work matters can sometimes keep me away
>> from my email. If you contact me, but don't hear back for more than a
>> week,
>> it is very likely that I am excessively backlogged or the message was
>> caught in the spam filters. Please don't hesitate to resend a message if
>> you feel that it did not reach my attention.
>>
>
>
>
> --
> blog: http://in.relation.to/Bloggers/Jay
>
--
blog: http://in.relation.to/Bloggers/Jay
17 years, 10 months
good job on the release
by Dan Allen
I know that right now the release process for Seam is a tedious
process, so congratulations to Norman for leading up the effort to get
2.1.0.CR1 out the door. I'm sorry to have to say, but hopefully you
will be right back at it for the GA.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
17 years, 10 months
Re: [Richfaces-exadel] Fwd: [seam-dev] Some profiling of blockingthreads
by Jay Balunas
I was able to update and build with RichFaces 3.3.0-SNAPSHOT and saw your
changes.
The good news is that I no longer see any blocking threads in the
"org.ajax4jsf.application.AjaxViewHandler" - none at all which is great.
The bad news is that the performance has not increased in any meaningful or
repeatable way.
During my profiling I noticed a definite increase in the blocked threads
performing JNDI lookups. My theory is that the AjaxViewHandler was acting
as a gate and effectively slowing down concurrent requests into Seam
proper. These threads now fly straight through and into Seam processing.
They the end up blocked with the other threads performing the lookups.
I will continue to look at the lookup issues, and let you all know what I
find.
-Jay
On Tue, Sep 30, 2008 at 2:05 PM, Jay Balunas <jbalunas(a)redhat.com> wrote:
> Excellent - I will build from sources and test the changes.
>
> I'll post the findings up on seam-dev.
>
> -Jay
> ----- "Nick Belaevski" <nbelaevski(a)exadel.com> wrote:
>
> > All,
> >
> > I've created JIRA issue for this optimization:
> > https://jira.jboss.org/jira/browse/RF-4554 and have just fixed it.
> >
> > As from now ViewHandlerWrapper#fillChain method is not synchronized
> > anymore.
> >
> > Best regards,
> > Nick Belaevski
> >
> > > -----Original Message-----
> > > From: richfaces-exadel-bounces(a)redhat.com [mailto:richfaces-exadel-
> > > bounces(a)redhat.com] On Behalf Of Max Rydahl Andersen
> > > Sent: Tuesday, September 30, 2008 10:32 AM
> > > To: Jay Balunas; richfaces-exadel(a)redhat.com
> > > Subject: Re: [Richfaces-exadel] Fwd: [seam-dev] Some profiling of
> > > blockingthreads
> > >
> > > Sergey/Nik ? Any news on this one ?
> > >
> > > /max
> > >
> > > > Hi Guys,
> > > >
> > > > I have been doing some performance testing on seam applications
> > and have
> > > > been able to post some of the results. One of the areas that I
> > have
> > > > investigated so far was blocking/waiting threads.
> > > >
> > > > In my example I am running 25 concurrent users and hitting the
> > seam wiki
> > > > example. I am seeing blocked threads waiting on
> > > > "org.ajax4jsf.application.AjaxViewHandler".
> > > > I have investigated it a bit (see below), and have included some
> > of the
> > > > discussions on the seam-dev list.
> > > >
> > > > I would like to get an opinion of the synchronized fillChain
> > method, and
> > > > see
> > > > if there is another way to handle this.
> > > >
> > > > Thoughts?
> > > >
> > > > Thanks,
> > > > Jay
> > > >
> > > > ---------- Forwarded message ----------
> > > > From: Emmanuel Bernard <emmanuel(a)hibernate.org>
> > > > Date: Thu, Sep 25, 2008 at 10:01 AM
> > > > Subject: Re: [seam-dev] Some profiling of blocking threads
> > > > To: Jay Balunas <tech4j(a)gmail.com>
> > > > Cc: Pete Muir <pmuir(a)redhat.com>, "seam-dev(a)lists.jboss.org" <
> > > > seam-dev(a)lists.jboss.org>
> > > >
> > > >
> > > >
> > > > On Sep 25, 2008, at 09:17, Jay Balunas wrote:
> > > >
> > > > org.ajax4jsf.application.AjaxViewHandler
> > > >> --------------------------------------------
> > > >> - This was not a large % of the blocked threads but caught my
> > eye as a
> > > >> potential trouble spot because it seemed directly related to
> > ajax
> > > calls.
> > > >> - This was easier to track down and the root cause is in the
> > > >> org.ajax4jsf.application.ViewHandlerWrapper class.
> > > >> - see
> > > >>
> > >
> >
> http://anonsvn.jboss.org/repos/richfaces/trunk/framework/api/src/main/java
> > > /org/ajax4jsf/application/ViewHandlerWrapper.java
> > > >> - The problem is all the calls to "fillChain" which is a
> > synchronized
> > > >> method in the class.
> > > >> - We need to find out how often the "_initialized" field is
> > false - is
> > > >> this once a request, once for each component, etc...
> > > >> - it appears to be called many times - I will look further into
> > this.
> > > >>
> > > >>
> > > > I will raise this the richfaces dev guys, and see what can be
> > done.
> > > >
> > > >
> > > > Using the double check lock pattern with a volatile should make
> > things
> > > > better. It has to be done right though :)
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > /max
> > >
> > > _______________________________________________
> > > Richfaces-exadel mailing list
> > > Richfaces-exadel(a)redhat.com
> > > https://www.redhat.com/mailman/listinfo/richfaces-exadel
> >
> > _______________________________________________
> > Richfaces-exadel mailing list
> > Richfaces-exadel(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/richfaces-exadel
>
--
blog: http://in.relation.to/Bloggers/Jay
17 years, 10 months
Fwd: [jbossseam-issues] [JBoss JIRA] Deleted: (JBSEAM-3467) Add conversation restart functionality
by Pete Muir
Is there a particular reason for deleting this JIRA issue?
We should not be deleting JIRA issues unless they are filed in error.
Begin forwarded message:
> From: "Christian Bauer (JIRA)" <jira-events(a)lists.jboss.org>
> Date: 29 September 2008 19:59:21 BST
> To: jbossseam-issues(a)lists.jboss.org
> Subject: [jbossseam-issues] [JBoss JIRA] Deleted: (JBSEAM-3467) Add
> conversation restart functionality
>
>
> [ https://jira.jboss.org/jira/browse/JBSEAM-3467?page=com.atlassian.jira.pl...
> ]
>
> Christian Bauer deleted JBSEAM-3467:
> ------------------------------------
>
>
>> Add conversation restart functionality
>> --------------------------------------
>>
>> Key: JBSEAM-3467
>> URL: https://jira.jboss.org/jira/browse/JBSEAM-3467
>> Project: Seam
>> Issue Type: Feature Request
>> Environment: Windows Server 2003
>> JBoss EAP 4.3.0.CP02_FP01
>> JRockit 1.5 JVM
>> Reporter: asookazian
>>
>> need functionality that will restart conversation (via
>> endBeforeRirect() and begin() methods in Conversation API or
>> similar). suggested solution from JBoss dev sppt did not work (see
>> forum URL below). workaround was to create a private method in
>> SFSB that set instance variables to null and continue with existing
>> LRC. a more elegant solution is preferred (Seam ending current
>> LRC, creating new LRC and transferring state from old conversation
>> variables to new one via restart() api call).
>> Scenario: conversation begin demarcation is driven by selection of
>> a drop-down (h:selectOneMenu) value. when user selects the new
>> value the second time, the conversation should end and start a new
>> LRC. Solution from dev sppt did not work b/c the
>> endBeforeRedirect() method was being called in action binding
>> method for drop-down in SFSB and subsequently, in pages.xml, <begin-
>> conversation> was coded prior to redirect to same xhtml.
>> Result: after the JSF was re-rendered after 2nd drop-down
>> selection, the value in the drop-down was set to "select value"
>> which is the default value. It should have been set to the 2nd
>> selection. The reason this is happening is b/c the instance
>> variables are conversation-scoped (b/c the SFSB is conversation-
>> scoped) and thus are presumably no longer available to the second
>> LRC (which strangely enough is still showing the original cid in
>> the debug.seam page after refresh!)
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the
> administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
> _______________________________________________
> seam-issues mailing list
> seam-issues(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-issues
17 years, 10 months
InitialContext performance issues
by Jay Balunas
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
17 years, 10 months
Hudson
by Nicklas Karlsson
Not directly a Seam issue but:
The Hudson server seems to be down, whom to contact?
---
Nik
17 years, 10 months
