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 <[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
