unsubscribe
On Wed, Jun 19, 2019 at 7:13 PM Fei Deng wrote:
> Adding some notes here from the discussion we had just now:
>
>- *Fatal* and *Emergency* both need to be exposed to plugins, where
>*Emergency* keeps traffic server down and *Fatal* will try and restart
>(just like the cor
Weighing in late, as usual, but I'm not sure what Leif means by
"ts/mgmt.h". Did you mean "ts/mgmtapi.h"? If so, that's a rather heavy
weight solution for the desired action here. AFAICT using that requires
setting up a full API client, not just making a single call to send a
message. You'd also ha
I think it is already logging it right now, leif had a new PR for it just
recently to remove the Emergency call.
Regards,
Fei Deng
On Wed, Jun 19, 2019 at 11:18 AM Sudheer Vinukonda
wrote:
> >>> while on a config reload it should not call it and fall back to
> the previous configuration.
>>> while on a config reload it should not call it and fall back to the
>>>previous configuration.
Is there a way we can alert this (at a minimum, an Error log?)?
Falling back to old config (definitely preferable), but, silently is a bit
misleading and confusing.
- Sudheer
On Wednesd
Adding some notes here from the discussion we had just now:
- *Fatal* and *Emergency* both need to be exposed to plugins, where
*Emergency* keeps traffic server down and *Fatal* will try and restart
(just like the core functions).
- When reading configs for the first time and fails, tr
So this is what it looks like now:
tsapi void
TSEmergency(const char *fmt, ...)
{
va_list args;
va_start(args, fmt);
EmergencyV(fmt, args);
va_end(args);
}
Regards,
Fei Deng
On Tue, Jun 18, 2019 at 9:41 AM Fei Deng wrote:
> Yes, this is suggested by Alan and Susan, since sometimes we
Yes, this is suggested by Alan and Susan, since sometimes we need plugins
to be able to abort and not try to restart (say if some important files are
missing). I'll change the name to TSEmergency().
And I'll look at TSDebug and TSError, and make it similar to those.
Regards,
Fei Deng
On Mon, Ju
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
> 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.
14 matches
Mail list logo
