tomcat 7.0.29 startup time

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

tomcat 7.0.29 startup time

Mark Struberg
Hi Lords and Ladies!

I'm currently wrangling with a doubled boot time on tomcat7.0.29 in comparison to 7.0.28 (12 webapps in my tc: 7.0.28 < 45s, 7.0.29 > 90s).

I'm aware that 7.0.29 now does the scanning for ServletContainerInitializer even if version=2.5 is specified. But there shall no class scanning be performed if metadata-complete="true" is set, right? The problem is that @HandlesTypes forces scanning. And regardless if you only scanning or the types registered via @HandlesTypes or searching for all - the startup time is almost the same. This is because the most expensive part is the file and zip handling...

So even if the webapp is metadata-complete, it still performs all the class scanning.
You can prove this by simply adding Apache MyFaces to a sample webapp. Any other sample which utilizes a ServletContainerInitializer and has @HandlesTypes will also do the job.

In my case it's even more fatal: I have the FacesServlet configured via web.xml, so the whole MyFaces ServletContextInitializer is not used at all...

Any ideas how we can ease the pain quickly?

I know the Servlet-EG 'clarified' that only recently, but being an EG member myself I know exactly that this can be reverted if it only got 'recently clarified'. Nothing is set in stone until a final MR spec with an absolute binding wording got released. Mark, others, what about explaining the impact to the EG again and maybe they change their mind?

For the long run you might be interested in commons-classscan we do over at commons atm. The idea is to have all sorts of ASF projects (tomcat, OpenWebBeans, OpenEJB, MyFaces, BVal, OpenJPA, ...) register their needs upfront and do the scanning only once.
But it will take a bit until we have something to show off I fear as most of us are under heavy load in other ASF projects as well.

LieGrue,
strub


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: tomcat 7.0.29 startup time

markt
On 25/07/2012 17:00, Mark Struberg wrote:

> Hi Lords and Ladies!
>
> I'm currently wrangling with a doubled boot time on tomcat7.0.29 in
> comparison to 7.0.28 (12 webapps in my tc: 7.0.28 < 45s, 7.0.29 >
> 90s).
>
> I'm aware that 7.0.29 now does the scanning for
> ServletContainerInitializer even if version=2.5 is specified. But
> there shall no class scanning be performed if
> metadata-complete="true" is set, right?

Wrong. I don't like this but the intent of the Servlet 3.0 EG was:
- ServletContainerInitializer cannot be disabled
- If a ServletContainerInitializer is found, then class-scanning will
take place

> Any ideas how we can ease the pain quickly?

The only option I see is a custom (non-spec compliant) Tomcat specific
feature that disables all of this.

> I know the Servlet-EG 'clarified' that only recently, but being an EG
> member myself I know exactly that this can be reverted if it only got
> 'recently clarified'. Nothing is set in stone until a final MR spec
> with an absolute binding wording got released. Mark, others, what
> about explaining the impact to the EG again and maybe they change
> their mind?

Not a chance. Been there tried that. Failed. The intent of the EG was
clear (within the EG) even if the expression of it wasn't.

> For the long run you might be interested in commons-classscan we do
> over at commons atm. The idea is to have all sorts of ASF projects
> (tomcat, OpenWebBeans, OpenEJB, MyFaces, BVal, OpenJPA, ...) register
> their needs upfront and do the scanning only once. But it will take a
> bit until we have something to show off I fear as most of us are
> under heavy load in other ASF projects as well.

I have been keeping an eye on that.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: tomcat 7.0.29 startup time

markt
On 28/07/2012 00:25, Mark Thomas wrote:

> On 25/07/2012 17:00, Mark Struberg wrote:
>> Hi Lords and Ladies!
>>
>> I'm currently wrangling with a doubled boot time on tomcat7.0.29 in
>> comparison to 7.0.28 (12 webapps in my tc: 7.0.28 < 45s, 7.0.29 >
>> 90s).
>>
>> I'm aware that 7.0.29 now does the scanning for
>> ServletContainerInitializer even if version=2.5 is specified. But
>> there shall no class scanning be performed if
>> metadata-complete="true" is set, right?
>
> Wrong. I don't like this but the intent of the Servlet 3.0 EG was:
> - ServletContainerInitializer cannot be disabled
> - If a ServletContainerInitializer is found, then class-scanning will
> take place
>
>> Any ideas how we can ease the pain quickly?
>
> The only option I see is a custom (non-spec compliant) Tomcat specific
> feature that disables all of this.

Ah. See the latest developments on
http://java.net/jira/browse/SERVLET_SPEC-36

Using an absolute ordering that specifies no fragments along with
metadata-complete=true should do the trick.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: tomcat 7.0.29 startup time

Mark Struberg
Hi Mark,

thanks for the clarifications, highly appreciated!

As far as the empty <absolute-ordering/> goes: After reading the spec again I've been down to that route as well. So far it didn't work out. Maybe I've just done something wrong - will revisit and try again. Should the <absolute-ordering/> only affect the jars with web-fragments, or does it disable scanning of all jars then?



