Skip to main content

[webtier] Re: purpose of extracting jars in web apps to generated directory?

3 replies [Last post]
Anonymous

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Jan Luehe

Hi Dies,

On 02/03/09 19:47, Dies Koper wrote:
> Hi Jan,
>
> I have a question about the implementation of WebappClassLoader.
>
> When including a jar with resources in a web app's WEB-INF/lib, at the
> moment a resource is first accessed from the application the jar's
> contents is extracted into the generated directory.
>
> This means that when there are many resources in a jar, there is a long
> delay when accessing the first resource. This is also noticeable when
> accessing the admin console each time after starting the domain.
>
> Do you know why is it implemented this way?
>
> I figured the reason is to work around redeployment problems due to file
> locks on jar files. If this is the case, have you considered redesigning
> the web classloader in the same way the EJB classloader is designed,
> i.e. closing the open streams when the classloader is discarded during
> re-/undeployment?
>
>

GlassFish inherited this behaviour from Tomcat.
The motivation for it is summarized in this Tomcat FAQ entry:

I want to redeploy web applications, how do I prevent resources from
getting locked?

Most locking issues will occur with JARs from /WEB-INF/lib, and are
useally caused by access through URLs. Tomcat has mechanisms to allow
avoiding locking. In Tomcat 5.0, a mechanism exists to prevent locking
when accessing resources using the getResource method of the URL
classloader (many applications, such as Xerces, do not set the use of
caching to false before opening the URL connection, causing
locking). If such a call occurs, resources inside the JARs will be
extracted to the work directory of the web application. In Tomcat 5.5,
this mechanism is disabled by default (as it has a non negligible
influence on startup times, and is often useless), and can be enabled
using the antiJARLocking attribute of the Context element.

GlassFish still enables antiJARLocking by default, and currently does
not provide any way of turning it off.

We should definitely support a way of turning antiJARLocking off
(and might want to consider turning it off by default), by honoring
the antiJARLocking attribute in Tomcat's context.xml, and adding a
similar property to sun-web.xml.

Thanks for bringing this up. I'll work on it, but feel free to file
an ENHANCEMENT request in IssueTracker.

Jan

> Thanks,
> Dies
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: dev-help@glassfish.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

Dies Koper

Hi Jan,

Thank you for your detailed reply.
I have created an issue to track the enhancement.
https://glassfish.dev.java.net/issues/show_bug.cgi?id=7149

I do think a better solution is to do what the EJBClassLoader does,
instead of just disabling antiJARLocking.

What EJBClassLoader does in its getResource (findResource0 really) and
getResourceAsStream methods is, it wraps the stream to a resource with a
special stream class (SentinelInputStream) that has a close method. When
an application is redeployed, the container calls a method in the
EJBClassLoader that will close all streams of the resources explicitly.

This is much more reliable than waiting for the gc to kick in. It also
solves the problem of the URL connection's caching not disabled by the
user application.

I don't think making antiJARLocking user configurable is the way to go,
especially when it is possible to solve the problem completely.

Thanks,
Dies Koper

Jan Luehe wrote:
> Hi Dies,
>
> On 02/03/09 19:47, Dies Koper wrote:
>> Hi Jan,
>>
>> I have a question about the implementation of WebappClassLoader.
>>
>> When including a jar with resources in a web app's WEB-INF/lib, at the
>> moment a resource is first accessed from the application the jar's
>> contents is extracted into the generated directory.
>>
>> This means that when there are many resources in a jar, there is a long
>> delay when accessing the first resource. This is also noticeable when
>> accessing the admin console each time after starting the domain.
>>
>> Do you know why is it implemented this way?
>>
>> I figured the reason is to work around redeployment problems due to file
>> locks on jar files. If this is the case, have you considered redesigning
>> the web classloader in the same way the EJB classloader is designed,
>> i.e. closing the open streams when the classloader is discarded during
>> re-/undeployment?
>>
>>
>
> GlassFish inherited this behaviour from Tomcat.
> The motivation for it is summarized in this Tomcat FAQ entry:
>
> I want to redeploy web applications, how do I prevent resources from
> getting locked?
>
> Most locking issues will occur with JARs from /WEB-INF/lib, and are
> useally caused by access through URLs. Tomcat has mechanisms to allow
> avoiding locking. In Tomcat 5.0, a mechanism exists to prevent locking
> when accessing resources using the getResource method of the URL
> classloader (many applications, such as Xerces, do not set the use of
> caching to false before opening the URL connection, causing
> locking). If such a call occurs, resources inside the JARs will be
> extracted to the work directory of the web application. In Tomcat 5.5,
> this mechanism is disabled by default (as it has a non negligible
> influence on startup times, and is often useless), and can be enabled
> using the antiJARLocking attribute of the Context element.
>
> GlassFish still enables antiJARLocking by default, and currently does
> not provide any way of turning it off.
>
> We should definitely support a way of turning antiJARLocking off
> (and might want to consider turning it off by default), by honoring
> the antiJARLocking attribute in Tomcat's context.xml, and adding a
> similar property to sun-web.xml.
>
> Thanks for bringing this up. I'll work on it, but feel free to file
> an ENHANCEMENT request in IssueTracker.
>
>
> Jan

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

