2010/8/18 Ivan <[email protected]> > 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 ? > Does it always occur or just in a special situation. I tried deploying a web app in console and it seems normal. Does your web app contain some special things?
-rex > 2010/8/17 David Jencks <[email protected]> > > >> 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 > -- Lei Wang (Rex) rwonly AT apache.org
