logging via SocketHandler and TCPserver

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Larry Bates

    logging via SocketHandler and TCPserver

    Every time I look at the logging module (up until now) I've given up and
    continue to use my home-grown logger that I've been using for years. I'm not
    giving up this time ;-)

    I find that I REALLY need to be able to monitor LOTS of running
    programs/processes and thought it would be nice to have them use SocketHandler
    logging and then I would write TCPServer to accept the log messages for
    real-time monitoring. I Googled (is that now a verb?) for several hours and
    came up with some code that I've turned in to something that works, but I can't
    figure out how to disconnect the server once it is connected The goal is to be
    able to start TCPServer, monitor the log messages sent via SocketHandler logger,
    disconnect, and move to the next application. Eventually I would like to wrap a
    GUI around all of this for monitoring a complex web application.

    Everything works, it just appears that I get into the while loop in
    LogRecordStream Handler.handle and it never breaks out (until I kill the client).
    I can't seem to do anything with the LogRecordSocket Receiver.abort attribute to
    make it quit.

    I'm sure it is something simple (stupid?), but I've spent about 4 hours and I'm
    not getting anywhere.

    Thanks in advance for any assistance.

    Regards,
    Larry


    Below is my code:

    import sys
    import time
    import logging

    if sys.argv[1] == 'client':
    import logging.config

    logging.config. fileConfig("log ging.conf")

    #create logger
    logger = logging.getLogg er("VESconsole" )

    while 1:
    logger.debug("d ebug message")
    logger.info("in fo message")
    logger.warn("wa rn message")
    logger.error("e rror message")
    logger.critical ("critical message")
    time.sleep(2)

    elif sys.argv[1] == 'server':
    import cPickle
    import logging.handler s
    import SocketServer
    import struct
    import signal

    class LogRecordStream Handler(SocketS erver.StreamReq uestHandler):
    """Handler for a streaming logging request.

    This basically logs the record using whatever logging policy is
    configured locally.
    """

    def handle(self):
    """
    Handle multiple requests - each expected to be a 4-byte length,
    followed by the LogRecord in pickle format. Logs the record
    according to whatever policy is configured locally.
    """
    while 1:
    chunk = self.connection .recv(4)
    if len(chunk) < 4:
    break

    slen = struct.unpack(" >L", chunk)[0]
    chunk = self.connection .recv(slen)
    while len(chunk) < slen:
    chunk = chunk + self.connection .recv(slen - len(chunk))

    obj = self.unPickle(c hunk)
    record = logging.makeLog Record(obj)
    self.handleLogR ecord(record)

    def unPickle(self, data):
    return cPickle.loads(d ata)

    def handleLogRecord (self, record):
    t = time.strftime(' %a, %d %b %y %H:%M:%S',
    time.localtime( record.created) )

    print "%s %s" % (t, record.getMessa ge())

    class LogRecordSocket Receiver(Socket Server.Threadin gTCPServer):
    """simple TCP socket-based logging receiver suitable for testing.
    """

    allow_reuse_add ress = 1

    def __init__(self, host='localhost ',
    port=logging.ha ndlers.DEFAULT_ TCP_LOGGING_POR T,
    handler=LogReco rdStreamHandler ):

    SocketServer.Th readingTCPServe r.__init__(self ,
    (host, port),
    handler)
    self.abort = 0
    self.timeout = 1
    self.logname = None

    def serve_until_sto pped(self):
    import select
    abort = 0
    while not abort:
    rd, wr, ex = select.select([self.socket.fil eno()],
    [], [],
    self.timeout)
    if rd:
    self.handle_req uest()

    abort = self.abort

    print "serve_until_st opped exiting"

    #
    # Start ThreadingTCPSer ver instance to accept SocketHandler log
    # messages from client.
    #
    tcpserver = LogRecordSocket Receiver()
    print "Starting ThreadingTCPSer ver..."
    tcpserver.serve _until_stopped( )

    '''
    #-----logging.conf-----
    [loggers]
    keys=root

    [handlers]
    keys=socketHand ler

    [formatters]
    keys=simpleForm atter

    [logger_root]
    level=DEBUG
    handlers=socket Handler

    [handler_socketH andler]
    class=handlers. SocketHandler
    level=DEBUG
    args=('localhos t', handlers.DEFAUL T_TCP_LOGGING_P ORT)
    host=localhost
    port=DEFAULT_TC P_LOGGING_PORT

    [formatter_simpl eFormatter]
    format=%(asctim e)s - %(name)s - %(levelname)s - %(message)s
    datefmt=
    '''
  • Vinay Sajip

    #2
    Re: logging via SocketHandler and TCPserver

    On Jul 13, 9:25 pm, Larry Bates <larry.ba...@we bsafe.com`wrote :
    Every time I look at theloggingmodul e (up until now) I've given up and
    continue to use my home-grown logger that I've been using for years. I'm not
    giving up this time ;-)
    >
    I find that I REALLY need to be able to monitor LOTS of running
    programs/processes and thought it would be nice to have them use SocketHandlerlo ggingand then I would write TCPServer to accept the log messages for
    real-time monitoring. I Googled (is that now a verb?) for several hours and
    came up with some code that I've turned in to something that works, but I can't
    figure out how to disconnect the server once it is connected The goal is to be
    able to start TCPServer, monitor the log messages sent via SocketHandler logger,
    disconnect, and move to the next application. Eventually I would like to wrap a
    GUI around all of this for monitoring a complex web application.
    >
    Everything works, it just appears that I get into the while loop in
    LogRecordStream Handler.handle and it never breaks out (until I kill the client).
    I can't seem to do anything with the LogRecordSocket Receiver.abort attribute to
    make it quit.
    >
    I'm sure it is something simple (stupid?), but I've spent about 4 hours and I'm
    not getting anywhere.
    >
    Thanks in advance for any assistance.
    >
    Regards,
    Larry
    >
    Below is my code:
    >
    import sys
    import time
    importlogging
    >
    if sys.argv[1] == 'client':
    importlogging.c onfig
    >
    logging.config. fileConfig("log ging.conf")
    >
    #create logger
    logger =logging.getLog ger("VESconsole ")
    >
    while 1:
    logger.debug("d ebug message")
    logger.info("in fo message")
    logger.warn("wa rn message")
    logger.error("e rror message")
    logger.critical ("critical message")
    time.sleep(2)
    >
    elif sys.argv[1] == 'server':
    import cPickle
    importlogging.h andlers
    import SocketServer
    import struct
    import signal
    >
    class LogRecordStream Handler(SocketS erver.StreamReq uestHandler):
    """Handler for a streamingloggin grequest.
    >
    This basically logs the record using whateverlogging policy is
    configured locally.
    """
    >
    def handle(self):
    """
    Handle multiple requests - each expected to be a 4-byte length,
    followed by the LogRecord in pickle format. Logs the record
    according to whatever policy is configured locally.
    """
    while 1:
    chunk = self.connection .recv(4)
    if len(chunk) < 4:
    break
    >
    slen = struct.unpack(" >L", chunk)[0]
    chunk = self.connection .recv(slen)
    while len(chunk) < slen:
    chunk = chunk + self.connection .recv(slen - len(chunk))
    >
    obj = self.unPickle(c hunk)
    record =logging.makeLo gRecord(obj)
    self.handleLogR ecord(record)
    >
    def unPickle(self, data):
    return cPickle.loads(d ata)
    >
    def handleLogRecord (self, record):
    t = time.strftime(' %a, %d %b %y %H:%M:%S',
    time.localtime( record.created) )
    >
    print "%s %s" % (t, record.getMessa ge())
    >
    class LogRecordSocket Receiver(Socket Server.Threadin gTCPServer):
    """simple TCP socket-basedloggingrec eiver suitable for testing.
    """
    >
    allow_reuse_add ress = 1
    >
    def __init__(self, host='localhost ',
    port=logging.ha ndlers.DEFAULT_ TCP_LOGGING_POR T,
    handler=LogReco rdStreamHandler ):
    >
    SocketServer.Th readingTCPServe r.__init__(self ,
    (host, port),
    handler)
    self.abort = 0
    self.timeout = 1
    self.logname = None
    >
    def serve_until_sto pped(self):
    import select
    abort = 0
    while not abort:
    rd, wr, ex = select.select([self.socket.fil eno()],
    [], [],
    self.timeout)
    if rd:
    self.handle_req uest()
    >
    abort = self.abort
    >
    print "serve_until_st opped exiting"
    >
    #
    # Start ThreadingTCPSer ver instance to accept SocketHandler log
    # messages from client.
    #
    tcpserver = LogRecordSocket Receiver()
    print "Starting ThreadingTCPSer ver..."
    tcpserver.serve _until_stopped( )
    >
    '''
    #-----logging.conf-----
    [loggers]
    keys=root
    >
    [handlers]
    keys=socketHand ler
    >
    [formatters]
    keys=simpleForm atter
    >
    [logger_root]
    level=DEBUG
    handlers=socket Handler
    >
    [handler_socketH andler]
    class=handlers. SocketHandler
    level=DEBUG
    args=('localhos t', handlers.DEFAUL T_TCP_LOGGING_P ORT)
    host=localhost
    port=DEFAULT_TC P_LOGGING_PORT
    >
    [formatter_simpl eFormatter]
    format=%(asctim e)s - %(name)s - %(levelname)s - %(message)s
    datefmt=
    '''
    Hi Larry,

    You can make the server quit (set abort to True) by changing the logic
    of the server appropriately. In your script (as in the example at
    http://docs.python.org/lib/network-logging.html), nothing sets
    server.abort, so the server never quits. If you were to insert a line
    "self.server.ab ort = True" before the break in the check "if
    len(chunk) < 4:", then the server will quit whenever a message shorter
    than 4 bytes is received; ordinarily, a SocketHandler will always send
    a 4-byte length followed by content. You can test this easily as
    follows:

    Run the server after modifying the script as described above.
    Run the client and observe some messages printed by the server.
    Kill the client. The server should still be waiting for events from
    clients, though it might quit if, when you kill the client, a
    truncated message is sent.
    Run "telnet localhost 9020" and type a character.
    The server should quit. If you make the "quitting" message a
    raw_input() call, then you can see that the server has exited normally
    via the abort flag.

    Don't forget, the receiver can receive events from several
    applications. You don't need to disconnect and reconnect. Simply have
    each event sent by an app identify the app in some way - e.g. the
    logger name could be "VESconsole.app 1" for one app and
    "VESconsole.app 2" in another. In your server's handleRecord code, you
    can get the logger name, decode the sending app from that and route
    the event appropriately.

    Another approach is to subclass SocketHandler and override the
    makePickle method. This determines the wire format of the event sent
    to the server, and if you change the wire format and modify the server
    end to suit, then you can have any amount of flexibility in the
    communications between the applications generating the events and the
    server collating them.

    I'm not sure why you've had so much trouble with logging in the past,
    or why it took several hours of Googling to find a solution relating
    to logging events across a network. I Googled for "python network
    logging" and the link in the Python docs which I referenced earlier
    was the first result, and hence also available via the "I'm Feeling
    Lucky" button ;-)

    Best regards,

    Vinay

    Comment

    • Larry Bates

      #3
      Re: logging via SocketHandler and TCPserver

      Vinay Sajip wrote:
      On Jul 13, 9:25 pm, Larry Bates <larry.ba...@we bsafe.com`wrote :
      >Every time I look at theloggingmodul e (up until now) I've given up and
      >continue to use my home-grown logger that I've been using for years. I'm not
      >giving up this time ;-)
      >>
      >I find that I REALLY need to be able to monitor LOTS of running
      >programs/processes and thought it would be nice to have them use SocketHandlerlo ggingand then I would write TCPServer to accept the log messages for
      >real-time monitoring. I Googled (is that now a verb?) for several hours and
      >came up with some code that I've turned in to something that works, but I can't
      >figure out how to disconnect the server once it is connected The goal is to be
      >able to start TCPServer, monitor the log messages sent via SocketHandler logger,
      >disconnect, and move to the next application. Eventually I would like to wrap a
      >GUI around all of this for monitoring a complex web application.
      >>
      >Everything works, it just appears that I get into the while loop in
      >LogRecordStrea mHandler.handle and it never breaks out (until I kill the client).
      >I can't seem to do anything with the LogRecordSocket Receiver.abort attribute to
      >make it quit.
      >>
      >I'm sure it is something simple (stupid?), but I've spent about 4 hours and I'm
      >not getting anywhere.
      >>
      >Thanks in advance for any assistance.
      >>
      >Regards,
      >Larry
      >>
      >Below is my code:
      >>
      >import sys
      >import time
      >importloggin g
      >>
      >if sys.argv[1] == 'client':
      > importlogging.c onfig
      >>
      > logging.config. fileConfig("log ging.conf")
      >>
      > #create logger
      > logger =logging.getLog ger("VESconsole ")
      >>
      > while 1:
      > logger.debug("d ebug message")
      > logger.info("in fo message")
      > logger.warn("wa rn message")
      > logger.error("e rror message")
      > logger.critical ("critical message")
      > time.sleep(2)
      >>
      >elif sys.argv[1] == 'server':
      > import cPickle
      > importlogging.h andlers
      > import SocketServer
      > import struct
      > import signal
      >>
      > class LogRecordStream Handler(SocketS erver.StreamReq uestHandler):
      > """Handler for a streamingloggin grequest.
      >>
      > This basically logs the record using whateverlogging policy is
      > configured locally.
      > """
      >>
      > def handle(self):
      > """
      > Handle multiple requests - each expected to be a 4-byte length,
      > followed by the LogRecord in pickle format. Logs the record
      > according to whatever policy is configured locally.
      > """
      > while 1:
      > chunk = self.connection .recv(4)
      > if len(chunk) < 4:
      > break
      >>
      > slen = struct.unpack(" >L", chunk)[0]
      > chunk = self.connection .recv(slen)
      > while len(chunk) < slen:
      > chunk = chunk + self.connection .recv(slen - len(chunk))
      >>
      > obj = self.unPickle(c hunk)
      > record =logging.makeLo gRecord(obj)
      > self.handleLogR ecord(record)
      >>
      > def unPickle(self, data):
      > return cPickle.loads(d ata)
      >>
      > def handleLogRecord (self, record):
      > t = time.strftime(' %a, %d %b %y %H:%M:%S',
      > time.localtime( record.created) )
      >>
      > print "%s %s" % (t, record.getMessa ge())
      >>
      > class LogRecordSocket Receiver(Socket Server.Threadin gTCPServer):
      > """simple TCP socket-basedloggingrec eiver suitable for testing.
      > """
      >>
      > allow_reuse_add ress = 1
      >>
      > def __init__(self, host='localhost ',
      > port=logging.ha ndlers.DEFAULT_ TCP_LOGGING_POR T,
      > handler=LogReco rdStreamHandler ):
      >>
      > SocketServer.Th readingTCPServe r.__init__(self ,
      > (host, port),
      > handler)
      > self.abort = 0
      > self.timeout = 1
      > self.logname = None
      >>
      > def serve_until_sto pped(self):
      > import select
      > abort = 0
      > while not abort:
      > rd, wr, ex = select.select([self.socket.fil eno()],
      > [], [],
      > self.timeout)
      > if rd:
      > self.handle_req uest()
      >>
      > abort = self.abort
      >>
      > print "serve_until_st opped exiting"
      >>
      > #
      > # Start ThreadingTCPSer ver instance to accept SocketHandler log
      > # messages from client.
      > #
      > tcpserver = LogRecordSocket Receiver()
      > print "Starting ThreadingTCPSer ver..."
      > tcpserver.serve _until_stopped( )
      >>
      >'''
      >#-----logging.conf-----
      >[loggers]
      >keys=root
      >>
      >[handlers]
      >keys=socketHan dler
      >>
      >[formatters]
      >keys=simpleFor matter
      >>
      >[logger_root]
      >level=DEBUG
      >handlers=socke tHandler
      >>
      >[handler_socketH andler]
      >class=handlers .SocketHandler
      >level=DEBUG
      >args=('localho st', handlers.DEFAUL T_TCP_LOGGING_P ORT)
      >host=localho st
      >port=DEFAULT_T CP_LOGGING_PORT
      >>
      >[formatter_simpl eFormatter]
      >format=%(ascti me)s - %(name)s - %(levelname)s - %(message)s
      >datefmt=
      >'''
      >
      Hi Larry,
      >
      You can make the server quit (set abort to True) by changing the logic
      of the server appropriately. In your script (as in the example at
      http://docs.python.org/lib/network-logging.html), nothing sets
      server.abort, so the server never quits. If you were to insert a line
      "self.server.ab ort = True" before the break in the check "if
      len(chunk) < 4:", then the server will quit whenever a message shorter
      than 4 bytes is received; ordinarily, a SocketHandler will always send
      a 4-byte length followed by content. You can test this easily as
      follows:
      >
      Run the server after modifying the script as described above.
      Run the client and observe some messages printed by the server.
      Kill the client. The server should still be waiting for events from
      clients, though it might quit if, when you kill the client, a
      truncated message is sent.
      Run "telnet localhost 9020" and type a character.
      The server should quit. If you make the "quitting" message a
      raw_input() call, then you can see that the server has exited normally
      via the abort flag.
      >
      Don't forget, the receiver can receive events from several
      applications. You don't need to disconnect and reconnect. Simply have
      each event sent by an app identify the app in some way - e.g. the
      logger name could be "VESconsole.app 1" for one app and
      "VESconsole.app 2" in another. In your server's handleRecord code, you
      can get the logger name, decode the sending app from that and route
      the event appropriately.
      >
      Another approach is to subclass SocketHandler and override the
      makePickle method. This determines the wire format of the event sent
      to the server, and if you change the wire format and modify the server
      end to suit, then you can have any amount of flexibility in the
      communications between the applications generating the events and the
      server collating them.
      >
      I'm not sure why you've had so much trouble with logging in the past,
      or why it took several hours of Googling to find a solution relating
      to logging events across a network. I Googled for "python network
      logging" and the link in the Python docs which I referenced earlier
      was the first result, and hence also available via the "I'm Feeling
      Lucky" button ;-)
      >
      Best regards,
      >
      Vinay
      Vinay,

      Thanks for your detailed explanation, but IMHO your suggested solution is almost
      the opposite (right idea wrong direction) of what I'm looking for. Hypothetical
      setup:


      application1 - SocketHandler logging turned on
      application2 - SocketHandler logging turned on
      application3 - SocketHandler logging turned on
      ..
      ..
      ..
      applicationN

      monitoring app - ThreadingTCPSer ver target that Allows user to connect to ANY
      running application and to view the real-time log messages. After monitoring,
      it should be able to disconnect and connect to another application... The
      clients (application1.. N) never stop sending and don't ever send anything short
      to disconnect themselves from the monitoring application. The disconnect/
      reconnect is done at the monitoring app end based on input from the user. I
      think each one would be logging to a different port, but I never really quite
      got that far. Perhaps there is some other way that I'm missing. It seems like
      this is something that might be able to be "generalize d" into a robust
      monitoring application for an arbitrary number of asynchronously running
      applications.

      Each application's real-time log might be reached by clicking on a tab, menu, etc.

      As to the difficulty, I might just have a mental block but two modules that I've
      had a real hard time getting my mind wrapped around is your Logging and Twisted.
      They both have a multitude of options/ways to be used and not very many working
      examples to work from. Might be a chance to make some money on a book. If it
      was full of examples, I'd purchase it.

      Regards,
      Larry

      Comment

      • Vinay Sajip

        #4
        Re: logging via SocketHandler and TCPserver

        On Jul 14, 11:16 pm, Larry Bates <larry.ba...@we bsafe.com`wrote :
        Vinay,
        >
        Thanks for your detailed explanation, but IMHO your suggested solution is almost
        the opposite (right idea wrong direction) of what I'm looking for. Hypothetical
        setup:
        >
        application1 - SocketHandlerlo ggingturned on
        application2 - SocketHandlerlo ggingturned on
        application3 - SocketHandlerlo ggingturned on
        .
        .
        .
        applicationN
        >
        monitoring app - ThreadingTCPSer ver target that Allows user to connect to ANY
        running application and to view the real-time log messages. After monitoring,
        it should be able to disconnect and connect to another application... The
        clients (application1.. N) never stop sending and don't ever send anything short
        to disconnect themselves from the monitoring application. The disconnect/
        reconnect is done at the monitoring app end based on input from the user. I
        think each one would beloggingto a different port, but I never really quite
        got that far. Perhaps there is some other way that I'm missing. It seems like
        this is something that might be able to be "generalize d" into a robust
        monitoring application for an arbitrary number of asynchronously running
        applications.
        >
        Each application's real-time log might be reached by clicking on a tab, menu, etc.
        Here's how I see it: the socket server listens, and receives logging
        events from numerous applications in real time. If the server is
        configured to monitor app1, then it quietly discards (or doesn't show
        in the UI) all events from other apps - it only collects/shows events
        from app1. When you click on a tab/menu/whatever to switch to
        monitoring app2, then this information is used to tell the server to
        discard (or not show) events from all apps except app2. You would of
        course need to ensure the communication between UI thread and server
        thread were done in a thread-safe manner.
        As to the difficulty, I might just have a mental block but two modules that I've
        had a real hard time getting my mind wrapped around is yourLoggingand Twisted.
        They both have a multitude of options/ways to be used and not very many working
        examples to work from. Might be a chance to make some money on a book. If it
        was full of examples, I'd purchase it.
        >
        But there are numerous examples in the logging docs - the script you
        quoted as having put together after several hours of Googling is
        pretty much the same as the (working) version in the logging docs! If
        you have reviewed the logging docs and find them lacking examples,
        please provide more detail about the kind of examples you think are
        missing. And I can't speak for Twisted, but it does a lot more than
        logging - and I don't think there's enough complexity in Python
        logging to warrant a paid-for book. (No doubt people will tell me if
        they disagree!)

        Best regards,

        Vinay Sajip

        Comment

        • Larry Bates

          #5
          Re: logging via SocketHandler and TCPserver

          Vinay Sajip wrote:
          On Jul 14, 11:16 pm, Larry Bates <larry.ba...@we bsafe.com`wrote :
          >Vinay,
          >>
          >Thanks for your detailed explanation, but IMHO your suggested solution is almost
          >the opposite (right idea wrong direction) of what I'm looking for. Hypothetical
          >setup:
          >>
          >application1 - SocketHandlerlo ggingturned on
          >application2 - SocketHandlerlo ggingturned on
          >application3 - SocketHandlerlo ggingturned on
          >.
          >.
          >.
          >applicationN
          >>
          >monitoring app - ThreadingTCPSer ver target that Allows user to connect to ANY
          >running application and to view the real-time log messages. After monitoring,
          >it should be able to disconnect and connect to another application... The
          >clients (application1.. N) never stop sending and don't ever send anything short
          >to disconnect themselves from the monitoring application. The disconnect/
          >reconnect is done at the monitoring app end based on input from the user. I
          >think each one would beloggingto a different port, but I never really quite
          >got that far. Perhaps there is some other way that I'm missing. It seems like
          >this is something that might be able to be "generalize d" into a robust
          >monitoring application for an arbitrary number of asynchronously running
          >applications .
          >>
          >Each application's real-time log might be reached by clicking on a tab, menu, etc.
          >
          Here's how I see it: the socket server listens, and receives logging
          events from numerous applications in real time. If the server is
          configured to monitor app1, then it quietly discards (or doesn't show
          in the UI) all events from other apps - it only collects/shows events
          from app1. When you click on a tab/menu/whatever to switch to
          monitoring app2, then this information is used to tell the server to
          discard (or not show) events from all apps except app2. You would of
          course need to ensure the communication between UI thread and server
          thread were done in a thread-safe manner.
          >
          >As to the difficulty, I might just have a mental block but two modules that I've
          >had a real hard time getting my mind wrapped around is yourLoggingand Twisted.
          >They both have a multitude of options/ways to be used and not very many working
          >examples to work from. Might be a chance to make some money on a book. If it
          >was full of examples, I'd purchase it.
          >>
          >
          But there are numerous examples in the logging docs - the script you
          quoted as having put together after several hours of Googling is
          pretty much the same as the (working) version in the logging docs! If
          you have reviewed the logging docs and find them lacking examples,
          please provide more detail about the kind of examples you think are
          missing. And I can't speak for Twisted, but it does a lot more than
          logging - and I don't think there's enough complexity in Python
          logging to warrant a paid-for book. (No doubt people will tell me if
          they disagree!)
          >
          Best regards,
          >
          Vinay Sajip
          Can multiple applications send SocketHandler logging records to the same socket
          server on the same port simultaneously? If so, then I understand your answer
          completely and will go in that direction. I guess I was trying to not use up
          bandwidth/CPU cycles on the applications that weren't being actively monitored
          by just not having the socket server connected to them.

          I think you may be a 'little to close' to the (excellent) application you have
          written to understand the steep learning curve that I see. You know the saying,
          "Brain surgery is easy to a brain surgeon". I should point out that I'm no
          newbie. I've used PIL, ReportLab, BeautifulSoup, Mechanize, Win32 extensions,
          ElementTree and a whole host of other modules with less difficulty. Please
          don't take this as anything more than an observation on my part. From what I
          see, you have written (and generously donated) an extremely powerful library and
          it is greatly appreciated. It is most likely just me.

          As far as the book is concerned, I guess I'd purchase the only copy ;-).

          I do appreciate your help very much.

          Regards,
          Larry

          Comment

          • Rob Wolfe

            #6
            Re: logging via SocketHandler and TCPserver

            Larry Bates <larry.bates@we bsafe.com`write s:
            Can multiple applications send SocketHandler logging records to the
            same socket server on the same port simultaneously?
            Of course they can. Server can accept requests from many clients.
            You have used `SocketServer.T hreadingTCPServ er`. That server for example
            handles every request in a different thread.
            If so, then I understand your answer completely and will go
            in that direction. I guess I was trying to not use up
            bandwidth/CPU cycles on the applications that weren't being actively
            monitored by just not having the socket server connected to them.
            >
            I think you may be a 'little to close' to the (excellent) application
            you have written to understand the steep learning curve that I see.
            You know the saying, "Brain surgery is easy to a brain surgeon". I
            should point out that I'm no newbie. I've used PIL, ReportLab,
            BeautifulSoup, Mechanize, Win32 extensions, ElementTree and a whole
            host of other modules with less difficulty. Please don't take this as
            anything more than an observation on my part. From what I see, you
            have written (and generously donated) an extremely powerful library
            and it is greatly appreciated. It is most likely just me.
            Well, I know what you mean. I had troubles to understand that library
            either. Logging docs are quite good as a reference, but there is lack
            of a good introductory tutorial. Now when I know `logging` I can't live
            without it, but the start wasn't easy.
            I shouldn't say it here, but I found helpful docs to the similar
            library in Java. ;)


            There are many differences (e.g. Appenders vs Handlers), but the rule
            is the same.
            As far as the book is concerned, I guess I'd purchase the only copy ;-).
            "The Art of Logging" - four volumes. ;-)

            Regards,
            Rob

            Comment

            • Larry Bates

              #7
              Re: logging via SocketHandler and TCPserver

              Rob Wolfe wrote:
              Larry Bates <larry.bates@we bsafe.com`write s:
              >
              >Can multiple applications send SocketHandler logging records to the
              >same socket server on the same port simultaneously?
              >
              Of course they can. Server can accept requests from many clients.
              You have used `SocketServer.T hreadingTCPServ er`. That server for example
              handles every request in a different thread.
              >
              >If so, then I understand your answer completely and will go
              >in that direction. I guess I was trying to not use up
              >bandwidth/CPU cycles on the applications that weren't being actively
              >monitored by just not having the socket server connected to them.
              >>
              >I think you may be a 'little to close' to the (excellent) application
              >you have written to understand the steep learning curve that I see.
              >You know the saying, "Brain surgery is easy to a brain surgeon". I
              >should point out that I'm no newbie. I've used PIL, ReportLab,
              >BeautifulSou p, Mechanize, Win32 extensions, ElementTree and a whole
              >host of other modules with less difficulty. Please don't take this as
              >anything more than an observation on my part. From what I see, you
              >have written (and generously donated) an extremely powerful library
              >and it is greatly appreciated. It is most likely just me.
              >
              Well, I know what you mean. I had troubles to understand that library
              either. Logging docs are quite good as a reference, but there is lack
              of a good introductory tutorial. Now when I know `logging` I can't live
              without it, but the start wasn't easy.
              I shouldn't say it here, but I found helpful docs to the similar
              library in Java. ;)

              >
              There are many differences (e.g. Appenders vs Handlers), but the rule
              is the same.
              >
              >As far as the book is concerned, I guess I'd purchase the only copy ;-).
              >
              "The Art of Logging" - four volumes. ;-)
              >
              Regards,
              Rob
              Five volumes if you add in "Logging within Frameworks (Django, TurboGears, and
              Pylons" ;-).

              Now on to UnitTesting (I use a home-grown method), Twisted, and other things I
              can't seem to find time to get my brain around...

              -Larry

              Comment

              Working...