tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@gmail.com>
Subject Re: svn commit: r1335700 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/catalina/startup/ webapps/docs/
Date Mon, 04 Jun 2012 09:51:51 GMT
2012/6/4 Mark Thomas <markt@apache.org>:
> On 04/06/2012 07:55, Konstantin Kolinko wrote:
>> 2012/5/8  <markt@apache.org>:
>>> Author: markt
>>> Date: Tue May  8 19:07:09 2012
>>> New Revision: 1335700
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1335700&view=rev
>>> Log:
>>> It appears that pausing requests for a Context during reload was relying on the
mapper not being cleaned up correctly. The Lifecycle refactoring cleaned up the mapper registrations
and broke the handling of paused requests. This commit restores that functionality and extends
it. The key changes are:
>>> - Contexts are no longer from the mapper if they are stopped while they are paused
>>> - The CoyoteAdapter pauses for 1s if a request is mapped to a paused Context
and then tries to re-map it. This replaces the reloading handling in the StandardContextValve
>>> - The reload handling has been removed from the StandardContextValve
>>> - Editing a watched resource now triggers a reload (that pauses requests received
during the reload) rather than a stop/start which will return 404s for requests received while
the context is stopping and starting
>>>
>>> As with previous iterations of this feature it is impossible to completely eliminate
the chances of a 404 without a fair amount of locking that would slow things down unnecessarily
in production.
>>>
>>> Modified:
>>>    tomcat/tc7.0.x/trunk/   (props changed)
>>>    tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
>>>    tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/MapperListener.java
>>>    tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
>>>    tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContextValve.java
>>>    tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/HostConfig.java
>>>    tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
>>>
>>> Propchange: tomcat/tc7.0.x/trunk/
>>> ------------------------------------------------------------------------------
>>>  Merged /tomcat/trunk:r1335692
>>>
>>
>>> --- tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
(original)
>>> +++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
Tue May  8 19:07:09 2012
>>> @@ -719,7 +719,19 @@ public class CoyoteAdapter implements Ad
>>>                     }
>>>                 }
>>>             }
>>> -
>>> +            if (!mapRequired && request.getContext().getPaused())
{
>>> +                // Found a matching context but it is paused. Mapping
data will
>>> +                // be wrong since some Wrappers may not be registered
at this
>>> +                // point.
>>> +                try {
>>> +                    Thread.sleep(1000);
>>> +                } catch (InterruptedException e) {
>>> +                    // Should never happen
>>> +                }
>>> +                // Reset mapping
>>> +                request.getMappingData().recycle();
>>> +                mapRequired = true;
>>
>> I think it also needs "version = null"; here.
>> The version variable is modified in the mapping loop.
>
> I don't believe this is the case. The correct version has already been
> identified and won't change on the next run through the loop. It is only
> the wrapper mapping that might change (as during a pause old Wrappers
> are unregistered and new Wrappers registered. By setting the version to
> null you force the version to be re-identified and this is not
> necessary. It just repeats what has already been done with the same result.

OK.

(I was wondering that you are clearing mappingData there but are not
restarting from scratch. Looking closely, version mapping already does
exactly the same, (version = ctxt.getWebappVersion(); followed by
clearing the mapping).

Maybe something can change during the wait and complete remapping will
be needed. The wait of 1s is short, but the actual wait might be
longer, because there is no upper limit on the count of iterations of
that loop.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message