On Jan 16, 2009, at 10:45 AM, Rhosyn wrote:
Dear all,
We would like to share with you a patch we use for log4cxx in order to
prevent an exception being raised when a very long message is logged.
We found our system was sometimes misbehaving due to an exception
being
raised by log4cxx when a very large message was logged - but only
when
the SyslogAppender/SyslogWriter was in use (other appenders "worked"
perfectly).
We eventually traced the issue to the message(s) in question being too
large to fit inside a UDP packet (the syslog protocol uses UDP).
We didn't want to massively restructure our program logic to be able
to
recover from rare logging errors e.g. by placing message length
checking
code or exception handling code around every call to every trace
function which might ever need to log a long message (after all,
logging, although important & useful, is not the focus of our
application - and "massive" log messages are a rarity ).
We were particularly certain that this course of action best suited
our
needs, given that the syslogappender wasn't the only appender in use
and
the other appenders were capturing the entire message safely.
Therefore we felt it pragmatic to instead simply truncate messages
that
are too long to be sent safely in a UDP packet just prior to sending
them.
The patch attached does just that - hopefully someone else will find
it
useful!
I would suggest it might be worth rolling a similar patch into any
future log4cxx release - although I also accept that that is a
philosophical point - and others might actually prefer the current
behaviour (although, as discussed previously, it is not behaviour that
we can easily/safely live with in our current project)
Cheers,
log4j also had similar issues which I assume log4cxx inherited. See
https://issues.apache.org/bugzilla/show_bug.cgi?id=42087
It would likely be good to align log4cxx with the current log4j
implementation. Again, please file a JIRA issue with this and even
better if you submit a patch with it.
