[
https://issues.apache.org/jira/browse/LOG4J2-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669294#comment-13669294
]
Ralph Goers commented on LOG4J2-246:
------------------------------------
OK. I don't think this Jira issue is the correct place to discuss enhancements
to DefaultErrorHandler.
> UDP socket Appender error
> -------------------------
>
> Key: LOG4J2-246
> URL: https://issues.apache.org/jira/browse/LOG4J2-246
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Core
> Affects Versions: 2.0-beta5
> Reporter: Remko Popma
> Fix For: 2.0-beta7
>
>
> On 2013/05/09, at 18:34, Tomek Kaczynski <[email protected]> wrote:
> Hi All,
> I'm using log4j2 since beta4, now beta5. In general it's a cute library,
> but there's some bug that I've found out recently :
> When a client code genreates a huge message ( 64k ), the underlying
> DatagramOutputStream fails ( UDP socket throws exception).
> After that all following flushes fail because data buffer is not cleared
> upon exception.
> So in lines
> DatagramOutputStream:91
> ----------------------------------------------------------------------
> public synchronized void flush() throws IOException {
> if (this.data != null && this.ds != null && this.address != null) {
> final DatagramPacket packet = new DatagramPacket(data,
> data.length, address, port);
> ds.send(packet);
> }
> data = null;
> }
> --------------------------------------------------------------------------
>
> data = null should be put in finally block or some simillar solution could be
> applied.
> What do you think ?
> Regards,
> Tomek
> Moreover DatagramOutputStream should check if message size is less then 64k .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
