Looking how Emergency() vs ink_emergency() works. The only difference is
Emergency() calls Diags::cleanup_func() with is only defined in traffic_manager.
Here is the call stack for Emergency():
Emergency > DiagsError > diags->error > error_va > ink_emergency_va >
::exit(UNRECOVERABLE_EXIT)
Vs
> On Jun 17, 2019, at 4:27 PM, Bryan Call wrote:
>
> I would assume he is going to be calling ink_emergency(), so it wouldn’t be a
> management API.
That’s not what I meant :).
I believe things that does process management, such as stop / start / check
status etc. etc. all belongs in the m
I would assume he is going to be calling ink_emergency(), so it wouldn’t be a
management API.
Fei, can you add more details about what "This API is a wrapper for the
"Emergency” call” is really going to do?
-Bryan
> On Jun 17, 2019, at 3:22 PM, Leif Hedstrom wrote:
>
>
>
>> On Jun 17, 201
> On Jun 17, 2019, at 4:16 PM, Bryan Call wrote:
>
> I would recommend having it like TSDebug and TSError.
>
> tsapi void TSEmergency(const char *fmt, ...) TS_PRINTFLIKE(1, 2);
>
> TSDebug and TSError:
> tsapi void TSDebug(const char *tag, const char *format_str, ...)
> TS_PRINTFLIKE(2, 3);
I would recommend having it like TSDebug and TSError.
tsapi void TSEmergency(const char *fmt, ...) TS_PRINTFLIKE(1, 2);
TSDebug and TSError:
tsapi void TSDebug(const char *tag, const char *format_str, ...)
TS_PRINTFLIKE(2, 3);
tsapi void TSError(const char *fmt, ...) TS_PRINTFLIKE(1, 2);
-Brya
The Buildbot has detected a restored build on builder trafficserver-website
while building trafficserver-website. Full details are available at:
https://ci.apache.org/builders/trafficserver-website/builds/2
Buildbot URL: https://ci.apache.org/
Buildslave for this Build: bb_slave1_ubuntu
Bui
> On Jun 17, 2019, at 3:13 PM, Fei Deng wrote:
>
> void TSEmergencyShutdown(const char *log_msg);
>
> This API is a wrapper for the "Emergency" call, which signals
> traffic_manager to not restart traffic_server after the shutdown, i.e. this
> call should be used when something has gone wrong
void TSEmergencyShutdown(const char *log_msg);
This API is a wrapper for the "Emergency" call, which signals
traffic_manager to not restart traffic_server after the shutdown, i.e. this
call should be used when something has gone wrong and cannot be recovered
by a restart.
With TSDEBUG there is no way to updated the global variable after you start up,
even with traffic_ctl. A plugin can set the variable directly, but that seems
hacky.
Debug should already be checking global variables to see if debug is enabled
first before calling into PCRE.
-Bryan
> On Jun 1
It looked like a simple fast change. Are you saying you can see that
TSDEBUG would not start printing debug messages if you enabled the global
flag with traffic_cntl ?
An alternative would be to have the core functions that print the debug
messages check the global flag first before they call PCR
Walt,
TSDEBUG uses diags_on_for_plugins and that looks to only be set on startup and
then just calls TSDebug(). It doesn’t make sense to replace TSDebug with
TSDEBUG.
I don’t see why you are trying to optimize just the plugin debug. When debug
is enabled it has a performance impact on the en
11 matches
Mail list logo
