displaying thread id in mod_status ExtendedStatus table - how to request it?

[Jeff Trawick <tr...@gmail.com>]

motivation: correlate stuck requests seen in mod_status display with
entries in third-party logs which log pid+tid

I assume that simply adding another column to the table will break
existing scripts.

Requre threadid in query argument to see this information?       
(/server-status/?notable&threadid or something like that)

Have a query argument that  tells mod_status to always spit out all
available information?   format may change if somebody adds a new
column in the future  (/server-status/?refresh=5&showall)

[PATCH] displaying thread id in mod_status ExtendedStatus table

[Jeff Trawick <tr...@gmail.com>]

On 6/11/05, Jeff Trawick <tr...@gmail.com> wrote:
> On 6/11/05, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> > At 12:34 PM 6/11/2005, Jeff Trawick wrote:
> > >> I like the idea of toggling columns, I'd make it more like
> > >> columns=pid,tid,ss,m,req to allow for abbreviated displays.
> > >
> > >columns= with column names like that works for me
> > >
> > >columns=all displays everything (may change layout in the future)
> > >default list for columns is whatever we display now
> >
> > I like columns=* personally :)  Less ambiguous if we decree all columns
> > can be toggled (especially if we allow modules to extend them).
> >
> > Perhaps +/- syntax?  Painful in code, but easier for the user
> > (?columns=+tid).  +/- wouldn't reorder the columns from their
> > default, while explicit lists would?

No reordering of columns is possible with this patch.
The Srv column is always implicitly enabled.
'*' = all columns (need to escape it on shell command-line)
Bogus values for columns parameter are not reported.
No changes implemented for the no-table flavor of output (yet).

Something that is a bit painful is that APR doesn't have a way to
format a thread id in hex, and that is a useful format for correlation
with some third party logs.  That should be resolved eventually so
that the thread id in hex (and perhaps the process id in hex too) can
be requested.

Step in the right direction?
Not usable since somebody is going to implement configurable field order soon?
Broken?
etc.

Thanks for any comments!

Re: displaying thread id in mod_status ExtendedStatus table - how to request it?

[Jeff Trawick <tr...@gmail.com>]

On 6/11/05, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> At 12:34 PM 6/11/2005, Jeff Trawick wrote:
> >> I like the idea of toggling columns, I'd make it more like
> >> columns=pid,tid,ss,m,req to allow for abbreviated displays.
> >
> >columns= with column names like that works for me
> >
> >columns=all displays everything (may change layout in the future)
> >default list for columns is whatever we display now
> 
> I like columns=* personally :)  Less ambiguous if we decree all columns
> can be toggled (especially if we allow modules to extend them).
> 
> Perhaps +/- syntax?  Painful in code, but easier for the user
> (?columns=+tid).  +/- wouldn't reorder the columns from their
> default, while explicit lists would?

Cute, but brings with it more complexity of both code and
documentation.  I'll come up with something that handles the basic
requirement and the rses of the world can take it from there ;)

Re: displaying thread id in mod_status ExtendedStatus table - how to request it?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 12:34 PM 6/11/2005, Jeff Trawick wrote:
>> I like the idea of toggling columns, I'd make it more like
>> columns=pid,tid,ss,m,req to allow for abbreviated displays.
>
>columns= with column names like that works for me
>
>columns=all displays everything (may change layout in the future)
>default list for columns is whatever we display now

I like columns=* personally :)  Less ambiguous if we decree all columns
can be toggled (especially if we allow modules to extend them).

Perhaps +/- syntax?  Painful in code, but easier for the user
(?columns=+tid).  +/- wouldn't reorder the columns from their
default, while explicit lists would?

>modules need a flag to their status hook to know to implement xml (or
>omit if xml is required)...  xml representation needed for everything
>else as well...  or display=xml implies that you get just the
>extendedstatus table and absolutely nothing else

I'd want the mode (xml v.s. html) to be toggled with a different
option flag.  The only reason for combining xml and columns would
be some synthesized columns that require extra cpu, and the user
knows exactly what they will use.

I don't know of many computationally intensive columns, but if we
later let this become extensible, I can see where that would become
a potential issue.

> > One other thing, we should probably contemplate disallowing
>> certain fields.  E.g. someone who wanted server-status, but
>> didn't want to leak pid/tid or remote IP information might
>> want to lock out those fields from being returned.
>
>in due time, if someone is sufficiently itchy

I'll scratch :)  If you have a first draft, I'll follow, otherwise
I'd steal code from mod_autoindex to start with.  Of course, this
would be trivial with libapreq in the core, and would support using
POST :)

Bill  

Re: displaying thread id in mod_status ExtendedStatus table - how to request it?

[Jeff Trawick <tr...@gmail.com>]

On 6/9/05, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> At 05:03 AM 6/9/2005, Jeff Trawick wrote:

> >Requre threadid in query argument to see this information?
> >(/server-status/?notable&threadid or something like that)
> >
> Or name the columns?  Better yet, move to an XML output
> (?refresh=5&display=xml) which any decent parser can tear apart,
> no matter how we change things in the future?
 
> I like the idea of toggling columns, I'd make it more like
> columns=pid,tid,ss,m,req to allow for abbreviated displays.

columns= with column names like that works for me

columns=all displays everything (may change layout in the future)
default list for columns is whatever we display now

modules need a flag to their status hook to know to implement xml (or
omit if xml is required)...  xml representation needed for everything
else as well...  or display=xml implies that you get just the
extendedstatus table and absolutely nothing else
 
> One other thing, we should probably contemplate disallowing
> certain fields.  E.g. someone who wanted server-status, but
> didn't want to leak pid/tid or remote IP information might
> want to lock out those fields from being returned.

in due time, if someone is sufficiently itchy

Re: displaying thread id in mod_status ExtendedStatus table - how to request it?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 05:03 AM 6/9/2005, Jeff Trawick wrote:
>motivation: correlate stuck requests seen in mod_status display with
>entries in third-party logs which log pid+tid

+1, was bit by this issue myself a week ago(!)

>I assume that simply adding another column to the table will break
>existing scripts.
>
>Requre threadid in query argument to see this information?       
>(/server-status/?notable&threadid or something like that)
>
>Have a query argument that  tells mod_status to always spit out all
>available information?   format may change if somebody adds a new
>column in the future  (/server-status/?refresh=5&showall)

Or name the columns?  Better yet, move to an XML output
(?refresh=5&display=xml) which any decent parser can tear apart,
no matter how we change things in the future?

I like the idea of toggling columns, I'd make it more like
columns=pid,tid,ss,m,req to allow for abbreviated displays.

One other thing, we should probably contemplate disallowing
certain fields.  E.g. someone who wanted server-status, but
didn't want to leak pid/tid or remote IP information might
want to lock out those fields from being returned.

Bill