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
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
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
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.
> 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
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
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
> 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 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: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
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
11 matches
Mail list logo
