Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #60983 > unrolled thread

any use case of logging.config.listen()?

Back to article view | Back to comp.lang.python

Contents

  any use case of logging.config.listen()? Zhang Weiwu <tristan@realss.com> - 2013-12-04 09:34 +0800
    Re: any use case of logging.config.listen()? Dan Sommers <dan@tombstonezero.net> - 2013-12-04 03:05 +0000
      Re: any use case of logging.config.listen()? Zhang Weiwu <tristan@realss.com> - 2013-12-04 17:09 +0800
        Re: any use case of logging.config.listen()? Chris Angelico <rosuav@gmail.com> - 2013-12-04 21:53 +1100

#60983 — any use case of logging.config.listen()?

Why would anyone use it? I can't think of use cases when one need to change 
logging configuration dynamically through socket, but not needing the same 
flexibility on overall configuration for his application (configparser). It 
feels strange to design a socket interface only to expose logging 
configuration. If you use logging.config.listen, I very much wish to know 
what problem are you attacking.

I imagined this use case, and invite you to debate if it be valid. Thanks.

 	To design a GUI monitor of a daemon, like amule-gui (log-reading
 	monitor for amule) or pureadmin (log-reading monitor for pureftp).
 	Here is how:

 	1. The user starts the monitor on his PC. It socket-coneect the
 	daemon written in python - perhaps wrapped by SSH protection - and
 	send a new config file that adds SocketHandler with his own IP
 	address and port.

 	2. The daemon starts to emit log to TCP socket, the user watches his
 	monitor.

 	3. When the user finishes, the GUI monitor sends a new config file
 	to remove the handler (is it possible with current API?)  Or, the
 	user drops out, the server finds socket dead and removes the
 	SocketHandler on its own.

 	It works like FTP's PORT command, asking server to establish
 	connection back to the client. Unfortunately this technology doesn't
 	work nowadays when most PCs are behind NAT firewall.

It begets the question, that if it is easier to write a socket-listening 
loging handler and forget all about logging.config.listen() stuff. I never 
did it before, hence the question.

[toc] | [next] | [standalone]

#60988

On Wed, 04 Dec 2013 09:34:13 +0800, Zhang Weiwu wrote:

> Why would anyone use [logging.config.listen()]? I can't think of use
> cases when one need to change logging configuration dynamically
> through socket, but not needing the same flexibility on overall
> configuration for his application (configparser). It feels strange to
> design a socket interface only to expose logging configuration. If you
> use logging.config.listen, I very much wish to know what problem are
> you attacking.

Consider a long-running process that listens for input (HTTP, CLI, GUI,
or something else; it doesn't matter), does some processing, and
produces output.  A web server is an example of such a process.

Now consider the case that something is wrong with the process, but
you're not sure what.  So you use logging.config.listen to raise the
logging level so that you can see more logging from your process without
disturbing it in any way.

Or suppose you want to deploy a new plug-in to the process, and
temporarily turn "up" the logging to watch the new plug-in emit some
debugging-level messages as it starts up.  When the new plug-in is
finished, you can turn "down" the logging level.  With
logging.config.listen(), you can do all of this without stopping and
restarting the process.

> I imagined this use case, and invite you to debate if it be
> valid. Thanks.

I think your use case is equivalent to the ones I described.  Therefore,
it is valid.  ;-)

> It begets the question, that if it is easier to write a
> socket-listening loging handler and forget all about
> logging.config.listen() stuff. I never did it before, hence the
> question.

But why develop all of that code when logging.config.listen() already
exists?  Adding a new SocketHandler seems more heavyweight (and more
risky) than adjusting the logging level on an existing SocketHandler.

HTH,
Dan

[toc] | [prev] | [next] | [standalone]

#60993

[Multipart message — attachments visible in raw view] — view raw

Thank you a lot for your case description.

On Wed, 4 Dec 2013, Dan Sommers wrote:

>> It begets the question, that if it is easier to write a
>> socket-listening loging handler and forget all about
>> logging.config.listen() stuff. I never did it before, hence the
>> question.
>
> But why develop all of that code when logging.config.listen() already
> exists?  Adding a new SocketHandler seems more heavyweight (and more
> risky) than adjusting the logging level on an existing SocketHandler.

There are 2 reasons that i cannot just use existing API for the project I am 
working on.

1. My monitoring GUI client is often behind various NAT. In fact it is a 
hand-held client, I could be using it in a café's WIFI. It is impossible to 
tell the python-daemon to just send the log to given address and port.

2. I forgot to explain that in my project adjusting log level is only half 
of what needs to be done. The monitoring GUI client also needs to be able to 
send a few operational parameters' change. e.g. I need to see the log, and 
decide to change 'Threshold' from 0.5 to 0.53 and see the difference.

For the first problem, a new logging.ListeningSocketHandler would work - 
don't know if it is easy to write one - which can be written in a way that 
simply drops logs if no one is listening, thus forgoing logging.config.listen().

For the second problem, a way to dynamically accept new operational 
paramters from socket is needed, solo logging.config.listen() wouldn't 
suffice.

Either case I don't find use of logging.config.listen(), even though I am 
looking hard for every way to reuse existing code.

[toc] | [prev] | [next] | [standalone]

#61009

On Wed, Dec 4, 2013 at 8:09 PM, Zhang Weiwu <tristan@realss.com> wrote:
> Either case I don't find use of logging.config.listen(), even though I am
> looking hard for every way to reuse existing code.
>

That's not a problem. It's a feature that doesn't quite fit your task,
so you don't use it. It's like trying to install an operating system
on a new computer and deciding that emacs isn't the one for you.
*dives for cover*

ChrisA

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web