Hi Thorbjoern.
On 28.02.2009, at 10:50, Thorbjoern Ravn Andersen wrote:
Joern Huxhorn skrev:
I tried to provide some explanations and background informations
about the way my multiplex appender is working.
Could you say why you've named it multiplex appender? I've missed
it if you said it already? Perhaps because it can send to multiple
receivers?
Oh yes, that's the reason. Funny that I failed to mention it ... :)
http://apps.sourceforge.net/trac/lilith/wiki/MultiplexAppenderBackground
Additionally, I collected some pitfalls of other appenders.
http://apps.sourceforge.net/trac/lilith/wiki/AppenderPitfalls
I'm not sure if I succeeded in explaining the complexity of my
appender but I tried my best, for sure ;)
If I understand your writeup correctly there are three basic issues
you are dealing with:
* detecting if a receiver goes away
It's only a problem if a receiver leaves in a dirty way, e.g.
unplugging the network cable or putting the computer to sleep, instead
of closing the stream/app first. If the stream is properly closed, the
appender receives an IOException when it's trying to use the stream
the next time. Otherwise, the appender will hang while writing.
* flattening events at the proper time to ensure that the contents
is right when deserialized
* buffering events to ensure the application can run at full speed
independently from the speed of the receivers
Yes, exactly.
We are routinely logging certain classes to > 10 receivers - while in
production!!
The first one, should it be enough to detect a broken TCP/IP
connection?
I've found no other way beside the TimeoutOutputStream that I'm using
now. Any other idea?
I am still pondering on a language agnostic receiver. The reason
for the XML being uninteresting was because it was much more verbose
than the plain serialised byte object?
I wouldn't call it uninteresting ;)
It's just more expensive to create such events so I'd only use it if I
have to.
The main objectives of my XML schema are:
- lossless conversion
It must be possible to create the exact same event from the XML
that was used to create it in the first place. This isn't the case wit
the log4j XML because it flattens the NDC. Beside that, if used in
conjunction with Logback, it destroys the messagePattern and arguments
of the original event. I plan to use those for translation of log
messages.
- readable by a human being
otherwise there's no real point to use XML. I could just define a
binary format, right?
Would a sufficiently terse xml-dialect be interesting? I was
thinking of having one-character node names and attribute names?
(and moving the namespace outside the fragments).
I'm not sure about that. Thinking about a binary format would probably
be more worthwhile...
Joern.
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
