On Mar 9, 2:10 pm, writeson wrote:
> My manager is suggesting that the underlying problem is using TCP
> rather than UDP (SocketHandler vs DatagramHandler) forloggingfrom
> clients to theloggingserver. His assertion is that using TCP would
> guarantee the loss of 2 messages at theloggingserver fro
reconnected to the server after a short delay. Messages were dropped
while the server was down, but that was what I expected. This makes it
look like I raised a "false alarm" and the
logging.handlers.SocketHandler is behaving as expected, and it is more
likely there is a problem in my applic
On Mar 6, 4:09 pm, writeson wrote:
> To further complicate my original question, here is more information.
> Theloggingserver I created uses Twisted (2.5.0) as it's network
> framework and gets network log messages from the clients using Twisted
> code. However, once a message is received it is pa
ging module, and the
logging.handlers.SocketHandler system specifically. So the clients
should try to reconnect if the server goes down and comes back up. So
I'm a little confused what to try next to resolve the problem I'm
seeing.
By the way, the Python logging system is great, really nice w
On Mar 5, 7:38 pm, writeson wrote:
> Hi everyone,
>
> I wrote aloggingserver that receives messages
> fromlogging.handlers.SocketHandler objects in client Python programs. This
> works well so long as the client programs are start/stop affairs.
> However, if the client is also a long running daem
Hi everyone,
I wrote a logging server that receives messages from
logging.handlers.SocketHandler objects in client Python programs. This
works well so long as the client programs are start/stop affairs.
However, if the client is also a long running daemon a problem shows
up. If the logging server