Jan Luehe

Hi Dies,

On 02/05/09 22:42, Dies Koper wrote:
> Hi Jan,
>
> Thank you for your detailed reply.
> I have created an issue to track the enhancement.
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=7149
>
> I do think a better solution is to do what the EJBClassLoader does,
> instead of just disabling antiJARLocking.
>
> What EJBClassLoader does in its getResource (findResource0 really) and
> getResourceAsStream methods is, it wraps the stream to a resource with
> a special stream class (SentinelInputStream) that has a close method.
> When an application is redeployed, the container calls a method in the
> EJBClassLoader that will close all streams of the resources explicitly.
>
> This is much more reliable than waiting for the gc to kick in. It also
> solves the problem of the URL connection's caching not disabled by the
> user application.
>
> I don't think making antiJARLocking user configurable is the way to
> go, especially when it is possible to solve the problem completely.

Thanks for filing the issue!
I will certainly explore the approach the EJBClassLoader has taken.

Thanks,

Jan

>
> Thanks,
> Dies Koper
>
>
> Jan Luehe wrote:
>> Hi Dies,
>>
>> On 02/03/09 19:47, Dies Koper wrote:
>>> Hi Jan,
>>>
>>> I have a question about the implementation of WebappClassLoader.
>>>
>>> When including a jar with resources in a web app's WEB-INF/lib, at the
>>> moment a resource is first accessed from the application the jar's
>>> contents is extracted into the generated directory.
>>>
>>> This means that when there are many resources in a jar, there is a long
>>> delay when accessing the first resource. This is also noticeable when
>>> accessing the admin console each time after starting the domain.
>>>
>>> Do you know why is it implemented this way?
>>>
>>> I figured the reason is to work around redeployment problems due to
>>> file
>>> locks on jar files. If this is the case, have you considered
>>> redesigning
>>> the web classloader in the same way the EJB classloader is designed,
>>> i.e. closing the open streams when the classloader is discarded during
>>> re-/undeployment?
>>>
>>>
>>
>> GlassFish inherited this behaviour from Tomcat.
>> The motivation for it is summarized in this Tomcat FAQ entry:
>>
>> I want to redeploy web applications, how do I prevent resources from
>> getting locked?
>>
>> Most locking issues will occur with JARs from /WEB-INF/lib, and are
>> useally caused by access through URLs. Tomcat has mechanisms to allow
>> avoiding locking. In Tomcat 5.0, a mechanism exists to prevent locking
>> when accessing resources using the getResource method of the URL
>> classloader (many applications, such as Xerces, do not set the use of
>> caching to false before opening the URL connection, causing
>> locking). If such a call occurs, resources inside the JARs will be
>> extracted to the work directory of the web application. In Tomcat 5.5,
>> this mechanism is disabled by default (as it has a non negligible
>> influence on startup times, and is often useless), and can be enabled
>> using the antiJARLocking attribute of the Context element.
>>
>> GlassFish still enables antiJARLocking by default, and currently does
>> not provide any way of turning it off.
>>
>> We should definitely support a way of turning antiJARLocking off
>> (and might want to consider turning it off by default), by honoring
>> the antiJARLocking attribute in Tomcat's context.xml, and adding a
>> similar property to sun-web.xml.
>>
>> Thanks for bringing this up. I'll work on it, but feel free to file
>> an ENHANCEMENT request in IssueTracker.
>>
>>
>> Jan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: webtier-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net