You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Damon Courtney <da...@your.unreality.com> on 2003/01/18 02:35:45 UTC
Error logging
Hey,
I was thinking it might be really cool to create a second channel
implementation and redirect 'stderr' to Apache's error log. Anyone
have an opinion on this?
I also have some new code for garbage cleanup. It cleans up hanging
file pointers, socket and Itcl objects after the page has executed. It's
turned on by default but can be turned off using configuration directives.
Any opinions all around?
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Error logging
Posted by "David N. Welton" <da...@dedasys.com>.
Damon Courtney <da...@your.unreality.com> writes:
> foreach fp [file channels] {
> if {[string match std* $fp]} { continue }
> catch { close $fp }
> }
>
> That's pretty well it. 0-] No fuss, no muss.
What if there is something (either sockets or files) that was already
opened somewhere... say in the server startup code. I think it should
try and be a bit cleverer by saving the state in some corresponding
'before page' code.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Error logging
Posted by Damon Courtney <da...@your.unreality.com>.
> Sure, if we made it a Tcl optional, then people could use it if they
> want the timestamp. I guess adding a stderr channel would be a pretty
> minor thing to do too. Maybe the best thing for now is to put it in
> the 'TODO' list with a note saying that we'll do it if enough people
> feel that it would help them.
We'll put it on the TODO. It's not a big deal. Just throwing out
thoughts. 0-]
> That sounds like the right way to handle things. How does it work?
foreach fp [file channels] {
if {[string match std* $fp]} { continue }
catch { close $fp }
}
That's pretty well it. 0-] No fuss, no muss.
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Error logging
Posted by "David N. Welton" <da...@dedasys.com>.
Damon Courtney <da...@your.unreality.com> writes:
> > Hrm... I'm undecided. It wouldn't be much larger, but maybe
> > adding a timestamp in Tcl itself would be more Tcl'ish?
> Hrmm... We could just add a command to do error logging. All it
> would do is 'puts stderr' with an Apache timestamp on the front.
Sure, if we made it a Tcl optional, then people could use it if they
want the timestamp. I guess adding a stderr channel would be a pretty
minor thing to do too. Maybe the best thing for now is to put it in
the 'TODO' list with a note saying that we'll do it if enough people
feel that it would help them.
> > if (toplevel && rsc->rivet_after_script) {
> > Tcl_AppendObjToObj(outbuf, Tcl_NewStringObj(rsc->rivet_after_script, -1));
> > }
> > We could do something like:
> > if (toplevel) {
> > #ifdef DEFAULT_AFTER_SCRIPT
> > rsc->after_script = DEFAULT_AFTER_SCRIPT;
> > #endif
> > if(rsc->after_script) {
> > Tcl_AppendObjToObj(outbuf, Tcl_NewStringObj(rsc->rivet_after_script, -1));
> > }
> > }
> > Something like that...
> > Let's see what you've got though, so I can see exactly how you've
> > done it:-) I definitely think the file/socket cleanup stuff could
> > be useful.
> Nah. Screw all that. 0-] I made it into it's own procedure
> called cleanup_open_channels, and they can run it as an
> "AfterScript" if they want to. I, originally, put it in the
> cleanup_request proc since it's there but not really doing anything.
> What do you think about that?
That sounds like the right way to handle things. How does it work?
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Error logging
Posted by Damon Courtney <da...@your.unreality.com>.
> Hrm... I'm undecided. It wouldn't be much larger, but maybe adding a
> timestamp in Tcl itself would be more Tcl'ish?
Hrmm... We could just add a command to do error logging. All it would
do is 'puts stderr' with an Apache timestamp on the front.
> if (toplevel && rsc->rivet_after_script) {
> Tcl_AppendObjToObj(outbuf, Tcl_NewStringObj(rsc->rivet_after_script, -1));
> }
>
> We could do something like:
>
> if (toplevel) {
> #ifdef DEFAULT_AFTER_SCRIPT
> rsc->after_script = DEFAULT_AFTER_SCRIPT;
> #endif
> if(rsc->after_script) {
> Tcl_AppendObjToObj(outbuf, Tcl_NewStringObj(rsc->rivet_after_script, -1));
> }
> }
>
> Something like that...
>
> Let's see what you've got though, so I can see exactly how you've done
> it:-) I definitely think the file/socket cleanup stuff could be
> useful.
Nah. Screw all that. 0-] I made it into it's own procedure called
cleanup_open_channels, and they can run it as an "AfterScript" if they
want to. I, originally, put it in the cleanup_request proc since it's
there but not really doing anything. What do you think abou that?
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Error logging
Posted by "David N. Welton" <da...@dedasys.com>.
Damon Courtney <da...@your.unreality.com> writes:
> > Uh... me stupid - I mean stderr, of course:-)
> Well, stderr directly goes to error_log, yes, but I was thinking
> more of having output to stderr actually be logged in the error_log
> using the Apache commands. As it stands now, output to stderr is
> just directly spit into the file. By calling the Apache commands to
> log errors, we actually get the '[Fri Jan 17 13:50:48 2003]
> [notice]' log message with each line.
Hrm... I'm undecided. It wouldn't be much larger, but maybe adding a
timestamp in Tcl itself would be more Tcl'ish?
> *shrug* Just a thought. It works now without any work. 0-]
> > I would go for the Itcl thing being a seperate thing, or maybe off
> > by default.
> We can turn it off by default. Makes no difference to me. 0-]
> > But... couldn't this stuff all just go in to begin and end page
> > chunks that are installed by default?
> Not sure what you mean here. 'Splain, Lucy!
if (toplevel && rsc->rivet_after_script) {
Tcl_AppendObjToObj(outbuf, Tcl_NewStringObj(rsc->rivet_after_script, -1));
}
We could do something like:
if (toplevel) {
#ifdef DEFAULT_AFTER_SCRIPT
rsc->after_script = DEFAULT_AFTER_SCRIPT;
#endif
if(rsc->after_script) {
Tcl_AppendObjToObj(outbuf, Tcl_NewStringObj(rsc->rivet_after_script, -1));
}
}
Something like that...
Let's see what you've got though, so I can see exactly how you've done
it:-) I definitely think the file/socket cleanup stuff could be
useful.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Error logging
Posted by Damon Courtney <da...@your.unreality.com>.
> Uh... me stupid - I mean stderr, of course:-)
Well, stderr directly goes to error_log, yes, but I was thinking more
of having output to stderr actually be logged in the error_log using the
Apache commands. As it stands now, output to stderr is just directly
spit into the file. By calling the Apache commands to log errors, we actually
get the '[Fri Jan 17 13:50:48 2003] [notice]' log message with each line.
*shrug* Just a thought. It works now without any work. 0-]
> I would go for the Itcl thing being a seperate thing, or maybe off by
> default.
We can turn it off by default. Makes no difference to me. 0-]
> But... couldn't this stuff all just go in to begin and end page chunks
> that are installed by default?
Not sure what you mean here. 'Splain, Lucy!
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Error logging
Posted by "David N. Welton" <da...@dedasys.com>.
Damon Courtney <da...@your.unreality.com> writes:
> > > I was thinking it might be really cool to create a second
> > > channel implementation and redirect 'stderr' to Apache's error
> > > log. Anyone have an opinion on this?
> > Stdout already goes there, IIRC.
> How can stdout go there if it already goes to the webpage? 0-]
Uh... me stupid - I mean stderr, of course:-)
> > > I also have some new code for garbage cleanup. It cleans up
> > > hanging file pointers, socket and Itcl objects after the page
> > > has executed. It's turned on by default but can be turned off
> > > using configuration directives.
> > What's it look like? Sounds useful! Especially the file and
> > socket cleanups.
> It's pretty clean. 0-] It's about 4 lines of code. The Itcl
> stuff is in a catch statement incase Itcl isn't installed, but it's
> also extremely useful.
I would go for the Itcl thing being a seperate thing, or maybe off by
default.
But... couldn't this stuff all just go in to begin and end page chunks
that are installed by default?
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Error logging
Posted by Damon Courtney <da...@your.unreality.com>.
> > I was thinking it might be really cool to create a second
> > channel implementation and redirect 'stderr' to Apache's error log.
> > Anyone have an opinion on this?
>
> Stdout already goes there, IIRC.
How can stdout go there if it already goes to the webpage? 0-]
>
> > I also have some new code for garbage cleanup. It cleans up
> > hanging file pointers, socket and Itcl objects after the page has
> > executed. It's turned on by default but can be turned off using
> > configuration directives.
>
> What's it look like? Sounds useful! Especially the file and socket
> cleanups.
It's pretty clean. 0-] It's about 4 lines of code. The Itcl stuff
is in a catch statement incase Itcl isn't installed, but it's also
extremely useful.
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Error logging
Posted by "David N. Welton" <da...@dedasys.com>.
Damon Courtney <da...@your.unreality.com> writes:
> I was thinking it might be really cool to create a second
> channel implementation and redirect 'stderr' to Apache's error log.
> Anyone have an opinion on this?
Stdout already goes there, IIRC.
> I also have some new code for garbage cleanup. It cleans up
> hanging file pointers, socket and Itcl objects after the page has
> executed. It's turned on by default but can be turned off using
> configuration directives.
What's it look like? Sounds useful! Especially the file and socket
cleanups.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org