2012/6/4 Mark Thomas <ma...@apache.org>:
> On 04/06/2012 07:55, Konstantin Kolinko wrote:
>> 2012/5/8  <ma...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to