Hi there,

First of all I have to say that Log4Net is the best logging library I have ever seen. Our company evaluated between 5 and 10 logging apis, some of them were even commercial ones. But Log4Net really kicks ass! :-)

For our company I have written a log viewer that listens on UDP. This tool works just fine but as you guys know UDP has one major problem: Sometimes messages are just "eaten", sometimes they come in a wrong order etc. For logging purposes where performance of the app is more important than 100 % correct log behaviour UDP might be the correct choice. For the purposes of our company performance is not an issue but we use this tool for live-diagnosis of customer problems.

So I wonder if you guys could create a TCP appender? I guess many people would love that, too :-)

Thanks,

Best regards,

Immo Landwerth
Software Developer
__________________________________

    The Project Group GmbH
    - your project experts. -
    Neherstraße 9
    81675 München
    Germany

    Fon +49 (89) 61 55 93 - 51
    Fax +49 (89) 61 55 93 - 40

    il@TheProjectGroup.de
    http://www.TheProjectGroup.de
__________________________________

Do you know about Chainsaw:

 http://logging.apache.org/log4j/docs/images/chainsaw-fullscreen.jpg

Its a log viewer that is able to display logging events in real-time
from UDP, files, etc. sources. Its very configurable. You're able to
restrict messages from just certain loggers, certain levels, etc. To
set it up you need to make a config file for it and tell it load this
file when the program starts. I call mine Udp.xml:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
 <log4j:configuration
  xmlns:log4j="http://jakarta.apache.org/log4j/">
  <plugin name="UDPReceiver" class="org.apache.log4j.net.UDPReceiver">
   <param name="Port" value="8080" />
  </plugin>
 </log4j:configuration>

Then you need add an UdpAppender in your application's log4net config:

 <appender name="UdpAppender" type="log4net.Appender.UdpAppender">
  <remoteAddress value="127.0.0.1" />
   <remotePort value="8080" />
   <layout type="log4net.Layout.XmlLayoutSchemaLog4j">
    <locationInfo value="true" />
   </layout>
 </appender>

Here is the download link:

http://logging.apache.org/log4j/docs/webstart/chainsaw/chainsaw-bundle.zip

Hi,

> Do you know about Chainsaw:
>
> http://logging.apache.org/log4j/docs/images/chainsaw-fullscreen.jpg

Yes, I know this tool. In fact, this tools was the biggest inspiration ;-)

Since we use out log viewer also on computers used by customer we cannot enforce they have
a Java Runtime installed. Believe it or not, we had even problems with .NET itself.

> Its a log viewer that is able to display logging events in real-time from UDP, files, etc. sources.

The problem is not the tool itself but the protocoll; UDP just loses messages. So this problem would
persist.

Best regards,

Immo Landwerth
Software Developer
__________________________________

    The Project Group GmbH
    - your project experts. -
    Neherstraße 9
    81675 München

    Fon +49 (89) 61 55 93 - 51
    Fax +49 (89) 61 55 93 - 40

    il@TheProjectGroup.de
    http://www.TheProjectGroup.de
__________________________________

Another logging package for .Net is NLog:

 http://nlog.sourceforge.net/

The author of that package is working on an NLogViewer program that is
a single file executable (i.e. NLogViewer.exe). Its not complete yet
but when it is it will be similiar to Chainsaw. The version in source
control processes and displays log messages from log4net. Search his
list archives for some Flash movies I made showing NLogViewer in
action. NLog has a TcpAppender and NLogViewer has a TcpReciever.

I think a TcpAppender for log4net sounds like a good idea.

Hi Ron,

> Another logging package for .Net is NLog:
>
> http://nlog.sourceforge.net/
>
> The author of that package is working on an NLogViewer program that is a
> single file executable (i.e. NLogViewer.exe). Its not complete yet but
> when it is it will be similiar to Chainsaw. The version in source control
> processes and displays log messages from log4net. Search his list archives
> for some Flash movies I made showing NLogViewer in action. NLog has a
> TcpAppender and NLogViewer has a TcpReciever.

Thanks for this information I will have a look at that project.

> I think a TcpAppender for log4net sounds like a good idea.

So do I :-)

Regards,

Immo Landwerth
Software Developer
__________________________________

    The Project Group GmbH
    - your project experts. -
    Neherstraße 9
    81675 München

    Fon +49 (89) 61 55 93 - 51
    Fax +49 (89) 61 55 93 - 40

    il@TheProjectGroup.de
    http://www.TheProjectGroup.de
__________________________________

> So I wonder if you guys could create a TCP appender? I guess
> many people would love that, too :-)

We already have 2 TCP appenders - but maybe they are not what you want.

The RemotingAppender can be configured to use TCP. This allows
LoggingEvent objects to be sent over a TCP connection and reconstituted
on the target machine.

The TelnetAppender listens for TCP connections. This allows the log
viewer to connect into the application to receive log messages. This is
an inversion of the normal way of logging in that the app doing the
logging does not send the messages anywhere until a viewer actually
connects to it. This method is nice for the application because it
doesn't have to do any work when there are no viewers connected to it.

As far as writing something that operates like the UdpAppender but uses
TCP instead, it should be simple to get something working using a
socket. It is a little more complex when you start thinking about how to
maintain the connection and reconnect. log4j uses a separate thread to
attempt to reconnect every few seconds, which seems to be a reasonable
approach. It is worth noting that doing something like this means that
the appender (and hence the application hosting it) will be polling a
log view server every few seconds. If this server is only periodically
active then the application may be doing a lot of work for nothing.

Cheers,

Nicko

Hi Nicko,

Thanks for your answer.

> > So I wonder if you guys could create a TCP appender? I guess many
> > people would love that, too :-)
>
> We already have 2 TCP appenders - but maybe they are not what
> you want.
>
> The RemotingAppender can be configured to use TCP. This
> allows LoggingEvent objects to be sent over a TCP connection
> and reconstituted on the target machine.

Oh, that sounds interesting. Since my first thought was "TCP is more
stable than UDP" I haven't looked in this direction. Anyway, I like
that idea because it should rather easy to implement (and I don't have
to deploy a custom appender).

Today I am trying to get a more stable version of my log viewer using
the remoting appender.

> The TelnetAppender listens for TCP connections. This allows
> the log viewer to connect into the application to receive log
> messages. This is an inversion of the normal way of logging
> in that the app doing the logging does not send the messages
> anywhere until a viewer actually connects to it. This method
> is nice for the application because it doesn't have to do any
> work when there are no viewers connected to it.
>
> As far as writing something that operates like the
> UdpAppender but uses TCP instead, it should be simple to get
> something working using a socket. It is a little more complex
> when you start thinking about how to maintain the connection
> and reconnect. log4j uses a separate thread to attempt to
> reconnect every few seconds, which seems to be a reasonable
> approach. It is worth noting that doing something like this
> means that the appender (and hence the application hosting
> it) will be polling a log view server every few seconds. If
> this server is only periodically active then the application
> may be doing a lot of work for nothing.

Good point. I will try consider this but actually, we don't care
about performance at all. Our applications are mainly server sided
database-based applications. Logging is by default disabled or
strongly limited. The UdpAppender, RemotingAppender or somthing like
that is only enabled for debugging (due to the lack of remote debugging).

Regards,

Immo Landwerth
Software Developer
__________________________________

    The Project Group GmbH
    - your project experts. -
    Neherstraße 9
    81675 München

    Fon +49 (89) 61 55 93 - 51
    Fax +49 (89) 61 55 93 - 40

    il@TheProjectGroup.de
    http://www.TheProjectGroup.de
__________________________________