unsubscribe
On Wed, Jun 19, 2019 at 7:13 PM Fei Deng <duke8...@gmail.com> 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 core functions).
> - When reading configs for the first time and fails, traffic server
> should call *Emergency*, while on a config reload it should not call it
> and fall back to the previous configuration.
>
> If I forgot something we just talked about please add to this note @Alan
> @Bryan.
>
> Regards,
> Fei Deng
>
>
> On Tue, Jun 18, 2019 at 10:11 AM Fei Deng <duke8...@gmail.com> wrote:
>
> > 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 <duke8...@gmail.com> wrote:
> >
> >> 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, Jun 17, 2019 at 5:59 PM Bryan Call <bc...@apache.org> wrote:
> >>
> >>> 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
> >>> ink_emergency > ink_emergency_va > ::exit(UNRECOVERABLE_EXIT)
> >>>
> >>> -Bryan
> >>>
> >>>
> >>> > On Jun 17, 2019, at 3:27 PM, Bryan Call <bc...@apache.org> wrote:
> >>> >
> >>> > 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 <zw...@apache.org>
> wrote:
> >>> >>
> >>> >>
> >>> >>
> >>> >>> On Jun 17, 2019, at 4:16 PM, Bryan Call <bc...@apache.org> 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);
> >>> >>> tsapi void TSError(const char *fmt, ...) TS_PRINTFLIKE(1, 2);
> >>> >>>
> >>> >>
> >>> >>
> >>> >> What I don’t like with the original idea is that we’re putting
> >>> management APIs (which we have ts/mgmt.h for) into the plugin APIs.
> There
> >>> should be nothing stopping a plugin from using the management APIs I
> don’t
> >>> think? If there is, that’s yet another issue.
> >>> >>
> >>> >> I feel reasonably strongly about not merging ts/hmgmt.h
> functionality
> >>> into ts/ts.h.
> >>> >>
> >>> >> — Leif
> >>> >>
> >>> >>>
> >>> >>> -Bryan
> >>> >>>
> >>> >>>
> >>> >>>> On Jun 17, 2019, at 2:13 PM, Fei Deng <duke8...@apache.org>
> 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 and cannot be
> >>> recovered
> >>> >>>> by a restart.
> >>> >>>
> >>> >>
> >>> >
> >>>
> >>>
>
--
-------------------------------
Have a Nice Day,
Kamil Abboud