I also discovered another possible impact:

Our scenario is to use 1 tomcat installation as 'quasi EAR' container. We use the shared.loader in conf/catalina.properties and set it to our own ${catalina.home}/applib directory which contains all our shared libraries (myfaces, openwebbeans, openjpa, ...).
For what I did understand by reading the servlet-3.0 spec is that only fragments and classes in either WEB-INF/classes or WEB-INF/lib/*.jar shall get scanned by tomcat, right? But it seems that also all our shared.loader jars will get scanned as well. I have not explicitly debugged thru, but from the startup times I see no other explanation as our WARs contain almost no jars.

If I set the jarToSkip=*.jar then the boot time is back to normal.


Is there an explanation in the servlet spec, or does tomcat scan a bit too much yet?


txs and LieGrue,
strub



----- Original Message -----

> From: Mark Thomas <[hidden email]>
> To: Tomcat Developers List <[hidden email]>
> Cc:
> Sent: Saturday, July 28, 2012 2:36 AM
> Subject: Re: tomcat 7.0.29 startup time
>
> On 28/07/2012 00:25, Mark Thomas wrote:
>>  On 25/07/2012 17:00, Mark Struberg wrote:
>>>  Hi Lords and Ladies!
>>>
>>>  I'm currently wrangling with a doubled boot time on tomcat7.0.29 in
>>>  comparison to 7.0.28 (12 webapps in my tc: 7.0.28 < 45s, 7.0.29 >
>>>  90s).
>>>
>>>  I'm aware that 7.0.29 now does the scanning for
>>>  ServletContainerInitializer even if version=2.5 is specified. But
>>>  there shall no class scanning be performed if
>>>  metadata-complete="true" is set, right?
>>
>>  Wrong. I don't like this but the intent of the Servlet 3.0 EG was:
>>  - ServletContainerInitializer cannot be disabled
>>  - If a ServletContainerInitializer is found, then class-scanning will
>>  take place
>>
>>>  Any ideas how we can ease the pain quickly?
>>
>>  The only option I see is a custom (non-spec compliant) Tomcat specific
>>  feature that disables all of this.
>
> Ah. See the latest developments on
> http://java.net/jira/browse/SERVLET_SPEC-36
>
> Using an absolute ordering that specifies no fragments along with
> metadata-complete=true should do the trick.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: tomcat 7.0.29 startup time

Mark Struberg
tried the empty absolute ordering again and it doesn't seem to help. I fear that @HandlesTypes again has higher precedence than the web-fragment ordering/disabling.

LieGrue,
strub



----- Original Message -----

> From: Mark Struberg <[hidden email]>
> To: Tomcat Developers List <[hidden email]>
> Cc:
> Sent: Sunday, July 29, 2012 1:14 PM
> Subject: Re: tomcat 7.0.29 startup time
>
> Hi Mark,
>
> thanks for the clarifications, highly appreciated!
>
> As far as the empty <absolute-ordering/> goes: After reading the spec
> again I've been down to that route as well. So far it didn't work out.
> Maybe I've just done something wrong - will revisit and try again. Should
> the <absolute-ordering/> only affect the jars with web-fragments, or does
> it disable scanning of all jars then?
>
>
>
> I also discovered another possible impact:
>
> Our scenario is to use 1 tomcat installation as 'quasi EAR' container.
> We use the shared.loader in conf/catalina.properties and set it to our own
> ${catalina.home}/applib directory which contains all our shared libraries
> (myfaces, openwebbeans, openjpa, ...).
> For what I did understand by reading the servlet-3.0 spec is that only fragments
> and classes in either WEB-INF/classes or WEB-INF/lib/*.jar shall get scanned by
> tomcat, right? But it seems that also all our shared.loader jars will get
> scanned as well. I have not explicitly debugged thru, but from the startup times
> I see no other explanation as our WARs contain almost no jars.
>
> If I set the jarToSkip=*.jar then the boot time is back to normal.
>
>
> Is there an explanation in the servlet spec, or does tomcat scan a bit too much
> yet?
>
>
> txs and LieGrue,
> strub
>
>
>
> ----- Original Message -----
>>  From: Mark Thomas <[hidden email]>
>>  To: Tomcat Developers List <[hidden email]>
>>  Cc:
>>  Sent: Saturday, July 28, 2012 2:36 AM
>>  Subject: Re: tomcat 7.0.29 startup time
>>
>>  On 28/07/2012 00:25, Mark Thomas wrote:
>>>   On 25/07/2012 17:00, Mark Struberg wrote:
>>>>   Hi Lords and Ladies!
>>>>
>>>>   I'm currently wrangling with a doubled boot time on
> tomcat7.0.29 in
>>>>   comparison to 7.0.28 (12 webapps in my tc: 7.0.28 < 45s, 7.0.29
>>
>>>>   90s).
>>>>
>>>>   I'm aware that 7.0.29 now does the scanning for
>>>>   ServletContainerInitializer even if version=2.5 is specified. But
>>>>   there shall no class scanning be performed if
>>>>   metadata-complete="true" is set, right?
>>>
>>>   Wrong. I don't like this but the intent of the Servlet 3.0 EG was:
>>>   - ServletContainerInitializer cannot be disabled
>>>   - If a ServletContainerInitializer is found, then class-scanning will
>>>   take place
>>>
>>>>   Any ideas how we can ease the pain quickly?
>>>
>>>   The only option I see is a custom (non-spec compliant) Tomcat specific
>>>   feature that disables all of this.
>>
>>  Ah. See the latest developments on
>>  http://java.net/jira/browse/SERVLET_SPEC-36
>>
>>  Using an absolute ordering that specifies no fragments along with
>>  metadata-complete=true should do the trick.
>>
>>  Mark
>>
>>
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: [hidden email]
>>  For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: tomcat 7.0.29 startup time

markt
Mark Struberg <[hidden email]> wrote:

>tried the empty absolute ordering again and it doesn't seem to help. I
>fear that @HandlesTypes again has higher precedence than the
>web-fragment ordering/disabling.

The 'clarification' from the EG is post the last release. I'm pretty sure some code changes are required. Feel free to open a bz issue so this isn't forgotten.

Mark

>
>LieGrue,
>strub
>
>
>
>----- Original Message -----
>> From: Mark Struberg <[hidden email]>
>> To: Tomcat Developers List <[hidden email]>
>> Cc:
>> Sent: Sunday, July 29, 2012 1:14 PM
>> Subject: Re: tomcat 7.0.29 startup time
>>
>> Hi Mark,
>>
>> thanks for the clarifications, highly appreciated!
>>
>> As far as the empty <absolute-ordering/> goes: After reading the spec
>
>> again I've been down to that route as well. So far it didn't work
>out.
>> Maybe I've just done something wrong - will revisit and try again.
>Should
>> the <absolute-ordering/> only affect the jars with web-fragments, or
>does
>> it disable scanning of all jars then?
>>
>>
>>
>> I also discovered another possible impact:
>>
>> Our scenario is to use 1 tomcat installation as 'quasi EAR'
>container.
>> We use the shared.loader in conf/catalina.properties and set it to
>our own
>> ${catalina.home}/applib directory which contains all our shared
>libraries
>> (myfaces, openwebbeans, openjpa, ...).
>> For what I did understand by reading the servlet-3.0 spec is that
>only fragments
>> and classes in either WEB-INF/classes or WEB-INF/lib/*.jar shall get
>scanned by
>> tomcat, right? But it seems that also all our shared.loader jars will
>get
>> scanned as well. I have not explicitly debugged thru, but from the
>startup times
>> I see no other explanation as our WARs contain almost no jars.
>>
>> If I set the jarToSkip=*.jar then the boot time is back to normal.
>>
>>
>> Is there an explanation in the servlet spec, or does tomcat scan a
>bit too much
>> yet?
>>
>>
>> txs and LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>>>  From: Mark Thomas <[hidden email]>
>>>  To: Tomcat Developers List <[hidden email]>
>>>  Cc:
>>>  Sent: Saturday, July 28, 2012 2:36 AM
>>>  Subject: Re: tomcat 7.0.29 startup time
>>>
>>>  On 28/07/2012 00:25, Mark Thomas wrote:
>>>>   On 25/07/2012 17:00, Mark Struberg wrote:
>>>>>   Hi Lords and Ladies!
>>>>>
>>>>>   I'm currently wrangling with a doubled boot time on
>> tomcat7.0.29 in
>>>>>   comparison to 7.0.28 (12 webapps in my tc: 7.0.28 < 45s, 7.0.29
>>>
>>>>>   90s).
>>>>>
>>>>>   I'm aware that 7.0.29 now does the scanning for
>>>>>   ServletContainerInitializer even if version=2.5 is specified.
>But
>>>>>   there shall no class scanning be performed if
>>>>>   metadata-complete="true" is set, right?
>>>>
>>>>   Wrong. I don't like this but the intent of the Servlet 3.0 EG
>was:
>>>>   - ServletContainerInitializer cannot be disabled
>>>>   - If a ServletContainerInitializer is found, then class-scanning
>will
>>>>   take place
>>>>
>>>>>   Any ideas how we can ease the pain quickly?
>>>>
>>>>   The only option I see is a custom (non-spec compliant) Tomcat
>specific
>>>>   feature that disables all of this.
>>>
>>>  Ah. See the latest developments on
>>>  http://java.net/jira/browse/SERVLET_SPEC-36
>>>
>>>  Using an absolute ordering that specifies no fragments along with
>>>  metadata-complete=true should do the trick.
>>>
>>>  Mark
>>>
>>>
>>>
>---------------------------------------------------------------------
>>>  To unsubscribe, e-mail: [hidden email]
>>>  For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]