bneradt commented on a change in pull request #6931:
URL: https://github.com/apache/trafficserver/pull/6931#discussion_r445031635
##########
File path: src/traffic_server/traffic_server.cc
##########
@@ -452,6 +453,33 @@ class MemoryLimit : public Continuation
struct rusage _usage;
};
+/** Gate the emission of the "Traffic Server is fuly initialized" log message.
+ *
+ * This message is intended to be helpful to users who want to know that
+ * Traffic Server is not just running but has become fully initialized and is
+ * ready to optimize traffic. This is in contrast to the "traffic server is
+ * running" message which can be printed before either of these conditions.
+ *
+ * This function is called on each initialization state transition. Currently,
+ * the two state transitions of interest are:
+ *
+ * 1. The cache is initialized.
Review comment:
Can you avoid cache initialization? I found that even if http.cache.http
was disabled the cache was still initialized.
I can look into this further.
##########
File path: src/traffic_server/traffic_server.cc
##########
@@ -452,6 +453,33 @@ class MemoryLimit : public Continuation
struct rusage _usage;
};
+/** Gate the emission of the "Traffic Server is fuly initialized" log message.
+ *
+ * This message is intended to be helpful to users who want to know that
+ * Traffic Server is not just running but has become fully initialized and is
+ * ready to optimize traffic. This is in contrast to the "traffic server is
+ * running" message which can be printed before either of these conditions.
+ *
+ * This function is called on each initialization state transition. Currently,
+ * the two state transitions of interest are:
+ *
+ * 1. The cache is initialized.
+ * 2. The ports are open and accept has been called upon them.
Review comment:
I actually do mean accept.
Here's some more context: Alan showed me that the ports may be opened and
listen may have been called on the ports before cache is initialized and before
accept is called on them, and that the difference in time between the opening
of the ports and the accept can be large (over 10 ms, say).
Here's the sequence of events that Traffic Server follows with regard to
configuring its ports:
1. Traffic server initializes data structures for the ports it listens on.
It may bind upon those ports depending upon Traffic Server configuration. (Our
docs say as much, see
https://docs.trafficserver.apache.org/en/9.0.x/developer-guide/api/functions/TSLifecycleHookAdd.en.html?highlight=life%20cycle#_CPPv4N17TSLifecycleHookID35TS_LIFECYCLE_PORTS_INITIALIZED_HOOKE)
1. Traffic Server calls TS_LIFECYCLE_PORTS_INITIALIZED_HOOK on all plugins
registered for it so they can do whatever they want to do to prepare for
connections.
1. If wait_for_cache is called, we delay calling accept on the ports until
cache is initialized, otherwise we directly...
1. Call start_HttpProxyServer(), which calls accept on the ports.
Before this patch, the AuTest extension considered Traffic Server ready to
accept test traffic if it succeeded in opening a connection to the listening
port. But this could happen in step one above, before cache is initialized and
before accept is called on the ports, **even if wait_for_cache is configured**.
This change adds a message to wait upon a message that is designed to guarantee
that everything is done and optimization is ready.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
