geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: [DISCUSS] Geronimo web profile 3.0 startup time
Date Wed, 18 Aug 2010 06:37:19 GMT
Agree to use some professional tools ...

I have to say sorry to ApplicationJNDI gbeans, the root cause of startup
time is due to the jaxb unmarshall of the web.xml file  :-(

Due to the Servlet 3.0, we need to calculate the security constraints while
starting the web applications, so I parse the web.xml file again in the
staring process, and seems it takes some time even with a simple web.xml
file. The first idea jumped to my mind is to serialize the WebApp object in
the config.ser file, but those jaxb class are not serializable. So.
currently, I am thinking to create some internal objects required for
securiy calculation, mightbe like those info objects in OpenEJB. So, we
could rapid those web applications.
Thoughts ? For this is not a block issue, I will add it on the plan list.

By the way, I also found that currently, it takes a long time to do the
deployment, even a simple web application, sometimes, it might need two or
three minutes, does anyone find it ?

2010/8/17 David Jencks <david_jencks@yahoo.com>

>
> On Aug 16, 2010, at 6:25 PM, Ivan wrote:
>
> > Hi
> >     Recently, I looked at a little about the Geronimo web-profile 3.0
> startup time, comparing with the 2.2 release, the components below takes
> more time :
> >     a. Start up Tomcat container, it took 3s while 2s in the past. At
> first glance at it, it is caused by TomcatServerGBean, guess that it is due
> to the new Tomcat 7, will double check it later.
> >     b. ApplicationJndi GBean is also an issue, for the simple
> remote-deploy-webapplication, it tooks more than 3s to startup the
> ApplicationJndi GBean.
> >     c. System-database also takes 11s at the first time startup, and it
> should be caused by some DB initialization work, we might try to do some
> initialization work in the building time.
> >
> >     Generally speaking, the most problem is for the item b, not sure why
> it took so much time for the jndi building, I have not checked it, anyone
> has ideas on it ? Another thing is that, in the past, I have some concern
> for the bundle copying, but currently, it seems that it does not affect the
> startup time too much :-)
>
> I think (b) is caused by something in xbean-naming federation code.
>  Overall the xbean-naming federation seems to be quite slow.  I haven't
> investigated why.  It seems to be fairly hard to write a working jndi
> implementation and there aren't really any tests for what it should do
> AFAIK.  I think the jndi implementation in openejb has some better design
> choices: the main one is that the Context implementation is clearly
> separated from the actual jndi tree data.  I don't know if we'll have time
> to try to speed this up before 3.0, but at least we know a little bit about
> where a major problem is.
>
> For (c) I wonder if derby is doing more work than it needs to.  Are we on
> an up to date version of derby?
>
> It's great to have this info about what is taking too much startup time
> even if we can't do much about it right now.
>
> thanks
> david jencks
>
>
> >
> > --
> > Ivan
>
>


-- 
Ivan

Mime
View raw message