https://issues.apache.org/bugzilla/show_bug.cgi?id=56713

            Bug ID: 56713
           Summary: Limit time that incoming request waits while webapp is
                    reloading
           Product: Tomcat 8
           Version: 8.0.9
          Hardware: PC
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
          Assignee: dev@tomcat.apache.org
          Reporter: knst.koli...@gmail.com

(Originally raised in bug 56710)

There is an old feature that when web application is being reloaded, any
incoming requests for that application are paused until reload completes.

This feature dates back to Tomcat 4.1.x or earlier. See also bug 53024 for
fixing (reimplementing) this feature in Tomcat 7.

The waiting loop is implemented in CoyoteAdapter.postParseRequest().

While this feature is useful, the wait time shall not be infinite.

Questions:
(1) How long is the allowed wait time?
(2) What to do if wait time expires?
(3) What to do if Connector state changes, e.g Tomcat shuts down?


Regarding (1):
---------------
a) I thought that maybe "connectionTimeout" of a Connector is the good time to
wait.
b) Make it configurable on Host?
c) Make it configurable on Context?
d) Hard-code something?

There are caveats for a):
- There may be several Connectors in the same Service with different value for
this attribute.
- For an AJP connector this attribute is "-1" by default.


Regarding (2):
---------------
I think the best would be to unregister that context in the Mapper and let
whatever other (ROOT) application there to handle the request. The ROOT
application may respond with 503, 404, 302 or whatever is suitable.

(Rejecting the request in CoyoteAdapter would be unfriendly, as it happens at a
lower level and there is no ErrorReportValve to render an error page. The
en-user will see an empty page).

I think this needs update to the Mapper API.
There will be race condition between this forced de-registration of context,
and its re-registration after successful startup. To avoid it,

a) MapperListener shall notify Mapper that the context has been paused. The
Mapper shall remember the "paused" state.
b) The forced de-registration shall be a separate method in the Mapper and it
shall check the "paused" state of a context before removing it.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

Reply via email to