Frank-Olaf,
Isn't this the worst possible solution? I mean *hideously* bad. Maybe I don't
understand it but here is what I think will happen,
set SO_SNDBUF to 1;
while(there is something to send) {
send 1 byte();
// that is:
// encapsulate that single *byte* in a TCP packet;
// encapsulate the TCP header in an IP packet;
// send the IP packet over the wire; packet is now around 50 bytes;
// wait for acknowledgement on packet just sent;
// the wait period will be at least the round-trip latency of the channel,
// this is the most important factor as the latency will be high even in a gigabit
LAN.
}
Depending on the size of the LoggingEvents sent around, this solution will be say 100
to 200 times slower then the application level acks. Am I missing something? Ceki
At 16:16 01.02.2001 +0000, you wrote:
>Mark,
>
>If you want to be on the save side set your send buffer size to 1.
>Setting it is not guarantied by Java but I have tested with NT an there it works
>fine. Then if you write something to the socket the write is blocked until your data
>is send or you get an exception (timeout by the OS). If you call close in the same
>thread you are on the save side now. If you get an exception you have to decide what
>to do with your unsent message.
>Be aware of usage of multiple writes in a loop for only one message. With buffer size
>set to one you really send one package after the other each acknowledged over the
>wire first. writeObject() that is used in SocketAppender has this drawback. Now you
>are more secure for the price of degrade in link performance. To solve this drawback
>it is a good idea to use a buffered stream in front of the socket stream and use the
>flush that now do what we expect.
>
>Kind regards
>Frank-Olaf Lohmann
>
>
>>>> Mark Douglas <[EMAIL PROTECTED]> 01.02.2001 14.17 Uhr >>>
>Hi Ceki,
>
>I could get all apps to call into my utility code before they exit, but I
>was kind of hoping that I could 'hide' the fact that I was using log4j.
>It's a shame there are no destructors as in C++ ;-)
>
>I've had a quick play with trying to flush the Socket, but you are calling
>oos.flush() anyway in the SocketAppender.append() method.
>
>I have even tries playing with the SO_LINGER option on the socket, and that
>seemed to have no effect.
>
>Looks like the only thing that works is calling Category.shutdown().
>
>Sorry if this topic has been discussed before, but I'm fairly new to this
>forum.
>
>Thanks to everyone for all the feedback :)
>
>Mark Douglas
>Systems Union Group plc
>
>-----Original Message-----
>From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
>Sent: 01 February 2001 13:22
>To: LOG4J Developers Mailing List
>Subject: Re: Request for new method.
>
>
>At 12:04 01.02.2001 +0000, you wrote:
>>Hi All,
>>
>>I would like for a new method to be added to the Category class (along the
>>lines of the shutdown() method). The new method 'flush' would be called to
>>flush the buffers of all appenders in all categories. This really only
>>makes sense for SocketAppender and AsyncAppender as the other appenders
>>don't tend to buffer output (my understanding - possibly incorrect). Most
>>appenders would simply return from a call to their flush() method. The
>>SocketAppender would call oos.flush() for example.
>
>Hello Mark,
>
>Flushing the SocketAppender won't help at all. Not one bit. This makes sense
>because sending depends on the acknowledgement of the other side (the
>receiving side). Flushing on one side is pretty much useless.
>Closing the SocketAppender is different because the call will not return
>until all packets in the send buffer are acknowledged or until there is a
>timeout exception.
>
>What you need to do is to close all appenders (or call Category.shutdown)
>when your VM exists. Is that a possibility? Ceki
>
>>The reason:
>>At the moment, the only way to ensure that all Appender output is 'flushed'
>>is to call Category.shutdown(). This is fine for an app. that is about to
>>terminate, but for an app. that is continuing, calling Category.shutdown()
>>means that no further logging takes place.
>>
>>Why do I want to flush the buffers?
>>I have some utility code that is used in a number of applications. After
>my
>>code is called, some apps terminate and other do not. If I call
>>Category.shutdown() before my code returns, the apps that terminate are
>>fine, but the others carry on and can't perform further logging (all the
>>appenders have been deleted). If I don't call Category.shutdown(), the
>apps
>>that terminate lose a few logging messages because they are buffered in the
>>SocketAppender.
>>
>>To fix this, my utility code needs to be able to flush the buffers before
>>returning. This way, both types of app. would work correctly. Also, I
>>don't the apps to have to 'know' about log4j and therefore it would be
>>unreasonable for them to call Category.shutdown() before they exit.
>>
>>Ceki, is it possible to add this functionality for 1.1? Or is there
>>something I can do right now to solve this?
>>
>>Mark Douglas
>>Systems Union Group
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
----
Ceki Gülcü - Independent IT Consultant
av. de Rumine 5 Tel: ++41 21 351 23 15
CH-1005 Lausanne e-mail: [EMAIL PROTECTED] or
Switzerland [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
